Визуализация пользовательского интерфейса

Визуализация пользовательского интерфейса

Иллюстрации

Показать все

Реферат

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

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

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

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

Сущность изобретения

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

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

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

Перечень чертежей

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

Фигура 2 - более подробное изображение структуры и функционирования сервера (100);

Фигура 3 - схематическое изображение программного обеспечения (400) для мобильных устройств (300);

Фигура 4 - схематическое изображение инструментального набора (200) контента; и

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

Подробное описание изобретения

Изобретение будет далее описано только в качестве иллюстрации и в отношении прилагаемых к описанию чертежей, на которых Фигура 1 показывает схематическое изображение системы, содержащей сервер (100), инструментальный набор (200) контента, мобильные устройства (300), системы (OSS) (700) операционной поддержки, средства (500) подачи контента и источники (600) пользовательского интерфейса (UI). При использовании сервер (100) передает данные контента и данные пользовательского интерфейса мобильным устройствам (300), (301), …, каждое из которых содержит пакет (400) программного обеспечения. Сервер (100) сопрягается с системами (700) операционной поддержки, представляющими собой системы, традиционно используемые для управления мобильными сетями, например, системы билинга (выставления счетов), ведения счетов абонентов и т.д. Кроме того, сервер (100) сопрягается с инструментальным набором (200) контента: инструментальный набор (200) контента принимает данные из источников (600), (601), … пользовательского интерфейса и упаковывает данные пользовательского интерфейса таким образом, чтобы сервер мог передать упакованные данные пользовательского интерфейса пакетам (400) программного обеспечения, содержащимся внутри мобильных устройств (300). Сервер принимает данные от множества средств подачи контента, и эти данные обрабатываются и упаковываются таким образом, что они могут быть посланы пакетам (400) программного обеспечения или так, что мобильные устройства (300) могут осуществить доступ к этим данным, используя пакеты (400) программного обеспечения.

Эта система может быть представлена разделенной на три отдельные сферы: сфера (50) оператора содержит системы и оборудование, управляемые оператором (MNO) мобильной связи; сфера (60) пользователей содержит множество мобильных устройств; а сфера (70) третьей стороны содержит средства подачи контента, средства подачи пользовательского интерфейса, которые могут контролироваться или управляться рядом различных субъектов.

Фигура 2 более подробно изображает структуру и функционирование сервера (100). Сервер (100) содержит публикующий компонент (110) и компонент (150) «сервер контента». Публикующий компонент содержит базу данных (111), очередь (112) импорта, интерфейс (113) инструментального набора контента; пользовательский интерфейс (114) и каталог (115). При работе публикующий компонент принимает контент от инструментального набора контента через интерфейс инструментального набора контента. Контент представлен в форме посылки (210а), (210b) и т.д. (смотри ниже), содержащей один или более «тригов» и один или более «триглетов». «Триг» представляет собой пользовательский интерфейс для мобильного устройства, такого как мобильный телефон, а «триглет» представляет собой файл данных, который может быть использован для того, чтобы расширить или изменить «триг». Если посылка содержит более чем один «триг», то один из «тригов» может быть главным «тригом», от которого производны остальные «триги».

Фигура 3 приводит схематическое изображение программного обеспечения (400) для мобильных устройств (300), которое содержит: модуль (410) визуализации языка разметки; администратор (420) обновлений; агент (425) сетевой связи; администратор (430) ресурсов; виртуальную файловую систему (435); администратор (440) модулей-деятелей; множество модулей-деятелей (акторов) (445а), (445), …; собственный модуль (450) визуализации пользовательского интерфейса; администратор (460) поддержки, администратор (465) «тригов» и модуль (470) анализа языка разметки.

Это программное обеспечение может функционировать, используя язык TrigML, который является приложением языка XML (Расширяемого языка разметки), и таким образом, что модуль (410) визуализация языка разметки осуществляет визуализацию кода TrigxML для отображения на мобильном устройстве (300). Модуль визуализации языка разметки также использует модуль анализа TrigML для анализа TrigML-ресурсов, отображает контент на экране устройства и управляет замещением и просмотром контента на телефонной трубке. Собственный модуль визуализации пользовательского интерфейса используется для отображения компонентов пользовательского интерфейса, которые могут быть отображены без использования TrigML, и для отображения сообщений об ошибках.

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

