УПРАВЛЕНИЕ РАСШИРЕННЫМИ СОВОКУПНОСТЯМИ ПРИСУТСТВИЯ
MANAGING EXTENDED COLLECTIONS OF PRESENCE

Предшествующий уровень техники
Серверы присутствия все чаще используются для предоставления статуса доступности пользователя. Информация о присутствии пользователя определяет текущее состояние присутствия пользователя. Пользователи могут сделать доступной свою информацию о присутствии, чтобы другие пользователи могли решить, как лучше связаться с ними. Например, в информации о присутствии указывать, вошел ли пользователь в систему («подключен») или вышел («отключен»). Возможно обеспечить более детальную информацию о доступности пользователя. Например, даже если пользователь подключен, он может отойти от компьютера на встречу. В таком случае состояние присутствия может указывать «подключен» и «на встрече».
В контексте обмена мгновенными сообщениями публикующий («публикатор») пользователь может предоставлять информацию о присутствии службе присутствия, которая затем предоставляет подписанным пользователям («подписчикам»). Таким образом, служба присутствия использует модель подписчик-публикатор для предоставления своим подписанным и публикующим пользователям информации о присутствии службы присутствия. Как только информация о присутствии пользователя меняется, служба присутствия уведомляется об изменении компьютерной системой этого пользователя и в свою очередь уведомляет подписанных пользователей об изменении. Подписанный пользователь затем решает, как лучше связаться с публикующим пользователем на основании информации о присутствии обозначенных участников. Например, статус присутствия указывает, что публикующий пользователь находится на телефонной конференции, тогда подписанный пользователь может решить послать мгновенное сообщение вместо того, чтоб сделать телефонный звонок публикующему пользователю. Если же подписанному пользователю все же необходимо позвонить и поговорить с публикующим пользователем, подписанный пользователь может отслеживать информацию о присутствии публикующего пользователя, чтобы определить, когда может быть совершен звонок. Когда подписанный пользователь замечает, что информация о присутствии публикующего пользователя указывает, что телефонная конференция закончена, подписанный пользователь может совершить телефонный звонок.
Отдельный пользователь может также публиковать информацию о присутствии с нескольких устройств. Например, пользователь может быть подключен к службе присутствия с портативного компьютера, настольного компьютера и с мобильного телефона одновременно. Статус присутствия может показывать статус пользователя на каждом устройстве. Это особенно полезно, если, например, пользователь пошел на встречу, имея при себе мобильный телефон, то есть отошел от своего настольного компьютера. Если подписанный пользователь захочет связаться с публикующим пользователем, информация в присутствии может указать, что звонок на сотовый телефон будет более эффективным способом связи, чем мгновенное сообщение, посланное на настольный компьютер. Каждое из устройств пользователя может также подписаться на получение информации о присутствии других пользовательских устройств для обеспечения возможности, например, определить для устройств, на каком из устройств публикующий пользователь наиболее активен.
Из-за роста популярности систем мгновенных сообщений и других систем связи в реальном времени службам присутствия необходимо поддерживать растущее число пользователей. Кроме того, таким системам необходимо поддерживать усложняющиеся определения информации о присутствии. Например, информация о присутствии может включать в себя календарную информацию, которая определяет доступность публикатора в ближайшие несколько месяцев. Как результат, сервер присутствия должен эффективно обрабатывать такую информацию эффективным способом. К сожалению, существующие модели присутствия требуют значительных вычислений при обновлении информации о присутствии. Таким образом, чем больше публикаторов и подписчиков добавляется, тем больше необходимо серверов присутствия, чтобы осуществить необходимые вычисления.
Прежде системы присутствия обрабатывали публикуемую информацию о присутствии в одном XML документе. Когда часть пользовательского статуса изменялась, публикатор должен был указать строку в документе и заменить ее новой информацией о присутствии либо указать узел в поддереве документа XML и заменить все поддерево документа XML. Для обновления таким требовалось выполнять вычислительно дорогой анализ документа XML. С увеличением количества пользователей и обновлений присутствия бремя анализа XML на сервере присутствия может стать непомерным. Эта модель публикации информации о присутствии не позволяет подписчику подписываться только на часть документа присутствия. Также отдельным частям документа не назначаются версии, так чтобы подписчику или серверу можно было легко определить, какая часть документа была недавно изменена. Эта модель также не позволяет раскрывать различным подписчикам различные версии документа присутствия или определять различную информацию авторизации для различных частей документа.
Более эффективна система присутствия, которая вычислительно менее дорога, описана в родственной заявке US № 11/190,503 (Номер патентного поверенного 41826-8225US), которая называется «Организация информации присутствия в совокупности публикаций», поданной 26 июля 2005 года, которая включена сюда в полном объеме в качестве ссылки. Родственная заявка раскрывает способ и систему управления информацией о присутствии, которая основана на совокупностях публикаций. Система совокупностей присутствия создает совокупности публикаций для публикатора. Публикация включает в себя тип и значение и может быть дополнена атрибутами, например, когда истечет срок действия такой публикации. Так публикация, имеющая тип «статус» и значение «подключен» может указывать подписанным пользователям, что публикующий пользователь в настоящий момент подключен. Публикатор может определить одну совокупность публикаций, которые должны быть доступны конкретным подписчикам, и другую совокупность публикаций, которая будет доступна другим подписчикам. Например, одна совокупность публикаций может быть видна всем, в то время как другая будет видна только коллегам публикующего пользователя. Каждая совокупность содержит список пользователей, которым разрешено подписываться на информацию из совокупности. Система совокупностей присутствия может позволять публикатору обновлять отдельные публикации в наборе. После получения обновления сервер присутствия может быстро обновить статус присутствия, не полагаясь на вычислительно дорогой анализ документов XML. Каждая совокупность публикаций может также содержать категории информации. Категория - это такой тип публикации, который захватывает несколько совокупностей. Например, категория «статус» может содержать публикации со значением «недоступен» в совокупности, которая доступна всем, и публикация со значением «на встрече с Джоном» в совокупности, доступной коллегам. Публикации могут также определять идентификатор экземпляра. Идентификатор экземпляра разграничивает одинаковые части информации в одной совокупности. Например, пользователь может разместить публикацию «статус» с экземпляром «ноутбук», который указывает статус пользователя на его ноутбуке, а в другой публикации «статус» с экземпляром «сотовый телефон», который указывает, что пользователь на сотовом телефоне.
Хотя система совокупностей присутствия является улучшением предшествующих методик, она может создать дополнительное бремя для ресурсов сети и сервера присутствия. Например, публикующий пользователь, посылающий раздельные обновления нескольким экземплярам публикаций в нескольких совокупностях сервера присутствий, создает большое количество сетевого трафика к серверу присутствия. Аналогично подписанный пользователь, получающий раздельные уведомления для каждой публикации, которая была обновлена, создает большое количество сетевого трафика от сервера присутствия до устройства или устройств, с которых подписанный пользователь подключился. Как правило, действие публикации присутствия истекает по прошествии определенного времени, и публикация должна периодически обновляться публикующим пользователем с целью поддержания публикаций опубликованными. Потребность обновлять несколько публикаций, которые не изменялись, создает ненужное бремя для сервера. В заключение, добавление совокупностей с различными степенями доступной детализации для разных подписанных пользователей создает возможность раскрывать информацию присутствия широким группам подписчиков. Список пользователей с доступом к совокупности может значительно вырасти, а вычислительная стоимость проверки, на какую совокупность должен быть подписан отдельный подписчик, только увеличивается с ростом списка, вызывая дополнительное бремя для сервера присутствия.
Сущность изобретения
Предоставлены система и способ увеличения вычислительной и сетевой эффективности серверов присутствия, которые содержат совокупности публикаций. Система присутствия использует несколько методик, которые позволяют серверу присутствия предоставлять расширенную информацию присутствия, не требуя при этом дорогостоящих вычислений. Во-первых, система присутствия принимает пакетные изменения публикаций в одном запросе обновления присутствия. Также система присутствия принимает пакетные запросы подписки. Далее система присутствия поддерживает типы истечения срока действия запроса обновления публикации, которые исключают необходимость публикующему пользователю постоянно обновлять информацию о присутствии, которая не изменилась. В заключение, система присутствия принимает списки доступа, которые содержат членские группы, а не списки индивидуальных пользователей, которым необходим доступ к конкретной совокупности присутствия. Этот раздел предоставлен для представления набора концепций в упрощенной форме, которые далее описаны в детальном описании. Этот раздел не предназначен для определения всех ключевых признаков или существенных признаков предмета изобретения, так же как не следует рассматривать его как ограничение области применения.
Перечень фигур чертежей
Фиг.1 изображает блок-схему компонентов системы присутствия в одном варианте осуществления.
Фиг.2 изображает листинг протокола, который изображает расширение SIP и для посылки обновлений публикаций в одном варианте осуществления.
Фиг.3 иллюстрирует блок-схему последовательности операций обработки компонента обновления публикаций системы присутствия в одном варианте осуществления.
Фиг.4 - листинг протокола, изображающий расширения протокола SIP для посылки запросов подписки в одном варианте осуществления.
Фиг.5 - блок-схема, изображающая обработку компонентов обновления подписки системы присутствия в одном варианте осуществления.
Фиг.6 - листинг протокола, изображающий расширения протокола SIP для обновления членства в совокупности в одном варианте осуществления.
Фиг.7 - блок-схема обработки компонента обновления членства системы присутствия в одном варианте осуществления.
Фиг.8 - блок-схема обработки компонента истекших публикаций в одном варианте осуществления.
Подробное описание изобретения
Предоставлены способ и система для увеличения вычислительной и сетевой эффективности серверов присутствия, имеющих совокупности публикаций. Система присутствия использует несколько методик, которые позволяют серверу присутствия предоставлять расширенную информацию присутствия, не требуя дорогостоящей обработки. Во-первых, система присутствия принимает пакеты обновлений публикаций в одном запросе обновления присутствия. Например, публикующий пользователь может публиковать несколько категорий информации в нескольких совокупностях, посылая один запрос обновления серверу присутствия. Также система присутствия в одном запросе обновления, принимает пакеты запросов подписки. Например, подписанный пользователь может запросить подписку на несколько категорий информации в нескольких совокупностях, посылая один запрос на сервер присутствия. Далее, система присутствия поддерживает новые типы истечения срока действия запроса обновления публикации, которые исключают необходимость постоянно обновлять информацию присутствия, которая не изменилась. Например, если номер домашнего телефона публикующего пользователя редко изменяется, система позволяет пользователю опубликовать эту информацию однажды и не обновлять ее до следующего изменения, а не обновлять ее раз в час. Наконец, система присутствия принимает списки доступа, которые содержат членские группы вместо списков индивидуальных пользователей, которым необходим доступ к конкретной совокупности присутствия. Например, публикующий пользователь может предоставить доступ всем своим коллегам, применив членскую группу к совокупности, без перечисления каждого коллеги отдельно.
Пакетирование публикаций
В одном варианте осуществления система присутствия принимает несколько публикаций присутствия в одном запросе. Публикации могут охватывать разные категории, экземпляры и совокупности. Например, публикующий пользователь, обладающий категориями «статус» и «местоположение» может опубликовать статус «недоступен» и местоположение «штаб-квартира Microsoft» в той совокупности, которая публично доступна, и статус «на встрече с Джоном» и местоположение «Строение 40/Переговорная 5» в совокупности, доступной для коллег. Публикующий пользователь также может опубликовать несколько экземпляров одной и той же информации в каждой совокупности. Например, категория «номер телефона» может иметь экземпляр «домашний» для домашнего номера, «рабочий» для рабочего номера телефона и «мобильный» для номера сотового телефона. Пользователь может публиковать значения для каждого из экземпляров в одном запросе публикации.
В одном варианте осуществления система присутствия принимает публикации и снятие публикаций в одном запросе. Например, публикующий пользователь, направляющийся на встречу, может выйти из системы на своем настольном компьютере, тем самым сняв все экземпляры публикаций, связанные с настольным компьютером, пользователь может стать активным на сотовом телефоне, вызывая необходимость добавления новых экземпляров для сотового телефона. Система присутствия может принимать как снятие публикаций настоящего компьютера, так и публикации сотового телефона в одном запросе. Например, служба присутствия корпоративной сети предприятия способна принимать обновления публикаций от обоих устройств и перенаправлять обновления в глобальную службу присутствия в одном запросе.
В одном варианте осуществления система присутствия посылает несколько обновлений присутствия, используя расширения Протокола Инициирования Сессии (SIP) и протокола SIP для Мгновенных Сообщений и Усиленных Расширений Присутствия (SIMPLE). SIP - это управляющий протокол прикладного уровня, который используется устройствами для обнаружения друг друга, а также для установления, модификации и завершения сессий между устройствами, и является стандартом Интернет, описанным в «RFC 3261». Спецификация RFC 3261, доступная в Интернет по адресу www.ietf.org/rfc/rfc3261.txt, включена в данное описание в полной мере посредством ссылки. Стандарт SIP позволяет разработчику добавлять расширения для определения стандартных режимов работы. Система присутствия добавляет тэг <publish>, который содержит список тэгов <publication>, определяющих информацию присутствия для публикации и подобный тэг <unpublish>, содержащий список тэгов <publication>, определяющих информацию присутствия для снятия с публикации. Каждая публикация указывает категорию, экземпляр и совокупность, к которой они имеют отношение. В некоторых вариантах осуществления система присутствия принимает нулевое значение срока действия для публикаций внутри тэга <publish> как указание снятия с публикации, вместо заведения отдельного тэга <unpublish>.
В одном варианте осуществления система присутствия принимает обновления для нескольких публикующих пользователей в одном запросе. Например, когда используется протокол SIP, каждая публикация может содержать URI пользователя, которому соответствует данная публикация. Это позволит службам публиковать информацию от имени большого количества пользователей. Например, почтовый сервер Exchange может публиковать информацию календаря для всех пользователей, использующих этот сервер. Как другой пример, с помощью сотовой несущей можно опубликовать информацию о местоположении владельцев сотовых телефонов на сервере присутствия. В обоих случаях информация, которая раньше создала бы огромный сетевой трафик, может быть опубликована для большего количества пользователей в одном запросе на сервер присутствия.
В одном варианте осуществления система присутствия принимает запросы публикаций, которые имеют различные атрибуты в одном запросе. Публикующий пользователь может задавать разные политики истечения для публикации в одной совокупности и для публикации в другой совокупности. Например, в совокупности с детальной информацией о публикации «местоположение» детальная информация о статусе (т.е. «в переговорной 2») может часто изменяться и иметь более короткий срок истечения, чем менее детальная информация в другой совокупности (т.е. «в Сиэтле»). Как другой пример, публикующий пользователь может задать иную политику уведомления для одного типа публикаций, чем для других типов в одном запросе. Например, политика уведомления может указывать, что обновления в определенных категориях не должны вызывать какие-либо уведомления вообще.
Пакетирование подписок
В одном варианте осуществления система присутствия принимает подписки от подписанного пользователя на несколько категорий в одном запросе. Например, подписанный пользователь, который заинтересован в статусе и местоположении публикующего пользователя, может составить один запрос, который содержит в списке категорий «статус» и «местоположение».
В одном варианте осуществления система присутствия принимает подписки от подписанного пользователя на несколько публикующих пользователей в одном запросе. Например, подписанный пользователь может подписаться на несколько категорий пользователя A и пользователя B в одном запросе. Когда подписанный пользователь подписывается на информацию присутствия каждого пользователя из своего списка контактов, то это может вызвать существенную экономию ресурсов, поскольку все подписки могут быть сделаны в одном запросе. Подобным образом система присутствия может также принимать различные списки категорий для разных пользователей в одном запросе. Например, подписанный пользователь может подписаться на категории 1 и 2 для пользователя A и на категории 3 и 4 для пользователя B в одном запросе.
В одном варианте осуществления система присутствия позволяет запросу подписки извлекать информацию присутствия без создания подписки. Например, пользователь может захотеть единовременно запросить информацию присутствия публикующего пользователя без получения уведомлений при изменении информации. Пользователь может посылать запрос на подписку с указанием, что запрашивается текущее значение информации присутствия в заданных категориях, но не запрашивается постоянная подписка.
В одном варианте осуществления система присутствия принимает удаление существующих подписок в том же запросе, что и добавление новых подписок. Например, подписанный пользователь не желает более получать информацию о местоположении публикующего пользователя, но также хочет отслеживать текущий номер телефона публикующего пользователя, подписанный пользователь может составить один запрос, который содержит категорию «статус» в списке категорий для снятия подписки, и категорию «номер телефона» в списке категорий для подписки.
В одном варианте осуществления система присутствия принимает запросы от имени нескольких подписанных пользователей в одном запросе. Например, предприятие может иметь локальный сервер присутствия, который принимает отдельные запросы подписки от разных подписанных пользователей на предприятии и перенаправляет запросы в глобальный сервер присутствия как один пакетный запрос подписки.
В одном варианте осуществления система присутствия посылает несколько подписок присутствия, используя расширения протоколов SIP и SIMPLE. Система присутствия добавляет тэг <batchSub>, который содержит тэг <caategoryList>, который задает список категорий подписки. Тэг <batchSub> может также задавать тэг <adhocList>, в котором задан список нескольких пользователей, на категории которых производится подписка. Система присутствия также добавляет тэг <batchUnsub>, который также содержит тэги, которые задают список пользователей и их категорий, подписку на которые необходимо снять. Система также может позволять запрос подписки с пустым телом, которые указывают, что со всех пользователей и категорий нужно снять подписку вместо требования от подписанного пользователя указывать список категорий и пользователей, на которые он имел подписку.
В одном варианте осуществления система присутствия отфильтровывает нетребуемую информацию присутствия для подписанного пользователя, требуя явной подписки на каждую категорию, в которой заинтересован подписанный пользователь. Например, публикующий пользователь может публиковать сотни категорий информации, но подписанный пользователь может желать знать только текущий статус публикующего пользователя. Подписанный пользователь может послать запрос подписки на категорию «статус» и будет получать уведомления только для этой категории. Это предотвращает подписанного пользователя от заваливания уведомлениями, в которых пользователь не заинтересован, поскольку количество информации, предоставляемой сервером присутствия, растет.
Модель истечения
В одном варианте осуществления система присутствия принимает публикации, которые истекают, когда публикующее устройство отключается от сервера присутствия. В предыдущих системах публикующий пользователь публиковал информацию на заданный период (например, на час) и должен был обновить либо перепубликовать информацию до истечения публикации, чтобы поддержать информацию опубликованной. Система присутствия определяет новый тип истечения, который поддерживает информацию присутствия опубликованной до тех пор, пока устройство, опубликовавшее информацию, не отключится. Это можно использовать, когда устройство, такое как сотовый телефон, опубликовало экземпляры информации, имеющей силу, только пока сотовый телефон подключен. Когда сотовый телефон выключен либо отключается другим способом, сервер системы может определить это и удалить информацию, которая имела силу, пока устройство было подключено. Когда устройство подключено, более нет необходимости постоянно обновлять информацию присутствия, которая изменилась, чтобы уберечь ее от истечения.
В одном варианте осуществления система присутствия принимает публикации, которые истекают, когда публикующий пользователь более не подключен. Такой тип истечения полезен для информации присутствия, применимой к нескольким устройствам так долго, пока пользователь подключен, и более не важна, когда пользователь отключен. Система присутствия может определять, что пользователь отключен, когда пользователь более не подключен к системе ни через какое из устройств. Система присутствия может определить, что пользователь более не подключен через устройство, когда устройство соединяется от сервера присутствия либо когда устройство сообщает серверу присутствия, что пользователь более не использует это устройство. Например, общественный Интернет-терминал может позволить пользователю получить доступ к Интернету путем вставки аппаратного ключа USB, идентифицирующего пользователя. Когда аппаратный ключ извлечен, Интернет-терминал может сообщить любой службе, к которой был подключен пользователь, такой как служба присутствия, что пользователь более не использует это устройство. Пока пользователь подключен, информация остается опубликованной без запросов на обновление со стороны пользователя, что позволяет уберечь сервер присутствия от обработки дополнительных запросов обновления.
В одном варианте осуществления система присутствия принимает публикации, которые не истекают. Такой тип истечения, называемый static, полезен для информации, которая важна независимо от того, подключен пользователь к системе или нет, такой как пользовательский номер телефона или адрес. Этот тип истечения также используется службами, которые публикуют информацию от имени пользователя. Например, сервер Exchange, который публикует информацию календаря для нескольких пользователей, не должен знать, подключен пользователь либо нет, перед публикацией информации календаря, и информация не должна истечь независимо от статуса подключения пользователя. Таким образом, подобные службы могут публиковать информацию, указывая тип истечения static для публикации, и опубликованная информация не может быть снята, пока сервер присутствия не получит явный запрос снятия публикации.
Членские группы
В одном варианте осуществления система присутствия принимает списки членства совокупности, которые содержат группы пользователей. Прежде пользователи, которые имели доступ к отдельным совокупностям информации присутствия, были явно перечислены и совокупность по умолчанию содержала информацию присутствия, которая применялась к пользователям вне списков. Система присутствия допускает задание групп пользователей, что уменьшает вычислительные трудности определения пользователей, имеющих доступ к совокупности, для больших групп пользователей. Списки членства совокупности могут быть заданы, когда информация присутствия публикуется, либо они могут быть заданы независимо по отдельному запросу. Один тип членской группы, «список контактов», задает, что любой подписанный пользователь в списке контактов публикующего пользователя может просматривать информацию в совокупности, которой назначена группа.
В одном варианте осуществления система присутствия принимает членскую группу, которая содержит пользователей в одном предприятии как публикующих пользователей. Такая членская группа позволяет одной записи в членском списке пользовательской совокупности задавать, что каждый подписанный пользователь из того же предприятия должен иметь доступ к отдельной совокупности. Например, для большой корпорации, такой как Майкрософт, это позволит создать совокупность с дополнительной детальной информацией для сотрудников, которая содержит одну запись в членском списке, который задает членство в группе «та же компания». Сервер присутствия определяет, имеет ли подписанный пользователь доступ к совокупности, проверкой того, является ли предприятие пользователя тем же, что и у публикующего пользователя, например, запрашивая внешний контроллер данных. Это позволяет избежать серверу присутствия репликации того же списка пользователей, который уже содержит контроллер домена.
В одном варианте осуществления система присутствия принимает членские группы, содержащие пользователей из публичного облака. Публичное облако определяется как доступный извне список пользователей, предоставленный другой организацией. Членская группа публичного облака полезна, когда один оператор сервера присутствия имеет партнерские отношения с операторами других серверов присутствия. Например, сервер присутствия, использующий программное обеспечение обмена мгновенными сообщениями от Microsoft, мог бы взаимодействовать с AOL, Aahoo и прочими платформами мгновенных сообщений, используя членские группы публичного облака. Заданием членской группы публичного облака в членском списке совокупности публикующий пользователь может определить публикации присутствия, на которые члены других систем присутствия могут подписаться и просматривать, не перечисляя каждого пользователя в членском списке совокупности.
В одном варианте осуществления система присутствия принимает объединенную членскую группу. Объединенная членская группа является группой, в которой несколько записей, определяет списки пользователей, которые должны иметь одинаковый доступ к информации присутствия. Например, две корпорации, такие как Майкрософт и Интел, делают список сотрудников доступным для объединенных членских групп. Сервер присутствия, получая публикации с типом объединенной членской группы, обращается к заданному серверу объединенного членства, чтобы определить, какие пользователи являются членами объединенной группы. Публикующий пользователь может затем задать публикации, на которые объединенная группа может подписаться.
В одном варианте осуществления система присутствия принимает пакетные изменения членских списков в одном запросе. Например, публикующий пользователь мог бы предоставить доступ к совокупности подписанным пользователям из членской группы того же предприятия и удалить пользователей из членской группы публичного облака из совокупности, посылая один запрос. Публикующий пользователь может указать членские списки для нескольких совокупностей, как и несколько членских групп и отдельных пользователей в членском списке для отдельной совокупности в одном запросе.
Комбинируя модель совокупностей с членскими группами, публикующий пользователь способен устанавливать иерархию доступа к информации присутствия. Например, пользовательская календарная информация может быть сделана доступной детально для коллег в том же предприятии и доступной как «свободен/занят» (только лишь указывая моменты времени, когда пользователь свободен или занят) для остальной публики. Таким образом, обычные пользователи могут планировать встречи, не конфликтующие с расписанием публикующего пользователя без раскрытия персональной информации о действиях пользователя. С другой стороны, коллеги получают более детальную информацию о действиях, так, например, они могут узнать, что пользователь будет на встрече с коллегой позднее в течение дня.
Фиг.1 представляет блок-схему компонентов системы присутствия в одном варианте осуществления. Система 110 присутствия соединена с устройствами-объектами 120 и 130 посредством линии 140 связи, например Интернет. Устройства-объекты соответствуют объектам, которые могут быть подписчиками либо публикаторами. Устройства-объекты включают в себя компонент 122 составления обновления публикации, компонент 125 составления запроса подписки и компонент 127 посылки запроса. Компонент 122 составления обновления публикации составляет запросы обновления для опубликованной информации присутствия, которая может включать в себя пакеты индивидуальных обновлений публикаций. Компонент 125 составления запроса подписки составляет запрос подписки, который может включать в себя пакеты подписок на несколько категорий информации присутствия для нескольких публикующих пользователей. Компонент 127 посылки запроса посылает запросы обновления публикаций и запросы подписки системе 110 присутствия.
Система присутствия включает в себя компонент 150 приема обновления публикации, компонент 155 обновления публикации, компонент 170 «приема» обновления членства, компонент 175 обновления членства, компонент 180 истечения публикаций, компонент 182 обнаружения статуса подключения, компонент 185 приема запроса подписки, компонент 190 обновления подписки, компонент 165 создания совокупности, компонент 160 хранилища публикации и компонент 195 хранилища подписок. Хранилище 160 публикаций содержит публикации публикаторов. Публикации организованы в совокупности, созданные компонентом 165 создания совокупностей. Компонент 150 приема обновления публикаций включается в работу, когда от публикатора получен запрос на обновление одной или нескольких публикаций. Компонент 150 приема обновления публикации обращается к компоненту 155 обновления публикации, чтобы добавить, удалить либо обновить публикации в хранилище 160 публикаций, как задано в запросе. Компонент 170 приема обновления членства включается в работу, когда получен запрос от публикатора на обновление членского списка в одной или нескольких совокупностях хранилища 160 публикаций. Запрос может быть получен как независимое сообщение или может быть частью запроса обновления публикации. Компонент 170 приема обновления членства вызывает компонент 175 обновления членства, чтобы добавить, удалить и обновить членство в совокупностях в хранилище 160 публикаций. Компонент 185 приема запроса подписки включается в работу, когда получен запрос от объекта на подписку на один или несколько типов публикаций публикатора. Компонент 185 приема запроса подписки вызывает компонент 190 обновления подписки, чтобы подписать объект на запрошенный тип публикаций. Подписки хранятся в хранилище 195 подписок, которое может быть интегрировано с хранилищем публикаций 160. Компонент 180 истечения публикаций вызывается периодически системой присутствия для очистки истекших публикаций в хранилище 160 публикаций. Хотя не показано на Фиг.1, устройства-объекты содержат компоненты системы присутствия для определения совокупностей и их членства, для посылки обновлений публикаций, для посылки запросов подписки и для приема уведомлений об обновлениях публикаций.
Вычислительное устройство, на котором реализуется система, может включать в себя блок центрального процессора, память, устройства ввода (т.е. клавиатуру и манипулятор «мышь»), устройства вывода (т.е. показывающие устройства) и устройства хранения (т.е. приводы дисков). Память и устройства хранения являются компьютеро-читаемыми носителями, которые могут содержать инструкции, которые реализуют систему. В дополнение, структуры данных и структуры сообщений могут храниться или передаваться через среду передачи данных, такую как сигнал в линии связи. Могут применяться разные линии связи, такие как Интернет, локальная сеть, глобальная сеть, коммутируемое соединение типа точка-точка, сотовая телефонная сеть и тому подобное.
Варианты осуществления системы могут быть реализованы в различных вычислительных окружениях, которые включают в себя персональные компьютеры, серверные компьютеры, наладонники или портативный компьютер, многопроцессорные системы, основанные на микропроцессорах системы, программируемую бытовую электронику, цифровые камеры, сетевые РС, миникомпьютеры, компьютеры-мэйнфреймы, распределенные вычислительные среды, которые включает в себя любые из упомянутых систем или устройств, и т.д. Компьютерная система может быть сотовым телефоном, персональным цифровым помощником, смартфоном, персональным компьютером, программируемой бытовой электроникой, цифровой камерой и т.д.
Система может быть описана в общем контексте компьютеро-исполняемых команд, таких как программные модули, исполняемые в одном или нескольких компьютерах, или других устройствах. В общем, программные модули содержат подпрограммы, программы, объекты, компоненты, структуры данных и т.п., которые выполняют конкретную задачу или реализуют конкретные абстрактные типы данных. Типично функциональность программных модулей может комбинироваться или распределяться, если понадобится, в различных вариантах осуществления.
Фиг.2 - это листинг протокола, иллюстрирующий расширения протокола SIP для посылки обновлений публикаций в одном варианте осуществления. Протокол начинается со слова SIP «PUBLISH» 210, которое обозначает запрос публикации информации. Протокол содержит заголовки 220, которые дополнительно описывают запрос, например тип его содержимого. Протокол содержит секцию 230 «<publish>», которая содержит секцию 232 «<publications>». Секция «<publications>» перечисляет публикации 235 и 240, которые нужно опубликовать, а также публикацию 250, которые нужно снять с публикации. Публикация 235 задает информацию присутствия для категории, именуемой «status», заданный экземпляр категории, названный «laptop», контейнер (один из типов коллекций), обозначенный как «1», версию «0» публикующего пользователя идентифицируемого адресом SIP «sip.foo@bar.com» и тип истечения публикации «user», который указывает, что публикация должна быть удалена, когда пользователь отключится. Несмотря на то что в некоторых полях показан текст для ясности, также могут быть использованы имена. Например, значение поля «instance» может содержать уникальный идентификатор, назначенный устройству, вместо использования текста «laptop». Другая публикация 240 задает подобную категорию «status», но иной экземпляр «desktop» в ином контейнере «2» для того же публикующего пользователя. Протокол также содержит публикацию 250, которая должна быть удалена из хранилища публикаций, как указано в данном примере параметром типа истечения, установленным в нуль. Несмотря на то что в этом примере поле «expireType» перегружено для обозначения того, что публикация должна быть снята с публикации, отдельное поле или отдельная секция XML в протоколе также может быть использована. Публикация 250, которая удаляется, была идентифицирована по имени категории, идентификатору экземпляра, идентификатору контейнера и адресу публикующего пользователя. Задание адреса публикующего пользователя в публикации позволяет иным объектам публиковать и снимать с публикации информацию присутствия от имени пользователя, как, например, сервером Exchange, как было описано выше.
На фиг.3 представлена блок-схема, иллюстрирующая обработку компонента обновления публикаций системы присутствия. Компонент вызывается компонентом приема обновлений публикаций, когда был принят запрос на публикацию, такой как на фиг.2. В блоке 310 компонент принимает запрос обновления публикации от компонента приема обновлений публикаций. В блоке 320 компонент выбирает следующую публикацию из запроса. В блоке 330 компонент определяет совокупность публикующего пользователя, идентифицированную выбранной публикацией в хранилище публикаций. В блоке принятия решения 340, если публикация существует, компонент продолжает в блоке 360, иначе компонент переходит к блоку 350. В блоке 350 публикации, которые ранее не существовали, добавляются в хранилище публикаций. В блоке 360 существующие в хранилище публикаций публикации обновляют в соответствии с информацией в запросе. В блоке принятия решения 370, если остались в запросе публикации, компонент зацикливается на блок 320, чтобы выбрать следующую публикацию, иначе работа компонента завершается.
На фиг.4 представлен листинг протокола, который иллюстрирует расширения протокола SIP, для посылки запросов подписки в одном варианте осуществления. Протокол SIP начинается со слова «SUBSCRIBE» 410, которое означает запрос на подписку на опубликованную информацию. Протокол содержит заголовок 420, который дополнительно описывает запрос, например тип содержимого. Протокол также содержит секцию 440 «<batchSub>», которая содержит секцию 442 «<action>». Секция действия содержит секцию 445 «<adhocList>» и секцию 450 «<categoryList>». Секции 445 специальных списков указывает идентификаторы публикующих пользователей, уведомления о чьих публикациях подписанный пользователь заинтересован получать. Секция 450 списка категорий задает категории для подписки для каждого публикующего пользователя. Запрос подписки приведет к тому, что подписанный пользователь будет принимать уведомления для каждой из заданных категорий и каждого из заданных пользователей. Хотя на Фиг.4 не показано, запрос также может содержать список категорий и пользователей, для которых нужно отменить подписку, подобный секции 440 подписки.
Блок-схема фиг.5 представляет обработку компонента обновления подписки в системе присутствия в одном варианте осуществления. Компонент запускается компонентом приема запроса подписки, когда принят запрос подписки, такой как на фиг.4. В блоке 510 компонент принимает запрос подписки от компонента приема запроса подписки. В блоке 520 принятия решения, если в запросе есть еще фильтры категорий, компонент продолжает в блоке 530, иначе компонент продолжает в блоке 550. В блоке 530 компонент выбирает следующий фильтр категории из запроса. В блоке 540 компонент обновляет фильтры категорий в хранилище подписок. Далее компонент зацикливается на блок 520, чтобы определить наличие в запросе дополнительных фильтров категорий. В блоке 550 принятия решения, если есть еще подписки в запросе, компонент продолжает в блоке 560, иначе компонент продолжает в блоке 580. В блоке 560 компонент выбирает следующую подписку из запроса подписки. В блоке 570 компонент добавляет подписку в хранилище подписок. Подписка может иметь вид списка пользователей и списка категорий, таких, которые позволят подписать нескольких пользователей на несколько категорий в одной секции подписки. Затем компонент зацикливается на блок 550 для определения, есть ли еще в запросе подписки. В блоке 580 принятия решений, если есть в запросе еще снятия подписок, компонент продолжает в блоке 590 и иначе завершает работу. В блоке 590 компонент выбирает следующее снятие подписки из запроса. В блоке 595 компонент удаляет заданные подписки из хранилища подписок. После завершения обработки всех снятий подписки компонент завершает работу.
Фиг.6 представляет листинг протокола, который иллюстрирует расширения протокола SIP для обновления членских коллекций в одном варианте осуществления. Показанная часть протокола может быть в теле SIP запроса публикации, показанного на фиг.2, или она может иметь типовые части независимого сообщения, особенно для обновления членства. Протокол начинается с секции 610 «<setContainerMembers>», которая содержит одну или более секций 615 «<container>», которые определяют совокупности, членство в которых нужно обновить. Каждая секция контейнера содержит одну или несколько записей 620, 630 и 640 членов. Первая членская запись 620 на Фиг.6 задает тип «uri», который указывает, что значением является SIP URI у заданного пользователя. Тип действия «add» указывает, что заданный пользователь должен быть добавлен как член с доступом к заданной совокупности. Вторая членская запись 630 задает тип «sameDomain», что означает, что должно быть изменено членство пользователей из такого же домена, что и публикующий пользователь, и тип действия «remove» указывает, что доступ к совокупности следует запретить. Третья запись 640 задает тип «contactList» и тип действия «add», что указывает разрешить доступ к заданной совокупности любому пользователю из списка контактов публикующего пользователя.
Блок схема, представленная на Фиг.7, иллюстрирует обработку компонента обновления членства в системе присутствия в одном варианте осуществления. Компонент запускается компонентом приема обновления членства, когда получен запрос обновления членства, такой, как представленный на фиг.6. В блоке 710 компонент принимает запрос обновления членства от компонента приема обновления членства. В блоке 720 компонент выбирает следующую секцию контейнера из запроса. В блоке 730 компонент выбирает следующее обновление членства в секции контейнера. В блоке принятия решений 740, при условии присутствия в членском обновлении действия «add», компонент продолжает в блоке 750, иначе компонент продолжает в блоке 760. В блоке 750 пользователь или группа, заданные в членском обновлении, добавляется в членский список выбранного контейнера в хранилище публикаций. В блоке 760 пользователь или группа, заданные в членском обновлении, удаляется из членского списка выбранного контейнера в хранилище публикаций. В блоке принятия решений 770, если есть еще членские обновления в выбранной секции контейнера, компонент зацикливается на блок 730, чтобы выбрать следующее членское обновление, иначе компонент продолжает в блоке 780. В блоке принятия решения 780, если есть еще секции контейнера в запросе членского обновления, то компонент зацикливается на блок 720, чтобы выбрать следующую секцию контейнера, иначе выполнение компонента завершается.
На фиг.8 представлена блок-схема, иллюстрирующая обработку компонента истечения публикации системы присутствия в одном варианте осуществления. Компонент периодически запускается системой присутствия для удаления устаревших публикаций из хранилища публикаций. В блоке 810 компонент выбирает следующую публикацию из хранилища публикаций. В блоке принятия решения 820, если тип истечения действия публикации указан как «static», тогда компонент продолжает в блоке 860, иначе компонент продолжает в блоке 830. Блок принятия решения 830, если тип истечения выбранной публикации - «device», тогда компонент продолжает в блоке 833, иначе компонент продолжает в блоке 840. В блоке принятия решения 833, если устройство, опубликовавшее выбранную публикацию, отключено, тогда компонент продолжает в блоке 836, иначе компонент продолжает в блоке 860. В блоке 836 компонент удаляет устаревшую публикацию из хранилища публикаций. В блоке принятия решения 840, если тип истечения выбранной публикации - «user», тогда компонент продолжает в блоке 843, иначе компонент продолжает в блоке 850. В блоке принятия решения 843, если пользователь, который публиковал выбранную публикацию, не подключен при помощи какого-либо устройства, компонент продолжает в блоке 846, иначе компонент продолжает в блоке 860. В блоке 846 компонент удаляет устаревшую публикацию из хранилища публикаций. В блоке принятия решения 850, если тип истечения выбранной публикации - «duration», тогда компонент продолжает в блоке 853, иначе компонент продолжает в блоке 860. В блоке принятия решения 853, если заданное количество времени указанной публикации истекло, тогда компонент продолжает в блоке 856, иначе компонент продолжает в блоке 860. В блоке 856 компонент удаляет устаревшую публикацию из хранилища публикаций. В блоке принятия решения 860, если есть еще публикации в хранилище публикаций, компонент зацикливается на блок 810, чтобы выбрать следующую публикацию, иначе работа компонента завершается. Хотя описанный способ показывает опрашивающий способ проверки устаревших публикаций и их удаления, специалистам в данной области должно быть понятно, что возможно применение иных способов, например модель на основании событий, в которой событие изменения статуса пользователя или устройства с подключенного на отключенный, приводит к удалению истекших публикаций напрямую.
Хотя предмет изобретения был описан на языке, специфичном для структурных особенностей и/или методологических действий, следует понимать, что предмет, определенный в приложенной формуле, не должен быть ограничен определенными признаками или действиями, описанными выше. Скорее определенные признаки и действия, раскрытые выше, приведены в качестве примера реализации изобретения. Например, запросы, обрабатываемые системой присутствия, были описаны, используя протокол SIP, но возможно применение других протоколов, например протокола управления передачей (TCP). Иногда действия были описаны как выполняемые компонентами сервера присутствия, но они могут также быть выполнены компонентами в объектах, которые взаимодействуют с сервером присутствия. Система может быть осуществлена как сеть, соединяющая равноправные узлы ЛВС, в которой нет отдельного, центрального сервера присутствия, а информация присутствия распределяется и сохраняется участниками сети. Соответственно изобретение не ограничено ничем, кроме приложенной формулы.