распределенная речевая служба

Формула изобретения

1. Машиночитаемый носитель, на котором закодированы инструкции, которые при их исполнении компьютером предписывают компьютеру выполнять способ обеспечения речевых служб в компьютерной сети, включающий в себя этапы, на которых:

обеспечивают список множества кодеков и множества протоколов;

принимают информацию о выборе одного из множества кодеков в качестве установленного кодека и о выборе одного из множества протоколов в качестве установленного протокола, причем прием информации об установленном кодексе и установленном протоколе происходит за один обмен данными между клиентом и сервером в среде Web-служб, при этом упомянутый один обмен данными представляет усиление функциональных возможностей приложений связи посредством добавления расширения медиа-кодирования и транспортного протокола к стандарту языка описания Web-служб (WSDL), с тем чтобы как сигнальный канал, так и медиа-канал устанавливались за один шаг, причем среда Web-служб не является средой Протокола Инициирования Сеанса;

принимают сигнальную информацию через сигнальный канал согласно установленному протоколу передачи сигналов;

принимают речевую информацию через медиа-канал согласно установленному кодеку и установленному протоколу, причем медиа-канал прекращает функционирование по истечении заданного периода времени; и

обрабатывают сигнальную, информацию и речевую информацию.

2. Машиночитаемый носитель по п.1, в котором способ дополнительно включает в себя этап, на котором выполняют распознавание речи в отношении речевой информации.

3. Машиночитаемый носитель по п.1, при этом обработку сигнальной информации и речевой информации выполняют в среде Web-служб.

4. Машиночитаемый носитель по п.1, в котором способ дополнительно включает в себя этап, на котором обеспечивают интерфейс стандарта телекоммуникационных приложений с компьютерной поддержкой (CSTA).

5. Машиночитаемый носитель по п.1, в котором способ дополнительно включает в себя этап, на котором интерпретируют сообщение простого протокола доступа к объектам (SOAP).

6. Машиночитаемый носитель по п.1, в котором способ дополнительно включает в себя этап, на котором обрабатывают речевую информацию, чтобы идентифицировать семантическую информацию, содержащуюся в ней.

7. Машиночитаемый носитель по п.1, в котором способ дополнительно включает в себя этап, на котором передают информацию в заданный порт, связанный с адресом Интернет-протокола (IP).

8. Машиночитаемый носитель по п.1, в котором способ дополнительно включает в себя этап, на котором передают сообщение простого протокола доступа к объектам (SOAP).

9. Машиночитаемый носитель по п.1, при этом установленный кодек и установленный протокол получают в результате поиска по метаданным каждой из множества Web-служб.

10. Способ обработки информации при осуществлении связи между клиентом и сервером в компьютерной сети, содержащий этапы, на которых:

устанавливают взаимосвязь между клиентом и сервером в среде Web-служб, причем среда Web-служб не является средой Протокола Инициирования Сеанса, при этом при установлении осуществляют доступ к списку множества кодеков и множества протоколов и принимают информацию о выборе одного из множества кодеков в качестве установленного кодека и о выборе одного из множества протоколов в качестве установленного протокола, причем прием информации об установленном кодексе и установленном протоколе происходит за один обмен данными между клиентом и сервером, при этом упомянутый один обмен данными представляет усиление функциональных возможностей приложений связи посредством добавления расширения медиа-кодирования и транспортного протокола к стандарту языка описания Web-служб (WSDL), с тем чтобы как сигнальный канал, так и медиа-канал устанавливались за один шаг;

передают данные от клиента к серверу согласно установленному протоколу, причем данные содержат аудиоданные или текстовые данные;

преобразуют данные из аудиоданных в текстовые данные, если данные являются аудиоданными, и из текстовых данных в аудиоданные, если данные являются текстовыми данными; и

передают преобразованные данные от сервера к клиенту согласно установленному протоколу.

11. Способ по п.10, в котором установленный протокол основан на стандарте телекоммуникационных приложений с компьютерной поддержкой (CSTA).

12. Способ по п.10, в котором установленный кодек и установленный протокол получают в результате поиска по метаданным каждой из множества Web-служб.

13. Способ осуществления связи между клиентом и сервером, содержащий этапы, на которых:

выбирают адрес Интернет-протокола и порт, связанный с адресом Интернет-протокола, за один обмен данными между клиентом и сервером в среде Web-служб посредством расширения описания медиа-данных языка описания Web-служб (WSDL) или адресации Web-служб, при этом упомянутый один обмен данными представляет усиление функциональных возможностей приложений связи посредством добавления расширения медиа-кодирования и транспортного протокола к стандарту WSDL, с тем чтобы как сигнальный канал, так и медиа-канал устанавливались за один шаг;

устанавливают медиа-канал между клиентом и сервером на основе упомянутых адреса Интернет-протокола и порта;

устанавливают сигнальный канал между клиентом и сервером;

осуществляют обмен информацией между клиентом и сервером через медиа-канал в соответствии с упомянутыми адресом Интернет-протокола и портом и через сигнальный канал.

14. Способ по п.13, в котором упомянутая информация содержит речевую информацию.

15. Способ по п.14, в котором при обмене информацией принимают речевую информацию по медиа-каналу.

16. Способ по п.15, дополнительно содержащий этап, на котором обрабатывают речевую информацию, чтобы идентифицировать семантическую информацию, содержащуюся в ней.

17. Способ по п.13, в котором установленный протокол основан на стандарте телекоммуникационных приложений с компьютерной поддержкой (CSTA).

18. Способ по п.13, дополнительно содержащий этап, на котором интерпретируют сообщение простого протокола доступа к объектам (SOAP).

19. Способ по п.13, дополнительно содержащий этап, на котором передают сообщение простого протокола доступа к объектам (SOAP).

Описание изобретения к патенту

Настоящая заявка испрашивает приоритет по предварительной патентной заявке США серийный № 60/621303, зарегистрированной 22 октября 2004 г.

Область техники, к которой относится изобретение

Настоящее изобретение относится к способам и системам определения и управления взаимодействиями с компьютером. В частности, настоящее изобретение относится к способам и системам установления протоколов связи между устройствами в системе, такой как телекоммуникационная система.

Предшествующий уровень техники

