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

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

1. Реализованная с помощью компьютера система для программирования приложения унифицированного обмена сообщениями (UM), содержащая:

пользовательский интерфейс;

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

программный компонент UM, включающий в себя внешний программный компонент, вызываемый посредством FSM UM; и

функцию XML, используемую средой программирования для создания допустимого состояния меню на основе программного компонента UM, причем функция XML включает в себя функцию-обертку, которая используется средой программирования для проверки правильности внешнего программного компонента во время фазы компиляции, когда внешний программный компонент присутствует, и генерирования двоичного FSM UM, и для генерирования ошибки, когда внешний программный компонент отсутствует во время фазы компиляции, и

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

2. Реализованная с помощью компьютера система по п.1, в которой программный компонент UM содержит настройку приложения UM, причем функция XML содержит условный атрибут, предопределяющий переход FSM UM.

3. Реализованная с помощью компьютера система по п.2, в которой условный атрибут содержит атрибут, составленный из контекстной переменной.

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

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

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

7. Реализованная с помощью компьютера система по п.6, в которой фрагмент XML содержит речевое меню, определяющее запросы и переходы в ответ на неотвечаемое произнесение пользователем.

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

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

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

11. Реализованная с помощью компьютера система по п.1, дополнительно содержащая интерфейс двухтонального многочастотного набора (DTFM), который определяет семантическое событие как ввод с клавиатуры с использованием набора DTMF.

12. Способ разработки пользовательского интерфейса для системы унифицированного обмена сообщениями (UM), содержащий этапы:

генерируют посредством по меньшей мере одного вычислительного устройства конечный автомат (FSM), содержащий состояния меню, запрашивающие пользователя, и переходы к следующему состоянию меню в соответствии с ответом пользователя;

генерируют допустимое состояние меню на основе существующего внешнего программного компонента UM посредством использования функции расширяемого языка разметки (XML), при этом генерирование допустимого состояния меню содержит этапы:

генерируют функцию-обертку для упомянутой функции XML,

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

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

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

13. Способ по п.12, в котором генерирование допустимого состояния меню основано на фрагменте XML, дублированном в конечном автомате посредством элемента импорта XML.

14. Способ по п.12, в котором генерирование допустимого состояния меню основано на контекстной переменной, на которую ссылаются посредством условного атрибута XML элемента XML, определяющего запрос или переход.

15. Способ по п.12, в котором генерирование допустимого состояния меню проверяется посредством действий, вызванных обертыванием, и переменных конечного автомата, которые ссылаются во внешнем программном компоненте UM, и созданием ошибки времени компоновки, если не определимо.

16. Способ по п.15, в котором дополнительно проверяют, что внешний программный компонент UM, на который ссылается компилированная версия конечного автомата, является идентичной при выполнении той, которая проверялась.

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

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

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

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

Технологии передач данных находятся на переднем крае быстро изменяющихся требований информационной эпохи. Лишь несколько лет назад технологии факсимильных машин угрожали традиционному способу приема информации по почте посредством электронного кодирования информационного содержания и доставки сообщений по телефонным линиям. Эта технология полностью изменила способ, посредством которого велся бизнес в течение сотен лет. Почти в то же время, когда факсимильные машины стали вездесущими, новая технология, известная как электронная почта или 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 конфигурации в соответствии с аспектом заявленного изобретения. Обычно файл 270 конфигурации включает в себя элементы действий, элементы подсказок и элементы переходов, которые размещены в одной или более группах диалоговых команд, проиллюстрированных номером 280 (например, группа 101, 102, 103 и т.д.), причем такие группы задают операции пользовательского интерфейса или меню для взаимодействия с системой передач данных или обмена сообщениями. Например, в конфигурационном файле XML описан телефонный интерфейс пользователя (TUI) для примера унифицированного обмена сообщениями. Элементы с атрибутом "id" описывают действие. Например, Меню, Запись и т.д. являются примерами действий. Элементы подсказок представляют собой подсказки, которые должны воспроизводиться для конечного пользователя, тогда как элементы переходов описывают следующее действие, которое будет выполнено, и действие, которое будет предпринято перед переходом.

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

