Среда разработки для комбинирования управляемого семантикой и управляемого состоянием диалога - RU2419843C2

Чертежи

Описание

УРОВЕНЬ ТЕХНИКИ

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

Приложения, которые поддерживают взаимодействие пользователя через речевой пользовательский интерфейс (РПИ, VUI), известны в уровне техники. В процессе разработки приложения этих типов могут создаваться поверх структуры интерфейса прикладного программирования (API) низкого уровня, которая обеспечивает доступ к базовым ресурсам. Например, известно, что приложения телефонии создаются поверх структуры низкоуровневого API, которая включает в себя поддержку для таких ресурсов, как без ограничения указанным: инфраструктура телефонии, ресурсы для распознавания речи и ресурсы для синтеза речи.

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

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

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

Среда разработки, которая поддерживает управляемый семантикой диалог, обычно является в большей степени управляемой пользователем, чем управляемой системой. При авторском создании раздела управляемого семантикой диалога разработчик, в общем случае, будет задавать, какие поля из множества полей должны быть заполнены по получении подходящей информации от пользователя системы. В определенной мере, управляемый семантикой формат сходен с формой в приложении графического пользовательского интерфейса (ГПИ, GUI), которая содержит некоторые поля, подлежащие заполнению пользователем. Вместо задания заранее установленного пути прохождения полей (А->B->C и т.д.) задают некоторые узлы диалога или элементы, чтобы реагировать в зависимости от конкретного состояния других полей. Например, задается, что данный узел А диалога будет активным, если поле C является пустым. Также возможны множественные зависимости, например, данный узел диалога задается как активный, если поля A, B и C являются пустыми, а поле E заполнено и подтверждено. Некоторые поля могут быть установлены как требующие подтверждения пользователем системы, что их содержимое является точно определенным. После каждого взаимодействия «пользователь-машина» выполняется определение в пределах структуры управляемого семантикой диалога относительно того, какой узел или узлы диалога должны быть активны далее.

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

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

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

Более высокоуровневый API может в качестве альтернативы быть настроен, чтобы главным образом поддерживать управляемый состоянием диалог. Теперь становится проще связать состояния диалога с условием (например, как только Вы завершили действие с состоянием A, Вы оцениваете, какое условие является истинным и следуете этому пути к следующему состоянию). Этот тип разработки диалога является простым для визуализации и авторского создания. Недостатком, однако, является то, что получаемый в результате диалог не является ни естественным, ни гибким для пользователя приложения.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

Фиг.2 - блок-схема, иллюстрирующая высокоуровневые характеристики архитектуры системы.

Фиг.3 - блок-схема части структуры API.

ПОДРОБНОЕ ОПИСАНИЕ ИЛЛЮСТРАТИВНЫХ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ

I. Примерные среды

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

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

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

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

Как показано на фиг.1, приведенная для примера система для осуществления настоящего изобретения включает в себя вычислительное устройство общего назначения в виде компьютера 110. Компоненты компьютера 110 могут включать в себя, без ограничения указанным, блок 120 обработки, системную память 130 и системную шину 121, которая связывает различные системные компоненты, включая системное запоминающее устройство, с блоком 120 обработки. Системная шина 121 может быть любой из различных типов шинных архитектур, включая шину памяти или контроллер памяти, периферийную шину и локальную шину, использующую любую шинную архитектуру из множества шинных архитектур. В качестве примера, а не ограничения, такие архитектуры включают в себя шину стандартной промышленной архитектуры (ISA), шину микроканальной архитектуры (MСA), расширенную ISA шину (EISA), локальную шину стандарта Ассоциации по стандартам в области видеоэлектроники (VESA) и шину межсоединения (PCI) периферийных компонентов, известную также как шина расширения.

Компьютер 110 обычно включает в себя различные машиночитаемые носители. Машиночитаемые носители могут быть любыми носителями, к которым может осуществлять доступ компьютер 110, и включают в себя энергозависимые и энергонезависимые носители, съемные и несъемные носители. В качестве примера, а не ограничения, машиночитаемые носители могут содержать носители для запоминающих устройств компьютера и носители для передачи данных. Носители для запоминающих устройств включают в себя энергозависимые и энергонезависимые, съемные и несъемные носители, реализованные любым способом или технологией, предназначенными для хранения информации, такой как машиночитаемые команды, структуры данных, программные модули или другие данные. Носители запоминающих устройств компьютера включают в себя, без ограничения указанным, оперативное запоминающее устройство (ОЗУ, RAM), постоянное запоминающее устройство (ПЗУ, ROM), электрически стираемое программируемое ПЗУ (ЭСППЗУ, EEPROM), флэш-память или другую технологию памяти ПЗУ на компакт-диске (CD-ROM), цифровые универсальные диски (DVD) или другое ЗУ на оптическом диске, ЗУ на магнитных кассетах, магнитной ленте, магнитном диске или другие ЗУ на магнитных носителях или любой другой носитель, который может быть использован для хранения требуемой информации и к которому может осуществлять доступ компьютер 110.

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