Телекоммуникационные Приложения с Компьютерной Поддержкой (CSTA) являются широко принятым стандартным набором программ для глобальных и корпоративных коммуникаций. В частности, CSTA являются стандартом, который точно определяет программный доступ и управление телекоммуникационной инфраструктурой. Программное обеспечение может быть разработано для широкого разнообразия задач, варьирующихся от инициации и приема простых телефонных звонков до управления большим масштабом мультисайтовых совместных работ через голос и видео.

CSTA стандартизирован в ряде ECMA/ISO (ECMA International Rue du Rhone 114 CH-1204 Geneva, WWW.ecma-international.org) стандартов. Модель операции ядра и семантики объектов CSTA, служб и событий определены в ЕСМА-269. Эти признаки CSTA определены в реферате и платформе независимым путем, чтобы они могли быть адаптированы к разным программным платформам. Кроме того, CSTA сопровождается некоторым стандартизированным программным или протокольным синтаксисом, среди них ЕСМА-323, который определяет расширяемый язык разметки (XML), привязанный к CSTA, обычно известный как CSTA-XML, и ЕСМА-348, привязанный к Языку Описания Web-служб (WSDL). Эти связки языков, рассмотренных как часть стандартного набора программ CSTA, обеспечивают максимальную функциональную совместимость, делающую признаки CSTA доступными компьютерам, работающим в разных операционных системах через любые стандартные транспортные протоколы, включая Протокол Управления Передачей (TCP), Протокол Инициирования Сеанса (SIP) или Простой Протокол Доступа к Объектам (SOAP).

Недавно CSTA утвердил выбор в области интерактивных голосовых служб. Этот выбор был усовершенствован улучшенными голосовыми службами, основанными на Тэгах Языка Речевого Приложения (SALT), которые далее описаны в Спецификации SALT 1.0, найденной по адресу www.saltforum.org. Используя SALT, центры обработки звонков могут далее быть автоматизированы, чтобы включать в себя различные относящиеся к речи признаки. Однако отличия в приложениях управления звонком и управления речью создают трудности в продвижении распределенных речевых служб. Таким образом, существует необходимость протоколов установления в продвижении речевых служб.

Раскрытие изобретения

Настоящее изобретение относится к установлению медиа-канала и канала передачи сигналов между клиентом и сервером. Медиа-канал использует выбранный кодек и протокол для связи. Через медиа-канал и канал передачи сигналов приложение на клиентской стороне может использовать речевые службы на сервере.

Краткое описание чертежей

Фиг.1-4 иллюстрируют примерные вычислительные устройства для использования с настоящим изобретением.

Фиг.5 иллюстрирует примерную архитектуру для распределенных речевых служб.

Фиг.6 иллюстрирует примерную систему для выполнения распределенных речевых служб.

Фиг.7 иллюстрирует примерный способ установления каналов в SIP-окружении.

Фиг.8 иллюстрирует примерный способ установления каналов в окружении Web-служб.

Осуществление изобретения

Перед описанием архитектуры для распределенных речевых служб и способов их выполнения может быть полезным описать в целом вычислительные устройства, которые могут функционировать в архитектуре. Обращаясь теперь к фиг.1, примерная форма устройства управления данными (PIM, PDA или подобное) обозначена позицией 30. Однако предполагается, что настоящее изобретение может также быть применено, используя другие вычислительные устройства, обсужденные ниже, и, в частности, те вычислительные устройства, которые имеют ограниченные площади поверхности для кнопок ввода или подобных. Например, телефоны и/или устройства управления данными также извлекут пользу из настоящего изобретения. Такие устройства будут иметь улучшенную полезность по сравнению с существующими переносными персональными устройствами управления информацией и другими переносными электронными устройствами, а функции и компактный размер таких устройств будет более вероятно поощрять пользователя носить устройство все время. Соответственно, не имеется в виду, что цель архитектуры, описанной здесь, будет ограничена раскрытием примерного управления данными или PIM-устройства, телефона или компьютера, иллюстрированного здесь.

Примерная форма мобильного устройства 30 управления данными иллюстрирована на фиг.1. Мобильное устройство 30 включает в себя корпус 32 и имеет пользовательский интерфейс, включающий в себя дисплей 34, которые использует контактно-чувствительный экран дисплея в соединении с пером 33. Перо 33 используется, чтобы нажимать или соприкасаться с дисплеем 34 в определенных координатах, чтобы выбрать область, выборочно переместить начальную позицию курсора или иным образом предоставить информацию о команде, типа через движения пера или почерк. Альтернативно или в дополнение одна или более кнопок 35 могут быть включены в устройство 30 для навигации. Кроме того, другие механизмы ввода, типа колесиков прокрутки, роликов и т.п., могут также быть предусмотрены. Однако нужно заметить, что изобретение не имеет в виду ограничение этими формами механизмов ввода. Например, другая форма ввода может включать в себя визуальный ввод, например через машинное зрение.

Обращаясь теперь к фиг.2, блок-схема иллюстрирует функциональные компоненты, содержащие мобильное устройство 30. Центральное процессорное устройство (CPU) 50 выполняет программные функции управления. CPU 50 соединено с дисплеем 34 так, что текстовые и графические значки, сгенерированные в соответствии с программным обеспечением управления, показываются на дисплее 34. Динамик 43 может быть соединен с CPU 50 типично с цифроаналоговым преобразователем 59, чтобы обеспечить звуковой вывод. Данные, которые загружены или введены пользователем в мобильное устройство 30, сохраняются в энергонезависимом открытым по чтению/записи оперативном запоминающем устройстве 54, двунаправлено соединенном с CPU 50. Оперативное запоминающее устройство (RAM) 54 обеспечивает энергозависимое хранение инструкций, которые выполняются CPU 50, и хранение временных данных, таких как значения регистров. Значения по умолчанию для вариантов конфигурации и другие переменные сохраняются в постоянном запоминающем устройстве (ROM) 58. ROM 58 может также быть использовано, чтобы хранить программное обеспечение операционной системы для устройства, которое управляет основной функциональностью мобильного устройства 30 и другими функциями ядра операционной системы (например, загрузка компонентов программного обеспечения в RAM 54).

RAM 54 также служит, как хранилище для кода аналогичным образом, для функционирования привода жесткого диска на PC, который используется, чтобы хранить прикладные программы. Нужно запомнить, что хотя энергонезависимая память используется для хранения кода, он альтернативно может быть сохранен в энергозависимой памяти, которая не используется для выполнения кода.

