Система и способ интерфейса динамического мастера

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

 

ПЕРЕКРЕСТНАЯ ССЫЛКА НА РОДСТВЕННЫЕ ЗАЯВКИ

Настоящее изобретение связано с одновременно поданными 3 июня 2002 г. заявками "XGL и мультиплатформный процессор пользовательского интерфейса" и "XGL и система и способ динамической доступности".

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

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

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

Коммуникационные сети хорошо известны в области компьютерных коммуникаций. По определению, сеть - это группа компьютеров и связанных устройств, которые подсоединены с помощью средств связи или линий связи. По своей природе сетевые коммуникации могут быть постоянного характера, например, осуществленные с использованием кабелей, или временного характера, например, соединения, осуществляемые посредством телефонных или беспроводных линий связи. Сети могут варьироваться по размеру от локальной сети (ЛС (LAN)), состоящей из нескольких компьютеров или рабочих станций и относящихся к ним устройств, до глобальной сети (ГС (WAN)), которая связывает между собой компьютеры и ЛС, которые территориально рассредоточены, и услуги удаленного доступа (УУД (RAS)), которая обеспечивает межсоединение удаленных компьютеров через временные линии связи. Межсетевое взаимодействие, в свою очередь, предусматривает соединение многочисленных компьютерных сетей, как сходных, так и различающихся, посредством шлюзов или маршрутизаторов, которые облегчают передачу данных и преобразование из различных сетей. Известным сокращенным термином для межсетевого взаимодействия служит "Интернет". В настоящее время написание термина "Интернет" с заглавной буквы обычно относится к совокупности сетей и маршрутизаторов, которые используют Интернет-протокол (IP), наряду с протоколами более высокого уровня, такими как протокол управления передачей/Интернет-протокол (TCP/IP) или протокол передачи дейтаграмм пользователя/Интернет-протокол (UDP/IP), которые служат для обеспечения связи друг с другом.

За последние годы Интернет стремительно вырос, благодаря своей способности обеспечивать связь с компьютерами, расположенными по всему миру. Другие интерактивные среды могут включать в себя частные среды, например, такие, которые выполнены с помощью сети компании Майкрософт (Microsoft) (MSN), или другие провайдеры онлайновых услуг, а также "беспроводная всемирная паутина" ("wireless Web"), обеспечиваемая различными провайдерами межсетевого взаимодействия, особенно в индустрии сотовых телефонов. Как следует из последующего описания, настоящее изобретение может применяться в любых таких интерактивных средах, однако, в целях обсуждения, Интернет используется как пример интерактивной среды для осуществления настоящего изобретения.

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

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

Одновременно с развитием Интернета появился ряд усовершенствований в графических пользовательских интерфейсах (ГПИ (GUIs)) для компьютерных систем. Один такой ГПИ известен под названием "интерфейс мастера", а также в некоторых случаях под названием "интерфейсы помощников". Интерфейсы мастеров представляют собой, в общем, структурированный ряд страниц или диалогов, которые взаимодействуют с процессором мастера, давая возможность пользователю получить результат. Все интерфейсы мастеров и процессоры мастеров упоминаются здесь как мастера. В отличие от других форм ГПИ, таких как обучающие программы и экранные изображения с оперативной подсказкой, мастера, кроме того, выполняют одну или более задач. С тех пор, как были введены интерфейсы мастеров, как показано в патенте США № 5301326, текст и чертежи которого включены в настоящую заявку посредством ссылки, они получили широкое признание в качестве способа выработки руководящих указаний для конечных пользователей при реализации сложных задач. По мере роста их признания росла и сложность задач, которые мастера должны решать. Кроме того, из-за повышенной степени их использования, специалисты различных профилей внесли свой вклад в создание мастеров.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

фиг.1 (предшествующий уровень техники) является иллюстрацией представительной части сетевого комплекса, такого как Интернет;

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

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

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

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

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

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

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

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

фиг.10 - общий алгоритм, иллюстрирующий подпрограмму обработки контейнера, выполняемую клиентским устройством, согласно настоящему изобретению;

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

фиг.12 - общий алгоритм, иллюстрирующий подпрограмму разбивки, реализуемый клиентским устройством согласно настоящему изобретению;

фиг.13 - общий алгоритм, иллюстрирующий объектную подпрограмму преобразования, выполняемую клиентским устройством, согласно настоящему изобретению;

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

фиг.15 - общий алгоритм, иллюстрирующий подпрограмму создания списка материалов, выполняемую клиентским устройством, согласно настоящему изобретению;

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

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

фиг.18A-18C - примеры страниц интерфейса мастера согласно настоящему изобретению;

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

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

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

фиг.22 - общий алгоритм, иллюстрирующий подпрограмму обработки объекта действия, выполняемую клиентским устройством, согласно настоящему изобретению;

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

фиг.24A - пример страницы интерфейса мастера согласно настоящему изобретению;

фиг.24B - пример страницы интерфейса мастера с улучшенной доступностью согласно настоящему изобретению.

ПОДРОБНОЕ ОПИСАНИЕ ПРЕДПОЧТИТЕЛЬНОГО ВАРИАНТА ОСУЩЕСТВЛЕНИЯ

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

Как объяснено ранее, термин "Интернет", который пишется с заглавной буквы, относится к совокупности сетей и маршрутизаторов, которые поддерживают связь друг с другом. Представительная часть Интернета 100 показана на фиг.1. Предшествующий уровень техники, а более конкретно - представительная часть Интернета 100, показанная на фиг.1, включает в себя множество ЛС 120 и ГС 130, связанных между собой маршрутизаторами 110. Маршрутизаторы 110 представляют собой в общем компьютеры специального назначения, которые используются для сопряжения одной ЛС или ГС с другой. Коммуникационные линии связи внутри ЛС могут быть выполнены с помощью витой пары, коаксиального кабеля или любой другой хорошо известной технологии коммуникационного соединения, включая и беспроводную технологию. Коммуникационные линии связи между сетями могут быть сформированы с помощью аналоговых телефонных линий, рассчитанных на скорость передачи 56 Кбит/с, или цифровых линий T-1, рассчитанных на скорость передачи 1 Мбит/с, и/или линий T-3, рассчитанных на скорость передачи 45 Мбит/с, или с помощью любой другой известной технологии коммуникационного соединения, включая и беспроводную технологию. Кроме того, компьютеры и другие соответствующие электронные устройства 140 можно дистанционно подсоединить к ЛС 120 или ГС 130 через модем и временную телефонную линию связи, включая и беспроводную телефонную линию связи. Такие компьютеры и электронные устройства 140 показаны на фиг.1 как подсоединенные к ЛС 120. Следует учитывать, что Интернет 100 содержит огромное число таких взаимосвязанных сетей, компьютеров и маршрутизаторов и что, только малая, представительная часть Интернета 100 показана на фиг.1.

На фиг.2 изображена функциональная блок-схема системы 200 для обеспечения интерфейса динамического мастера. Хотя система 200 в общем работает в распределенной вычислительной среде, содержащей отдельные компьютерные системы, взаимосвязанные по сети (такой как Интернет 100), специалистам должно быть понятно, что система 200 может в равной степени функционировать как одиночная автономная компьютерная система. Система 200, показанная на фиг.2, включает в себя клиентское устройство 300, сервер 400 XGL и пользовательскую базу 210 данных, связанные между собой по сетевому комплексу, такому как Интернет 100. Кроме того, на фиг.2 показана база 449 данных XGL, которая поддерживает связь с сервером 400 XGL. Специалистам должно быть понятно, что база 449 данных XGL может постоянно храниться на сервере 400 XGL, или что она может постоянно храниться на другом вычислительном устройстве. Клиентское устройство 300 и сервер 400 XGL дополнительно описаны ниже со ссылкой, соответственно, на фиг.3 и 4. Кроме того, хотя показано только одно клиентское устройство 300, понятно, что многочисленные клиентские устройства 300 могут быть включены в систему 200.

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

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

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

Как показано на фиг.3, образцовое клиентское устройство 300, подходящее для использования при осуществлении изобретения, представляет собой вычислительное устройство общего назначения в виде компьютера 320. Компоненты компьютера 320 включают в себя, но не ограничиваются, процессор 322, системную память 324, дисплей 390 и системную шину 326, которая подсоединяет различные компоненты системы, включая системную память 324, к процессору 322. Системная шина 325 может быть любой из нескольких типов структур шины, включающей в себя шину памяти или контроллер памяти, периферийную шину и локальную шину, использующую любое из множества шинных архитектур.

