СИСТЕМА И СПОСОБ ДЛЯ ГЛОБАЛЬНОЙ СЛУЖБЫ КАТАЛОГОВ Российский патент 2016 года по МПК G06F17/40 G06F17/30 

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

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

Использование электронных визитных карточек первоначально предложено консорциумом Versit Consortium в 1995, и впоследствии это взял на себя Консорциум электронной почты Internet (IMC). С тех пор IMC разработал несколько стандартов для электронных визитных карточек, например, vCard или hCard, последним из которых является открытый стандарт vCard v3.0. vCard v3.0. определен в двух документах Инженерной группы по развитию интернета (IETF), т.е. в Request for Comments (RFC) 2425 (MIME Content-Type for Directory Information) и в RFC 2426 (MIME Directory Profile). Как определено в упомянутых стандартах, как vCard, так и hCard могут содержать метаданные, семантическую информацию, графику и изображения, и даже аудио или видеоклипы. Как определено в стандартах, следовательно, как vCard, так и hCard являются не более чем пассивными элементами информации.

Один пример использования vCards обсуждается в европейской Патентной заявке № EP 1589730, озаглавленной "Method for Management of vCards". Целью EP 1589730 является способ создания vCards на мобильном терминале и обмен vCards между мобильным терминалом и другими устройствами. Согласно способу EP 1589730, vCard сохраняется как данные изображения в файле JPEG посредством вставки данных vCard в тип MIME в заголовок JPEG.

В американском патенте № 6442263, Beaton и другие, озаглавленном "Electronic Business Cards", обсуждается способ обеспечения электронных визитных карточек в устройство связи. Согласно способу Битона (Beaton), визитные карточки создаются с использованием информации CLID, пересылаются между пользователями телефонной сети, и используются для автоматического инициирования вызова.

Другая система, которая использует платформу vCard, раскрыта в американском патенте № 7246099, Feldhahn. Feldhahn обеспечивает возможность субъектам поддерживать текущую контактную информацию в программном обеспечении, предназначенном для контактных сведений, другого субъекта при отсутствии необходимости самостоятельного уведомления принимающего субъекта или повторной отправки обновленной контактной информации субъекту вручную. Статическая контактная информация субъекта сохраняется на центральном сервере, и ей присваивается глобально уникальный ID. Статическая контактная информация включает в себя динамическую связь, содержащую глобально уникальный ID создателя, который может быть использован получателями контактной информации для осуществления выборки обновленной контактной информации.

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

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

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

РАСКРЫТИЕ ПРЕДМЕТА ИЗОБРЕТЕНИЯ

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

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

регистрации упомянутой электронной визитной карточки в каталоге, причем этот этап регистрации электронной визитной карточки также включает в себя:

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

передачи объекта электронной визитной карточки в каталог, и

сохранения объекта электронной визитной карточки в базе данных,

приема в каталоге набора параметров поиска от абонента,

поиска в базе данных объектов электронной визитной карточки, которые соответствуют параметрам поиска,

обеспечения списка объектов электронной визитной карточки абоненту,

приема в каталоге запроса от абонента на объект электронной визитной карточки из обеспеченного списка объектов электронной визитной карточки и

направления запрошенного объекта электронной визитной карточки абоненту.

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

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

Предпочтительно сеть является сетью мобильной связи, IP-сетью и т.п.

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

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

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

Способ может также включать в себя этап обеспечения возможности абоненту или любой авторизованной стороне обновлять или удалять любой из атрибутов объекта электронной визитной карточки. Соответственно, этап обновления атрибутов объекта электронной визитной карточки может быть выполнен через множество интерфейсов пользователя, включающих в себя, например, web- или wap-интерфейс, локальное приложение или систему меню, с использованием электронной почты, SMS, MMS, срочного сообщения или технологии IP.

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

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

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

по меньшей мере, один сервер, соединенный с упомянутой сетью,

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

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

Предпочтительно сеть является сетью мобильной связи, IP-сетью и т.п.

Абонент может вести поиск и/или просматривать множество электронных объектов визитной карточки, хранящихся в базе данных, в которой поиск/просмотр может быть выполнен через множество интерфейсов пользователя, включающих в себя, например, web- или wap-интерфейс, локальное приложение или систему меню, с использованием электронной почты, SMS, MMS, срочного сообщения или технологии IP.

Система может обеспечивать возможность абоненту или любой авторизованной стороне обновления или удаления любого из атрибутов объекта электронной визитной карточки. Соответственно, этап обновления атрибутов объекта электронной визитной карточки может быть выполнен через множество интерфейсов пользователя, включающих в себя, например, web- или wap-интерфейс, локальное приложение или систему меню, с использованием сообщения электронной почты, SMS, MMS, срочного сообщения или технологии IP.

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

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

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

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

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