Радиосигналы могут быть переданы/приняты мобильным устройством через радиоприемопередатчик 52, который соединен с CPU 50. Необязательный интерфейс 60 связи может также быть предусмотрен для загрузки данных непосредственно из компьютера (например, настольного компьютера) или из проводной сети, если требуется. Соответственно, интерфейс 60 может содержать разные формы устройств связи, например инфракрасную связь, модем, сетевую карту и т.п.

Мобильное устройство 30 включает в себя микрофон 29, аналого-цифровой (A/D) преобразователь 37 и необязательную программу распознавания (речи, DTMF, почерка, знака или компьютерного зрения), сохраненную в памяти 54. В качестве примера, в ответ на звуковую информацию, инструкции или команды от пользователя устройства 30 микрофон 29 предоставляет речевые сигналы, которые оцифровываются A/D-преобразователем 37. Программа распознавания речи может выполнить нормализацию и/или характерные функции извлечения на оцифрованных речевых сигналах, чтобы получить промежуточные результаты распознавания речи.

Используя радиоприемопередатчик 52 или интерфейс 60 связи, речевые данные передаются удаленному речевому серверу 204, обсужденному ниже и иллюстрированному в архитектуре фиг.5. Результаты распознавания затем возвращаются мобильному устройству 30 для воспроизведения (например, визуального и/или звукового) на нем и возможной передачи Web-серверу 202 (фиг.5), где Web-сервер 202 и мобильное устройство 30 работают в отношении клиент/сервер.

Подобная обработка может быть использована для других форм ввода. Например, ввод почерком может быть оцифрован с или без предварительной обработки на устройстве 30. Подобно речевым данным эта форма ввода может быть передана речевому серверу 204 для распознавания, где результаты распознавания возвращаются по меньшей мере одному устройству 30 и/или Web-серверу 202. Также данные DTMF, знаковые данные и визуальные данные могут быть обработаны подобным образом. В зависимости от формы ввода устройство 30 (и другие формы клиентов, обсуждаемых ниже) будет включать в себя необходимое аппаратное средство, типа камеры для визуального ввода.

Фиг.3 это вид в плане примерного варианта осуществления переносного телефона 80. Телефон 80 включает в себя дисплей 82 и клавиатуру 84. Вообще блок-схема фиг.2 применяется к телефону из фиг.3, хотя может потребоваться дополнительная схема, необходимая, чтобы выполнить другие функции. Например, приемопередатчик, необходимый, чтобы работать как телефон, потребуется для варианта осуществления из фиг.2; однако такая схема не подходит настоящему изобретению.

В дополнение к переносным или мобильным вычислительным устройствам, описанным ниже, также нужно понимать, что настоящее изобретение может быть использовано с рядом других вычислительных устройств, таких как обычный настольный компьютер. Например, настоящее изобретение позволит пользователю с ограниченными физическими возможностями вводить или вносить текст в компьютер или другое вычислительное устройство, когда другие традиционные устройства ввода, такие как полная алфавитно-цифровая клавиатура, являются слишком тяжелыми, чтобы работать.

Изобретение является также работоспособным с многочисленными другими вычислительными системами общего или специального назначения, окружениями или конфигурациями. Примеры хорошо известных вычислительных систем и/или конфигураций, которые могут быть подходящими для использования с изобретением, включают в себя (но не только) обычные телефоны (без какого-либо экрана), персональные компьютеры, серверы, «карманные» компьютеры или дорожные компьютеры, многопроцессорные системы, системы на базе микропроцессоров, стойки высокопроизводительных установок, программируемую бытовую электронную аппаратуру, устройства радиочастотной идентификации (RFID), сетевые ПК, миникомпьютеры, мейнфреймы, распределенные вычислительные окружения, которые содержат любые из вышеуказанных систем и устройств, и т.п.

Дальнейшее является кратким описанием компьютера 120 общего назначения, иллюстрированного на фиг.4. Однако компьютер 120 снова является только одним примером соответствующей вычислительной среды и не предназначен предлагать любые ограничения на цель использования или на функциональность изобретения. Компьютер 120 ни при каких условиях не должен трактоваться как имеющий какую-либо зависимость или требование, связанное с каким-либо одним или сочетанием компонентов, иллюстрированных здесь.

Изобретение может быть описано в общем контексте машиноисполняемых инструкций, таких как программные модули, являющиеся исполняемыми компьютером. Программные модули в общем случае включают в себя алгоритмы, программы, объекты, компоненты, структуры данных и т.д., которые выполняют отдельные задачи или реализуют отдельные абстрактные типы данных. Изобретение может также быть реализовано на практике в распределенных вычислительных окружениях, в которых задачи выполняются удаленными обрабатывающими устройствами, которые связаны через сеть связи. В распределенном вычислительном окружении программные модули могут быть расположены в носителе хранения и локального, и удаленного компьютера, включающем в себя запоминающие устройства памяти. Задачи, выполняемые программами и модулями, описаны ниже и с помощью чертежей. Специалисты в области техники могут реализовать описание и чертежи, как процессор выполняемых инструкций, которые могут быть записаны на любой форме компьютерного читаемого носителя.

Со ссылкой к фиг.4 компоненты компьютера 120 могут включать в себя, но не только, процессорный модуль 140, системную память 150 и системную шину 141, которая соединяет различные компоненты системы, включая системную память, с процессорным модулем 140. Системная шина 141 может быть любой из нескольких типов структур шины, включающих в себя шину памяти или контроллер памяти, периферийную шину и локальную шину, используя любую из ряда архитектур шины. В качестве примера, а не ограничения, такие архитектуры включают в себя шину с Промышленной Стандартной Архитектурой (ISA), Универсальную Последовательную Шину (USB), шину с Микро Канальной Архитектурой (МСА), шину с Улучшенной ISA (EISA), локальную шину Ассоциации Видео Электронных Стандартов (VESA) и шину межсоединений периферийных компонентов (PCI), также известную как шина Mezzanine. Компьютер 120 типично включает в себя ряд компьютерных читаемых носителей. Компьютерные читаемые носители могут быть любым доступным носителем, к которому может быть доступ компьютеру 120, и включает в себя и энергозависимый, и энергонезависимый носитель, сменный и несменный носитель. В качестве примера, а не ограничения, компьютерные считываемые носители могут содержать компьютерный носитель хранения данных и носитель передачи данных. Компьютерный носитель хранения включает в себя энергозависимый и энергонезависимый, сменный и несменный носитель, реализованный по любому способу или технологии хранения такой информации, как компьютерночитаемые инструкции, структуры данных, программные модули и другие данные. Компьютерный носитель хранения данных включает в себя (но не только) RAM, ROM, EEPROM, флэш-память или другую технологию памяти, CD-ROM, универсальные цифровые диски (DVD) или другие оптические диски, магнитные кассеты, магнитные ленты, магнитные диски или другие магнитные устройства хранения, либо любой другой носитель, который можно использовать для хранения нужной информации и к которому можно обращаться с помощью компьютера 120.