На Фиг.10 показана иллюстративная унифицированная система 300 обмена сообщениями в соответствии с аспектом заявленного изобретения. В этом примере система 300 изображает, как унифицированная система 300 обмена сообщениями взаимодействует в контексте частной телефонной станции (PBX) 310 и шлюза 320 протокола инициации сеанса (SIP). Шлюз 320 может направлять вызовы 330 (по проводной или беспроводной связи) к унифицированной системе 300 обмена сообщениями по сети 340 протокола IP с использованием протокола SIP. Это позволяет унифицированной системе 300 обмена сообщениями не быть расположенной вместе с PBX 310. Другие компоненты могут включать в себя почтовый сервер 350 для хранения сообщений и активный каталог 360 для управления сообщениями. Как проиллюстрировано, унифицированная система 300 обмена сообщениями может включать в себя такие компоненты, как преобразователь текста в речь (TTS) и механизм 370 распознавания речи для обработки входящих вызовов 330, хотя также могут быть обеспечены компоненты другого типа, например, управления DTMF. Благодаря настоящему раскрытию очевидно, что может быть обеспечена служба унифицированного обмена сообщениями или служба(не показана), которая загружает и выполняет файл конфигурации для создания сеанса интерфейса для взаимодействия с пользователями (или приложениями), формирующими вызовы 330. Это может включать в себя работу различных объектов и классов, которые управляют работой состояний системы 300.

На Фиг.11 среда программирования 10, изображенная на Фиг.1, преимущественно поддерживает и улучшает локализацию подсказок сообщений, как описано в общедоступной и находящейся на одновременном рассмотрении заявке на патент США № 11/238521, номер публикации 2007/0073544 A1, раскрытие которой включено в настоящий документ по ссылке во всей своей полноте. Система 400 имеет компьютер 402, исполняемый на компьютере код 404, таблицу 406 определения классов, ресурсные файлы 408 и локализованные мультимедийные файлы 410. Компьютер 402 выполняет код 404, который определяет метод для воспроизведения подсказок (например, воспроизведение звуковых файловых образцов речевых подсказок). Система 400 преимущественно позволяет отдельно и индивидуально модифицировать или перевести на язык локализации ресурсные строки и мультимедийные файлы, не внося каких-либо модификаций в код 404. Это существенное преимущество позволяет программистам написать код 404 один раз для использования на многих других языках локализации. Когда код 404 создан и ресурсные строки созданы на некотором языке (например, на английском языке), переводчики могут сделать обзор ресурсных строк и обеспечить локализованные переводы ресурсных строк (например, на французский язык). Затем переводы сохраняются в локализованных ресурсных файлах для французского языка. Аналогичным образом переводчики могут сделать запись речевых мультимедийных отрывков ресурсных строк и фрагментов ресурсных строк на языке локализации (например, на французском языке) и сохранить записи как локализованные мультимедийные файлы, которые доступны компьютеру 402 при воспроизведении локализованных мультимедийных отрывков по мере вызова посредством кода 404.

Например, код 404 задает создание имени (например, "Messages"), присвоенного VariableName на основе значения, присвоенного переменной KEY. Компьютер 402 обращается к таблице 406 определения классов, чтобы идентифицировать грамматическую переменную (например, "Plural"), которая соответствует значению переменной KEY. Код 404 создает новое имя (например, "Messages_Plural"), присваивает новое имя переменной VariableName и дает компьютеру 402 команду идентифицировать мультимедийные файлы, которые соответствуют переменной VariableName (то есть, "Messages_Plural"). Компьютер 402 обращается к ресурсным файлам 408 и определяет местонахождение ресурсной строки, которая соответствует переменной VariableName. Компьютер 402 анализирует ресурсную строку и определяет мультимедийный файл (файлы), который соответствуют ресурсной строке и порядку мультимедийного файла (файлов) в ресурсной строке. Компьютер 402 обращается к мультимедийному файлу (файлам), который соответствуют ресурсной строке, из локализованных мультимедийных файлов 410. Затем код 404 дает компьютеру 402 команду воспроизвести локализованные мультимедийные файлы в грамматически правильном порядке, который идентифицирован в ресурсной строке.

