Конечный автомат унифицированного обмена сообщениями

Иллюстрации

Показать все

Изобретение относится к области компьютерных систем. Техническим результатом является обеспечение независимости от платформы для приложения унифицированной системы обмена сообщениями. Конечный автомат (FSM) приложения системы UM создается с использованием функции XML создавать допустимое состояние меню на основе программного компонента системы UM. Для программного компонента системы UM, который является контекстом или настройкой приложения системы UM, условный атрибут XML задает условие для подсказки, перехода или грамматического узла конечного автомата системы UM. Для программного компонента системы UM, который является фрагментом XML, элемент импорта XML повторяет фрагмент XML при компиляции, что предотвращает отнимающее много времени и подверженное ошибкам ручное дублирование кода. Для программного компонента системы UM, такого как внешний метод, функция, переменная или действие, средство XML функции-обертки проверяет существование таких внешних программных компонентов системы UM во время компоновки и получает информацию о версии для проверки доступности той же самой версии при выполнении. 2 н. и 14 з.п. ф-лы, 13 ил.

Реферат

ОБЛАСТЬ ТЕХНИКИ

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

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

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

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

Один общий признак современных систем передач данных состоит в том, что пользователям обычно даны различные варианты конфигурации из меню различных стилей, чтобы приспособить эти системы для конкретных предпочтений передач данных. Таким образом, голосовая почта, унифицированный обмен сообщениями и другие приложения интеллектуального распознавания голоса (IVR) имеют пользовательские интерфейсы, которые обычно управляются с помощью меню. Меню состоит из одной или более подсказок, которые могут воспроизводиться конечному пользователю, например, по телефону. Пользователь делает выбор пункта меню одним или более способами, например, используя клавиатуру для двухтонального многочастотного набора (DTMF). Методики навигации DTMF могут оказаться громоздкими, когда имеется много вариантов ввода. Кроме того, с ростом использования приборов передач данных, оставляющих руки свободными (hands-free), ввод с помощью клавиатуры DTMF может оказаться неудобными или неуместным.

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

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

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

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

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

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

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

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

Фиг.3 изображает иллюстративное описание расширения пункта меню, показанного на Фиг.2.

Фиг.4 изображает иллюстративное описание иерархии меню в соответствии с системой обмена сообщениями, показанной на Фиг.3.

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

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

Фиг.7 - блок-схема сеанса вызова, усовершенствованного посредством механизма грамматики в соответствии с аспектом заявленного изобретения.

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

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

Фиг.10 изображает блок-схему иллюстративной системы унифицированного обмена сообщениями в соответствии с аспектом заявленного изобретения.

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

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

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

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

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

На Фиг.1 среда 10 программирования унифицированного обмена сообщениями (UM) системы 12 реализации UM обеспечивает возможность гибких программных конструкций, многократного использования существующих программных элементов и проверки целостности созданного приложения 14 системы UM, созданной посредством среды 10 программирования и используемой на машине 16 исполнения системы UM.

В иллюстративной версии редактор 18 создает конечный автомат 20 (FSM) меню системы UM, который может удовлетворить быстро изменяющиеся потребности приложений системы UM. Для освобождения от трудностей, связанных с жестким кодированием и управляющими элементами для обработки сообщений, для создания FSM 20 используется расширяемый язык разметки (XML). Язык XML представляет собой универсальный язык разметки, классифицируемый как расширяемый язык, поскольку он позволяет своим пользователям определять свои собственные тэги. Язык XML обеспечивает возможность совместного использования структурированных данных среди различных информационных систем, особенно через Интернет. Таким образом, его использование охватывает и область кодирования документов, и область сериализации данных.

