РАСШИРЯЕМАЯ СИСТЕМА ПОЛЬЗОВАТЕЛЬСКОГО КОНТЕКСТА ДЛЯ ДОСТАВКИ ИЗВЕЩЕНИЯ

Данная заявка связана с патентной заявкой США, номер в реестре патентного поверенного MSFT-1-20462, под названием "System and Method Utilizing Test Notifications" (Система и способ использования пробных извещений), поданной одновременно с данной заявкой, которая включена сюда посредством ссылки во всей полноте.

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

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

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

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

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

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

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

Раскрытие изобретения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Согласно фиг.1, иллюстративная система для реализации изобретения включает в себя вычислительное устройство общего назначения в виде традиционного персонального компьютера 20, включающего в себя процессор 21, системную память 22 и системную шину 23, которая подключает различные компоненты системы, в том числе системную память 22, к процессору 21. Системная шина 23 может относиться к любому из нескольких типов шинных структур, включая шину памяти или контроллер памяти, периферийную шину и локальную шину с использованием различных шинных архитектур. Системная память включает в себя постоянную память (ПЗУ) 24 и оперативную память (ОЗУ) 25. Базовая система 26 ввода/вывода (BIOS), содержащая основные процедуры, которые помогают переносить информацию между элементами персонального компьютера 20, например, при запуске, обычно хранятся в ПЗУ 24. Персональный компьютер 20 дополнительно включает в себя привод 27 жесткого диска, который считывает с или записывает на жесткий диск 39, привод 28 магнитного диска, который считывает с или записывает на сменный магнитный диск 29, и привод 30 оптического диска, который считывает с или записывает на сменный оптический диск 31, например, CD-ROM или другой оптический носитель. Привод 27 жесткого диска, привод 28 магнитного диска и привод 30 оптического диска подключены к системной шине 23 посредством интерфейса 32 привода жесткого диска, интерфейса 33 привода магнитного диска и интерфейса 34 привода оптического диска, соответственно. Приводы и соответствующие компьютерно-считываемые среды обеспечивают энергонезависимое хранение компьютерно-считываемых команд, структур данных, программных модулей и других данных для персонального компьютера 20. Хотя в описанной здесь иллюстративной среде используются жесткий диск 39, сменный магнитный диск 29 и сменный оптический диск 31, специалистам в данной области очевидно, что в иллюстративной рабочей среде можно также использовать другие компьютерно-считываемые среды других типов, в которых могут храниться данные, доступные компьютеру, например магнитные кассеты, карты флэш-памяти, цифровые универсальные диски, картриджи Бернулли, блоки ОЗУ, блоки ПЗУ и т.д.

На жестком диске 39, магнитном диске 29, оптическом диске 31, в ПЗУ 24 или ОЗУ 25 может храниться ряд программных модулей, в том числе операционная система 35, одна или несколько прикладных программ 36, другие программные модули 37 и программные данные 38. Пользователь может вводить команды и информацию в персональный компьютер 20 через устройства ввода, например, клавиатуру 40 и указательное устройство 42. Другие устройства ввода (не показаны) могут включать в себя микрофон, джойстик, игровую панель, спутниковую антенну, сканер и т.п. Эти и другие устройства ввода часто подключены к процессору 21 через интерфейс 46 последовательного порта, который подключен к системной шине 23, но также могут подключаться посредством других интерфейсов, например, параллельного порта, игрового порта или универсальной последовательной шины (USB). Дисплей в виде монитора 47 также подключен к системной шине 23 через интерфейс, например, видеокарту или адаптер 48. Один или несколько громкоговорителей 57 также могут быть подключены к системной шине 23 через интерфейс, например, аудио-адаптер 56. Помимо дисплея и громкоговорителей, персональные компьютеры обычно включают в себя другие периферийные устройства вывода (не показаны), например принтеры.