Носитель передачи данных в типичном варианте содержит машиночитаемые инструкции, структуры данных, программные модули или другие данные в модулированном информационном сигнале, таком как несущее колебание или другой механизм распространения, и включает в себя любой носитель для доставки информации. Термин "модулированный информационный сигнал" означает сигнал, который обладает одной или несколькими характеристиками, заданными или измененными таким способом, как кодирование информации в сигнале. Для примера, но не в качестве ограничения, носитель передачи данных включает в себя проводной носитель, такой как проводная сеть или непосредственное проводное соединение, и беспроводной носитель, такой как акустическая среда, радиочастота, инфракрасное излучение и другая беспроводная среда. Сочетания любого из вышеперечисленного также следует включить в число машиночитаемого носителя.

Системная память 150 включает в себя компьютерную среду хранения в виде энергозависимой и/или энергонезависимой памяти, такой как постоянное запоминающее устройство 151 (ROM) и оперативное запоминающее устройство 152 (RAM). Базовая система 153 ввода/вывода (BIOS), содержащая в себе базовые процедуры, которые помогают передавать информацию между элементами в пределах компьютера 120, например, во время запуска, типично сохранена в ROM 151. RAM 152 типично содержит в себе данные и/или программные модули, которые непосредственно доступны и/или являются собственно выполняемыми блоком 140 обработки. В качестве примера, но не ограничения, фиг.4 иллюстрирует операционную систему 154, прикладные программы 155, другие программные модули 156 и программные данные 157.

Компьютер 120 может также включать в себя другой съемный/стационарный, энергозависимый/энергонезависимый компьютерный носитель хранения. Только в качестве примера фиг.4 иллюстрирует накопитель 161 на жестком диске, который считывает из или записывает на стационарный энергонезависимый магнитный носитель, накопитель 171 на магнитных дисках, который считывает из или записывает на съемный энергонезависимый магнитный диск 172, и накопитель 175 на оптических дисках, который считывает с или записывает на съемный энергонезависимый оптический диск 176, такой как CD-ROM, или другой оптический носитель. Другие сменные/стационарные, энергозависимые/энергонезависимые компьютерные носители хранения данных, которые могут использоваться в типичной операционной среде, включают в себя (но не только) кассеты на магнитных лентах, карты флэш-памяти, универсальные цифровые диски, цифровые видеоленты, полупроводниковую RAM, полупроводниковую ROM и т.п. Накопитель 161 на жестких дисках типично подключен к системной шине 141 посредством интерфейса стационарного запоминающего устройства, такого как интерфейс 160, а накопитель 171 на магнитных дисках и накопитель 175 на оптических дисках типично подключены к системной шине 141 посредством интерфейса съемного запоминающего устройства, таким как интерфейс 170.

Накопители и ассоциативно связанный с ним компьютерный носитель хранения, обсужденные выше и проиллюстрированные на фиг.4, обеспечивают хранение машиночитаемых инструкций, структур данных, программных модулей, и других данных для компьютера 120. На фиг.4, например, накопитель 161 на жестких дисках проиллюстрирован в качестве сохраняющего операционную систему 164, прикладные программы 165, другие программные модули 166 и программные данные 167. Заметим, что эти компоненты могут либо быть такими же как, или отличными от операционной системы 154, прикладных программ 155, других программных модулей 156 и программных данных 157. Операционная система 164, прикладные программы 165, другие программные модули 166 и программные данные 167 даны здесь с разными номерами, чтобы проиллюстрировать, что, как минимум, они являются различными копиями.

Пользователь может вводить команды и информацию в компьютер 120 посредством устройств ввода, например клавиатуры 182, микрофона 183 и указательного устройства 181, такого как мышь, трекбол или сенсорная панель. Другие устройства ввода (не показаны) могут включать в себя джойстик, игровую панель, спутниковую антенну, сканер и т.п. Эти и другие устройства ввода часто присоединены к блоку 140 обработки через интерфейс 180 пользовательского ввода, который присоединен к системной шине, но может быть присоединен другим интерфейсом и шинными структурами, такими как параллельный порт, игровой порт или универсальная последовательная шина (USB). Монитор 184 или другой тип дисплейного устройства также подключен к системной шине 141 посредством такого интерфейса, как видеоинтерфейс 185. Помимо монитора, компьютеры могут также включать в себя другие периферийные устройства вывода, например, динамики 187 и принтер 186, которые могут быть подключены средствами периферийного интерфейса 188 вывода.

Компьютер 120 может работать в объединенном в сеть окружении, использующем логические соединения с одной или более удаленными компьютерами, таким как удаленный компьютер 194. Удаленный компьютер 194 может быть персональным компьютером, карманным устройством, сервером, маршрутизатором, сетевой ПК, одноранговым устройством или другим общим узлом сети и типично включает в себя многие или все элементы, описанные выше относительно компьютера 120. Логические соединения, показанные на фиг.4, включают в себя локальную вычислительную сеть (LAN) 191 и глобальную сеть (WAN) 193, но могут также включать в себя другие сети. Такие сетевые среды имеют место в офисах, корпоративных вычислительных сетях, интрасетях и в Интернете.

Когда использован в сетевом окружении LAN, компьютер 120 подключен к LAN 191 посредством сетевого интерфейса или адаптера 190. Когда использован в сетевом окружении WAN, компьютер 120 типично включает в себя модем 192 или другое средство установления связей по WAN 193, такой как Интернет. Модем 192, который может быть внутренним или внешним, может быть подключен к системной шине 141 через пользовательский интерфейс 180 ввода, или другой подходящий механизм. В сетевой среде программные модули, изображенные по отношению к компьютеру 120, или их части могут храниться на удаленном устройстве хранения данных. В качестве примера, а не ограничения, фиг.4 иллюстрирует удаленные прикладные программы 195 как хранящиеся на удаленном компьютере 194. Должно быть очевидно, что показанные сетевые соединения являются примерными, и может быть использовано другое средство установления линий связи между компьютерами.