Системная память 130 включает в себя компьютерные носители в виде энергозависимого и/или энергонезависимого запоминающего устройства, такого как постоянное запоминающее устройство (ПЗУ, ROM) 131 и оперативное запоминающее устройство (ОЗУ, RAM) 132. Базовая система 133 ввода-вывода (BIOS), содержащая базовые процедуры, обеспечивающие передачу информации между компонентами компьютера 110, например, при запуске, обычно хранится в ПЗУ 131. ОЗУ 132 обычно содержит данные и/или программные модули, которые непосредственно доступны для блока 120 обработки и/или обрабатываются им в данный момент времени. В качестве примера, а не ограничения, на фиг.1 проиллюстрирована операционная система 134, прикладные программы 135, другие программные модули 136 и программные данные 137.

Компьютер 110 может также включать в себя другие съемные/несъемные, энергозависимые/энергонезависимые компьютерные носители для хранения данных. В качестве примера на фиг.1 проиллюстрирован накопитель 141 на жестком диске, который осуществляет считывание с несъемных, энергонезависимых магнитных носителей или запись на них, накопитель 151 на магнитном диске, который осуществляет считывание со съемного, энергонезависимого магнитного диска 152 или запись на него, и накопитель 155 на оптическом диске, который осуществляет считывание со съемного, энергонезависимого оптического диска 156 или запись на такой диск, например, СD-ROM или другой оптический носитель. Другие съемные/несъемные, энергозависимые/энергонезависимые компьютерные носители для хранения данных, которые могут быть использованы в приведенной для примера операционной среде, включают в себя, без ограничения указанным, кассеты на магнитных лентах, карты флэш-памяти, цифровые универсальные диски, ленту цифрового видеомагнитофона, твердотельное ОЗУ, твердотельное ПЗУ и т.п. Накопитель 141 на жестком диске обычно соединен с системной шиной 121 через интерфейс несъемной памяти, такой как интерфейс 140, и накопитель 151 на магнитном диске и накопитель 155 на оптическом диске обычно соединены с системной шиной 121 посредством интерфейса съемной памяти, такого как интерфейс 150.

Накопители и связанные с ними компьютерные носители для хранения данных, описанные выше и проиллюстрированные на фиг.1, обеспечивают хранилище для машиночитаемых команд, структур данных, программных модулей и других данных для компьютера 110. На фиг.1, например, накопитель 141 на жестком диске проиллюстрирован в качестве хранящего операционную систему 144, прикладные программы 145, другие программные модули 146 и программные данные 147. Эти компоненты могут быть либо теми же, либо отличными от операционной системы 134, прикладных программ 135, других программных модулей 136 и программных данных 137. Операционная система 144, прикладные программы 145, другие программные модули 146 и программные данные 147 обозначены отличающими ссылочными позициями, чтобы проиллюстрировать, что, по меньшей мере, они являются различными копиями.

Пользователь может вводить команды и информацию в компьютер 110 через устройства ввода, такие как клавиатура 162, микрофон 163 и указательное устройство 161, такое как мышь, шаровой манипулятор или сенсорная клавиатура. Другие устройства ввода (не показаны) могут включать в себя джойстик, игровую панель, спутниковую антенну, сканирующее устройство и т.п. Эти и другие устройства ввода обычно соединены с блоком 120 обработки через интерфейс 160 пользовательского ввода, соединенный с системной шиной, но могут быть соединены посредством другого интерфейса и шинных структур, таких как параллельный порт, игровой порт или универсальная последовательная шина (USB). Монитор 191, или другой тип устройства вывода на экран, также соединен с системной шиной 121 через интерфейс, например, видеоинтерфейс 190. В дополнение к монитору компьютеры также могут включать в себя другие периферийные устройства вывода, такие как динамики 197 и принтер 196, которые могут быть соединены через интерфейс 195 периферийных устройств вывода.