Персональный компьютер 20 может работать в сетевой среде с использованием логических соединений с одним или несколькими удаленными компьютерами, например удаленным компьютером 49. Удаленный компьютер 49 может представлять собой другой персональный компьютер, сервер, маршрутизатор, сетевой ПК, равноправное устройство или другой общий сетевой узел, и обычно включает в себя многие или все элементы, описанные выше применительно к персональному компьютеру 20. Логические соединения, описанные на фиг.1, включают в себя локальную сеть (ЛС) 51 и глобальную сеть (ГС) 52. Такие сетевые среды обычно применяются в учреждениях, компьютерных сетях в масштабе предприятия, интранетах и Интернете.

При использовании в сетевой среде ЛС, персональный компьютер 20 подключен к локальной сети 51 через сетевой интерфейс или адаптер 53. При использовании в сетевой среде ГС, персональный компьютер 20 обычно включает в себя модем 54 или другое средство установления связи в глобальной сети 52, например, Интернете. Модем 54, который может быть внутренним или внешним, подключен к системной шине 23 через интерфейс 46 пользовательского ввода. В сетевой среде, программные модули, описанные применительно к персональному компьютеру 20, или часть из них могут храниться в удаленном запоминающем устройстве. Очевидно, что показанные сетевые соединения являются иллюстративными и можно использовать другие средства установления линии связи между компьютерами.

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

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

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

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

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

На фиг.2 показана логическая блок-схема процедуры 200 обработки извещения согласно настоящему изобретению. На блоке 202, операционная система или произвольная программа вызывает программный интерфейс приложения (API) извещения. На блоке 204, элементы извещения оцениваются по отношению к пользовательским контекстам, заданным операционной системой и произвольными программами, далее одобренным или измененным пользователем, и по отношению к пользовательским правилам, заданным пользователем. На блоке 206, извещение доставляется, отсрочивается, отклоняется, маршрутизируется или иначе обрабатывается в соответствии с пользовательскими контекстами и пользовательскими правилами.

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

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

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

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

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

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

На фиг.4 показана логическая блок-схема 230 процедуры оценивания контекста как истинного или ложного во время вызова API извещения. На блоке 232 принятия решения, производится определение, нужно ли оценивать пользовательские контексты во время вызова API извещения. Если пользовательские контексты нужно оценивать, то процедура переходит к блоку 234. Если пользовательские контексты не нужно оценивать во время вызова API извещения, то процедура заканчивается. На блоке 234, пользовательские контексты оцениваются как истинные или ложные.

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

На фиг.5 показана логическая блок-схема 240 процедуры, посредством которой пользователь может регулировать контексты и создавать новые правила. На блоке 242, производится определение, желает ли пользователь регулировать контексты. Если пользователь не желает регулировать контексты, то процедура переходит к блоку 246 принятия решения, который будет более подробно описан ниже. Если пользователь желает регулировать контекст, то процедура переходит к блоку 244, где пользователь вносит изменения в контексты.

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

