Система и способ установки и выполнения прикладных программ предпочтений - RU2364917C2

Чертежи

Показать все 42 чертежа(ей)

Описание

Перекрестная ссылка на родственные заявки

В данной заявке заявлен приоритет заявки на американский патент регистрационный № 10/693,735 под названием SYSTEM AND METHOD FOR PREFERENCE APPLICATION INSTALLATION AND EXECUTION, поданной 24 октября 2003 г., которая приведена здесь полностью в качестве ссылочного материала.

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

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

Уровень техники

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

Основной прорыв в компьютерной технике произошел, когда технология разрушила некоторые барьеры к доступу. В мире мэйнфреймов компьютеры были слишком дорогостоящими для всех, кроме крупных фирм. Появление миникомпьютеров и затем персональных компьютеров (ПК, PC) разрушило барьер стоимости и сделало компьютеры доступными для малого бизнеса и отдельных лиц. В 1980-е годы программисты приложили много усилий, чтобы создать прикладные программы графического интерфейса пользователя (GUI, ГИП). Без разнообразных и последовательных GUI программисты не смогли бы построить полноценные прикладные программы для пользователей ПК. Революция, происшедшая с появлением Visual Basic, а также использование конструкций GUI, основанных на управлении и событиях, позволили разработчикам прикладных программ легко строить разнообразные прикладные программы. Впоследствии был установлен эффективный цикл, благодаря которому значительно большее количество конечных пользователей получили возможность использовать эти прикладные программы. В 1990-е годы конечные пользователи стремились преодолеть отсутствие доступа к информации. Рост Интернет изменил наш мир, делая почти всю ценную информацию доступной для любого человека, имеющего браузер. Однако все еще остаются значительные барьеры, которые нужно преодолеть.

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

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

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

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

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

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

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

КПК …).

Центром информационной прикладной системы является схематизация данных. Схематизация представляет собой структурирование данных в виде хорошо известных и хорошо проработанных структур, которые позволяют множеству прикладных программ распознавать и взаимодействовать друг с другом. Информационные свойства, информационные события и логика принятия решений все они могут быть схематизированы. Схематизированные свойства информации относятся к данным, которые представляют собой основу прикладных программ конечного пользователя (например, электронная почта, люди, группы, местоположения …). Информационные свойства могут быть схематизированы, что позволяет обеспечить последовательную интерпретацию данных для множества различных прикладных программ. Информационные события обеспечивают привязки для присоединения логики программы. Эти события представляют собой события высокого уровня и связаны с информационными потоками, улучшающими их понимание неопытными конечными пользователями. События также могут быть схематизированы. Кроме того, логика принятия решения тоже может быть схематизирована. Поскольку конечные пользователи являются неопытными разработчиками, неразумно ожидать, что программа будет написана на традиционном языке программирования. Скорее для конечных пользователей может быть обеспечено построение схематизированных логических блоков (например, на основе оператора IF-THEN) так, чтобы они могли программировать, сшивая эти блоки вместе в виде простых, но все же разнообразных комбинаций. Схематизация данных, информационные привязки (события) и возможности программирования конечным пользователем обеспечивают конечным пользователям значительную ценность соединенных разнообразной средой прикладных программ, взаимодействующих через логику, установленную конечным пользователем, что впоследствии позволяет конечным пользователям - новичкам стать системными интеграторами.

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

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

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

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

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

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

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

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

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

Краткое описание чертежей

На фиг.1 показана блок-схема системы информационного агента в соответствии с аспектом настоящего изобретения.

На фиг.2 - блок-схема уведомления компонента в соответствии с аспектом настоящего изобретения.

На фиг.3 - блок-схема прикладной программы информационного агента в соответствии с аспектом настоящего изобретения.

На фиг.4 - блок-схема примера логической схемы в соответствии с аспектом настоящего изобретения.

На фиг.5 - блок-схема системы, предназначенная для оценки постоянного средства доступа, в соответствии с аспектом предмета изобретения.

На фиг.6 - блок-схема системы оценки предпочтений в соответствии с аспектом настоящего изобретения.

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

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

На фиг.9 - блок-схема, иллюстрирующая классификацию сообщения, в соответствии с аспектом настоящего изобретения.

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

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

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

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

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

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

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

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

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

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

На фиг.20 - схема, иллюстрирующая программу генерирования текста и классификатор, в соответствии с аспектом настоящего изобретения.

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

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

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

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

На фиг.25 представлена иллюстрация примера интерфейса в соответствии с аспектом настоящего изобретения.

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

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

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

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

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

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

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

На фиг.33 - иллюстрация эволюционной цепи действия/условия в соответствии с аспектом настоящего изобретения.

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

На фиг.35 - блок-схема персонализированной системы в соответствии с аспектом настоящего изобретения.

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

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

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

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

На фиг.40 - схема последовательности выполнения операций способа расширения программных констант среди прикладных программ в соответствии с аспектом настоящего изобретения.

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

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

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

Осуществление изобретения

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

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

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

Платформа информационного агента

Рассмотрим вначале фиг.1, на которой представлена система 100 информационного агента в соответствии с аспектом настоящего изобретения. Система 100 информационного агента содержит интерфейс (интерфейсы) 110 прикладного программирования (API, ИПП), компилятор 120, компонент 130 события, анализатор 140 контекста, накопитель 150 схематизированных данных, механизм 160 выполнения предпочтений, компонент 170 действия и компонент 180 уведомления. Система 100 образует платформу, которая обеспечивает выполнение различных прикладных программ информационного агента. Система 100 может представлять собой автономную систему или часть более крупной системы. Система 100 может, в соответствии с аспектом предмета изобретения, использоваться совместно с компьютерной операционной системой, в которой операционную систему можно использовать на множестве различных вычислительных устройств, включая, без ограничений, персональные компьютеры и мобильные устройства, такие как телефоны, и карманные персональные компьютеры (КПК, PDA). Система 100 также может применяться на серверах (например, на сервере SQL (ЯСЗ, язык структурированных запросов), сервере WinFS) и совместно с услугами, предоставляемыми по подписке. В соответствии с этим систему 100 можно использовать для обеспечения синергетического эффекта использования различных продуктов и услуг, обеспечивающих возможности информационного агента для клиентов, серверов и услуг облака-клиент-сервер (например, Outlook, Exchange и Hotmail).

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

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

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

Система 100 также содержит компонент 130 события. События включают так, чтобы инициировать и представить информацию для оценки предпочтений. События происходят из источников событий, которые могут представлять собой внутренние изменения состояния, например, в отношении прикладной программы или данных и/или внешние изменения в окружающем мире. Компонент 130 события может захватывать события, подаваемые через API из прикладных программ и начинать оценку предпочтения. Например, события могут поступать через провайдера простого протокола пересылки электронной почты (SMTP, ПППП), который принимает новые сообщения SMTP, изменения данных в накопителе 150 данных, действия операционной системы, явные действия пользователя и/или действия других предпочтений. Компонент 130 события может также собирать события или принимать события от провайдеров третьей стороны и из множества различных типов источников, включая, без ограничений, сообщения, такие как Интернет-сообщения и сообщения, передаваемые на основе сети, а также телефонные сообщения и программные услуги, файлы XML (РЯР, расширяемый язык разметки гипертекста), прикладные программы и базы данных. Кроме того, компонент 130 события позволяет отслеживать и собирать данные с использованием различных способов. Примеры способов сбора данных включают, без ограничений, мониторинг директории в отношении добавления файлов, проверку системы и журналов регистрации событий для определенных типов входных данных, организацию ловушек для обнаружения изменений в таблицах базы данных и просмотр данных, предоставляемых сетевой услугой (услугами).

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

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

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

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

Информация, собираемая анализатором 140 контекста, в соответствии с одним аспектом настоящего изобретения включает контекстную информацию, определенную анализатором. Контекстная информация определяется с помощью анализатора 140 путем распознавания местоположения пользователя и его состояния, в частности его внимания, по одному или нескольким источникам контекстной информации (не показаны), как более подробно описано в следующем разделе описания. Анализатор 3122 контекста, например, может обладать возможностью точно определять действительное местоположение пользователя с помощью системы глобальной навигации (GPS, СГН), которая установлена как часть автомобиля или сотового телефона пользователя. Анализатор также может использовать статистическую модель для определения вероятности того, что пользователь находится в данном состоянии внимания, учитывая фоновые оценки и/или наблюдения, собираемые с учетом такой информации, как день (рабочий, выходной или праздник), время суток, дата в календаре пользователя, и наблюдения о действиях пользователя. Данное состояние внимания можно затем использовать как событие или условие для предпочтения, определяемого пользователем.

Механизм 160 выполнения предпочтения также может быть вовлечен в обработку действий. Хотя логика предпочтений в действительности производит только набор результатов, она в качестве альтернативы называется здесь действиями, поскольку оказывает общее влияние на такие результаты. Использование механизма 160 предпочтительного выполнения для выполнения действий представляет собой всего лишь один способ выполнения действий. Действия также могут выполняться с помощью прикладных программ, которые просто считывают результаты предпочтений системы 100 и действуют по ним. При выполнении действий с помощью механизма выполнения как часть системы 100 в большей степени используется активный агент, в то время как при выполнении действий прикладными программами в большей степени используется пассивная логика принятия решения. В соответствии с этим система 100 может обеспечивать услугу хостинга для обработчиков действий прикладных программ, которые могут считывать и выполнять действия аналогично тому, как система 100 предоставляет услугу хостинга для считывания и обработки события в отношении компонента 130 события. Кроме того, следует понимать, что в соответствии с аспектом настоящего изобретения, действия, которые близки к данным (например, перемещение электронной почты в определенную папку), можно выполнять в системе 100, с использованием механизма 160 выполнения, синхронно с оценкой предпочтений, а также как часть этой же транзакции.

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

В соответствии с аспектом выполнения настоящего изобретения исполнительный механизм 160 и система 100 могут одновременно поддерживать легкий и тяжелый агент или прикладные программы предпочтений. Легкие прикладные программы представляют собой программы, для которых требуется низкая задержка, малый объем, занимаемый базой данных, и небольшой рабочий набор. Высокая пропускная способность и масштабирование не являются требованиями первого порядка для легких прикладных программ. Тяжелые прикладные программы представляют собой такие программы, для которых требуется высокая пропускная способность, масштабирование, высокая надежность, строгие гарантии правильности, предсказуемое восстановление после аварийного отказа и возможность простого управления. Низкая задержка и потребление ресурсов не представляют собой основные приоритеты для прикладных программ тяжелого веса. Тяжелые прикладные программы типично выполняют на серверах с высокими рабочими характеристиками, в то время как легкие прикладные программы обычно используют на системах с более низкими рабочими характеристиками, включая, без ограничений, персональные компьютеры и мобильные устройства. В соответствии с этим механизм 160 выполнения должен быть способен различать тяжелые прикладные программы и легкие прикладные программы для соответствующих изменений при выполнении, наиболее соответствующем конкретному типу прикладной программы (например, использование высокой пропускной способности или малого времени задержки). Обычно механизм выполнения больше всего заботится об объеме базы данных, времени задержки при активации компонента, обработке, занимаемом объеме памяти и постоянно работающих процессах. Выполнение тяжелых прикладных программ может потребовать (1) выделения большого объема, занимаемого базой данных, для поддержки, помимо прочего, множества баз данных, таблиц, просмотров, сохраненных процедур и определяемых пользователем функций; (2) малых интервалов опроса для сбора событий, генерирования уведомлений и распределения уведомлений; и (3) пакетной обработки информации. Выполнение легких прикладных программ будет отличаться тем, что они могут (1) использоваться с минимальными объемами памяти и баз данных; (2) могут использовать большие интервалы опроса для сбора событий, генерирования уведомлений и распределения уведомлений (если эта функция включена); и (3) обрабатывать информацию, такую как события, в форме небольших пакетов или индивидуально. Кроме того, в соответствии с аспектом изобретения провайдеры события ведущего узла и определенные распределения уведомления могут не поддерживаться в легких прикладных программах, поскольку для них могут потребоваться непрерывно работающие процессы, которые могли бы отрицательно повлиять на время отклика системы. Однако следует понимать, что исполнительный механизм 160 является гибким, поскольку он позволяет поддерживать изменения с последовательным приращением "легкости" прикладной программы, в зависимости от доступных ресурсов и состояния технологии.

Следует отметить, что система 100 также включает компонент 170 действия. После успешной оценки предпочтений механизм 160 выполнения предпочтений может запускать компонент 170 действия для выполнения определенного действия в соответствии с одним или несколькими действительными предпочтениями. Действия могут влиять на накопитель 150 данных (например, вставлять, удалять или модифицировать данные) и/или другие компоненты и системы в пределах или за пределами системы 100. Один конкретный тип действий представляет собой уведомление пользователя. В соответствии с этим компонент действия иллюстрируется компонентом 180 уведомления.

На фиг.2 более подробно представлен компонент 180 уведомления. Компонент 180 уведомления содержит форматировщик 272 и протоколы 274 доставки. Компонент 180 уведомления принимает необработанные данные уведомления на входе и выводит отформатированные уведомления, которые в конечном итоге поступают в устройство пользователя (например, компьютер, КПК, мобильный телефон …). После приема необработанных уведомлений с компонентом 180 уведомления эти уведомления преобразуют в пригодное для чтения уведомление, которые были отформатированы для соответствия устройству назначения и, возможно, переведены на предпочтительный язык пользователя, и затем передают в устройство через протокол (протоколы) 274 доставки. Форматирование содержания представляет собой задачу, решаемую одним или несколькими компонентами 272 форматирования содержания. Форматировщик (форматировщики) 272 содержания принимают данные уведомления, упакованные в виде массива, в качестве входных данных. Для стандартной доставки массив должен содержать только один элемент, который содержит информацию для одной записи уведомления. Для доставки в виде сборников, когда требуется отправить абоненту множество уведомлений в виде одного сообщения, в массиве может содержаться множество элементов, каждый из которых содержит данные одного уведомления. Форматировщик 272 содержания затем форматирует данные для отображения с использованием информации получателя, включенной в данные уведомления, например, для определения соответствующего форматирования. Кроме того, если используется доставка в виде сборника, форматировщик 272 содержания также отвечает за соответствующее агрегатирование информации уведомления. Внутренне форматировщик 272 содержания может использовать любую соответствующую схему для форматирования уведомления. Например, такая схема может быть простой, и в ней могут использоваться манипуляции основной строки, или она может быть более сложной, например, с использованием преобразований расширяемого языка стилей (XSL, РЯС) или визуализации ASP.NET. Когда форматировщик содержания заканчивает свою работу, на его выход поступает строка, содержащая отформатированные данные. Строку вместе с некоторой информацией заголовка уведомления, которая может быть сгенерирована, передают в компонент 274 протокола доставки.

Доставка уведомления выполняется через протоколы 274 доставки. Когда становится доступным пакет уведомлений, компонент 180 уведомления считывает данные абонента из уведомления (уведомлений) для определения соответствующего форматирования. Компонент 180 уведомления может затем отправить уведомление (уведомления) с использованием протокола 274 доставки в службу доставки, такую как, например, .NET Alerts или сервер SMTP. Более конкретно, при работе прикладной программы компонент 172 уведомления может считывать каждое уведомление для получения устройства и места расположения для доставки абоненту. Дистрибьютор затем сопоставляет комбинацию устройства и местоположения с определенным объектом форматировщика для генерирования конечного уведомления. Само уведомление может содержать комбинацию необработанных данных уведомления, которые были рассчитаны во время форматирования, а также текст, указанный форматировщиком 272 содержания. Эти опции позволяют обеспечить профессиональный и удобный для пользователя текст уведомления, а также включить ссылки на веб-узлы, а также информацию сетевой рекламы.