Компьютер 110 может действовать в сетевой среде, используя логические соединения с одним или несколькими удаленными компьютерами, например удаленным компьютером 180. Удаленный компьютер 180 может быть персональным компьютером, портативным устройством, сервером, маршрутизатором, сетевым ПК, одноранговым устройством или другим обычным сетевым узлом и обычно включает в себя многие или все элементы, описанные выше относительно компьютера 110. Логические соединения, изображенные на фиг.1, включают в себя локальную вычислительную сеть (LAN) 171 и глобальную вычислительную сеть (WAN) 173, но также могут включать в себя другие сети. Такие сетевые среды являются обычными для учреждений, вычислительных сетей масштаба предприятия, внутрикорпоративных локальных сетей и Интернет.

При использовании в сетевой среде LAN компьютер 110 соединен с локальной сетью 171 через сетевой интерфейс или адаптер 170. При использовании в сетевой среде WAN компьютер 110 обычно включает в себя модем 172 или другое средство установления связи в WAN 173, такой как Интернет. Модем 172, который может быть внутренним или внешним, может быть соединен с системной шиной 121 через интерфейс 160 пользовательского ввода или другие подходящие средства. В сетевой среде программные модули, изображенные относящимися к персональному компьютеру 110 или их части, могут храниться на удаленном запоминающем устройстве. В качестве примера, а не ограничения, на фиг.1 проиллюстрированы удаленные прикладные программы 185 в качестве постоянно хранимых на запоминающем устройстве 181. Понятно, что показанные сетевые соединения являются иллюстративными, и могут использоваться другие средства установления линии связи между компьютерами.

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

II. Примерные системные среды

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

Приложение телефонии можно рассматривать в виде многозвенной системы, включающей в себя уровень представления и уровень «логика + данные». Уровень представления обычно отвечает за взаимодействие с конечным пользователем, использующим речевой вывод и речевой ввод. Некоторые системы будут включать в себя дополнительное средство вывода, такое как ГПИ, или дополнительное средство ввода, такое как механизм ввода двухтонального многочастотного (ДТМЧ, DTMF) набора телефонного номера. Обычно уровень представления обеспечивает речевой пользовательский интерфейс. Уровень «логика + данные» обычно является ответственным за основные бизнес-правила и хранение и доступ к данным. Известно, что он обеспечивает набор API в качестве интерфейса для уровня «логика + данные», но, тем не менее, имеется необходимость в приспосабливаемой структуре API, предназначенной для авторского создания РПИ.

На фиг.2 показана схематическая блок-схема, иллюстрирующая высокоуровневые характеристики для архитектуры 200 системы. Верхний уровень архитектуры 200 включает в себя приложение или пользовательский программный код 202. Иллюстративно он является программой, созданной разработчиком, чтобы приводить в исполнение диалог. Нижний уровень архитектуры 200 включает в себя базовую структуру 206 API. Базовая структура 206 иллюстративно обеспечивает доступ к ресурсам системы. Например, базовая структура иллюстративно включает в себя API для телефонии, API для передачи сигналов, API для ДТМЧ, API для распознавания речи, API для синтеза речи и/или любой другой интерфейс ресурсов системы.

Как обозначено стрелкой 208, код 202 может настраиваться для непосредственного вызова компонентов базовой структуры 206. Такой способ разработки может быть относительно утомительным и трудоемким с точки зрения разработчика. Чтобы снизить трудности разработки, структура 204 API, предназначенного для диалога, позиционируется между приложением 202 и базовой структурой 206. Структура 204 обеспечивает подход с более высокоуровневым API, чем структура 206. Таким образом, в соответствии со стрелками 210 и 212 пользовательский программный код 202 может создаваться для непосредственных обращений к структуре 204, которая затем осуществляет соответствующие вызовы компонентов структуры 206. Таким образом, разработчик может создавать диалог более продуктивным способом. В соответствии с одним вариантом осуществления инструментальное средство (не показано) устанавливается поверх структуры 204 API диалога, чтобы обеспечивать возможность дополнительных улучшений производительности разработчика. Инструментальное средство содействует и расширяет возможности разработчика для авторского создания по отношению к структуре более высокоуровневого API.

Таким образом, архитектура 200 обеспечивает среду разработки РПИ, содержащую два уровня: низкоуровневый речевой уровень, достаточный для авторского создания различных сценариев телефонии; и диалоговый уровень более высокого уровня, настроенный для повышения производительности разработчика за счет создания высокоуровневых абстракций.

III. Структура API диалога

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