Администратор (465) «тригов» представляет интерфейс администратору (430) ресурсов и модулю визуализации языка разметки. Он отвечает за администрирование «тригов» в общем. Это включает в себя: сохранение знания об используемом «триге», смену текущего «трига», выбор «трига» при запуске, выбор дополнительного «трига» в качестве замены для испорченного «трига», поддержание набора установленных «тригов», указание администратору ресурсов того, где установлен конкретный «триг», и считывание определений канала обновления «трига» и соответствующее конфигурирование администратора обновлений.

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

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

Администратор обновлений обрабатывает прием и применение «тригов» и «триглетов». Администратор обновлений представляет интерфейс модулю визуализации и администратору «тригов» и отвечает за: инициацию обновлений в ручном режиме, когда ему дается команда модулем визуализации; управление и реализацию канала автоматического обновления, когда так сконфигурировано администратором «тригов»; указание хода обновления в ручном режиме и восстановление обновления вслед за неожиданной потерей сетевого соединения и/или отключением электропитания устройства. Формат пакета обновления может быть определен как преобразование в двоичную последовательную форму XML-схемы.

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

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

Администратор 440 модулей-деятелей следит за набором модулей-деятелей (445), имеющихся в этом программном обеспечении. Он используется: модулем визуализации, когда контент посылает события модулю-деятелю; модулями-деятелями, которые хотят уведомить об изменении значения атрибута; и модулями-деятелями, которые хотят эмитировать событие (смотри ниже).

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

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

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

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

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

Учитывая ситуации оказания поддержки, диалоговые сообщения об ошибках также отображают код ошибки в виде 4-значной (16-битовой) шестнадцатеричной строки. Каждый код ошибки связан с текстом описания, которое может быть использовано оказывающим поддержку персоналом для определения характера проблемы с программным обеспечением. Ошибки, которые имеют место в программном обеспечении и которые не являются в достаточной мере серьезными для того, чтобы остановить его операции, могут быть зарегистрированы компонентом «администратор поддержки». Администратор поддержки может быть запрошен пользователем, набирающим специальную последовательность клавиш. Администратор поддержки может также передать свой журнал ошибок серверу посредством метода GET (Получение) или POST (Почта) HTTP-протокола (Протокола передачи гипертекста).

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

Например, если нажата клавиша, то модулю визуализации поступает событие 'keypress' ('нажатие клавиши') с параметром, установленным на соответствующую клавишу. Когда клавиша отпущена, модулю визуализации поступает событие '!keypress' ('!нажатие клавиши'). Если клавиша держится нажатой в течение длительного периода времени, то модулю визуализации поступает событие 'longkeypress' ('длительное нажатие клавиши'). Когда ее отпускают, модулю визуализации поступает как событие '!keypress', так и событие '!longkeypress' ('!длительное нажатие клавиши').

Когда бы ни было запущено программное обеспечение, оно исполняет следующие действия:

. проверку на наличие и продолжение прерванной обработки обновления;

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

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

. если текущий «триг» не установлен, то может быть запущен «триг», который отмечен флагом как «триг» 'по умолчанию';

. при отсутствии «трига» по умолчанию будет выбран первый действительный «триг» в алфавитном порядке по имени.

«Триг» запускается посредством загрузки определенного имени ресурса, запуск/умолчание. TrigML-код, определенный в «запуск/умолчание», подвергается анализу как новый контент для корневого узла контента.

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

Запускающий элемент может выглядеть для пользователя как пиктограмма приложения, и ее выбор запускает программное обеспечение с «трига», определенного этим модулем запуска (этот «триг» может быть указан пиктограммой запускающего элемента и/или именем). При использовании запускающего элемента для запуска «трига» имеется возможность определить параметр 'entry point' ('точка входа'). Этот параметр представляет собой имя ресурса файла, найденного в папке 'start-up' ('запуск'). Этот файл не используется, если этот «триг» никогда ранее не исполнялся, и в этом случае вместо этого используется файл, именуемый 'firsttime' ('первый раз').

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

Ниже, в приложении А, приводятся подробности, касающиеся организации файловой системы для варианта осуществления настоящего изобретения. Помимо этого программное обеспечение хранит некоторую или всю из нижеследующей информации: статистику использования, активные счета пользователей, состояние администратора «тригов», TrigML-фрагменты и определение канала обновления (преобразованные в последовательную форму в виде двоичного формата языка XML); изображения в формате PNG (Переносимой сетевой графики); простой текст, закодированный в формате UTF-8 ОТА (Формат 8 ОТА, преобразование универсального набора символов (UCS)) и затем сохраненный в системе кодирования, специфичной для платформы; другие ресурсы, специфичные для платформы, например, файлы с мелодиями звонков, фоновые изображения и т.д.