Согласно фиг.5, на блоке 246 принятия решения, производится определение, желает ли пользователь создать новые пользовательские правила. Если пользователь не желает создавать новые пользовательские правила, то процедура переходит к блоку 250 принятия решения, который будет более подробно описан ниже. Если пользователь желает создать новые пользовательские правила, то процедура переходит к блоку 248, где создаются новые правила. В общем случае, пользовательские правила указывают, как следует обрабатывать извещения, содержащие указанные элементы. Например, правило может предписывать, что извещения от указанного лица всегда должны доставляться немедленно, и это правило может применяться ко всем извещениям, независимо от того, какая программа инициировала извещение, если оно от указанного лица. В качестве более конкретных примеров, другие пользовательские правила могут относиться, например, к «уведомлениям о трафике MSN auto для Бремертона, Вашингтон» и «важным отправлениям электронной почты от Джона Доу». Например, пользовательское правило для важных отправлений электронной почты от Джона Доу может предписывать, что любые отправления электронной почты, поступающие от Джона Доу, со словом «срочно» в тексте и с пометкой «высокий приоритет», должны подчиняться указанным условиям обработки. Условия обработки могут указывать, что извещение следует доставлять немедленно, и что у пользователя нужно потребовать подтвердить получение. В общем случае, требование к пользователю подтвердить получение извещения означает небольшой подъем агрессивности извещения, т.е. извещение будет оставаться на экране, пока пользователь специально не уберет его. В одном варианте осуществления, требование у пользователя подтверждения получения можно задать только через пользовательское правило. В другом примере, правила также могут задавать воспроизведение специфического звука для извещения, с указанной громкостью, чтобы уведомить пользователя о поступлении особого извещения. Можно также выбирать разные настройки относительно того, как следует обрабатывать извещение при «нормальном» и «занятом» условиях для пользователя, которые можно определить из контекста пользователя. Инструкции обработки также могут включать в себя, например, варианты маршрутизации извещения, например, «доставлять извещения от Джона Доу на мой пейджер». В одном варианте осуществления, при оценивании контекста, наиболее ограничительный истинный в данный момент контекст - это тот, который применяется. При оценивании пользовательских правил это значит, что конкретное извещение отвечает правилу, созданному пользователем, и в этом случае наиболее агрессивная настройка применяется из пользовательских правил, которые отвечают извещению. Другими словами, в пользовательских правилах пользователь задал что-то важное, и эта процедура призвана отвечать предпочтениям пользователя. В случае конфликта между двумя правилами применяется наиболее агрессивное.

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

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

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

На фиг.6 показана логическая блок-схема 300 процедуры обработки извещения в соответствии с пользовательскими контекстами и пользовательскими правилами. На блоке 302, операционная система или произвольная программа вызывает API извещения. На блоке 304 принятия решения, производится определение, следует ли записать извещение в историю извещений. Если извещение следует записать, то процедура переходит к блоку 306, где извещение записывается в историю. Если извещение не следует записывать, то процедура переходит к блоку 310 принятия решения.

На блоке 310 принятия решения, производится определение, согласуется ли извещение с какими-либо пользовательскими правилами. Если извещение согласуется с какими-либо пользовательскими правилами, то процедура переходит к блоку 312, где выполняются пользовательские правила (на основании содержимого извещения плюс пользовательские контексты), и процедура переходит к точке А, обозначающей переход к фиг.7. Если на блоке 310 принятия решения выясняется, что извещение не согласуется ни с какими пользовательскими правилами, то процедура переходит к блоку 320 принятия решения.

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

Согласно фиг.6, на блоке 320 принятия решения, производится определение, можно ли отображать извещение в данное время (только на основании пользовательского контекста). Если извещение можно отображать в данное время, то процедура переходит к блоку 322, где извещение отображается, и обеспечивается соответствующий звук и громкость. Если не следует отображать извещение в данное время, то процедура переходит к блоку 330 принятия решения.

На блоке 330 принятия решения, производится определение, истек ли срок действия извещения. Если срок действия извещения истек, то процедура переходит к блоку 332, где извещение уничтожается. Если срок действия извещения не истек, то процедура переходит к блоку 334, где извещение отсрочивается, и процедура переходит к точке В, которая обозначает переход к фиг.7.

На фиг.7 показана логическая блок-схема процедуры 350 обработки извещения в соответствии с указанными пользовательскими правилами. Процедура продолжается от точки А на фиг.6, как описано выше. Согласно фиг.7, на блоке 352 принятия решения, производится определение, следует ли маршрутизировать извещение. Если извещение не следует маршрутизировать, то процедура переходит к блоку 362 принятия решения, который будет более подробно описан ниже. Если извещение следует маршрутизировать, то процедура переходит к блоку 354, где извещение маршрутизируется указанным образом. Когда извещение маршрутизируется, это свидетельствует о том, что извещение содержит элементы, которые согласуются с правилами пользователя, которые требуют пересылки извещения в другую систему. Это может произойти, если пользователь занят, или это может происходить для каждого извещения, которое отвечает критериям, указанным в правилах пользователя, является ли пользователь недоступным. Например, извещение со словом «срочно» всегда должно пересылаться на пейджер пользователя, тогда как другие извещения могут маршрутизироваться только на основании комбинации правил и контекста пользователя.

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