На фиг.3 в соответствии с одним аспектом настоящего изобретения показана блок-схема части 304 структуры API диалога (например, структуры 204 на фиг.2). Для поддержки системы авторского создания диалога комбинированного типа проиллюстрированная структура 304 включает в себя контейнер 306 управляемого семантикой диалога и контейнер 308 управляемого состоянием диалога. Хотя проиллюстрирован только один тип для каждого типа контейнера, в зависимости от конкретной схемы разработки в состав может быть включен набор любых типов. Функциональные отношения между многими контейнерами диалогов и их содержимым поясняются ниже.

Контейнеры 306 и 308 диалогов включают в себя каждый множество диалоговых элементов 310. Хотя одинаковая ссылочная позиция использована для обозначения всех проиллюстрированных диалоговых элементов, понято, что сущность диалоговых элементов может изменяться от одного к другому. В соответствии с одним вариантом осуществления каждый контейнер диалога настроен для управления активизацией содержащихся в нем диалоговых элементов. Контейнер 306 настроен для вмещения и выполнения управляемого семантикой диалога, в то время как контейнер 308 настроен для вмещения и выполнения управляемого состоянием диалога.

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

В соответствии с одним аспектом настоящего изобретения, на уровне более высокого API (то есть, на уровне структуры 204 по фиг.2), имеется поддержка для индивидуальных диалоговых элементов, управляемого семантикой диалога и инфраструктура поддержки всех типов диалога. В одном варианте осуществления уровень API также включает в себя поддержку управляемого состоянием диалога. В другом варианте осуществления, однако, явная поддержка управляемого состоянием диалога включена в компонент инструментального средства, который устанавливается поверх структуры API для содействия разработке. Следует отметить, что в объем настоящего изобретения входит управление границами между инструментальным средством и API, чтобы делать возможной любую из разнообразия различных конкретных реализаций. Все такие конфигурации входят в объем настоящего изобретения.

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

В соответствии с одним примером разработки диалога комбинированного формата разработчик начинает с пустого «холста» и затем добавляет три узла, которые представляют компоненты последовательного диалога, которые подлежат выполнению по порядку. Разработчик проходит вниз, на первый узел и вставляет предложение, например, "добро пожаловать". Предложение является компонентом простого диалога, который не требует сложных возможностей управляемого семантикой диалога. Одной необязательной возможностью для первого узла является создание управляемого состоянием контейнера и размещение в нем элемента предложения. В одном варианте осуществления платформа разработки настроена для вмещения установления предложения без создания какого-либо типа контейнера.

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

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

В соответствии с одним аспектом настоящего изобретения структура API диалога включает в себя множество объектов API в форме диалоговых элементов, которые предоставлены для использования разработчиком приложения. Как описано, контейнер диалога является одним типом диалогового элемента и настроен для содействия разработке и исполнению диалога конкретного типа.

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

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

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

В одном варианте осуществления в пределах элемента QuestionAnswer могут быть установлены характеристики для поддержки функциональных возможностей постобработки (например, если поля A, B и C заполнены, то произойдет постобработка X и т.д.). Для элемента QuestionAnswer, который будет вложен внутрь управляемого семантикой контекста диалога, некоторые значения характеристик должны предоставляться для поддержки постобработки функциональных возможностей. В одном варианте осуществления, если элемент QuestionAnswer вложен внутрь контекста управляемого состоянием диалога, постобработка может быть усилена, если разработчик осуществляет такой выбор, но она не является обязательно требуемой.

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

В соответствии с одним вариантом осуществления элемент QuestionAnswer настроен с возможностью воспроизведения MainPrompt (основная подсказка) при запуске, чтобы слушать речь и/или ДТМЧ, поддерживать более одной грамматики речи или ДТМЧ, слушать или не слушать при воспроизведении подсказки, начинать слушать после того, как часть подсказки была воспроизведена, подобно стандартному DialogElement (диалоговый элемент), описанному ниже, продолжать выдавать подсказку, пока не будет обнаружено действительное распознавание, приспосабливать подсказку, чтобы рассматривать команды Help (справка) и Repeat (повторить), адаптировать подсказку с учетом паузы или нераспознавания, поддерживать диалог FormFillingDialog (диалог для заполнения форм) для открытия механизма для привязки результатов к SemanticItems (семантические единицы), автоматизировать подтверждение SemanticItem и/или определять активизацию FormFillingDialog согласно просмотру семантических привязок.