Фиг.2 изображает процесс обновления объекта электронной визитной карточки согласно одному варианту осуществления настоящего изобретения.

Фиг.3 - блок-схема, изображающая процедуру поиска согласно одному варианту осуществления настоящего изобретения.

Фиг.4 - блок-схема, изображающая выборку объекта электронной визитной карточки согласно одному варианту осуществления настоящего изобретения.

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

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

Фиг.7A - концептуальная диаграмма одной возможной архитектуры объекта EBC согласно одному варианту осуществления настоящего изобретения.

Фиг.7B - блок-схема, изображающая одну возможную структуру меню, выведенную из архитектуры объекта EBC по фиг.7A.

Фиг.7C - концептуальная диаграмма одной возможной архитектуры объекта EBC согласно одному варианту осуществления настоящего изобретения.

Фиг.7D - блок-схема, изображающая одну возможную структуру меню, выведенную из архитектуры объекта EBC по фиг.7C.

Фиг.8A - концептуальная диаграмма одной возможной архитектуры объекта EBC с присвоенным конкретным контекстом (contest) согласно одному варианту осуществления настоящего изобретения.

Фиг.8B - концептуальная диаграмма одной возможной архитектуры объекта EBC с присвоенным конкретным контекстом согласно одному варианту осуществления настоящего изобретения.

Фиг.8C - концептуальная диаграмма одной возможной архитектуры объекта EBC с присвоенным конкретным контекстом согласно одному варианту осуществления настоящего изобретения.

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

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

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

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

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

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

Согласно фиг.1, изображена система для облегчения передачи контактной информации между множеством абонентов сети 100, которую заявитель называет глобальным каталогом. Как изображено, глобальный каталог включает в себя, по меньшей мере, один сервер 101, соединенный с базой данных 102, содержащей контактную информацию одной или нескольких зарегистрированных сторон 104. Как изображено, сервер соединен с хост-сетью (105), которая оказывает некоторые услуги множеству абонентов 103₁, 103₂..., 103_n, включающие в себя регистрацию и выборку контактной информации из глобального каталога. Каждый абонент 103₁, 103₂., ..., 103_n может получать доступ к глобальному каталогу для внесения своей контактной информации. После регистрации, может быть осуществлена выборка контактных данных конкретного абонента любым другим абонентом 103₁, 103₂ , ..., 103_n через запрос к глобальной службе каталогов. Ниже более подробно обсуждаются различные процедуры выборки и регистрации и т.д.

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

На фиг.2 изображена процедура 200 регистрации, которая обеспечивает возможность абоненту добавлять или исправлять его контактные данные, содержащиеся в глобальном каталоге, согласно одному варианту осуществления настоящего изобретение. Для того чтобы зарегистрировать свои подробные данные в глобальном каталоге, абонент должен отправить свои контактные данные (этап 201) в виде электронной визитной карточки (EBC) в глобальную службу каталогов. До передачи EBC инкапсулируется как объект (этап 202), далее в этом документе называемый объектом EBC. После этого объект EBC направляется (этап 203) в глобальную службу каталогов для регистрации. Инкапсуляция электронной визитной карточки в объект электронной визитной карточки является по существу отображением различных полей vCard, которые являются простой текстовой информацией, в атрибуты для текстовой информации в пределах подходящих атрибутов объекта EBC. На этой стадии отображение использует взаимно однозначное соответствие между информацией vCard и атрибутом объекта EBC, или, возможно, соответствие, которое определяется посредством определения бизнес-правила.

После приема объекта EBC {этап 204) глобальная служба каталогов переходит к проверке того, хранится ли этот объект EBC в ее базе данных (этап 205). Если запись этого объекта EBC найдена в глобальном каталоге, то после этого она переходит к проверке параметров доступа абонента (этап 206). Параметры доступа могут включать в себя одно или несколько из следующего: номер мобильного телефона, или идентификационный номер SIM, или IMEI запрашивающей стороны, и/или любую такую информацию, которая может быть получена от упомянутой стороны без ее активной осведомленности или участия, PIN-код, пароль, и/или любую такую информацию, которую должна явно обеспечивать сторона. Если параметры доступа являются адекватными, то предыдущая отдельная запись пользователя в пределах базы данных глобального каталога обновляется данными, содержавшимися в объекте EBC (этап 207). Пользователю отправляется уведомление об успешном обновлении (этап 208).

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