Документ (или множество взаимосвязанных документов, называемых приложением) образует диалоговый конечный автомат 20 системы UM. В каждый момент времени пользователь всегда находится в одном диалоговом состоянии, или в диалоговом окне. Каждое диалоговое окно определяет следующее диалоговое окно, на которое следует перейти. Переходы указаны с помощью идентификаторов, которые задают следующий документ и диалоговое окно для использования. Пользователь взаимодействует через пользовательский интерфейс (не показан) с редактором 18 для сборки элементов диалогового окна/состояний, изображенных как подсказки 22 системы UM и переходы 24. Преимущественно пользователь может многократно использовать фрагменты XML, изображенные как файлы 26 определения XML системы UM, поскольку среда 10 программирования обеспечивает поддержку для подпрограмм XML и вставок файлов. Например, код для "найти пользователя" с использованием DTMF набора является действительно сложной последовательностью меню (например, первое меню - запрашивающее произнесение по буквам, второе меню - подтверждающее, другое меню - позволяющее пользователю начать сначала, другое меню - сообщающее, что результаты не были найдены, и т.д.). Кроме того, эта функция "найти пользователя" используется в нескольких местах (например, при поиске контакта с целью его вызова, при поиске адреса человека для отправки голосовой почты, при поиске адреса человека для отправки приглашения на совещание и т.д.). Следовательно, имеется частая потребность правильно дублировать фрагменты XML для каждого контекста.

С этой целью в определение конечного автомата включен элемент языка XML, называемый <FsmImport>, показанный 28. Этот элемент включает в себя имя 'FsmModule' и факультативно файловую ссылку. При запуске системы тэги FsmImport расширяются до их ссылочных модулей. Например, следующий тэг будет заменен блоком XML кода с именем 'SearchMenus' в файле 'Common.fsm':

<FsmImport file="common.fsm" module="SearchMenus"/>

Фиг.2 является изображением приложения 32, которое не использует преимущество функции импорта. Предположим, что приложение 18 позволяет вам "отправлять" пользователю множество различных элементов обмена. Например, могут быть отправлены сообщение e-mail, сообщение голосовой почты или элемент календаря. Все эти возможные варианты выражены через разные "состояния меню" в определениях XML, поскольку каждый из них фактически весьма отличается от других и требует уникальные подсказки и переходы. Однако когда дело доходит до выяснения, кто должен принять отправляемое сообщение, все они очень похожи, если не идентичны, в этом отношении. Иллюстративный диалог для отправки может выглядеть следующим образом:

Система: "Кому вы хотите отправить это?"

Пользователь: "Тому"

Система: "Я думаю, Вы сказали Джону, верно?"

Пользователь: "Нет, я сказал Тому"

Система: "OK. Тому, верно?"

Пользователь: "Да"

Такой диалог фактически может быть весьма сложным, требующим множества различных меню, взаимодействующих сложным образом. Каждое меню поиска каталога должно быть продублировано соответственно в каждой отправляющей структуре, изображенной на Фиг.2, соответственно как оператор 34 отправления электронной почты, проходящий через меню 36 поиска каталога к оператору 38 "электронная почта отправлена". Оператор 40 отправления голосовой почты проходит через первое дублирование меню 42 поиска каталога к оператору 44 "голосовая почта отправлена". Оператор 46 отправления календаря проходит через второе дублирование меню 48 поиска каталога к оператору 50 "календарь отправлен".

Фиг.3 иллюстрирует, как наличие механизма для "импорта" подпрограммы во время прогона избегает необходимости дублирования таких фрагментов XML. Терминология FsmImport, которая появляется в конфигурационных XML-файлах, использует XML FsmModules. Таким образом, единственная копия меню 36 поиска каталога может быть использована многократно для привязки оператора 34 отправления электронной почты к оператору 38 "электронная почта отправлена", оператора 40 отправления голосовой почты к оператору 44 "голосовая почта отправлена" и оператора 46 отправления календаря к оператору 50 "календарь отправлен", чтобы сформировать меню 32' поиска. Код XML для меню 32' поиска может быть написан, как пример 1:

1: <EmailManager>
2: <Menu id="EmailForwardStatement">
3: <Prompts>
4: <Prompt id="ForwardingEmail"/>
5: </Prompts>
6: <Transitions>
7: <Transition event= "1" refId="SearchMenuStart"/>
8: </Transitions>
9: </Menu>
10: <FsmImport file="Search.fsm" moduleId="CommonSearchMenus"/>
11: </EmailManager>

Десятая строка дает указание механизму конечного автомата, который использует определения XML, выполнить поиск в файле с именем Search.fsm и импортировать те определения меню линейно в контекст EmailManager. Это позволяет меню с ID EmailForwardStatement сослаться на меню с именем SearchMenuStart, которое, однако, не появляется в контексте EmailManager, поскольку оно находится только в файле, на который сделана ссылка.

Редактор 18 также может использовать добавленный элемент XML условных атрибутов 60 к определениям меню конечного автомата, чтобы обеспечить возможность дополнительной сложности и упростить программирование FMS 20. Рассмотрим на Фиг.4 меню 70, состоящее только из четырех состояний, созданных множеством команд для воспроизведения пользователю ("подсказки "), и что следующее состояние должно быть основано на вводе пользователя ("переходы"). В иллюстративном примере состояние 72 главного меню дает пользователю указание нажать "1" для голосовой почты, "2" для электронной почты или "3" для календаря. В зависимости от того, что пользователь нажимает, которое изображено как нажатие пользователем "1" на стрелке 74, нажатие "2" на стрелке 76 или нажатие "3" на стрелке 78, диалог переходит в соответствующее состояние подсистемы 80 голосовой почты, подсистемы 82 электронной почты или подсистемы 84 календаря.

Для этого конкретного меню 70 кодирование этой информации с использованием языка XML может выглядеть следующим образом в примере 2:

<Menu id="MainMenuState">

<Prompts>

<Prompt id="mainMenu"/>

<Prompt id="voicemailOption1"/>

<Prompt id="emailOption2"/>

<Prompt id="calendarOption3"/>

</Prompts>

<Transitions>

<Transition event="1" refId="VoicemailSubsystem"/>

<Transition event="2" refId ="EmailSubsystem"/>

<Transition event="3" refId ="CalendarSubsystem"/>

</Transitions>

</Menu>

Следует понимать, что каждое состояние 72, 80, 82, 84 меню существует в "контексте". Состояние 72 главного меню существует в "контексте глобального управления", в котором в памяти имеется объект, называемый GlobalManager, который хранит некоторую информацию, подходящую для этого конкретного меню. Пример кода для объекта GlobalManager может выглядеть следующим образом в примере 3:

<GlobalManager>

<Menu id="MainMenuState">

<Prompts>

<Prompt id="mainMenu"/>

<Prompt id="voicemailOption1"/>

<Prompt id="emailOption2"/>

<Prompt id="calendarOption3"/>

</Prompts>

<Transitions>

<Transition event="1" refId ="VoicemailSubsystem"/>

<Transition event="2" refId ="EmailSubsystem"/>

<Transition event="3" refId ="CalendarSubsystem"/>

</Transitions>

</Menu>

</GlobalManager>

На Фиг.5 меню 86 системы UM преимущественно включает в себя условные атрибуты элемента XML. Предположим, что проектирование функции требует, чтобы вариант электронной почты воспроизводился только в том случае, если администратор задал флаг, который позволяет вызывающему обращаться к нему. Это можно рассматривать как принятие решения верхнего уровня, изображенное как условное выражение 88 разрешения электронной почты, даже перед тем, как начинается состояние основного меню 72. Если при переходе 90 от условного выражения 88 имеется флаг "Да", то будет достигнуто ранее описанное основное состояние 72. Однако если при переходе 92 от условного выражения 88 имеется флаг "Нет", выполняется вход в состояние 94 сокращенного основного меню. Пользователю дается указание ввести "1" для голосовой почты или "3" для календаря, что соответственно дает в результате переход 96 для "1" в состояние 80 подсистемы голосовой почты и переход 98 для "3" в состояние 84 подсистемы календаря. Если происходит переход 100 для "2", выполняется вход в состояние 102 "Ошибка! Вариант недоступен". Таким образом, условное выражение 88 позволяет избежать более громоздкой и подверженной ошибкам структуры меню.

