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

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

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

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

прием выбора по меньшей мере одного значения триггера, связанного по меньшей мере с одним событием;

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

прием выбора доступного действия; и

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

при этом указанное действие должно быть выполнено устройством в ответ на указанное по меньшей мере одно значение триггера.

2. Способ по п.1, в котором указанное по меньшей мере одно значение триггера соответствует значению, генерируемому устройством.

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

4. Способ по п.1. в котором указанное по меньшей мере одно значение триггера соответствует значению, генерируемому вне устройства.

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

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

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

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

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

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

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

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

при этом указанное действие должно быть выполнено терминалом в ответ на указанное по меньшей мере одно выбранное значение триггера.

8. Терминал по п.7, в котором указанное по меньшей мере одно значение триггера соответствует значению, генерируемому в пределах терминала.

9. Терминал по п.7, в котором указанное по меньшей мере одно значение триггера соответствует значению, генерируемому датчиком терминала.

10. Терминал по п.7, в котором указанное по меньшей мере одно значение триггера соответствует значению, генерируемому вне терминала.

11. Терминал по п.7, в котором сценарий правил, который описывает другое правило, поступает извне от другого пользователя.

12. Терминал по п.7, в котором сценарий правил, который описывает другое правило, поступает извне от стороннего поставщика сценария правил.

13. Терминал по п.7, который представляет собой мобильный терминал.

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

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

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

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

для приема выбора доступного действия; и

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

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

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

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

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

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

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

20. Терминал, содержащий:

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

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

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

средство для приема выбора действия; и

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

при этом указанное действие должно быть выполнено терминалом в ответ на указанное по меньшей мере одно значение триггера.

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

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

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

24. Терминал по п.20, который представляет собой мобильный терминал.

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

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

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

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

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

Проблеме адаптации работы приложения к контексту уделено большое внимание в литературе. Хотя задача зависящих от контекста вычислений хорошо обоснована и привела к разработке устройств, которые способны реагировать на ситуацию и соответственно адаптировать свои действия, имеется одна фундаментальная проблема, а именно: понимание контекста людьми радикально отличается от понимания его компьютерными системами (см., например, Erickson, Т., Some problems with the notion of context-aware computing, Communications of the ACM, 45(2), (2002), 102-104). Жестко запрограммированные полностью автоматические действия, основанные на контексте, редко приносят пользу, а возникновение неправильных автоматических действий приводит к негативным последствиям. Гринберг отметил (Greenberg, S., Context as a dynamic construct, Human-Computer Interaction, 16 (2001), 257-268), что не всегда можно априори перечислить ограниченный набор контекстов, которые согласованы с реальным контекстом. Если такой набор найден и на данный момент он справедлив, он может оказаться неподходящим в любое другое время из-за "внутренних и внешних изменений в социальных и физических обстоятельствах". Кроме того, определение подходящего действия по данному контексту может оказаться затруднительным,

Однако нет необходимости стремиться к полностью автоматизированным действиям как единственной цели понимания контекста. Мянтюярви и др. (Mäntyjärvi, J., Känsälä, I., Tuomela, U., Häkkilä, J., Context-Studio - Tool for Personalizing Context-Aware Applications in Mobile Terminals, Proc. Australasian Computer Human Interaction Conference 2003, (2003), 64-73) предложили для адаптации на основе контекстов использовать категоризацию системы автоматизации. Можно выделить три различных уровня автоматизации контекстно зависимых действий: ручной, полуавтоматический и полностью автоматический. Ручные действия относятся к действиям, производимым пользователем на основе контекстной информации, которая выявлена устройством (или пользователем). На полуавтоматическом уровне пользователь может заранее задать действия приложения на основе контекста, выявленного устройством, или выбрать одно из действий, предложенных устройством на основе контекста. На полностью автоматическом уровне приложение автоматически совершает (заранее заданные) действия согласно контексту, выявленному устройством.

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