На фиг.3 изображен процесс 300 предоставления возможности абоненту поиска информации, содержащейся в глобальном каталоге, согласно одному варианту осуществления настоящего изобретения. Как представлено, процесс поиска запускается абонентом, который вводит набор параметров поиска, например, набор ключевых слов (этап 301). Параметры поиска после этого направляются (этап 302) в глобальный каталог. После приема параметров поиска, глобальная служба каталогов переходит к запросу своей базы данных (этап 303) на предмет нахождения объектов EBC, содержащих атрибуты, которые соответствуют (этап 304) параметрам поиска.

В случае существования объектов EBC в базе данных, которые соответствуют параметрам поиска, служба каталогов после этого компилирует отсортированный список этих соответствующих объектов EBC (этап 305), при соблюдении параметров конфиденциальности. Отсортированный список после этого отправляется (этап 306) абоненту для вывода на экран его терминала (этап 308). Если не существует соответствующих результатов, на основе результатов этапа 304, исходя из запроса 303 к базе данных, то глобальный каталог переходит к отправке уведомления абоненту с указанием того, что результаты не найдены (этап 307). После этого на экран терминала 308 абонента выводится нулевой результат.

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

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

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

Так как CRN, как обсуждалось выше, однозначно идентифицирует владельца объекта EBC, то упомянутая система аналогично делает возможным использование номеров-функций. Номера-функции являются номерами, ассоциированными как с владельцем объекта EBC, так и с абонентом, запрашивающим объект EBC. Номер-функция формируется "на лету", но является действительной как уникальный идентификатор связи (телефонный номер, адрес электронной почты, URL и т.п.) между владельцем объекта EBC и запрашивающим абонентом, если в противном случае не является заблокированной владельцем объекта EBC. С каждым запрашивающим абонентом ассоциируется другая номер-функция, но это множество номеров-функций ассоциируется с одним владельцем объекта EBC. Номер-функция применяет ассоциацию "из конца в конец", следовательно, номер-функция ассоциируется как с CRN владельца объекта EBC, так и с CRN запрашивающего абонента. Это обеспечивает возможность двусторонней связи между этими двумя сторонами. Использование номер-функции, сформированной для абонента третьей стороной, для соединения с владельцем EBC или абонентом, ассоциированным с упомянутой номер-функцией, не допускается, поскольку эта система Номер-функции применяет встроенный механизм аутентификации. Соответственно, только субъект, для которого сформирована номер-функция, может использовать эту номер-функцию для соединения с субъектом на другом конце, с которым ассоциируется эта номер-функция.

На фиг.4 изображен один пример выборки для процесса 400 для объектов EBC (из) GD согласно одному варианту осуществления настоящего изобретения. Как представлено, абоненту предоставляют отсортированный список объектов EBC из этапа 308 по фиг.3. После этого абонент выбирает отдельную запись (этап 401) в упомянутом списке, для которой требуется осуществить выборку объекта электронной визитной карточки. Этот выбор далее передается в глобальный каталог, который после этого переходит к просмотру параметров настройки конфиденциальности (этап 402), присвоенных объекту EBC. В данном случае объекты EBC делятся на две группы, т.е. закрытые и открытые списки.

Если определено, что запрошенный объект EBC является закрытым списком, на основе результатов этапа 403, то служба каталогов отправляет запрос 404, в виде выполнимого сообщения, владельцу объекта EBC (этап 405) для получения разрешения на раскрытие информации, содержащейся в объекте EBC, запрашивающей стороне. Владелец после приема запроса отправляет ответ обратно в службу каталогов (этап 406). Служба каталогов после этого определяет, дал ли владелец объекта EBC разрешение на обеспечение запрошенной информацией или отклонил запрос (этап 407). Если владелец не дал разрешение на обеспечение запрошенного объекта EBC, то глобальный каталог переходит к отправке извещения об отказе (этап 408) запрашивающей стороне 409.

Если владелец объекта EBC дал разрешение на обеспечение запрошенной информацией запрашивающей стороны, то служба каталогов переходит к осуществлению выборки объекта EBC из своей базы данных (этап 410). До отправки объекта EBC (этап 412) запрашивающей стороне 409 служба каталогов может помечать объект EBC (этап 411) как часть дублирующего списка контактов для запрашивающей стороны. Как можно видеть из фиг.4, эти этапы также следуют в случае определения того, что объект EBC является открытым списком.

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

В случае выбора пользователем продолжения процесса проверки, абоненту предоставляют опцию для выполнения проверки вручную или автоматически (этап 503). Если абонент выбирает выполнение проверки вручную, то пользователь должен физически присутствовать в уполномоченном Радиоцентре данных Глобального каталога 504 (например, розничный центр данных мобильного абонента и т.д.) и обеспечивать соответствующей документацией. Радиоцентр данных после этого переходит к отправке запроса аутентификации вместо пользователя (этап 505) в глобальный каталог. В отличие от этого, выбор опции автоматической аутентификации вызывает отправку запроса аутентификации непосредственно из мобильного устройства абонента (этап 506) в глобальный каталог.

