DE60220968T2

DE60220968T2 - Webfähige Spracherkennung

Info

Publication number: DE60220968T2
Application number: DE60220968T
Authority: DE
Inventors: Kuansan Bellevue Wang; Hsiao-Wuen Bellevue Hon
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2001-05-04
Filing date: 2002-05-03
Publication date: 2007-11-08
Anticipated expiration: 2022-05-04
Also published as: EP1255193B1; ATE366454T1; EP1255193A3; DE60220968D1; JP2003044093A; CN1266625C; EP1255193A2; JP4467226B2; CN1420446A

Description

HINTERGRUND DER ERFINDUNG
Die vorliegende Erfindung betrifft Zugang zu Informationen über ein Fernnetzwerk (wide area network), wie zum Beispiel das Internet. Insbesondere betrifft die vorliegende Erfindung netzwerkaktivierte Erkennung, die ermöglicht, dass auf einer Client-Seite Informationen und Steuerung unter Verwendung einer Vielzahl von Verfahren eingegeben werden können.
Kleine Computervorrichtungen, wie zum Beispiel Personal Information Manager (PIM, ein Zeitplanungssystem), Vorrichtungen und tragbare Telefone, werden von Menschen immer häufiger für alltägliche Tätigkeiten genutzt. Mit der nunmehr zur Verfügung stehenden zunehmenden Verarbeitungsleistung von Mikroprozessoren, die zum Betreiben der genannten Vorrichtungen verwendet werden, nimmt die Funktionalität der genannten Vorrichtungen zu und verschmilzt in einigen Fällen. Zum Beispiel können zahlreiche tragbare Telefone nunmehr verwendet werden, um auf das Internet zuzugreifen und in dem Internet zu browsen und um persönliche Informationen, wie zum Beispiel Adressen, Telefonnummern und ähnliches, zu speichern.
Angesichts des Umstandes, dass die genannten Computervorrichtungen zum Browsen im Internet verwendet werden, ist es daher notwendig, Informationen in die Computervorrichtung einzugeben. Aufgrund des Bemühens, die genannten Vorrichtungen möglichst klein zu halten, so dass sie gut tragbar sind, sind herkömmliche Tastaturen, die alle Buchstaben des Alphabets als einzelne Tasten aufweisen, aufgrund der begrenzten auf den Gehäusen der Computervorrichtungen zur Verfügung stehenden Fläche, normalerweise leider nicht möglich.
In jüngster Zeit wurden Sprachportale durch die Anwendung von VoiceXML (voice extensible markup language) weiterentwickelt, um zu ermöglichen, dass lediglich unter Verwendung eines Telefons auf Internetinhalte zugegriffen werden kann. In dieser Architektur verarbeitet ein Dokumentserver (zum Beispiel ein Webserver) Anfragen von einem Client über einen VoiceXML-Interpreter. Der Webserver kann als Antwort VoiceXML-Dokumente erzeugen, die durch den VoiceXML-Interpreter verarbeitet und für den Benutzer hörbar gemacht werden. Durch Verwendung von Sprachbefehlen durch Spracherkennung kann der Benutzer in dem Web navigieren.
VoiceXML ist eine Auszeichnungssprache mit Flusskontrolle-Steuerungskennzeichen, jedoch folgt die Flusskontrolle nicht dem HTML-Flusskontrolle-Modell (HTML = Hyper Text Markup Language), das Eventing (Synchronisieren verschiedener Tasks) und getrennte Scripts umfast. Vielmehr umfasst VoiceXML normalerweise einen Forminterpretationsalgorithmus, der besonders für telefonbasierte Nur-Sprache-Wechselwirkung geeignet ist und bei dem die von dem Benutzer gewonnenen Informationen häufig unter der Steuerung des Systems oder der Anwendung stehen. Die Integration von VoiceXML direkt in Anwendungen, die in einer Client-Server-Beziehung zur Verfügung stehen, in der graphisch auch Benutzerschnittstellen bereitgestellt werden, werden von dem Entwickler abverlangen, zwei Formen des Web-Authorings zu beherrschen, eine davon für VoiceXML und die andere unter Verwendung von HTML (oder ähnlichem), wobei eine jede davon einem unterschiedlichen Flusskontrolle-Modell folgt.
Es besteht somit ein fortlaufender Bedarf an Verbesserung der Architektur beziehungsweise von Teilen derselben, und der Verfahren, die zur Bereitstellung von Spracherkennung in einer Client-Server-Architektur, wie zum Beispiel dem Internet, verwendet werden. Das Authoringtool für Spracherkennung muss gut an kleine Computervorrichtungen, wie zum Beispiel an Personal Information Manager (PIM), Telefone und ähnliches, anpassbar sein. Eine Architektur oder ein Verfahren des Webauthoring, die oder das einen oder alle der oben genannten Nachteile anspricht und überwindet, wird insbesondere benötigt.
Ein nach dem Stand der Technik bekanntes System und Verfahren zum Bereitstellen von Spracherkennungsfähigkeiten für einen Computer in einem Netzwerk durch ein Spracherkennungssystem basierend auf einer Java-Anwendung ist aus EP 0 854 418 A bekannt.
Weiterhin beschreibt ein Artikel von Hemphill C. T. und Thrift P. R. unter dem Titel „Surfing the Web by Voice" ein System für Sprachaktivierung von HTML-basierten Webseiten durch einen Sprach-Benutzeragenten in der Form eines Anwendungsprogramms, das auf einem Client-Computer läuft und angezeigt wird.
Aus US 5,819,220 ist ein Verfahren zum Extrahieren einer Wortmenge aus einer HTML-basierten Webseite durch eine Java-Anwendung bekannt. Die Wortmenge wird verwendet, um eine Grammatik zum Ausführen eines Spracherkennungsprozesses durch die Java-Anwendung zu erzeugen.
ZUSAMMENFASSUNG DER ERFINDUNG
Ein Server-Client-System zum Verarbeiten von Daten umfasst ein Netzwerk, das einen Webserver mit Informationen aufweist, auf die von fern zugegriffen werden kann. Ein Client-Vorrichtung umfasst ein Eingabevorrichtung, wie zum Beispiel ein Mikrofon, und eine Rendering-Komponente, wie zum Beispiel einen Lautsprecher oder eine Anzeige. Die Client-Vorrichtung ist so konfiguriert, dass Informationen von dem Webserver abgerufen werden und die zu den Feldern in den Informationen zugehörigen Eingabedaten aufgezeichnet werden. Die Client-Vorrichtung ist angepasst, um die Eingabedaten an einen entfernten Ort mit einer Anzeige einer Grammatik zur Verwendung für Erkennung zu senden.
Als ein Aspekt der vorliegenden Erfindung empfängt ein Erkennungsserver, der durch die anhängenden unabhängigen Patentansprüche definiert wird, die Eingabedaten und die Anzeige der Grammatik. Der Erkennungsserver gibt die Daten, die anzeigen, was eingegeben worden ist, an wenigstens entweder den Client oder den Webserver zurück.
Als ein zweiter Aspekt der vorliegenden Erfindung umfasst eine Auszeichnungssprache zur Ausführung auf einer Client-Vorrichtung in einem Client-Server-System Befehle zur Vereinheitlichung von wenigstens entweder erkennungsbezogenen Ereignissen, GUI-Ereignissen (GUI = graphische Benutzerschnittstelle) und Telephonieereignissen an einer spracheingabebasierten Nichtanzeige-Client-Vorrichtung und einem multi modalbasierten Client für einen Webserver, der mit einem jeden der Client-Vorrichtungen in Wechselwirkung steht.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 ist eine Draufsicht eines ersten Ausführungsbeispieles einer Computervorrichtungs-Betriebsumgebung.
2 ist ein Blockschema der Computervorrichtung aus 1.
3 ist eine Draufsicht eines Telefons.
4 ist ein Blockschema eines Allzweckcomputers.
5 ist ein Blockschema einer Architektur für ein Client-Server-System.
6 ist eine Anzeige zum Erfassen von Kreditkarteninformationen.
7 ist eine Seite einer Auszeichnungssprache, die auf einem Client ausführbar ist.
8 ist eine beispielhafte Seite einer Auszeichnungssprache, die auf einem Client, der eine Anzeige und Spracherkennungsfähigkeiten aufweist, ausführbar ist.
9A und 9B sind eine beispielhafte Seite einer Auszeichnungssprache, die auf einem Client mit akustischem Rendering und Systeminitiative ausführbar ist.
10A und 10B sind eine beispielhafte Seite einer Auszeichnungssprache, die auf einem Client mit akustischem Rendering und gemischter Initiative ausführbar ist.
11 ist ein beispielhaftes Script, das von einem serverseitigen Steckmodul ausführbar ist.
12 ist eine bildliche Darstellung eines ersten Betriebsmodus eines Erkennungsservers.
13 ist eine bildliche Darstellung eines zweiten Betriebsmodus des Erkennungsservers.
14 ist eine bildliche Darstellung eines dritten Betriebsmodus des Erkennungsservers.
15A und 15B sind eine beispielhafte Seite einer deklarativen Auszeichnungssprache, die auf einem Client ohne Scripting ausführbar ist.
AUSFÜHRLICHE BESCHREIBUNG DER VERANSCHAULICHENDEN AUSFÜHRUNGSBEISPIELE
Bevor die Architektur von webbasierter Erkennung sowie Verfahren zur Durchführung derselben beschrieben werden, kann es zweckdienlich sein, allgemein Computervorrichtungen zu beschreiben, die in der Architektur arbeiten können. Unter Bezugnahme auf 1 wird eine beispielhafte Form einer Datenverwaltungsvorrichtung (Personal Information Manager, PIM; elektronischer Assistent, PDA; oder ähnliches) mit 30 veranschaulicht. Es wird jedoch davon ausgegangen, dass die vorliegende Erfindung unter Verwendung anderer weiter unten diskutierter Computervorrichtungen und insbesondere von Computervorrichtungen mit einer begrenzten Fläche für Eingabetasten und ähnliches durchgeführt werden kann. Zum Beispiel werden auch Telefone und/oder Datenverwaltungsvorrichtungen von der hier vorliegenden Erfindung profitieren. Solche Vorrichtungen werden im Vergleich zu vorhandenen tragbaren persönlichen Informationsverwaltungsvorrichtungen und zu anderen tragbaren elektronischen Vorrichtungen eine verbesserte oder erweiterte Dienstprogrammfunktion aufweisen, und die Funktionen und die kompakte Größe solcher Vorrichtungen wird den Benutzer ermutigen, die Vorrichtung stets bei sich zu tragen. Dementsprechend ist es nicht beabsichtigt, die hierin beschriebene Architektur durch die Offenlegung einer beispielhaften Datenverwaltung oder einer hierin veranschaulichten PIM-Vorrichtung, eines Telefons oder Computers einzuschränken.
Eine beispielhafte Form einer mobilen Datenverwaltungsvorrichtung 30 wird in 1 veranschaulicht. Die Mobilvorrichtung 30 umfasst ein Gehäuse 32 und weist eine Benutzerschnittstelle mit einer Anzeige 34 auf, die einen berührungsempfindlichen Anzeigebildschirm in Verbindung mit einem Tablettstift 33 verwendet. Der Tablettstift 33 wird verwendet, um die Anzeige 34 an benannten Koordinaten zu drücken oder zu berühren, um ein Feld auszuwählen, um eine Anfangsposition eines Cursors gezielt zu bewegen oder um anderweitig Befehlsinformationen bereitzustellen, wie zum Beispiel durch Befehlszeichen (Gesture) oder durch Handschrift. Alternativ dazu oder zusätzlich kann die Vorrichtung 30 eine Taste oder mehrere Tasten 35 für Navigation umfassen. Es ist jedoch zu beachten, dass die Erfindung durch diese Formen von Eingabemechanismen nicht eingeschränkt werden soll. Zum Beispiel können andere Formen der Eingabe unter anderem visuelle Eingabe, wie zum Beispiel durch Computersehen, umfassen.
Unter Bezugnahme auf 2 veranschaulicht ein Blockschema Funktionskomponenten, die die Mobilvorrichtung 30 umfassen. Eine Zentraleinheit (CPU) 50 implementiert die Programmsteuerfunktionen. Die Zentraleinheit (CPU) 50 ist mit der Anzeige 34 gekoppelt, so dass Text und Grafiksymbole, die entsprechend dem Steuerprogramm erzeugt werden, auf der Anzeige 34 erscheinen. Ein Lautsprecher 43 kann mit der Zentraleinheit (CPU) 50 gekoppelt werden, üblicherweise über einen Digital-Analog-Wandler 59, um einen hörbaren Ausgang bereitzustellen. Daten, die heruntergeladen werden oder die von dem Benutzer in die Mobilvorrichtung 30 eingegeben werden, werden in einem nichtflüchtigen Lese-/Schreib-Direktzugriffsspeicher (RAM) 54 gespeichert, der bidirektional mit der Zentraleinheit 50 gekoppelt ist. Der Direktzugriffsspeicher (RAM) 54 stellt flüchtige Speicherung für Befehle bereit, die von der Zentraleinheit (CPU) 50 ausgeführt werden, sowie Speicherung für temporäre Daten, wie zum Beispiel Registerwerte. Standardeinstellungswerte für Konfigurationsoptionen und andere Variablen werden in einem Nur-Lese-Speicher (ROM) 58 gespeichert. Der Nur-Lese-Speicher (ROM) 58 kann auch verwendet werden, um das Betriebssystemprogramm für die Vorrichtung, das die Grundfunktionalität des Mobilvorrichtung 30 und andere Betriebssystem-Kernfunktionen (zum Beispiel das Laden von Programmkomponenten in den Direktzugriffsspeicher (RAM) 54) steuert, zu speichern.
Der Direktzugriffsspeicher (RAM) 54 dient weiterhin als Speicher zur analogen Speicherung für den Code für die Funktion eines Laufwerkes auf einem PC, der zur Speicherung von Anwendungsprogrammen verwendet wird. Es ist zu beachten, dass, wenngleich ein nichtflüchtiger Speicher zum Speichern des Codes verwendet wird, die Speicherung alternativ dazu in einem flüchtigen Speicher erfolgen kann, der nicht für die Ausführung des Codes verwendet wird.
Drahtlose Signale können durch die Mobilvorrichtung über ein drahtloses Sende-/Empfangs-Gerät 52, das mit der Zentraleinheit (CPU) 50 gekoppelt ist, gesendet/empfangen werden. Eine wahlweise Kommunikationsschnittstelle 60 kann ebenfalls für das Herunterladen von Daten direkt von einem Computer (zum Beispiel von einem Tischcomputer) oder aus einem Drahtnetzwerk bereitgestellt werden, falls dies gewünscht wird. Desmentsprechend kann die Schnittstelle 60 verschiedene Formen von Kommunikationsvorrichtungen umfassen, wie zum Beispiel eine Infrarotverbindung, ein Modem, eine Netzwerkkarte oder ähnliches.
Die Mobilvorrichtung 30 umfasst ein Mikrofon 29 und einen Analog-Digital-Wandler (A/D-Wandler) 37 und ein wahlweises Erkennungsprogramm (Sprache, Dual Tone Multiple Frequency (DTMF), Handschrift, Befehlszeichen (Gesture) oder Computersehen), das in dem Speicher 54 gespeichert ist. Beispielhaft stellt das Mikrofon 29 als Antwort auf hörbare Informationen, Befehle oder Anweisungen von einem Benutzer der Vorrichtung 30 Sprachsignale bereit, die durch einen Analog/Digital-Wandler (A/D-Wandler) 37 digitalisiert werden. Das Spracherkennungsprogramm kann Normalisierung und/oder Merkmalsextraktionsfunktionen an den digitalisierten Sprachsignalen durchführen, um Zwischen-Spracherkennungsergebnisse zu erhalten. Unter Verwendung des drahtlosen Sende-/Empfangs-Gerätes 52 oder der Kommunikationsschnittstelle 60 werden Sprachdaten an einen entfernten Erkennungsserver 204 gesendet, der weiter unten diskutiert und in der Architektur von 5 veranschaulicht wird. Erkennungsergebnisse werden danach an die Mobilvorrichtung 30 zurückgegeben, zwecks Rendern an denselben (zum Beispiel visuell und/oder hörbar) und schließlich zwecks Senden an einen Webserver 202 (5), wobei der Webserver 202 und die Mobilvorrichtung 30 in einer Client-Server-Beziehung arbeiten. Ähnliche Verarbeitung kann für andere Formen von Eingabe verwendet werden. Zum Beispiel kann Handschrift-Eingabe mit und ohne Verarbeitung an der Vorrichtung 30 digitalisiert werden. Wie bei den Sprachdaten auch, kann diese Form der Eingabe zwecks Erkennung an den Erkennungsserver 204 gesendet werden, wobei die Erkennungsergebnisse an wenigstens entweder die Vorrichtung 30 und/oder an den Webserver 202 zurückgegeben werden. Auf ähnliche Weise können DTMF-Daten, Befehlszeichendaten (Gesturedaten) und visuelle Daten verarbeitet werden. In Abhängigkeit von der Eingabeform umfasst die Vorrichtung 30 (sowie die anderen unten diskutierten Formen von Clients) die notwendige Vorrichtungstechnik, wie zum Beispiel eine Kamera, für visuelle Eingabe.
3 ist eine Draufsicht eines beispielhaften Ausführungsbeispieles eines Mobiltelefons 80. Das Telefon 80 umfasst eine Anzeige 82 und ein Tastenfeld 84. Im Allgemeinen gilt das Blockschema aus 2 für das Telefon aus 3, wenngleich zusätzliche Schaltungen erforderlich sein können, um andere Funktionen ausführen zu können. Zum Beispiel wird ein Sende-/Empfangs-Gerät, das als Telefon arbeiten muss, für das Ausführungsbeispiel aus 2 erforderlich sein; jedoch ist eine solche Schaltung für die hier vorliegende Erfindung nicht sachdienlich.
Es ist zu beachten, dass die hier vorliegende Erfindung zusätzlich zu den oben beschriebenen tragbaren oder mobilen Computervorrichtungen mit zahlreichen anderen Computervorrichtungen, wie zum Beispiel mit einem Allzweck-Tischrechner, verwendet werden kann. Zum Beispiel wird es die hier vorliegende Erfindung einem Benutzer mit begrenzten körperlichen Fähigkeiten ermöglichen, Text in einen Computer oder in eine andere Computervorrichtung einzugeben, wenn andere herkömmliche Eingabevorrichtungen, wie zum Beispiel eine vollwertige alphanumerische Tastatur, zu schwierig zu bedienen sind.
Die Erfindung ist weiterhin mit zahlreichen anderen Allzweck- oder Spezialrechensystemen, Umgebungen oder Konfigurationen betriebsfähig. Beispiele hinlänglich bekannter Computersysteme, Umgebungen und/oder Konfigurationen sind unter anderem reguläre Telefone (ohne jeglichen Bildschirm), Personalcomputer, Servercomputer, Handheld-Computer oder Laptops, Multiprozessorsysteme, mikroprozessorbasierte Systeme, Satellitenempfänger (Set-Top-Boxen), programmierbare Unterhaltungselektronik, Netzwerk-PCs, Minirechner, Großrechner (Mainframes), verteilte Rechenumgebungen, die beliebige der oben genannten Systeme oder Vorrichtungen beinhalten, und ähnliches.
Es folgt eine kurze Beschreibung eines in 4 veranschaulichten Allzweckcomputers 120. Der Computer 120 ist jedoch lediglich ein Beispiel einer geeigneten Rechenumgebung und soll den Umfang der Verwendungsmöglichkeiten und der Funktionalität der Erfindung nicht einschränken. Ebenso soll der Computer 120 nicht als von einer der darin veranschaulichten Komponenten oder von einer Kombination von Komponenten abhängig angesehen werden.
Die Erfindung kann in dem allgemeinen Kontext von computerausführbaren Befehlen oder Anweisungen, wie zum Beispiel von Programmmodulen, die von einem Computer ausgeführt werden, beschrieben werden. Im Allgemeinen umfassen Programmmodule Dienstprogramme oder Routinen, Programme, Objekte, Komponenten, Datenstrukturen etc., die bestimmte Aufgaben ausführen oder die bestimmte abstrakte Datentypen implementieren. Die Erfindung kann weiterhin in verteilten Rechenumgebungen ausgeführt werden, wobei Aufgaben von entfernten Verarbeitungsvorrichtungen ausgeführt werden, die über ein Kommunikationsnetzwerk verbunden sind. In einer verteilten Rechenumgebung können Programmmodule sowohl in lokalen als auch in entfernten Computerspeichermedien, einschließlich in Speichervorrichtungen, vorliegen. Von den Programmen und Modulen ausgeführte Aufgaben werden unten anhand der Figuren beschrieben werden. Der Durchschnittsfachmann kann die Beschreibung und die Figuren als prozessorausführbare Befehle oder Anweisungen implementieren, die auf eine beliebige Form von computerlesbarem Medium geschrieben werden können.
Unter Bezugnahme auf 4 können Komponenten des Computers 120 unter anderem eine Verarbeitungseinheit 140, einen Systemspeicher 150 und einen Systembus 141 umfassen, welcher verschiedene Systemkomponenten, einschließlich des Systemspeichers, mit der Verarbeitungseinheit 140 koppelt. Der Systembus 141 kann eine von mehreren Busstrukturen aufweisen, einschließlich ein Speicherbus oder eine Speicher-Steuereinheit, ein Peripheriebus und ein lokaler Bus unter Verwendung einer Vielzahl von Busarchitekturen. Beispielhaft und nicht einschränkend umfassen die genannten Architekturen den ISA-Bus (Industry Standard Architecture), den universalen seriellen Bus (USB), den MCA-Bus (Micro Channel Architecture), den EISA-Bus (Enhanced ISA), den lokalen VESA-Bus (Video Electronics Standards Association) und den PCI-Bus (Peripheral Component Interconnect), der auch als Mezzanin-Bus bezeichnet wird. Der Computer 120 umfasst üblicherweise eine Vielzahl von computerlesbaren Spei chermedien. Computerlesbare Medien können beliebige verfügbare Speichermedien sein, auf die der Computer 120 zugreifen kann, und umfassen sowohl flüchtige als auch nichtflüchtige Speichermedien, entfernbare und nicht entfernbare Speichermedien. Beispielhaft und nicht einschränkend können computerlesbare Medien Speichermedien und Kommunikationsmedien umfassen. Computer-Speichermedien umfassen sowohl flüchtige als auch nichtflüchtige, entfernbare und nicht entfernbare Speichermedien, die durch beliebige Verfahren oder Technologien zum Speichern von Informationen implementiert werden, wie zum Beispiel computerlesbare Befehle oder Anweisungen, Datenstrukturen, Programmmodule und andere Daten. Computerspeichermedien sind unter anderem ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein EEPROM, ein Flash-Speicher oder eine andere Speichertechnologie, eine CD-ROM, eine Digital Versatile Disc (DVD) oder eine optische Speicherplatte, Magnetkassetten, Magnetbänder, magnetische Speicherplatten oder andere Magnetspeichervorrichtungen, oder beliebige andere Speichermedien, die verwendet werden können, um die gewünschten Informationen zu speichern, und auf die der Computer 120 zugreifen kann.
Kommunikationsmedien enthalten üblicherweise computerlesbare Befehle oder Anweisungen, Datenstrukturen, Programmmodule oder andere Daten in einem modulierten Datensignal, wie zum Beispiel einer Trägerwelle oder einem anderen Transportmechanismus, und umfassen beliebige Informationsübergabemedien. Der Ausdruck „moduliertes Datensignal" bedeutet ein Signal, bei dem ein Merkmal oder mehrere Merkmale so verändert ist oder sind, dass in dem Signal Informationen verschlüsselt werden. Beispielhaft und nicht einschränkend umfassen Kommunikationsmedien verdrahtete Medien, wie zum Beispiel ein verdrahtetes Netzwerk oder eine direktverdrahtete Verbindung, und drahtlose Medien, wie zum Beispiel akustische Medien, FR, Infrarotmedien oder andere drahtlose Medien. Kombinationen der oben genannten fallen ebenfalls in den Bereich der computerlesbaren Speichermedien.
Der Systemspeicher 150 umfasst Computerspeichermedien in der Form flüchtiger und/oder nichtflüchtiger Speicher, wie zum Beispiel Nur-Lese-Speicher (ROM) 151 und Direktzugriffsspeicher (RAM) 152. Ein Basic Input-Output System (BIOS) 153, das die grundlegenden Routinen enthält, die den Informationsaustausch zwischen Elementen in dem Computer 120 unterstützen, wie zum Beispiel während des Hochfahrens, ist üblicherweise in dem Nur-Lese-Speicher (ROM) 151 gespeichert. Der Direktzugriffs speicher (RAM) 152 enthält typischerweise Daten und/oder Programmmodule, die unmittelbar zugänglich sind und/oder die von der Verarbeitungseinheit 140 bearbeitet werden. Beispielhaft und nicht einschränkend veranschaulicht 4 ein Betriebssystem 54, Anwendungsprogramme 155, andere Programmmodule 156 und Programmdaten 157.
Der Computer 120 kann weiterhin andere entfernbare/nichtentfernbare flüchtige/nichtflüchtige Computerspeichermedien umfassen. Ausschließlich beispielhaft veranschaulicht 4 ein Festplattenlaufwerk 161, das von oder auf nichtentfernbare(n), nichtflüchtige(n) Magnetmedien liest und schreibt, ein Magnetplattenlaufwerk 171, das von oder auf eine entfernbare, nichtflüchtige Magnetspeicherplatte 172 liest und schreibt, und ein optisches Plattenlaufwerk 175, das von oder auf eine entfernbare, nichtflüchtige optische Speicherplatte 176, wie zum Beispiel eine CD-ROM oder andere optische Speichermedien, liest oder schreibt. Andere entfernbare/nichtentfernbare, flüchtige/nichtflüchtige Computerspeichermedien, die in der beispielhaften Betriebsumgebung verwendet werden können, sind unter anderem Magnetbandkassetten, Flash-Speicherkarten, Digital Versatile Discs, digitale Videobänder, Festkörper(RAM), Festkörper-Nur-Lese-Speicher (ROM) und ähnliche. Das Festplattenlaufwerk 161 ist üblicherweise über eine nichtentfernbare Speicher-Schnittstelle, wie zum Beispiel die Schnittstelle 160, mit dem Systembus 141 verbunden, und das Magnetplattenlaufwerk 171 und das optische Plattenlaufwerk 175 sind üblicherweise durch eine Speicher-Schnittstelle, wie zum Beispiel die Schnittstelle 170, mit dem Systembus 141 verbunden.
Die Laufwerke und ihre zugehörigen Computerspeichermedien, die oben diskutiert und in 4 veranschaulicht werden, stellen Speicherung von computerlesbaren Befehlen und Anweisungen, Datenstrukturen, Programmmodulen und anderen Daten für den Computer 120 bereit. In 4 zum Beispiel wird das Festplattenlaufwerk 161 als das Betriebssystem 164, Anwendungsprogramme 165, andere Programmmodule 166 und Programmdaten 167 speichernd dargestellt. Es ist zu beachten, dass diese Komponenten die gleichen wie das Betriebssystem 154, die Anwendungsprogramme 155, die anderen Programmmodule 156 und Programmdaten 157 sein können oder aber dass sie sich von diesen unterscheiden können. Das Betriebssystem 164, die Anwendungsprogramme 165, die anderen Programmmodule 166 und Programmdaten 167 erhalten hier unterschiedliche Verweisziffern, um damit zu veranschaulichen, dass es sich um unterschiedliche Exemplare handelt.
Ein Benutzer kann Befehle und Informationen über Eingabevorrichtungen, wie zum Beispiel eine Tastatur 182, ein Mikrofon 183, und ein Zeigegerät 181, wie zum Beispiel eine Maus, einen Trackball oder ein Touch-Pad, in den Computer 120 eingeben. Andere Eingabevorrichtungen (nicht gezeigt) sind unter anderem ein Joystick, ein Gamepad, eine Satellitenschüssel, ein Scanner oder ähnliches. Diese und andere Eingabevorrichtungen sind oft über eine Benutzer-Schnittstelle 180, die mit dem Systembus gekoppelt ist, mit der Verarbeitungseinheit 140 verbunden, können jedoch auch über andere Schnittstellen und Busstrukturen, wie zum Beispiel eine parallele Schnittstelle, einen Gameport oder einen universellen seriellen Bus (USB) verbunden sein. Ein Monitor 184 oder eine andere Art von Anzeigevorrichtung ist ebenfalls über eine Schnittstelle, wie zum Beispiel eine Videoschnittstelle 185, mit dem Systembus 141 verbunden. Zusätzlich zu dem Monitor können Computer andere periphere Ausgabevorrichtungen, wie zum Beispiel Lautsprecher 187 und Drucker 186 umfassen, die über eine periphere Ausgabe-Schnittstelle 188 verbunden sein können.
Der Computer 120 kann in einer vernetzten Umgebung arbeiten und logische Verbindungen zu einem oder mehreren entfernten Computer oder Computern, wie zum Beispiel dem entfernten Computer 194, nutzen. Der entfernte Computer 194 kann ein Personalcomputer, ein Handheld-Gerät, ein Server, ein Router, ein Netzwerk-PC, ein Peergerät oder ein anderer gemeinsamer Netzwerkknoten sein und umfasst üblicherweise zahlreiche oder alle der in Bezug auf den Computer 120 oben beschriebenen Elemente. Die in 4 dargestellten logischen Verbindungen umfassen ein lokales Netzwerk (LAN) 191 und ein Fernnetzwerk (WAN) 193, können jedoch auch andere Netzwerke umfassen. Solche Netzwerkumgebungen werden in Büros, in unternehmenseigenen Computernetzwerken, in Intranets und in dem Internet weit verbreitet verwendet.
Bei Verwendung in einer LAN-Netzwerkumgebung ist der Computer 120 über eine Netzwerk-Schnittstelle oder einen Adapter 190 mit dem lokalen Netzwerk (LAN) 191 verbunden. Bei Verwendung in einer Fernnetzwerkumgebung (WAN-Netzwerkumgebung) umfasst der Computer 120 üblicherweise ein Modem 192 oder andere Vorrichtungen zum Einrichten von Kommunikation über das Fernnetzwerk (WAN) 193, wie zum Beispiel das Internet. Das Modem 192, welches ein internes oder externes sein kann, kann über die Benutzer-Schnittstelle 180 oder über andere geeignete Mechanismen mit dem Systembus 141 verbunden werden. In einer vernetzten Umgebung können in Bezug auf den Computer 120 oder Teile desselben dargestellte Programmmodule in der Fernspeichervorrichtung gespeichert werden. Beispielhaft und nicht einschränkend veranschaulicht 4 die Anwendungsprogramme 195 als an dem entfernten Computer 194 residierend. Es wird erkennbar sein, dass die gezeigten Netzwerkverbindungen beispielhaft sind und dass andere Vorrichtungen zum Einrichten von Kommunikationsverbindungen zwischen den Computern verwendet werden können.
5 veranschaulicht eine Architektur 200 für webbasierte Erkennung, wie sie in die vorliegende Erfindung eingebaut werden kann. Im Allgemeinen kann auf in einem Webserver 202 gespeicherte Informationen über eine Mobilvorrichtung 30 (die in dieser Schrift gleichzeitig andere Formen von Rechenvorrichtungen, die einen Anzeigebildschirm, ein Mikrofon, eine Kamera, einen berührungsempfindlichen Bildschirm etc. nach Erfordernis ausgehend von der Eingabeform aufweisen, darstellt) oder über ein Telefon 80 zugegriffen werden, wobei Informationen hörbar oder durch durch das Telefon 80 als Antwort auf gedrückte Tasten erzeugte Töne angefordert werden und wobei Informationen von dem Webserver 202 ausschließlich hörbar an den Benutzer zurückgegeben werden.
Wichtiger ist jedoch, dass die Architektur 200 dahingehend vereinheitlicht ist, dass unabhängig davon, ob Informationen über die Vorrichtung 30 oder über das Telefon 80 unter Verwendung von Spracherkennung erfasst werden, ein einzelner Erkennungsserver 204 beide Betriebsarten unterstützen kann. Zusätzlich arbeitet die Architektur 200 unter Verwendung einer Erweiterung einer hinlänglich bekannten Auszeichnungssprache (zum Beispiel HTML, XHTML, cHTML, XML, WML oder ähnliche). Somit kann auf auf dem Webserver 202 gespeicherte Informationen auch unter Nutzung des hinlänglich bekannten GUI-Verfahrens, das in diesen Auszeichnungssprachen vorgefunden wird, zugegriffen werden. Unter Verwendung der hinlänglich bekannten Auszeichnungssprachen wird das Authoring auf dem Webserver 202 leichter und gegenwärtig vorhandene Altanwendungen können ebenfalls problemlos verändert werden, um Spracherkennung einzuschließen.
Im Allgemeinen führt die Vorrichtung 30 HTML-Seiten, Scripts oder ähnliches aus, die von dem Webserver 202 bereitgestellt werden. Wenn beispielhaft Spracherkennung gefordert ist, können Sprachdaten, welche digitalisierte Audiosignale oder Sprachmerkmale sein können, wobei die Audiosignale wie oben diskutiert durch die Vorrichtung 30 vorverarbeitet worden sind, an den Erkennungsserver 204 mit einer Anzeige von Grammatik oder Sprachmodell, das während der Spracherkennung zu verwenden ist, übergeben werden. Die Implementierung des Erkennungsservers 204 kann zahlreiche Formen annehmen, von denen eine veranschaulicht wird, umfasst jedoch im Allgemeinen eine Erkennungsvorrichtung 211. Die Erkennungsergebnisse werden zwecks lokalem Rendering an die Vorrichtung 30 zurückgegeben, falls dies erwünscht oder angemessen ist. Beim Kompilieren der Informationen durch Erkennung und gegebenenfalls durch eine verwendete grafische Benutzerschnittstelle sendet die Vorrichtung 30 die Informationen zwecks Weiterverarbeitung und gegebenenfalls Empfang weiterer HTML-Seiten/Scripts an den Webserver 202.
Wie in 5 veranschaulicht wird, sind die Vorrichtung 30, der Webserver 202 und der Erkennungsserver 204 über das Netzwerk 205, in diesem Fall ein Fernnetzwerk, wie zum Beispiel das Internet, gemeinsam verbunden und separat adressierbar. Daher ist es nicht notwendig, dass eine dieser Vorrichtungen physisch neben einer anderen angeordnet ist. Insbesondere ist es nicht notwendig, dass der Webserver 202 den Erkennungsserver 204 mit einschließt. Auf diese Weise kann das Authoring an dem Webserver 202 auf die Anwendung konzentriert werden, für die es vorgesehen ist, ohne dass die Autoren die Feinheiten des Erkennungsservers 204 kennen müssen. Vielmehr kann der Erkennungsserver 204 unabhängig ausgelegt und mit dem Netzwerk 205 verbunden werden und dadurch aktualisiert und verbessert werden, ohne dass weitergehende Veränderungen an dem Webserver 202 erforderlich sind. Wie weiter unten beschrieben werden wird, kann der Webserver 202 weiterhin einen Authoring-Mechanismus umfassen, der dynamisch clientseitige Auszeichnungssprachen und Scripts erzeugen kann. In einem weiteren Ausführungsbeispiel können der Webserver 202, der Erkennungsserver 204 und der Client 30 in Abhängigkeit von den Fähigkeiten der implementierenden Vorrichtungen kombiniert werden. Wenn zum Beispiel der Client einen Allzweckcomputer umfasst, wie zum Beispiel einen Personalcomputer, kann der Client den Erkennungsserver 204 umfassen. Falls dies erwünscht ist, können der Web server 202 und der Erkennungsserver 204 analog dazu in eine einzelne Vorrichtung integriert werden.
In Bezug auf das Client-Vorrichtung umfasst ein Verfahren für Verarbeiten von Eingabedaten in einem Client-Server-System das Empfangen einer Auszeichnungssprachenseite mit Erweiterungen, die konfiguriert sind, um Eingabedaten von einem Benutzer einer Client-Vorrichtung zu erfassen; Ausführen der Auszeichnungssprachenseite auf der Client-Vorrichtung; Senden der Eingabedaten (die von dem Benutzer erfasste Sprache, DTMF, Handschrift, Befehlszeichen (Gesture) oder Bilder anzeigen) und einer zugehörigen Grammatik an einen von dem Client entfernten Erkennungsserver; und Empfangen eines Erkennungsergebnisses von dem Erkennungsserver an dem Client. Ein computerlesbares Speichermedium kann bereitgestellt werden, das eine Auszeichnungssprache zum Ausführen auf einer Client-Vorrichtung in einem Client-Server-System aufweist, wobei die Auszeichnungssprache einen Befehl aufweist, der eine Grammatik anzeigt, die mit den über die Client-Vorrichtung eingegebenen Daten zu verknüpfen ist.
Der Zugriff auf den Webserver 202 über das Telefon 80 umfasst das Verbinden des Telefons 80 mit einem verdrahteten oder einem drahtlosen Telefonnetz 208, das wiederum das Telefon 80 mit einem Dritt-Gateway 210 verbindet. Der Gateway 210 verbindet das Telefon 80 mit einem Telephonie-Sprachbrowser 212. Der Telephonie-Sprachbrowser 212 umfasst einen Medienserver 214, der eine Telephonie-Schnittstelle und einen Sprachbrowser 216 bereitstellt. Wie die Vorrichtung 30, empfängt auch der Telephonie-Sprachbrowser 212 HTML-Seiten/Scripts oder ähnliches von dem Webserver 202. Insbesondere sind die HTML-Seiten/Scripts von ähnlicher Form, wie die an die Vorrichtung 30 übergebenen HTML-Seiten/Scripts. Auf diese Weise muss der Webserver 202 die Vorrichtung 30 und das Telefon 80 nicht getrennt unterstützen oder nicht einmal Standard-GUI-Clients separat unterstützen. Vielmehr kann eine gemeinsame Auszeichnungssprache verwendet werden. Zusätzlich wird, wie bei der Vorrichtung 30, Spracherkennung von hörbaren Signalen, die von dem Telefon 80 übertragen werden, von dem Sprachbrowser 216 an den Erkennungsserver 204 bereitgestellt, entweder über das Netzwerk 205 oder über die Standleitung 207, zum Beispiel unter Verwendung von TCP/IP. Der Webserver 202, der Erkennungsserver 204 und der Telephonie- Sprachbrowser 212 können in einer beliebigen geeigneten Rechenumgebung, wie zum Beispiel dem in 4 veranschaulichten Allzweck-Tischrechner, ausgeführt werden.
Es ist jedoch zu beachten, dass wenn DTMF-Erkennung genutzt wird, diese Form der Erkennung im Allgemeinen an dem Medienserver 214 durchgeführt wird, nicht jedoch an dem Erkennungsserver 204. Mit anderen Worten wird die DTMF-Grammatik von dem Medienserver angewendet.
Wie weiter oben angedeutet worden ist, können Auszeichnungssprachen, wie zum Beispiel HTML, XHTML, HTML, XML, WML oder beliebige andere SGML-abgeleitete Auszeichnungssprachen, Steuerungen und/oder Objekte beinhalten, die Erkennung in einer Client-Server-Architektur bereitstellen. Auf diese Weise können Autoren alle Tools und alles in diesen Auszeichnungssprachen, die die in solchen Architekturen genutzte dominante Web-Entwicklungsplattform sind, enthaltene Wissen ausnutzen.
Im Allgemeinen können Steuerungen und/oder Objekte eine oder mehrere der folgenden Funktionen umfassen: Erkennungsvorrichtungs-Steuerungen und/oder Objekte für die Erkennungsvorrichtungs-Konfiguration, Erkennungsvorrichtungs-Ausführung und/oder Nachverarbeitung; Synthesizersteuerungen und/oder Objekte für Synthesizerkonfiguration und Wiedergabe von Eingabeaufforderungen; Grammatiksteuerungen und/oder Objekte zum Spezifizieren von Eingabegrammatik-Ressourcen; und/oder Belegungssteuerungen und/oder Objekte zum Verarbeiten von Erkennungsergebnissen. Die Erweiterungen sind als leichte Auszeichnungssprache-Schicht ausgelegt, die die Leistung einer hörbaren, visuellen, Handschrift-Schnittstelle etc. zu vorhandenen Auszeichnungssprachen hinzufügt. Als solches können die Erweiterungen unabhängig bleiben von: der höheren Seite, in der sie enthalten sind, wie zum Beispiel HTML; den niederen Formaten, die die Erweiterungen nutzen, um Verweise auf linguistische Ressourcen zu geben, wie zum Beispiel den Text-zu-Sprache- und den Grammatik-Formaten; und den einzelnen Eigenschaften der in dem Erkennungsserver 204 verwendeten Erkennungs- und Sprachsynthese-Plattformen.
Bevor die Auszeichnungssprachen mit Steuerungen und/oder Objekten beschrieben werden, die für Erkennung geeignet sind, kann es zweckdienlich sein, ein einfaches Beispiel einer grafischen Benutzerschnittstelle (GUI) zu betrachten, das in die HTML-Auszeichnungssprache eingebettet ist. Unter Bezugnahme auf 6 umfasst eine einfache grafische Benutzerschnittstelle (GUI) die Eingabe von Kreditkarteninformationen in einen Webserver zum Abschließen eines Online-Kaufvorganges. In diesem Beispiel umfassen die Kreditkarteninformationen ein Feld 250 zur Eingabe der Art der Kreditkarte, die verwendet wird, wie zum Beispiel Visa, MasterCard oder American Express. Ein zweites Feld 252 ermöglicht die Eingabe der Kreditkartennummer, während ein drittes Feld 254 die Eingabe des Ablaufdatums der Gültigkeit der Kreditkarte ermöglicht. Die Sendeübergabe-Taste (Submit-Taste) ermöglicht das Senden der in den Feldern 250, 252 und 254 eingegebenen Informationen.
7 veranschaulicht den HTML-Code zum Erfassen der vorgenannten Kreditkarteninformationen von dem Client. Im Allgemeinen, und dies haben die genannten Arten von Auszeichnungssprachen gemeinsam, umfasst der Code einen Körperabschnitt 260 und einen Scriptabschnitt 262. Der Körperabschnitt 260 umfasst Codezeilen, die die Art der auszuführenden Aktion, die Art der Nutzung, die verschiedenen Informationsfelder 250, 252 und 254 sowie einen Code für die Sendeübergabe-Taste (Submit-Taste) 264 (6) andeuten. Dieses Beispiel veranschaulicht weiterhin Eventing-Unterstützung und eingebettetes Scripthosting, wobei bei Betätigung der Submit-Taste 264 eine Funktion „Überprüfen" in dem Scriptabschnitt aufgerufen oder ausgeführt wird. Die Funktion „Überprüfen" bestätigt, ob die Länge der Kartennummer für eine jede Kreditkarte (Visa, MasterCard und American Express) die richtige Länge ist.
8 veranschaulicht eine Client-Auszeichnungssprache, die die gleiche grafische Benutzerschnittstelle (GUI) aus 6 erzeugt, um Kreditkarteninformationen zu erfassen, die unter Verwendung von Sprecherkennung an den Webserver 204 zu übergeben sind. Wenngleich unten unter Bezugnahme auf die 8 bis 14 Sprecherkennung diskutiert werden wird, ist zu beachten, dass die beschriebenen Verfahren analog in Handschrifterkennung, Gestureerkennung und Bilderkennung angewendet werden können.
Im Allgemeinen sind die Erweiterungen (die häufig auch als „Auszeichnungssprachen" bezeichnet werden) eine kleine Menge von XML-Elementen mit zugehörigen Attributen und DOM-Objekteigenschaften, Ereignissen und Methoden, die in Verbindung mit einem Quellenauszeichnungssprachendokument verwendet werden kann, um eine Erkennungs-Schnittstelle anzuwenden, mit DTMF oder mit Anrufsteuerung auf eine Quellenseite. Die Erweiterungsformalitäten und die Semantik sind abhängig von der Art des Quellendokuments, so dass die Erweiterungen gleichermaßen wirksam in HTML, XHTML, cHTML, XML, WML oder mit beliebigen anderen SGML-abgeleiteten Auszeichnungssprachen verwendet werden können. Die Erweiterung folgt dem Dokumentobjektmodell, wobei neue funktionale Objekte oder Elemente, die hierarchisch sein können, bereitgestellt werden. Ein jedes der Elemente wird in dem Anhang ausführlich diskutiert werden, jedoch können die Elemente im Allgemeinen Attribute, Eigenschaften, Methoden, Ereignisse und/oder andere Child-Objekte umfassen.
An dieser Stelle ist zu beachten, dass die Erweiterungen in zwei verschiedenen „Modi" entsprechend den Fähigkeiten der Vorrichtung, auf der der Browser ausgeführt wird, interpretiert werden können. In dem ersten Modus, dem „Objektmodus", stehen die vollständigen Fähigkeiten zur Verfügung. Die programmatische Manipulierung der Erweiterungen wird durch beliebige Mechanismen durchgeführt, die von dem Browser auf der Vorrichtung freigegeben werden, wie zum Beispiel ein JScript-Interpreter in einem XHTML-Browser oder ein WMLScript-Interpreter in einem WML-Browser. Aus diesem Grund muss lediglich eine kleine Menge von Kerneigenschaften und Kernmethoden der Erweiterungen definiert und dieselben durch beliebige auf der Vorrichtung oder auf der Clientseite vorhandenen programmatischen Mechanismen manipuliert werden. Der Objektmodus stellt Eventing und Scripting bereit und kann eine größere Funktionalität anbieten, um dem Dialogautor eine feinere Kontrolle über Sprachwechselwirkungen zu ermöglichen. Bei Verwendung in dieser Schrift wird ein Browser, der vollständiges Eventing und Scripting unterstützt, auch als „höherer Browser" bezeichnet. Diese Form eines Browsers wird alle Attribute, Eigenschaften, Methoden und Ereignisse der Erweiterungen unterstützen. Höhere Browser weisen häufig größere Verarbeitungsfähigkeiten auf.
Die Erweiterungen können auch in einem „deklarativen Modus" unterstützt werden. Bei Verwendung in dieser Schrift wird ein in einem deklarativen Modus arbeitender Browser als „niederer Browser" bezeichnet und unterstützt keine vollständigen Eventing- und Scripting-Fähigkeiten. Vielmehr wird diese Form eines Browsers die deklarativen Aspekte einer gegebenen Erweiterung (das heißt das Kernelement und die Kernattribute) unterstützen, jedoch nicht alle DOM-Objekteigenschaften (DOM = Dokumentobjekt modell), Methoden und Ereignisse. Dieser Modus verwendet ausschließlich deklarative Syntax und kann weiterhin in Verbindung mit deklarativer Multimediasynchronisation und Koordinationsmechanismen (synchronisierte Auszeichnungssprache), wie zum Beispiel SMIL (Synchronized Multimedia Integration Language) 2.0., verwendet werden. Niedere Browser werden üblicherweise auf Vorrichtungen mit begrenzten Verarbeitungsfähigkeiten anzutreffen sein.
An diesem Punkt muss jedoch ein besonderer Eingabemodus diskutiert werden. Als besonders nützlich erweist sich die Anwendung von Spracherkennung in Verbindung mit wenigstens einer Anzeige und, in einem weiteren Ausführungsbeispiel, weiterhin mit einem Zeigevorrichtung zur Anzeige der Felder für Dateneingabe. Bei diesem Modus der Dateneingabe wird der Benutzer im Allgemeinen dahingehend gesteuert, wann ein Feld auszuwählen ist, um entsprechende Informationen bereitzustellen. In dem Beispiel aus 6 kann der Benutzer zum Beispiel zuerst entscheiden, die Kreditkartennummer in dem Feld 252 einzugeben und danach die Art der Kreditkarte in dem Feld 250 einzugeben, gefolgt von dem Ablaufdatum der Gültigkeit in dem Feld 254. Analog dazu kann der Benutzer zu dem Feld 252 zurückgehen und dort eine fehlerhafte Eingabe korrigieren, fass dies gewünscht wird. Bei einer Kombination mit Spracherkennung wie unten beschrieben wird eine leichte und natürliche Art der Navigation bereitgestellt. Bei Verwendung in dieser Schrift wird diese Form der Eingabe, die sowohl eine Bildschirmanzeige, die eine freie Auswahl von Feldern ermöglicht, und Spracherkennung verwendet, als „multimodal" bezeichnet.
Unter erneuter Bezugnahme auf 8 wird der HTML-Auszeichnungssprachensprachen-Code veranschaulicht. Wie auch der in 7 veranschaulichte HTML-Code, umfasst auch dieser Code einen Körperabschnitt 270 und einen Scriptabschnitt 272. Ebenfalls wie auch der in 7 veranschaulichte Code, umfasst der in 8 veranschaulichte Code Anzeigen der Art der durchzuführenden Aktion und der Stelle des Formulars. Die Eingabe von Informationen in den einzelnen Feldern 250, 252 und 254 wird durch die Codeabschnitte 280, 282 beziehungsweise 284 gesteuert oder ausgeführt. Unter Bezugnahme auf den Codeabschnitt 280 wird zum Beispiel die Auswahl des Feldes 250 durch Verwendung eines Tablettstiftes 33 der Vorrichtung 30 eingeleitet, das Ereignis „onClick" wird eingeleitet, welches die Funktion „talk" in dem Scriptabschnitt 272 aufruft oder ausführt. Dies aktiviert eine Grammatik, die für Spracherkennung genutzt wird, die zu der Art der Daten, die im Allgemeinen in dem Feld 250 erwartet werden, zugehörig ist. Diese Art der Wechselwirkung, die mehr als ein Eingabeverfahren umfasst (zum Beispiel Sprache und Stiftklick/Rolle), wird als "multimodal" bezeichnet.
Es ist zu beachten, dass die in 8 beispielhaft gezeigten Spracherkennungs-Erweiterungen auf dem Browser des Client keine vorgesehene standardmäßige visuelle Darstellung haben, da für zahlreiche Anwendungen davon ausgegangen wird, dass der Autor die Sprachfreigabe der verschiedenen Komponenten der Seite signalisieren wird, indem er anwendungsspezifische grafische Mechanismen auf der Quellenseite verwendet. Dennoch können die Erweiterungen, wenn grafische Darstellungen wünschenswert sind, entsprechend verändert werden.
Unter erneuter Bezugnahme auf die Grammatik ist die Grammatik eine syntaktische Grammatik wie zum Beispiel eine kontextfreie Grammatik, eine N-Grammatik oder eine Hybridgrammatik. (Natürlich werden DTMF-Grammatik, Handschrift-Grammatik, Gesture-Grammatik und Bild-Grammatik verwendet, wenn entsprechende Formen der Erkennung verwendet werden. Bei Verwendung in dieser Schrift umfasst der Ausdruck „Grammatik" Informationen zum Durchführen von Erkennung und, in einem weiteren Ausführungsbeispiel, Informationen entsprechend der erwarteten einzugebenden Eingabe (zum Beispiel in einem spezifischen Feld). Eine neue Steuerung 290 (in dieser Schrift als „Reco" bezeichnet", die eine erste Erweiterung der Auszeichnungssprache umfasst, beinhaltet verschiedene Elemente, von denen zwei veranschaulicht werden, das heißt ein Grammatikelement „grammar" und ein Belegungselement „bind". Im Allgemeinen, wie der von einem Webserver 202 auf einen Client heruntergeladene Code, kann die Grammatik von dem Webserver 202 stammen und auf den Client heruntergeladen und/oder zwecks Sprachverarbeitung an einen entfernten Server weitergeleitet werden. Die Grammatik kann sodann lokal auf dem Client in einem Cache-Speicher gespeichert werden. Schließlich wird die Grammatik zwecks Verwendung in der Erkennung an den Erkennungsserver 204 bereitgestellt. Das Grammatikelement wird genutzt, um die Grammatik zu spezifizieren, entweder als mitlaufende Verarbeitung oder als Verweis unter Nutzung eines Attributes.
Bei Eingang von Erkennungsergebnissen von dem Erkennungsserver 204, die der erkannten Sprache, Handschrift, den erkannten Befehlszeichen (Gesture), Bildern etc. entsprechen, wird die Syntax der Reco-Steuerung 290 bereitgestellt, um die entsprechenden Ergebnisse zu empfangen und diese dem entsprechenden Feld zuzuordnen, was Rendern des Textes in demselben in der Anzeige 34 umfassen kann. In dem veranschaulichten Ausführungsbeispiel und bei Abschluss der Spracherkennung mit dem an den Client zurückgegebenen Ergebnis wird das Reco-Objekt deaktiviert und der erkannte Text wird dem entsprechenden Feld zugeordnet. Die Abschnitte 282 und 284 arbeiten analog dazu, wobei einzigartige Reco-Objekte und Grammatik für jedes der Felder 252 und 254 aufgerufen und bei Empfang des erkannten Textes einem jeden der Felder 252 und 154 zugewiesen werden. In Bezug auf den Empfang des Kartennummer-Feldes 252 prüft die Funktion „bearbeiten" die Länge der Kartennummer in Bezug auf die Art der Kreditkarte analog dazu, wie dies oben in Bezug auf 7 beschrieben wurde.
Im Algemeinen erfolgt die Verwendung von Spracherkennung in Verbindung mit der Architektur 200 und der clientseitigen Auszeichnungssprache wie folgt: zuerst wird das der Sprache zugewiesene Feld angezeigt. In dem veranschaulichten Ausführungsbeispiel wird der Tablettstift 33 verwendet; es ist jedoch zu beachten, dass die vorliegende Erfindung nicht auf den Tablettstift 33 begrenzt ist, wobei eine beliebige Anzeigeform verwendet werden kann, wie zum Beispiel Schaltflächen, ein Mauszeiger, ein Drehrad oder ähnliches. Das entsprechende Ereignis, wie zum Beispiel ein Ereignis „onClick", kann auf hinlänglich bekannte Art und Weise und unter Verwendung von visuellen Auszeichnungssprachen bereitgestellt werden. Es ist zu beachten, dass die vorliegende Erfindung nicht auf die Verwendung eines Ereignisses „onClick" zur Anzeige des Beginns von Sprach-, Handschrift-, Gesturebefehlen etc. begrenzt ist. Alle verfügbaren GUI-Ereignisse (GUI = grafische Benutzerschnittstelle) können ebenfalls für den gleichen Zweck verwendet werden, wie zum Beispiel „onSelect". In einem Ausführungsbeispiel ist ein solches Eventing besonders zweckdienlich, da es dazu dient, den Beginn und/oder das Ende der entsprechenden Sprache anzuzeigen. Es ist zu beachten, dass das Feld, an das die Sprache gerichtet ist, von dem Benutzer angezeigt werden kann, wie auch von Programmen, die auf dem Browser laufen und die Benutzerwechselwirkungen verfolgen.
An dieser Stelle wird darauf verwiesen, dass die verschiedenen Szenarien der Spracherkennung verschiedenes Verhalten und/oder verschiedene Ausgänge aus dem Erkennungsserver 204 erfordern. Wenngleich der Beginn des Erkennungsprozesses in allen Fällen Standard ist – ein expliziter Startaufruf () von höheren Browsern oder ein deklaratives Element <reco> in niederen Browsern – können die Mittel zum Unterbrechen der Spracherkennung unterschiedlich sein.
In dem obenstehenden Beispiel wird ein Benutzer in einer multimodalen Anwendung zum Beispiel die Eingabe in die Vorrichtung steuern, indem er eine druckempfindliche Anzeige antippt und hält. Der Browser verwendet danach ein GUI-Ereignis, wie zum Beispiel „pen-up", um zu steuern, wann die Erkennung aufhören soll, und gibt danach die entsprechenden Ergebnisse zurück. In einem Nur-Sprache-Szenario, wie zum Beispiel in einer Telefonanwendung (unten diskutiert) oder in einer Freisprechanwendung, hat der Benutzer jedoch keine direkte Steuerung oder Kontrolle über den Browser, und der Erkennungsserver 204 oder der Client 30 müssen die Verantwortung dafür übernehmen, zu entscheiden, wann die Erkennung gestoppt wird und die Ergebnisse zurückgegeben werden (üblicherweise nachdem ein Pfad durch die Grammatik erkannt worden ist). Weiterhin erfordern Diktatszenarien und andere Szenarien, bei denen Zwischenergebnisse zurückgegeben werden müssen, bevor die Erkennung gestoppt wird (auch als „open microphone, offenes Mikrofon" bekannt), nicht nur eine explizite Stopp-Funktion, sondern müssen auch mehrfache Erkennungsergebnisse an den Client 30 und/oder den Webserver 202 zurückgeben, bevor der Erkennungsprozess unterbrochen wird.
In einem Ausführungsbeispiel kann das Erkennungselement (Reco) ein Attribut „Modus" aufweisen, um die folgenden drei Erkennungsmodi zu unterscheiden, die den Erkennungsserver 204 anweisen, wie und wann Ergebnisse zurückzugeben sind. Die Rückgabe von Ergebnissen impliziert die Bereitstellung des Ereignisses „onReco" beziehungsweise die Aktivierung der Belegungselemente „bind" je nach Gegebenheit. In einem Ausführungsbeispiel und wenn der Modus nicht vorgegeben ist, kann der Standard-Erkennungsmodus „automatisch" sein.
12 ist eine bildliche Darstellung des Betriebes des „automatischen" Modus für Spracherkennung (ähnliche Modi, Ereignisse etc. können für andere Erkennungs formen bereitgestellt werden). Eine Zeitlinie 281 zeigt an, wann der Erkennungsserver 204 angewiesen ist, die Erkennung bei 283 zu beginnen und wann der Erkennungsserver 204 Sprache bei 285 detektiert und bei 285 entscheidet, dass Sprache bei 287 geendet hat.
Verschiedene Attribute des Erkennungselements (Reco) steuern das Verhalten des Erkennungsservers 204. Das Attribut „initialTimeout" 289 ist die Zeit zwischen dem Beginn der Erkennung 283 und der Detektion von Sprache 285. Wenn dieser Zeitraum überschritten wird, wird das Ereignis „onSilence" 291 von dem Erkennungsserver 204 bereitgestellt werden, wodurch signalisiert wird, dass Erkennung geendet hat. Wenn der Erkennungsserver 204 die Äußerung als nicht erkennbar bewertet, wird ein Ereignis „onReco" 293 ausgegeben, das ebenfalls anzeigen wird, dass die Erkennung unterbrochen ist.
Andere Attribute, die Erkennung unterbrechen oder abbrechen können, sind unter anderem das Attribut „babbleTimeout" 295, welches der Zeitraum ist, in dem der Erkennungsserver 204 nach Detektion von Sprache bei 285 ein Ergebnis zurückgeben muss. Wenn dieser Zeitraum überschritten wird, werden verschiedene Ereignisse in Abhängigkeit davon, ob ein Fehler aufgetreten ist, ausgegeben. Wenn der Erkennungsserver 204 weiterhin Audio verarbeitet, wie zum Beispiel in dem Fall einer außergewöhnlich langen Äußerung, wird das Attribut „onNoReco" 293 ausgegeben. Wenn jedoch das Attribut „babbleTimeout" 295 aus beliebigen anderen Gründen überschritten wird, ist ein Erkennungsvorrichtungsfehler wahrscheinlicher, und ein Ereignis „onTimeout" 297 wird ausgegeben. Analog dazu kann ein Attribut „maxTimeout" 299 ebenfalls ausgegeben werden und gilt für den Zeitraum zwischen dem Erkennungsbeginn 283 und den an den Client 30 zurückgegebenen Ergebnissen. Wenn dieser Zeitraum überschritten wird, wird das Ereignis „onTimeout" 297 ausgegeben.
Wenn jedoch ein Zeitraum größer als das Attribut „endSilence" 301 überschritten wird, was impliziert, dass Erkennung abgeschlossen ist, unterbricht der Erkennungsserver 204 die Erkennung automatisch und gibt ihre Ergebnisse zurück. Es ist zu beachten, dass der Erkennungsserver 204 ein Vertrauensmaß implementieren kann, um zu entscheiden, ob die Erkennungsergebnisse zurückzugeben sind. Wenn das Vertrauensmaß unter einem Schwellenwert liegt, wird das Attribut „onNoReco" 293 ausgegeben, wohin gegen, wenn das Vertrauensmaß über dem Schwellenwert liegt, ein Attribut „onNoReco" 303 sowie die Erkennungsergebnisse ausgegeben werden. 12 veranschaulicht dabei, dass in dem „automatischen Modus" keine Anforderungen expliziter Halt () ausgegeben werden.
13 veranschaulicht bildlich den „Einzelmodus"-Betrieb des Erkennungsservers 204. Die oben in Bezug auf den „automatischen Modus" beschriebenen Attribute und Ereignisse gelten und werden somit mit den gleichen Verweisziffern gezeigt. Bei diesem Betriebsmodus wird jedoch eine Halt-Anforderung () 305 an der Zeitlinie 281 angezeigt. Die Halt-Anforderung () 305 entspräche in einem solchen Fall einem Ereignis, wie „pen-up" (Stift hoch) durch den Benutzer. In diesem Betriebsmodus steht die Rückgabe von Erkennungsergebnissen unter der Steuerung und Kontrolle der expliziten Halt-Anforderung () 305. Wie bei allen Betriebsmodi, wird das Ereignis „onSilence" 291 ausgegeben, wenn innerhalb des Zeitraumes „initialTimeout" 289 keine Sprache detektiert wird, jedoch wird bei diesem Betriebsmodus die Erkennung nicht abgebrochen. Analog dazu bricht ein Ereignis „onNoReco" 293, das durch eine nicht erkennbare Äußerung vor der Halt-Anforderung () 305 erzeugt wird, die Erkennung nicht ab. Wenn jedoch die zu dem Attribut „babbleTimeout" 295 oder zu dem Attribut „maxTimeout" 299 zugehörigen Zeiträume überschritten werden, wird die Erkennung abbrechen.
14 veranschaulicht bildlich den „Mehrmoden"-Betrieb des Erkennungsservers 204. Wie weiter oben angedeutet worden ist, wird dieser Betriebsmodus für ein Szenario des „offenen Mikrofons" oder in einem Diktat-Szenario verwendet. Im Allgemeinen werden in diesem Betriebsmodus Erkennungsergebnisse in Intervallen zurückgegeben, bis eine explizite Halt-Anforderung ()_ 305 empfangen wird oder die zu dem Attribut „babbleTimeout" 295 oder zu dem Attribut „maxTimeout" 299 zugehörigen Zeiträume überschritten werden. Es ist jedoch zu beachten, dass nach einem Ereignis „onSilence" 291, einem Ereignis „onReco" 303 oder einem Ereignis „onNoReco" 293, die die Erkennung nicht abbrechen, Zeitglieder für die Zeiträume „babbleTimeout" und „maxTimeout" zurückgesetzt werden.
Im Allgemeinen wird in diesem Betriebsmodus für jeden erkannten Satz ein Ereignis „onReco" 303 ausgegeben, und das Ergebnis wird zurückgegeben, bis die Halt-Anforderung () 305 empfangen wird. Wenn das Ereignis „onSilence" 291 aufgrund einer nicht erkennbaren Äußerung ausgegeben wird, werden diese Ereignisse gemeldet, jedoch wird die Erkennung fortgesetzt.
Wie weiter oben beschrieben worden ist, wird das zugehörige Reco-Objekt oder werden die zugehörigen Reco-Objekte für das Feld aktiviert, was Bereitstellen von wenigstens einer Anzeige an den Erkennungsserver 204, welche Grammatik zu verwenden ist, umfasst. Diese Informationen können mit den Sprachdaten einhergehen, die auf dem Client 30 aufgezeichnet worden sind, und an den Erkennungsserver 204 gesendet werden. Wie weiter oben angedeutet wurde, können die Sprachdaten Streamingdaten umfassen, die zu den von dem Benutzer eingegebenen Sprachdaten gehören, oder sie können vorverarbeitete Sprachdaten umfassen, die Sprachmerkmale anzeigen, die während der Spracherkennung genutzt werden. In einem weiteren Ausführungsbeispiel kann die clientseitige Verarbeitung weiterhin Normalisieren der Sprachdaten dergestalt umfassen, dass die von dem Erkennungsserver 204 empfangenen Sprachdaten von Client zu Client relativ konsistent sind. Dies vereinfacht die Sprachverarbeitung des Erkennungsservers 204 und ermöglicht damit eine einfachere Skalierbarkeit des Erkennungsservers 204, da der Erkennungsserver in Bezug auf die Art von Client und Kommunikationskanal statusarm gemacht werden kann.
Bei Empfang des Erkennungsergebnisses von dem Erkennungsserver 204 wird das Erkennungsergebnis dem entsprechenden Feld zugewiesen, und eine clientseitige Verifizierung oder Überprüfung kann durchgeführt werden, falls dies gewünscht wird. Bei dem Ausfüllen aller Felder, die zu dem gegenwärtig von dem Client gerenderten Code zugehörig sind, werden die Informationen zwecks Anwendungsverarbeitung an den Webserver 202 gesendet. Aus dem Vorgesagten geht hervor, dass wenngleich der Webserver 202 Code oder Seiten/Scripts geeignet für Erkennung an den Client 30 bereitgestellt hat, die Erkennungsdienste nicht durch den Webserver 202 durchgeführt werden, sondern vielmehr von dem Erkennungsserver 204. Die Erfindung schließt jedoch eine Implementierung nicht aus, bei der der Erkennungsserver 204 mit dem Webserver 202 kollokiert ist oder bei dem der Erkennungsserver 204 Bestandteil des Client 30 ist. Mit anderen Worten sind die hierin bereitgestellten Erweiterungen auch dann nützlich, wenn der Erkennungsserver 204 mit dem Webserver 202 oder mit dem Client 30 kombiniert ist, da die Erweiterung eine einfache und bequeme Schnittstelle zwischen diesen Komponenten bereitstellt.
Wenngleich dies in dem in 8 veranschaulichten Ausführungsbeispiel nicht gezeigt wird, kann Reco-Steuerung weiterhin ein entferntes Audioobjekt (RAO) umfassen, um die geeigneten Sprachdaten zu dem Erkennungsserver 204 zu leiten. Der Vorteil dessen, das entfernte Audioobjekt (RAO) als steckbares Objekt auszuführen, besteht darin, ein unterschiedliches für eine jede unterschiedliche Vorrichtung oder einen jeden Client bereitzustellen, da die Ton-Schnittstelle mit Wahrscheinlichkeit unterschiedlich sein kann. Zusätzlich kann ein entferntes Audioobjekt ermöglichen, dass mehrere Reco-Elemente gleichzeitig aktiviert werden.
Die 9A und 9B veranschaulichen eine Voice-only-Auszeichnungssprache, die hierin als HTML mit Seiten/Scripts ausgeführt ist. Wie deutlich veranschaulicht ist, umfasst der Code ebenfalls einen Körperabschnitt 300 und einen Scriptabschnitt 302. Es gibt eine weitere Erweiterung der Auszeichnungssprache – die Eingabeaufforderungssteuerung 303, die Attribute, wie zum Beispiel Aufschaltung (barge-in), umfasst. Die Spracherkennung wird jedoch in dem Voice-only-Ausführungsbeispiel aus den 9A und 9B unterschiedlich durchgeführt. Der Prozess wird nunmehr vollständig durch die Scriptfunktion „checkFilled" gesteuert, die die nicht ausgefüllten Felder entscheiden wird und die entsprechende Eingabeaufforderung und neue Objekte aktivieren wird. Dennoch wird Grammatik unter Verwendung des gleichen Kontexts wie des oben in Bezug auf 8 beschriebenen gesteuert, wobei Sprachdaten und die Anzeige der zu verwendenden Grammatik an den Erkennungsserver 204 bereitgestellt werden. Analog dazu wird der von dem Erkennungsserver 204 empfangene Ausgang zu den Feldern des Client (hierbei Telephonie-Sprachbrowser 212) zugewiesen.
Andere Merkmale, die im Allgemeinen nur bei Voice-only-Anwendungen vorhanden sind, sind eine Anzeige an den Benutzer, wenn Sprache nicht erkannt worden ist. In multimodalen Anwendungen, wie zum Beispiel 8, setzt ,onNoReco' einfach einen Nullwert in das angezeigte Feld, um Nicht-Erkennung anzuzeigen; somit ist keine weitere Aktion erforderlich. In dem Voice-only-Ausführungsbeispiel ruft „onNoReco" 305 eine Funktion „mumble" auf oder führt diese aus, welche einen Wortsatz an den Erkennungsserver 204 weiterleitet, welcher wiederum unter Verwendung eines geeigneten Text-zu-Sprache-Systems 307 (5) in Sprache umgewandelt wird. Der Erkennungsserver 204 übergibt einen Audiostrom an den Telephonie-Sprachbrowser 212, welcher wieder um an das Telephon 80 gesendet wird, um von dem Benutzer gehört zu werden. Analog dazu werden in der Voice-only-Anwendung ausgeführte andere Wellenform-Eingabeaufforderungen erforderlichenfalls ebenfalls durch den Erkennungsserver 204 in einen Audiostrom umgewandelt.
Es ist zu beachten, dass in diesem Beispiel nach der Wiedergabe der Willkommens-Eingabeaufforderung über die Funktion „welcome" die Funktion „checkFilled" den Benutzer auffordert, für jedes Feld eine Eingabe vorzunehmen, und die jeweilige Grammatik aktiviert, einschließlich der Wiederholung der Felder, die eingegeben worden sind, und der Bestätigung, dass die Informationen richtig sind, was die Aktivierung einer „Bestätigungs"-Grammatik umfasst. Bei diesem Ausführungsbeispiel ist zu beachten, dass eine jede der Reco-Steuerungen von dem Scriptabschnitt 302 ausgelöst wird, nicht jedoch von dem Körperabschnitt des vorangehenden Beispiels.
Die Auszeichnungssprache kann auf verschiedenen Arten von Client-Vorrichtungen (zum Beispiel multimodal, ohne Anzeige, spracheingabebasierte Client-Vorrichtungen, wie zum Beispiel ein Telephon) ausgeführt werden und unifiziert wenigstens erkennungsbezogene Ereignisse, GUI-Ereignisse oder Telephonieereignisse für einen Webserver, der in Wechselwirkung mit einer jeden Client-Vorrichtung steht. Dies ist besonders vorteilhaft, da es ermöglicht, dass wesentliche Teile der Webserver-Anwendung generisch oder unabhängig von der Art der Client-Vorrichtung geschrieben werden können. Ein Beispiel wird in den 8 und 9A, 9B mit den Funktionen „handle" beschrieben.
Wenngleich dies in 9 nicht gezeigt wird, gibt es zwei weitere Erweiterungen zu der Auszeichnungssprache zur Unterstützung der Telephoniefunktionalität – DTMF-Steuerung (Dual Tone Modulated Frequency) und Anrufsteuerelemente oder Objekte. DTMF arbeitet ähnlich wie die Reco-Steuerung. Sie spezifiziert eine einfache Grammatikaufnahme vom Tastaturstring zur Texteingabe. Zum Beispiel bedeutet „1" die Lebensmittelabteilung, „2" bedeutet die Drogerieabteilung u.s.w. Andererseits bearbeitet das Aufrufobjekt Telephoniefunktionen, wie zum Beispiel Übergabe und Drittanruf. Die Attribute, Eigenschaften, Methoden und Ereignisse werden in dem Anhang ausführlich beschrieben.
Die 10A und 10B veranschaulichen ein weiteres Beispiel einer Auszeichnungssprache, die für den Voice-only-Betriebsmodus geeignet ist. In diesem Ausführungsbeispiel erhält der Benutzer eine gewisse Steuerung und Kontrolle darüber, wann Informationen eingegeben oder gesprochen werden. Mit anderen Worten und wenngleich das System einleiten oder den Benutzer auf andere Weise anweisen kann, mit dem Sprechen zu beginnen, kann der Benutzer gegebenenfalls mehr Informationen darbieten, als die Informationen, die ursprünglich angefordert wurden. Hierbei handelt es sich um ein Beispiel von „gemischter Initiative". Im Allgemeinen kann sich der Benutzer bei dieser Dialogform der Wechselwirkung die Dialoginitiative mit dem System teilen. Neben dem oben angedeuteten und unten ausführlich diskutierten Beispiel, in dem der Benutzer mehr Informationen darbietet, als durch eine Eingabeaufforderung angefordert werden, kann der Benutzer auch Aufgaben umschalten, wenn er dazu nicht aufgefordert wird.
In dem Beispiel aus den 10A und 10B umfasst eine als „do_field" bezeichnete Grammatik Informationen, die zu den Grammatiken „g_card_types", „g_card_num" und „g_expiry_date" zugehörig sind. In diesem Beispiel sendet der Telephonie-Sprachbrowser 212 Sprachdaten, die er von einem Telefon 80 erhalten hat, und eine Anzeige zur Nutzung der Grammatik „do_field" bei Empfang der erkannten Sprache gemäß Bezeichnung durch „onReco" an den Erkennungsserver 204, die Funktion „handle" wird aufgerufen oder ausgeführt, welche das Zuweisen der Werte für beliebige oder alle Felder, die aus den Sprachdaten erkannt werden, umfasst. Mit anderen Worten umfasst das von dem Erkennungsserver 204 gewonnene Ergebnis auch Anzeigen für ein jedes der Felder. Diese Informationen werden analysiert und entsprechend verbindlichen Regeln, die in 405 spezifiziert sind, zu den entsprechenden Feldern zugewiesen. Wie in 5 angedeutet wird, kann der Erkennungsserver 204 einen Parser 309 umfassen.
Aus den 7, 8, 9A, 9B, 10A und 10B wird ein sehr ähnlicher Webentwicklungsrahmen verwendet. Die Datendarstellung ist in jedem dieser Fälle ebenfalls sehr ähnlich. Zusätzlich ermöglicht die Trennung der Datendarstellung und der Flusskontrollen eine größtmögliche Wiederverwendbarkeit zwischen verschiedenen Anwendungen (Systeminitiative und gemischte Initiative) oder verschiedenen Modalitäten (GUI webbasiert, Voice-only und multimodal). Dies ermöglicht weiterhin eine natürliche Erweiterung aus dem Voice-only-Betrieb über ein Telefon zu einem multimodalen Betrieb, wenn Telefone Anzeigen und Funktionalitäten ähnlich denen der Vorrichtung 30 umfassen. Anhang A nennt weitere Details der oben diskutierten Kontrollen und Objekte.
Wie weiter oben angedeutet wurde, können höhere Browser Scripting verwenden, um verschiedene Verschachtelungen durchzuführen, wie zum Beispiel das Aufrufen der Funktion „handle" in den oben genannten Beispielen, um die Erkennungsergebnisse zuzuweisen. In den oben beschriebenen Ausführungsbeispielen und wie in dem Anhang A unter 2.1.2. weiter beschrieben wird, wird das Element „bind" die Erkennungsergebnisse analysieren und Werte zuweisen, wobei das Element „bind" ein Teilelement oder Child-Element des Elements „reco" ist.
Wenngleich Scripting zweckdienlich sein kann, ist es eine weit verbreitete Auffassung, dass es sich dabei zum Beispiel wegen Sicherheitsbedenken nicht um die beste Form der Browserimplementierung handelt. Daher ist das Element „bind" in einem weiteren Ausführungsbeispiel oder Aspekt der vorliegenden Erfindung ein höheres Element (ähnlich „reco") und ist mit anderen reicheren Eigenschaften ausgestattet, die Scripting nachahmen können, ohne Scripting an sich durchzuführen.
Ohne die Nutzung von Scripting und ohne die Nutzung des unten diskutierten Aspekts der hier vorliegenden Erfindung können einige der unten diskutierten Fähigkeiten, wie zum Beispiel ausgereifte Dialogeffekte, nur erzielt werden, indem eine Seite an den Webserver 202 zurückgegeben wird, wodurch die Anwendungslogik auf derselben ausgeführt wird, um eine neue Seite zu erzeugen, und indem die Seite an die Client-Vorrichtung zurückgegeben wird. Dieser Aspekt der hier vorliegenden Erfindung ermöglicht es dem Programmierer, Methoden auf Objekten der Seite aufzurufen, ohne eine Serverrundreise durchzuführen.
In den oben beschriebenen Ausführungsbeispielen hat das Element „bind" lediglich die Attribute „TargetElement" und „TargetAttribute", um Erkennungsergebnisse zu einem Feld in dem Formular oder der Webseite zuzuweisen. In einem weiteren Ausführungsbeispiel umfasst das Element „bind" weiterhin eine „TargetMethod", welche zum Aufrufen des Objektaufrufes hinzugefügt wird. Die Verwendung und Fähigkeit von „TargetMethod" ist die Hauptmethode für das Nachahmen von Scripting. Zum Beispiel kann die folgende Syntax verwendet werden, um die Methode „X" des Objektes „OBJ1" aufzurufen.