Код меню 86 системы UM может быть получен, как показано в примере 4:

<GlobalManager>

<Menu id="MainMenuStateWithEmailOption">

<Prompts>

<Prompt id="mainMenu"/>

<Prompt id="voicemailOption1"/>

<Prompt id="emailOption2"/>

<Prompt id="calendarOption3"/>

</Prompts>

<Transitions>

<Transition event="1" refId ="VoicemailState"/>

<Transition event="2" refId ="EmailState"/>

<Transition event="3" refId ="CalendarState"/>

</Transitions>

</Menu>

<Menu id="MainMenuStateWithoutEmailOption">

<Prompts>

<Prompt id="mainMenu"/>

<Prompt id="voicemailOption1"/>

<Prompt id="calendarOption3"/>

</Prompts>

<Transitions>

<Transition event="1" refId ="VoicemailState"/>

<Transition event="3" refId ="CalendarState"/>

</Transitions>

</Menu>

</GlobalManager>

Чтобы расширить этот пример, рассмотрим, что получается, если администратор выбирает также отключить по условию доступ к календарю. Традиционно потребовались бы четыре меню, например: MainMenuAllOptions (основное меню со всеми вариантами), MainMenuNoEmail (основное меню без электронной почты), MainMenuNoCalendar (основное меню без календаря) и MainMenuNoEmailNoCalendar (основное меню без электронной почты и без календаря).

В отличие от этого, использование условных выражений создает более изящный подход посредством предоставления расширения к определению XML, которое позволяет применять подсказки и переходы в зависимости от условий, как, например, в примере 5:

<Menu id="MainMenuStateWithEmailOption">

<Prompts>

<Prompt id="mainMenu"/>

<Prompt id="voicemailOption1"/>

<Prompt condition"IsEmailEnabled" id="emailOption2"/>

<Prompt id="calendarOption3"/>

</Prompts>

<Transitions>

<Transition event="1" refId ="VoicemailState"/>

<Transition condition="IsEmailEnabled" event="2" refId ="EmailState"/>

<Transition event="3" refId ="CalendarState"/>

</Transitions>

</Menu>

Имя переменной "IsEmailEnabled" является булевой переменной (истина/ложь), которая находится в контексте глобального менеджера. Во время выполнения механизм конечного автомата XML будет просматривать XML и решать, какие элементы должны или не должны быть "активными" на основе динамических значений своих условных атрибутов.

Язык условных атрибутов довольно устойчив и поддерживает логические операторы AND (И), OR (ИЛИ), NOT (НЕ), GT (больше чем), LT (меньше чем) и некоторые другие для комбинирования контекстных переменных. Например, подсказка может быть помечена с помощью некоторого условия condition="IsEmailEnabled AND IsVoicemailEnabled". Это выражение может быть разобрано в дерево разбора (например, синтаксического) с использованием простого восходящего синтаксического анализатора и оценено во время выполнения.

Условный атрибут применяется не только к подсказкам и переходам, но также и к грамматическим узлам. Так, вы можете иметь некоторые грамматики команд, активные в зависимости от условий во время итерации речевого меню. Общее понятие автоматизированного распознавания речи (ASR) описано в общедоступной и находящейся на одновременном рассмотрении заявке на патент США №11/238521, номер публикации 2007/0073544 A1, раскрытие которой включено в настоящий документ по ссылке во всей своей полноте. Использование ASR, изображенной номером 110 на Фиг.1, таким образом, усовершенствовано возможностью быстро импортировать этот конечный мини-автомат в каждую соответствующую часть речевого меню, а также тем, что его можно легко создавать с помощью условных выражений.