Хотя система 100 может обрабатывать внутренние уведомления (например, всплывающее уведомление), система 100 не обязательно должна выполнять окончательную доставку уведомлений во внешнее устройство третьей стороны. Вместо этого в системе могут использоваться каналы доставки (не показаны), которые можно рассматривать как магистрали для услуг по доставке, такие как шлюзы электронной почты или серверы .NET Alerts. В частности, канал доставки может состоять из протокола и адреса конечной точки. Система 100 может конфигурировать протокол 274 доставки для получения магистральной линии от компонента 180 уведомления во внешнюю систему доставки, по которой она передает уведомление получателю. Компонент уведомления может затем упаковать уведомления в виде пакета протокола с использованием компонента 274 протокола доставки и передать уведомления в один или несколько каналов доставки. Каналы доставки, в свою очередь, представляют пакеты по внешнюю службу доставки, которая в конце концов может передать уведомление (уведомления) получателю, для которого они предназначены.

Прикладная программа (программы) информационного агента

На фиг.3 представлена прикладная программа 300 информационного агента в соответствии с аспектом предмета изобретения. Прикладная программа 300 представляет собой блок, размещенный в системе 100, и содержит логическую схему 310, интерфейс 320 пользователя, компонент 330 логики принятия решения, компонент 340 программирования события и компонент 350 планирования задачи. Логическая схема 310 образует схематизированные блоки логического построения или шаблоны, которые конечный пользователь может свести вместе. Разработчик схемы отвечает за построение логической схемы 310, а также за принятое по умолчанию поведение и поведение в случае исключения. Фактически логическая схема 310 ограничивает действительную силу выражения логических устройств конечного пользователя, обеспечивая, таким образом, практическую возможность и осуществимость для конечных неопытных пользователей действительно "запрограммировать" прикладную программу. Блоки логического построения могут включать класс предпочтений, набор определений класса условий и набор потенциальных результатов или действий. Условия и действия могут быть сопоставлены с функциями соответствующей прикладной программы 300 и/или контекстом пользователя. Кроме того, следует понимать, что в соответствии с аспектом предмета изобретения логическая схема 310 может быть определена с использованием XML (расширяемого языка разметки гипертекста).