Например, такие архитектуры включают, не ограничиваясь этим, шину стандартной промышленной архитектуры (ISA), шину микроканальной архитектуры (MCA), шину расширенной стандартной архитектуры для промышленного применения (EISA), локальную шину Ассоциации по стандартам в области видеоэлектроники (VESA) и локальную шину для соединения периферийных устройств (PCI), известную также, как шина расширения, и шину ускоренного графического порта (AGP).

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

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

Системная память 324 включает в себя компьютерные носители информации в виде энергозависимой и энергонезависимой памяти, такой как постоянное запоминающее устройство (ПЗУ, ROM) 328 и оперативное запоминающее устройство (ОЗУ, RAM) 320. Базовая система 332 ввода-вывода (БСВВ, BIOS), содержащая базовые подпрограммы, которые помогают переносить информацию между элементами внутри компьютера 320, например, во время запуска, обычно хранится в ПЗУ 328. ОЗУ 330 обычно содержит данные и/или программные модули, к которым непосредственно обращаются и/или которыми оперируют в текущий момент времени с помощью процессора 322. Например, но не для ограничения, на фиг.1 изображена операционная система 346, прикладные программы 348, процессор 349 мастера для обработки динамических мастеров другие программные модули 350 и данные 352 программы. Компьютер 110 может также включать в себя другие съемные/несъемные и энергозависимые/энергонезависимые компьютерные носители информации. Например, на фиг.1 изображен накопитель 334 жесткого диска, который считывает или записывает на съемный, энергонезависимый магнитный носитель информации, накопитель 338 магнитного диска, который считывает или записывает на съемный, энергонезависимый магнитный диск 340, и накопитель 342 оптического диска, который считывает или записывает на съемный, энергонезависимый оптический диск 344, такой как КД-ПЗУ или другой оптический носитель информации. Другие съемные/несъемные, энергозависимые/энергонезависимые компьютерные носители информации, которые могут использоваться в примерной операционной среде, включают в себя, но не ограничены этим, кассеты с магнитной лентой, платы флэш-памяти, цифровые универсальные диски, цифровые видеоленты, картриджи с головкой Бернулли, твердотельные ОЗУ, твердотельные ПЗУ и тому подобное. Накопитель 334 жесткого диска, накопитель 338 магнитного диска и накопитель 342 оптического диска можно подсоединить к системной шине 326, соответственно, с помощью интерфейса 354 накопителя жесткого диска, интерфейса 356 накопителя магнитного диска и интерфейса 358 накопителя оптического диска. С другой стороны, накопитель 334 жесткого диска, накопитель 338 магнитного диска или накопитель 342 оптического диска можно подсоединить к системной шине 326 с помощью интерфейса малых компьютерных систем (SCSI).

Накопители и связанные с ними компьютерные носители информации, обсужденные выше и изображенные на фиг.3, обеспечивают хранение команд, считываемых с помощью компьютера, структур данных, программных модулей и других данных, поступающих из компьютера 320. На фиг.3, например, накопитель 334 жесткого диска может также хранить операционную систему 346, прикладные программы 348, процессор 349 мастера, другие программы 350 и данные 147 программы. Следует обратить внимание, что эти компоненты могут быть одинаковыми или отличаться от операционной системы 346, других программных модулей 350 и данных 352 программы. Пользователь может вводить команды и информацию в компьютер 320 через устройство ввода, такое как клавиатура 162 и/или координатно-указательное устройство 362, которое обычно называется мышью, шаровым указателем или сенсорной клавиатурой. Другие устройства ввода (не показаны) могут включать в себя микрофон, джойстик, игровую панель, спутниковую антенну, сканер и тому подобное. Эти и другие устройства ввода часто подсоединяются к системной шине 326 через пользовательский интерфейс 364 и могут подсоединяться с помощью другого интерфейса и шинных структур, таких как параллельный порт, игровой порт или универсальная последовательная шина (USB).

Компьютер 320 может работать в сетевой среде, использующей логические соединения с одним или более удаленными компьютерами 140. Удаленный компьютер 140 может быть персональным компьютером, сервером, маршрутизатором, сетевым ПК, одноранговым устройством или другим общим сетевым узлом, и обычно включает в себя многие или все элементы, описанные выше по отношению к компьютеру 320. Логические соединения, изображенные на фиг.3, включают в себя ЛС 120 и ГС 130, но могут также включать в себя другие сети. Такие среды с организацией сети являются обычными в офисах, корпоративных компьютерных сетях, внутренних сетях и Интернете.

При использовании в среде с организацией сети ЛС, компьютер 320 подсоединен к ЛС 120 через сетевой интерфейс 368. При использовании среды с организацией сети ГС, компьютер обычно включает в себя модем или другое средство для установления связи по ГС 130, включающее в себя сетевой интерфейс 368 по ГС 130, такой как Интернет. Модем 369, который может быть внутренним или внешним, может быть подсоединен к системной шине 326 через интерфейс 364 пользовательского ввода или другой соответствующий механизм. Следует понимать, что показанные сетевые соединения приведены для примера, и можно использовать другое средство установления линии связи между компьютерами. Хотя много других внутренних компонентов компьютера 320 не показано, специалистам должно быть понятно, что такие компоненты и их межсоединения известны. Соответственно, дополнительные подробности, относящиеся к внутреннему построению компьютера 320, необязательно раскрывать в настоящем изобретении.

Специалистам понятно, что программные модули, такие как операционная система 346, прикладные программы 348, процессор 349 мастера и данные 352 подаются в компьютер 320 через одно из своих запоминающих устройств, которые могут включать в себя ПЗУ 328, ОЗУ 330, накопитель 334 жесткого диска, накопитель 338 магнитного диска или накопитель 342 оптического диска. Накопитель 334 жесткого диска используется для хранения данных 352 и программ, включая операционную систему 346 и прикладные программы 348.

При включении или сбросе компьютера 320, БСВВ 332, которая хранится в ПЗУ, выдает команды в процессор 322 для загрузки операционной системы 346 с накопителя 334 жесткого диска в ОЗУ 330. Сразу после загрузки операционной системы 346 в ОЗУ 330, процессор 322 выполняет код операционной системы и вызывает отображение на экране монитора визуальных элементов, связанных с пользовательским интерфейсом операционной системы. Когда пользователь открывает прикладную программу 348, код программы и релевантные данные считываются с накопителя 334 жесткого диска и сохраняются в ОЗУ 330.

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

Как показано на фиг.4, пример сервера 400, подходящего для осуществления изобретения, также представляет собой вычислительное устройство общего назначения в виде компьютера 420. Компоненты компьютера 420 могут включать в себя, но не ограничиваться, процессор 422, системную память 424, дисплей 490 и системную шину 426, которая соединяет различные компоненты системы, включая системную память 424 с процессором 120. Системная шина 425 может быть любой из нескольких типов шинных структур, включая шину памяти или контроллер памяти, периферийную шину и локальную шину, использующую любую из множества архитектур шины. Например, но не ограничиваясь этим, такие архитектуры включают в себя шину ISA, шину MCA, шину EISA, локальную шину VESA и шину PCI, известную также, как шина расширения, и шину AGP.

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

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

Системная память 424 включает в себя компьютерные носители информации в виде энергозависимой и энергонезависимой памяти, такой как ПЗУ 428 и ОЗУ 430. Система 432 БСВВ 432, содержащая базовые подпрограммы, которые помогают переносить информацию между элементами внутри компьютера 420, например, во время запуска, обычно хранится в ПЗУ 428. ОЗУ 430 обычно содержит данные и/или программные модули, к которым непосредственно обращаются и/или которыми оперируют в текущий момент времени с помощью процессора 422. Например, но не для ограничения, на фиг.4 изображены операционная система 446, прикладные программы 448, другие программные модули 450 и данные 452 программы. Кроме того, как постоянно хранящаяся в системной памяти 424 показана база 449 данных XGL.