В одной версии таблица 406 определений классов содержит грамматическую переменную, возможно, префикс, суффикс или их комбинацию. Затем грамматическая переменная добавляется к имени, присвоенному переменной VariableName, с тем чтобы она соответствовала грамматически правильному ресурсному файлу ресурсной строки, соответствующему числовому значению переменной KEY. Например, если значение переменной KEY равно "1", то соответствующая ресурсная строка будет являться строкой, которая грамматически правильна для единственного значения (например, "You have 4 new messages "; "У вас 4 новых сообщения"). Если значение переменной KEY равно "5", то соответствующая ресурсная строка будет являться строкой, которая грамматически правильна для множественного значения (например, "You have 5 new messages"; "У вас 5 новых сообщений"). В качестве альтернативы, если значение переменной KEY равно "0", то соответствующая ресурсная строка будет являться строкой, которая грамматически правильна для нулевого значения (например, "You have no new messages"; "У вас нет новых сообщений").

В другой версии ресурсные строки, расположенные в ресурсных файлах 408, являются отдельными от кода 404 и могут быть переведены переводчиками на языки локализации на неанглийский язык без необходимости модификации или повторной компиляции кода 404. Во время перевода ресурсная строка и числовые переменные могут быть переведены на язык локализации, и ресурсная строка и числовые значения могут быть перестроены в грамматически правильном порядке для языка перевода. Например, грамматически правильный порядок и время для английской ресурсной строки "You have" {0} "new messages" содержит два текстовых фрагмента "You have" и "new messages", где в этом примере "{0}" является множественным числовым значением. Однако если ресурс был переведен на французский язык, грамматически правильный порядок и время могут представлять собой {0} "nouveaux messages sont arrives", причем числовая переменная находится в начале предложения, указывающего, что были приняты два или более сообщений.

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

Таким образом, благодаря предшествующему раскрытию очевидно, что аспекты могут включать в себя приложения системы UM только с использованием двухтонального многочастотного набора (DTMF), приложения системы UM только с использованием автоматизированного распознавания речи (ASR) или гибридные приложения системы UM с использованием двухтонального многочастотного набора (DTMF) и автоматизированного распознавания речи (ASR).

На Фиг.12 показано, что иллюстративная среда 910 для реализации различных аспектов изобретения включает в себя компьютер 912. Компьютер 912 включает в себя процессор 914, системную память 916 и системную шину 918. Системная шина 918 присоединяет системные компоненты, в том числе, но без ограничения, системную память 916 к процессору 914. Процессор 914 может представлять собой любой из различных доступных микропроцессоров. Двойные микропроцессоры и другие многопроцессорные архитектуры также могут использоваться в качестве процессора 914.

Системная шина 918 может быть шинной структурой любого из нескольких типов, в том числе шиной памяти или контроллером памяти, периферийной шиной или внешней шиной и/или локальной шиной, использующей любое разнообразие доступных шинных архитектур, таких как, но без ограничения, 11-разрядная шина, стандартная промышленная архитектура (ISA), микроканальная архитектура (MSA), расширенная стандартная промышленная архитектура (EISA), интерфейс IDE, локальная шина VESA (VLB), стандарт PCI, универсальная последовательная шина (USB), усовершенствованный графический порт (AGP), шина стандарта международной ассоциации производителей карт памяти для персональных компьютеров (PCMCIA) и интерфейс малых вычислительных систем (SCSI).