Файлы в этой файловой системе могут быть изменены либо при изменении значения атрибута модуля-деятеля, либо при замене файла «триглетом». Когда файлы в директории/attrs изменяются, модуль визуализации немедленно получает уведомление об этом, и соответствующие ветви дерева контента обновляются и регенерируются. Когда изменяют изображения и текстовые ресурсы, модуль визуализации ведет себя таким образом, как будто затронутые ресурсы немедленно перезагружаются (может быть регенерировано либо все дерево контента, либо только затронутые его ветви). Когда изменяют TrigML-фрагменты, модуль визуализации ведет себя таким образом, как будто он не был уведомлен и продолжает отображать свой текущий, возможно, устаревший контент. Это сделано для того, чтобы избежать необходимости постоянно хранить элементы<include>(<включение в себя>) и историю элемента<load>(<загрузка>) текущего контента.

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

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

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

<image res=”signallevels/{protocol.signalstrength}”/>

Когда атрибут нужен как файл, то доступ к нему осуществляется через папку /attr.

<text res=”/attr/network/name”>

Модулю-деятелю может быть дано сообщение посредством посылки ему события элементом<throw>(<вбрасывание>). События, эмитированные модулями-деятелями, могут быть доставлены дереву контента в качестве контент-событий: они могут быть нацелены на идентификатор элемента или на 'вершину'. Интерфейс модуля-деятеля определен файлом определения интерфейса модуля-деятеля. Он представляет собой XML-документ, который определяет атрибуты, типы, имена полей, входящие события и параметры, и исходящие события. Набор модулей-деятелей может быть сконфигурирован во время компоновки для программного обеспечения. Приложение В приводит примерный перечень некоторых модулей-деятелей, которые могут быть использованы, вместе со связанными с ними функциями или переменными.

Обновления содержат новый «триг» (новый или заменяющий пользовательский интерфейс) или «триглет» (изменение, вносимое в существующий «триг») и могут рассматриваться как изменения, вносимые в файловую систему программного обеспечения. Администратор обновлений должен определять, что требуется изменить в файловой системе при чтении пакета. Пакеты обновлений могут быть загружены через эфир посредством программного обеспечения (400) c использованием HTTP-протокола (Протокола передачи гипертекста) или других подходящих транспортных механизмов, обернутыми в специфический для устройства упаковочный формат, или могут быть предоставлены заранее при установке самого программного обеспечения.

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

. проверку программным обеспечением наличия прерванной обработки обновления при запуске;

. проверку программным обеспечением наличия заранее установленных пакетов обновлений при запуске;

. автоматически, как это сконфигурировано каналом обновления;

. инициирование пользователем;

. прием устройством специального SMS-сообщения (сообщения службы коротких сообщений).

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

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

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

Для пользовательских интерфейсов, обновлений пользовательских интерфейсов и шаблонов для участия третьей стороны используется контейнер, именуемый посылкой. Посылки содержат всю информацию, необходимую для того, чтобы третья сторона производила, тестировала и поставляла брэндированные (снабженные товарным знаком) пользовательские интерфейсы и их обновления. Фигура 4 показывает схематическое изображение инструментального набора (200) контента, который содержит сценарную среду (220), тестовую и моделирующую среду (230) и среду (240) технического обслуживания.

Процесс создания посылки содержит пять этапов обработки:

1. Сценарная среда (220) предоставляет средство для разработки шаблона для одного или более пользовательских интерфейсов и стратегии обновления для пользовательских интерфейсов, основанных на этом шаблоне.

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

3. Функциональная возможность «предполетной» подготовки, предусмотренная в среде (240) технического обслуживания, позволяет администратору развертывания проверять и настраивать пользовательские интерфейсы и обновления, которые они принимают от третьих сторон.

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

5. Публикующий компонент (110) делает возможным автоматическое генерирование обновлений на основе прямых поставок контента.

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

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