На Фиг.6 в примере взаимодействия с 110 ASR после входа в основное состояние 112 от пользователя ожидается некоторый голосовой ответ. Эта часть 110 ASR изображает случай, когда нет возможности получить осмысленный ответ. В состоянии 114 "Молчание 1" воспроизводится подсказка, если пользователь молчит (например, "Извините, вас не слышно"). Если затем наступает состояние 116 "Молчание 2", воспроизводится подсказка, если пользователь молчит второй раз подряд (например, "Извините, вас по-прежнему не слышно"). Если пользователь невнятно пробормотал после состояния 114 "Молчание 1", то в состоянии 118 "Бормотание 1" воспроизводится подсказка (например, "Извините, непонятно, что вы сказали"). Если пользователь пробормотал после основного состояния 112, а не молчания, инициируется другое состояние 120 "Бормотание 1". Если за этим следует молчание, то вызывается состояние 122 "Молчание 1". Если вместо этого следует другое бормотание, то состояние 124 "Бормотание 2" вызывает воспроизведение подсказки, если пользователь молчит второй раз подряд (например, "Извините, опять не понимаю вас. Вот что вы можете сказать…"). Затем состояние 126 справки дает справочные подсказки для этого меню. В качестве альтернативы, ответ от пользователя может быть понят, но являться неподходящим для этого меню, что приводит к состоянию 128 "Неправильная команда" и подсказке (например, "Мы поняли то, что сказал пользователь, но сказанное не является допустимым вариантом в настоящий момент", "Извините, я не могу отменить это совещание, потому что вы не являетесь организатором", повторение последних слов пользователя). После слишком большого количества неудачных попыток (например, некоторая последовательность из трех молчаний или бормотаний) состояние 130 "Речевая ошибка" информирует пользователя об этой неудаче и предпринимает действия по возврату (например, "Извините, не могу вам помочь. Возврат в главное меню").

На Фиг.7, если от пользователя был получен осмысленный ответ, а не бормотание или молчание, то другой аспект, усовершенствованный посредством импорта и условных выражений, состоит в том, каким образом речь пользователя передается на уровень конечного автомата и используется на уровне меню. Например, существует много вариантов, чтобы сказать "да". Вы можете сказать "да, ага, угу, так точно, OK, конечно" и т.д., и все это семантически эквивалентно "да" и изображено номерами 132, 134, 136. С использованием языка семантической разметки (SML), грамматики команд в механизме 138 грамматики определяют значение для "семантического события", которое сообщается конечному автомату, как изображено в виде меню 140 "Да/Нет", которое отвечает на RecoYes диалогом A 142, и на RecoNo диалогом B 144. Меню даже не знает о том, что фактически сказал пользователь.

Вернемся к Фиг.1, на которой с преимуществом функций импорта и условных выражений создан конечный автомат 20 (FSM) системы UM, содержащий ASR 110, код 146 XML, мультимедийные файлы 148, определения 150 классов и ресурсные файлы 152. Хотя кодирование на языке XML имеет много преимуществ, часто может оказаться, что переменные или файлы по ссылке отсутствуют. Такие упущения будут обнаружены весьма поздно в процессе развертывания приложения 14 системы UM. Поэтому инструмент 156 обертки действий/переменных является частью фазы компиляции на языке C#, изображенной как компилятор 158 времени компоновки. Инструмент 156 обертки использует файлы XML конечного автомата и формирует обертки, изображенные как двоичный код 160 времени компоновки системы UM, который дает ссылки на методы и функции, определенные в существующих определениях 161 (кода) на языке C# для своих соответствующих менеджеров. Например, если имеется класс с именем EmailManager, у которого есть метод с именем NextMessage, который возвращает строку, иллюстративная обертка для этого способа может выглядеть следующим образом в примере 6:

1 string NextMessage(EmailManager m)

2 {

3 return m.NextMessage();

4 }