Для определения действий приложения на основе контекста Ранганатан и Кэмпбелл (Ranganathan, A., Campbell, R., An infrastructure for context-awareness based on first order logic, Personal and Ubiquitous Computing Journal 7, Springer-Verlag, (2003), 353-364) ввели модель на основе правил логики первого порядка и распределенной структуры. В последующей работе авторы разработали графический интерфейс, который позволяет пользователю выбрать из имеющихся контекстов и действий элементы правила, вместо того, чтобы записывать логику первого порядка. Т. Сон и А. Дей (Sohn, Т., Dey, A., 2003 ICAP: An Informal Tool for Interactive Prototyping of Context-Aware Applications, Ext. abstracts CHIOS, (2003), 974-975) ввели неформальный инструмент на основе пера, который позволяет пользователям задать устройства ввода, которые собирают контекстную информацию, и устройства вывода, которые поддерживают ответ. Вводы и выводы могут быть объединены в правила и протестированы с помощью инструмента. Однако этот инструмент не предназначен для небольших мобильных терминалов и устройств с небольшим экраном, а кроме того, элементы интерфейса пользователя не генерируются на основе четкой информационной модели. В качестве цели будущей работы авторы выделяют предоставление возможности как разработчикам, так и конечным пользователям создавать и модифицировать приложения, понимающие контекст. Дей и др. (Dey, A., Hamid, R., Beckmann, С, Li, I., Hsu, D, a CAPpella: Programming by Demonstration of Context-Aware Applications, Proc. CHI 2004, ACM, (2004)) экспериментировали с подходом типа "программирование-путем-демонстрации", чтобы создать прототип приложения, понимающего контекст. Авторы разработали инструмент, который позволяет пользователю обучать и делать комментарии с помощью приведенных для примера моделей контекстов, которые могут быть связаны с действиями. Интерфейс пользователя такого инструмента также не предназначен для мобильных устройств с небольшим экраном. Кроме того, как говорится, "фокус отличается от фокуса", что как нельзя более справедливо для данного изобретения, которое относится к масштабируемой модели для представления контекстов онтологии в интерфейсе пользователя, где контексты свободно выбираются пользователем.