Компьютер 420 может также включать в себя съемные/несъемные, энергозависимые/энергонезависимые компьютерные носители информации. Например, на фиг.4 изображен накопитель 434 жесткого диска, который считывает или записывает на несъемный энергонезависимый магнитный носитель 436 информации, накопитель 438 магнитного диска, который считывает или записывает на съемный, энергонезависимый магнитный диск 440, и накопитель 442 оптического диска, который считывает или записывает на съемный, энергонезависимый оптический диск 444, такой как КД-ПЗУ или другие оптические носители информации. Другие съемные/несъемные, энергозависимые/энергонезависимые компьютерные носители информации, которые могут использоваться в приведенной для примера операционной среде, включают в себя, но не ограничиваются, кассеты с магнитной лентой и платы флэш-памяти, ЦУД, цифровые видеоленты, картриджи с головкой Бернулли, твердотельные ОЗУ, твердотельные ПЗУ и тому подобное. Накопитель 434 жесткого диска, накопитель 438 магнитного диска и накопитель 442 оптического диска можно подсоединить к системной шине 426 с помощью, соответственно, интерфейса 454 накопителя жесткого диска, интерфейса 456 накопителя магнитного диска или интерфейса 458 накопителя оптического диска. С другой стороны, накопитель 434 жесткого диска, накопитель 438 магнитного диска или накопитель 442 оптического диска можно подсоединить к системной шине 426 с помощью соединения SCSI.

Накопители и связанные с ними компьютерные носители информации, обсужденные выше и изображенные на фиг.4, обеспечивают хранение команд, считываемых с помощью компьютера, структур данных, программных модулей и других данных, поступающих из компьютера 420. На фиг.4, например, накопитель 434 жесткого диска может также хранить операционную систему 446, прикладные программы 448, другие программы 450, данные 452 программы и базу 449 данных XGL. Следует отметить, что эти компоненты могут быть одинаковыми или отличаться от операционной системы 446, других программных модулей 450 и данных 452 программы. Пользователь может вводить команды и информацию в компьютер 420 через устройство ввода, такое как клавиатура 460 и/или координатно-указательное устройство 462, которое обычно называют мышью, шаровым указателем или сенсорной клавиатурой. Другие устройства ввода (не показаны) могут включать в себя микрофон, джойстик, игровую панель, спутниковую антенну, сканер и тому подобное. Эти и другие устройства ввода часто подсоединяются к системной шине 426 через пользовательский интерфейс 464 и могут подсоединяться с помощью другого интерфейса и шинных структур, таких как параллельный порт, последовательный порт, игровой порт, USB или другой интерфейс.

Компьютер 420 может работать в сетевой среде, использующей логические соединения с одним или более удаленными компьютерами 140. Удаленный компьютер 140 может представлять собой персональный компьютер, сервер, маршрутизатор, сетевой ПК, одноранговое устройство или другой общий сетевой узел и обычно включает в себя многие или все элементы, описанные выше по отношению к компьютеру 420. Логические соединения, изображенные на фиг.4, включают в себя ЛС 120 и ГС 130, но могут также включать в себя другие сети. Такие среды с организацией сети являются обычными в офисах, корпоративных компьютерных сетях, внутренних сетях и Интернете 100.

При использовании в среде с организацией сети ЛС, компьютер 420 подсоединен к ЛС 120 через сетевой интерфейс 468. При использовании среды с организацией сети ГС, компьютер обычно включает в себя модем или другое средство для установления связи по ГС 130, включающее в себя сетевой интерфейс 468, по ГС 130, такой как Интернет 100. Модем 469, который может быть внутренним или внешним, можно подсоединить к системной шине 426 через интерфейс 464 пользовательского ввода или другой соответствующий механизм. Следует понимать, что показанные сетевые соединения приведены для примера и можно использовать другое средство установления линии связи между компьютерами. Хотя много других внутренних компонентов компьютера 420 не показано, специалистам понятно, что такие компоненты и их межсоединения известны. Соответственно, дополнительные подробности, относящиеся к внутреннему построению компьютера 420, необязательно раскрывать в настоящем изобретении.

Специалистам понятно, что программные модули, такие как операционная система 446, прикладные программы 448 и данные 452 подаются в компьютер 420 через одно из запоминающих устройств, которые могут включать в себя ПЗУ 428, ОЗУ 430, накопитель 434 жесткого диска, накопитель 438 магнитного диска или накопитель 442 оптического диска. Накопитель 434 жесткого диска используется для хранения данных 452 и программ, включая операционную систему 446 и прикладные программы 448.

При включении или сбросе компьютера 420, БСВВ 432, которая хранится в ПЗУ, выдает команды в процессор 422 для загрузки операционной системы 446 с накопителя 434 жесткого диска в ОЗУ 430. Сразу после загрузки операционной системы 446 в ОЗУ 430, процессор 422 выполняет код операционной системы и вызывает отображение на экране монитора визуальных элементов, связанных с пользовательским интерфейсом операционной системы. Когда пользователь открывает прикладную программу 448, код программы и релевантные данные считываются с накопителя 434 жесткого диска и сохраняются в ОЗУ 430.

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

Для иллюстрации работы интерфейса динамического мастера, сформированного согласно настоящему изобретению, на фиг.5 изображена последовательность взаимодействий между устройствами системы 200, показанной на фиг.2. Устройства системы 200, изображенные на фиг.5, включают в себя клиентское устройство 300, сервер 400 XGL и пользовательскую базу 210 данных. Взаимодействия и подпрограммы, выполняемые с помощью различных устройств, изображены и описаны более подробно со ссылкой на фиг.6 и 9-17.

Как показано на фиг.5, обеспечение и интерпретация динамического мастера инициируется тогда, когда клиентское устройство 300 посылает запрос 502 мастера на сервер 400 XGL. После того, как сервер 400 XGL получит запрос 502 мастера, сервер XGL запрашивает любой релевантный список материалов (СМ) 504, который содержится в пользовательской базе 210 данных. Список материалов представляет собой данные, сохраненные локально или на удаленном устройстве, которые можно использовать для заполнения полей в интерфейсе мастера. В некоторых вариантах осуществления сохраненные данные представляют собой специфическую информацию о пользователе. Структура данных СМ является такой, что имена полей в интерфейсе мастера и в структуре данных СМ имеют соответствие.

Предполагая, что информация находится в пользовательской базе 210 данных, СМ 506 возвращается на сервер 400 XGL. Соответственно, сервер XGL возвращает контейнер XGL, описывающий исходные пакеты мастера наряду с СМ 508, в клиентское устройство 300. Клиентское устройство 300, использующее процессор 349 мастера, затем производит структурный анализ 510 контейнера XGL и его содержимое. Затем клиентское устройство создает интерфейс мастера, исходя из структурного анализа контейнера XGL, после чего интерфейс мастера заполнятся (514) любыми согласующими полями в СМ. Интерфейс мастера затем изображается (516) на клиентском устройстве 300. Принимаются (518) любые варианты пользовательского выбора. Если варианты пользовательские выбора требуют дополнительного пакета, такого как выполняющий запрос на ветвление, новый запрос пакета посылается (520) в сервер 400 XGL. В ответ на это, сервер 400 XGL возвращает контейнер XGL с запрошенным пакетом (522) в клиентское устройство 300. Контейнер XGL и содержимое снова подвергается структурному анализу (524), и интерфейс мастера обновляется (526) дополнительной информацией, прошедшей структурный анализ. Затем, если любая дополнительная информация в мастере согласует поля в СМ, мастер заполняется (528) областями согласования. Далее, обновленный интерфейс мастера изображается (530) на клиентском устройстве 300. Когда конечный пользователь завершает свое взаимодействие с мастером, конечный пользователь показывает завершение 532. После этого клиентское устройство 300 посылает любую дополнительную информацию в обновленном СМ 534 через сервер 400 XGL в пользовательскую базу 210 данных, где обновленный СМ сохраняется (536). Между тем, сервер 400 XGL производит структурный анализ обновленного СМ и производит действие по любой информации, которая требует действия. Например, если пользователь производит учетную запись, сервер 400 XGL может проверить всю учетную информацию, полученную от пользователя, и сразу после подтверждения выдает подтверждение 540 обратно в клиентское устройство 300.

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