Системная память 916 включает в себя энергозависимую память 920 и энергонезависимую память 922. Базовая система ввода-вывода (BIOS), содержащая основные подпрограммы для переноса информации между элементами в пределах компьютера 912, например, во время запуска, хранится в энергонезависимой памяти 922. Для иллюстрации, но без ограничения, энергонезависимая память может включать в себя постоянное запоминающее устройство (ROM; ПЗУ), программируемое постоянное запоминающее устройство (PROM; ППЗУ), электрически программируемое постоянное запоминающее устройство (EPROM; ЭППЗУ), электрически стираемое программируемое постоянное запоминающее устройство (EEPROM; ЭСППЗУ) или флэш-память. Энергозависимая память может включать в себя оперативное запоминающее устройство (RAM; ОЗУ), которое действует как внешняя кэш-память. Для иллюстрации, но без ограничения, оперативное запоминающее устройство является доступным во многих формах, таких как синхронное оперативное запоминающее устройство (SRAM), динамическое оперативное запоминающее устройство (DRAM), синхронное динамическое оперативное запоминающее устройство (SDRAM), синхронное динамическое оперативное запоминающее устройство с удвоенной скоростью передачи данных (DDR SDRAM), усовершенствованное синхронное динамическое оперативное запоминающее устройство (ESDRAM), динамическое оперативное запоминающее устройство Synchlink (SLDRAM) и оперативное запоминающее устройство Rambus (DRRAM).

Компьютер 912 также включает в себя съемные или несъемные, энергозависимые или энергонезависимые компьютерные носители данных. Фиг.12 иллюстрирует, например, дисковую память 924. Дисковая память 924 включает в себя, но без ограничения, такие устройства, как накопитель на магнитных дисках, накопитель на гибких магнитных дисках, накопитель на магнитной ленте, накопители "Jaz drive", накопители "Zip drive", накопители LS-100, карта флэш-памяти или флэш-карта. Кроме того, дисковая память 924 может включать в себя носители данных отдельно или в комбинации с другими носителями данных, такими как, но без ограниченная, накопитель на оптических дисках, например, постоянное запоминающее устройство на компакт-диске (CD_ROM), накопитель на однократно записываемом компакт-диске (CD-R), накопитель на многократно записываемом компакт-диске (CD-RW) или накопитель на цифровом универсальном диске (DVD-ROM). Для обеспечения возможности соединения устройств 924 дисковой памяти с системной шиной 918 обычно используется, например, съемный или несъемный интерфейс, такой как интерфейс 926.

Очевидно, что Фиг.12 описывает программное обеспечение, которое выступает в качестве посредника между пользователями и основными компьютерными ресурсами, описанными в подходящей рабочей среде 910. Такое программное обеспечение включает в себя операционную систему 928. Операционная система 928, которая может храниться в памяти 924 на диске, управляет и выделяет ресурсы компьютерной системы 912. Системные приложения 930 используют преимущества управления ресурсами посредством операционной системы 928 через программные модули 932 и программные данные 934, хранящиеся в системной памяти 916 или в памяти 924 на диске. Следует понимать, что заявленное изобретение может быть реализовано с помощью разных операционных систем или комбинаций операционных систем.

Пользователь вводит команды или информацию в компьютер 912 через устройство (устройства) 936 ввода данных. Устройства 936 ввода включают в себя, но без ограничения, указательное устройство, например, мышь, шаровой указатель, перо, сенсорную клавиатуру, клавиатуру, микрофон, джойстик, игровую клавиатуру, спутниковую антенну, сканер, карту телевизионного приемника, цифровую камеру, цифровую видеокамеру, веб-камеру и т.п. Эти и другие устройства ввода данных соединяются с процессором 914 через системную шину 918 через интерфейсный порт (порты) 938. Интерфейсный порт (порты) 938 включает в себя, например, последовательный порт, параллельный порт, игровой порт и универсальную последовательную шину (USB). Устройство (устройства) 940 вывода используют некоторые из портов того же типа, как и устройство (устройства) 936 ввода данных. Таким образом, например, порт USB может использоваться для обеспечения ввода в компьютер 912 и вывода информации из компьютера 912 на устройство 940 вывода. Адаптер 942 вывода обеспечивается для иллюстрации того, что имеются некоторые устройства 940 вывода, как мониторы, динамики и принтеры, среди других устройств 940 вывода, которые требуют специальные адаптеры. Адаптеры 942 вывода включают в себя для примера, но без ограничения, видео и звуковые карты, которые обеспечивают средство соединения между устройством 940 вывода и системной шиной 918. Следует отметить, что другие приборы и/или системы приборов обеспечивают возможности как ввода, так и вывода, например, удаленный компьютер (компьютеры) 944.