После приема запроса аутентификации (этап 507) глобальный каталог переходит к проверке параметров доступа стороны - отправителя (этап 508) для определения того, отправлен ли запрос через радиоцентр данных или инициирован пользователем (этап 509). Если запрос отправлен Радиоцентром данных, то объект EBC помечается как удостоверенный (этап 510), т.е. данные, содержащиеся в EBC, являются независимо проверенными и аутентифицированными. После этого абоненту отправляют уведомление об успешной проверке и аутентификации (этап 513).

Если глобальный каталог определяет, что запрос отправлен абонентом, то глобальный каталог переходит к проверке всех доступных данных (этап 511), относящихся к объекту EBC, для проверки и аутентификации личности запрашивающей стороны. Данные могут включать в себя, например, установленные связи и отношения между объектом EBC и другими удостоверенными объектами EBC, информацию, содержащуюся в базах данных Поставщика услуг мобильной связи или поставщика интернет-услуг (ISP) абонента или базах данных другой третьей стороны, например, данные учетной записи в социальной сети, потребительских базах данных утилит и т.д. Если полученные данные являются адекватными, на основе результатов этапа 512 принятия решения, то на запрос аутентификации выдается разрешение, и объект EBC помечается как удостоверенный (этап 510). После этого абоненту отправляют уведомление об успешной проверке и аутентификации (этап 513). Если доступные данные являются не адекватными, на основе результатов этапа 512 принятия решения, для обеспечения возможности глобальному каталогу для проверки и аутентификации личности запрашивающей стороны, то запрашивающей стороне направляется уведомление о неудаче (этап 513).

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

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

После осуществления выборки глобальным каталогом списка объектов EBC из мобильного устройства, глобальный каталог начинает сравнивать отдельные записи в выбранном списке объектов EBC с объектами EBC, содержащимися в своей базе данных. Как представлено, глобальный каталог сравнивает первую отдельную запись в выбранном списке объектов EBC с каждым объектом EBC, хранящимся в своей базе данных (этап 604). Если не существует записи данного объекта EBC в базе данных (этап 605), то объект EBC рассматривается как добавленной вручную отдельной записью, и глобальный каталог пропускает эту отдельную запись (этап 607). Глобальный каталог после этого определяет то, существуют ли еще объекты EBC в списке выбранных объектов EBC, которые должны быть проверены (этап 611), и если это так, то глобальный каталог переходит к проверке следующего объекта EBC в списке выбранных объектов EBC (этап 604).

Если на этапе 604 найдена соответствующая запись объекта EBC, выбранного из устройства абонента, то глобальный каталог сравнивает данные, содержащиеся в выбранной EBC, с данными, содержащимися в EBC, хранящейся в своей базе данных (этап 606). Если данные, содержащиеся в каждом из упомянутых объектов EBC, являются идентичными, на основе результатов этапа 608, то информация, содержащаяся в EBC на устройстве абонента, рассматривается как являющаяся самой последней, и дальнейшие действия не требуется, и эта отдельная запись пропускается (этап 609). Глобальный каталог после этого определяет то, существуют ли еще объекты EBC в списке выбранных объектов EBC, которые должны быть проверены (этап 611), и, если это так, то глобальный каталог переходит к проверке следующего объекта EBC в списке выбранных объектов EBC (этап 604).

Если данные, содержащиеся в объекте EBC, выбранном из устройства абонента, не соответствуют данным, содержащимся в объекте EBC, содержащемся в глобальном каталоге, на этапе 608, то каталог рассматривает данные в EBC, выбранной из устройства абонента, как устаревшие и требующие обновления. Тогда глобальный каталог отправляет обновление абоненту, содержащее обновленный объект EBC, в устройство абонента (этап 610). После приема обновления (этап 612), данные, содержащиеся в объекте EBC, хранящемся на устройстве абонента, замещаются данными, содержащимися в уведомлении. Глобальный каталог после этого определяет то, существуют ли еще объекты EBC в списке выбранных объектов EBC, которые должны быть проверены (этап 611), и, если это так, то глобальный каталог переходит к проверке следующего объекта EBC в списке выбранных объектов EBC (этап 604).

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

Как кратко упоминалось выше, объект EBC включает в себя несколько атрибутов и способов, концептуальная диаграмма структуры одного варианта осуществления объекта EBC изображена на фиг.7A. В этом конкретном примере, объект EBC включает в себя два атрибута 701₁, 701₂ и два способа 702₁, 702₂. Как уже отмечалось, атрибуты являются информационными атрибутами и могут ассоциироваться с различными текстовыми полями виртуальной визитной карточки объектов. Способы, с другой стороны, определяют действия, которые могут быть выполнены над объектом EBC.

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

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