Как показано на фиг.2, 4 и 5, вариант осуществления системы 200 динамического мастера, описанный здесь, включает в себя сервер 400 XGL, который используется для обеспечения контейнеров и пакетов, которые описывают интерфейс мастера так, как это запрашивает клиентское устройство 300. Алгоритм, изображающий подпрограмму 600 обеспечения мастера, который выполняет сервер 400 XGL, в соответствии с одним вариантом осуществления настоящего изобретения, показан на фиг.6. Подпрограмма 600 обеспечения мастера начинается в блоке 601 и продолжается в блоке 605, где запрос мастера поступает из клиентского устройства 300. Затем, в блоке 610, любая информация СМ восстанавливается из пользовательской базы 210 данных. Далее, в блоке 615 принятия решения, производится определение того, была ли доступна любая информация СМ. Если информация СМ была доступна, то контейнер XGL, содержащий исходные пакеты для интерфейса мастера, и СМ посылают клиенту в блок 620. В противном случае, если СМ был недоступен, как определено в блоке 615 принятия решения, сервер 400 XGL только посылает контейнер XGL клиенту в блок 625. Сервер 400 XGL затем ожидает свой следующий сеанс связи из клиентского устройства 300, а именно модули для приема обновленного СМ, как показано с помощью блока 630 принятия решения. Если в блоке 630 принятия решения определено, что был получен обновленный СМ, подпрограмма 600 переходит в блок 635, где сервер 400 XGL действует по обновленному СМ. Затем обновленный СМ направляется в пользовательскую базу 210 данных, как показано с помощью блока 640. Подпрограмма 600 затем заканчивается в блоке 699. Однако, если в блоке 630 принятия решения определено, что обновленный СМ не был получен, и таким образом окончание подпрограммы 600 способом, описанным выше, в блоке 645 производится определение относительно того, был ли получен новый запрос пакета. Если результатом является "нет", то обработка возвращается к началу цикла в блок 630 принятия решения, в противном случае, обработка продолжается в блоке 650, где запрашиваемый пакет посылается в контейнер обратно в клиентское устройство 300. Подпрограмма 600 возвращается к началу цикла в блоке 630 принятия решения.

Специалистам понятно, что подпрограмма 600 обеспечения мастера изображает установление связи между одиночным клиентским устройством и сервером 400 XGL. Следует понимать, что в многочисленных средах подпрограмма 600 будет иметь место в многочисленных подпроцессах или процессах на сервере 400 XGL с множеством клиентских устройств 300.

Для дополнительного изображения работы интерфейса динамического мастера, сформированного согласно настоящему изобретению, на фиг.7 изображена другая последовательность взаимодействий между устройствами системы 200, показанной на фиг.2. Устройства системы 200, изображенные на фиг.7, включают в себя клиентское устройство 300, сервер 400 XGL, базу 449 данных XGL и пользовательскую базу 210 данных. Взаимодействия и подпрограммы, выполненные с помощью различных устройств, изображены и описаны более подробно со ссылкой на фиг.8 и 9-17.

Как показано на фиг.7, обеспечение динамического мастера и интерпретация инициируется в случае, когда клиентское устройство 300 посылает запрос 702 мастера в сервер 400 XGL. После того, как сервер 400 XGL принимает запрос 702 мастера, сервер XGL определяет 703, какие пакеты должны быть включены в качестве исходных пакетов в контейнере мастера. Сервер 400 XGL затем запрашивает 704 пакеты из базы 449 данных XGL, которая возвращает 705 запрошенные исходные пакеты. Затем сервер XGL запрашивает 706 любую информацию СМ из пользовательской базы 210 данных. Предполагая, что релевантной информации нет в пользовательской базе 210 данных, при отсутствии взаимодействия 707 СМ происходит возврат к серверу 400 XGL. Соответственно, сервер XGL производит возврат контейнера XGL, описывающего исходные пакеты мастера 708, к клиентскому устройству 300.

Клиентское устройство 300 затем производит структурный анализ 710 контейнера XGL и его содержимого. Затем клиентское устройство создает 712 интерфейс мастера, исходя из структурного анализа контейнера XGL. После этого создается 712 клиентское устройство. Интерфейс мастера затем изображается 716 на клиентском устройстве 300. Затем поступают 718 любые варианты пользовательского выбора. Если варианты пользовательского выбора требуют дополнительного пакета, например, из запроса на ветвление, новый запрос пакета посылается 720 в сервер 400 XGL. В ответ на это, сервер 400 XGL возвращает контейнер XGL с запрашиваемым пакетом 722 в клиентское устройство 300. Контейнер XGL и содержимое снова проходит структурный анализ 724, и интерфейс мастера обновляется 726 дополнительной информацией, полученной в ходе структурного анализа. Затем обновленный интерфейс мастера изображается 730 на клиентском устройстве 300. Когда конечный пользователь заканчивает свое взаимодействие с мастером, конечный пользователь показывает это завершение 732. После этого клиентское устройство 300 посылает любую дополнительную информацию при обновленном СМ 734 через сервер 400 XGL в пользовательскую базу 210 данных, где обновленный СМ затем сохраняется 736. Между тем сервер 400 XGL производит структурный анализ обновленного СМ и воздействует на любую информацию, которая требует действия. Например, если пользователь подписывает счет, сервер 400 XGL может проверить всю информацию о счете, полученную от пользователя, и, при утверждении, выполняет подтверждение 740 обратно в клиентском устройстве 300.

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

Как изображено на фиг.2, 4 и 5, вариант осуществления системы 200 динамического мастера, описанный здесь, включает в себя сервер 400 XGL, который используется для обеспечения контейнеров и пакетов, которые описывают интерфейс мастера, который запрашивает клиентское устройство 300. Алгоритм, иллюстрирующий дополнительную подпрограмму 800 обеспечения мастера, который выполняет сервер 400 XGL, в соответствии с одним дополнительным вариантом осуществления настоящего изобретения, показан на фиг.8. Подпрограмма 800 обеспечения мастера начинается в блоке 801 и продолжается в блоке 805, где запрос мастера поступает из клиентского устройства 300. Затем исходный набор пакетов определяется в блоке 810. В одном варианте осуществления это представляет собой набор всех неветвящихся пакетов, которые образуют исходную часть интерфейса мастера. Эти исходные пакеты затем восстанавливаются из базы 449 данных XGL в блоке 815. Затем, в блоке 820, любая информация о СМ восстанавливается из пользовательской базы 210 данных. Затем, в блоке 825 принятия решения производится определение того, была ли доступна любая информация СМ. Если информация СМ была доступна, то контейнер XGL, содержащий исходные пакеты для интерфейса мастера, и СМ посылаются клиенту в блоке 830. В противном случае, если СМ был не доступен, как это было определено в блоке 825 принятия решения, то сервер 400 XGL только посылает контейнер XGL клиенту в блоке 835. Сервер 400 XGL затем ожидает своего следующего сеанса связи с клиентским устройством 300. Если в блоке 840 принятия решения было определено, что обновленный СМ был получен, то подпрограмма 800 переходит в блок 845, где сервер 400 XGL может затем действовать на обновленный СМ, и обновленный СМ направляется в пользовательскую базу 210 данных в блоке 850. Подпрограмма 800 затем заканчивается в блоке 899. Однако, если в блоке 840 принятия решения было определено, что обновленный СМ не был получен (например, окончание подпрограммы 800), то в блоке 855 принятия решения производится определение относительно того, был ли получен новый запрос на пакет (или пакеты). Если нет, то обработка возвращается к началу цикла в блоке 840 принятия решения, в противном случае, обработка продолжается в блоке 860, где запрашиваемые пакеты восстанавливаются из базы 499 данных XGL. Затем пакеты посылаются в контейнере обратно в клиентское устройство 300, и подпрограмма 800 продолжается в блоке 840 принятия решения. Специалистам понятно, что подпрограмма 800 обеспечения мастера изображает связь между одиночным клиентским устройством и сервером 400 XGL. Следует понимать, что в многочисленных средах подпрограмма 800 будет встречаться в многочисленных подпроцессах или процессах на сервере 400 XGL с множеством клиентских устройств 300.

На фиг.9 изображена подпрограмма 900 мастера, реализованная на клиентском устройстве 300, как часть процессора 349 мастера. Подпрограмма 900 мастера запускается в блоке 901 и продолжается в блоке 905, где клиентское устройство 300 принимает исходный контейнер мастера и любые дополнительные данные, такие как данные СМ. Затем в блоке 1000 подпрограмм обрабатывается контейнер мастера. Подпрограмма 1000 описана более подробно ниже со ссылкой на фиг.10. Процесс затем продолжается в блоке 1600 подпрограмм, где страница отображается из контейнера. Описание блока 1600 подпрограмм приводится более подробно ниже со ссылкой на фиг.16. После отображения страницы, блок 1700 подпрограмм принимает и обрабатывает любой пользовательский ввод. Подпрограмма 1700 описана более подробно ниже со ссылкой на фиг.17. После того, как пользовательский ввод получен и/или обработан, процесс продолжается в блоке 910 принятия решения, где производится определение того, получен или нет сигнал окончания. Если это так, то обработка продолжается в блоке 915, где окончательный СМ посылается в сервер 400 XGL. Подпрограмма 900 затем заканчивается в блоке 999.