Фиг.5 иллюстрирует примерную архитектуру 200 для распределенных речевых служб, которая может быть реализована в настоящем изобретении. Как правило, к информации, сохраненной в Web-сервере 202, можно обращаться через мобильное устройство 30 (которое здесь также представляет другие формы вычислительных устройств, имеющих экран дисплея, микрофон, камеру, сенсорную панель и т.д., как требуемых, основанных на форме ввода), или через телефон 80, в котором информация запрашивается голосом или через тоны, сгенерированные телефоном 80 в ответ на нажатые кнопки, и где информация от Web-сервера 202 предоставляется только звуковым образом назад пользователю.

Тем не менее, более важно, что архитектура 200 унифицирована в том, что получена ли информация через устройство 30 или через телефон 80, использующий распознавание речи, отдельный речевой сервер 204 может поддерживать любой режим работы. Кроме того архитектура 200 работает, используя расширение хорошо известных языков разметки (например, HTML, XHTML, cHTML, XML, WML и т.п.). Таким образом, к информации, сохраненной на Web-сервере 202, можно обратиться, используя хорошо известные GUI-способы, основанные на этих языках разметки. Используя расширение хорошо известных языков разметки, создание страниц на Web-сервере 202 является более легким, а уже существующие унаследованные приложения могут быть также легко модифицированы, чтобы включить в себя распознавание голоса.

Как правило, устройство 30 выполняет HTML+ скрипты или подобные, предоставленные Web-сервером 202.

Когда требуется распознавание голоса, в качестве примера, речевые данные, которые могут быть оцифрованными аудиосигналами, или речевые признаки, в которых аудиосигналы предварительно обработаны устройством 30, как описано выше, предоставляются речевому серверу 204 с указанием грамматики или модели языка, чтобы использовать их во время распознавания речи. Осуществление речевого сервера 204 может быть сделано многими формами, одна из которых иллюстрирована, но как правило включает в себя устройство распознавания 211. Результаты распознавания предоставляются назад устройству 30 для локального воспроизведения, если желательные или подходящие. После компиляции информации посредством распознавания и любого графического пользовательского интерфейса, если используется, устройство 30 отправляет информацию Web-серверу 202 для дальнейшей обработки и принимает дальнейшие HTML скрипты, если необходимо.

Как показано на фиг.5, устройство 30, Web-сервер 202 и речевой сервер 204 обычно связаны и имеют отдельные адреса посредством сети 205, здесь глобальной сетью типа Интернет. Поэтому нет необходимости в том, что любое из этих устройств должно быть физически расположено по соседству друг с другом. В частности, нет необходимости в том, что Web-сервер 202 включает в себя речевой сервер 204. В таком способе создание страниц на Web-сервере 202 может быть сосредоточено на приложении, для которого это предназначено, без необходимости авторов, чтобы знать сложности речевого сервера 204. Скорее речевой сервер 204 может быть независимо сконструирован и соединен в сеть 205 и таким образом обновляться и улучшаться без дальнейших изменений, требуемых для сервера 202. В дальнейшем варианте осуществления клиент 30 может непосредственно связываться с речевым сервером 204, без необходимости в Web-сервере 202. В дальнейшем будет понятно, что Web-сервер 202, речевой сервер 204 и клиент 30 могут быть объединены в зависимости от возможностей выполняющих машин. Например, если клиент содержит компьютер общего назначения, например персональный компьютер, клиент может включать в себя речевой сервер 204. Подобно, если желаемо, Web-сервер 202 и речевой сервер 204 могут быть объединены в одну машину.

Доступ к Web-серверу 202 через телефон 80 включает в себя соединение телефона 80 с проводной или беспроводной телефонной сетью 208, которая, в свою очередь, соединяет телефон 80 с шлюзом 210 третьей стороны. Шлюз 210 соединяет телефон 80 с браузером 212 телефонной связи. Браузер 212 телефонной связи включает в себя медиа-сервер 214, который обеспечивает интерфейс телефонии и голосового браузера 216. Подобно устройству 30, браузер 212 телефонной связи принимает HTML-скрипты или подобные от Web-сервера 202. Тем не менее более важно, что HTML-скрипты похожи по форме на HTML-скрипты, предоставленные устройством 30. В этом способе Web-серверу 202 не нужно поддерживать устройство 30 и телефон 80 отдельно или даже поддерживать стандартных GUI-клиентов отдельно. Скорее может быть использован общий язык разметки. Кроме того, подобно устройству 30 распознавание голоса из звуковых сигналов, переданных телефоном 80, предоставляется из голосового браузера 216 речевому серверу 204 или через сеть 205, или через выделенный канал 207, например, используя TCP/IP. Web-сервер 202, речевой сервер 204 и браузер 212 телефонной связи могут быть реализованы в любой подходящей вычислительной среде, такой как настольный компьютер общего назначения, иллюстрированный на фиг.4.

Однако нужно запомнить, что, если применяется DTMF-распознавание, эта форма распознавания, как правило, может быть выполнена в медиа-сервере 214 предпочтительнее, чем в речевом сервере 204. Другими словами DTMF-грамматика будет использована медиа-сервером.

Данные устройства и архитектура, описанная выше, настоящее изобретение далее будет описано, основываясь на простой среде клиент/сервер. Как показано на фиг.6, настоящее изобретение имеет отношение к системе 300, содержащей сервер 302, который обеспечивает медиа-службы (например, распознавание речи или преобразование текста в речь) и клиента 304, которые выполняют специализированные коды приложения. Соединение между сервером 302 и клиентом 304 основано на модели службы, где информация может быть обменена или тегирована или другим образом включать в себя идентифицированные части, такие как, но не только, XML (Расширенный Язык Разметки) документы. Сервер 302 и/или клиент 304 могут собирать и передавать звук в дополнение к другой информации. В одном варианте осуществления сервер 302 может содержать Microsoft Speeh Server, разработанный корпорацией Microsoft Corporation г.Редмонд, штат Вашингтон, тогда как клиент 304 может принимать любое число форм, как обсуждено выше, включая в себя, но не ограничиваясь этим, настольные ПК, мобильные устройства и т.д.