Пример системы меню для интерпретации информации, хранящейся в объекте EBC в контексте мобильного телефона, представлен на фиг.7B. В этом случае объект EBC считывается обработчиком меню системы меню и выводится на экран пользователя как отдельная запись 703 телефонной книги. Для вывода на экран объекта EBC как отдельной записи телефонной книги, обработчик меню определяет значение, присвоенное "атрибуту name" объекта EBC. Как представлено в примере по фиг.7A, объект EBC содержит два атрибута 701₁, 701₂. Любой из этих атрибутов может быть назначен как атрибут «name» (имя). В этом примере первый атрибут 701₁ является атрибутом name и содержит релевантную информацию, относящуюся к имени объекта, например, "John Doe". Второй атрибут 701₂ в этом случае ассоциируется с телефонным номером объекта. Для простоты описания, атрибут, ассоциируемый с контактным телефонным номером объектов или номерами, далее в этом документе называется атрибутом «phone» (телефон).

Как и в случае с пунктом отдельной записи стандартной телефонной книги, пользователь может свободно выбрать этот пункт для вывода подменю 704. Подменю 704 в этом случае предоставляет пользователю выбор доступных способов, ассоциированных с релевантными атрибутами объекта EBC. В этом случае способам 702₁ и 702₂, присвоены конкретные задачи "Call (Вызов)" и «Send Money» (Отправка денег). Способу 702₁ в этом случае присвоена функция "Call", и, как таковой, этот способ ассоциируется с атрибутом 701₂, т.е. атрибутом «phone». Выбор вызова 704 на выведенном на экран меню вызывает выборку способом 702₁ релевантного контактного номера из атрибута 701₂ «phone» и инициирование вызова релевантной стороны. Соответственно, не требуется дополнительного взаимодействия с меню со стороны пользователя для инициирования вызова. Аналогично, выбор опции "Send Money", вызовет инициирование способом два 702₂ релевантных действий для осуществления передачи некоторой величины, обозначенной мобильным пользователем, в учетную запись, заданную в одном из атрибутов 701₁, 701₂.

Как изображено, подменю 704 также включает в себя пункт меню по умолчанию, "View Details” (Просмотр подробных данных) 707. Этот пункт меню обеспечивает возможность просмотра и редактирования значений других информационных атрибутов, например, возможно, адрес электронной почты, день рождения и т.п., содержащийся в одном или нескольких атрибутах объекта EBC.

Несмотря на то, что примеры, изображенные на фиг.7A и фиг.7B, используют два атрибута и способа, специалистам в данной области техники будет понято, что объект EBC может включать в себя множество атрибутов и способов. Концептуальная диаграмма структуры объекта EBC, имеющего множество атрибутов и способов, представлена на фиг.7C. Как представлено, Атрибуты могут находиться в пределах от 1 до n, где n - верхняя граница. Аналогично, способы могут находиться в пределах от 1 до m, где m - верхняя граница.

На фиг.7D изображено меню, сформированное обработчиком меню для объекта EBC, имеющего структуру, изображенную на фиг.7C. Как и в случае с рассмотренными выше примерами, обработчик меню в этом случае преобразует значение, содержащееся в атрибуте name объекта EBC, и представляет информацию пользователю в виде отдельной записи телефонной книги 705. Выбор отдельной записи "John Doe" выводит на экран подменю 706, содержащее список доступных способов 702₁, 702₂, ..., 702_m. Как представлено, способы, выводимые на экран как пункты меню, ограничены только количеством способов, которое может уместиться на экране, минус один. В приведенном выше примере, несмотря на то, что на экране умещаются 5 способов в виде пунктов меню, представлены только 4 пункта меню, соответствующие способам 1-4 (702₁, 702₂, 702₃, 702₄), для предоставления места обязательному пункту меню "View Details" 707. Обработчик меню после этого устанавливает соответствие с кнопкой на мобильном устройстве, которая обеспечивает возможность прокрутки до следующего экрана, заполненного пунктами меню. Это может являться использованием навигационных клавиш, встроенного джойстика или любой "горячей" клавиши, назначенной для такой цели. Соответственно, следующий полный экран представляет Способ 5 - Способ 9, при этом на последнем доступном экране выводятся Способ (m-4) - Способ m.

Согласно предложенной системе меню заявителя, объекты EBC могут также быть обеспечены невизуальным атрибутом "Context” (Контекст). Атрибут “context” определяет набор способов и атрибутов по умолчанию, ассоциированных с объектом EBC. Пример использования атрибута “context” изложен ниже в Таблице 1. В данном случае обеспечены 3 типа контекста, причем каждый контекст имеет набор способов и атрибутов по умолчанию.