Если в блоке 910 принятия решения было определено, что сигнал окончания не был получен, то обработка продолжается в блоке 920 принятия решения, где производится определение того, получен или нет сигнал отмены. Если сигнал отмены был получен, то обработка заканчивается в блоке 999. Следует обратить внимание, что с помощью сигнала отмены СМ не посылается в сервер XGL, поскольку конечный пользователь не одобрил ввод в мастере.

Если в блоке 920 принятия решения было определено, что сигнал отмены не был получен, то в блоке 925 принятия решения производится определение того, получен или нет обратный сигнал. Если это так, то логический процесс продолжается в блоке 930, где мастер следует за указателем назад на одну страницу в ходе выполнения мастера. Обработка затем возвращается к началу цикла в блоке 1600 подпрограмм, где снова отображается предыдущая страница.

Если в блоке 925 принятия решения определяется, что обратный сигнал не был получен, то в блоке 935 принятия решения производится определение того, получен или нет следующий сигнал. Если следующий сигнал был получен в блоке 935 принятия решения, то логический процесс продолжается в блоке 940 принятия решения, где производится определение того, инициировал или нет следующий сигнал команду ветвления. Как отмечено выше, команда ветвления выдается в случае, когда текущие пакеты имеют точку ветвления, где один или более других пакетов и/или страниц должны продолжить процесс мастера.

Если команда ветвления была показана в блоке 945, то новый контейнер с пакетами восстанавливается из сервера 400 XGL, который удовлетворяет условиям, запрашиваемым при ветвлении. Новый контейнер затем обрабатывается с помощью возврата к началу цикла в блоке 1000 подпрограмм.

Если в блоке 940 принятия решения было определено, что следующий сигнал не инициировал команду ветвления, то в блоке 955 сохраняется указатель на текущую страницу, и восстанавливается следующая страница (блок 960). Процесс затем возвращается к началу цикла в блок 1600 подпрограмм для отображения следующей страницы. Если, однако, в блоке 935 принятия решения не был получен следующий сигнал, то в блоке 950 подпрограмма 900 ждет снова пользовательского ввода путем возврата к началу цикла в блоке 1700 подпрограмм.

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

На фиг.10 изображена подпрограмма 1000 обработки контейнера. Подпрограмма 1000 начинается в блоке 1001 и продолжается в блоке 1005, где пакет извлекается из контейнера. Извлеченный пакет затем обрабатывается в подпрограмме 1100 обработки пакета, описанной более подробно ниже со ссылкой на фиг.11. После обработки, в блоке 1010 принятия решения производится новое определение относительно того, имеет или нет контейнер большее количество пакетов. Если в блоке 1010 принятия решения определено, что контейнер содержит большее количество пакетов, обработка возвращается к началу цикла в блок 1005, где другой пакет извлекается из контейнера. В противном случае, если в блоке 1010 принятия решения определено, что дополнительные пакеты не содержатся в контейнере, то в блоке 1015 принятия решения производится определение относительно того, доступен или нет СМ сопроводительный контейнер или часть контейнера. Если в блоке 1015 принятия решения определяется, что СМ не доступен, то создается новый СМ в блоке 1500 подпрограмм, который описан более подробно ниже со ссылкой на фиг.15. Обработка затем заканчивается в блоке 1099. В противном случае, если в блоке 1015 принятия решения определяется, что СМ является доступным, обработка продолжается в блоке 1400 подпрограмм, где компоненты данных в мастере с соответствующими полями в СМ заполнены этими вновь доступными данными в блоке 1400 подпрограмм, который описан более подробно ниже со ссылкой на фиг.14. В любом случае, подпрограмма 1000 заканчивается в блоке 1099 путем возвращения к подпрограмме, которую он вызвал.

На фиг.11 изображен пример подпрограммы 1100 синтаксического анализа пакетов. Подпрограмма 1100 начинается в блоке 1101 и продолжается в блоке 1105 принятия решения, где происходит определение того, содержит ли пакет текущие данные. Если в блоке 1105 принятия решения определено, что пакет содержит текущие данные, обработка продолжается в блоке 1110, где текущий ("живой") пакет с информацией XGL разгружается из сервера 400 XGL. Затем подпрограмма 1100 рекурсивно вызывается для обработки текущего пакета. Обработка затем продолжается в блоке 1200 подпрограмм. Если в блоке 1105 принятия решения производится определение того, что пакет не содержит текущих данных, то обработка также продолжается в блоке 1200 подпрограмм, где размещенные компоненты пользовательского интерфейса преобразуются из пакета XGL в одну или более страниц мастера. Подпрограмма 1200 описана более подробно ниже со ссылкой на фиг.12. После того, как размещение компонента пользовательского интерфейса была преобразована из XGL, обработка продолжается в подпрограмме 1300, где объекты в пакете XGL преобразуются в компоненты пользовательского интерфейса как размещенные в соответствии с размещенными компонентами, которые предварительно были преобразованы в блоке 1200 подпрограмм. Подпрограмма 1300 описана более подробно ниже со ссылкой на фиг.13. Совместное преобразование размещения и компонентов в накопителе в результате приводит к набору размеченных страниц, которые возвращаются в блоке 1199 к подпрограмме, которая называется подпрограммой 1100 синтаксического анализа пакетов.

На фиг.12 изображен пример подпрограммы 1200 преобразования размещения. Подпрограмма 1200 преобразования размещения начинается в блоке 1201 и продолжается в блоке 1205, где данные размещения XGL проверяются для размещения компонентов пользовательского интерфейса. Затем в блоке 1210 принятия решения производится тест для того, чтобы увидеть, остались или нет еще какие-нибудь компоненты, которые нужно проверить. Если нет, то размещенные отмеченные страницы возвращаются в блоке 1299 к подпрограмме, которая вызвала подпрограмму 1200. Если в блоке 1210 принятия решения определено, что остается большее количество компонентов размещения, то следующий компонент размещается в блоке 1215. Во время размещения в блоке 1220 принятия решения производится определение того, нужно ли использовать специфический шаблон для размещения следующего компонента. Если это так, то в блоке 1225 положение следующего компонента основывается на описании специфического шаблоном расположения объекта. Это можно использовать в случае, когда специальное расположение необходимо для конкретного типа мастера и/или компонента в мастере. Обработка затем возвращается к началу цикла в блоке 1210 принятия решения. Если в блоке 1220 принятия решения производится определение того, что специфический шаблон не требуется, как показано в блоке 1230, положение компонента основывается на описании XGL стандартного шаблона расположения объекта в соответствии со стандартным шаблоном размещения, используемым машиной мастера на клиентском устройстве 300. После этого обработка снова возвращается к началу цикла в блок 1210 принятия решения, где производится определение относительно того, остаются ли какие-нибудь компоненты для размещения.

На фиг.13 изображен возможный вариант осуществления подпрограммы 1300 преобразования объекта XGL. Подпрограмма 1300 начинается в блоке 1301 и продолжается в блоке 1305, где пакет XGL подвергается структурному анализу для получения иерархического списка объектов. Затем в блоке принятия решения 1310 производится определение того, остаются ли в списке какие-нибудь объекты. Если нет, то подпрограмма 1300 возвращает любые компоненты пользовательского интерфейса для мастера в блоке 1399.

Если в блоке 1310 принятия решения обнаружено, что объекты все еще остаются в списке, то следующий объект извлекается в блоке 1315, то есть, удаляется из списка. Затем, в блоке 1320 принятия решения производится тестирование для определения того, имеется ли подтип, доступный для извлеченного объекта. Если подтип доступен, обработка продолжается в блоке 1325, где идентифицируется подтип объекта. Если в блоке 1320 принятия решения было определено, что подтип недоступен, или после того, как был идентифицирован подтип объекта в блоке 1325, обработка переходит в блок 1330 принятия решения, где производится определение того, доступен ли класс для объекта. Если класс доступен, обработка продолжается в блоке 1335, где идентифицируется класс объекта. После того, как класс объекта был идентифицирован в блоке 1335, или если был найден класс, который будет недоступен в блоке 1330 принятия решения, обработка возвращается к началу цикла в блок 1310 принятия решения, где производится определение того, остаются ли какие-нибудь объекты в списке.

