КОНТЕЙНЕР ДАННЫХ ДЛЯ ДАННЫХ КОНТЕНТА ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА Российский патент 2009 года по МПК G06F9/445 

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

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

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

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

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

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

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

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

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

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

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

Перечень фигур чертежей

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

фиг.2 - более подробное изображение структуры и работы сервера;

фиг.3 - схема программного обеспечения 400 для мобильных устройств;

фиг.4 - схема набора инструментальных средств контента;

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

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

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

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

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

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

ОМС может иметь несколько публикующих доменов, например один домен для каждого целевого сервера в нескольких странах или регионах. С каждым доменом обращаются изолированно от других доменов, и каждый домен имеет свою собственную схему публикации, описывающую, как должны быть опубликованы объекты в информационные серверы как в активной, так и промежуточной средах. GUI, ГПИ (графический пользовательский интерфейс) публикующего компонента предоставляет несколько различных видов в каждый домен, давая возможность операторам полностью управлять публикацией контента. Каталог содержит ссылки на триги, хранящиеся в каталоге, и каналы обновления и каналы подачи, используемые для переноса контента в различные домены. Для каждого домена оператор использует ГПИ публикующего компонента, чтобы конфигурировать структуру домена и назначать триги из каталога каждому узлу домена. Чтобы помочь оператору в эффективном выборе тригов, в каталоге предоставлен фильтр, так чтобы были показаны только релевантные элементы.

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

На каналы обновления можно ссылаться с помощью тригов для управления доставкой контента. Канал обновления содержит URL (универсальный адрес информационного ресурса), который является ссылкой на ресурс в ассоциированном домене, который содержит пакет обновления триглета. URL можно опрашивать через предварительно определенные интервалы времени и с помощью функции GET (получить) HTTP (протокола передачи гипертекста), используемой для доступа к пакету (очевидно, будет понятно, что могут быть использованы другие транспортные схемы, например SyncML или SMS, или широковещательная передача в соте для малых обновлений). Пакет обновления триглета описывает, как может быть модифицирован триг, например замену одного или более файлов изображений или текстовых файлов, используемых тригом. ГПИ публикующего компонента дает возможность оператору задавать каналы обновления и управлять каналами обновления, которые имеются для домена, указателями URL, связанными с каждым триглетом в канале обновления, и взаимосвязью триглетов с каналами обновления для домена. Так как каждый триглет ассоциирован с каналом обновления, оператор может вводить дату и время, в которые должно быть опубликовано обновление, давая возможность устанавливать расписание.

Источник контента подобен каналу обновления, для которого обновления контента автоматически генерируются на регулярной основе. Доступ к источнику контента осуществляют с помощью опроса URL, извлечения обновленного пакета и применения его к тригу. Однако из-за разного характера обновлений сконструированного вручную триглета и автоматически сгенерированного контента каналами обновления и устройствами подачи контента управляют раздельно. Кроме того, могут быть использованы другие транспортные схемы, такие как SincML или OMA-DM (управление устройствами по схеме открытого альянса мобильных систем).

Контентный серверный компонент 150 является стандартной реализацией Web-сервера и, по существу, модель масштабирования достаточно понятна. Функциональные возможности сервера могут быть оценены с использованием номера “SPECweb99”, указывающего количество одновременных сеансов, которые Web-сервер может обрабатывать при условиях эталонного тестирования. Опубликованные номера SPECweb99 находятся в диапазоне от 404 до 21000, причем типичные коммерческие Web-серверы имеют номера SPECweb99 порядка 5000. Типичный сценарий развертывания для 1 миллиона абонентов с ежечасным обновлением контента требует Web-сервер с оценкой SPECweb99 только 1112. Успешное развертывание приведет к увеличенному использованию услуг, что может быть обеспечено с помощью предоставления дополнительных серверов для создания инфраструктуры, которая может быть как масштабируемой, так и очень устойчивой к сбою.

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

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

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

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

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

Программное обеспечение 400 поставляют и устанавливают в устройстве особым способом. Например, для устройства серии 60 Nokia программное обеспечение устанавливают с использованием файла SIS, в то время как для устройства MS Smartphone программное обеспечение устанавливают с использованием файла САВ. Подобным образом модернизацию программного обеспечения осуществляют способом, зависящим от конкретного устройства. Программное обеспечение может быть поставлено в более ограниченном формате, как автономное программное приложение, которое визуализирует только свой встроенный контент, т.е. программное обеспечение поставляют со встроенным тригом, но дополнительные триги не могут быть добавлены позже. Поставленный триг может быть модернизирован через эфир.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фрагменты TrigML являются файлами, содержащими текстовый TrigML, а ссылки на ресурсы внутри этих фрагментов являются путями к виртуальным файлам. Соответствие этих путей виртуальным файлам, путям к реальным файлам задается файлом определение трига TrigDefinition. Этот файл также определяет другие характеристики трига. При использовании для компиляции триглета этот файл также определяет, как задается соответствие входных TrigML/PNG/текстовых ресурсов изменениям виртуальной файловой системы трига.

Для PNG и текстовых ресурсов файл определения трига указывает на список реальных файлов в главной файловой системе, и ресурсы копируются в выходные данные.

TrigML может использовать переменные-константы вместо значений атрибутов. Доступ к переменным-константам осуществляют с помощью того же синтаксиса, как <включить> (<include>) параметры, например $фоновый_цвет. Константы обрабатывают как глобальные переменные в триге и их определяют в зарезервированной папке, constants/. Определения переменных, содержащиеся в файлах в папке constants/, могут быть разрешены во время компиляции с помощью прямой подстановки их значений. В альтернативном варианте осуществления определения переменных в constants/ компилируют как глобальные переменные и разрешают во время синтаксического разбора контента программным обеспечением. Это дает возможность обновлять триг с помощью простой замены одного или всех его файлов констант.

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

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

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