В этом месте должно быть отмечено, что хотя связь друг с другом сервера 302 и клиента 304 основана на модели службы, приложение, вызывающее аспекты настоящего изобретения, не должно быть написано исключительно основанным на модели службы, в которой приложения основанные на описателях и/или процедурно основанные приложения могут использоваться пока соединение между сервером 302 и клиентом 304 выполняется в соответствии с запросами модели службы. В одном варианте осуществления клиентское приложение может быть сформировано на C++, Java, C# или других императивных языках программирования, которые не требуют браузера как в случае приложений, основанных на HTML, описанных на фиг.5.

Важным аспектом CSTA (ЕСМА-269) в ред.6 являются расширенные голосовые службы, основанные на Тегах Языка Речевого Приложения (SALT). Недавно добавленные признаки включают в себя автоматическое распознавание речи, проверку речи, подлинность говорящего, проверку говорящего и преобразование текста в речь, которые могут быть выполнены в системе 300. Некоторые или все из этих признаков предусмотрены в автоматических центрах обработки звонков. Аспекты настоящего изобретения предусматривают подмножество служб CSTA для облегчения сетевых речевых служб. В частности, некоторые аспекты настоящего изобретения иллюстрируют как ЕСМА-348 и uaCSTA (ECMA-TR/87) могут быть применены, чтобы облегчить распределенные речевые службы в Web-службе и основанной на SIP (Протокол Инициирования Сеанса) VoIP (Протокол для передачи голоса по Интернету) среде, соответственно.

Службы для телекоммуникационных приложений с компьютерной поддержкой (CSTA) ЕСМА-269 и их протоколы XML и Web-службы определены ЕСМА-323 и ЕСМА-348, соответственно. Недавно ECMA-TR/87 (uaCSTA) добавочно описывает набор условных обозначений SIP для использования ЕСМА-323 в VoIP среде. Все эти протоколы в принципе адресуют полный набор CSTA и, следовательно, применимы к голосовым службам в отдельности. В 6-й редакции ЕСМА-269 прибавлена часть голосовых служб CSTA, основанных на технологии, полученной из SALT. В дополнение к существующим голосовым службам новое дополнение включает в себя ключевые признаки, которые существенны для автоматизации центров обработки звонков и мобильных приложений, включающих автоматическое распознавание речи, проверку речи, идентификацию говорящего, проверку говорящего и преобразование текста в речь и т.д.

Хотя тесно объединенные осуществления CSTA управления телефонным трафиком и голосовые сценарии желательны разработчикам приложения, основные способности между управлением телефонным трафиком и поставщиками связи необязательно те же самые. Для текущего развертывания и в обозримом будущем разработчики CSTA-приложения могут нуждаться в том, чтобы вовлечь многих поставщиков, чтобы удовлетворить их соответствующие потребности в этих областях. К счастью, концепция построения модели CSTA, как описано в ЕСМА-269, позволяет одному приложению извлекать службы из нескольких поставщиков служб CSTA. Поэтому это правильный сценарий, где CSTA-приложение будет одновременно использовать два выполнения CSTA, одно для управления телефонным трафиком, а другое для голосовых служб.

Профили CSTA для речевых служб не являются усовершенствованными и в области управления телефонным трафиком. Аспекты настоящего изобретения описывают профиль CSTA для обеспечения речевых служб в платформо-независимом средстве, использующем XML. Хотя профиль CSTA является транспортом, который является агностическим по природе, два общих применения профиля речевой службы служат примером здесь, чтобы лучше способствовать сквозной функциональной совместимости: SIP-среда, основанная на небольшом использовании CSTA, и основанная на Web-службе среда, основанная на ЕСМА-348.

Описание, предоставленное здесь, предоставляет примеры того, как подмножества CSTA Голосовых Служб могут быть включены в облегчение основанной на архитектуре клиент-сервер обработки речи. Следующие Стандарты ЕСМА объединены здесь ссылкой на их полноту: ЕСМА-269 Службы для Телекоммуникационных Приложений с Компьютерной Поддержкой (CSTA) Фаза III; ECMA-323, SMLP Протокол для Телекоммуникационных Приложений с Компьютерной Поддержкой (CSTA) Фаза III; и ЕСМА-348 Язык Описания Web-служб (WSDL) для CSTA. Кроме того, это приложение описывает, как Речевые Службы CSTA могут быть осуществлены в SIP-основанной VoIP среде, используя предложение uaCSTA. ECMA-TR/87 будет использован как ссылка для uaCSTA, копия которого встроена здесь по ссылке.

Основанная на архитектуре клиент-сервер обработка речи, описанная здесь, способна управлять асимметричными типами медиа-данных в цикле ответ/запрос. Например, в случае службы распознавания речи клиент передает аудиоданные серверу. Сервер преобразует аудиоданные в текстовые данные и передает преобразованные данные назад клиенту. В случае синтезирования речи клиент передает текстовые данные, а сервер отвечает преобразованными аудиоданными. Переданные данные могут быть отправлены согласно определенному протоколу, основанному на CSTA. В результате среда SIP и Web-служб может быть расширена, чтобы включить в себя текст-аудио или аудио-текст аудио-в-аудио взаимодействия.

ЕСМА TR/87 устанавливает транспортный протокол «канала передачи служебных сигналов» 308, как иллюстрировано на фиг.6. Канал 308 передачи служебных сигналов используется сервером 302 и клиентом 304, чтобы обмениваться информацией о том, что каждый будет делать, когда это имеет отношение к средствам управления телефонным трафиком. Когда сервер 302 содержит телефонный коммутатор, использование канала 308 передачи служебных сигналов является достаточным. Однако если сервер 304 является речевым сервером, а клиент 304 запрашивает речевую службу, сервер 302 будет также знать, куда принять и передать речевую информацию. Например, сервер 302 будет знать, где получить информацию распознавания речи и куда отправить синтезированную речь.

Поэтому в дополнение к установлению канала 308 передачи служебных сигналов также может быть установлен протокол "медиа-канала" 310. Например, медиа-канал 310 используется для переноса речевых данных (аудиоданных), собранных клиентом 304 к серверу 302. Более того, в операции текст-в-речь, клиент 304 может отправить текстовые данные через канал 308 передачи служебных сигналов в то время, как синтезированные речевые данные передаются назад клиенту 304 от сервера 302 через медиа-канал 310.