Как отмечено выше, на фиг.14 изображена подпрограмма заполнения мастера для заполнения полей данных в мастере из СМ. Подпрограмма 1400 начинается в блоке 1401 и продолжается в блоке 1405 принятия решения, где производится определения того, являются ли какие-нибудь данные доступными для заполнения компонентов мастера. Если нет, то обработка продолжается в блоке 1495, который возвращает уведомление относительно того, что компоненты недоступны для вызова подпрограммы. Однако, если в блоке 1405 принятия решения было определено, что имеются данные для заполнения компонентов, то в блоке 1410 имена данных в СМ и в мастере сравниваются для сопоставления. Затем, в блоке 1415 часть данных компонентов мастера, которые соответствуют именам в СМ, заполняют значениями в полях данных СМ. Эти вновь заполненные компоненты затем возвращаются в блок 1499 в вызывающую подпрограмму.

На фиг.15 изображена подпрограмма 1500 для создания нового СМ. Подпрограмма 1500 начинается в блоке 1501 и продолжается в блоке 1505, где контейнер или контейнеры, которые используются для создания мастера, проходят структурный анализ для объектов с полями данных, которые будут сохранены в СМ. Затем, в блоке 1510 создаются входные сообщения в СМ для всех полей данных, которые будут сохранены. Далее, в блоке 1515 локально сохраняется СМ, и в блоке 1599 подпрограмма 1500 заканчивается и возвращается к подпрограмме, которая ее вызвала.

На фиг.16 изображена подпрограмма 1600 отображения страницы мастера. Подпрограмма 1600 начинается в блоке 1601 и продолжается в блоке 1605, где страница поступает в формате разметки страницы. Затем, в блоке 1610 интерпретируется язык разметки в странице. Далее, в блоке 1615 форматированная страница отображается на клиентском устройстве 300 (фиг.18A-C и следующее описание иллюстрируют и описывают примеры страниц интерфейса мастера). Подпрограмма 1600 заканчивается в блоке 1699 и возвращается к подпрограмме, которая ее вызвала.

На фиг.17 изображена подпрограмма для обработки пользовательского ввода. Подпрограмма 1700 обработки пользовательского ввода начинается в блоке 1701 и продолжается в блоке 1705, где подпрограмма ожидает пользовательского ввода. Затем в блоке 1710 принятия решения производится определение того, закончил ли пользователь ввод информации. Если нет, то обработка возвращается к началу цикла в блоке 1705, где подпрограмма 1700 ожидает дальнейшего пользовательского ввода. Однако, если в блоке 1710 принятия решения было определено, что пользователь сделал ввод, то в блоке 1700 подпрограмма 1715 ожидает запуска, такого как щелчок по кнопке мыши пользователя или нажатия одной из стандартных кнопок мастера для переключения страниц. Если в блоке 1720 принятия решения определяется, что запуск был принят, то обработка переходит в блок 1725 принятия решения. Однако, если в блоке 1720 принятия решения было определено, что запуск не был принят, то обработка возвращается к началу цикла в блок 1715, где подпрограмма 1700 ожидает запуска.

В блоке 1725 принятия решения определяется, был ли принят запуск "запуском отмены". Если это так, то обработка переходит в блок 1799, где запуск возвращается к вызывающей подпрограмме. Однако, если в блоке 1725 принятия решения определяется, что был принят запуск отмены, обработка переходит в блок 1730 принятия решения, где определяется, требуется ли дополнительный ввод или имелась ошибка в вводе пользователя. Если это так, то обработка возвращается к началу цикла в блок 1705. Однако, если дополнительный ввод не требуется и при вводе пользователя не было ошибки, обработка продолжается в блоке 1735, где ввод в странице мастера сохраняется в локальной копии СМ. Обработка затем заканчивается в блоке 1799, где запуск, который закончил обработку, возвращается назад в вызывающую подпрограмму.

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

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

На фиг.18A-C изображены примеры страниц интерфейса мастера, созданные с помощью возможного варианта осуществления настоящего изобретения. На фиг.18A показана исходная страница 1850 мастера, которая включает в себя только следующую кнопку 1844, кнопку 1848 отмены, левую панель 1820 и правую панель 1830, которые расположены в пределах рамки 1810 страницы мастера. На фиг.18B показана страница 1855 мастера. Фиг.18B подобна фиг.18А за исключением того, что фиг.18B также включает в себя кнопку 1842 "вернуться назад". Фиг.18C показывает конечную страницу 1860 мастера. Фиг.18C подобна фиг.18B за исключением того, что кнопка 1844 "перейти далее", показанная на фиг.18B, была заменена кнопкой 1846 "конец". Специалистам должно быть понятно, что многочисленные другие компоненты, которые отличаются от показанных на фиг.18A-C, могут быть включены в интерфейс мастера. В этом возможном варианте осуществления страницы интерфейса мастера включают в себя кнопки "перемещение" для перемещения вперед или назад страниц в интерфейсе мастера. Соответственно, пример на фиг.18A не включает в себя кнопку "вернуться назад", так как отсутствует место для возврата от исходной страницы. Так как фиг.18B показывает промежуточное звено, фиг.18B включает в себя кнопку "вернуться назад" и "перейти далее". Поскольку на фиг.18C показана конечная страница, фиг.18C включает в себя кнопку 1846 "конец".

Специалистам понятно, что загрузка и разгрузка компонентов может вызывать события, которые можно использовать для усовершенствования интерфейса динамического мастера, соответствующего настоящему изобретению. На фиг.19-22 изображен альтернативный вариант осуществления изобретения, воплощающий обработку и/или запуск действий из таких выработанных событий. На фиг.19 изображена подпрограмма 1900 для обнаружения событий. Подпрограмма 1900 начинается в блоке 1901 и продолжается в блоке 1905, где обнаруживается событие загрузки контейнера. Затем блок 1910 принятия решения определяет, являются ли любые команды в этом контейнере или любые предварительно загруженные контейнеры наблюдаемыми событиями загрузки контейнера для выработки действия или действий; если это так, то обработка продолжается в блоке 2200 подпрограмм, где обрабатывается соответствующее действие или действия. Подпрограмма 2200 описана более подробно ниже со ссылкой на фиг.22. После окончания подпрограммы 2200, обработка продолжается в блоке 2000 подпрограмм. С другой стороны, если в блоке 1910 принятия решения действия событий загрузки контейнера не были найдены, то обработка переходит непосредственно в блок 2000 подпрограмм, где обнаруживаются и обрабатываются события пакета. Подпрограмма 2000 обсуждена более подробно ниже со ссылкой на фиг.20.

После окончания подпрограммы 2000, обработка переходит в блок 1915. В блоке 1915 обнаруживается разгрузка контейнера. Если событие разгрузки контейнера наблюдается с помощью любого кода XGL с соответствующими действиями, то блок 1920 принятия решения вызывает действия, которые должны обрабатываться посредством создания другого вызова в подпрограмме 2200. После окончания подпрограммы 2200, обработка переходит в блок 1925 принятия решения. С другой стороны, если действия событий разгрузки контейнера не наблюдались (блок 1920 принятия решения), то обработка переходит непосредственно в блок 1925 принятия решения. В блоке 1925 принятия решения определяется, должны ли контейнеры дополнительно загружаться. Например, эта подпрограмма 1900 события может непрерывно обрабатываться при загрузке и работе динамического мастера. Если это так, то блок 1925 принятия решения вызовет ожидание процесса до тех пор, пока не будет получен определенный ответ, что больше контейнеров не ожидается, например, когда динамический мастер завершается или отменяется. Если в наличии будет больше контейнеров, то обработка возвращается к началу цикла назад в блок 1905. Если в блоке 1925 принятия решения определяется, что в наличии больше не будет контейнеров, обработка заканчивается в блоке 1999.

Как описано выше, подпрограмма 2000 обнаруживает и обрабатывает события пакета. Подпрограмма 2000 начинается в блоке 2001 и продолжается в блоке 2005, где обнаруживается событие загрузки пакета. Обработка затем продолжается в блоке 2010 принятия решения, где определяется, происходят ли какие-нибудь действия, связанные с обнаруженным событием загрузки пакета; если это так, то эти действия обрабатываются с помощью подпрограммы 2200. Как отмечено выше, подпрограмма 2200 изображена на фиг.22 и описана ниже. После возвращения из подпрограммы 2200, или если действия не связаны с событием загрузки пакета (блок 2010 принятия решения), обработка продолжается в блоке 2100 подпрограмм, где обрабатываются события страницы. Подпрограмма 2100 обсуждена более подробно ниже со ссылкой на фиг.21. После возвращения из подпрограммы 2100, обработка продолжается в блоке 2015, где обнаруживаются события разгрузки пакетов.