Фигура 5 показывает схематическое изображение устройства (800), которое содержит пользовательский интерфейс в соответствии с вариантом осуществления настоящего изобретения. Устройство содержит дисплей (810), который отображает пользовательский интерфейс (815) и средство (820) пользовательского интерфейса, которое дает пользователю возможность взаимодействовать с пользовательским интерфейсом (815). Процессор (830) исполняет программное обеспечение, которое хранится в одном или более запоминающих средств (840), и может быть предусмотрен один или более интерфейсов (850) беспроводной связи для того, чтобы сделать возможной связь с другими устройствами и/или сетями связи. В устройстве могут быть размещены одна или более батарей (860) для электропитания устройства, которое может также содержать интерфейсы для приема электрического питания и/или кабелей связи.

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

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

Такое устройство может быть реализовано в сопряжении с, фактически, любой сетью беспроводной связи, например, с цифровыми сетями мобильной телефонной связи второго поколения (то есть сетями GSM (Глобальной системы для мобильных телекоммуникаций), D-AMPS (Цифровой усовершенствованной мобильной телефонной службы)), так называемыми сетями поколения 2,5G (то есть сетями GPRS (Службы универсальной радиопередачи), HSCSD, EDGE (технологии «Повышенных скоростей передачи данных для глобальной эволюции»)), сетями WCDMA (широкополосного мультиплексированного доступа с кодовым разделением каналов) или CDMA-2000 (мультиплексированного доступа с кодовым разделением каналов, версия 2000), относящимся к третьему поколению, и с усовершенствованными или производными от этих сетями и аналогичными сетями. Внутри зданий и кампусов могут также быть использованы другие технологии, такие как Bluetooth, IrDa (стандарт Ассоциации по средствам передачи данных в инфракрасном диапазоне) или беспроводные локальные сети (LAN) (как основанные на радио, так и оптических системах). Для синхронизации данных с другими устройствами и/или для зарядки батареи может быть подведена USB (универсальная последовательная шина) и/или шина FireWire.

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

Эта заявка испрашивает приоритет по заявке номер 0403709.9 на патент Великобритании, поданной 19 февраля 2004 г., содержимое которой включено в данный документ посредством ссылки.

Приложение А

Для путей доступа к файлам, начинающихся с идущего впереди символа '/':

/attr	Подобно директории /proc в системе unix здесь хранятся значения атрибутов модулей-деятелей для ссылки посредством контента, когда атрибут необходим как файловая ссылка.
<actor>(<модуль-деятель>)	Каждая поддиректория директории /attr представляет собой имя модуля-деятеля.
<attribute>(<атрибут>)	Доступ к каждому атрибуту осуществляется как к узлу в поддиректории модуля-деятеля.
<field>(<поле>)	Если атрибут представляет собой структуру, то имя поля определяет то, к какому элементу структуры осуществлять доступ.
<index>(<индекс>)	Если атрибут представляет собой векторный атрибут, то индексное число определяет индекс в векторе требуемого атрибута.
<field>(<поле>)	Если векторный атрибут представляет собой коллекцию структур, то имя поля вновь определяет элемент структуры.

Пути доступа к файлам, не имеющие идущего впереди символа '/', считаются относящимися к текущему «тригу», то есть каждый «триг» хранится в своей собственной иерархии папок, имеющей корень в одной папке.

config(конфигурация)	Общая папка в каждом «триге» для хранения метаданных «трига».
channels(каналы)	Общая папка для хранения определений каналов обновлений.
<channel defs>(<определения каналов>)	Набор файлов, определяющий коллекцию каналов обновления для «трига». Каждый файл может определять один или более каналов обновления.
start-up(запуск)	Общая папка для хранения точек входа для «трига».
default(умолчание)	Общий TrigML-файл для хранения точки входа по умолчанию для «трига».
firsttime(первый раз)	Общий TrigML-файл для хранения TrigML-документа для использования при первом исполнении «трига».
<trigml files>(<TrigML-файлы>)	Другие поименованные TrigML-файлы могут быть использованы в качестве точек входа, если они найдены в папке запуска.
constants(константы)	Эта папка не проходит ОТА и вместо этого разрешается во время компиляции контента.
<rest of content>(<остальной контент>)	Контент «трига» организован в определенном «тригом» формате под папкой «тригов».

Приложение В

Trigplayer Actor(Модуль-деятель, проигрывающий «триги»)	Атрибуты	UpdateState(Состояние обновления)
Сообщения	exit(выход)
predial_mode(режим, предшествующий набору номера)	on/off(включено/выключено)
События	idle(ожидание)
Launch Actor(За