В соответствии с другим вариантом осуществления элемент SemanticItem является другим типом диалогового элемента, предусмотренного в структуре. Элемент SemanticItem представляет класс, который поддерживает поля формы, обычно в управляемом семантикой контексте. Эти поля формы являются полями, которые заполняются в течение процесса управляемого семантикой диалога.

В соответствии с другим вариантом осуществления элемент FormFillingDialog является другим типом диалогового элемента, предусмотренного в структуре. Элемент FormFillingDialog является контейнером, который управляет семантически управляемым диалогом и поддерживает связанный процесс заполнения полей.

В соответствии с другим вариантом осуществления элемент RecordSound (звукозапись) является другим типом диалогового элемента, предусмотренного в структуре. Элемент RecordSound может действовать изнутри любого типа контейнера, либо независимо. Общей функцией элемента RecordSound является получение записи от пользователя (например, без выполнения какой-либо функции распознавания). Такой элемент является полезным в контексте речевой почты и других подобных приложений.

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

В соответствии с другим вариантом осуществления элемент Application (приложение) является другим типом диалогового элемента, предусмотренного в структуре. Элемент Application действует в качестве контекста верхнего уровня для конкретного диалогового приложения. Он обычно создает экземпляр контейнера верхнего уровня. Общей функцией элемента Application является установление направляющих принципов для взаимодействий в целом, а также низкоуровневых взаимодействий, которые происходят между элементами в структуре. Хотя функции элемента Application могут изменяться в широком диапазоне, они могут включать в себя осуществление основных этапов для поддержки различных аспектов приложения телефонии, включая автоматический ответ на телефонный вызов, отклонение вызова, завершение вызова, отслеживание хода продвижения вызова, конкретную поддержку некоторых функциональных возможностей входящих и исходящих вызовов и обработку ошибок соединений.

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

В одном варианте осуществления система настроена для поддержки выбора подсказки автоматически (то есть, используя элемент PromptSelection (выбор подсказки)) при условии, что соответствующие тексты заранее определены. Элементы, такие как HistoryItem (элемент предыстории), используются для определения, что происходит в течение времени исполнения. Подобным образом элемент Logging (регистрация) обеспечивает помощь в отслеживании происходящего в течение времени исполнения (например, API выдает данные в установленную структуру регистрации). Элемент HistoryItem может быть использован для содействия реализации элемента Bail-Out (срочная помощь) в качестве подходящей реакции на необычные обстоятельства, например, при пропадании пользователя (например, запрошенный четыре раза вопрос без ответа, кроме паузы или нераспознаваемых ответов).

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

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

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

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

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

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

Как описано выше, структура API диалога может поддерживать два основных типа объектов, а именно, DialogElements (диалоговые элементы) и DialogContainers (контейнеры диалога). Основным приложением является DialogContainer (контейнер диалога); при этом новые DialogContainers определяются посредством логического вывода, с новым классом, определяемым для каждого нового контейнера. Эти контейнеры затем реализуются во время исполнения и исполняются. Поддиалоги в этой модели могут рассматриваться в качестве повторного использования компонентов (вместо вызовов подпрограмм).

В одном варианте осуществления DialogContainers технически не содержат других DialogContainers непосредственно, но они "активируют" другие контейнеры диалога. Это может осуществляться через использование примитива или элемента DialogReference (диалоговая ссылка). DialogReference открывают свойства, на которые может ссылаться любой DialogContainer, так что он может быть реализован во время исполнения. Когда реализованный по ссылке DialogContainer завершает свое выполнение, он может уведомить DialogReference, который его реализовал. Родительский DialogContainer затем может возобновить последовательность действий как обычно.

В одном варианте осуществления DialogElements настроены для открытия способа запуска исполнения, открытия способа остановки/отмены исполнения, асинхронного исполнения уведомления приложения, если они более не исполняются, уведомления приложения о причине, почему они более не исполняются (завершено, отменено, ошибка, и т.д.), уведомления приложения, когда они запущены, и получения доступа к объекту Application (и, следовательно, к связанным API сигнализации и унифицированному API). DialogElements могут быть компонуемыми, и в том случае они будут иметь доступ к своему родителю.

В соответствии с одним аспектом настоящего изобретения любая среда авторского создания может быть предусмотрена для открытия функциональных возможностей описанной структуры API диалога. Такая среда авторского создания может представлять собой единственно API, API + инструментальное средство, единственно инструментальное средство или любую другую реализацию без отклонения от объема настоящего изобретения.

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

Реферат

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

Формула