Что касается архитектуры на фиг.5, канал 308 передачи служебных сигналов и медиа-канал 310 устанавливаются для любого подключения к речевому серверу 204. Однако нужно отметить, что использование сервера 202 Web-приложений является необязательным и что приложение может постоянно храниться на клиенте 30, как иллюстрировано на фиг.5.

Один аспект настоящего изобретения - это какие шаги сделаны, чтобы осуществить медиа-канал 310. В одном примерном варианте осуществления обсуждается установление медиа-канала 310 для CSTA в SIP-среде. В дальнейшем примерном варианте осуществления обсуждается, какие шаги сделаны, чтобы реализовать медиа-канал 310 для CSTA в среде, основанной на Web-службе.

Стоит отметить, что семантическая информация может быть передана между сервером 302 и клиентом 304, например, используя Язык Описания Речевого Приложения (SADL), который может определить XML-схему для результатов, возвращенных ресурсом слушателя, т.е. результатов, возвращенных сервером 302 с распознаванием речи.

СОЗДАНИЕ КАНАЛОВ В SIP-СРЕДЕ

SIP является протоколом, который предназначен быть «болтливым», таким, что сервер 302 и клиент 304 часто обмениваются маленькими частями информации. В SIP-среде создание медиа-канала 310 выполняется через Протокол Описания Сеанса (SDP). Примерный способ 400 выполнения этой задачи иллюстрирован на фиг.7.

Этап 402, клиент 304 инициирует сеанс с сервером 302, используя SIP-приглашение. SDP-описание также отправляется, которое объявляет IP (Протокол Интернета) адрес, который должен быть использован и порт по IP-адресу, который должен быть использован для аудио. Кроме того, на этапе 404 SDP-описание объявит, какой тип кодека для кодирования используется для медиа-потока и протокол связи, такой как протокол управления передачей (TCP) или транспортный протокол реального времени (RTP).

После приема сервером сервер может решать, принимать ли SDP-описание, установленное клиентом 304, на этапе 406. Если протокол и кодек принимаются, сервер 302 отвечает статусом SIP-okay и собственным SDP-описанием, перечисляющим его IP-адрес и аудио порт. Затем способ 400 переходит к этапу 408, где устанавливается канал передачи служебных сигналов.

В альтернативном варианте, если сервер 302 не поддерживает предложенный кодек или протокол, сервер 302 может обсудить с клиентом 304, какой кодек и/или протокол будет использоваться. Другими словами, сервер 302 ответит клиенту 304 начальным SDP-описанием со встречным предложением, предлагающим другой кодек и/или протокол. Перед созданием предложения способ 400 переходит к этапу 410, где делается определение, продолжать ли распознавание. Например, на этапе 412 после определенного числа представленных встречных предложений, соединение будет остановлено. Дополнительные встречные предложения могут быть сделаны между клиентом 304 и сервером 302 на этапе 414 до тех пор, пока соглашение не будет достигнуто или до тех пор, когда станет ясно, что соглашение не будет достигнуто.

SIP/SDP это стандарт, одобренный Инженерной Проблемной Группой Интернет (IETF), который используется для того, чтобы установить аудиоканал в телефонии на базе IP. Однако SIP/SDP не описывает способ установления канала передачи сигналов, осуществляющего CSTA. На этапе 408 канал 308 передачи сигналов устанавливается посредством ECMA-TR/87. После создания канала передачи сигналов приложение соединения считается законченным. В результате распределенные речевые службы могут быть выполнены в системе 300.

СОЗДАНИЕ КАНАЛОВ В СРЕДЕ WEB-СЛУЖБ

В противоположность «болтливой» природе SIP, описанной выше, Web-службы разработаны и часто оптимизированы для «содержащих кусочки» соединений так, что необходимо меньше обменов диалогами между сервером 302 и клиентом 304. В результате признаки, которые обсуждаются в многочисленных диалоговых оборотах в SIP, обычно описываются и раскрываются через описания службы, опубликованные в публичных каталогах для Web-служб или получаются динамически в обмене метаданными Web-служб. Среда Web-служб включает в себя UDDI (Интеграция Раскрытия Единообразного Описания) стандартный протокол. Провайдеры Web-служб публикуют соответствующую информацию, которую разработчики приложения могут обнаружить, получить и, таким образом, выбрать подходящего провайдера службы, который позволит разработчикам приложения динамически интегрировать Web-службу в приложение. Например, ЕСМА-348 определяет Язык Описания Web-служб (WDSL) для CSTA так, что Web-службы, предлагающие функциональность CSTA, могут быть единообразно описаны, обнаружены и интегрированы, используя стандартные протоколы Web-служб. Создание медиа-канала является расширением к ЕСМА-348.

Фиг.8 иллюстрирует примерный способ 420, чтобы установить каналы в среде Web-служб. В текущем изобретении провайдеры Web-служб перечисляют как метаданные службы все кодеки и протоколы, которые поддерживаются Web-службой на этапе 422. Разработчик приложения может использовать провайдеров каталога Web-служб, чтобы получить или обнаружить, какая Web-служба имеет кодек и протокол, который может использоваться на этапе 424. Этот этап может быть выполнен поиском по метаданным каждой предоставленной Web-службы для того, чтобы найти желаемый кодек и протокол, требующийся для него. Каталог предоставляет URL (унифицированный указатель ресурса) адрес для каждой Web-службы. Клиент 304 затем делает соединение с Web-службой и использует приложение с желаемым кодеком и протоколом, чтобы связаться с сервером 302. После того как соединение сделано, сразу устанавливаются медиа-канал 310 и его канал 308 передачи сигналов.

Изобретение в среде Web-служб адресует, как установить соединения, через все уровни (приложения и транспортный) в один обмен через расширение описания медиа-данных к WSDL. В одном варианте осуществления изобретение может быть применено в соединении с ЕСМА-348, который уже имеет механизм того, как установить CSTA и лежащий в его основе транспортный протокол передачи сигналов. Добавляя расширение медиа-кодирования и транспортного протокола к ЕСМА-348, CSTA таким образом улучшается, чтобы установить сигнальный и медиа-каналы за один шаг.

В другом варианте осуществления описание медиа-данных передается, используя возможность наращивания адресации Web-служб или WS-адресации, протокола, как этап, предшествующий CSTA приложению соединения. WS-адресация (WSA) является спецификацией, которая предоставляет транспортные нейтральные механизмы, чтобы адресовать конечные точки Web-службы и сообщения. И CSTA переключательные функции и CSTA приложения являются конечными точками Web-службы. WS-адресация вводит новую спецификацию, названную ссылкой на конечную точку, которая поддерживает динамическое использование служб, соответственно не закрытых, с элементами <wsdl:service> и <wsdl:port> в WSDL.