Поскольку части "string NextMessage" строки 1 и "NextMessage" строки 3 объявлены в файлах определения XML и используются для формирования упомянутой выше обертки, строка 3 обертки гарантирует, что во время фазы обычной компиляции класс EmailManager действительно имеет метод с именем NextMessage. Кроме того, строка 3 обертки гарантирует, что метод NextMessage возвращает строку. Если оба условия проверки не удовлетворены, обертка вызовет ошибку компиляции.

Таким образом, использование инструмента 156 обертки гарантирует, что файлы определения XML не могут ссылаться на метод или переменную, которые фактически не существуют в коде 161, который также скомпилирован, и что эти методы и переменные имеют правильный тип (например, булевский). Если файл определения XML должен сослаться на несуществующий метод или переменную, инструмент 156 обертки формирует эти обертки и затем на фазе «компиляции» формирует прерывание компоновки. После успешной компиляции создается двоичный код 160 времени компоновки системы UM для экспорта из среды 10 программирования вместе с файлами 162 определения системы UM.

Например, если класс EmailManager содержит метод с именем NextMessage, и определение XML идентифицировало его как называемый NextMessageItem, и инструмент соответствующим образом сформировал кодовые обертки, фаза компиляции языка C# создаст прерывание компоновки. Затем будет сформирована ошибка времени компиляции, например, "ОШИБКА: класс EmailManager не содержит определение для NextMessageItem". Пример такой реализации дан в виде примера 7:

//

//

// internal class EmailManager