<bind TargetElement = „OBJ1" TargetMethod = „X"...>.
Es ist zu beachten, dass wenngleich die hier gezeigten Beispiele der Ereignissyntax HTML/XHTML folgen, der Durchschnittsfachmann problemlos in der Lage sein sollte, die Anwendung von <bind> auf andere Eventingmechanismen zu verallgemeinern, einschließlich des Eventingstandards W3C Document Object Model Level 2 oder Level 3, des Ereignismodells ECMA Common Language Infrastructure (CLI), des Programmiersprachen-Ereignismodells Java, von W3C Synchronous Multimedia Integration Language (SMIL) und der als Entwurf vorliegenden Standards W3C XML Events Standard.
Die 15A und 15B sind eine Seite einer Auszeichnungssprache, die auf einem Client ausgeführt werden kann, insbesondere auf einem niederen Browser. In diesem Beispiel wird der Benutzer durch Audio-Eingabeaufforderungen zu einem Getränk befragt. Das System bestätigt danach, was für ein Getränk bestellt worden ist. In Abhängigkeit von den Erkennungsergebnissen führt das Element „bind" die Ausführung unter Verwendung von deklarierter Logik. Wenn das Getränk bestätigt wird, wird das Formular an den Webserver 202 zurückgegeben, und das alles ohne Scripting.
Im Allgemeinen umfast das Auszeichnungssprachenbeispiel aus den 15A und 15B einen Datenabschnitt 350, einen Sprachabschnitt 352 und Benutzerschnittstellen-Abschnitte 354, 356 und 358. Der Abschnitt 354 beschreibt das Erkennungsergebnis von der allgemeinen Abfrage, welches Getränk der Benutzer haben möchte, und leitet interaktiven Erkennungsfluss entweder zu einer erneuten Eingabeaufforderung, mit der gefragt wird, ob Sahne oder Zucker gewünscht werden, oder mit der das bestellte Getränk bestätigt wird. Insbesondere empfängt der Erkennungsabschnitt 356 ein Erkennungsergebnis, wenn auch Sahne und Zucker bestellt werden. Der Abschnitt 358 empfängt das Erkennungsergebnis für die Bestätigung des Getränkes. Der Abschnitt 360 ist ein Aufruf-Steuerungsabschnitt und verwendet ein neues Mitteilungsübermittlungs-Objekt „SMEX", das weiter unten diskutiert wird.
Wie weiter oben angedeutet worden ist, umfasst das Element „bind" dieses Aspektes der hier vorliegenden Erfindung Objektmethoden-Aufruf, der in dem Beispiel aus den 15A und 15B Benutzer-Wechselwirkung auslösen wird, indem die Eingabeaufforderung „welcome" wiedergegeben wird, wenn an 361 die Methode „start" an dem Objekt „welcome" ausgeführt wird.
Der Benutzer wird danach gefragt „Wünschen Sie ein Cola-Getränkt, Kaffee oder Orangensaft?", indem die Methode „start" des „angefragten" Objektes an 362 ausgeführt wird. Die Erkennung wird danach durchgeführt, indem die Methode „start" an 363 an dem Erkennungsobjekt „reco_drink" aufgerufen wird.
Die Auszeichnungssprache des Abschnittes 354 wird danach ausgeführt, wobei die von dem Erkennungsserver 204 verwendete Grammatik durch die Xpath-Anweisung „./drink types" bereitgestellt wird. Es ist zu beachten, dass wenngleich dieses Beispiel die Sprache W3C Xpath verwendet, der Durchschnittsfachmann problemlos in der Lage sein sollte, das Konzept auf andere Standardsprachen auszudehnen, so unter anderem auf die Abfragesprache W3C XML Query Language (XQL). Wie durch das Element „bind" 364 spezifiziert wird, wenn das von dem Erkennungsserver 204 empfangene Erkennungsergebnis ein Vertrauensergebnis von weniger als zehn aufweist, wird das Eingabeaufforderungs-Objekt „reprompt" an 366 ausgeführt, gefolgt von dem Eingabeaufforderungs-Objekt „ask" 368, an welchem Punkt das Erkennungsobjekt ""reco_drink" an 370 erneut eingeleitet wird. Wenn das zurückgegebene Erkennungsergebnis „coffee" mit einem Vertrauenswert von mehr als zehn ist, wird das Feld „drink" dem Wert des Erkennungsergebnisses an 372 zugewiesen, und der Benutzer wird danach an 374 durch das Eingabeaufforderungs-Objekt „reco_cream_sugar" zu einer Eingabe aufgefordert, ob er Sahne oder Zucker möchte. Das Erkennungsobjekt "reco_cream_sugar" in dem Abschnitt 356 wird sodann bei 376 aufgerufen. Im anderen Fall, wenn das Vertrauensergebnis des Erkennungsergebnisses größer als zehn ist, jedoch nicht Kaffee, wird das Feld Getränk an 378 erneut zugewiesen. Eine Bestätigung des Erkennungsergebnisses wird an 380 bereitgestellt, indem das Eingabeaufforderungs-Objekt „confirm" ausgeführt wird, gefolgt von dem Aufruf des Erkennungsobjektes „reco_yesno" in dem Abschnitt 358 bei 382. Wenn der Benutzer „Ja" mit einer Vertrauensbewertung von größer als zehn antwortet, wird die Eingabeaufforderung „thanks" an 384 abgespielt und danach wird das Formular an 386 eingereicht. Im anderen Fall, wenn der Benutzer „no" antwor tet oder wenn Vertrauensbewertung des Erkennungsergebnisses kleiner als zehn ist, wird das Eingabeaufforderungs-Objekt „retry" an 390 ausgeführt, erneut gefolgt von dem Eingabeaufforderungs-Objekt „ask", das an 392 ausgeführt wird, und Aufruf des Erkennungsobjektes „reco_drink" an 394.
Aus dem obenstehenden Beispiel geht hervor, dass das Element „bind" Mehrfachaufrufe von Methoden ermöglicht, wie in den Abschnitten 354, 356 oder 358 angedeutet wird. Falls gewünscht, können auch Mehrfachzuweisungen des Erkennungsergebnisses erklärt werden. In dem veranschaulichten Ausführungsbeispiel werden, wenn Mehrfachzuweisungen und Methodenaufrufe erklärt werden, diese in der Dokumentreihenfolge ausgeführt.
In einem weiteren Ausführungsbeispiel wird weiterhin eine Konvention zum Durchlaufen von Methodenargumenten bereitgestellt. Mit anderen Worten erfordern einige Methoden gegebenenfalls eine Liste von Argumenten. Dies wird erzielt, indem das Teilelement „arg" verwendet wird. Wenn zum Beispiel die Auszeichnungssprache
<bind TargetElement = „OBJ" TargetMethod =
„F"><arg>X</arg><arg>Y</arg></bind> gleich "OBJ.F(X,Y)" ist oder wenn "OBJ" ein Objekt ist, das eine Methode „F" mit Parametern oder Argumenten „X" und „Y" ist.
Das Element „bind" kann auch ein Attribut „event" umfassen, das erklärt, für welches Ereignis das Element „bind" vorgesehen ist. Zum Beispiel beudeutet die Auszeichnungssprache
<bind event = „onNoReco" = TargetElement „ „prompt1" TargetMethod – "start"/>, wenn das Ereignis "onNoReco" gesendet wird, dass die Methode "start" des Objektes "prompt1" aufgerufen werden wird. Um konsistent mit der Nutzung des Elementes „bind" als Child-Element des Elementes „Reco" zu sein, zum Beispiel wie weiter oben unter Bezugnahme auf 8 beschrieben, ist das Standardattribut für das Element „bind" „onReco".
Das Element „bind" als höheres Element kann beliebige der in dem Abschnitt 2.4. des Anhanges spezifizierten Ereignisse umfassen. Zusätzlich kann das Element „bind" auch ein Ereignis „onError" mit einem Attribut „status" umfassen, auf das zugegriffen werden kann und das zum Leiten des Programmflusses verwendet werden kann.
Insofern andere Ereignisse des Elementes „bind" „status"-Attribute aufweisen, kann auf diese ebenfalls zugegriffen werden.
Zusätzlich zu der Überprüfung der Bedingungen des Erkennungsergebnisses kann auch das aktuell ausgeführte Dokument oder die aktuell ausgeführte Seite überprüft werden. Insbesondere können sowohl das Attribut „test" als auch das Attribut „value" erweitert werden, so dass sie ein Grundelement „host" umfassen, das sich auf den Wurzelknoten des enthaltenden Dokumentes bezieht. Unter erneuter Bezugnahme auf die 15A, 15B weist das darin enthaltene Beispiel in dem Abschnitt 354 eine Zusatzlogik auf, um zu fragen, ob der Benutzer Sahne oder Zucker haben möchte, wenn er Kaffee verlangt. Die Kennzeichen zum Hinzufügen von Zucker oder Sahne und somit zum Aufrufen von Abschnitt 356 werden nur zurückgegeben, wenn das Getränkefeld „coffee" ist, wie durch die Auszeichnungssprache „host()/get_drink/drink='coffee'" spezifiziert wird.
Es ist zu beachten, dass das Element „bind" nicht nur auf Erkennungsergebnisse von dem Sprachserver 204 oder das Empfangen oder Zuweisen von Werten in dem Dokument anwendbar ist, sondern auch auf Nachrichtenobjekte (die hierin als „smex" bezeichnet werden, zum Beispiel von Anwendungen, die auf der Client-Vorrichtung laufen. In dem Beispiel aus den 15A und 15B wird die Seite ausgeführt, wenn eine Telephonieanwendung, die auf der Client-Vorrichtung läuft, einen Anruf detektiert. In dem Abschnitt 360 führt das Element „bind" die Eingabeaufforderung „welcome" aus oder spielt diese ab und beginnt Erkennung durch Ausführen des Objektes „reco_drink", wenn die Nachricht „/Call_connected" empfangen wird. Wie die von dem Sprachserver 204 empfangenen Erkennungsergebnisse, können die empfangenen Nachrichten stark voneinander abweichen. Einige der Nachrichten sind gut definiert, um den gewünschten Programmfluss auszulösen. Andere können empfangen und verarbeitet werden (zum Beispiel analysiert werden, wie die empfangenen Erkennungsergebnisse des Erkennungsservers. Zum Beispiel ermöglicht dies, dass die Auszeichnungssprache wie ein natürlicher Sprachparser von text von einer Tastatur verwendet werden kann. Das Reco-Element in dem Anhang A umfasst eine Eigenschaft zum Durchführen dieser Funktion. Analog dazu kann das Eingabeaufforderungselement verwendet werden, um eine Textnachricht für dynamischen Inhalt oder Audiowellendateien bereitzustellen, indem die Eigenschaft „innertext" verwendet wird, was ebenfalls weiterführend in dem Anhang A erläutert wird. Eventing kann analog zu Eventing für Erkennungsergebnisse sein. Zum Beispiel kann Eventing „onReceived" umfassen, das gesendet wird, wenn die Nachrichtenquelle (zum Beispiel eine Anwendung, die auf der Client-Vorrichtung läuft eine Nachricht für den Browser verfügbar hat.
Das „smex"-Objekt oder Nachrichtenobjekt ermöglicht somit, dass die hierin diskutierten Auszeichnungssprachenkennzeichen auf andere Komponenten oder Anwendungen, die auf der Client-Vorrichtung laufen, erweitert werden kann. Als ein weiteres Beispiel kann das Nachrichtenobjekt verwendet werden, um mit einer TTY-Komponente für Menschen mit Hörbehinderung zu kommunizieren, die auf der Client-Vorrichtung läuft. Die TTY-Komponente verwendet nicht Spracherkennung, sondern wird eine Nachricht von dem, was der Benutzer eingegeben hat, bereitstellen. Diese Nachricht wird sodann so genutzt, als ob ein Erkennungsergebnis von dem Erkennungsserver empfangen worden wäre, wobei die Nachricht analysiert und an Felder des Formulars zugewiesen werden kann oder indem Verarbeitung unter Verwendung der oben beschriebenen Elemente „reco", „grammar" oder „bind" erfolgt. Eine weiterführende Diskussion des Nachrichtenobjektes oder „smex"-Objektes wird in dem Anhang A bereitgestellt.
Das Element „bind" kann auch ein Attribut „for" umfassen, das ermöglicht, dass seine Aktion an anderen Objekte auf der Seite angehangen werden kann. Zum Beispiel wird eine Auszeichnungssprache, wie zum Beispiel:
<bind for = „prompt 1" event = „onComplete" targetElement = „prompt 2" = targetMethod = = "start"/>
die Start-Methode des Objektes "prompt 2" aufrufen, wenn das Objekt "prompt 1" das Ereignis "onComplete" sendet.
Unter erneuter Bezugnahme auf 5 kann der Webserver 202 ein serverseitiges deklaratives Einsteck-Authoringtool oder Modul 320 (zum Beispiel ASP oder ASP+ von der Microsoft Corporation, JSP oder ähnliches) umfassen. Das serverseitige Einsteckmodul 320 kann dynamisch clientseitige Auszeichnungssprachen erzeugen und sogar eine spezifische Form der Auszeichnungssprache für die Art von Client, der auf den Webserver 202 zugreift. Die Clientinformationen können bei der Ausgangseinrichtung der Client-Server-Beziehung bereitgestellt werden, oder der Webserver 202 kann Module oder Routinen umfassen, um die Fähigkeiten des Client zu detektieren. Auf die se Weise kann das serverseitige Steckmodul 320 eine clientseitige Auszeichnungssprache für ein jedes Spracherkennungsszenario erzeugen, das heißt für Voice-only über das Telefon 80 oder multimodal für die Vorrichtung 30. Durch die Verwendung des clientseitigen Modells (Erkennungs- (Reco) und Eingabeaufforderungssteuerungen, die in einer jeden Anwendung genutzt werden können) ist das Anwendungsauthoring für zahlreiche verschiedene Clients wesentlich einfacher.
Zusätzlich zu dem dynamischen Erzeugen clientseitiger Auszeichnungssprachen können höhere Dialogmodule, wie das Erfassen von Kreditkarteninformationen, das in 6 mit Auszeichnungssprachebeispielen aus den 8, 9A und 9B veranschaulicht wird, als serverseitige Steuerung implementiert werden, wie sie in dem Speicher 324 für Anwendung durch Entwickler beim Anwendungsauthoring gespeichert sind. Im Allgemeinen erzeugen die höheren Dialogmodule 324 dynamisch clientseitige Auszeichnungssprache und Script sowohl bei Voice-only- als auch bei Multimodal-Szenarien auf der Grundlage der von den Entwicklern spezifizierten Parameter. Die höheren Dialogmodule können Parameter beinhalten, um clientseitige Auszeichnungssprache zu erzeugen, die den Anforderungen der Entwickler entspricht. Zum Beispiel kann ein Kreditkarten-Informationsmodul Parameter beinhalten, die anzeigen, welche Arten von Kreditkarten das clientseitige Auszeichnungssprachenscript zulassen sollte. Ein Beispiel einer ASP+-Seite, die in dem serverseitigen Einsteckmodul 320 verwendet wird, wird in 11 veranschaulicht.
Wenngleich die hier vorliegende Erfindung unter Bezugnahme auf bevorzugte Ausführungsbeispiele beschrieben worden ist, wird der Durchschnittsfachmann erkennen, dass Änderungen in Form und Detail vorgenommen werden können, ohne von dem Erfindungsbereich der Erfindung abzuweichen.
ANHANG A
1. Einleitung
Die folgenden Kennzeichen sind eine Menge von Auszeichnungselementen, die ermöglichen, dass ein Dokument Sprache als Eingabe- oder Ausgabemedium verwendet. Die Kennzeichen sind als in sich geschlossene XML ausgelegt, die in SGML-abgeleitete Auszeichnungssprachen, wie zum Beispiel HTML, XHTML, cHTML, SMIL, WML oder ähnliche eingebettet werden kann. Die hierin verwendeten Kennzeichen sind ähnlich SAPI 5.0., welches bekannte Methoden sind, die von der Microsoft Corporation in Redmond, Washington, erhältlich sind. Die Kennzeichen, Elemente, Ereignisse, Attribute, Eigenschaften, Rückgabewerte etc. sind lediglich beispielhaft und sollen nicht einschränkend verstanden werden. Wenngleich sie in dieser Schrift als Beispiele für Sprach- und DTMF-Erkennung angeführt werden, können ähnliche Kennzeichen für andere Formen von Erkennung bereitgestellt werden.
Die hierin diskutierten wichtigsten Elemente sind:

<prompt ...> für Sprachsynthesekonfiguration und Eingabeaufforderungs-Abspielen;
<reco ...> für Erkennungsvorrichtungs-Konfiguration und Erkennungsausführung und Nachverarbeitung;
<grammar ...> für die Verarbeitung von Erkennungsergebnissen;
<bind ...> für die Verarbeitung von Erkennungsergebnissen;
<dtmf ...> für die Konfiguration und Steuerung von HTMF.

2. Reco-Erkennung
Das Reco-Element wird verwendet, um mögliche Benutzereingaben zu spezifizieren, und ist eine Vorrichtung zum Behandeln der Eingabeergebnisse.
Seine Hauptelemente als solches können <grammar> und <bind> sein, und es enthält Ressourcen zum Konfigurieren von Erkennungsvorrichtungs-Eigenschaften.
Reco-Elemente (Erkennungselemente) werden in höheren Browsern programmatisch über die Methoden Start und Stop beziehungsweise in SMIL-freigegebenen Browsern unter Verwendung von SMIL-Befehlen aktiviert. Sie gelten als aktiv deklarativ in niederen Browsern (das heißt nicht scriptunterstützende Browser) durch ihr Vorliegen auf der Seite. Um die Aktivierung von mehrfacher Grammatik in parallelen, mehrfachen Reco-Elementen (Erkennungselementen) zu ermöglichen, können Reco-Elemente als gleichzeitig aktiv angesehen werden.
Recos können auch einen besonderen Modus annehmen – 'automatic' (automatisch), 'single' (einzel) oder 'multiple' (mehrfach)-, um die Art der Erkennungsszenarien zu unterscheiden, die sie freigeben, und das Verhalten der Erkennungsplattform.
2.1. Reco-Inhalt
Das Reco-Element enthält eine Grammatik oder mehrere Grammatiken und wahlweise eine Menge von Belegungselementen, die die Ergebnisse der Erkennung prüfen und die entsprechenden Abschnitte auf Werte in der enthaltenden Seite kopieren.
In höheren Browsern unterstützt Reco die programmatische Aktivierung und Deaktivierung der einzelnen Grammatikregeln. Es ist weiterhin zu beachten, dass alle höheren Regeln in einer Grammatik standardmäßig für einen Erkennungskontext aktiv sind.
2.1.1. Das Element <grammar>
Das Grammatik-Element wird verwendet, um Grammatik zu spezifizieren, entweder als mitlaufende Verarbeitung oder durch Bezug unter Verwendung des Attributes src. Wenigstens eine Grammatik (entweder als mitlaufende Verarbeitung oder durch Bezug) wird üblicherweise spezifiziert. Grammatiken der mitlaufenden Verarbeitung können textbasierte Grammatikformate sein, wohingegen referenzierte Grammatik textbasiert oder binär sein kann. Mehrfach-Grammatikelemente können spezifiziert werden. Wenn mehr als ein Grammatikelement spezifiziert wird, werden die Regeln in der Grammatik als zusätzliche Regeln innerhalb derselben Grammatik hinzugefügt. Alle Regeln mit dem gleichen Namen werden überschrieben werden.
Attribute:

* src:

Wahlweise, wenn Grammatik als mitlaufende Verarbeitung spezifiziert ist. URI der Grammatik ist mit einzubeziehen. Es ist zu beachten, dass alle höheren Regeln in einer Grammatik für einen Erkennungs-Kontext standardmäßig aktiv sind.

* langID:

Wahlweise. Ein String, der angibt, welche Sprachmaschine zu verwenden ist. Das Stringformat folgt der Definition xml:lang. Zum Beispiel bezeichnet langID="en-us" US-amerikanisches Englisch. Dieses Attribut ist nur wirksam, wenn langID nicht in der Grammatik-URI spezifiziert ist. Wenn keine Vorgabe vorhanden ist, ist die Standardeinstellung US-amerikanisches Englisch.

Wenn die langID an mehreren Orten spezifiziert ist, folgt die langID einer Präzedenzreihenfolge von dem untersten Umfang – entfernte Grammatikdatei (das heißt, die Sprach-ID wird in der Grammatikdatei spezifiziert), gefolgt von dem Grammatikelement, gefolgt von dem Reco-Element.
Wenn sowohl eine src-Grammatik als auch eine Grammatik mit mitlaufender Verarbeitung spezifiziert sind, werden die Regeln der mitlaufenden Verarbeitung zu den referenzierten Regeln hinzugefügt, und Regeln mit dem gleichen Namen werden überschrieben.
2.1.2. Element <bind>
Das Belegungselement (bind) wird verwendet, um Werte aus den Erkennungsergebnissen in die Seite zu belegen.
Die von dem Belegungselement verbrauchten Erkennungsergebnisse können ein XML-Dokument sein, das eine semantische Auszeichnungssprache (SML) zum Spezifizieren der Erkennungsergebnisse enthält. Ihr Inhalt umfasst semantische Werte, tatsächliche gesprochene Worte und Vertrauensbewertungen. Die SML kann auch wechselnde Erkennungs-Auswahlen enthalten (wie zum Beispiel ein Erkennungsergebnis N-best). Ein Muster eines SML-Dokuments für die Äußerung „Ich möchte von Seattle nach Boston reisen." Wird unten veranschaulicht:
Da eine In-Grammatik-Erkennung angenommen wird, um ein XML-Dokument zu erzeugen – in semantischer Auszeichnungssprache oder SML-, werden die von dem SML-Dokument zu belegenden Werte unter Verwendung einer XPath-Abfrage referenziert. Und da die Elemente in der Seite, in die die Werte belegt werden, eindeutig identifiziert werden müssen (sie werden mit Wahrscheinlichkeit Steuerungen bilden), werden diese Zielelemente direkt referenziert.
Attribute:

* targetElement:

Erforderlich. Das Element, dem der Wert-Inhalt von der SML zugewiesen werden wird (wie in W3C SMIL 2.0.).

* targetAttribute:

Optional. Das Attribut des Zielelements, dem der Wert-Inhalt von der SML zugewiesen werden wird (wie bei dem Attribut attribute-Name in SMIL 2.0.). Wenn keine Vorgabe vorhanden ist, geht dieses auf die Standardeinstellung „value" (Wert) über.

* test:

Optional. Ein XML-Musfer-String (wie in der Spezifikation W3C XML DOM), der die Bedingung anzeigt, unter der das Erkennungsergebnis zugewiesen werden wird. Die Standardbedingung ist wahr.

* value:

Erforderlich. Ein XPATH-String (wie in der Spezifikation W3C XML DOM), der den Wert aus dem Erkennungsergebnis-Dokument spezifiziert, der dem Zielelement zuzuweisen ist.

Beispiel:
Ausgehend von dem oben genannten Rücksprung nutzt das folgende Erkennungselement (reco) belegen, um die Werte in origin_city (Ausgangsort) und dest_city (Zielort) in die Zielseitenelemente txtBoxOrigin und txtBoxDest zu übertragen:
Diese Belegung kann bedingt sein, wie in dem folgenden Beispiel, wobei eine Überprüfung auf das Vertrauensattribut des Ergebnisses dest_city (Zielort) als Vorbedingung für die Belegungsoperation durchgeführt wird:
Das Belegungselement ist ein einfaches deklaratives Mittel der Verarbeitung von Erkennungsergebnissen auf niederen und höheren Browsern. Für eine komplexere Verarbeitung implementiert das Erkennungsobjekt DOM, das von höheren Browsern unterstützt wird, den Ereignishandler onReco, um programmatische Scriptanalyse und Nachverarbeitung des Erkennungs-Rücksprungs zu ermöglichen.
2.2. Attribute und Eigenschaften
Die folgenden Attribute werden von allen Browsern unterstützt, und die Eigenschaften von höheren Browsern.
2.2.1. Attribute
Die folgenden Attribute von Reco werden verwendet, um die Spracherkennungsvorrichtung für eine Dialogwendung zu konfigurieren.

* initialTimeout:: Optional. Die Zeit in Millisekunden zwischen dem Beginn der Erkennung und der Erfassung von Sprache. Dieser Wert wird an die Erkennungsplattform übergeben, und falls er überschritten wird, wird ein Ereignis onSilence von der Erken nungsplattform bereitgestellt werden (siehe 2.4.2.). Wenn keine Vorgabe vorhanden ist, wird die Sprachplattform einen Standardwert verwenden.
* babbleTimeout:: Optional. Der Zeitraum in Millisekunden, in dem die Erkennungsvorrichtung nach Erfassung von Sprache ein Ergebnis zurückgeben muss. Für Erkennung in den Betriebsmodi Automatisch und Einzel betrifft dies den Zeitraum zwischen der Erfassung und dem Halt-Aufruf. Für Erkennung in dem ,Mehrfach'-Modus gilt die Zeitsperre für einen Zeitraum zwischen der Spracherfassung und einer jeden Sprachrückgabe, das heißt der Zeitraum wird nach einer jeden Rückgabe von Ergebnissen oder einem anderen Ereignis neu gestartet. Wenn er überschritten wird, werden verschiedene Ereignisse in Abhängigkeit davon, ob ein Fehler aufgetreten ist, ausgegeben. Wenn die Erkennungsvorrichtung noch immer Audio verarbeitet, wie zum Beispiel in dem Fall einer außergewöhnlich langen Äußerung, wird das Ereignis onNoReco ausgegeben, mit dem Statuscode 13 (siehe 2.4.4.). Wenn die Zeitsperre aus beliebigen anderen Gründen überschritten wird, ist ein Erkennungsvorrichtungs-Fehler wahrscheinlicher, und das Ereignis onTimeout wird ausgegeben. Wenn keine Vorgabe vorhanden ist, wird die Sprachplattform als Standardeinstellung auf einen internen Wert umschalten.
* maxTimeout:: Optional. Der Zeitraum in Millisekunden zwischen dem Beginn der Erkennung und der Rückgabe von Ergebnissen an den Browser. Wenn dieser Zeitraum überschritten wird, wird das Ereignis onTimeout von dem Browser umgestellt – dies verursacht Netzwerk- oder Erkennungsvorrichtungsfehler in verteilten Umgebungen. Für Erkennungen (Recos) im ,Mehrfach'-Modus, wie zum Beispiel bei babbleTimeout, wird der Zeitraum nach der Rückgabe einer jeden Erkennung oder eines anderen Ereignisses neu gestartet. Es ist zu beachten, dass das Attribut maxTimeout größer als oder gleich der Summe aus initialTimeout und babbleTimeout sein muss. Wenn keine Vorgabe vorhanden ist, wird die Standardeinstellung einen internen Wert der Plattform verwendet.
* endSilence:: Optional. Für Erkennungen (Recos) in dem automatischen Modus der Zeitraum von Ruhe in Millisekunden dem Ende einer Äußerung, der frei von Sprache sein muss, nachdem die Erkennungsergebnisse zurückgegeben werden. Wird für Erkennungen (Recos) von anderen Modi als automatisch ignoriert. Wenn keine Vorgabe vorliegt, wird ein plattforminterner Wert als Standardeinstellung verwendet.
* reject:: Optional. Die Erkennungs-Sperrungsschwelle, unterhalb derer die Plattform das Ereignis 'no reco' ausgegeben wird. Wenn keine Vorgabe vorhanden ist, wird die Sprachplattform einen Standardwert verwenden. Vertrauensbewertungen reichen von 0 bis 100 (ganzzahlig). Sperrwerte liegen dazwischen.
* server:: Optional. URI der Sprachplattform (zur Anwendung, wenn der Kennzeichen-Interpreter und die Erkennungsplattform nicht ortsgleich angeordnet sind). Ein Beispielwert kann server=protocol://yourspeechplatform sein. Ein Anwendungsschreiber kann ebenfalls sprachplattformspezifische Einstellungen bereitstellen, indem ein Abfragestring zu dem URI-String hinzugefügt wird, wie zum Beispiel protocol://yourspeechplatform?bargeinEnergyThreshold=0.5.
* langID:: Optional. Ein String, der anzeigt, welche Sprache die Sprachmaschine verwenden muss. Das Stringformat folgt der Definition xml:lang. Zum Beispiel bezeichnet langID="en-us" US-amerikanisches Englisch. Dieses Attribut ist nur wirksam, wenn die langID in dem Grammatikelement nicht spezifiziert ist (siehe 2.1.1.).
* mode:: Optional. Ein String, der den zu befolgenden Erkennungsmodus spezifiziert. Wenn keine Vorgabe vorhanden ist, wird als Standardeinstellung der Modus „automatisch" verwendet.

2.2.2. Eigenschaften
Die folgenden Eigenschaften enthalten die von dem Erkennungsprozess zurückgegebenen Ergebnisse (diese werden durch höhere Browser unterstützt).

* recoResult:: Nur Lesen. Die Erkennungsergebnisse, die in einem XML-DOM-Knotenobjekt gespeichert werden, das semantische Auszeichnungssprache (SML) enthält, wie unter 2.1.2. beschrieben wird. In dem Fall ohne Erkennung kehrt die Eigenschaft auf Null zurück.
* text:: Lesen/Schreiben. Ein String, der Text der erkannten Wörter speichert (das heißt Kurzzeichen für Inhalte des Textattributs des höchsten Elements in der SML-Erkennungsrückgabe in recoResult in einem Lesemodus. In dem Schreibmodus kann ein String zugeordnet werden, der sodann analysiert wird, als ob der String dem Erkennungsergebnis entspricht. Der Schreibmodus ermöglicht die Erweiterung der Auszeichnungs-Kennzeichen und die Verarbeitung derselben zu anderen Komponenten oder Anwendungen auf der Client-Vorrichtung. Der String kann aus dem Nachrichtenobjekt „smex" gewonnen werden.
* status:: Nur Lesen. Statuscode, der von der Erkennungsplattform zurückgegeben wird. Mögliche Werte sind 0 für erfolgreiche Erkennung oder die Fehlerwerte –1 bis –4 (gemäß Definition in den Ausnahmeregelungen, die bei der Start-Methode (Abschnitt 2.3.1.) und der Aktivieren-Methode (Abschnitt 2.3.4.) möglich sind, sowie der Status –11 bis –15, der bei dem Empfang von Erkennungsvorrichtungs-Ereignissen eingestellt ist (siehe Abschnitt 2.4.).

2.3. Objekt-Methoden
Die Erkennungs-Aktivierung und die Grammatik-Aktivierung können unter Verwendung der folgenden Methoden in dem DOM-Objekt von Reco gesteuert werden. Mit diesen Methoden können höhere Browser Reco-Objekte starten und stoppen, ablaufende Erkennungen abbrechen sowie einzelne höhere Grammatikregeln aktivieren und deaktivieren (nur höhere Browser).
2.3.1. Start
Die Start-Methode startet den Erkennungsprozess unter Verwendung aller höheren Regeln als aktive grammatische Informationen für den Erkennungskontext, die nicht ausdrücklich deaktiviert worden sind.

Syntax:

Object. Start()

Rückgabewert:

Keiner.

Ausnahmeregelung:

Diese Methode setzt einen Nicht-Null-Statuscode und löst bei Versagen ein Ereignis onNoReco aus. Mögliche Fehler sind unter anderem keine Grammatik (reco status/Erkennungsstatus = –1), Fehler des Ladens einer Grammatik, für die es eine Vielzahl von Gründen geben kann, wie zum Beispiel das Versagen des Kompilierens einer Grammatik, nicht vorhandene URI (reco status/Erkennungsstatus = –2) oder Sprachplattform-Fehler (reco status/Erkennungsstatus = –3).
2.3.2. Stop
Die Stop-Methode ist ein Aufruf zur Beendigung des Erkennungsprozesses. Das Reco-Objekt unterbricht die Audioaufzeichnung und die Erkennungsvorrichtung gibt auf Audio empfangene Erkennungsergebnisse an den Punkt zurück, an dem die Aufzeichnung unterbrochen wurde. Alle Erkennungsressourcen, die von Reco verwendet werden, werden freigegeben, und ihre Grammatik wird deaktiviert. (Es ist zu beachten, dass diese Methode in dem automatischen Modus nicht explizit für typische Erkennungen verwendet werden muss, da die Erkennungsvorrichtung selbst das Erkennungsobjekt (Reco-Objekt) an der Endpunkt-Erkennung unterbrechen wird, nachdem ein vollständiger Satz erkannt worden ist.) Wenn die Erkennung (Reco) nicht gestartet worden ist, hat der Abruf keine Wirkung.

Syntax:

Object. Stop()

Rückgabewert:

Keiner.

Ausnahmeregelung:

Keine.
2.3.3. Abbrechen
Die Methode Cancel/Abbrechen unterbricht die Audioeinspeisung in die Erkennungsvorrichtung, deaktiviert die Grammatik und gibt die Erkennungsvorrichtung frei und verwirft alle Erkennungsergebnisse. Der Browser wird ein Erkennungsergebnis für abgebrochene Erkennung ignorieren. Wenn die Erkennungsvorrichtung nicht gestartet worden ist, ist der Abruf ohne Wirkung.

Syntax:

Object. Cancel()

Rückgabewert:

Keiner.

Ausnahmeregelung:

Keine.
2.3.4. Aktivieren
Die Methode Activate/Aktivieren aktiviert eine höhere Regel in der kontextfreien Grammatik (CFG). Die Aktivierung muss aufgerufen werden, bevor die Erkennung beginnt, da sie während des 'gestarteten' Erkennungsprozesses Wirkung haben wird. Es ist zu beachten, dass alle höheren Grammatikregeln für den Erkennungskontext, die nicht explizit deaktiviert worden sind, bereits als aktiv behandelt worden sind.

Syntax:

Object. Activate (strName);

Parameter:

– strName: Erforderlich. Der zu aktivierende Regelname.

2.3.5. Deaktivieren
Diese Methode deaktiviert eine höhere Regel in der Grammatik. Wenn die Regel nicht existiert, ist die Methode wirkungslos.

Syntax:

Object. Deactivate (strName);

Parameter:

– strName: Erforderlich. Der zu deaktivierende Regelname. Ein leerer String deaktiviert alle Regeln.

2.4. Erkennungsereignisse
Das Objekt Reco DOM unterstützt die folgenden Ereignisse, deren Handler als Attribute des Erkennungselements (Reco) spezifiziert werden können.
2.4.1. onReco
Dieses Ereignis wird ausgelöst, wenn die Erkennungsvorrichtung ein Erkennungsergebnis für den Browser zur Verfügung hat. Für Erkennungen in dem automatischen Modus unterbricht dieses Ereignis den Erkennungsvorgang automatisch und löscht die Ressourcen (siehe 2.3.2.). OnReco wird typischerweise für programmatische Analyse des Erkennungsergebnisses und Verarbeitung des Inhaltes in die Seite verwendet.
Syntax:
Ereignisobjekt-Informationen:
Ereigniseigenschaften:
Wenngleich der Ereignishandler keine Eigenschaften direkt empfängt, kann der Handler das Ereignisobjekt nach Daten abfragen (siehe die Verwendung des Ereignisobjektes in dem untenstehenden Beispiel).
Beispiel:
Das folgende HTML-Fragment verwendet onReco zum Aufrufen eines Scriptes zum Analysieren des Erkennungsergebnisses und zur Zuordnung der Werte zu den richtigen Feldern.
2.4.2. onSilence
onSilence handhabt das Ereignis von von der Erkennungsplattform detektierter Nicht-Sprache vor dem Zeitraum, der in dem Attribut initialTimeout auf dem Reco spezifiziert wird (siehe Abschnitt 2.2.1.). Dieses Ereignis löscht den Erkennungsprozess automatisch für den automatischen Erkennungsmodus.
Syntax:
Ereignisobjektinformation:
Ereigniseigenschaften:
Wenngleich der Ereignishandler keine Eigenschaften direkt empfängt, kann der Handler das Ereignisobjekt nach Daten abfragen.
2.4.3. onTimeout
onTimeout handhabt zwei Arten von Ereignissen, die üblicherweise Fehler von der Sprachplattform Wiederspiegeln.

• Es handhabt das Ereignis, das von dem Kennzeichnungsinterpreter ausgegeben wird, das signalisiert, dass der in dem Attribut Maxtime vorgegebene Zeitrum (siehe Abschnitt 2.2.1.) abgelaufen ist, bevor die Erkennung abge schlossen war. Dieses Ereignis wird üblicherweise Probleme wiederspiegeln, die in einer verteilten Architektur auftreten können.
• Es handhabt weiterhin (ii) das Ereignis, das von der Spracherkennungsplattform ausgelöst wird, wenn die Erkennung begonnen hat, jedoch die Verarbeitung ohne Erkennung innerhalb des von babbleTimeout vorgegebenen Zeitraums abgebrochen hat (siehe Abschnitt 2.2.1.).

Dieses Ereignis bricht den Erkennungsprozess automatisch ab.
Syntax:
Ereignisobjektinformation:
Ereigniseigenschaften:
Wenngleich der Ereignishandler keine Eigenschaften direkt empfängt, kann der Handler das Ereignisobjekt nach Daten abfragen.
2.4.4. onNoReco
onNoReco ist ein Handler für das Ereignis, das von der Sprachplattform ausgelöst wird, wenn sie nicht in der Lage ist, gültige Erkennungsergebnisse zurückzugeben. Die ver schiedenen Fälle, in denen dies geschehen kann, werden durch den Statuscode unterschieden. Das Ereignis unterbricht den Erkennungsprozess automatisch.
Syntax:
Ereignisobjektinformation:
Ereigniseigenschaften:
Wenngleich der Ereignishandler keine Eigenschaften direkt empfängt, kann der Handler das Ereignisobjekt nach Daten abfragen.
3. Eingabeaufforderung
Das Element der Eingabeaufforderung wird verwendet, um Systemausgabe zu spezifizieren. Sein Inhalt kann eines oder mehrere der folgenden sein:

– Mitlaufender oder referenzierter Text, der mit prosodischen oder anderen Sprachausgabeinformationen markiert sein kann;
– Variablenwerte, die zu der Renderzeit von dem enthaltenden Dokument abgerufen wurden;
– Links zu Audiodateien.

Eingabeaufforderungs-Elemente können deklarativ durch niedere Browser interpretiert werden (oder durch SMIL-Befehle aktiviert werden) oder aber durch Objektmethoden auf höheren Browsern.
3.1. Eingabeaufforderungs-Inhalt
Das Eingabeaufforderungs-Element enthält die Ressourcen für Systemausgabe, entweder als Text oder als Bezug auf Audiodateien, oder beides.
Einfache Eingabeaufforderungen müssen nur den Text angeben, der für die Ausgabe erforderlich ist, wie zum Beispiel:
Dieser einfache Text kann auch eine weitere Markierung beliebiger der unten beschriebenen Aren enthalten.
3.1.1. Sprachsynthese-Markierung
Ein beliebiges Format von Sprachsynthese-Auszeichnungssprache kann in einem Eingabeaufforderungs-Element verwendet werden. (Dieses Format kann in dem in dem Abschnitt 3.2.1. beschriebenen Attribut 'tts' spezifiziert werden.)
Das folgende Beispiel zeigt Text in einer Anweisung zur Hervorhebung bestimmter darin enthaltener Wörter:
3.1.2. Dynamischer Inhalt
Der tatsächliche Inhalt der Eingabeaufforderung kann gegebenenfalls auf dem Client verarbeitet werden, kurz bevor die Eingabeaufforderung ausgegeben wird. Um einen bestimmten Wert zu bestätigen, muss der Wert zum Beispiel in einer Variablen dereferenziert werden. Das Werteelement kann für diesen Zweck verwendet werden.
Werteelement

Wert: Optional. Ruft die Werte eines Elements in dem Dokument ab.

Attribute:

* targetElement:

Optional. Entweder href oder targetElement muss spezifiziert werden. Die ID des Elements, das den Wert enthält, wird abgerufen.

* targetAttribute:

Optional. Das Attribut des Elements, von dem der Wert abgerufen werden wird.

* href:

Optional. Die URI eines Audiosegments. Href wird targetElement übersteuern, wenn beide vorliegen. Das Attribut targetElement wird zum Referenzieren eines Elements in dem enthaltenden Dokument verwendet. Der Inhalt des Elements, dessen ID durch targetElement spezifiziert wird, wird in den zu synthetisierenden Text eingefügt. Wenn der gewünschte Inhalt in einem Attribut des Elements gehalten wird, kann das Attribut targetAttribute verwendet werden, um das notwendige Attribut auf dem targetElement zu spezifizieren. Dies ist hilfreich für das Dereferenzieren der Werte, zum Beispiel in HTML-Formularsteuerungen. In der folgenden Veranschaulichung werden die Attribute „value" der Elemente „txtBoxOrigin" und „txtBoxDest" in den Text eingefügt, bevor die Ei ngabeaufforderung ausgegeben wird.

3.1.3. Audiodateien
Das Werteelement kann auch verwendet werden, um Bezug zu einer vorher aufgezeichneten Audiodatei zur Wiedergabe anstelle einer oder innerhalb einer synthetisierten Eingabeaufforderung herzustellen. Das folgende Beispiel spielt an dem Ende der Aufgabeeinforderung einen Piepton ab:
3.1.4. Referenzierte Eingabeaufforderung
Anstelle des Spezifizierens von Inhalt als mitlaufender Verarbeitung kann der Attribut src mit einem leeren Element verwendet werden, um einen externen Inhalt über URI zu referenzieren, wie zum Beispiel in:
Das Ziel des Attributes src kann beliebige Teile oder den gesamten oben spezifizierten Inhalt für Eingabeaufforderungen für mitlaufende Verarbeitung halten.
3.2. Attribute und Eigenschaften
Das Eingabeaufforderungselement hält die folgenden Attribute (niedere Browser) und Eigenschaften (niedere und höhere Browser).
3.2.1. Attribute

* tts:

Optional. Die Art der Auszeichnungssprache für Synthese Text-zu-Sprache. Die Standardeinstellung ist „SAPI 5".

* src:

Optional, wenn eine Eingabeaufforderung für mitlaufende Verarbeitung spezifiziert ist. Die URI einer referenzierten Eingabeaufforderung (siehe Abschnitt 3.1.4.).

* bargein:

Optional. Ganzzahlig. Der Zeitraum in Millisekunden von dem Start der Eingabeaufforderung bis zu dem Zeitpunkt, an dem die Wiedergabe durch den menschlichen Hörer unterbrochen werden kann. Die Standardeinstellung ist unendlich, das heißt es ist keine Aufschaltung (barge-in) zulässig. Baregin=0 ermöglicht die sofortige Aufschaltung. Dies gilt für alle Arten von Aufschaltungen, die von der Plattform unterstützt werden. Entweder kennwortbasierte oder energiebasierte Aufschaltungszeiten können auf diese Art und Weise konfiguriert werden, in Abhängigkeit davon, welches zum Zeitpunkt des Startens der Erkennung freigegeben ist.

* prefetch:

Optional. Boolesches Kennzeichen, das anzeigt, ob die Eingabeaufforderung unverzüglich synthetisiert und in dem Browser gespeichert werden soll, wenn die Seite geladen wird. Die Standardeinstellung ist falsch.

3.2.2. Eigenschaften
Höhere Browser unterstützen die folgenden Eigenschaften in dem DOM-Objekt der Eingabeaufforderung.

* bookmark:: Nur Lesen. Ein Stringobjekt, das den Text des zuletzt angetroffenen Synthesebookmarks aufzeichnet.
* status:: Nur Lesen. Statuscode, der von der Sprachplattform zurückgegeben wird.
* Innertext:: Nur Lesen. Diese Eigenschaft wird die Texttranskription der Eingabeaufforderung, die an den Synthesizer gesendet wird, bereitstellen. Wenn zum Beispiel eine Eingabeaufforderung die Wiedegabe einer Audiowellendatei umfasst, stellt diese Eigenschaft eine Textversion dieser Eingabeaufforderung bereit (die oft in der Audiowellendatei gespeichert wird), die danach angezeigt oder auf andere Weise verwendet werden kann, wie zum Beispiel durch Bereitstellen der Textversion der Eingabeaufforderung an eine Komponente oder an eine Anwendung, die auf der Client-Vorrichtung läuft. Die Eigenschaft InnerText kann ebenfalls verwendet werden, um Textversionen von Eingabeaufforderungen, die dynamischen Inhalt beinhalten, bereitzustellen.

3.3. Eingabeaufforderungs-Methoden
Die Wiedergabe von Eingabeaufforderungen kann unter Verwendung der folgenden Methoden in dem DOM-Objekt der Eingabeaufforderung gesteuert werden. Auf diese Weise können höhere Browser Eingabeaufforderungs-Objekte starten und stoppen, ablaufende Eingabeaufforderungen in Pause schalten und die Wiedergabe fortsetzen sowie die Geschwindigkeit und die Lautstärke der synthetisierten Sprache verändern.
3.3.1. Start
Startet die Wiedergabe der Eingabeaufforderung. Wenn kein Argument angeführt wird, gibt die Methode die Inhalte des Objektes wieder. Nur ein einzelnes Eingabeaufforderungs-Objekt wird zu einer gegebenen Zeit als 'gestartet' angesehen, das heißt, wenn Start aufeinanderfolgend aufgerufen wird, werden alle Wiedergaben in der Reihenfolge abgespielt.

Syntax:

Object.Start([strText]);

Parameter:

– strText: Der an den Synthesizer zu sendende Text. Falls vorhanden, übersteuert dieses Argument die Inhalte des Objektes.

3.3.2. Pause
Unterbricht die Wiedergabe, ohne den Audiopufferspeicher zu löschen. Dies hat keine Auswirkung, wenn die Wiedergabe unterbrochen oder abgebrochen ist.

Syntax:

Objeckt.Pause();

Rückgabewert:

Keiner.

Ausnahmeregelung:

Keine.
3.3.3. Wiederaufnehmen
Nimmt die Wiedergabe wieder auf, ohne den Audiopufferspeicher zu löschen. Diese Methode ist unwirksam, wenn die Wiedergabe nicht unterbrochen worden ist.

Syntax:

Object.Resume();

Rückgabewert:

Keiner.

Ausnahmeregelung:

Gibt eine Ausnahmeregelung aus, wenn die Wiederaufnahme fehlschlägt.
3.3.4. Stop
Hält die Wiedergabe an, falls dies nicht bereits geschehen ist, und löscht den Audiopufferspeicher. Wenn die Wiedergabe bereits angehalten worden ist, löscht die Methode einfach den Audiopufferspeicher.

Syntax:

Object.Change (speed, volume);

Parameter:

– speed: Erforderlich. Der Faktor der Geschwindigkeitsänderung. Speed=2.0 bedeutet das Zweifache der aktuellen Geschwindigkeit. Speed=0.5 bedeutet die Hälfte der aktuellen Geschwindigkeit. Speed=0 bedeutet die Wiederherstellung des Standardwertes.
– volume: Erforderlich. Der Faktor der Lautstärkeänderung. Volume=2.0 bedeutet das Doppelte der aktuellen Lautstärke. Volume=0.5 bedeutet die Hälfte der aktuellen Lautstärke. Volume=0 bedeutet die Wiederherstellung des Standardwertes.

3.3.6. Beispiel für Eingabeaufforderungssteuerung
Das folgende Beispiel zeigt, wie die Steuerung der Eingabeaufforderung unter Verwendung der oben genannten Methoden für eine Plattform, die keinen Schlüsselwort-Aufschaltmechanismus unterstützt, redaktionell bearbeitet werden kann.
Der Aktienmarkt war wieder einmal träge, da den Investoren vor der in der kommenden Woche anstehenden Sitzung der Zentralbank keine Anreize für größere Aktienbewegungen angeboten wurden. Der techniklastige Nasdaque Composite Index fiel um 42,51 Punkte auf fast 2156,26. Der Dow Jones Industrial Average fiel um 17,05 Punkte auf 10866,46, nachdem eine kurze Erholung am frühen Nachmittag wirkungslos blieb.
3.4. Eingabeaufforderungs-Ereignisse
Das Eingabeaufforderungs-Objekt DOM unterstützt die folgenden Ereignisse, deren Handler als Attribute des Eingabeaufforderungs-Elements spezifiziert werden können.
3.4.1. onBookmark
Löst aus, wenn ein Synthese-Bookmark angetroffen wird. Das Ereignis unterbricht die Wiedergabe nicht.
Syntax:
Ereignisobjekt-Informationen:
Ereigniseigenschaften:
Wenngleich der Ereignishandler keine Eigenschaften direkt empfängt, kann der Handler das Ereignisobjekt nach Daten abfragen.
3.4.3. onComplete:
Löst aus, wenn die Wiedergabe der Eingabeaufforderung das Ende erreicht oder wenn Ausnahmeregelungen (gemäß obenstehender Definition) angetroffen werden.
Syntax:
Ereignisobjekt-Eigenschaften:
Ereigniseigenschaften:
Wenngleich der Ereignishandler keine Eigenschaften direkt empfängt, kann der Handler das Ereignisobjekt nach Daten abfragen.
3.4.4. Verwendung von Bookmarks und Ereignissen
Die folgenden Beispiele zeigen, wie Bookmark-Ereignisse verwendet werden können, um die Semantik einer Benutzer-Antwort – entweder eine Korrektur eines Ausgangsortes oder die Angabe eines Zielortes – dahingehend zu bestimmen, wann die Aufschaltung während der Ausgabe der Eingabeaufforderung erfolgt ist. Der onBargein-Handler (Aufschaltungshandler) ruft ein Script auf, das eine allgemeine Markierungs-Variable ('mark') auf das letzte in der Eingabeaufforderung angetroffene Bookmark setzt, und der Wert dieser 'Markierung' wird in der Erkennungs-Verarbeitungsfunktion ('heard') verwendet, um den richtigen Wert einzustellen.
4. DTMF
Erzeugt ein DTMF-Erkennungsobjekt. Das Objekt kann unter Verwendung eines Auszeichnungssprachensyntax für mitlaufende Verarbeitung oder in Scripting instantiiert werden. Bei Aktivierung kann DTMF bewirken, dass ein Eingabeaufforderungs-Objekt in einem Aufschaltereignis ausgelöst wird. Es ist zu beachten, dass die Kennzeichen und das Eventing, die unten in Bezug auf DTMF-Erkennung diskutiert werden, sowie die in dem Abschnitt 5 diskutierte Aufrufsteuerung im Allgemeinen zu der Wechselwirkung zwischen dem Sprachbrowser 216 und dem Medienserver 214 gehören.
4.1. Inhalt

* dtmfgrammar:

Für Grammatik für mitlaufende Verarbeitung.

* bind:

Zuweisung des DTMF-Umwandlungsergebnisses zu dem richtigen Feld.

Attribute:

* targetElement:

Erforderlich. Das Element, dem ein Teil-Erkennungsergebnis zugeordnet werden wird (siehe dito wie in W3C SMIL 2.0.)

* targetAttribute:

Das Attribut des Zielelements, dem das Erkennungsergebnis zugeordnet werden wird (siehe dito wie in SMIL 2.0.). Die Standardeinstellung ist „value" (Wert).

* test:

Bedingung für die Zuordnung. Die Standardeinstellung ist wahr.

Beispiel 1:

Abbilden von Schlüsseln auf den Text.

Wenn "city_choice" aktiviert worden ist, wird "Seattle" dem Eingabefeld zugeordnet werden, wenn der Benutzer die 1 drückt, beziehungsweise "Boston", wenn er die 2 drückt, ansonsten nichts.
Beispiel 2:

Wie DTMF mit Mehrfachfeldern verwendet werden kann.

Dieses Beispiel zeigt, wie es Benutzern ermöglicht wird, in Mehrfachfelder hineinzugehen.
Beispiel 3:

Wie sowohl Sprache- als auch DTMF-Eingaben ermöglicht werden und wie Sprache gesperrt wird, wenn der Benutzer DTMF startet.

4.2. Attribute und Eigenschaften
4.2.1. Attribute

* dtmfgrammar:

Erforderlich. Die URI einer DTMF-Grammatik.

4.2.2. Eigenschaften

* DTMFgrammar:

Lesen-Schreiben.

Ein Knotenobjekt XML DOM, das DTMF zu Stringumwandlungsmatrix darstellt (auch DTMF-Grammatik genannt). Die Standardeinstellung ist

* flush

Lesen/Schreiben, ein Boolesches Kennzeichen, das anzeigt, ob der DTMF-Pufferspeicher auf der zugrundeliegenden Telephonie-Schnittstellenkarte vor der Aktivierung automatisch gelöscht wird. Die Standardeinstellung ist falsch, um die Type-Ahead-Funktion zu nutzen.

* escape

Lesen/Schreiben. Die Escape-Taste, um die DTMF-Lesesitzung zu beenden. Die Escape-Taste ist eine Taste.

* numDigits

Lesen/Schreiben. Die Anzahl der Tastenanschläge zum Beenden der DTMF-Lesesitzung. Wenn sowohl Escape als auch die Länge spezifiziert sind, wird die DTMF-Sitzung beendet, wenn eine der Bedingungen erfüllt ist.

* dtmfResult

Nur-Lese-String, der die von dem Benutzer eingegebenen DTMF-Tasten speichert. Escape ist in dem Ergebnis enthalten, wenn es eingegeben wird.

* text

Nur-Lese-String, der den durch einen Weißbereich abgetrennten Token-String speichert, wobei ein jeder Token gemäß der DTMF-Grammatik umgewandelt wird.

* initialTimeout

Lesen/Schreiben. Zeitsperre für den Empfang des ersten DTMF-Tastenanschlags, in Millisekunden. Wenn keine Vorgabe erfolgt, wird als Standardeinstellung auf die interne Einstellung der Telephonieplattform umgeschaltet.

* interdigitTimeout

Lesen/Schreiben. Zeitsperre für benachbarte TDMF-Tastenanschläge, in Millisekunden. Wenn keine Vorgabe erfolgt, wird als Standardeinstellung auf die interne Einstellung der Telephonieplattform umgeschaltet.

4.3. Objektmethoden:
4.3.1. Start

Gibt DTMF-Unterbrechung frei und startet eine DTMF-Lesesitzung. Syntax: Object.Start(); Rückgabewert: Keiner. Ausnahmeregelung: Keine.

4.3.2. Stop

Sperrt DTMF. Die von dem Benutzer eingegebenen Tastenanschläge verbleiben jedoch in dem Pufferspeicher. Syntax: Object.Stop(); Rückgabewert: Keiner. Ausnahmeregelung: Keine.

4.3.3. Flush

Löscht den DTMF-Pufferspeicher. Das Löschen kann während einer DTMF-Sitzung nicht aufgerufen werden. Syntax: Object.Flush(); Rückgabewert: Keiner. Ausnahmeregelung: Keine.

4.4. Ereignisse
4.4.1. onkeypress
Löst aus, wenn eine DTMF-Taste gedrückt wird. Dies übersteuert das Standardeinstellungs-Ereignis, das von der HTML-Steuerung vererbt wird. Wenn ein Benutzer die Escape-Taste drückt, löst das Ereignis onRec aus, nicht onKeypress.
Syntax:
Ereignisobjekt-Information:
Ereigniseigenschaften:
Wenngleich der Ereignishandler keine Eigenschaften direkt empfängt, kann der Handler das Ereignisobjekt nach Daten abfragen.
4.4.2. onReco
Löst aus, wenn eine DTMF-Sitzung beendet wird. Das Ereignis sperrt automatisch das aktuelle DTMF-Objekt.
Syntax:
Ereignisobjekt-Information:
Ereigniseigenschaften:
Wenngleich der Ereignishandler keine Eigenschaften direkt empfängt, kann der Handler das Ereignisobjekt nach Daten abfragen.
4.4.3. onTimeout
Löst aus, wenn kein Ereignis Satzende vor der Zeitsperre empfangen wird. Das Ereignis hält den Erkennungsprozess automatisch an.
Syntax:
Ereignisobjekt-Information:
Ereigniseigenschaften:
Wenngleich der Ereignishandler keine Eigenschaften direkt empfängt, kann der Handler das Ereignisobjekt nach Daten abfragen.
5. Object CallControl
Dieses stellt die Telefonschnittstelle (Anruf, Endgerät und Verbindung) des Telefon-Sprachbrowsers dar. Dieses Objekt ist ebenso nativ wie ein Fensterobjekt in einem GUI-Browser. Als solches ist die Lebensdauer des Telefonobjektes die gleiche wie die Browserinstanz selbst. Ein Sprachbrowser für Telephonie instantiiert das Telefonobjekt, eines für jeden Anruf. Die Benutzer instantiieren oder beseitigen das Objekt nicht.
An diesem Punkt werden durch dieses Objekt nur Merkmale, die sich auf den zuerst anrufenden Teilnehmer beziehen, beschrieben.
5.1. Eigenschaften
* address

Nur Lesen. Knotenobjekt XML DOM. Implementierungsspezifisch. Dies ist die Adresse des Anrufers. Für ein öffentliches Selbstwählferndienstnetz (SWFD, PSTN) kann es eine Kombination aus ANI und ALI sein. Für VoIP ist dies die IP-Adresse des Anrufers.

* ringsBeforeAnswer

Die Anzahl der Ruftöne vor dem Beantworten eines ankommenden Anrufs. Die Standardeinstellung ist unendlich, das heißt der Entwickler muss die untenstehende Antwort-Methode () spezifisch nutzen, um den Telefonanruf zu beantworten. Wenn das Call-Center ACD verwendet, um die ankommenden Telefonanrufe in eine Warteschleife zu geben, kann diese Anzahl auf 0 gesetzt werden.

5.2. Methoden

Achtung: Alle hier genannten Methoden sind synchron.

5.2.1. Transfer/Übertragung
Überträgt den Anruf. Für Blindübertragung kann das System den ursprünglichen Anruf beenden und die Systemressourcen freigeben, nachdem die Übertragung abgeschlossen ist.

Syntax:

Telephone.Transfer(strText);

Parameter:

– strText: Erforderlich. Die Adresse des vorgesehenen Empfängers.

5.2.2. Bridge/Brücke
Drittteilnehmer-Übertragung. Nachdem der Anruf übertragen worden ist, kann der Browser für den Anruf zugewiesene Ressourcen freigeben. Es obliegt der Anwendung, den Sitzungsstatus wiederherzustellen, wenn der übertragene Anruf unter Verwendung von strUID zurückruft. Die zugrundeliegende Telephonieplattform kann den Rückanruf an einen anderen Browser leiten. Der Anruf kann nur zurückrufen, wenn der Empfänger den Anruf beendet.

Syntax:

telephone.Bridge(strText, strUID, (imaxTime]
);
Parameter:

– strText: Erforderlich. Die Adresse des vorgesehenen Empfängers.
– strUID: Erforderlich. Die Sitzungs-ID, die den aktuellen Anruf eindeutig identifiziert. Wenn der übertragene Anruf zurückgeleitet wird, erscheint die srtUID an dem Adressattribut.
– imaxTime: Optional. Die maximale Dauer des übertragenen Anrufs in Sekunden. Wenn keine Vorgabe vorhanden ist, wird die Standardeinstellung des plattforminternen Wertes verwendet.

Rückgabewert: Keiner. Ausnahmeregelung: Keine.

5.2.3. Answer/Entgegennehmen

Nimmt den Telefonanruf entgegen. Syntax: telephone.Answer(); Rückgabewert: Keiner. Ausnahmeregelung: Gibt eine Ausnahmeregelung aus, wenn keine Verbindung vorhanden ist. Das Ereignis onAnswer wird in diesem Fall ausgelöst.

5.2.4. Hangup/Auflegen

Beendet den Telefonanruf. Hat keine Auswirkung, wenn gegenwärtig kein Anruf abläuft. Syntax: telephone.Hangup(); Rückgabewert: Keiner. Ausnahmeregelung: Keine.

5.2.5. Connect/Verbinden

Beginnt einen abgehenden Telefonanruf eines ersten Teilnehmers. Syntax: telephone.Connect (strText, [iTimeout]); Parameter:

– strText: Erforderlich. Die Adresse des vorgesehenen Empfängers.
– iTimeout: Optional. Die Zeit in Millisekunden, bevor der Anrufversuch abgebrochen wird. Ohne Vorgabe wird der plattforminterne Wert als Standardeinstellung verwendet.

Rückgabewert: Keiner. Ausnahmeregelung: Gibt eine Ausnahmeregelung aus, wenn der Anruf nicht abgeschlossen werden kann, einschließlich des Auftretens des Besetztsignals oder des Erreichens eines Faxgerätes oder eines Anrufbeantworters (Achtung: Die Hardware unterstützt dieses Merkmal gegebenenfalls nicht.)

5.2.6. Record/Aufzeichnen

Zeichnet Benutzeraudio in einer Datei auf. Syntax: telephone.Record (url, endSilence, [maxTimeout], [initialTimeout]); Parameter:

– url: Erforderlich. Der URL der aufgezeichneten Ergebnisse.
– endSilence: Erforderlich. Die Zeit in Millisekunden bis zum Anhalten der Aufzeichnung, nachdem Ruhe detektiert wird.
– maxTimeout: Optional. Größte Zeit in Sekunden für die Aufzeichnung. Die Standardeinstellung ist plattformspezifisch.
– initialTimeout: Optional. Größte Zeit (in Millisekunden) der Ruhe, die zu Beginn einer Aufzeichnung zulässig ist.

Rückgabewert: Keiner. Ausnahmeregelung: Gibt eine Ausnahmeregelung aus, wenn die Aufzeichnung nicht auf den URL geschrieben werden kann.

5.3. Ereignishandler
Anwendungsentwickler, die einen Telefon-Sprachserver verwenden, können die folgenden Ereignishandler implementieren.
5.3.1. onlncoming()
Wird aufgerufen, wenn der Sprachbrowser einen ankommenden Telefonanruf empfängt. Alle Entwickler können diesen Handler benutzen, um die Adresse des Anrufers zu lesen und um kundenspezifische Merkmale aufzurufen, bevor der Telefonanruf entgegengenommen wird.
5.3.2. onAnswer()
Wird aufgerufen, wenn der Sprachbrowser einen ankommenden Telefonanruf entgegennimmt.
5.3.3. onHangup()
Wird aufgerufen, wenn der Benutzer das Telefon auflegt. Dieses Ereignis wird NICHT automatisch ausgelöst, wenn das Programm die Methoden Hangup/Auflegen oder Transfer/Übertragung aufruft.
5.4. Beispiel
Dieses Beispiel zeigt Scripting, das mit den Anruf-Steuerereignissen verdrahtet ist, um die Telephoniesitzung zu manipulieren.
6. Steuerung des Dialogflusses
6.1. Nutzung von HTML und Script zur Implementierung des Dialogflusses Diese Beispiel zeigt, wie ein einfacher Dialogfluss, der Werte für Eingabefelder sucht und kontextsensitive Hilfe für die Eingabe anbietet, implementiert wird. Es verwendet das Titelattribut an den HTML-Eingabemechanismen (die in einem visuellen Browser als „Tooltip"-Mechanismus verwendet werden), um die Ausbildung des Inhaltes der Hilfe-Eingabeaufforderung zu unterstützen.
6.2. Nutzung der SMIL
Das folgende Beispiel zeigt die Aktivierung einer Eingabeaufforderung und von Erkennungselementen (Reco-Elementen) unter Verwendung von SMIL-Mechanismen.
7. Element/Objekt SMEX(-Nachricht)
SMEX, die Abkürzung für Simple Messaging EXchange/EXtension, ist ein Objekt, das mit einer externen Komponente oder Anwendung auf der Plattform der Client-Vorrichtung kommuniziert. Es kann in ein auf XML oder einer ähnlichen Auszeichnungssprache basierendes Dokument als Element mit dem Markierungsnamen <smex> eingebettet werden. Beispielhafte Verwendungen des Mitteilungsübermittlungsobjektes können unter anderem Protokollierungs- und Telephoniesteuerung sein. Das Objekt stellt die Erweiterungsfähigkeit von Auszeichnungssprache auf Basis der Erkennung und der Bedienerführung dar, da sie ermöglicht, dass neue Funktionalität durch Mitteilungsübermittlung hinzugefügt werden kann.
Bei der Instantiierung wird das Objekt angewiesen, einen asynchronen Mitteilungsaustauschkanal mit einer Plattformkomponente oder Anwendung über seine Konfigurationsparameter oder Attributspezifikationen einzurichten. Es weist eine Stringeigenschaft auf, deren Inhalt jedes Mal an die Plattformkomponente oder die Anwendung gesendet wird, wenn die Eigenschaft der Empfänger einer Zuweisungsoperation (das heißt Ivalue) ist. Analog dazu weist es ebenfalls eine Eigenschaft einer Knotenart XML DOM auf, die die von der Plattformkomponente oder der Anwendung empfangene Mitteilung hält. Das Mitteilungsobjekt sendet jedes Mal ein Ereignis, wenn es eine Plattformnachricht empfängt. Da seine grundlegenden Operationen asynchron sind, weist das Objekt auch einen eingebauten Taktgeber auf, so dass die Anwendungsentwickler Zeitsperre-Einstellungen entsprechend manipulieren können.
Das Mitteilungsobjekt oder SMEX-Objekt ist agnostisch gegenüber den Kommunikationsvorrrichtungen. In einem Ausführungsbeispiel weist das SMEX-Objekt jedoch die gleiche Lebensdauer auf wie herkömmliche XML- oder Auszeichnungselemente, das heißt das SMEX-Objekt wird zerstört oder vernichtet, wenn sein Wirtsdokument entladen wird. Während das SMEX-Objekt in zahlreichen Fällen eine automatische Bereinigung durchführen kann und Kommunikationsressourcen freigeben kann, wenn es entladen wird, kann es Anwendungsfälle geben (wie zum Beispiel Anrufsteuerungen), in denen eine stabile Kommunikationsverbindung über Auszeichnungsseiten wünschenswert ist. Für solche Fälle delegiert die Architektur die Verantwortung für die Abgabe der zugewiesenen Ressourcen (zum Beispiel in der Nähe des Sockets) an die Anwendungsentwickler.
Das SMEX-Objekt ist neutral zu dem Format (Schema) von Mitteilungen und Nachrichten. In einigen Ausführungsbeispielen kann es wünschenswert sein, von den Implementierern zu fordern, dass einige rudimentäre Schemata unterstützt werden, mit starker Präferenz auf vorhandene Standardnachrichtenformate (wie sie zum Beispiel in SIP oder CCXML verwendet werden). Im Kern ermöglicht dies, dass sowohl die Plattform als auch die Anwendungsentwickler die Vorteile der standardisierten Erweiterungsfähigkeit von XML oder ähnlichen Auszeichnungssprachen umfassend ausnutzen können, um andere Merkmale einzuführen, ohne zwischenzeitlich Interoperabilität zu verlieren.
Beispiel 1: Nutzung von SMEX als Protokollierungsobjekt.
Dieses Beispiel zeigt, wie ein Protokollierungsmechanismus unter Verwendung eines COM-Objektes mit seiner Klasse-ID und seiner Schnittstellen-ID erzielt werden kann. Die Sprachentwickler hängen ein Attribut „log" an, das das Interessenniveau für Protokollierung für die jeweiligen SML-Knoten anzeigt. In dem obenstehenden Beispiel entscheidet sich der Anwendungsentwickler dafür, alle Knoten mit einem Protokollwert von größer als oder gleich 3 zu protokollieren, indem eine einzelne Zuweisungsanweisung verwendet wird. Das Beispiel funktioniert mit niederen und mit höheren Browsern.
Das Beispiel soll auch nachweisen, dass es möglich ist, dass eine Seite mehrere SMEX-Objekte enthalten kann, die mit der gleichen Plattformkomponente kommuniziert werden, solange es keine Verwechslung dazu gibt, welches SMEX-Objekt für die Rückgabe der Plattformnachrichten an das Erkennungsdokument verantwortlich ist. Das obenstehende Beispiel impliziert, dass eine Komponente mehrere Schnittstellen implementieren kann, von denen eine jede ihren eigenen SMEX- oder Nachrichtenkanal hat. Das gleiche Argument gilt für TCP-Server, die mehrere Ports abhören.
Beispiel 2: Lesen der Adressen für einen ankommenden Anruf:
Dieses Beispiel zeigt, wie die Belegungsanweisungen genutzt werden können, um die empfangene Nachricht zu verarbeiten. Das Beispiel geht von der Annahme aus, dass eine Nachricht für einen ankommenden Anruf die Unterelemente remote_addr, transfer_addr und local_addr enthält, deren Inhalte die Fernadresse, die Übertragungsadresse beziehungsweise die lokale Adresse des ankommenden Anrufes darstellen.
In diesem Beispiel wird ein verbindungsloses Protokoll auf Basis von HTTP verwendet, um mit dem Telephonieserver zu kommunizieren. Der Telephonieserver ist in diesem Beispiel ausgelegt, um mit mehr als einer Browserinstanz zu kommunizieren, und somit muss sich ein jeder Client selbst mit einer eindeutigen Kennnummer (ID) identifizieren, die von dem Server zugewiesen wird, wenn die Anwendung startet. Dies wird in diesem Beispiel erzielt, indem eine Nachricht „start_listening" an den Server gesendet wird. In diesem Beispiel wird die Sitzungs-Kennnummer (ID) in dem versteckten Feld gespeichert, das an den Webserver zurückgesendet werden kann und auf die nächste Seite der Anwendung weitergeleitet werden kann, wenngleich andere Verfahren (zum Beispiel clientseitiges Cookie) ebenfalls verwendet werden können, um den Sitzungszustand zu verwalten. Wie dies in dem Fall der Erkennung zutrifft, wird nicht jede Belegungsanweisung für eine jede Plattformnachricht ausgeführt. Das obenstehende Beispiel impliziert nicht, dass die eindeutige Kennnummer (ID) nur dann empfangen wird, wenn es sich um einen ankommenden Telefonanruf handelt.
7.1. Eigenschaften
Das SMEX-Objekt kann die folgenden Eigenschaften aufweisen, wobei nur die Lese/Schreib-Eigenschaften auch als Attribute für die Ausgangswert-Spezifikation dienen dürfen.

* sent:: Lesen/Schreiben, ein String, der der an die Plattformkomponente zu sendenden Nachricht entspricht. Wenn sent als L-Wert verwendet wird, werden seine Inhalte verschickt. Es besteht keine Wirkung, wenn die Eigenschaft als r-Wert verwendet wird oder wenn ein Nullobjekt dieser Eigenschaft zugewiesen wird.
* received:: Nur Lesen, XML-DOM-Knotendaten zur Anzeige der empfangenen Nachricht. Die Nachricht wird als r-Wert zur Verfügung stehen, bis das nächstfolgende Ereignis onReceive zum Senden bereit ist.
* timer:: Lesen/Schreiben, eine Anzahl in Millisekunden, die eine Zeitspanne anzeigt, bevor ein Zeitsperre-Ereignis ausgelöst werden wird. Das Zeitgeberelement startet, wenn der Eigenschaft ein positiver Wert zugewiesen wird. Der Wert kann geändert werden, wenn ein Rückwärtszählen abläuft. Ein Nullwert beziehungsweise ein negativer Wert hält den Zeitgeber an, ohne dass das Zeitsperre-Ereignis ausgelöst wird. Die Standardeinstellung ist 0, das heißt keine Zeitsperre.
* status:: Nur Lesen, eine ganze Zahl, die den aktuellen Status des Objektes anzeugt. Die möglichen Werte sind 0, –1 und –2, was bedeutet: normal, Zeit abgelaufen und Kommunikation mit der Plattform kann nicht hergestellt werden beziehungsweise ist unterbrochen worden. Plattformspezifische Fehlermeldungen sind über die empfangene Eigenschaft zu leiten. Für Fälle, in denen die Fehlermeldung erfolgreich übergeben wird, ist der Statuscode gleich 0.

7.2. Ereignisse
Das Objekt weist die folgenden Ereignisse auf:

* onReceive:: Dieses Ereignis wird gesendet, wenn eine Plattformnachricht angekommen ist. Wenn durch die Elemente bind Anweisungen deklariert worden sind, werden diese Anweisungen zuerst bewertet, bevor das Ereignis ausgelöst wird. Vor dem Senden wird die Eigenschaft received aktualisiert werden.
* onError:: Dieses Ereignis wird gesendet, wenn die Zeitsperre abläuft oder wenn ein Kommunikationsverbindungs-Fehler aufgetreten ist. Wenn das Ereignis gesendet wird, wird die Eigenschaft status mit dem entsprechenden Fehlercode wie oben beschrieben aktualisiert werden.

7.3. Child-Elemente
Wenn eine Elementform angenommen wird, kann SMEX die folgenden Child-Elemente aufweisen:

* bind:: Dies ist das gleiche wie in Erkennung (Reco), mit der Ausnahme, dass die Anweisungen an der empfangenen Nachricht betrieben werden.
* param:: Dies ist das gleiche wie bei Erkennung (Reco), stellt plattformspezifische Parameter für das SMEX-Objekt bereit. Ein jedes Element param kann unter Verwendung eines Attributes „name" benannt werden, wobei die Inhalte des Elementes param der Wert des Parameters sind. In einem Ausführungsbeispiel muss das Element Standard-XML-Attribute für Deklarationen des Namensraums und der XML-Datenart verstehen.

7.4. Sonstige Kommentare
Eine elegante Möglichkeit, SMEX für die Protokollierungsfunktion zu erweitern, wäre
Dies erweitert das Objekt um eine (globale) Funktion, deren Verhalten kundenspezifisch angepasst werden kann. In dem obenstehenden Beispiel ist die Protokollierungsfunktion programmiert, um ein Feld-Trennzeichen „I" zwischen der Kennnummer (ID) und der Nachricht einzufügen.
Wer keine globalen Funktionen mag, kann die Eigenschaft „prototype" von ECMA-Script verwenden, um die Funktion als eine Objekt-Methode anzuhängen. Zum Beispiel:
Man kann den Bezug zu de Funktion stärker objektorientiert gestalten:

LogServer.logMessage (RECO_LOG_ERROR, "My Message");
Es wird darauf verwiesen, dass weitere Arbeit von den Implementierern der SMEX-Objekte erforderlich ist, um die Erweiterung in dem oben genannten Beispiel funktionsfähig zu machen, wenngleich alle notwendigen Mechanismen bereits hinreichend etablierte Standards sind.

Claims

Computerlesbares Medium, das von einem Computer (204) lesbare Befehle enthält, die, wenn sie darauf ausgeführt werden, den Computer (204) veranlassen, Informationen zu verarbeiten, indem er Schritte ausführt, die umfassen: Empfangen von Daten über ein Fernnetzwerk (wide area network) (205), die Eingabe von einer Client-Vorrichtung anzeigen, sowie einer Anzeige einer Grammatik von der Client-Vorrichtung (30, 212), die mit den die Eingabe anzeigenden Daten zu verwenden ist, um Erkennung durchzuführen; Senden von Daten, die Erkennungsergebnisse für die die Eingabe anzeigenden Daten anzeigen, zu einer entfernten Position (30, 202, 212) in dem Fernnetzwerk (205); Empfangen von Daten, die eine Aufforderung für den Benutzer anzeigen, die zu verwenden ist, wenn die Erkennungsergebnisse keine Erkennung der Eingabe von dem Client (30, 212) anzeigen, von der entfernten Position (30, 202, 212); Umwandeln der Daten, die die Aufforderung anzeigen, in Sprachdaten, wenn die Erkennungsergebnisse keine Erkennung der Eingabe von dem Client (30, 212) anzeigen; und Senden der Sprachdaten zu der Client-Vorrichtung (30, 212) über das Fernnetzwerk (205).
Computerlesbares Medium nach Anspruch 1, wobei die Anzeige einen Verweis auf eine Position der Grammatik bereitstellt.
Computerlesbares Medium nach Anspruch 1, wobei die Anzeige einen Verweis auf eine Sprache zur Erkennung enthält.
Computerlesbares Medium nach Anspruch 1, wobei die Erkennungseinrichtung eine Spracherkennungseinrichtung umfasst und sich die Grammatik auf Spracherkennung bezieht.
Computerlesbares Medium nach Anspruch 1, wobei die Erkennungseinrichtung eine Handschrift-Erkennungseinrichtung umfasst und sich die Grammatik auf Handschrift-Erkennung bezieht.
Computerlesbares Medium nach Anspruch 1, wobei die Erkennungseinrichtung eine Gesture-Erkennungseinrichtung umfasst und sich die Grammatik auf Gesture-Erkennung bezieht.
Computerlesbares Medium nach Anspruch 1, wobei die Erkennungseinrichtung eine Sichterkennungseinrichtung umfasst und sich die Grammatik auf Sichterkennung bezieht.
Computerlesbares Medium nach Anspruch 1, wobei die entfernte Position (30, 202, 212) in dem Netzwerk (205) die Client-Vorrichtung (30, 212) ist.
Verfahren zur Spracherkennung in einem Client-Server-Netzwerk (205), wobei das Verfahren umfasst: Empfangen von Daten über ein Fernnetzwerk (205) von einer Client-Vorrichtung (30, 212), die eingegebene Sprache anzeigen, zusammen mit einer Anzeige einer Grammatik, die mit den Eingabe anzeigenden Daten zu verwenden ist, um Erkennung durchzuführen; Verarbeiten der Daten unter Verwendung der Grammatik mit einer Erkennungseinrichtung, um Erkennungsergebnisse zu gewinnen; und Senden der Erkennungsergebnisse für die die Eingabe anzeigenden Daten zu einer entfernten Position (30, 202, 212) in dem Netzwerk (205); Empfangen von Daten, die eine Aufforderung für den Benutzer anzeigen, die zu verwenden ist, wenn die Erkennungsergebnisse keine Erkennung der Eingabe von dem Client (30, 212) anzeigen, von der entfernten Position (30, 202, 212); Umwandeln der die Aufforderung anzeigenden Daten in Sprachdaten, wenn die Erkennungsergebnisse keine Erkennung der Eingabe von dem Client (30, 212) anzeigen; und Senden der Sprachdaten zu der Client-Vorrichtung (30, 212) über das Fernnetzwerk (205).
Verfahren nach Anspruch 9, wobei die Anzeige einen Verweis auf eine Position der Grammatik bereitstellt.
Verfahren nach Anspruch 9, wobei die Anzeige einen Verweis auf eine Sprache zur Erkennung enthält.
Verfahren nach Anspruch 9, wobei die entfernte Position (30, 202, 212) in dem Netzwerk (205) die Client-Vorrichtung (30, 212) ist.