Онтология контекстов может использоваться для перечисления всех возможных контекстных событий, которые могут использоваться для действий по активизации. Для онтологии имеется множество определений (см. Gomez-Perez, A., Fernandez-Lopez, M., Corcho, О., Ontological Engineering,. Springer-Verlag, (2003), 403 р.). В настоящем описании считается, что целью онтологии является выражение информации так, чтобы она была легко понимаема людьми и могла восприниматься машинами. Человеческое понимание контекстной информации позволяет конечному пользователю мобильного устройства сформировать свойства, зависящие от контекста. Способность машины к восприятию контекстной информации позволяет динамически формировать элементы интерфейса пользователя на основе онтологии. Кроме того, онтология облегчает описание правил в виде XML-сценариев протокола обмена контекстами (СЕР, Context Exchange Protocol), которые могут быть выполнены машиной логического вывода (Lakkala, H., Context Script Specification, (2003), 22 р. Доступна по адресу: http://www.mupe.net, ниже - ссылка Lakkala 2003b). В литературе имеется множество контекстных моделей и онтологии, например (Schmidt, A., Aidoo, К.А., Takaluoma, A., Tuomela, U., Laerhoven, К., Van de Velde, W., Advanced interaction in context, Proc. 1st International symposium on handheld and ubiquitous computing 1999, Springer-Verlag, (1999); Henricksen, K., Indulska, J., Rakotonirainy, A., Modeling Context Information in Pervasive Computing Systems, Proc. International Conference on Pervasive Computing 2002, LNCS 2414, Springer-Verlag, (2002); and Wang, X., Zhang, D., Gu, Т., Pung, H., Ontology Based Context Modeling and Reasoning using OWL, Proc. Workshop on Context Modeling and Reasoning at IEEE International Conference on Pervasive Computing and Communication, (2004), 18-22).

Вышеупомянутый инструмент Context Studio представляет собой инструмент по персонализации приложения для полуавтоматической адаптации на основе контекста. Персонализация приложения выполняется с использованием графического интерфейса пользователя, который позволяет пользователю сопоставить контексты действиям приложения. Концепция Context Studio была представлена Mäntyjärvi и др. (2003), которые представили также оценку практичности и простоты использования для прототипа этого инструмента, предназначенного для доказательства полезности концепции контекстов. Результаты оценки показали, что испытуемые люди были способны уяснить принцип контекстной установки для конкретного приложения, но испытывали затруднения в выражении правильных условий, определяемых пользователем. Субъективная идея о контекстах в сценариях использования менялась от одного испытуемого к другому, влияя на их выбор. Кроме того, испытуемые затруднялись в составлении правил, которые включали использование множества булевых операторов.

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

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

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

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

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

По меньшей мере одно значение триггера может быть значением, генерируемым в пределах мобильного терминала, например значением, генерируемым датчиком мобильного терминала, и/или по меньшей мере одно значение триггера может быть значением, генерируемым вне мобильного терминала.

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

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

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

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

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

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

на фиг.2 показан пример типа контекста и набора значений контекстов;

на фиг.3 показан пример изображения при работе в редакторе правил Context Studio и пример соответствующего сценария протокола обмена контекстами;

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

на фиг.5 показана Таблица 2, содержащая примеры типов действий в словаре категорий действий для телефона;

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

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

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

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

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

В приведенных для примера вариантах выполнения настоящего изобретения используются контекстовые и словарные модели, модель правил и контекстная структура, раскрытые в следующей работе (Korpipää, Р., Mäntyjärvi, J., Kela, J., Keränen, H., Malm, E-J, Managing Context Information in Mobile Devices, IEEE Pervasive Computing Magazine special issue: Dealing with Uncertainty 2(3), IEEE Computer Society, (2003), 42-51, ниже упоминается как Korpipää и др. 2003). Эти модели обеспечивают динамическое управление правилами и расширяемыми словарями контекстов и позволяют автоматически генерировать элементы интерфейса пользователя в процессе работы.

В приведенных для примера вариантах выполнения настоящего изобретения используется онтологическая модель контекстов для мобильного телефона на основе датчиков (см. Korpipää, P., Mäntyjärvi, J, An Ontology for Mobile Device Sensor-Based Context Awareness, Proc. 4th International and Interdisciplinary Conference on Modeling and Using Context 2003, LNAI2680, Springer-Verlag, (2003), 451-459, ниже упосинается как Korpipää & Mäntyjärvi, и см. также Korpipää и др. 2003), которая представляет собой более детализированную модель словаря и является развитием предыдущих моделей.

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

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

Онтологическая структура определяется как набор свойств. В приведенных для примера вариантах выполнения настоящего изобретения каждый контекст (объект) описан с использованием шести свойств: Тип контекста, Значение контекста, Источник, Конфиденциальность, Временная метка и Атрибуты (см. Korpipää и Mäntyjärvi 2003). Определение словарей контекстов включает определение наборов Типов контекстов и Значений контекстов (в качестве примера см. сриг.6). Другие признаки, которые не имеют отношения к пониманию настоящего изобретения, в дальнейшем не обсуждаются.

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

На фиг.1 и 2 типы 1 контекста определены по именам и классифицируют значения контекста. Тип 1 контекста похож на имя переменной, в то время как значения 2 контекста похожи на набор значений для переменной. Фиг.1 иллюстрирует пример модели словаря для одного типа 1 контекста и набора значений 2 контекстов для типа 1 контекста. На фиг.2 показан пример одного описания контекста для словаря. Тип 1 контекста может иметь одну или несколько концепций [Concept] (например, Conceptl , ConceptN), и каждый тип 1 контекста может иметь одно или несколько значений контекста (Valuel , ValueM). Экземпляр контекста в определенное время может иметь одно из значений (1-М) для каждого типа 1 контекста. Различные типы контекстов могут иметь по меньшей мере одну общую концепцию. Следовательно, можно и предпочтительно для концепций типа 1 контекста сформировать древовидную иерархию, где листья представляют значения 2 контекста. Эта иерархия может использоваться для запроса и обращения к ветвям дерева контекстов вместо линейного поиска.

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

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

В таблице 1, изображенной на фиг.4, представлен пример словаря контекстов, где описаны контексты категорий устройств, которые извлечены из данных датчика ускорения и сенсорного датчика (датчика касания). Можно отметить, что контекст примера, показанного на фиг-2, описан в виде текста в первом ряду таблицы 1, где две концепции (Устройство, Ориентация) ассоциированы с шестью значениями, связанными с антенной и ориентацией дисплея (например, вверх, вниз влево, вправо).

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

Телефон: Джойстик; Телефон: Клавиатура и ассоциированные значения 4 действия. Кроме того, внешние устройства могут объявлять свои действия, которые могут быть динамически включены как словари действий в Context Studio.

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

СОГЛАШЕНИЕ О НАИМЕНОВАНИЯХ

Управление контекстами в Context Studio предпочтительно использует структуру контекстов (см. Korpipää и др. 2003). Подходящее имя можно рассматривать в качестве существенного условия, особенно при описании признаков, типа контекста, значения контекста и источника, которые необходимы для каждого объекта контекста, добавленного к менеджеру контекста типа "классной доски". Эти признаки также используются для получения доступа к информации о контекстах из менеджера контекстов. При именовании типов контекста имеется два главных аспекта. Во-первых, подходящее имя должно отражать значение контекста для пользователя, который обычно является или разработчиком приложения, или пользователем инструмента персонализации. Имя предпочтительно указывает на использование контекста. Во-вторых, использование правильного соглашения об именах гарантирует, что пользователь контекстной информации может полностью использовать функции, предлагаемые менеджером контекстов.

Когда типы контекстов строятся в виде путей, содержащих элементы от общей концепции до специфической концепции, к контекстной информации можно получить доступ посредством частичных типов контекстов, которые представляют собой большие поднаборы контекстной информации. Такое соглашение об именах использовалось также в вышеупомянутом протоколе обмена контекстами (СЕР), где ссылка на поднабор иерархии типов контекстов называется групповым символом (см. Lakkala, EL, Context Exchange Protocol Specification, (2003), 28 p.доступна по адресу: http://www.mupe.net, ниже упоминается как Lakkala 2003a). Кроме того, протокол обмена контекстами рекомендует, чтобы имена типов контекстов, зависящих от поставщика, начинались с префикса, обозначающего этого поставщика, например, "x-vendor_name:", после чего следует нормальное определение типа контекста.

Набор значений контекстов может быть численным или символьным. Если значения контекстов описаны как численные, то для практического использования предпочтительно, чтобы они имели ясное для людей значение, например окружающая температура в градусах. Если используются необработанные измеренные значения, нет необходимости именовать набор значений контекстов и обычно можно использовать тип 1 контекста. Если значения 2 контекстов для персонализации определяются пользователем, предпочтительно, чтобы они были понятными для человека, символическими, а количество значений в наборе должно быть небольшим, но достаточным, чтобы обеспечить выбор значений из набора, с выбором функции, зависящей от условий в формулировке правила. Когда требуется малый набор значений, численные значения могут быть разделены на именованные интервалы, например, температурное значение может быть "свыше 20". Имеется несколько других способов перевода численных значении в символические значения (см., например, Korpipää и др. 2003).

Характеристика источника контекста не описана в словарях, но она необходима, если имеется много поставщиков контекста для одного и того же типа 1 контекста 1 и если клиент интересуется контекстами, имеющими конкретный источник. Таким образом, политика именований для источника желательна для того, чтобы избежать конфликта имен между различными поставщиками контекстной информации. Категории источников могут именоваться как внутренний по отношению к терминалу и внешний по отношению к терминалу. Имена внутренних по отношению к терминалу источников можно давать, начиная с префикса, например: "Terminal": (терминал) или "Phone" (телефон), за которым следует описание источника, например название датчика. Если терминальный источник имеет множество элементов, их предпочтительно называть аналогично типу 1 контекста, где имя формирует путь, например, "Terminal:Sensor:Acceleration". Имена внешних по отношению к терминалу источников можно формировать как название протокола, идентифицирующее поставщика, например, "http://context_provider.com/context_type" (см. Lakkala 2003a).

ПРАВИЛА в Context Studio

Context Studio позволяет пользователю определить правила, которые связывают контексты с действиями. Когда правила в мобильном устройстве активны, контексты вызывают действия, определенные правилом. Элементы частей "условия" для правила называют триггерами. Триггер может быть любым событием или состоянием, которое может использоваться для запуска действия. Триггеры - это элементы словаря контекста. Тип 1 контекста (имя переменной) и значение 2 контекста (значение переменной) совместно задают триггер. Действие - это любое приложение, функция или событие, которое может быть запущено, когда срабатывает набор триггеров, причем набор триггеров содержит по меньшей мере один элемент. Элемент части "действия" правила называется действием. Для ясности, одно правило может содержать одно действие. Тип 3 действия и тип 4 действия определяют одно действие.

Правило - это выражение, связывающее набор триггеров с действием. В приведенных для примера вариантах выполнения настоящего изобретения правила содержат один элемент действие и по меньшей мере один элемент триггера. Правила имеют следующую структуру: ЕСЛИ триггер (триггеры), ТОГДА действие. Чтобы сделать определение правил простым для пользователя, предпочтительно, чтобы единственным оператором для объединения триггеров был И. Пример правила, содержащего множество триггеров, приведен ниже: ЕСЛИ триггер 1 И триггер 2 И триггер 3 ТОГДА действие. В приведенных для примера вариантах выполнения настоящего изобретения использован оператор ИЛИ, что позволяет пользователю определить дополнительные параллельные правила для того же самого действия. Однако следует отметить, что в других вариантах выполнения настоящего изобретения совокупность операторов (например, ИЛИ, И и/или другие булевы операторы) может использоваться в одном и том же правиле. Кроме того, в приведенных для примера вариантах выполнения настоящего изобретения пользователю позволяют создать неполные правила, то есть часть "действие" или триггерная часть могут быть опущены. Неполные правила представлены в интерфейсе пользователя пиктограммами как заблокированные.

В Context Studio применяется представление сценария контекстов с использованием протокола обмена контекстами для правил (Lakkala 2003 а, 2003b). Сценарии контекстов - это полуформальные описания на языке XML, которые могут использоваться для описания правил. Пример правила (Rule), описанного как сценарий контекста, показан на фиг.3:

Если устройство неподвижно, а дисплей повернут вниз, тогда установить звуковой профиль в состояние "Собрание" (Meeting).

Пример Rule заставляет профиль устройства переключиться в состояние "Собрание", если ориентация устройства - дисплеем вниз, и устройство неподвижно. Правила, соответствующие техническим параметрам сценария, и правило Context Studio могут быть отображены на интерфейсе пользователя, как показано на чертеже. Следовательно, можно использовать правила, определенные другими, можно произвести по беспроводной связи обмен сценариями правил с другими пользователями и можно загрузить по беспроводной связи сценарии правил из источника правил. Однако некоторые правила могут быть персональными и, таким образом, не могут быть использованы другими. Например, если местоположение дома некоторого человека привязано к координатам места, описание будет недействительно для дома кого-либо еще (если только это, например, не другой член семьи пользователя, проживающего в том же месте). Следует отметить, что шрифты, показанные на фиг.3, не обязательно соответствуют масштабу.

Сценарии правил могут быть созданы, просмотрены и отредактированы в окне Правила (Rule) интерфейса пользователя. На фиг.3 представлен вид окна Rule в виде сценария в рамках протокола обмена контекстами.

Управление контекстами в Context Studio предпочтительно основано на структуре контекста для мобильных устройств в виде "классной доски" (см. Korpipää и др. 2003), а сценарии правил оцениваются с использованием машины логического вывода, называемой машиной сценариев (Lakkala 2003 а), в которой используется менеджер контекстов. Условные операции, например, И, ИЛИ, НЕ, РАВНО, НЕ РАВНО, МЕНЬШЕ, БОЛЬШЕ, МЕНЬШЕ ИЛИ РАВНО, БОЛЬШЕ ИЛИ РАВНО и В ДИАПАЗОНЕ поддерживаются моделью сценариев контекстов и машиной логического вывода. В примере онлайновой системы менеджер контекстов принимает всю контекстную информацию из источников контекстов и от референтов и указывает машине сценариев на изменения в тех контекстах, которые используются в сценариях правил, сгенерированных Context Studio и определенных пользователем с помощью графического интерфейса пользователя. Машина сценариев оценивает правила для измененных контекстов, и инициированные правила используются для запуска действий приложения или событий в базовой системе, как задано в этом правиле.

ИНТЕРФЕЙС ПОЛЬЗОВАТЕЛЯ

Правила Context Studio предпочтительно задаются пользователем с использованием графического интерфейса пользователя (GUI), называемого также просто интерфейсом пользователя (UI), путем следования полуавтоматической модели адаптации. Интерфейс пользователя - это применение онтологии контекста. Представление триггеров и действий основано на модели словаря онтологии. Элементы изображения Триггер, Действие и Правило в интерфейсе пользователя могут быть автоматически и динамически сгенерированы на основе моделей правил и онтологии. Для облегчения пользователю поиска иерархия онтологии может быть преобразована в представление файловой модели в интерфейсе пользователя. Концепции типов контекстов и действий могут быть представлены как каталоги и подкаталоги согласно иерархии словаря. Значения контекстов и действия соответствуют файлам в каталогах концепций. Расширение и модификация возможны в процессе работы, и соответственно может быть обновлен интерфейс пользователя. Новые типы контекстов и действий представлены в интерфейсе пользователя как пути, а новые значения контекстов и действий представлены как новые файлы в каталогах.

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

Предположим в качестве примера, что пользователь просматривает словарь контекстов в категории Устройство (Device) в поисках нужного триггера для правила, заданного в более раннем примере. Пользователь следует по пути DeviceMovement и после выбора значения контекста Тар (Постукивание) для типа Gesture (Жест) отображение переходит к окну редактирования правила, как показано в примере на фиг.7. В интерфейсе пользователя можно просматривать иерархию действий и управлять ею аналогичным образом.

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

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

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

Подходящие правила, соответствующие этим примерам сценария, можно построить, выбирая соответствующие определения в окне редактирования правила, см. фиг.3. Выбранные значения можно найти путем просмотра иерархической каталогизированной структуры "триггеры" и "действия"'. На фиг.6 показан пример триггера (триггеров), части "действия", иерархической информационной модели (например, Устройство [Device]==>Перемещение [Movement]==>Тряска/Наклон/Вращение [Shake/Tilt/Spin]) и последующая автоматическая генерация интерфейса пользователя согласно иерархической модели.

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

Кроме того, онтология поддерживает использование сценариев контекстов в качестве формальной модели правил.

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

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

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

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

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

Обратимся к фиг.6 и 7. На фиг.6 показаны упрощенные иллюстративные компоненты правил для модели, а на фиг.7 показано формирование правила на основе иерархии каталогов, сгенерированной из словаря модели. На фиг.7 пользователь выбирает по меньшей мере один триггер и действие, которые совместно формируют правило. В качестве примера определения триггера каталогизированная структура доступных триггерных событий генерируется автоматически согласно иерархической информационной модели (см. фиг.6); пользователь выбирает тип значения триггера из набора доступных триггеров (в этом случае "Жест" (Gesture), a затем выбирает конкретное значение триггера "Жест" (в данном случае Тар (Постукивание)). Действие может быть определено аналогичным образом.

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

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

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

На фиг.8 показана упрощенная блок-схема устройства 100 согласно не ограничивающему изобретение варианту его выполнения, например, мобильного устройства, такого как мобильный терминал, который может использоваться для реализации приведенных для примера вариантов выполнения настоящего изобретения. Примеры подходящих мобильных устройств включают, но этим не ограничиваются, мобильные телефоны, персональный цифровой секретарь (PDA), портативные компьютеры, устройства захвата изображения, например цифровые камеры, игровые устройства, устройства для записи и воспроизведения музыки и портативные блоки или терминалы, которые включают комбинации таких функций. Мобильное устройство 100 содержит процессор 102, соединенный с памятью 104 (по меньшей мере часть которой может быть устройством с долговременной памятью (NVM, non-volatile memory), предназначенной для хранения определенных Правил), в которой хранится по меньшей мере рабочая программа (ОР, operative program) 104А для процессора 102, причем предполагается, что рабочая программа 104А позволяет реализовать способы согласно вариантам выполнения настоящего изобретения. Мобильное устройство 100 содержит также интерфейс 106 пользователя, включающий экран 106А дисплея (или эквивалентное устройство для представления данных) для отображения интерфейса пользователя и по меньшей мере одно устройство 106В для ввода данных (DE, data entry), например клавишное поле или клавиатуру, указательное устройство, сенсорный экран или комбинацию устройств для ввода данных. При помощи этих компонентов пользователь может определить Правила (Rules), как показано примерами на фиг.1-7, которые затем хранятся в памяти 104. Мобильное устройство 100 может также включать по меньшей мере один датчик 108, например акселерометр, термометр, механический переключатель и/или подсистему определения местоположения (например GPS приемник), которая способна воспринимать некоторое внутреннее и/или внешнее состояние мобильного устройства 100 для обеспечения ввода данных для определения триггерного состояния (например, для определения ориентации и/или перемещения мобильного устройства 100 в трехмерном пространстве). Отметим, что по меньшей мере некоторые из этих компонентов, например процессор 102 и интерфейс 106 пользователя, могут быть физически вынесены из мобильного устройства 100, например могут располагаться в настольном персональном компьютере или в рабочей станции, а любые Правила, которые определены с использованием внешнего интерфейса пользователя, могут быть введены в мобильное устройство 100 для сохранения в памяти 104 через проводное или беспроводное внешнее соединение 110. Отметим, что вышеуказанные сценарии могут также быть введены в мобильное устройство 100 через проводное или беспроводное внешнее соединение 110.

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

На фиг.9 показана упрощенная логическая последовательность операций согласно способу, который может быть реализован процессором 102 под управлением рабочей программы 104А для определения интерфейса пользователя для мобильного терминала или устройства 100. Способ включает выбор по меньшей мере одного триггера и действия, которые совместно осуществляют формирование правила (блок А); автоматическую генерацию каталогизированной структуры доступных событий в соответствии с иерархической информационной моделью (блок В); выбор по меньшей мере одного значения триггера из доступного набора событий (блок С); и определение соответствующего действия, которое будет выполнено мобильным терминалом или устройством 100 (блок D).

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

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

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