Таблица 1 Количество атрибутов и методов по умолчанию для конкретных контекстов Контекст Атрибуты Методы Person (Субъект) 6 7 Institution (Учреждение) 4 5 Device Owner (Владелец устройства) 6 5

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

Концептуальные диаграммы каждой из структур объекта EBC для каждого из вышеупомянутых идентифицированных контекстов изображены на фиг.8A, фиг.8B и фиг.8C. На фиг.8A изображена одна возможная структура для классификации контекста "Субъект". Согласно вышеприведенной таблице 1, структура объекта EBC для этого контекста включает в себя шесть атрибутов 801 (в том числе невизуальный атрибут 801₁ “context”) и 7 способов 802. Атрибуты по умолчанию предусматривают, что этот контекст включают в себя атрибуты name 801₂ и phone 801₃, как обсуждалось выше. В дополнение к этим атрибутам структура объекта EBC также включает в себя дополнительные атрибуты, которые содержат дополнительную информацию относительно субъекта, идентифицированного в атрибуте name. Эти дополнительные атрибуты могут включать в себя, например, атрибут 801₄ “email” (электронная почта), атрибут 801₅ “website” (web-сайт), атрибут 801₆ “Blog” (Блог). Каждый из атрибутов 801 может быть ассоциирован с одним или несколькими способами 802. Как представлено, эти семь способов, обеспеченных согласно контексту "Субъект", могут включать в себя такие действия, как messaging (передача сообщений) 802₁, call (вызов) 802₂, visit site (посещение сайта) 802₃, read blog (чтение блога) 802₄, poke (запись по машинному адресу) 802₅, send money (отправка денег) 802₆, а также view details (просмотр подробных данных) 802₇ по умолчанию. Ниже более подробно обсуждается ассоциация различных способов с различными атрибутами.

На фиг.8B изображена одна возможная структура объекта EBC для классификации контекста "Institution". Как представлено, структура объекта EBC для этого конкретного контекста включает в себя четыре атрибута 801 и 5 способов 802. Атрибуты 801 предусматривают, что этот конкретный контекст включает в себя “name” 801₂, “phone” 801₃, “email” 801₄ и невизуальный атрибут 801₁ “context”. Способы 802, ассоциированные с атрибутами 801, в этом случае включают в себя в дополнение к способу 802₇ “view details” по умолчанию и “messaging” 802₁ и “call” 802₂, обеспеченных согласно контексту "Субъект". В дополнение к этим способам контекст "Institution" включает в себя несколько способов, специальных для контекста “Institution”, в этом примере этими специальными для контекста способами являются способы "see catalog” (просмотр каталога) 802₈ и "Locate” (определение местоположения) 802₉. Когда имя предполагает, обеспечивается способ "see catalog" 802₈ для обеспечения возможности пользователю просмотра релевантного каталога продукта для учреждения, идентифицированного в ассоциированном атрибуте “name”, в то время как способ "Locate" 802₉ обеспечивает информацию относительно местоположения соответствующего учреждения, идентифицированного в ассоциированном атрибуте “name”.

Одна возможная структура объекта EBC для контекста "Device Owner" изображена на фиг.8C. Как задано в вышеприведенной Таблице 1, контекст “Device Owner” включает в себя шесть атрибутов 801 и пять способов 802. Соответственно, контекст Device Owner сосредоточен больше на информационных атрибутах 801 и меньше на способах 802. Как представлено, информационные атрибуты 801, обеспеченные согласно контексту “Device Owner”, являются аналогичными информационным атрибутам, обеспеченным согласно контексту “Person”. В этом случае контекст “Device Owner” включает в себя, в дополнение к невизуальному атрибуту 801₁ “context”, атрибуты “name” 801₂, “phone” 801₃, “email” 801₄, “website” 801₅ и “blog” 801₆. Способы 802, обеспеченные согласно этому конкретному контексту, могут включать в себя, например, read notes (чтение заметок) 802₁₀, manage money (управление деньгами) 802₁₁, check planner (проверка организатора) 802₁₂ и write blog (написание блога) 802₁₃. Как и в случае вышеупомянутых контекстов, рассмотренных выше, контекст Device Owner также включает в себя способ view details 802 по умолчанию.

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