Согласно фиг.7, на блоке 362 принятия решения, производится определение, следует ли отклонить извещение. Если извещение не следует отклонять, то процедура переходит к блоку 366 принятия решения, который будет более подробно описан ниже. Если извещение следует отклонить, то процедура переходит к блоку 364, где извещение уничтожается и не наблюдается пользователем. Другими словами, отклоненному извещению не разрешается воспроизводиться или производить звук. Например, это может произойти на основании пользовательского правила, которое утверждает, что определенное извещение следует отклонить, или, как описано выше со ссылкой на блок 332 фиг.6, по истечении срока действия извещения.

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

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

На фиг.8 показана логическая блок-схема процедуры 380 отсрочивания доставки извещения. Процедура продолжается от точки В от любой из фиг. 6 или 7, которые описаны выше. Согласно фиг.8, на блоке 382, извещение удерживается. На блоке 384, система отслеживает изменения, касающиеся истинности или ложности объявленных контекстов, или пользовательского правила, указывающего, что доставить извещение нужно сейчас. На блоке 386 принятия решения, производится определение, изменился ли пользовательский контекст, или предписывает ли пользовательское правило доставить извещение сейчас. Если пользовательский контекст не изменился, и если ни одно пользовательское правило не предписывает обратного, то процедура возвращается к блоку 382, где извещение продолжает удерживаться. Если пользовательский контекст изменился, или если пользовательское правило указывает, что сейчас может быть уместно доставить извещение, то процедура переходит к точке С, которая обозначает переход к фиг.6. От точки С на фиг.6 происходит возврат к блоку 304 принятия решения, где начинается процесс оценивания извещения.

На фиг.9 показана блок-схема процедуры 400 определения отображения извещения в соответствии с различными ограничениями. Очевидно, что эта процедура может быть реализована как часть обработки извещений, например, на блоке 322 фиг.6 или блоке 372 фиг.7. В общем случае, когда извещение поступает в систему, производится оценивание всех контекстов, которые истинны в данный момент, и наиболее ограничительные настройки для извещения применяются в соответствии с текущим состоянием пользователя. Согласно фиг.9, на блоке 402 принятия решения, производится определение, следует ли вообще отображать извещение. Если извещение не следует отображать вовсе, то процедура переходит к блоку 404, где задается не отображать извещение ни на каком дисплее. Если извещение нужно отобразить, то процедура переходит к блоку 406 принятия решения.

На блоке 406 принятия решения, производится определение, следует ли отображать извещение, но только внешне. Если извещение следует отображать только внешне, то процедура переходит к блоку 408, где извещение отображается, но только на дисплеях внешнего оборудования. Если извещение не следует отображать на дисплеях внешнего оборудования, то процедура переходит к блоку 410 принятия решения.

На блоке 410 принятия решения, производится определение, следует ли отображать извещение на текущем дисплее. Если извещение следует отображать на текущем дисплее, то процедура переходит к блоку 412, где извещение отображается в соответствии с надлежащим уровнем агрессивности на текущем дисплее. Если извещение не следует отображать на текущем дисплее, то процедура заканчивается.

На фиг.10 показана логическая блок-схема 402 процедуры определения громкости воспроизведения звука извещения в соответствии с различными ограничениями. Как было описано выше в связи с фиг.9, очевидно, что процедура может быть реализована как часть обработки извещений, например, на блоке 322 фиг.6 или блоке 372 фиг.7. Когда извещение поступает в систему, производится оценивание всех контекстов, которые истинны в данный момент, и наиболее ограничительные настройки для извещения применяются в соответствии с текущим состоянием пользователя. Согласно фиг.10, на блоке 422 принятия решения, производится определение, следует ли заглушать извещение. Если извещение следует заглушать, то процедура переходит к блоку 424, для извещения не обеспечивается никакой громкости. Если извещение не следует заглушать, то процедура переходит к блоку 426 принятия решения.

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

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

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

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