В соответствии с аспектом изобретения, существуют два вида компоновочных блоков, для которых логика 310 схемы может определять: класс условия, определяющий шаблонную булеву функцию, и класс действия, определяющий шаблонную процедуру. Класс предпочтений представляет собой модуль развития схемы информационного агента. Предпочтение включает набор разрешенных классов условия (например, IsFrom(X) (от (Х)), IsTo(Y) (кому: (Y)) и классы действия (например, MoveToFolder(Z) (переместить в папку (Z)), Delete() (удалить()). Кроме того, каждое предпочтение ассоциировано с конкретным классом событий или триггером для инициирования действия (например, с событием EmailEvent (событие электронной почты)). После определения логики 310 схемы схема 310 может быть скомпилирована с использованием компилятора 120 и может быть сохранена в нормализованных метатаблицах системы в накопителе 150 данных. Кроме того, сохраненные процедуры могут быть созданы во время периода компиляции, которая позволяет выполнить оценку предпочтений. Как логика 310 схемы, так и процедуры могут быть сохранены в схематизированном накопителе 150 данных для последующего доступа и выполнения. После этого, когда пользователь пытается указать предпочтение, его можно сравнивать со схемой 122 логики для проверки соответствия его формата и затем сохранять в накопителе 150 данных, например в одной или нескольких таблицах предпочтений. Когда соответствующее событие происходит, система 100 может затем обеспечить выполнение оценки соответствующих предпочтений путем выполнения сохраненных процедур, созданных во время компиляции. В соответствии с аспектом предмета изобретения сохраненные процедуры позволяют эффективно оценивать множество предпочтений с ориентировкой на набор, с использованием таких технологий, как индексация и устранение дубликатов (описаны ниже).

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

Прикладная программа (программы) 300 также содержит три компонента, которые могут использоваться конечными пользователями, для получения предпочтений или программ с различными функциями: компонент 330 логики принятия решения, компонент 340 программирования события и компонент 430 планирования задачи. Компонент 330 логики принятия решения позволяет конечным пользователям определять логику решения (также известную как логика конечного пользователя). Прикладная программа может затем разрешить определенной логике конечного пользователя управлять различными решениями. Например, конечные пользователи могут указать, если, когда и как предупреждения могут всплывать на экране и отвлекать пользователя. Прикладная программа также может показывать события, к которым конечные пользователи могут прикреплять логику решения. Например, прикладная программа электронной почты может выводить на передний план событие всегда, когда в папку поступает новая электронная почта. Компонент 340 программирования события позволяет конечным пользователям прикреплять предпочтения или правила, которые определяют поведение, которое может происходить в зависимости от содержания сообщения и, например, контекста пользователя. Условия в правилах позволяют осуществлять доступ к данным из других прикладных программ (например, активной директории, для проверки, состоит ли отправитель в той же рабочей группе), и эти действия могут, в соответствии с одним аспектом предмета изобретения, влиять на другие прикладные программы 450 или выводить на передний план другое событие. Компонент 430 планирования задачи позволяет конечным пользователям прикреплять специальные или заданные задачи к появлению события. Например, когда появляется жалоба нового клиента, конечный пользователь может выбрать начало заданного рабочего потока для разрешения жалобы.

Компонент 330 логики решения позволяет конечному пользователю написать логику решения или логические программы конечного пользователя, комбинируя шаблоны условия и вывода, предоставленные разработчиком. Логика решения может быть определена с использованием предпочтений или правил "IF (условие) THEN (результат)". Логика такого типа особенно соответствует спецификации конечного пользователя, поскольку даже конечные пользователи, абсолютно не имеющие опыта программирования вообще, могут легко понимать и создавать такие правила. Рассмотрим, например, следующую строку: IF (TheDogBarks) OR (TheBeeStings) THEN (IFeelSad) (Если (собака лает) или (пчела жалит) тогда (я грустный)). Это правило выполнено так, что не разработчик и даже ребенок может понять и ясно сформулировать его при наличии соответствующего интерфейса пользователя. Такое логическое программирование типа IF-THEN соответствует спецификации конечного пользователя, по меньшей мере, потому, что оно соответствует представлениям человека об умозаключениях и вербальном общении. Семантика одиночного правила является декларативной и хорошо понятной, а именно результаты являются действительными, если и только если условия являются истинными. Кроме того, конечные пользователи могут интуитивно применять логику предпочтения в активном контексте. В результате будут получены действия, которые требуется предпринять, вместо простого указания трюизмов. Например, IF (TheDogBarks OR TheBeeStings) THEN (ThinkAboutRainDropsOnRoses) (Если (собака лает) или (пчела жалит) тогда (подумай о каплях дождя на розах)). Даже при использовании одиночного правила IF-THEN могут быть разрешены различные степени полноты в силе выражения. Предыдущий приведенный выше пример приблизительно соответствует логике высказываний. Логика высказываний основана на понятии, что простые суждения типа истина/ложь могут быть скомбинированы для получения логических высказываний. Однако более полные логические формы, указание которых может оказаться слишком сложным для конечных пользователей среднего уровня, включая без ограничений предикативную логику, логику ограничений целостности и рекурсии, также можно использовать в связи с предметом изобретения.

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

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

Компонент 340 программирования по событию обеспечивает, по меньшей мере, три функции для прикладной программы 300 информационного агента. Во-первых, компонент 420 программирования события может обеспечить набор событий схематизированной информации (например, определенных разработчиком схемы), которые могут действовать как зацепки для программ конечного пользователя. Каждое событие может переносить структурированные данные с их помощью. Существует множество механизмов для захвата отдельного случая события (например, API для передачи события). Существуют также несколько подклассов информационных событий. Один подкласс событий соответствует изменению данных в накопителе 150 схематизированных данных. В соответствии с этим компонент 340 программирования события может представлять механизмы для доступа к изменению данных в накопителе 420 и может сделать их доступными как события схематизированных изменений. Другой подкласс событий может соответствовать периодическому повторению временных событий, которые могут быть важными для действия запланированного предпочтения. Компонент 340 программирования события может также предоставлять возможность ассоциировать логику "обработки" конечного пользователя с появлением определенных событий. Кроме того, компонент 340 программирования события может обеспечить услуги по захвату событий, применению соответствующей логики решения и вызова обработчиков действия для выполнения результатов решения.

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

Компонент 350 планирования задачи управляет планами или рабочими потоками задачи конечного пользователя. Используемый здесь термин план представляет собой согласованный набор задач с определенной последовательностью их выполнения. Цель полного выполнения задач обычно состоит в решении некоторой проблемы из реального мира, например планирования встречи с четырьмя людьми. В примере организации встречи задачи в плане могут включать, помимо прочего, посылку исходного запроса на встречу и обработку положительных и отрицательных ответов. Хотя рабочие потоки часто используются в процессе автоматизации бизнеса, схемы задачи или рабочие потоки, описанные в соответствии с настоящим изобретением, ассоциируются с действиями конечного пользователя (например, планирование встреч, поиск документов, делегирование запросов …). Хотя многие из этих рабочих потоков являются простыми процессами, они могут быть настраиваемыми и прозрачными для конечного пользователя.

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

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

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

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

Активные вызовы логики конечного пользователя через компонент 330 логики решения можно использовать в множестве ситуаций. Например, активную логику можно использовать для организованных данных, таких как категоризированные изображения, по мере их загрузки из камеры или электронной почты, при приеме ее в соответствии с организационными правилами. Активную логику также можно использовать для реакции на изменения, например, когда поступает новая электронная почта и получатель не находится за своим столом, почту передают в его/ее мобильный телефон. Активную логику также можно использовать для улучшения связи, например, в виде ответа по телефону пользователя, когда пользователь не доступен, или, например, ответа с указанием, когда в следующий раз пользователь сможет ответить на вызов. Кроме того, активную логику можно использовать для подписки на публикуемую информацию, при этом пользователю, например, может быть отправлено уведомление в случае, когда плохая погода ожидается в месте назначения его поездки. Также активную логику можно использовать для поддержания контекста. Например, когда пользователь приходит на различные встречи, проходящие в различных местах, и уходит с них, контекст может соответствующим образом обновляться (например, удаленный или местный, занятый или свободный …).

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

Логическая схема

На фиг.4 показан пример логической схемы 400 в соответствии с аспектом настоящего изобретения. Логическая схема 400 содержит класс 410 условия, класс 415 действия, класс 420 события, класс 425 предпочтения, связи 430, хроники 435, разрешение 445 конфликта, упорядочивание 450 явного выполнения, требуемые условия и действия 455, шаблоны 460 и запланированные и повторные предпочтения 465. Пример логической схемы 400 и указанные компоненты схемы представлены для упрощения пояснения. Поэтому следует понимать, что логическая схема 400 может содержать все указанные компоненты, их поднабор и/или дополнительные компоненты схемы, которые здесь не описаны. Как было описано раньше, разработчик схемы определяет компоновочные блоки схематизированной логики, которые могут быть соединены вместе конечным пользователем. Компоновочные блоки двух типов представляют классы 410 условия и классы 415 действия. Классы 410 условия могут определять шаблонные булевы функции, в то время как классы 415 действия могут определять шаблонные процедуры. Класс 425 предпочтения представляет собой блок разработки схемы информационного агента. Класс 425 предпочтения может включать, помимо прочего, набор классов разрешенного условия и классов действия, связи 430, разрешение 445 конфликта и требуемые условия 455. Кроме того, каждый класс 425 предпочтения может быть ассоциирован с определенным классом 420 событий, который определяет включение событий для предпочтения. Ниже приведен пример класса предпочтений для прикладной программы электронной почты информационного агента:

InboxPreferenceClass (класс предпочтений входящего почтового ящика)

ConditionClasses (классы условия)

IsFrom (X) (от: (Х))

IsTo (Y) (кому: (Y))

ActionClasses (классы действия)

MoveToFolder (Z) (переместить в папку (Z))

Delete () (удалить ())

TriggeringEventClass (класс инициирующего события)

EmailEventClass (класс события электронной почты)

Source of triggering event (источник инициирующего события)

Changes of triggering event (изменения инициирующего события)

ApplyNow () (применить немедленно)

ScheduledEvent () (запланированное событие)

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

UserPreference:

Instance of InBoxPreferenceClass - (экземпляр класса предпочтения входящего ящика электронной почты)

IF (IsFrom (John) OR IsTo ('bookclub") THEN MovetoFolder ('Book Club') - (ЕСЛИ (от (Джона) ИЛИ для ('книжного клуба') ТОГДА переместить в папку ('книжный клуб').

Конечные пользователи затем могут "программировать" для определения обработчиков событий. Каждый обработчик события определен набором предпочтений того же самого класса предпочтений и поэтому иницируется тем же событием. Например:

IF (IsFrom (John) OR IsTo ('bookclub') THEN MovetoFolder ('Book Club') - ЕСЛИ (от (Джона) ИЛИ для ('книжного клуба') ТОГДА переместить в папку ('книжный клуб')

IF (IsTo ('SillyStuffDL')THEN Delete() - ЕСЛИ (для 'глупой чепухи DL') ТОГДА удалить ())

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

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

Данные присутствия: IF (IsFrom ('John') AND SenderIsOnline ()) THEN … - (ЕСЛИ (от: ('Джона' И отправитель на линии ()) ТОГДА …)

Данные местоположения: IF (IAmFarMeetingLocation ()) THEN ReminderMinutesWindow (30) - (ЕСЛИ (я в удаленном месте встречи ()) ТОГДА окно напоминания в минутах (30)

Организационная иерархия: IF (IsFromMyManagement ()) THEN MarkAsHighPriority () - (ЕСЛИ (из моего руководства ()) ТОГДА отметить как высокий приоритет ().

Все приведенные выше примеры имеют дело с контекстом пользователя. Контекст пользователя может быть определен анализатором 140 контекста (фиг.1) и записан в накопитель 150 данных (фиг.1) для использования прикладными программами информационного агента. Таким образом, функция такого типа, как "BoolIsOnline(X)" (булев оператор на линии (Х)) может возвращать значения истина или ложь на основе идентификации человека X, которому он передан, и с учетом его/ее текущего контекста, определенного анализатором контекста.

Продолжая с приведенным выше примером, разработчик схемы класса предпочтений, такого как InBoxPreferenceClass - (класс предпочтений входящего ящика электронной почты) должен обеспечить класс 410 условия для использования конечным пользователем. Существует несколько способов, с помощью которых это может быть выполнено. Например, класс условия может быть IsOnline() (находится на линии). В этом случае конечный пользователь может определить предпочтение в форме "IF (IsOnline (Email. Sender)) THEN …" - (ЕСЛИ (находящийся на линии (отправитель электронной почты)) ТОГДА). В качестве альтернативы, класс условия может представлять собой SenderIsOnline () - (отправитель находится на линии()) и его декларацию, которую разработчик схемы может связать с IsOnline (X), - (находиться на линии(Х)) и связать X с Email.Sender - (отправитель электронной почты). В соответствии с этим конечный пользователь может определить предпочтение или правило как: "IF (SenderIsOnline ()) THEN …" - ("ЕСЛИ (отправитель находится на линии()) ТОГДА …") Хотя настоящее изобретение поддерживает множество форм определения классов 410 условия, следует отметить, что существует существенное различие в описанной выше форме. Первая форма представляет собой традиционное правило вычисления на основе фактов, где лицо, утверждающее правило (то есть конечный пользователь), устанавливает доводы в отношении схем и различных связей. Вторая форма является менее гибкой, но определенно более простой для использования конечным пользователем. В соответствии с этой формой класс 410 условия представляет собой область, где разработчики схемы могут ограничить силу выражения логики конечного пользователя и, таким образом, сделать "программирование" прикладных программ информационного агента более практичным и удобным для наивных конечных пользователей.

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

Как указано в данном описании и в соответствии с аспектом предмета изобретения, не предполагается, что конечные пользователи будут опытными программистами. В соответствии с этим создают предпочтения на основе условий с интуитивно понятными названиями (например, EmailIsFrom ()) - (электронная почта от()), и аргументы для этих условий могут представлять собой простые константы, определенные пользователем (например, Mary (Мэри)). Это позволяет конечному пользователю написать предпочтение, которое инициируется по условию EmailIsFrom (Mary) - (электронная почта от (Мэри)). Однако аргументы, основанные исключительно на строчных константах, установленных пользователем, являются слишком ограничительными. В соответствии с этим ограничения 430 могут быть указаны в логической схеме 400 как часть класса 425 предпочтений как для облегчения программирования для конечных пользователей, так и для расширения области, из которой может быть получена информация. В схеме 400 могут быть указаны, по меньшей мере, три типа ограничений параметра. Во-первых, могут быть указаны ограничения константы, которые предопределяют константу. Указание ограничения константы является полезным, по меньшей мере, потому, что оно освобождает конечного пользователя от необходимости выбора или указания константы. Выражения, связанные с событиями, также могут быть связаны со значениями, приведенными в качестве аргументов для условий и действий. Более конкретно, может быть определено выражение, в котором используются поля событий и константы для расчета значения. Например:

Класс условия: SenderIsOnline () - (отправитель на линии ())

Функция определения: IsOnline (X) - (на линии (Х))

Ограничение: X → Email.Sender - (Х → отправитель электронной почты).

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

Принадлежности констант представляют собой очень мощные константы, которые позволяют записывать предпочтения и условия, позволяющие обеспечить навигацию и поиск информации из различных областей. Эти константы представляют собой просто имена, наложенные поверх функций, которые работают по поиску и материализации правильной информации, а именно членов группы, ассоциированных с названием константы. Рассмотрим вкратце фиг.5, на которой представлена система 500 для получения значения константы в соответствии с аспектом настоящего изобретения. Система 500 содержит компонент 510 входной принадлежности, компонент 520 связи и множество доменов 530, 540 и 550 (DOMAIN₁ - DOMAIN_N, где N больше единицы). Компонент 610 ввода принадлежности принимает в качестве входной информации константу, такую как MyFamily (моя семья), MyCoworkers (мои сотрудники) или MyFriends (мои друзья), и передает эту константу в компонент 520 принадлежности. Компонент 520 принадлежности выполняет поиск по всем доступным доменам 520, 530 и 540 в попытке разрешения или обеспечения связи со значением (значениями), ассоциированным с членами группы, указанной входной константой. В соответствии с одним аспектом предмета изобретения домены 530, 540 и 550 могут представлять собой прикладные программы, сохраненные в схематизированном накопителе данных. Например, домен 520 может представлять собой прикладную программу электронной почты, домен 530 может представлять собой прикладную программу календарь, и домен 540 может представлять собой прикладную программу счета клиента. В соответствии с этим компонент 520 принадлежности может обеспечивать доступ к прикладной программе электронной почты или к локализованному регистру данных в попытке определить значение константы (например, MyFamily (моя семья)). Если компонент 520 не может разрешить значение в этой области или в локализованном регистре данных, он может продолжить проверку дополнительных доступных областей до тех пор, пока не определит значение константы или не проверит все доступные области. В одном случае компонент принадлежности может находить данные в прикладной программе электронной почты, например, такие:

- (моя семья)

Bob Jones - (отец, Боб Джонс)

Barb Jones - (мать, Барб Джонс)

- (братья)

Michael Jones - (брат 1, Майкл Джонс)

Jason Jones - (брат 2, Джейсон Джонс)

Следует отметить, что XML представление членов группы, ассоциированной с константой MyFamily, используется только для целей иллюстрации. Наполнение группы может быть определено и/или материализовано в соответствии с изобретением различными путями. В соответствии с этим компонент 520 принадлежности может разрешать или связывать MyFamily с Bob Jones, Barb Jones, Michael Jones и Jason Jones на основе данных, полученных из прикладной программы электронной почты. Компонент 540 принадлежности, однако, мог бы продолжать проверку в других областях для обеспечения полноты и точности данных. Например, он мог бы найти Jennifer Jones (моя сестра Дженифер Джонс) в прикладной программе календаря и добавить это значение к строке значений, относящихся к константе MyFamily.

Описанные выше константы (например, MyFamily, MyCoworkers, MyFriends, MyFavorite Musicians (мои любимые музыканты)) известны как константы первого порядка, поскольку они определены по отношению к данному пользователю. Компонент 510 принадлежности или принадлежность может затем отключить идентификационные данные пользователя или другие исходные точки. Следует также отметить, что константы N-го порядка могут также быть составлены и сохранены пользователем с использованием предпочтений для комбинирования ранее определенных групп (например, поименованных по константам). В качестве иллюстрации рассмотрим комбинацию групп, названных константами, которые обеспечивают функции, аналогичные семантическим или предложным фразам. Например, пользователь может составить и сохранить константы, представляющие такие группы, как FriendsOfMyFamily (друзья моей семьи) или EmailsFromPreferredCustomersInAppointmentsToday (электронная почта от предпочтительных клиентов, с которыми назначена встреча сегодня). C другой перспективы расширения константы аналогичны условиям в полях элементов, которые также могут быть представлены как принадлежности констант и скомбинированы с другими константами.

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

Кроме того, следует отметить, что также могут быть указаны группы предпочтений. Логика решения, определенная конечными пользователями, представлена одним или несколькими наборами предпочтений. В соответствии с этим группы предпочтений могут быть определены как контейнер для групп ассоциированных предпочтений. Предпочтения в группе предпочтений могут затем (1) принадлежать тому же классу предпочтений, (2) их можно оценивать вместе, причем по результату следует выполнять разрешение конфликтов. Кроме того, предпочтения в группах предпочтений могут быть совместно разрешены или не разрешены. Коллективное разрешение или запрет предпочтений можно использовать в множестве сценариев. Например, конечный пользователь может иметь один набор предпочтений во время работы и другой набор предпочтений дома. Таким образом, группы предпочтений могут быть разрешены или запрещены на основе контекста пользователя.

Логическая схема 400 также может включать протоколы 435. Многие прикладные программы информационного агента должны поддерживать состояние для того, чтобы принимать осмысленные решения. В качестве простого примера рассмотрим прикладную программу - информационный агент публикации новостей. Конечные пользователи подписываются на новостные статьи, представляющие интерес. Поступление событий обеспечивает постоянный поток новостных статей. Одна из проблем состоит в том, что одна и та же статья может поступать много раз с несколько модифицированным содержанием, но с одинаковым названием. В этом контексте осмысленное условие может представлять собой: IsNewArticle () - (если новая статья). Это условие может проверять, что данное название не появлялось раньше. Другой пример может состоять в проверке, появляется ли в постоянном потоке обновлений статья с новой историей. Для обеспечения функции такого типа необходимо поддерживать состояние по мере обработки события. Это состояние называется здесь хроникой, поскольку оно является представлением истории прикладных программ.

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

Разработчики могут определять процедуры разрешения конфликта или логики в компоненте 545 разрешения конфликта как часть класса 425 предпочтений в логической схеме 400. Когда происходит событие, может возникнуть множество действий, если множество предпочтений соответствуют событию. Таким образом, необходимы система и способ определения порядка выполнения и/или предпринятого конечного действия. Существуют, по меньшей мере, три способа работы с инициированием множества действий. Во-первых, схема 500 может обеспечить возможность для конечных пользователей определить действие или приоритеты предпочтения. Например, конечные пользователи могут назначать приоритеты каждому предпочтению. Кроме того, конечные пользователи могут назначать индикатор (например, флаг) остановки обработки для определенных предпочтений. В соответствии с этим, когда события связаны с инициированием множества действий, эти действия могут выполняться в порядке приоритета. Кроме того, и в качестве альтернативы, если множество предпочтений соответствуют в пределах группы предпочтений предпочтению с наивысшим приоритетом, может выполняться это предпочтение, в то время как от других отказываются. Кроме того, схема 400 может позволить конечным пользователям указать процедуры разрешения конфликта, например разрешить им прикреплять индикатор обработки остановки к определенным предпочтениям для обработки ситуации, в которой предпочтение, содержащее индикатор, включают одновременно с другими предпочтениями. Другой подход, с помощью которого могут быть разрешены конфликты, состоит в определении приоритетов класса действия в пределах схемы 400. В соответствии с этим, разработчик схемы может определять приоритеты класса действия. Например, классу действия MoveToFolder - (перейти к папке) может быть назначен более высокий приоритет, чем классу действия Delete - (удалить). Другой сценарий конфликта может возникать, когда одновременно включают множество действий из одного класса действий. Разработчики схемы могут определять множество логик разрешения конфликтов для работы в ситуации такого типа. Например, предположим, что существует класс действия, который устанавливает объем требуемой всплывающей информации (например, SetVolume ()) (установить объем). Также предположим, что событие включает два действия, SetVolume (50) и SetVolume (70). В этом случае логика конфликта, определенная в компоненте 545 разрешения конфликтов, может быть определена так, что предпринимаемое действие будет соответствовать минимуму, максимуму или среднему значению этих двух уровней.

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

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

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

Схема 400 также может быть определена таким образом, что она будет работать с запланированными и повторными предпочтениями через компонент 465 запланированного и повторного предпочтения. Для множества прикладных программ информационного агента может быть желательно использовать предпочтения, которые оценивают по повторному плану. Один из множества примеров может включать предпочтение, которое передает состояние обобщения в 17:00 каждый рабочий день. В соответствии с одним аспектом изобретения запланированная и повторная функции могут быть выполнены в схеме 400 с использованием двух абстракций. Во-первых, класс событий, определенный системой (например, TimerEvent (событие по таймеру)), можно использовать для привязки события к запланированному действию. Этот класс события может быть сконфигурирован для различных однородных степеней структурирования. Кроме того, данные, связанные с событием, могут включать текущее время и время предыдущего включения. Во-вторых, каждое запланированное предпочтение может включать такое условие, как:

RecurrenceInWindow (RecurrenceSchedule, StartTime, EndTime) - (повторение в окне, план повторения, время начала, время окончания), где

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

StartTime привязана разработчиком к предыдущему времени события таймера; и

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

В общем, логическая схема 400 может содержать множество различных компонентов или секций для обеспечения компоновочных блоков логики, для выражения предпочтений конечного пользователя. Схема может принимать любую форму, например форму файла XML. После того как схема будет закончена, она может быть скомпилирована в виде представления в базе данных и сохранена, например, в накопителе 150 данных (фиг.1). Следует понимать, что файл схемы может быть непосредственно отредактирован или построен с использованием таких прикладных программ, как Visual Studio. В соответствии с этим компилятор системы также должен обеспечивать обработку файлов схемы поддержки, сформированных с использованием множества прикладных программ схемы редактирования.

Выполнение прикладной программы

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

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

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

По изменениям данных, например, включаются события для логики IA, когда данные изменяются в накопителе 150 данных.

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

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

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

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

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

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

На фиг.6 представлена система 600 оценки предпочтений в соответствии с аспектом предмета изобретения. Система 600 содержит накопитель 150 данных, множество таблиц 610, механизм 160 выполнения предпочтений и таблицу 630 результатов. Накопитель 150 данных содержит множество таблиц 610, которые сформированы системой 100 из схемы разработчика, а также предпочтений конечного пользователя. В результате возникновения события механизм выполнения предпочтений принимает или считывает предпочтения, например, из таблицы, сохраненной в накопителе 150 данных. Механизм 160 выполнения затем использует предпочтения, а также некоторые сохраненные процедуры (которые также могут быть сохранены как данные) для обращения с запросом к таблице 610 и получения таблицы 630 результатов. В таблице 630 результатов могут быть сохранены предпочтения, условия которых были удовлетворены так, что на их основе можно начинать указанные действия.

Количество и сложность таблиц 610 могут изменяться в зависимости от сложности схемы, написанной разработчиком, для поддержки предпочтений конечного пользователя. Здесь представлен пример для пояснения того, как система 600 использует таблицы базы данных и подает запросы на обработку предпочтений. В этом примере фигурируют два человека Джек и Джилл, которые хотят использовать несколько групп предпочтений. Как было описано выше, прежде чем Джек и Джилл смогут указывать предпочтения конечного пользователя, должна быть сформирована схема. Схема содержит несколько частей, как описано выше, однако для упрощения понимания здесь будет описана очень простая схема. Одна из основных частей схемы представляет собой определение классов событий. В этом примере рассматриваются два класса событий, EmailEvents и Stockevents (события электронной почты и события на бирже). В приложенном к настоящему описанию Приложении представлен псевдокод, изображающий определение схемы для этих двух классов событий, а также трех классов предпочтения. Два класса предпочтения основаны на EmailEvents, в то время как третий класс основан на StockEvents. Информационная система 100 может затем использовать эту схему для формирования таблицы класса предпочтений и класса условия, которая может быть сохранена в накопителе 150 данных. Например:

Джек и Джилл могут затем определить свои предпочтения. Для целей этого примера предположим, что Джек определяет три группы предпочтений PG(Jack, 1), PG(Jack, 2), и PG(Jack, 3). Кроме того, Джек определяет пять предпочтений, распределенных среди групп следующим образом:

PG (Jack, 1)

P1 : On EmailEvents if MailIsFrom (Mary) AND MailContains ("California") - (по событиям электронной почты, если почта от (Мэри) И почта содержит ("Калифорния")

then PopAToast

P2 : On EmailEvents if MailIsFrom (Bob) OR MailContains ("Info Agent") - (по событиям электронной почты, если почта от (Боба) ИЛИ почта содержит ("Информационный агент")

then PopAToast

P3 : On EmailEvents if MailIsFrom (Home) OR MaillsFrom (MyWife) OR MaillsFrom (MySon) - (по событиям электронной почты, если почта из (Дома) ИЛИ почта содержит (Моя жена) ИЛИ почта от (Моего сына)

then PopAToast

PG (Jack, 2)

P3 : On EmailEvents if MailIsFrom (Home) OR MaillsFrom (MyWife) OR MaillsFrom (MySon) - (по событиям электронной почты, если почта из (Дома) ИЛИ почта содержит (Моя жена) ИЛИ почта от (Моего сына)

then PopAToast

PG (Jack. 3)

P4 : On EmailEvents if MailIsFrom (Home) AND MailPriority (10) - (по событиям электронной почты, если почта из (Дома) И приоритет почты (10)

then MoveToFolder ("URGENT") - (тогда перейти к папке ("СРОЧНО")

P5 : On EmailEvents if MailPriority (15) (по событиям электронной почты, если приоритет почты (15)

then MoveToFolder ("VERY URGENT") - (тогда перейти к папке ("ОЧЕНЬ СРОЧНО")

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

PG (Jill, 1)

P6 : On EmailEvents if MailIsFrom (Home) OR MailContains ("Vacation") - (по событиям электронной почты, если почта из (Дома) ИЛИ почта содержит ("Отпуск")

then PopAToast

P7 : On EmailEvents if MailIsFrom (Bob) AND IMailContains ("Work") - (по событиям электронной почты, если почта от (Боба) И почта содержит ("Работа")

then PopAToast

P8 : On EmailEvents if MailContains ("Bonus") - (по событиям электронной почты, если почта содержит ("Премия")

then PopAToast

PG (Jill. 2)

P9 : On StockEvents if StockSymbol = ('EBAY') AND TargetPrice > 120 - (по событиям на бирже, если биржевой символ = ('EBAY')И целевая цена > 120)

then SendCellPhoneMessage ('Me') - (тогда передать сообщение на сотовый телефон ('Мне'))

P10 : On StockEvents if StockSymbol = ('AMZN') AND TargetPrice > 50 - (по событиям на бирже, если биржевой символ = ('AMZN') И целевая цена > 50)

then SendCellPhoneMessage ('Me') - (тогда передать сообщение на сотовый телефон ('Мне'))

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

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

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

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

Следует также отметить, что в приведенной выше таблице предпочтений всего существует 14 Групп И.

Кроме того, выше представлено в сумме 19 условий. Информация об этих Группах И и условиях может быть сведена в дополнительных таблицах в следующем виде:

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

Следует отметить, что значение ConditionCount равно 1, а не 2, как следовало ожидать. Для учета наличия NOT (НЕТ) при оценке запроса, подсчет условия определен, как сумма только тех условий в группе И, перед которыми не указано НЕТ (!). Условия, перед которыми указано НЕТ, можно свести в отдельную таблицу, которая показана ниже.

ANDGroups (группы И) могут быть дополнительно определены в таблице условий ANDGroupMembership (членство групп И), как представлено в следующей объединенной таблице:

Как отмечено выше, условия с НЕТ можно рассматривать как специальный случай и свести в их собственную таблицу в следующем виде:

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

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

Как отмечено выше, один из аспектов настоящего изобретения состоит в создании декларативной системы программирования, которая позволяет представить модель по одному для разработчиков функций условия, но которая, в конце концов, обрабатывает запросы класса условий, которые выполняются в виде набора, что обеспечивает преимущества эффективного запроса в базе данных. В соответствии с этим декларации класса условия по одному могут быть преобразованы в запросы. Например, в EmailEvents (события электронной почты) предпочтение конечного пользователя может выполнять действия, зависящие от отправителя электронной почты (например, Jack′s P1). Таким образом, конечный пользователь через интерфейс пользователя может написать MaillsFrom (Mary) (электронная почта от (Мэри)). Однако при выполнении предпочтений система 700 будет выполнять запросы в базе данных, представляющие оператор условия пользователя. Например, система может выполнять следующий оператор запроса SQL вместо декларации пользователя, где CV.ParamValuel = 'Mary':

SELECT 1

FROM EmailEvents E, ConditionValues CV

WHERE E.Sender = CV.ParamValuel

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

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

create proc NSStoreResultsIntoResultsTable

@conditionClassId int

AS

declare @query varchar (255) --this number could be much lager (это число может быть намного больше)

select @query=Query_Text

from ConditionClasses

where conditionClassId = @conditionClassId

insert ConditionResults exec (@query)

return (0)

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

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

select distinct (eventld, prefld)

from ConditionResults C, AndGroupMemberShip A

where C.condld = A.condld

group by C.eventld, C.prefld, A.AndGroupId

having sum (C.Bool) = (select ConditionCount

from AndGroups A2

where C.Prefid = A2.Prefld

and A.AndGroupId = A2.AndGroupId)

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

Пример 1:

Предположим, что Таблица ConditionResults содержит следующие два ряда.

Между этими двумя предпочтениями в условии 1 присутствует И. Следовательно, это предпочтение будет оценено, как истинное, только если оба приведенные выше условия являются истинными. Оба эти условия принадлежат к 1-й ANDGroup (группе И), подсчет условия которой равен 2. Поэтому, когда приведенную выше таблицу соединяют с таблицей AndGroupMembership, получают следующую результирующую таблицу:

сумма = 2

После перемножения групп получаем следующую строку

Теперь (Pref. Id, ANDGroupId) формируют ключ для Таблицы ANDGroups.

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

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

Пример 2:

Предположим, что Таблица ConditionResults содержит следующие две строки:

Между этими двумя условиями в Предпочтении 2 находится ИЛИ. Таким образом, это предпочтение будет оценено как истинное, только если любое из двух условий является истинным. Эти условия принадлежат ко 2-й и 3-й ANDGroups соответственно, и подсчет условий для обеих этих групп равен 1. Поэтому, когда приведенную выше таблицу соединяют с таблицей AndGroupMembership, получают следующую результирующую таблицу:

После группировки приведенной выше таблицы получим

Оба приведенные выше ряда удовлетворяют условию обладания и, следовательно, после их отдельного использования мы получим, что предпочтение (Pref. Id = 2, Event Id = 101) будет скопировано в таблицу 703 результатов.

Пример 3:

Для этого последнего примера предположим, что Таблица ConditionResults имеет следующие две строки:

Вспомним, что условие предпочтения 7 в действительности представляло собой

From (Bob) and! Contains (Work).

В присутствии NOT 1 во втором ряду выше изменяется на -1 в соответствии с аспектом настоящего изобретения. Ниже приведен пример запроса, который обеспечивает такую функцию:

update ConditionResults

set Bool = -1

where cond. Id IN (select cond Id from Not)

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

сумма = 0

Оба этих условия принадлежат к 11-й ANDGroup. Из таблицы ANDGroup можно определить, что подсчет условия этого предпочтения (предпочтения, ANDGroup) равен 1. Поскольку 0 ≠ 1, по запросу оценки предпочтения не будет получена ни одна из строк. Следует, однако, отметить, что если бы вторая строка не содержалась в таблице ConditionResults, то была бы получена сумма, равная 1 (= 1), и предпочтение 7 было бы оценено как истинное.

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

Действия приоритета и контекстный Анализ

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

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

На фиг.7 показана система 700, иллюстрирующая систему 712 приоритетов и архитектуру действия уведомления в соответствии с аспектом настоящего изобретения. Система 712 приоритетов принимает одно или несколько сообщений или уведомлений 714, генерирует приоритет или меру важности (например, величину вероятности того, что сообщение имеет высокую или низкую важность) для ассоциированного сообщения, и передает одно или несколько сообщений с ассоциированной величиной приоритета на выход 716. Как более подробно описано ниже, классификаторы могут быть построены и обучены для автоматического назначения меры приоритетов сообщениям 714. Например, выход 716 может быть отформатирован так, что сообщениям назначают вероятность в соответствии с принадлежностью сообщения к высокой, средней, низкой или другой категории важности. Сообщения могут быть автоматически отсортированы в почтовом ящике программы электронной почты (не показана), например, в соответствии с определенной категорией важности. Сортировка также может включать направление файлов в системные папки, имеющие определенные метки важности. При этом можно использовать папки, помеченные такими степенями важности, как низкая, средняя и высокая, при этом сообщения определенной конкретной важности сортируют в соответствующую папку. Аналогично, один или несколько звуков или визуальных представлений (например, пиктограмм, символов) можно использовать для предупреждения пользователя о том, что было принято сообщение, имеющее требуемый приоритет (например, три звуковых сигнала для сообщения с высоким приоритетом, два звуковых сигнала для среднего, один звуковой сигнал для низкого приоритета, красный или мигающий символ предупреждения для высокого приоритета, зеленый и не мигающий символ предупреждения, обозначающий, что было получено сообщение со средним приоритетом).

В соответствии с другим аспектом настоящего изобретения систему 717 информационного агента (100 по фиг.1) можно использовать совместно с системой 712 приоритетов для направления приоритетных сообщений в один или несколько приемников уведомлений, доступных для пользователей. Как будет более подробно описано ниже, система 717 IA может быть адаптирована для приема приоритетных сообщений 716 и принятия решения в отношении них, например, в отношении того, где и как уведомлять пользователя. В качестве примера система 717 IA может определять модальность связи (например, текущий приемник 718 уведомлений пользователя, такой, например, как сотовый телефон, или карманный персональный компьютер (КПК)) и вероятное расположение и/или вероятный фокус внимания пользователя. Если по электронной почте было принято сообщение с высоким уровнем важности, например, система 717 IA может определить местоположение/фокус пользователей и направлять/ переформатировать сообщение в приемник 718 уведомлений, связанный с пользователем. Если было принято сообщение 716 с более низким приоритетом, система 717 IA может быть cконфигурирована так, что она будет оставлять сообщения, принятые по электронной почте в почтовом ящике пользователя для последующего просмотра, например, по желанию. Как будет более подробно описано ниже, другие системы 719 маршрутизации и/или предупреждения можно использовать для направления приоритезированных сообщений 716 пользователям и/или в другие системы.

В следующей секции описания описано генерирование приоритета для текстовых файлов, таких как электронная почта, с использованием системы и процесса автоматической классификации. Генерирование приоритетов для текстов, как описано ниже, можно затем использовать в других системах, таких как платформа уведомления, которая более подробно описана ниже. Описание этой секции приведено совместно с рассмотрением фиг.8 и фиг.9, причем на первой фигуре представлена схема, иллюстрирующая явное и неявное обучение классификатора текста, и на последней показана схема, представляющая то, как приоритет для текста генерируют путем ввода информации в классификатор текста. Также приведено описание фиг.10 и 11, на которых показаны схемы различных структур, в соответствии с которыми могут быть классифицированы приоритеты текста, и совместно с рассмотрением фиг.8 и 11, на которых представлены графики, иллюстрирующие функции стоимости, которые можно использовать в зависимости от типа текста.

Рассмотрим фиг.8, на которой представлен классификатор 820 текста/данных, который можно обучать явно, как представлено стрелкой 822, и неявно, как представлено стрелкой 824, для выполнения классификации для определения приоритета. Явное обучение, представленное стрелкой 822, обычно производят на начальных фазах построения классификатора 820, в то время как неявное обучение, представленное стрелкой 824, обычно производят после построения классификатора 820, например, для тонкой подстройки классификатора 820 с использованием фонового монитора 834. Конкретное описание приведено здесь со ссылкой на классификатор SVM, в качестве примера иллюстрации обучения классификации и подхода варианта выполнения. Можно использовать другие подходы классификации текста, включая байесовские сети, древовидные схемы принятия решений и модели вероятностной классификации, обеспечивающие различные структуры независимости. Классификация текста используется здесь также как содержащая инклюзивную статистическую регрессию, которую используют для разработки модели приоритета.

В соответствии с одним аспектом изобретения векторная машина поддержки (SVM, ВМП), которая хорошо известна, используется как классификатор 820. Следует понимать, что также можно использовать другие модели классификатора, такие как наивные байесовские сети, байесовские сети, древовидные структуры принятия решений и другие модели обучения. SVM сконфигурированы через фазу обучения или тренировки в конструкторе классификатора и в модуле 826 выбора функции. Классификатор представляет собой функцию, которая отображает вектор входного атрибута, x = (x1, x2, x3, x4, xn), с определенной достоверностью того, что входные данные принадлежат к определенному классу, то есть f (x) = достоверность (класс). В случае классификации текста атрибуты представляют собой слова или фразы или другие атрибуты, относящиеся к домену, полученные из слов (например, части речи, присутствие ключевых терминов), и классы представляют собой категории или области, представляющие интерес (например, уровни приоритетов).

Аспект SVM и других подходов индуктивного обучения состоит в использовании тренировочного набора помеченных объектов классов, для автоматического обучения функции классификации. Тренировочный набор представлен как находящийся в пределах накопителя 830 данных, ассоциированного с конструктором 826 классификатора. Как представлено, тренировочный набор может включать поднабор Групп G1-GN, которые включают потенциальные и/или действительные элементы или комбинации элементов (например, слов или фраз), которые ассоциированы с конкретной категорией. Накопитель 830 данных также включает множество категорий 1 - М, в которых группы могут быть ассоциированы с одной или несколькими категориями. В ходе обучения осуществляется изучение функции, которая отображает входные свойства на уровень достоверности класса. Таким образом, после обучения модели категории представлены как взвешенный вектор входных свойств.

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

Конструктор 826 классификатора использует модель 832 обучения для анализа групп и ассоциированных категорий в накопителе 830 данных, для "обучения" функции, отображающей входные векторы, по достоверности класса. Для множества моделей обучения, включая SVM, модель для категорий может быть представлена, как вектор весов свойства w, в котором может быть изучен вектор весов для каждой категории. Когда изучают веса w, новые тексты классифицируют путем подсчета скалярного произведения x и w, где w представляет собой вектор изученных весов, и x представляет собой вектор, представляющий новый текст. Сигмоидальную функцию также можно использовать для преобразования выхода SVM в вероятность P. Вероятности обеспечивают сравнимые оценки среди категорий или классов, из которых можно определять приоритеты.

SVM представляет собой параметризованную функцию, функциональная форма которой определена до обучения. Обучение SVM обычно требует помеченного тренировочного набора, поскольку SVM будет соответствовать функции по набору примеров. Тренировочный набор может состоять из набора N примеров. Каждый пример состоит из входного вектора, xi, и метки категории, yj, которые описывают, находится ли входной вектор в категории. Для каждой категории может существовать N свободных параметров в SVM, обученной по N примерам. Для определения этих параметров решают задачу квадратичного программирования (QP), как хорошо известно. Существует множество хорошо известных методик решения проблемы QP. Эти методики могут включать методику последовательной минимальной оптимизации, а также другие методики. Как показано на фиг.9, входные текстовые данные 936, которые были преобразованы во входной вектор x, прикладывают к классификатору 920 для каждой категории. Классификатор 920 использует изученные весовые векторы w, определенные с помощью конструктора 926 классификатора (например, один весовой вектор для каждой категории), и формирует скалярное произведение для получения выходных данных 938 приоритета, в котором вероятности P могут быть назначены для входного текста 936, обозначая один или несколько ассоциированных приоритетов (например, высокий, средний, низкий).

Как показано на фиг.8, тренировка классификатора 820 текста, как представлено стрелкой 822, включает построение классификатора в 826, включая использование выбора функции. На явной фазе обучения классификатор 820 может быть представлен как текстом с критическим временем, так и текстом с не критическим временем, так что классификатор может различать, например, эти две категории. Этот набор обучения может быть представлен пользователем, или для обучения может использоваться стандартный или используемый по умолчанию набор. После подачи в него подборки текстов классификатор 820 вначале применяет процедуры выбора свойства, затем пытается найти наиболее различающие свойства. В этом процессе используется взаимный информационный анализ. Выбор свойства может работать по одному или нескольким словам, или может быть доступна возможность различения на более высоком уровне, на таком как фразы и части речи, помеченные при обработке естественного языка. То есть классификатор 820 текста может быть снабжен специально помеченным текстом для определения свойств текста, которые считаются важными.

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

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

ИНФОРМАЦИЯ В ЗАГОЛОВКЕ СООБЩЕНИЯ, НАПРИМЕР:

КОМУ: ПОЛЕ (ИНФОРМАЦИЯ ПОЛУЧАТЕЛЯ)

Адресована только пользователю,

Адресована нескольким людям, включая пользователя,

Адресована псевдониму, описывающему небольшое количество людей,

Адресована нескольким псевдонимам с небольшим количеством людей,

Копия: адресована пользователю,

Слепая копия: адресована пользователю.

ОТ: ПОЛЕ (ИНФОРМАЦИЯ ОТПРАВИТЕЛЯ)

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

Отправители, идентифицированные как внутренние для компании/организации пользователя,

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

Отчеты пользователей перед менеджерами,

менеджерами менеджеров пользователей,

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

людьми из внешнего бизнеса.

ИНФОРМАЦИЯ О ПРОШЕДШЕМ ВРЕМЕНИ

Она включает описание событий, которые уже произошли, таких как:

Мы встретились,

встреча прошла,

случилось,

собрались,

заботились,

встреча вчера.

ИНФОРМАЦИЯ О БУДУЩЕМ ВРЕМЕНИ

Завтра,

На этой неделе,

Собираешься ли ты,

Когда можем мы,

Ожидание с нетерпением,

Будет ли это,

Будет.

ИНФОРМАЦИИ О ВСТРЕЧЕ И СОГЛАСОВАНИИ,

Собраться вместе

Можешь ли ты встретить,

Мы встретимся

Согласуй с,

Нужно встретиться,

Увидимся,

Организуй встречу,

Хотел бы пригласить,

Будь поблизости.

РЕШЕНИЕ ПО ДАТАМ

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

5/2,

В 12:00.

ВОПРОСЫ

Слова, фразы, расположенные рядом с вопросительным знаком (?)

Обозначение персональных запросов:

Не могли бы Вы,

Находитесь ли Вы,

Сможете ли Вы,

Пожалуйста,

Не могли бы Вы сделать,

Позвольте спросить,

От Вас.

Обозначения потребности:

Мне нужно,

Ему нужно,

Ей нужно,

Я бы хотел,

Я был бы благодарен,

Я хочу,

Он хочет,

Она хочет,

Позаботьтесь.

КРИТИЧНОСТЬ ВРЕМЕНИ

скоро произойдет,

прямо сейчас,

конечный срок будет,

конечный срок установлен,

как можно скорее,

мне нужно это срочно,

это нужно сделать срочно,

сделать прямо сейчас,

немедленно,

к [дата],

к [время].

ВАЖНОСТЬ

это важно,

это критично,

слово, фраза +!,

Явно выраженное состояние флага приоритета (низкого, отсутствия, высокого).

ДЛИНА СООБЩЕНИЯ

Количество байтов в компоненте нового сообщения.

СИМВОЛЫ КОММЕРЧЕСКОЙ И РЕКЛАМНОЙ ЭЛЕКТРОННОЙ ПОЧТЫ С СОДЕРЖАНИЕМ, ПРЕДНАЗНАЧЕННЫМ ДЛЯ ВЗРОСЛЫХ

Бесплатно!!,

Слово +!!!,

До 18,

Только для взрослых,

Процент слов, записанных большими буквами,

Процент не цифро-буквенных знаков.

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

Кроме того, как показано на фиг.8, неявное обучение классификатора 820, как представлено стрелкой 824, может быть проведено путем мониторинга работы пользователя или использования структур через фоновый монитор 834, который может быть установлен, например, в настольном компьютере или в мобильном компьютере пользователя. Например, по мере работы пользователей список почтовых сообщений пересматривается, при этом предполагаться, что сообщения, критичные по времени, читают первыми, и сообщения с меньшим приоритетом просматривают позже и/или удаляют. То есть при получении нового сообщения по электронной почте выполняется мониторинг пользователя для определения, открывает ли он или она немедленно это сообщение электронной почты и в каком порядке удаляет электронную почту без открывания и/или отвечает на электронную почту через относительно короткий период времени. Таким образом, классификатор 820 адаптируется так, что он отслеживает пользователя во время работы или управления системой, при этом классификатор периодически подстраивается по результатам тренировки, проводимой в фоновом режиме, и обновляется для улучшения принятия решений в режиме реального времени. Фоновые технологии для построения классификаторов могут продолжаться от технологий, которые используются для обновления классификатора 820 с использованием новых тренировочных сообщений.

В качестве альтернативы могут быть собраны большие количества сообщений, при этом новые фильтры создают в процессе пакетной обработки либо в соответствии с ежедневным расписанием, по количеству новых сообщений, допущенных в тренировочный набор, и/или с использованием комбинаций этих подходов. Для каждого сообщения, введенного в классификатор, может быть создан, например, новый случай для классификатора. Случаи сохраняют как отрицательные и положительные примеры текстов, которые обладают, например, высоким или низким приоритетом. В качестве примера один или несколько классов низкой, средней и высокой срочности могут распознаваться так, что вероятности принадлежности к каждому из этих классов используют для построения ожидаемой критичности. Большие количества классов критичности можно использовать для получения более высокой разрешающей способности. Например, как показано на фиг.9, тренировочный набор сообщений 940 (например, с очень высокой, высокой, средней, нормальной, низкой, очень низкой и т.д. важностью) можно первоначально использовать для обучения классификатора 942, так что достигается классификация в режиме реального времени, как обозначено в 944, в котором новые сообщения классифицируют в соответствии с количеством примеров, разрешенных тренировочным набором 940. На фиг.9 в качестве примера представлены три такие категории, однако следует понимать, что можно обучить множество таких категорий в соответствии с изменяющимися уровнями требуемой важности. Как показано, новые сообщения 944 могут быть помечены, снабжены ярлыками и/или отсортированы в одну или несколько папок 946, например, в соответствии с приоритетами, назначенными классификатором 942. Как будет более подробно описано ниже, назначенные приоритеты могут дополнительно использоваться последующими системами для составления формата сообщения, доставки и определения модальности для пользователя.

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

Например, постоянная частота потерь, связанная с задержанным просмотром сообщений, называется ожидаемой критичностью (EC, ОК) сообщения, в которой

где C представляет собой функцию стоимости, d - задержка, E - событие, H - класс критичности электронной почты, и EC выражена как сумма вероятностей класса (классов), взвешенных на частоту потери, описанную функцией C стоимости для потенциального класса (классов).

В качестве примера, как показано на фиг.9, текст, такой как сообщения электронной почты 936, вводят в классификатор 920, который на его основе генерирует приоритет 938 для текста 936. Таким образом, классификатор 920 генерирует приоритет 938, измеренный как процентное значение, например, от 0 до 100%. Это процентное значение может представлять собой меру вероятности того, что текст 936 имеет высокий или некоторый другой приоритет на основе предыдущего обучения классификатора 920.

Следует отметить, что настоящее изобретение в том виде, как оно описано выше, классификатор 920 и приоритет 938 могут быть основаны на схеме, в которой электронная почта на фазе тренировки рассматривается как имеющая, например, высокий приоритет или низкий приоритет. Эта схема представлена со ссылкой на фиг.10, в которой классификатор 1020 текста обучают с помощью группы текстов 1047, для которой заранее установлен высокий приоритет, и группы текстов 1048, для которой заранее установлен низкий приоритет. Текст для анализа вводят в классификатор 820, на выход которого поступает скалярное число 1049, например, представляющее собой меру вероятности того, что анализируемый текст имеет высокий или низкий приоритет.

Например, как показано на фиг.10 и 11, схемы представляют структуру, в которой тексты 1036, 1136 категоризированы как имеющие низкий, средний и высокий приоритет. Как описано выше, множество других тренировочных наборов можно использовать для обеспечения большей или более высокой разрешающей способности приоритетов. Классификатор 1020, 1120 текста обучают на группе текстов 1047, 1147, которые имеют высокий приоритет, и группе текстов 1048, 1148, которые имеют низкий приоритет, и на группе текстов 1150, которые имеют средний приоритет. Таким образом, анализируемый текст 1036, 1136 вводят в классификатор 1020, 1120, на выход которого поступает скалярное число 1049, 1149, так что можно измерить вероятность того, что анализируемый текст имеет высокий приоритет, если это требуется, или, например, средний приоритет, или низкий приоритет. Классификатор 1020, 1120 может выводить класс 1152, который обозначает класс низкого, среднего или высокого приоритета, к которому наиболее вероятно относится текст 1136. Дополнительные классы также могут быть добавлены, если необходимо.

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

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

Например, общий случай показан на фиг.12, на которой представлен график 1254 линейной функции стоимости, зависящей от приоритета текста. На графике 1254 по мере увеличения времени также увеличивается стоимость не просмотренного текста. Однако стоимость увеличивается в большей степени для сообщения с высоким приоритетом, как обозначено линией 1256, по сравнению с сообщением среднего приоритета, как обозначено линией 1258, или с сообщением низкого приоритета, как обозначено линией 1260. Например, линия 1256 высокого приоритета может иметь наклон 100, линия 1258 среднего приоритета может иметь наклон 10, и линия 1260 низкого приоритета может иметь наклон единица. Эти значения наклона затем могут использоваться в классификаторе 1020, 1120 при назначении приоритета данному тексту, например, с использованием регрессионного анализа.

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

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

где EL представляет собой ожидаемые потери, p(critical_i) представляет собой вероятность того, что текст имеет критичность i. C(critical_i) представляет собой функцию стоимости для текста, имеющего критичность i, и n представляет общее количество классов критичности, минус единица. Функции стоимости могут быть линейными или нелинейными, как было описано выше. В случае, когда функция является линейной, функция стоимости определяет постоянную частоту потерь в зависимости от времени. Для нелинейных функций частота потерь изменяется при задержке просмотра или обработке текста и может увеличиваться или уменьшаться, в зависимости от величины задержки.

В случае, когда n=1, что указывает на то, что существует только два класса приоритетов, низкий и высокий, ожидаемые потери могут быть сформулированы в следующем виде:

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

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

где t представляет время задержки до просмотра документа.

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

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

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

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

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

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

Другие различия, которые могут быть рассмотрены при классификации, включают длину сообщения, были ли обнаружены вопросы и указано ли имя пользователя в сообщении. Формулировки, ассоциированные с критичностью по времени, могут повысить важность сообщения. Например, такие фразы, как "произойдет скоро," "прямо сейчас", "как можно скорее," "ASAP" (как можно скорее) и "окончательный срок", могут повысить критичность сообщения. Использование прошедшего времени по сравнению с будущим временем можно учитывать, так же как задачи согласования, определяемые такими фразами, как "собираемся", "можем ли мы встретиться" и так далее. Признаки рекламной почты могут снизить приоритет сообщения. Сказуемые, представляющие комбинации, такие как короткие вопросы от отправителя, расположенного рядом с пользователем в организационной структуре, также можно рассматривать в процессе классификации.

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

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

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

В качестве другой политики можно использовать анализ затрат и результатов, основанный на более полном теоретическом анализе принятия решения, таком как NEVA = EVTA - ECA - TC, где NEVA представляет собой суммарную ожидаемую величину предупреждения, EVTA представляет собой ожидаемую величину предупреждения, ECA представляет собой ожидаемую стоимость предупреждения и TC представляет затраты на передачу, связанные с передачей сообщения.

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

где EL представляет собой ожидаемые потери в результате не просмотра текста в данный момент времени t, и EC представляет ожидаемые затраты на предупреждение пользователя о тексте в текущий момент времени t. Ожидаемая потеря описана в предыдущей секции описания.

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

где EL_alert представляет собой ожидаемую потерю пользователя при просмотре сообщения, если он или она просмотрит сообщение сейчас, после предупреждения, в отличие от EL_no-alert, которая представляет собой ожидаемую потерю, если пользователь самостоятельно просмотрит сообщения в определенный момент времени без предупреждения, минус EC - ожидаемые затраты на предупреждение с учетом отвлечения внимания и непосредственных затрат, связанных с передачей информации. Кроме того, информация из нескольких сообщений может быть сгруппирована вместе в виде одного составного предупреждения. Просмотр информации о многих сообщениях в предупреждении может быть более дорогостоящим, чем информация, относящаяся к предупреждению об одном сообщении. Такое повышенное отвлечение внимания может быть представлено в результате установления стоимости предупреждения как функции его информационной сложности. При этом можно предположить, что ЕVA сообщения электронной почты не зависит от EVA других сообщений электронной почты. ЕВА (M_i, t), например, относится к величине предупреждения пользователя об одиночном сообщении M_i в момент времени t, и ECA(n) относится к ожидаемым затратам на передачу содержания из n сообщений. Таким образом, множество сообщений можно рассматривать путем суммирования вместе ожидаемой величины передаваемой информации о наборе из n сообщений, в которой:

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

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

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

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

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

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

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

Приоритет данных затем выводят на этапе 1984. Как показано на фиг.29, это может включать обработку на этапах 1986, 1988, 1990, 1992 и 1994. На этапе 1986, как ожидается, определяется потеря от не просмотра данных в данный момент времени t. При таком определении учитывают ожидаемые потери от не просмотра текста и будущее время на основе предположения, что пользователь самостоятельно просмотрит текст, без предупреждения, как было описано. На этапе 1988 определяют ожидаемую стоимость предупреждения, как также было описано. Если затраты будут больше, чем стоимость в 1990, то передают предупреждение в момент времени t, 1992, и процесс переходит обратно на этап 1986, для нового текущего времени t. Обработка снова на этапе 1986 может быть выполнена с течением времени, при этом ожидаемые потери могут в некоторый момент времени превысить стоимость предупреждения, так что результат вычисления в 1990 может измениться. После того как ожидаемые потери превысят затраты на предупреждение, выполняют предупреждение пользователя или другой системы на этапе 1994.

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

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

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

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

Рассмотрим теперь фиг.21, на которой представлена система 2100, изображающая, как механизм выполнения предпочтений и анализатор контекста функционируют вместе, в соответствии с аспектом настоящего изобретения. Система 3100 включает анализатор 3122 контекста, механизм 2124 выполнения предпочтений, один или несколько источников 1 - N, 2126, 2127, 2128 уведомления о событии, систему 2130 приоритетов, которая может работать как источник уведомления, и один или несколько приемников 1 - М, 2136, 2137, 2138 действия или уведомления, где N и М представляют собой целые числа соответственно. Источники также могут быть обозначены как публикаторы события, в то время как приемники также могут быть названы абонентами события в соответствии с аспектом настоящего изобретения. Может существовать любое количество приемников и источников. В общем, механизм 2124 выполнения передает уведомления, которые также называются событиями или предупреждениями, из источников 2126-2128 в приемники 2136-2138, на основе частично параметрической информации, сохраненной в и/или доступной для анализатора 2122 контекста.

Анализатор 2122 контекста сохраняет/анализирует информацию в отношении переменных и параметров пользователя, которые влияют на принятие решений об уведомлении. Например, параметры могут включать контекстную информацию, такую, как обычное местоположение пользователя и фокус внимания или деятельности, в зависимости от времени суток и дня недели, а также дополнительные параметры, обусловленные этими параметрами, такие как пользователи устройств, которые могут быть доступны в различных местах. Такие параметры также могут представлять собой функции наблюдений, выполненных автономно с использованием одного или нескольких датчиков. Например, один или несколько профилей (не показаны) могут быть выбраны или модифицированы на основе информации о местоположении пользователя, которая может быть представлена подсистемой глобальной системы навигации (GPS), по информации о типе используемого устройства и/или структуры использования этого устройства, а также когда в последний раз устройство определенного типа использовалось пользователем. Кроме того, как более подробно описано ниже, автоматизированный интерфейс также можно использовать для динамического вывода о параметрах или статусе, таких как местоположение и предмет внимания. Параметры профиля могут быть сохранены как профиль пользователя, который может быть отредактирован пользователем. Помимо передачи набора заданных профилей или динамических выводов, архитектура уведомления может позволить пользователям указывать в режиме реального времени свое состояние, например, когда пользователь является не доступным, за исключением, например, важных уведомлений в течение следующих "x" часов, или начиная с определенного времени.

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

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

Источники 2126-2128, 2130 генерируют уведомления, предназначенные для пользователя и/или другого объекта. Например, источники 2126-2128 могут включать сообщения, такие как сообщения, передаваемые по Интернет или по сети, и телефонные голосовые сообщения, а также программные услуги. Источники уведомления определены, в общем, здесь как источники, которые генерируют события, которые также можно назвать уведомлениями и предупреждениями, предназначенными для предупреждения пользователя или уполномоченного заместителя пользователя об информации, услугах и/или системе или событиях в мире. Источник уведомления также можно назвать источником события.

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

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

прикладные программы, передаваемые по электронной почте в компьютер, такие как календарные системы;

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

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

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

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

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

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

Механизм 2124 выполнения выполняет доступ к информации, сохраненной и/или определенной анализатором контекста, и определяет, какое из уведомлений, принятых из источников 2126-2128, передать, в какой из приемников 2136-2138. Кроме того, механизм 2124 может определять, как уведомление должно быть передано, в зависимости от того, какой из приемников 2136-2138 был выбран, для передачи информации. Например, может быть определено, что уведомления должны быть сведены вместе перед передачей в выбранные приемники 2136-2138.

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

точность и надежность передачи каждого доступного приемника уведомлений;

стоимость отвлечения внимания пользователя;

новизну информации для пользователя;

время, через которое пользователь самостоятельно просмотрит информацию;

потенциальное значение информации, чувствительной к контексту; и/или

увеличение и/или уменьшение значения с течением времени для информации, содержащейся в уведомлении.

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

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

где пользователь находится в настоящее время;

насколько важна информация;

какова стоимость задержки уведомления;

насколько будет отвлекать внимание уведомление;

какова вероятность того, что пользователь получит сообщение; и

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

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

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

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

Протокол передачи гипертекста (HTTP, ППГТ) или расширения http, как известно в данной области техники;

Простой протокол доступа к объектам (SOAP), как известно в данной области техники;

Инструментарий Управления Windows (WMI, ИУВ), как известно в данной области техники;

Технология Jini, как известно в данной области техники; и,

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

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

Рассмотрим теперь фиг.22, на которой представлен анализатор 2122 контекста архитектуры системы - информационного агента, описанной в предыдущей секции описания, представленный более подробно здесь в системе 2200. Анализатор 2222 контекста, показанный на фиг.22, включает накопитель 2240 предпочтений уведомления пользователя, модуль 2260 контекста пользователя, который включает накопитель 2262 контекста пользователя и "белую доску" 2264 (совместно используемая виртуальная классная доска для видеоконференцсвязи). Анализатор 2222 контекста, в соответствии с одним аспектом изобретения, может быть выполнен как одна или несколько компьютерных программ, выполняемых процессором компьютера, хранящаяся на его считываемом компьютером носителе информации, включая, без ограничений, запоминающее устройство.

В накопителе 2262 предпочтений сохранены параметры уведомления для пользователя, такие как уведомления, определенные по умолчанию, о предпочтениях пользователя, например профиль пользователя, который может быть отредактирован и модифицирован пользователем. Накопитель 2262 предпочтений можно рассматривать как такой накопитель, в котором сохранена информация о параметрах, которые влияют на форму уведомления пользователя. Как описано в настоящем описании, предпочтения могут быть указаны пользователями с использованием схематизированной логики, например, в формате IF-THEN. Контекстный модуль 2260 пользователя определяет текущий контекст пользователя на основе одного или нескольких источников 2280 контекстной информации, которая опубликована, например, на белой доске 2264. Накопитель 2262 профиля контекста пользователя сохраняет контекстные параметры для пользователя, такие как определенные по умолчанию установки контекста для пользователя, которые пользователь может редактировать и модифицировать. То есть контекстный модуль 2260 пользователя обеспечивает наилучшее предположение или оценку о текущей контекстной информации пользователя путем доступа к информации в накопителе 3262 профиля и/или обновления предварительной установки представлений в накопителе 2262 путем опознания деятельности через один или несколько источников 2280 контекста. Накопитель 2262 профиля можно рассматривать как накопитель, который сохраняет априори, например, местонахождение пользователя и что делает пользователь.

Накопитель 2262 профиля контекста пользователя может представлять собой профиль пользователя, к которому заранее был выполнен доступ, и/или был заранее определен, в котором содержится такая информация, как детерминированный или вероятностный профиль. Профиль может представлять типичные местоположения, деятельность, доступность устройств и стоимость и значения различных классов уведомления, как функция таких наблюдений, как время дня, тип дня и взаимодействие пользователя с одним или несколькими устройствами. Тип дня может включать, например, будние дни, выходные дни и праздники. Модуль 2260 контекста пользователя может затем активно определять или делать логически выводы в отношении аспектов контекста или состояния пользователя, таких как текущее или будущее местоположение и состояние внимания пользователя. Кроме того, доступ к действительному состоянию контекста можно выполнять непосредственно из источников 2280 информации контекста через белую доску 2264, и/или логические выводы по ним можно делать на основании множества таких наблюдений, с использованием способов логических выводов, таких как байесовский вывод, как более подробно описано ниже.

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

Другие типы контекстных источников 2280 включают информацию персонального менеджера информации (PIM, ПМИ) для пользователя, который обычно может обеспечивать запланированную информацию, относящуюся, например, к плану пользователя. Текущее время дня, а также местоположение пользователя, например, определенное с помощью системы глобальной навигации (GPS), и/или доступность для пользователя сотового телефона, КПК или переносного компьютера, которые могут быть определены по отношению к данному месту, также являются источниками 2280 контекста. Кроме того, мобильное устройство, используемое в режиме реального времени, представляет собой определенный тип источника 2280 контекста. Например, мобильное устройство, такое как сотовый телефон, может обеспечивать возможность определения, выполняет ли в данный момент времени пользователь доступ к нему, а также, например, ориентацию устройства и его наклон (что также обозначает информацию об использовании устройства), ускорение и скорость (например, информацию, обозначающую, передвигается ли пользователь или нет).

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

В соответствии с одним аспектом настоящего изобретения источники 2326-2328 уведомления могут иметь один или несколько следующих параметров в пределах стандартного описания или атрибутов и взаимозависимостей, называемых здесь схемой источника уведомления или схемой источника. Следует отметить, что схема может быть представлена для источников, для приемников и для источников информации контекста, описанных выше. Такие схемы обеспечивают декларативную информацию о различных компонентах и могут включать источники 2326-2328, механизм 2324 уведомления, приемники 2336-2338 и анализатор 2322 контекста для совместного использования семантической информации друг с другом. Таким образом, различные схемы предоставляют информацию о природе, срочности и модальностях связи устройства в связи с уведомлением. То есть схема может быть определена, в общем, как подборка классов взаимозависимостей между классами, которые определяет структуру уведомлений и событий, содержащих информацию, включающую класс события или уведомления, источник, цель, семантические правила, события или уведомления, информацию онтологического содержания, надежность наблюдений и, по существу, любые атрибуты, относящиеся, например, к качеству услуги.

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

Компромисс в отношении точности, связанный с уведомлением, обозначает потерю значения информации, содержащейся в уведомлении, например, в результате использования различных форм указанного разрешенного усечения и/или резюмирования. Такое усечение и/или резюмирование может потребоваться для уведомления, передаваемого в определенные типы приемников 2336-2338 уведомлений, которые могут иметь полосу пропускания и/или другие ограничения, не позволяющие принимать в приемнике полное уведомление в том виде, как оно было сгенерировано первоначально. Точность, в общем, относится к природе и/или степени полноты исходного содержания, связанного с уведомлением. Например, длинное сообщение, переданное по электронной почте, может быть усечено или другим образом сведено к резюме длиной максимум 100 знаков, разрешенной для сотового телефона, включая потери точности. Аналогично, для исходного сообщения, содержащего текст и графическое содержание, будут потеряна точность при передаче через устройство, которое обладает только возможностями представления текста. Кроме того, устройство может обеспечить возможность представления только участка всей разрешающей способности, доступной от источника. Компромисс точности относится к набору предпочтений точности источника, выраженного либо в виде упорядочений (например, придания важности по порядку вначале графике, а затем звуку) и/или функций стоимости, которые указывают, как уменьшается общее значение содержания уведомления при изменении его точности. Например, компромисс точности может описывать, как полное значение, ассоциированное с передачей полного сообщения по электронной почте, изменяется при постепенном увеличении степени усечения. Атрибуты контекста, например, могут включать резюме, связанное с природой содержания, представляющее такую информацию, когда основное сообщение включает текст, графические и звуковые компоненты. Само содержание представляет собой собственно графику, текст и/или звук, которые составляют содержание сообщения уведомления.

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

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

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

Приемники 2336-2338 уведомления могут иметь один или несколько следующих параметров, обеспечиваемых схемой. Эти параметры могут включать класс устройства; режимы передачи информации (предупреждения); и для ассоциированного режима, например, возможности по точности/предоставлению, надежности передачи, действительной стоимости передачи информации и/или стоимости отвлечения внимания. Для устройств, которые адаптированы для параметризованного контроля над атрибутами предупреждений, схема этих устройств может дополнительно включать описание атрибутов предупреждения и параметров для управления атрибутами, и функций, с помощью которых другие атрибуты (например, надежность передачи информации, стоимость распространения) изменяются при различных установках атрибутов предупреждения. Схема для приемников уведомлений определяет способ, с помощью которого устройство уведомления передает семантическую информацию о своей природе и возможностях в механизм 2324 выполнения уведомления и/или другие компоненты системы. Определенные по умолчанию атрибуты и шаблоны схемы для различных типов устройств могут быть сделаны доступными в профилях устройства, сохраненных в накопителе предпочтений уведомления пользователя, таких как накопитель 2240 по фиг.22, как описано в предыдущей секции. Такие определенные по умолчанию шаблоны могут быть направлены на аннулирование значений, предоставленных устройствами, или на обеспечение атрибутов, когда они потеряны из схемы, представленной такими устройствами.

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

Надежность передачи для режима приемника 2336-2338 уведомления обозначает вероятность того, что пользователь получит переданное предупреждение об уведомлении, которое передают пользователю через приемник, работающий в этом режиме. Поскольку надежность передачи может зависеть от доступности устройства и контекста пользователя, надежность передачи для различных режимов устройства может быть обусловлена такими атрибутами контекста, как местоположение и внимание пользователя. Также может быть указана надежность передачи для одного или нескольких уникальных состояний контекста, определяемых векторным произведением таких атрибутов, как уникальные местоположения и уникальные состояния внимания, определенные как дизъюнкция, созданная как абстракции таких атрибутов (например, для каждого местоположения вне дома и в любой период времени после 8:00 и до полудня). Например, в зависимости от того, где в данный момент находится пользователь, информация, передаваемая в сотовый телефон, не всегда может достигать пользователя, в частности, если пользователь находится в области с прерывистой зоной обслуживания, или куда пользователь обычно не берет с собой сотовый телефон (например, на семейный праздник). Контекст также может влиять на надежность передачи, из-за окружающего шума и/или других маскирующих или отвлекающих внимание свойств контекста.

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

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

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

На фиг.25 изображен интерфейс 2500, представляющий, как может быть выполнена прямая спецификация контекста, в соответствии с аспектом настоящего изобретения. Окно 2502, например, имеет секцию 2520 фокуса внимания и секцию 2540 местоположения. В секции 2520 фокуса внимания пользователь может выбирать одну или несколько кнопок 2522 выбора, например, указывая, что пользователь всегда доступен для приема предупреждения; пользователь никогда не доступен для приема предупреждения; и пользователь доступен для приема предупреждения только, когда уровень важности выше, чем заданное пороговое значение. Следует понимать, что могут быть предоставлены другие варианты выбора доступности. Как показано на фиг.25, пороговое значение может быть измерено в долларах, но такой подход приведен только в качестве примера, и изобретение не ограничивается этим. Пользователь может увеличить порог с помощью кнопки-флажка 2524, путем непосредственного ввода нового значения или увеличивая или уменьшая пороговое значение с помощью стрелок 2526.

В секции 2540 местоположения пользователь может выбирать одну или несколько кнопок-флажков 2542 выбора для указания, желает ли пользователь, чтобы ему передавались предупреждения. Например, предупреждения для пользователя можно передавать на настольный компьютер, по электронной почте, в переносной компьютер, по сотовому телефону, в его или ее автомобиль, на пейджер или в устройство карманного персонального компьютера (КПК) и т.д. Следует понимать, что эти устройства приведены только для примера, однако само изобретение не ограничивается ими.

В окне 2502 могут быть заданы установки, принятые по умолчанию для кнопки-флажка 2522 выбора и кнопки-флажка 2524 секции 2520, а также кнопки-флажка 2542 выбора секции 2540, где может быть рассмотрен принятый по умолчанию профиль пользователя. Профиль может быть модифицирован пользователем, при этом пользователь может отменять выбор, принятый по умолчанию, заменяя его своими собственными вариантами выбора. Другие типы профилей также можно использовать в соответствии с изобретением.

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

На фиг.26 показана система 2600, в которой может быть обеспечено непосредственное измерение контекста пользователя. Система 2600 включает анализатор 2602 контекста и соединенное с ним с возможностью передачи данных множество датчиков 2604-2616, а именно, например, сотовый телефон 2604, видеокамеру 2606, микрофон 2608, клавиатуру 2610, КПК 2612, автомобиль 2614 и GPS 2616. Датчики 2604-2616, представленные на фиг.26, показаны только для примера и не представляют ограничение или пределы самого изобретения. Термин датчик используется здесь в общем смысле и представляет собой термин с широким охватом значений, означающий любое устройство или способ, с помощью которого анализатор 2602 контекста может определять, на чем в данный момент сфокусировано внимание пользователя и/или в каком месте в данный момент находится пользователь.

Например, если у пользователя включен сотовый телефон 2604, это указывает, что пользователь может принимать предупреждения на сотовый телефон 2604. Однако если пользователь в данный момент разговаривает по сотовому телефону 2604, это указывает на то, что внимание пользователя сфокусировано на чем-то другом (а именно на текущем телефонном вызове), так что пользователя в данный момент времени не стоит беспокоить предупреждением уведомления. Видеокамера 2606 может, например, быть установлена в офисе пользователя для определения, находится или нет пользователь в своем офисе (то есть для определения местоположения пользователя), а также находятся ли вместе с ним в офисе также другие люди, которые, возможно, встречаются с ним, так что пользователя не следует беспокоить (то есть фокус внимания пользователя). Аналогично микрофон 2608 также может находиться в офисе пользователя для детектирования, разговаривает ли пользователь с кем-то еще, так что пользователя не следует беспокоить, или печатает на клавиатуре (что, например, определяется по звукам работы с клавиатурой), так что пользователя также в данный момент не следует беспокоить. Клавиатуру 2610 также можно использовать для определения, печатает ли пользователь в данный момент времени на ней, при этом, например, если пользователь печатает очень быстро, это может указывать на то, что пользователь сосредоточен на деятельности, связанной с применением компьютера, и его не следует излишне беспокоить (и также может указывать на то, что пользователь фактически находится в своем офисе).

Если пользователь работает с устройством 2612 КПК, это может указывать на то, что пользователь может принимать предупреждения в устройстве 2612, то есть место, в которое можно передавать уведомления, представляет собой место, где расположено устройство 2612. Устройство 2612 также можно использовать для определения текущего фокуса внимания пользователя. Транспортное средство 2614 можно использовать для определения, находится ли пользователь в данный момент времени в транспортном средстве, то есть управляет ли пользователь в данный момент времени транспортным средством. Кроме того, можно учитывать, например, скорость транспортного средства для определения фокуса внимания пользователя. Если скорость, например, выше, чем заданное пороговое значение скорости, тогда можно определить, что пользователь сосредоточен на управлении автомобилем и его не следует отвлекать предупреждениями об уведомлении. Устройство 2616 GPS также можно использовать для определения текущего местоположения пользователя, как известно в данной области техники.

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

На фиг.27 показана схема, иллюстрирующая пример иерархически упорядоченного набора правил 2700. Набор правил 2700 включает, например, правила 2702, 2704, 2706, 2708, 2710, 2712 и 2714. Следует отметить, что можно использовать другие правила, сконфигурированные аналогичным образом. Как показано на фиг.27, правила 2704 и 2706 подчинены правилу 2702, в то время как правило 2706 подчинено правилу 2704 и правило 2714 подчинено правилу 2712. Правила упорядочены в том, что вначале проверяют правило 2702; если определяется, что оно истинно, затем проверяют правило 2704, и если будет найдено, что правило 2704 истинно, тогда проверяют правило 2706 и т.д. Если будет определено, что правило 2704 ложно, то проверяют правило 2708. Если будет определено, что правило 2702 ложно, тогда проверяют правило 2710, и при определении, что оно истинно, выполняют проверку правила 2712, и в случае его истинности, выполняют проверку правила 2714. Пользователь предпочтительно может сам создавать и/или модифицировать эти правила. В противном случае правила другого типа также могут быть включены в набор правил 2700 (например, если правило if-then будет определено, как ложное, тогда проверяют другое правило).

Таким образом, набор правил может быть построен пользователем, в соответствии с которым определяют контекст пользователя. Например, в отношении местоположения набор правил может быть установлен таким образом, что первое правило проверяет, является ли текущий день рабочим днем. Если это так, тогда второе правило, подчиненное первому правилу, проверяет, является ли текущее время временем в диапазоне от 9:00 до 17:00. Если это так, тогда второе правило проверяет, находится ли пользователь в своем офисе, в противном случае пользователь находится дома. Если будет определено, что первое правило ложно, то есть текущий день является выходным днем, а не рабочим днем, тогда другое правило может установить, что пользователь находится дома. Следует отметить, что при этом не подразумевается, что этот пример является ограничительным примером или устанавливающим пределы в отношении самого изобретения, в котором одно или несколько других правил также могут быть сконфигурированы аналогичным образом.

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

На фиг.28 показана схема системы 2800, в которой выполняется анализ на основе логического вывода с помощью механизма 2802 логического вывода, для определения контекста 2804 пользователя, в соответствии с аспектом настоящего изобретения. Механизм 2802 в одном аспекте представляет собой компьютерную программу, выполняемую процессором компьютера, которая записана на его считываемом компьютером носителе, таком как запоминающее устройство. Контекст 3804 пользователя можно рассматривать как выходную переменную механизма 2802.

Механизм 2802 может обрабатывать одну или несколько входных переменных для принятия решения по контексту. Такие входные переменные могут включать один или несколько датчиков 2808, таких как датчик (датчики), которые были описаны при описании подхода прямого измерения для определения контекста в предыдущей секции описания, а также текущее время и день, которые представлены часами 2810 и календарем 2812, доступ к которым может осуществляться программой планирования работой пользователя или компьютерной программой-менеджером персональной информации (PIM) и/или, например, устройством КПК пользователя. Другие входные переменные также можно рассматривать на основе схемы, представленной на фиг.28. Переменные по фиг.28 не рассматриваются как ограничения или границы самого изобретения.

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

Можно использовать байесовские сети, которые позволяют делать логический вывод в отношении вероятности контекстов альтернативной деятельности или состояний на основе набора наблюдений о деятельности пользователя и его местоположения. Например, на фиг.29 показана байесовская сеть 2900 для логической оценки фокуса внимания пользователя в течение единичного периода времени. Состояния переменной 2920 Focus of Attention (фокус внимания) относятся к контексту, связанному с областью задачи выполнения операционной системы и не связанному с нею. Примеры контекста внимания, рассматриваемые в модели, включают, например, осведомленность о ситуации, быстрое схватывание, неспецифические фоновые задачи, генерирование или просмотр сфокусированного содержания, генерирование или просмотр легкого содержания, просмотр документов, встречи в офисе, встречи вне офиса, прослушивание презентаций, частное время, время в семье, персональный фокус, случайные разговоры и переезды. Байесовская Сеть 2900 учитывает, что на текущее внимание и местоположение пользователя влияют запланированные встречи 2930 пользователя, время суток 2940 и близость к срокам 2950 выполнения задач. На распределение вероятности внимания пользователя также влияют, например, обобщенные характеристики статуса окружающих акустических сигналов 2960, которые можно отслеживать в офисе пользователя. Сегменты окружающих акустических сигналов 2960 с течением времени создают ключи/входные данные о наличии активности и разговоров. Состояние и конфигурация программных приложений и текущий поток деятельности пользователя, генерируемый пользователем, который взаимодействует с компьютером, также обеспечивают источник свидетельств о внимании пользователя.

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

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

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

На фиг.31 показана схема 3100 последовательности выполнения операций, определяющая контекст пользователя в соответствии с настоящим изобретением. Процесс включает определение местоположения пользователя на этапе 3102 и фокуса внимания пользователя на этапе 3104. Эти действия могут быть выполнены с использованием одного или нескольких подходов, описанных выше. Например, можно использовать профиль; пользователь может указывать свой собственный контекст; можно использовать непосредственное измерение контекста; можно следовать набору правил; также можно выполнить анализ на основе логических выводов, например, с использованием Байесовского анализа или статистической модели. Следует понимать, что для определения контекста пользователя можно использовать другие варианты анализа. Например, можно использовать источник на основе интегрированной видеокамеры, который отмечает, находится ли кто-то перед компьютером и смотрит ли он или она на компьютер. Однако следует отметить, что система может работать как с камерой, так и без нее. Для всех источников система может работать, по существу, с любым доступным входным источником, который не требует какого-либо определенного источника для логического вывода о контексте. Кроме того, в других аспектах акселерометры, микрофоны и бесконтактные датчики могут быть встроены в небольшие КПК, которые позволяют чувствовать местоположение пользователя и фокус его внимания.

На фиг.32 показана схема 3200 последовательности выполнения операций, предназначенных для выполнения процесса принятия решения для механизма уведомления в соответствии с аспектом настоящего изобретения. На этапе 3202 один или несколько источников уведомления генерируют уведомления, которые принимает механизм уведомления. На этапе 3204 анализатор контекста генерирует/определяет информацию контекста в отношении пользователя, которую механизм уведомления принимает на этапе 3206. То есть в соответствии с одним аспектом настоящего изобретения на этапе 3204 анализатор контекста выполняет доступ к профилю контекстной информации пользователя, который указывает текущее состояние внимания и местоположение пользователя и/или выполняет доступ к информации пользователя в режиме реального времени в отношении текущего состояния внимания пользователя и его местоположения на основе одного или нескольких источников информации контекста, как было описано в предыдущих секциях описания. На этапе 3208 механизм уведомления определяет, какое из уведомлений следует передать в какой из приемников уведомления, частично, на основе информации контекста, принятой из анализатора контекста. Механизм уведомления также выполняет определение на основе информации, относящейся к параметрам уведомления пользователя, сохраненной анализатором контекста. То есть в соответствии с одним аспектом на этапе 3208 механизм выполняет теоретический анализ для принятия решения в отношении того, следует ли предупреждать пользователя о данном уведомлении и как следует предупреждать пользователя. Как более подробно будет описано ниже, на этапе 3208 можно использовать теоретический и/или эвристический анализ для принятия решения, определения и политики. Параметры уведомления в отношении пользователя можно использовать для персонализации анализа путем внесения отсутствующих значений или путем перезаписи параметров, полученных в схеме источников или приемников. Предпочтения уведомления также позволяют обеспечить политики (например, эвристические), которые используются вместо теоретического анализа для принятия решения. На основе этих определений механизм уведомления передает уведомления дистрибьютеру на этапе 3210.

Установка прикладной программы под управлением данных

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

Для выполнения указанного выше все события, предпочтения и процедуры могут быть сохранены как данные. Это позволяет системе использовать преимущества постоянно повышающейся мощности обработки механизмов базы данных и запросов для выполнения множества прикладных программ, таких как прикладные программы 300 информационного агента (фиг.3). Как описано выше, предпочтения могут быть определены конечными пользователями и затем могут быть обобщены в полях данных высокого уровня, в таблицах и базах данных. События могут быть захвачены или могут быть считаны и затем сохранены в базе данных. Обычные сохраненные процедуры, такие как процедуры оценки запроса, также могут быть представлены как данные, путем создания процедур и сворачивания текста в одну или несколько таблиц базы данных. После этого, когда процедура должна быть выполнена, строку текста, представляющую процедуру, можно вытянуть из таблицы базы данных и динамически оценить в базе данных. Такой подход существенно уменьшает количество сохраненных процедур, которые должна создавать прикладная программа, и делает установку прикладной программы просто операцией DML (ЯМД, язык манипулирования данными), управляемой данными.

Возможности компоновки и расширения

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

Целью обеспечения пригодности для компоновки и возможности расширения прикладной программы информационного агента является создание новой прикладной программы, компонента или модели системы (хотя это возможно и следует учитывать в объеме настоящего изобретения). Цель скорее состоит в обеспечении возможности динамического расширения для уровня или компонента системы, который позволяет пользователю указывать логику предпочтения через модель ECA (например, компонент 330 логики принятия решения). В частности, цель состоит в обеспечении возможности новых условий и действий (часть CA в ECA) для конечных пользователей после установки данной прикладной программы. Кроме того, следует понимать, что события (часть E в ECA) также можно динамически расширять аналогичным образом.

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

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

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

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

На фиг.33 изображена цепочка 3300 развития условия/действия в соответствии с аспектом настоящего изобретения. Условия и действия начинаются как функции условия или действия на этапе 3310. Такое обозначение функции можно использовать при ссылке к формальной сигнатуре определения функции, обеспечивающей, например, SQL/сохраненную процедуру. Между моментом времени, когда новая функция условия или действия определена и когда функция привязана к существующей прикладной программе, с помощью декларации соответствующих условий или действий эту функцию рассматривают как функцию-кандидат. Разработчик функции- кандидата определяет связи, которые позволят целевой, предназначенной для выполнения прикладной программе, создавать условия или действия на основе этой функции, называемые условиями или действиями кандидата на этапе 3320. На данном этапе условия или действия являются кандидатами на использование существующей, предназначенной для исполнения прикладной программы, так что прикладная программа может использовать эти условия или действия, но от нее не требуется принимать их. Логика принятия прикладной программы для расширения определяет, будет ли такая связь принята или нет, например, на основе того, кто подписал предложенное расширение/связь. После того как прикладная программа связывает свои классы предпочтения с функцией-кандидатом условия или логики, условия или действия становятся просто условиями или действиями на этапе 3330. Наконец, когда конечный пользователь использует условие или действие в контексте вновь определенного предпочтения, говорят, что это действие или условие должны быть реализованы на основе экземпляра, как представлено в цепочке на этапе 3340.

На фиг.34 показана система 3400 для взаимодействия прикладной программы в соответствии с аспектом настоящего изобретения. Система 3400 содержит компонент 3410 регистра экземпляра, регистр 3412 определения, регистр 3414 связывания, прикладную программу A 3420, прикладную программу B 3430, связь 3425 и компонент 3440 расширения. В одном варианте выполнения возможности расширения модуль развертывания представляет собой прикладную программу или расширение. Экземпляры расширяют путем добавления прикладных программ или файлов данных прикладных программ (ADF, ФДП). ADF могут быть созданы разработчиками для использования во время разворачивания отдельной прикладной программы. ADF обычно определяет центральную логику прикладной программы и может включать схемы для, помимо прочего, событий, условий и действий, таких как уведомления. Прикладные программы могут быть расширены путем добавления расширений или файлов данных расширения (EDF, ФДР). EDF могут быть созданы любым человеком и используются в любой момент времени после момента создания прикладной программы (включая исходную установку прикладной программы).

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

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

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

Связь, зарегистрированная в регистре 3414, может иметь несколько статусов. Например, связь может представлять собой связь кандидата. Связи кандидата создаются определителем функции, и их делают доступными для других прикладных программ. Связь также может иметь статус функции связи, указывающей, что связи являются специфичными для данной прикладной программы, и представляющий, как эти специфические прикладные программы связаны с данным условием или функцией действия. Также, помимо этого, связь может иметь состояние "не принято". Эти функции представляют собой функции-кандидаты, которые нацелены на конкретную прикладную программу, но не были приняты логикой приема целевой прикладной программы. Логика приема может быть декларирована в ADF и может включать компоненты для, помимо прочего, обеспечения проверки того, что источник EDF является аутентичным (например, с использованием цифровой подписи), авторизованным (например, из списка надежных источников), сертифицированным (EDF был подписан надежным источником). Другая информация, которую можно найти в регистре 3414, включает, без ограничений:

Компонент 3420 расширения создает условия и действия на основе функций кандидатов. Компонент 3420 расширения можно назвать сценарием установки в момент установки, для привязки функций кандидатов к прикладным программам. Если вход в новую функцию кандидата выполняется в регистре 3414 связей, возможно несколько вариантов, в зависимости от действия или отсутствия действия, предпринятого в отношении части целевой прикладной программы. Например, если целевая прикладная программа не установлена, тогда вход можно игнорировать. Если целевая прикладная программа установлена, но сконфигурирована так, что она не принимает расширения, тогда снова вход может быть проигнорирован. Однако, если целевая прикладная программа установлена и принимает функцию кандидата, тогда новое условие, действие или принадлежность связи создают для прикладной программы и связывают прикладные программы с использованием компонента 3420 расширения. В соответствии с этим в системе 3400 прикладная программа A 3430 содержит локальную функцию "ConditionFuncX", которую требуется сделать доступной для прикладной программы B 3440. Функция может быть сделана доступной для прикладной программы B 3440 путем добавления файла данных расширения (EDF). После этого функцию сохраняют в регистре 3410 экземпляра таким образом, что она становится доступной для прикладной программы B 3440. Например, ConditionFuncX может быть зарегистрирован в регистре 3412 определения, и функция кандидата может быть сохранена в регистре 3414 связи. Компонент 3420 расширения затем может считывать функцию кандидата из регистра 3414 связи, может создать условие Condition A путем связывания его с прикладной программой B 3440. В соответствии с этим связь 3450 представляет собой созданную связь Condition A с ConditionFuncX прикладной программы Application A.

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

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

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

Разработчики также могут создавать экземпляры предпочтений как в пределах, так и между прикладными программами, без явного вмешательства конечного пользователя. Для выполнения этой функции можно использовать несколько механизмов. Например, новую метку ADF можно добавить к классу предпочтения, что позволяет устанавливать предпочтения в ADF непосредственно во время определения прикладной программы. В качестве альтернативы новая метка EDF может быть добавлена к классу предпочтения. Это позволяет создавать экземпляры предпочтений как во время, так и после определения прикладной программы. Кроме того, создание экземпляра предпочтения может быть выполнено через сценарии (например, сценарии SQL) за пределами определения схемы, например, путем использования системы API.

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

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

Пример № 1 Композиция

Композиция может быть определена, когда новой прикладной программе дают указание связаться с существующей известной функцией. В этом примере вначале устанавливают ShellApp и после этого устанавливают Office. Во время инициализации Office разработчик знал о том, что разработанная прикладная программа Office будет управлять функцией условия FuncX прикладной программы ShellApp. Когда Office устанавливают, он регистрирует в регистре связей связь, которая связывает функцию условия FuncX (старая функция) с условием прикладной программы Office (новая прикладная программа). Сценарий установки прикладной программы Office затем вызывает компонент расширения, который считывает регистр связи. Компонент расширения может затем детектировать, присутствует ли это уже определенное ("встроенное") условие, и поэтому пропускает следующий этап, где он повторно оценивает состояние NotAvailable (Не доступен), действующее для всего экземпляра. При этом говорят, что прикладная программа Office должна быть расширена ShellApp.

Пример № 2 Расширение

Расширение может быть определено как, когда старую прикладную программу расширяют новой функцией. В этом примере так же, как указано выше, ShellApp уже установлена, и затем устанавливают Office. При инициализации Office разработчик создал функцию действия FuncY, которую можно использовать в прикладной программе ShellApp. Когда устанавливают Office, он регистрирует функцию действия в регистре определения и в регистре связи регистрирует связь, которая связывает прикладную программу FuncY Office (новая функция) с действием в ShellApp (старая прикладная программа). Сценарий прикладной программы Office вызывает компонент расширения для детектирования того, что присутствует новая связь, которая не имеет соответствующие действия в ShellApp и поэтому интернализовала действие путем создания его в ShellApp. Он затем повторно оценивает состояние NotAvailable (Не доступен) для всего экземпляра. При этом говорят, что ShellApp была расширена прикладной программой Office.

Пример № 3 Расширение с помощью перемычки

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

Пример № 4 Деинсталляция

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

Пример № 4 Повторная установка

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

Персонализированные папки

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

На фиг.35 показана персонализированная система 3500 в соответствии с аспектом настоящего изобретения. Система 35000 содержит накопитель 3550 данных и прикладную программу 300 информационного агента, содержащую персонализированную папку (папки) 3510 и предпочтения 3512. Персонализированная папка (папки) 3510 относится к папкам или контейнерам данных, которые могут включать или исключать элементы, основанные на условных выражениях, которые могут быть интуитивно определены конечными пользователями. В одном случае папка (папки) 3510 могут быть расположены иерархическим образом и могут быть выполнены с помощью компонента операционной системы. Однако следует отметить, что использование термина папка или контейнер данных не подразумевает какое-либо ограничение. Папка (папки) 3510 могут быть расширены до любой подборки связей, указателей или данных, определенных набором взаимозависимостей. Предпочтения 3512 информационного агента представляют возможность для не обладающего техническими навыками конечного пользователя комбинировать схематизированную логику и схематизированные данные (например, через накопитель 150 данных) для обеспечения разнообразных персонализированных прикладных программ и среды. В отличие от этого обычные предпочтения просто используют простые условия с интуитивными названиями, для которых предоставляются строчные константы. Предпочтения 3512 могут быть определены конечными пользователями, например, с использованием логики, которая понятна для них, например, в таком виде: в случае событий IF действия THEN, или в виде более специфичных для прикладной программы терминов: в случае события папки IF условия THEN включают/исключают действия. Кроме того, следует отметить, что предпочтения 3512 могут быть разработаны с помощью анализа на основе логического заключения, такого как, например, с использованием статистических моделей и/или байесовских моделей, для изучения предпочтений пользователя, на основе действий пользователя. Анализ на основе логического заключения, используемый здесь, относится к использованию процесса (процессов) логического заключения в отношении множества входных переменных, для получения выходной переменной (переменных), а именно предпочтений пользователя или входных данных пользователя в инструменте разработки предпочтений. Анализ может включать в одном аспекте использование статистической модели и/или байесовской модели, но не ограничивается этим. Кроме условий и действия, предпочтения содержат инициирующие механизмы, которые инициируют оценку предпочтения. В соответствии с одним аспектом предмета изобретения такие инициирующие механизмы могут включать ясно выраженное направление пользователя, запланированное по времени, и/или автоматическое добавление документа, удаление документа и/или изменение документа в папке. Также помимо этого следует понимать, что предпочтения 3512 могут быть сгруппированы для достижения наборов результатов, которые были бы слишком сложными для простого создания через простое выражение (например, включить/исключить определенные элементы из папок, скомбинировать результаты множества запросов). Также помимо этого следует отметить, что как отдельные, так и группы предпочтений 3512 могут быть задекларированы как физические объекты так, что пользователь может перетягивать и оставлять, вырезать и вставлять предпочтения в различных папках 3510. Папки 3510 могут содержать копии данных или простые указатели на данные, сохраненные в запоминающем устройстве (также называемые виртуальными папками). Сохраненные данные могут включать, без ограничений, документы текстового редактора, электронные таблицы данных, рисунки и музыку. Также помимо этого персонализированные папки 3510 могут иметь ассоциированные предпочтения 3512, которые относятся к элементам в множестве различных областей. Для поддержания такой функции могут быть введены заранее определенные константы. Более конкретно, заранее определенные константы из области одного элемента (например, MyGrandparent (родители моих родителей)) можно использовать как аргументы для условий из других областей (например, Photosfrom (MyGrandparent) фотографии из (родители моих родителей)). Комбинация заданных условий и констант обеспечивает для конечных пользователей простой, интуитивный способ соотносить различные области элементов. Конечно, константы, определяемые пользователем, также могут быть предоставлены для условий персонализированной папки. Простые условия могут быть логически выведены из схемы для области элемента. Например, условия EmailIsFrom () или SubjectContains () (электронная почта из () или предмет содержит ()) могут быть логически выведены из схемы электронной почты. Однако разработчик схемы может совершенно определенным образом указать как более разнообразный, так и более узкий набор полезных условий. Кроме того, следует также отметить, что новые условия могут быть добавлены к прикладной программе 300 (возможность расширения) и впоследствии могут использоваться конечными пользователями, определяющими новые предпочтения. По мере того как будут установлены новые схемы, становятся доступными новые возможности для персонализированных папок.

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

В полученных папках используют предпочтения для принятия решения, следует ли включить или исключить конкретные файлы из папки. Кроме того, следует отметить, что полученные папки могут представлять собой виртуальные папки, которые обеспечивают отображения или предоставляют указатели на файлы. Виртуальные папки действуют, как реальные папки для содержания данных, однако эти папки не существуют реально физически. Один пример использования полученной папки включает ситуацию, когда пользователь определяет папку для помещения в нее всей Джазовой музыки, прослушанной пользователем, по меньшей мере, три раза за последние две недели. Полученные папки также могут быть определены с помощью предпочтений для включения всех файлов определенного типа, но с определенными исключениями. Например, папка может быть определена так, что она будет включать все записи джазового музыканта Майлса Дэвиса, но будет исключать записи определенных песен (например, Human Nature and New Rumba). Кроме того, следует отметить, что предпочтения могут быть определены таким образом, что пользователь может перемещать и оставлять файлы в соответствующие папки и папки будут определять, имеют ли оставленные файлы определенный тип. Если файл имеет разрешенный тип, он может быть добавлен в папку, в противном случае такой файл может быть отклонен (например, не скопирован в папку), или в качестве альтернативы, пользователю может быть представлено указание в отношении того, должно ли быть создано расширение для этого конкретного файла.

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

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

Действия типа потока, основанные на активных папках

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

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

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

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

Папки хроник

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

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

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

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

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

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

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

На фиг.36 показана методология 3600, предназначенная для выполнения предпочтений, в соответствии с аспектом предмета изобретения. На этапе 3610 конечный пользователь указывает предпочтения на основе схемы разработчика (например, схема XML) и сохраняет их в виде таблиц, например, в накопителе данных. Затем на этапе 3620 одно или несколько событий могут быть приняты или детектированы. Предпочтения затем могут быть выполнены или оценены с использованием языка запросов (например, SQL), для запроса таблиц данных на этапе 3630. На этапе 3640 результирующая таблица может быть получена или заполнена с использованием условно действительных предпочтений. Наконец, на этапе 3650 соответствующие действия могут быть выполнены на основе результатов таблицы результатов.

На фиг.37 показана методология 3700, предназначенная для установки прикладных программ в соответствии с аспектом настоящего изобретения. На этапе 3710 базовые таблицы устанавливают в накопителе данных, связанном с системой или платформой, которая будет выполнять установленную прикладную программу (например, накопитель 150 данных системы информационного агента). Базовые таблицы затем обновляют с использованием данных прикладной программы на этапе 3720, вместо создания новых таблиц и баз данных непосредственно для установленной прикладной программы. На этапе 3730 процедуры прикладных программ сохраняют, например, как данные в базовой таблице, предназначенной для процедур прикладных программ. Для выполнения строки текста процедуры прикладной программы удаляют из базы данных и выполняют в соответствии с одним аспектом в режиме реального времени.

На фиг.38 представлена методология 3800 расширения прикладных программ в соответствии с аспектом настоящего изобретения. На этапе 3810 EDF принимают от разработчика. EDF содержит информацию, относящуюся к обеспечению возможности для классов предпочтения в одной прикладной программе ссылаться на условия, действия и события, определенные в других прикладных программах. После этого на этапе 3820 связи функции регистрируют в центральном месте, таком как, например, регистр. На этапе 3830 информацию о связях считывают или получают в компонентах расширения. Затем логика приемлемости может быть приложена к связям на этапе 3840. Когда EDF установлен, связи становятся доступными, однако они не применяются автоматически к прикладной программе в соответствии с одним аспектом предмета изобретения. Скорее, логику приемлемости применяют для определения, следует ли принять EDF. Логика приемлемости запрашивает, помимо прочего, аутентичность связей, ауторизацию и/или сертификацию у проверенного источника для определения, будет ли она принята. На этапе 3850 выполняют определение с помощью прикладной программы в отношении того, следует ли принять связь. Если "нет", тогда процесс просто заканчивается без образования связи. Если "да", тогда на этапе 3860 связь функции кандидата выполняют из первой прикладной программы во вторую прикладную программу.

На фиг.39 показана схема последовательности выполнения операций методологии 3900 деинсталляции прикладных программ в соответствии с аспектом настоящего изобретения. На этапе 3910 деинсталлируемая прикладная программа удаляет все свои записи из центрального места накопления. Центральное место накопления может представлять собой, например, регистр с регистрами определения и связей. Компоненты прикладной программы могут затем быть удалены на этапе 3920. Зависимые прикладные программы можно затем уведомить о деинсталлируемой прикладной программе (например, с помощью компонента расширения). Кроме того, и как отмечено выше, блоки методологии 3900 могут иметь любой порядок. В соответствии с этим другой аспект изобретения включает уведомления зависимых прикладных программ перед какими-либо процессами деинсталляции или удаления.

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

На фиг.41 представлена методология 4100 для персонализации компьютерных функций в соответствии с аспектом настоящего изобретения. На этапе 4110 конечный пользователь записывает предпочтения в соответствии с предоставленной схемой. Предпочтения могут быть в любой форме, но в соответствии с одним аспектом изобретения они содержат множество операторов IF-THEN, разделенных булевыми операторами. Схема может быть представлена разработчиком прикладной программы для ограничения и, таким образом, упрощения программирования конечного пользователя. На этапе 4120 предпочтение выполняют в случае появления события. Событие может представлять собой все, что случается, включая, без ограничений, изменения в данных папки или изменения курса акций. Выполнение или оценка предпочтения могут быть выполнены с использованием данных запроса в компоненте накопителя данных. На этапе 4120 предпринимают действие на основе условно действительного предпочтения.

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

Как показано на фиг.42, пример варианта выполнения 4210 для выполнения различных аспектов изобретения включает компьютер 4212. Компьютер 4212 включает процессорный блок 4214, системную память 4216 и системную шину 4218. Системная шина 4218 соединяет системные компоненты, включая, без ограничений, системную память 4216 с процессорным блоком 4214. Процессорный блок 4214 может представлять собой любой из различных доступных процессоров. Двойные микропроцессоры и другие многопроцессорные архитектуры также можно использовать в качестве процессорного блока 4214.

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

Системная память 4216 включает энергозависимую память 4220 и энергонезависимую память 4222. Базовая система входа-выхода (BIOS), содержащая базовые процедуры для передачи информации между элементами в компьютере 4212, например, во время включения компьютера, записана в энергонезависимой памяти 4222. В качестве иллюстрации, а не для ограничения, энергонезависимая память 4222 может включать постоянное запоминающее устройство (ПЗУ), программируемое ПЗУ (ППЗУ), электронно-программируемое ПЗУ (ЕППЗУ), электрически стираемое ПЗУ (СППЗУ) или память типа флэш. Энергозависимая память 4220 включает оперативное запоминающее устройство (ОЗУ), которое действует как память внешнего кэша. В качестве иллюстрации, а не для ограничения, ОЗУ доступно во множестве форм, таких как синхронное ОЗУ (SRAM), динамическое ОЗУ (DRAM), синхронное DRAM (SDRAM), SDRAM c двойной передачей данных (DDR SDRAM), улучшенное SDRAM (ESDRAM), Synchlink (SLDRAM) и прямая шина ОЗУ (DRRAM).

Компьютер 4212 также включает съемные/несъемные энергозависимые/энергонезависимые накопители компьютерных данных. На фиг.42 представлен, например, дисковый накопитель 4224. Дисковый накопитель 4124 включает, без ограничений, такие устройства: приводы магнитного диска, приводы гибкого диска, приводы на магнитной ленте, приводы типа Jaz, приводы типа Zip, привод типа LS-100, карту памяти типа флэш или memory stick. Кроме того, дисковый накопитель 4224 может включать носители данных отдельно или в комбинации с другими носителями данных, включая, без ограничений, привод оптического диска, такой как устройство компактного диска, предназначенного только для чтения (CD-ROM), записываемый привод CD (привод CD-R), перезаписываемый привод CD (привод CD-RW) или привод цифрового универсального диска, предназначенного только для чтения (DVD-ROM). Для улучшения соединения устройств 4224 дискового накопителя с системной шиной 4218 обычно используют съемный или несъемный интерфейс, такой как интерфейс 4226.

Следует понимать, что на фиг.42 представлены программные средства, которые действуют как посредники между пользователями и основными компьютерными ресурсами, описанными в соответствующей операционной среде 4210. Такие программные средства включают операционную систему 4228. Операционная система 4228, которая может быть сохранена на дисковом накопителе 4224, во время работы управляет и распределяет ресурсы компьютерной системы 4212. Системные прикладные программы 4230 используют преимущества управления ресурсами операционной системы 4228 через программные модули 4232 и программные данные 4234, сохраненные либо в системной памяти 4216, или на дисковом накопителе 4224. Следует понимать, что настоящее изобретение может быть выполнено с различными операционными системами или комбинациями операционных систем.

Пользователь вводит команды или информацию в компьютер 4212 через входное устройство (устройства) 4236. Входное устройство 4236 включают, без ограничений, устройство-указатель, такое как мышь, шаровой манипулятор, пишущее перо, сенсорную панель, клавиатуру, микрофон, джойстик, игровую панель, спутниковую антенну, сканер, карту телевизионного приемника, цифровую камеру, цифровую видеокамеру, вэб-камеру и т. п. Эти и другие входные устройства соединены с процессорным блоком 4214 через системную шину 4218, через порт (порты) 4238 интерфейса. Порт (порты) 4238 интерфейса включает, например, последовательный порт, параллельный порт, игровой порт и универсальную последовательную шину (USB). Выходное устройство (устройства) 4240 использует некоторые порты тех же типов, что и входное устройство (устройства) 4236. Таким образом, например, порт USB можно использовать как для обеспечения входа в компьютер 4212, так и для вывода информации из компьютера 4212 в выходное устройство 4240. Выходной адаптер 4242 предназначен для иллюстрации того, что присутствуют некоторые выходные устройства 4240, такие как мониторы, громкоговорители и принтеры, помимо других выходных устройств 4240, которые требуют использования специальных адаптеров. Выходные адаптеры 4242 включают в качестве иллюстрации, и не для ограничений, видеокарты и звуковые карты, которые обеспечивают средство связи между выходными устройствами 4240 и системной шиной 4218. Следует отметить, что другие устройства и/или системы устройств обеспечивают возможности как ввода, так и вывода данных, например, при использовании удаленного компьютера (компьютеров) 4244.

Компьютер 4212 может работать в сетевой среде, с использованием логических связей, с одним или несколькими удаленными компьютерами, такими как удаленный компьютер (компьютеры) 4244. Удаленный компьютер (компьютеры) 4244 может представлять собой персональный компьютер, сервер, маршрутизатор, сетевой ПК, рабочую станцию, бытовое устройство на основе микропроцессора, равноправное устройство или другой общий сетевой узел и т.п. и обычно включает множество или все элементы, описанные в отношении компьютера 4212. Для краткости описания в удаленном компьютере (компьютерах) 4244 представлено только запоминающее устройство 4246. Удаленный компьютер (компьютеры) 4244 логически соединен с компьютером 4212 через сетевой интерфейс 4248 и затем физически соединен через канал 4250 передачи данных. Сетевой интерфейс 4248 охватывает сети передачи данных, такие как локальные вычислительные сети (ЛВС, LAN) и глобальные сети (WAN, ГС). Технологии ЛВС включают интерфейс для передачи распределенных данных по оптоволоконным каналам (FDDI, ИПДО), распределенный интерфейс проводной передачи данных (CDDI, РИПП), сеть Ethernet/IEEE 1102.3, кольцевую компьютерную сеть с маркерным доступом/IEEE 1102.5 и т.п. Технологии WAN включают, без ограничений, связи от точки-к-точке, коммутируемые сети, такие как цифровая сеть с комплексными услугами (ISDN, ЦСКУ) и их вариации, сети с коммутацией пакетов, а также цифровые абонентские линии (DSL, ЦАЛ).

Канал (каналы) 4250 передачи данных относится к аппаратным средствам/программным средствам, используемым для соединения сетевого интерфейса 4248 с шиной 4218. Хотя канал 4250 передачи данных показан для иллюстрации соединений как находящийся внутри компьютера 4212, он также может быть расположен снаружи компьютера 4212. Аппаратные/программные средства, необходимые для соединения с сетевым интерфейсом 4248, включают, только в качестве примера, внутренние и внешние технологии, такие как модемы, включая обычные телефонные модемы, кабельные модемы и модемы DSL, адаптеры ISDN и карты Ethernet.

На фиг.43 схематично показана блок-схема среды 4300 расчета выборки, с которой может взаимодействовать настоящее изобретение. Система 4300 включает в себя один или несколько клиентов 4310. Клиент (клиенты) 4310 может представлять собой аппаратные и/или программные средства (например, потоки, процессы, компьютерные устройства). Система 4300 также включает в себя один или несколько серверов 4330. Сервер (серверы) 4330 может быть выполнен на основе аппаратных средств и/или на основе программного обеспечения (например, виде потоков, процессов, вычислительных устройств). В серверах 4330 могут быть установлены потоки для выполнения преобразований с использованием, например, настоящего изобретения. Один возможный канал передачи данных между клиентом 4310 и сервером 4330 может быть выполнен в форме передачи пакетных данных, адаптированных для передачи между двумя или более вычислительными процессами. Система 4300 включает структуру 4350 передачи данных, которую можно использовать для обеспечения передачи данных между клиентом (клиентами) 4310 и сервером (серверами) 4330. Клиент (клиенты) 4310 функционально соединен с одним или несколькими накопителями 4360 данных клиента, который можно использовать для сохранения информации, локально по отношению к клиенту (клиентам) 4310. Аналогично сервер (серверы) 4330 функционально соединен с одним или несколькими накопителями 4340 данных сервера, который можно использовать для сохранения информации локально на сервере 4330.

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

ПРИЛОЖЕНИЕ

Реферат

Предложение относится к средствам персонализации компьютерных систем. Техническим результатом является повышение производительности работы пользователя за счет обеспечения возможности совместного использования данных между компонентами прикладной программы и между прикладными программами. Конечным пользователям предоставляется инструмент для простого написания разнообразного текста и сложных предпочтений, например, с использованием множества простой логики высказываний IF-THEN. Предпочтения затем преобразуют в запросы и выполняют в отношении структурированных данных. Удовлетворяющие предпочтения затем выполняют действия, такие как представление уведомления или сохранение данных в конкретной папке. Кроме того, в соответствии с аспектом изобретения все данные, логика, события, помимо прочих, являются схематизированными. 5 н. и 18 з.п. ф-лы, 43 ил.

Формула