{

internal static void GetScope(Microsoft.Exchange.UM.UMCore.ActivityManager manager, out Microsoft.Exchange.UM.UMCore. EmailManager scope )

{

scope = manager as Microsoft.Exchange.UM.UMCore.EmailManager;

while ( null == scope )

{

if ( null == manager.Manager )

{

throw new FsmConfigurationException(String. Empty);

}

else

{

manager = manager.Manager;

scope = manager as Microsoft.Exchange.UM.UMCore.EmailManager;

}

}

//

// Action Proxies

//

//

internal static TransitionBase NextMessage(Microsoft.Exchange.UM.UMCore.ActivityManager manager, string actionName, BaseUMCallSession vo)

{

Microsoft.Exchange.UM.UMCore.EmailManager scope manager as Microsoft.Exchange.UM.UMCore.EmailManager;

if ( null == scope )

{

GetScope(manager, out scope);

}

return

manager.GetTransition(scope.NextMessage(vo));

}

//

// Variable Proxy

//

//

//

internal static System.Boolean

IsSentImportant(Microsoft.Exchange.UM.UMCore.ActivityManager manager, string variableName)

{

Microsoft.Exchange.UM.UMCore.EmailManager scope = manager as Microsoft.Exchange.UM.UMCore.EmailManager;

if ( null == scope )

{

GetScope(manager, out scope);

}

return scope.IsSentImportant;

}

Вторая часть верификации происходит, когда приложение 14 системы UM установлено и выполняется на машине 16 выполнения системы UM. Когда приложение 14 системы UM запускается, оно считывает конфигурационные файлы 162 XML. Когда приложение 14 системы UM встречает определение XML, например в объекте EmailManager, который вызывает некоторый метод класса EmailManager, отражение 164 платформы .NET, обеспечиваемое платформой Microsoft .NET, находит сформированную обертку в двоичном коде 160 системы UM. Среди прочего отражение 164 платформы .Net позволяет программе, написанной на языке C#, исследовать программную структуру другой программы, написанной на языке C#. Например, программа может просмотреть двоичное информационное содержимое другой программы и перечислить все ее функции и их имена. Если такая обертка не существует, то XML файл не был тем файлом, который использовался во время компоновки для формирования обертки, и выдается ошибка несоответствия версий. В ином случае разрешается выполнение допустимого XML и двоичного кода, как показано номером 166.

Использование отражения платформы .Net дополняет проверки, возможность которых обеспечивается инструментом 156 обертки во время фаз обертки и компиляции. В обоих случаях для кода обертки в примере 6 определения конечного автомата (FSM) проверяются, чтобы определить, что класс, называемый EmailManager, имеет метод с именем NextMessage. На фазе обертки, выполняемой во время компоновки, формируется этот код проверки. На фазе отражения, выполняемой во время выполнения, отражение 164 платформы .Net гарантирует, что функция обертки фактически существует в двоичном коде 160 системы UM. Попытки использовать неправильную или поврежденную версию таким образом могут быть предотвращены.

На Фиг.8 конфигурируемая система 200 обмена сообщениями может быть создана посредством среды 10 программирования. Система 200 включает в себя компонент 210 обмена сообщениями, который взаимодействует с одним или более пользователями и/или автоматизированными приложениями 220, для обеспечения возможности обработки различных приложений передач данных. Компонент 210 обмена сообщениями может быть связан с различными приложениями, такими как приложение унифицированного обмена сообщениями, обработка голосовой почты или в значительной степени любым типом приложения распознавания речи. Как правило, взаимодействия с компонентом 210 обмена сообщениями выполняются через вводы двухтонального многочастотного (DTMF) набора, но может применяться также и другой тип ввода, например речевой или текстовый ввод.

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

Файл 230 конфигурации обычно определяет, например, какие действия должны быть выполнены в диалоговом сеансе 240 и к какому состоянию должен быть выполнен переход после завершения или прерывания заданного действия. Состояниями управляет контроллер 250 состояний, который направляет компонент 260 обработки сообщений (или такие компоненты, как служба) для выполнения некоторого действия в системе 200 (например, записи голосовой почты, воспроизведения сообщения, проверки пользовательского ввода и т.д.). Файл 230 конфигурации позволяет администраторам динамически адаптировать функциональные возможности компонента 210 обмена сообщениями для множества разнообразных приложений передач данных. Это достигается посредством задания диалоговых взаимодействий или команд на расширяемом языке разметки (XML) или на языке другого типа, которые взаимодействуют для управления состоянием компонента 210 обмена сообщениями. В этом случае команды в файле 230 конфигурации устраняют жестко закодированные реализации состояний от контроллера 250 состояний и позволяют администраторам адаптироваться к изменяющимся ситуациям без необходимости изменять контроллер состояний после произведения изменений.

Поскольку переходы к другим состояниям содержатся в файле 230 конфигурации, управление диалогом может быть задано динамически на детальном уровне для заданного диалогового сеанса 240 (например, заданы переходы как группа в пределах файла, а не во внешнем документе), при этом уменьшаются взаимодействия с другими компьютерами/компонентами для определения соответствующих состояний или действий системы 200. Таким образом, заявленное изобретение обеспечивает возможность конфигурирования меню и его переходов для диалогового сеанса 240 в файле XML (или другого типа), а не жесткого кодирования этих аспектов в контроллере 250 состояний. Этот отличительный признак обеспечивает возможность расширения, причем новые меню и переходы могут быть добавлены без изменения компонента 210 обмена сообщениями. Кроме того, файл 230 конфигурации сокращает время на разработку приложения и дает возможность специализированной настройки, посредством чего администратор и конечный пользователь потенциально могут добавлять новые меню и изменять существующие переходы меню для соответствия своим потребностям. Другие аспекты включают в себя языковую поддержку для добавления подсказок, меню и переходов на других языках (например, на немецком, французском, английском языке и т.д.) лишь посредством изменения файла (или файлов) 230 конфигурации, в то время как базовая реализация приложения системы 200 обмена сообщениями может остаться неизменной. Дополнительные аспекты иллюстративного файла конфигурации описаны в общедоступной и находящейся на одновременном рассмотрении заявке на патент США №11/068691, номер публикации 2007/0055751 A1, раскрытие которой включено в настоящий документ по ссылке во всей своей полноте.

На Фиг.9 показан иллюстративный файл 270 конфигурации в соответствии с аспектом заявленного изобретения. Обычно файл