Фиг.4 схематически изображает набор 200 инструментальных средств контента, который содержит среду 220 сценариев, среду 230 тестирования и имитации и среду 240 поддержки.

Обработка посылки содержит пять этапов обработки.

1. Среда 220 сценариев предоставляет средство для разработки шаблона для одного или более ПИ и стратегию обновления для ПИ на основании этого шаблона.

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

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

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

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

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

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

Основные функции среды 220 сценариев могут содержать следующее.

Определяет структуру меню и отображение страницы.

Определяет инфраструктуру, в которую помещен маркированный контент.

Определяет части ПИ, которые являются обновляемыми.

Определяет части и обновления, которые являются заменяемыми для перемаркировки.

Обеспечивает интерактивный предварительный просмотр, чтобы помочь редакторам.

Обеспечивает графическое представление кода каждого уровня ПИ.

Позволяет перетаскивать ресурсы в интерактивный предварительный просмотр и представление кода.

Экспортирует шаблоны для специфических задач перемаркировки или построения обновления.

Имитирует интерфейсы ПИ и обновления в имитаторе телефона.

Создает интерфейсы ПИ и обновления для тестирования в реальном устройстве.

Предоставляет расширенные инструментальные средства отладки для содействия в разработке.

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

перемаркировка шаблонов ПИ;

наполнение обновлений новым контентом;

управление элементами меню ПИ через обновления;

переводить интерфейсы ПИ и обновления на дополнительные языки;

назначение строк и контента для дополнительных устройств;

имитация интерфейсов ПИ, развернутых в имитаторе телефона;

создание интерфейсов ПИ и обновлений для тестирования перемаркированного ПИ в реальном устройстве.

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

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

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

Из общей базы могут быть получены многие разные ПИ. Обычно общая база сама реализует большую часть интерфейса, и триги, производные от нее, реализуют небольшие изменения в нем, такие как маркировка. Триглет может быть получен из трига, и он может заменять любые из ресурсов из родительского трига, которые им выбраны (в необязательном порядке, он может вводить свои собственные ресурсы). Следует заметить, что “ресурсы” в настоящем описании также относятся к TrigML, таким образом, поведение и компоновка трига могут быть модифицированы с помощью триглета точно так же легко, как замещение одного изображения или части текста.

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

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

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

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

Проектировщик графики создает окончательную графику и добавляет ее к конструкции.

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

Графика для динамического обновления должна быть закончена проектировщиком графики.

Затем проектируют и реализуют области персонализации ПИ. Этим могли бы управлять несколько поставщиков контента третьей стороны.

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

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

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

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

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

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

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

По этой заявке испрашивается приоритет заявки на патент Великобритании номер 0403709,9, поданной 19-го февраля 2004 г., содержание которой включено в настоящее описание посредством ссылки.

Приложение А

Актор воспроизведения трига Атрибуты Состояние обновления   Сообщения Выход   Режим перед набором номера Вкл/выкл События    

Актор запуска Атрибуты     Сообщения Браузер URL SMS Номер   Сообщение Камера   Почтовый ящик для входящих сообщений   Профили   Пропущенные вызовы   Средство набора телефонного номера Номер …       Собственное приложение Идентификатор приложения   URL События    

Актор установки Атрибуты     Сообщения Тональный сигнал звонка Путь к ресурсу Фоновая графическая картинка Путь к ресурсу События     Актор телефона Атрибуты Bluetooth   IrDA   Вызов   GPRS   Непрочитанные SMS   Непрочитанная голосовая почта   Непрочитанные сообщения   Уровень заряда батареи   Интенсивность сигнала   Сообщения     События Пропущенный вызов   Поступившее сообщение   Поступившая голосовая почта  

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

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

2. Способ по п.1, дополнительно содержащий этап, на котором
e) обрабатывают содержимое контейнера в формат, предназначенный для передачи в мобильное устройство, причем этап е) выполняют после этапа а) и перед этапом b).

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

4. Способ по п.1, в котором метаданные содержат данные, определяющие доступ к исполняемому коду и/или к каждому ресурсу контента, чтобы предотвратить несанкционированный доступ к исполняемому коду и/или к каждому ресурсу контента во время этапа а).

5. Способ по любому из предшествующих пунктов, в котором, если во время этапа а) исполняемый код и/или ресурс контента изменяются, соответственно обновляют метаданные.

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

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

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

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

10. Способ по п.9, в котором метаданные содержат данные, определяющие доступ к исполняемому коду и/или к каждому ресурсу контента, чтобы управлять доступом к исполняемому коду и/или к каждому ресурсу контента во время этапа b).

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

12. Носитель данных, содержащий машиноисполняемый код, предназначенный для выполнения способа по любому из пп.9-11.

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

14. Мобильное устройство по п.13, в котором метаданные, сохраненные в средстве хранения данных, содержат данные, определяющие доступ к исполняемому коду и/или к каждому ресурсу контента, чтобы управлять доступом к исполняемому коду и/или к каждому ресурсу контента.

15. Мобильное устройство по п.14, дополнительно выполненное с возможностью при использовании принимать управляющие команды из сети связи через интерфейс связи, причем управляющие команды обновляют метаданные, которые определяют доступ к коду и/или к ресурсу (или ресурсам контента).