Затем в блоке 2020 принятия решения запускается тест для того, чтобы определить, имеются ли какие-нибудь действия, связанные с событием разгрузки обнаруженных пакетов. Если это так, то обработка продолжается в подпрограмме 2200, где обрабатываются эти действия. После возврата из блока 2200 подпрограмм, или если не были обнаружены действия, которые должны быть связаны с событием разгрузки пакетов (блок 2020), обработка переходит в блок 2025 принятия решения, где определяется, имеются ли еще пакеты. Если это так, то обработка возвращается к началу цикла в блоке 2005, в противном случае, обработка заканчивается в блоке 2099, где подпрограмма 2000 возвращается к подпрограмме, которая ее вызвала.

На фиг.21 изображена подпрограмма 2100 обработки события страницы, подобная подпрограмме 2000 обработки события страницы, которая показана на фиг.20. Подпрограмма 2100 начинается в блоке 2101 и продолжается в блоке 2105, где обнаруживается событие загрузки страницы. Затем в блоке 2110 определяется, связаны ли какие-нибудь действия с обнаруженным событием загрузки страницы; если это так, то обработка переходит к подпрограмме 2200, где обрабатываются эти действия. После возврата из блока 2200 подпрограмм, или если было найдено, что нет действий, которые должны быть связаны с обнаруженным событием загрузки страницы, обработка продолжается в блоке 2115, где обнаруживается событие разгрузки страницы. Затем в блоке 2120 принятия решения производится тестирование для того, чтобы определить, имеются ли действия, связанные с обнаруженным событием разгрузки страницы. Если это так, то обработка продолжается в подпрограмме 2200, где эти действия обрабатываются. После возвращения из подпрограммы 2200, или если не были найдены действия, которые должны быть связаны с обнаруженным событием разгрузки страницы, обработка переходит в блок 2125 принятия решения, где определяется, необходимо ли обрабатывать большее количество страниц. Если это так, то обработка возвращается к началу цикла в блоке 2105. В противном случае, обработка заканчивается в блоке 2199, и подпрограмма 2100 возвращается к подпрограмме, которая ее вызвала.

На фиг.22 изображена подпрограмма 2200 обработки действия. Подпрограмма 2200 запускается в блоке 2201 и продолжается в блоке 2205, где сценарий для действия извлекается из объекта действия XGL. Объекты действия XGL представляют собой специальные объекты XGL, которые содержат программы и/или сценарии, которые могут быть загружены и выполнены на стороне клиентского устройства 300 в процессоре мастера XGL. Специалистам понятно, что возможные сценарии могут быть на любом из множества языков и/или форм, например, Javascript, VBscript, C# ("C-SHARP") и тому подобное. После того, как сценарий был извлечен из объекта действия XGL в блоке 2210, сценарий интерпретируется и выполняется. Затем в блоке 2215 принятия решения определяется, было ли запущено больше действий. Если это так, то обработка возвращается к началу цикла в блоке 2205. Однако, если в блоке 2215 принятия решения определяется, что больше не было запущено действий, подпрограмма 2200 заканчивается в блоке 2299, и обработка возвращается к подпрограмме, которая вызвала подпрограмму 2200 обработки действия.

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

В дополнение к динамическому созданию интерфейса мастера, настоящее изобретение может также использоваться для оснащения средствами контроля, такими как отслеживание пользовательских взаимодействий с интерфейсом мастера. На фиг.23 изображен пример подпрограммы средств контроля для отслеживания пользовательских взаимодействий с интерфейсом динамического мастера, сформированным согласно настоящему изобретению. Подпрограмма 2300 начинается в блоке 2301 и продолжается в блоке 2305, где обнаруживается событие. Затем в блоке 2310 принятия решения определяется, было ли это событием загрузки для некоторого компонента мастера. Если это так, то в блоке 2315 подпрограмма 2300 средств контроля запускает регистрацию пользовательского действия, связанного с событием загрузки. Например, если пользователь загружает страницу в интерфейс мастера, то регистрация действия на этой странице будет начинаться с события загрузки страницы. Обработка затем возвращается к началу цикла в блок 2305 и ожидает, пока не будет обнаружено следующее событие.

Если в блоке 2310 принятия решения определено, что событие загрузки не обнаружено, то в блоке 2320 принятия решения определяется, было ли обнаруженное событие событием разгрузки. Если это так, то в блоке 2325 событие разгрузки вызывает подпрограмму 2300 для того, чтобы остановить регистрацию пользовательской деятельности для случая загрузки, которое соответствует событию разгрузки. Например, если пользователь загружает пакет, и затем пакет разгружается, загрузка пакета останавливает регистрацию в случае, когда был загружен пакет. Затем в блоке 2330 зарегистрированные данные сохраняются в журнале сеансов, связанном с пользователем. Обработка затем возвращается к началу цикла в блоке 2305.

Если в блоке 2320 принятия решения определено, что событие разгрузки не обнаружено, обработка переходит в блок 2335 принятия решения, где определяется, являлось ли событие событием окончания. Если нет, то данные события регистрируются в блоке 2340, и обработка возвращается к началу цикла в блоке 2305 для ожидания нового события, которое необходимо обнаружить. Однако, если в блоке 2335 принятия решения было обнаружено событие окончания, обработка продолжается в блоке 2345, где вся регистрация останавливается. Затем в блоке 2350 все зарегистрированные данные сохраняются, и затем обработка заканчивается в блоке 2399.

Структура XGL интерфейса динамического мастера, сформированного в соответствии с описанным возможным вариантом осуществления настоящего изобретения, значительно увеличивает настройку, локализацию и доступность интерфейсов динамических мастеров. Например, на фиг.24A изображен пример страницы 2400 мастера, сформированной согласно настоящему изобретению. Страница включает в себя кнопку 2442 "вернуться назад", кнопку 2444 "перейти далее" и кнопку 2448 "отмена" наряду с левой панелью 2410, правой панелью 2430, причем все окружает рамка 2405 страницы мастера. В левой панели 2410 содержится пояснительный текст 2412. Правая панель 2430 включает в себя ряд помеченных полей 2420. Хотя страница 2400 мастера, изображенная на фиг.24A, без труда понятна большинству пользователей интерфейса мастера, для некоторых пользователей со специфическими потребностями может потребоваться расширение возможностей взаимодействия с таким интерфейсом мастера. Соответственно, на фиг.24B показана высококонтрастная версия 2450 страницы 2400 мастера, показанной на фиг.24A. Высококонтрастная страница 2450 мастера включает в себя по существу ту же самую информацию, как и страница 2400 мастера, показанная на фиг.24A, за исключением текста 2412a левой панели 2410, которая представлена без цветного фона и имеет увеличенный размер шрифта. Оба изменения предназначены для повышения контраста и четкости. Аналогично, помеченные области 2420a правой панели 2430 высококонтрастной страницы 2450 мастера представлены в высококонтрастном виде. Кроме того, текст в кнопке 2442a "вернуться назад", кнопке 2444a "перейти далее" и кнопке 2448a " отмена" также увеличен по размеру шрифта для повышения зрительного восприятия. Кодирование компонентов интерфейса динамического мастера в XGL позволяет клиентской стороне процессора мастера определить, какие будут использоваться шаблоны, и тем самым определять, каким образом динамический мастер будет представлен конечному пользователю.

Специалистам понятно, что еще более выразительные примеры по сравнению с показанными на фиг.24A-24B входят в объем настоящего изобретения. Например, так как клиентское устройство 300 поддерживает связь с сервером 400 XGL, поскольку пакеты мастера собираются в контейнер, могут быть собраны специальные страницы и/или пакеты, чтобы соответствовать специфическим потребностям части процессора мастера, расположенного на клиентском устройстве 300. Если клиентское устройство использует французский язык в качестве выбранного языка, пакеты, собранные вместе в контейнерах XGL динамического мастера, будут включать в себя французский язык для отображения в интерфейсе динамического мастера. Некоторую часть локализации и настройки можно просто определить с помощью тех шаблонов и/или процессора мастера, которые являются резидентными на клиентском устройстве 300. Как уже было отмечено, высококонтрастные шаблоны могут быть резидентными на клиентском устройстве. Дополнительные шаблоны могут включать в себя преобразователь текста в звук или визуальный дисплей для шаблона преобразования Бернулли, расположенного на клиентском устройстве 300. Ни одно из этих усовершенствований не влияет на то, какие пакеты и/или страницы собраны для формирования интерфейса динамического мастера, представленного пользователю. Они просто точно настраивают представление в виде, более пригодном для конечного пользователя.

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

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

