Система и способ для глобальной службы каталогов

Система и способ для глобальной службы каталогов

Иллюстрации

Показать все

Реферат

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

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

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

Использование электронных визитных карточек первоначально предложено консорциумом 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₂. Как уже отмечалось, атрибуты являются ин