Для определения того, какие способы должны быть выведены на экран пользователя для данного объекта EBC, обработчик меню применяет процесс обнаружения сервиса. По существу обработчик меню сравнивает установление соответствия атрибутов со способами. Пример процесса обнаружения сервиса изображен на фиг.9. Как представлено, обработчик меню сначала определяет то, существует ли атрибут, установленный в соответствие способу (этап 901). Если атрибут не существует, то способ помечается как недоступный (этап 902), и наоборот, если атрибут существует, то способ помечается как доступный (этап 903). Обработчик меню после этого определяет то, существуют ли еще способы, которые должны быть проверены (этап 904), для конкретного объекта EBC, и, если это так, то обработчик меню повторяет этапы 901, 902 или 903 процесса (в зависимости от доступности способа) до тех пор, пока не останется способов, которые должны быть проверены, в результате чего обработчик меню формирует меню, содержащее только пункты меню (этап 905), которые соответствуют способам, (помеченным) как доступные для данного объекта EBC.

В качестве примера, рассмотрим объекты EBC контекста "Person". Согласно этому контексту объект EBC включает в себя способ "Read Blog” (Чтение блога), который установлен в соответствие с атрибутом “Blog”. Атрибут “Blog” может иметь в качестве своего значения или URL Блога или пустой указатель. Именно это значение обработчик меню считывает на этапе 901 для определения того, существует ли атрибут, если атрибут “Blog” является пустым указателем, то способ "Read Blog" не становится частью системы меню, ассоциированной с объектом EBC. И наоборот, если существует значение, соответствующее атрибуту “Blog”, то способ "Read Blog" становится пунктом меню в системе меню, ассоциированной с конкретным объектом EBC.

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

• Широковещательная рассылка со стороны владельца информации;

• Совместное использование отдельной записи телефонной книги;

• Синхронизация с глобальной службой каталогов (как описано выше).

Широковещательная рассылка со стороны владельца информации происходит, когда владелец информации использует мобильную сеть для передачи обновленной копии объекта EBC, который относится к конкретному владельцу информации. Владельцем информации является владелец информации, локально определенный на мобильном устройстве как объект EBC с контекстом "Device Owner". Таким владельцам информации обеспечиваются определенные инструментальные средства для обновления и даже изменения или преобразования атрибутов и способов, ассоциированных с объектом EBC. Набор атрибутов и способов по умолчанию, ассоциированный с таким объектом EBC, замещается этой настройкой. В примере, иллюстрированном на фиг.10A, владелец информации (Субъект A) отредактировал подробные данные своего объекта EBC, так что они включают в себя новые атрибуты и способы. В данном случае Субъект A добавил два новых атрибута "Social Net” (Социальная сеть) 1001₁ и "Chat” (Чат) 1001₂ к полям атрибута по умолчанию невизуального атрибута 801₍₁₎ “context”, атрибутов “name” 801₂, “phone” 801₃, “email” 801₄, “website” 801₅ и “blog” 801₆. Аналогично, два новых способа “See Social Net” (просмотр Социальной сети) 1002₁ и “Chat” (Чат) 1002₂) добавлены к списку способов по умолчанию для контекста “Device Owner”, а именно, “read notes” 802₁₀, “manage money” 802₁₁, “check planner” 802₁₂ и “write blog” 802₁₃.

Как очевидно специалисту в данной области техники, в то время как объект EBC субъекта A рассматривается локально как принадлежащий контексту "Device Owner", он виден из устройства других людей как принадлежащий контексту "Person". Соответственно, объект EBC субъекта A виден локально из устройства субъекта B как объект EBC, имеющий, по меньшей мере, способы и атрибуты по умолчанию рассмотренного выше контекста “Person”. Что касается субъекта B, объект EBC, относящийся к субъекту A, остается без атрибутов "Social Net" и "Chat", и, следовательно, без способов "See Social Net" и "Chat" до тех пор, пока не произойдет обновление объекта EBC субъекта A, т.е. пока обработчик меню субъекта B не примет обновление посредством приема широковещательной рассылки от владельца информации, Совместного использования отдельной записи телефонной книги с субъектом A или запроса субъекта B на синхронизацию своего списка объектов EBC с глобальной службой каталогов (как обсуждалось выше в отношении фиг.6).

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

Если получатель решит принять обновленный EBC, то обработчик меню инициирует обновление меню "на лету", то есть, когда используется обновленный объект EBC, как представлено на фиг.10B. В этом примере, если получатель решает получить доступ к обновленный EBC через свою телефонную книгу, то обработчик меню обновляет систему меню способом, весьма подобным процессу, иллюстрированному посредством процесса обнаружения сервиса, подобного тому, который изображен на фиг.9.

Кроме обновления меню, обработчик меню может также перекомпоновывать то, как представлены способы как пункты меню. Для каждого объекта EBC, способы ранжируются на основе следующих критериев:

• Успех транзакции

• Частота транзакции

• Стоимость транзакции