WS-адресация определяет тип XML-документа (wsa:EndpointReferenceType), чтобы представить ссылку на конечную точку. Элемент XML, wsa:EndpointReference, также определен, чтобы иметь тип. Оба находятся в пространстве имен XML по адресу http://schemas.xmlsoap.org/ws/2004/03/addressing.

Тип Ссылки на Конечную точку WSA может включать в себя следующее:

[адрес]: URI (Унифицированный Идентификатор Ресурса) идентифицирует конечную точку.

[свойства ссылки]: <xs:any/> (0 неограниченный), определенные свойства, каждое из которых передающийся объект или ресурс.

[тип выбранного порта]: QName (0 1), имя первичного типа порта, как определено в WSDL, для конечной точки.

[служба и порт]: (QName, NCName (0 1)) (0 1), служба и порт, как определено в WSDL, которые соответствуют конечной точке.

[политика]: необязательные элементы WS-Политики, описывающие режим, требования и возможности конечной точки.

Как в случае SIP, установление аудиоканала необходимо для CSTA речевых служб. Так как аудиоканал может обсуждаться в SIP через SDP, ссылка на WSA Конечную точку может использоваться для провайдеров речевой службы, чтобы объявить конечную точку медиа. Транспортные медиа-протоколы и механизмы кодирования являются из числа критических пунктов, необходимых, чтобы быть определенными для того, чтобы облегчить речевые службы. Эти пункты объявлены как свойства ссылки.

Чтобы улучшить устойчивость, медиа-канал в среде Web-служб смоделирован как арендованная линия от сервера (провайдер голосовых ресурсов CSTA) к клиенту (CSTA приложение) и аренда заканчивается по истечение времени. Сервер может также определять менеджера аренды, где клиент может отменять или обновлять аренду.

CSTA Тип Ссылки к Конечной точке медиа с XML-схемой включает в себя одну или много ссылок к конечной точке WSA. Например, провайдер CSTA речевой службы, который использует протокол G.711 поверх Транспортного Протокола Реального времени (RTP) по порту 6060, может описывать конечную точку медиа как следующее:

Свойства ссылки к конечной точке медиа CSTA включают в себя объявление кодека, идентификатор подписки и необязательное объявление окончания аренды. Как и в случае uaCSTA, где медиа-канал устанавливается вместе с каналом передачи сигналов, вышеупомянутая ссылка на конечную точку медиа может быть включена перед тем, как процесс CSTA приложения соединения в средах Web-служб считается законченным.

Используя преимущество расширяемости WS-протоколов, сеанс связи может быть установлен, используя <wsa:Action>. Ссылка на конечную точку медиа может сама быть свойством ссылки в ссылке на конечную точку CSTA провайдера Web-служб. Сообщение Простого Протокола Доступа к Объекту (SOAP) составляется, присоединяя ссылку на конечную точку медиа непосредственно после <wsa:To>, как показано ниже:

Web-службы описываются метаданными, такими как WS-Политика и WSDL. Тогда как WS-Политика описывает основные возможности, требования и характеристики службы, WSDL описывает абстрактные операции с сообщением и конкретные сетевые протоколы и адресует к области действия Web-службы. Обмен Метаданными Web-Служб, WS-МЕХ или WSX является спецификацией, которая загружает исправленные метаданные. Клиент может отправлять WS-MEX запрос к конечной точке, чтобы получить ее метаданные. Нормативная структура запроса, использующего SOAP, следующая:

Как показано в заголовке SOAP, WS-MEX использует WS-Адресацию, чтобы определить запрос для поиска метаданных. Целевая служба определена как URI в <wsa:To>, а конечная точка ответа определена, используя WS-Адресацию ссылки на конечную точку в содержимом <wsa:ReplayTo>. Типы метаданных, которые должны быть возвращены, определены в содержимом <wsx:GetMetadata> в теле SOAP.

Если конечная точка принимает запрос GetMetadata, она должна ответить ответным сообщением GetMetadata. Нормативная структура ответа в SOAP следующая:

Переданные в теле SOAP метаданные могут быть возвращены встроено, как содержимое элемента<wsx:Metadata>, или ссылкой, использующей WS-Адресацию ссылки на конечную точку или простым URI.

Вышеупомянутые SOAP сообщения могут иметь следующие WSDL связки:

Описание медиа-данных CSTA является типом метаданных, которые CSTA приложения должны получить от провайдера голосовой службы. WS МЕХ особенно подходящий здесь. Нижеследующее является простым SOAP сообщением для нахождения ссылки на конечную точку медиа:

Пример демонстрирует клиентское приложение, расположенное на client.example.com, которое запрашивает ссылку на конечную точку медиа у провайдера CSTA речевой службы по адресу server.acme.org. Поскольку определен особенный диалект, сервер должен ответить только метаданными желаемого типа. SOAP ответное сообщение будет:

Описание речевого приложения является другим типом метаданных, который может предоставить речевая служба. Многочисленные типы метаданных могут быть получены в то же время начальной загрузкой <wsx.-GetMetadata> с их соответственными URIs через <wsx:Dialect>. Следующее является примером тела SOAP для получения и обеих ссылок на конечную точку медиа и на речевое приложение:

Пока Web-службы загружаются в одностороннем порядке, модели запрос и ответ, Web-службы часто хотят принять сообщения, когда происходят события в других службах или приложениях. Событийность Web-служб, или WS-Событийность (WSE), является спецификацией, чтобы облегчить оповещение о событии. WS-событийность определяет как одна Web-служба может подписаться на события от имени другой службы или приложения и позволяет приложениям определять, как доставляются сообщения о событии. Это поддерживает широкое разнообразие событийных топологий, позволяющих источнику события и конечному приемнику события быть разъединенными. Эти свойства являются подходящими для широкого диапазона CSTA приложений, от центров обработки звонков до мобильной компьютерной среды. Использование WS-событийности предусмотрено, поскольку CSTA голосовым службам нужно определение события, чтобы функционировать.

Хотя настоящее изобретение было описано со ссылками на конкретные варианты осуществления, специалисты в данной области техники признают, что изменения могут быть сделаны в форме и деталях без отступления от сущности и области применения изобретения.