(b) инкапсулируют упомянутые пакеты в контейнере;

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

(d) причем в ответ на прием упомянутого контейнера упомянутый процессор мастера:

(i) анализирует данные и исполняемый код, включенные в упомянутые пакеты; и

(ii) создает интерфейс мастера в соответствии с данными и исполняемым кодом, включенными в упомянутые пакеты;

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

(f) инкапсулируют упомянутый, по меньшей мере, один пакет в контейнер;

(g) доставляют контейнер в упомянутый процессор мастера и

(h) причем в ответ на прием упомянутого контейнера процессор мастера:

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

(ii) обновляет интерфейс мастера в соответствии с данными и исполняемым кодом, включенными в упомянутый, по меньшей мере, один пакет.

2. Способ по п.1, в котором упомянутый контейнер и упомянутые пакеты представлены в формате данных с самоописанием.

3. Способ по п.2, в котором форматом данных с самоописанием является расширяемый язык разметки (XML).

4. Способ по п.1, в котором пакет содержит страницы и объекты, описывающие интерфейс мастера.

5. Способ по п.4, в котором объекты представлены в формате данных с самоописанием.

6. Способ по п.4, в котором страницы содержат указатели "вперед" и "назад" для сохранения прямого и обратного перехода между страницами.

7. Способ по п.4, в котором объекты содержат объект действия.

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

9. Способ по п.8, в котором предварительное заполнение интерфейса мастера содержит согласование поля данных с самоописанием в структуре данных с объектами с самоописанием в пакете.

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

11. Способ по п.10, в котором после доставки первого пакета ответвления в процессор мастера повторно используют доставленный первый пакет ответвления в случае выбора упомянутого первого доставленного пакета ответвления.

12. Способ по п.11, в котором упомянутый первый пакет ответвления кэширован.

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

14. Способ по п.13, в котором в ответ на выбор в интерфейсе мастера один из упомянутых пакетов ответвления инкапсулируют в контейнере ответвления для доставки в процессор мастера.

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

16. Способ по п.1, в котором упомянутый, по меньшей мере, один из упомянутого набора пакетов инкапсулирует дополнительный пакет.

17. Способ по п.16, в котором дополнительный пакет содержит объекты текущих данных.

18. Способ по п.17, в котором дополнительный пакет представляет собой пакет ответвления, а объект текущих данных представляет собой объект выбора, выбор которого определяет, какой пакет ответвления будет доставлен в процессор мастера.

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

(b) извлечения упомянутых пакетов из базы данных, содержащей множество пакетов,

(c) инкапсулирования упомянутых пакетов в контейнер и

(d) доставки контейнера на упомянутое клиентское устройство, причем упомянутое клиентское устройство содержит процессор мастера для преобразования упомянутых данных и исполняемого кода, включенных в упомянутые пакеты, инкапсулированные в упомянутый контейнер, в интерфейс мастера путем:

(i) анализа данных и исполняемого кода, включенных в упомянутые пакеты; и

(ii) создания интерфейса мастера в соответствии с данными и исполняемым кодом, включенными в упомянутые пакеты;

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

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

(g) инкапсулирования упомянутого, по меньшей мере, одного пакета в контейнер;

(h) доставки упомянутого контейнера в клиентское устройство для обновления интерфейса мастера посредством:

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

(ii) обновления интерфейса мастера в соответствии с данными и исполняемым кодом, включенными в упомянутый, по меньшей мере, один пакет.

20. Компьютерное серверное устройство по п.19, в котором упомянутый контейнер и упомянутые пакеты представлены в формате данных с самоописанием.

21. Компьютерное серверное устройство по п.20, в котором форматом данных с самоописанием является расширяемый язык разметки (XML).

22. Компьютерное серверное устройство по п.19, в котором упомянутые пакеты содержат страницы и объекты, описывающие интерфейс мастера.

23. Компьютерное серверное устройство по п.22, в котором объекты представлены в формате данных с самоописанием.

24. Компьютерное серверное устройство по п.22, в котором страницы содержат указатели "вперед" и "назад" для сохранения прямого и обратного перехода между страницами.

25. Компьютерное серверное устройство по п.22, в котором объекты содержат объект действия.

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

27. Компьютерное серверное устройство по п.26, в котором предварительное заполнение интерфейса мастера содержит согласование области данных с самоописанием в структуре данных с объектами с самоописанием в пакете.

28. Компьютерное серверное устройство по п.19, в котором определение исходного набора пакетов содержит сбор пакетов, которые должны быть инкапсулированы в контейнере, вплоть до и включая первый пакет ответвления.

29. Компьютерное серверное устройство по п.28, в котором после доставки упомянутого первого пакета ответвления в клиентское устройство доставленный первый пакет ответвления используется повторно в случае выбора упомянутого первого доставленного пакета ответвления.

30. Компьютерное серверное устройство по п.29, в котором упомянутый первый пакет ответвления кэширован.

31. Компьютерное серверное устройство по п.28, в котором упомянутый первый пакет ответвления содержит указатели на множество пакетов ответвления.

32. Компьютерное серверное устройство по п.31, в котором в ответ на выбор в интерфейсе мастера, один из упомянутых пакетов ответвления инкапсулируется в контейнере ответвления для доставки в процессор мастера.

33. Компьютерное серверное устройство по п.32, в котором инкапсулированный контейнер ответвления содержит указатель на страницу в упомянутом одном из пакетов ответвления, содержащем объект выбора, где был сделан упомянутый выбор.

34. Компьютерное серверное устройство по п.19, в котором упомянутый, по меньшей мере, один из упомянутого набора пакетов инкапсулирует дополнительный пакет.

35. Компьютерное серверное устройство по п.34, в котором дополнительный пакет может содержать объекты с текущими данными.

36. Компьютерное серверное устройство по п.35, в котором дополнительный пакет представляет собой пакет ответвления, а объект текущих данных представляет собой объект выбора, выбор которого определяет, какой пакет ответвления будет доставлен на клиентское устройство.

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

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

(b) инкапсулирования упомянутых пакетов в контейнер;

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

(d) причем в ответ на прием упомянутого контейнера упомянутый процессор мастера:

(i) анализирует данные и исполняемый код, включенные в упомянутые пакеты; и

(ii) создает интерфейс мастера в соответствии с данными и исполняемым кодом, включенными в упомянутые пакеты;

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

(f) инкапсулирования упомянутого, по меньшей мере, одного пакета в контейнер;

(g) доставки контейнера в упомянутый процессор мастера;

(h) причем в ответ на прием упомянутого контейнера процессор мастера:

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

(ii) обновляет интерфейс мастера в соответствии с данными и исполняемым кодом, включенными в упомянутый, по меньшей мере, один пакет.

38. Машиночитаемый носитель информации п.37, в котором упомянутый контейнер и упомянутые пакеты представлены в формате данных с самоописанием.

39. Машиночитаемый носитель информации по п.38, в котором форматом данных с самоописанием является расширяемый язык (XML).

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

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

42. Машиночитаемый носитель информации по п.40, в котором объекты содержат объект действия.

43. Машиночитаемый носитель информации по п.40, в котором объекты представлены в формате данных с самоописанием.

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

45. Машиночитаемый носитель информации по п.44, в котором предварительное заполнение интерфейса мастера содержит согласование области данных с самоописанием в структуре данных с объектами с самоописанием в пакете.

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

47. Машиночитаемый носитель информации по п.46, в котором после доставки первого пакета ответвления в процессор мастера доставленный первый пакет ответвления повторно используется в случае выбора упомянутого доставленного первого пакета ответвления.

48. Машиночитаемый носитель информации по п.47, в котором упомянутый первый пакет ответвления содержит указатели на множество пакетов ответвления.

49. Машиночитаемый носитель информации по п.47, в котором упомянутые пакеты ответвления кэшированы.

50. Машиночитаемый носитель информации по п.48, в котором в ответ на выбор в интерфейсе мастера один из упомянутых пакетов ответвления инкапсулируется в контейнере ответвления для доставки в процессор мастера.

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

52. Машиночитаемый носитель информации по п.37, в котором упомянутый, по меньшей мере, один пакет инкапсулирует дополнительный пакет.

53. Машиночитаемый носитель информации по п.52, в котором дополнительный пакет может содержать объекты текущих данных.

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