Компьютер 912 может работать в сетевом окружении с использованием логических соединений с одним или более удаленными компьютерами, например, удаленным компьютером (компьютерами) 944. Удаленный компьютер (компьютеры) 944 может являться персональным компьютером, сервером, маршрутизатором, сетевым персональным компьютером, рабочей станцией, бытовым прибором на основе микропроцессора, одноранговым прибором или другим общим сетевым узлом и т.п., и обычно включает в себя многие или все элементы, описанные в отношении компьютера 912. В целях краткости с удаленным компьютером (компьютерами) 944 проиллюстрировано только запоминающее устройство 946. Удаленный компьютер (компьютеры) 944 логически соединен с компьютером 912 через сетевой интерфейс 948 и затем физически соединен через соединение 950 передачи данных. Сетевой интерфейс 948 охватывает сети передач данных, например, локальные сети (LAN) и глобальные сети (WAN). Технологии локальных сетей включают в себя распределенный интерфейс передачи данных по волоконно-оптическим каналам (FDDI), распределенный интерфейс передачи данных по медным кабелям (CDDI), стандарт Ethernet/IEEE 802.3, стандарт Token Ring/IEEE 802.5 и т.п. Технологии WAN включают в себя, но без ограничения, двухточечную связь, сети с коммутацией каналов, такие как цифровая сеть комплексного обслуживания (ISDN) и ее варианты, сети с коммутацией пакетов и цифровые абонентские линии (DSL).

Соединение (соединения) 950 передач данных обращается к аппаратным и программным средствам, используемым для соединения сетевого интерфейса 948 с шиной 918. Хотя соединение 950 передач данных показано для ясности иллюстрации внутри компьютера 912, оно также может быть внешним по отношению к компьютеру 912. Аппаратные и программные средства, необходимые для соединения с сетевым интерфейсом 948, включают в себя только с целью иллюстрации такие внутренние и внешние технологии, как модемы, в том числе обычные телефонные модемы, кабельные модемы и модемы DSL, адаптеры ISDN и карты Ethernet.

Фиг.13 является блок-схемой иллюстративной компьютерной среды 1000, с которой может взаимодействовать заявленное изобретение. Система 1000 включает в себя один или более клиентов 1010. Клиент (клиенты) 1010 может представлять собой аппаратное и/или программное средство (например, потоки, процессы, вычислительные устройства). Система 1000 также включает в себя один или более серверов 1030. Сервер (серверы) 1030 также может представлять собой аппаратные и/или программные средства (например, потоки, процессы, вычислительные устройства). Серверы 1030 могут содержать потоки для выполнения преобразований, например, с использованием заявленного изобретения. Одно возможное взаимодействие между клиентом 1010 и сервером 1030 может быть в виде пакета данных, выполненного с возможностью быть переданным между двумя или более компьютерными процессами. Система 1000 включает в себя структуру 1050 передач данных, которая может использоваться для обеспечения передачи данных между клиентом (клиентами) 1010 и сервером (серверами) 1030. Клиент (клиенты) 1010 соединены с возможностью взаимодействия с одним или более клиентским хранилищем (хранилищами) 1060 данных, которое может использоваться для хранения информации, локальной по отношению к клиенту (клиентам) 1010. Аналогично сервер (серверы) 1030 соединен с возможностью взаимодействия с одним или более хранилищем (хранилищами) 1040 данных сервера, которое может использоваться для хранения информаций, локальной по отношению к серверам 1030.

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

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