• Другие бизнес-правила

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

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

Система меню может также применять маскирующую функцию для обеспечения возможности пользователям взаимодействовать с различными индивидуумами без необходимости идентифицировать конкретно каждого индивидуума. Маскирующая функция использует классификацию контекста, (известную) как контекст "Group” (Группа). Контекст "Group" также делится на локальные или глобальные классы. Объектом EBC контекста "local group” (локальная группа) является тот, который служит псевдонимом для группы объектов EBC, хранящихся локально на устройстве пользователя. Любое действие над псевдонимом является действием над всеми объектами EBC, связанными с этим псевдонимом локальной группы. Это действие, однако, будет ограничено теми действиями, которые могут быть выполнены в группе, например, отправка SMS.

Пример использования маскирующей функции для контекста local group представлен на фиг.11. Как представлено, в SMS 1101 указывается адрес с использованием псевдонима 1102 локальной группы. Маскирующая функция переходит к отправке SMS каждому индивидууму, идентифицированному в объектах 1103₁, 1103₂, 1103₃, 1103₄ EBC, содержащийся в локальной группе.

Объект EBC контекста "global group” (глобальная группа) может быть реализован аналогично. Различие, однако, в отношении "local group" и "global group" состоит в том, что "local group" создается владельцем устройства на устройстве, посредством маскирования объектов EBC, которые расположены на упомянутом устройстве, в то время как "global group" является объектом EBC из глобальной службы каталогов, который служит указателем на другие объекты EBC. Маскированные объекты EBC в "local group" известны владельцу устройства, потому что экземпляры этих маскированных объектов, как предполагается, хранятся в упомянутом устройстве, в то время как маскированные объекты EBC в "global group" не известны владельцу устройства. Маскированные объекты EBC в "global group" хранятся в базе данных службы каталогов.

Фиг.12 иллюстрирует использование маскирующей функции для отправки сообщения объектам EBC в контексте локальной или глобальной группы. Как представлено, пользователь отправляет SMS псевдониму контекста группы (этап 1201). Маскирующая функция после этого переходит к проверке того, равен ли атрибут контекста группы “local group” (этап 1202). Если определено, что группа является локальной группой, то маскирующая функция переходит к считыванию атрибута указатель “mask” (этап 1204), который идентифицирует все объекты EBC, содержащиеся в группе. Маскирующая функция после этого переходит к извлечению объектов EBC из локального списка объектов EBC (этап 1205) и отправке SMS каждому индивидууму, идентифицированному извлеченными объектами EBC (этап 1206).

Когда группа является глобальной группой, маскирующая функция направляет SMS в глобальную службу каталогов (этап 1203). Глобальная служба каталогов после этого переходит к считыванию указателя “mask” (этап 1204) для извлечения релевантных объектов EBC (этап 1205) из своей базы данных. После того, как глобальный каталог извлек объекты EBC, содержащиеся в группе, он переходит к пересылке SMS (каждому) индивидууму, идентифицируемому извлеченными объектами EBC (этап 1206).

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

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

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

2. Способ по п.1, в котором этап регистрации также включает в себя этап проверки набора параметров доступа абонента.

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

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

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

6. Способ по п.5, в котором этап приема параметров поиска также включает в себя этап синтаксического анализа (парсинга) принятых ключевых слов до инициирования поиска.

7. Способ по любому из пп.1-4, 6, в котором этап обеспечения списка объектов электронной визитной карточки также включает в себя этап сортировки и/или фильтрации результатов поиска.

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

9. Способ по любому из пп.1-4, 6, 8, также включающий в себя этап обеспечения возможности абоненту или любой авторизованной стороне обновлять или удалять любой из атрибутов объекта электронной визитной карточки.

10. Способ по п.9, в котором этап обновления атрибутов и/или способов объекта электронной визитной карточки выполняется через множество интерфейсов пользователя.

11. Способ по п.10, в котором интерфейсы пользователя включают в себя, по меньшей мере, одно из следующего: web- или wap-интерфейс, локальное приложение или систему меню с использованием электронной почты, SMS, MMS, срочного сообщения или технологии IP.

12. Способ по любому из пп.1-4, 6, 8, 10, 11, также включающий в себя этап приема запроса на синхронизацию от абонента.

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

14. Способ по любому из пп.1-4, 6, 8, 10, 11, 13, также включающий в себя этап проверки и аутентификации содержимого объекта электронной визитной карточки.

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

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

17. Способ по п.1, в котором объект электронной визитной карточки включает в себя один или несколько выполнимых элементов.

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

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

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

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

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

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

24. Система по п.20, в которой объект электронной визитной карточки включает в себя один или несколько выполнимых элементов.

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

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