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

Реферат: Розкривається система та спосіб для полегшення передачі контактної інформації між передплатниками мережі, при цьому зазначена система містить щонайменше один сервер, під'єднаний до мережі; щонайменше одну базу даних, під'єднану до серверу; множину терміналів підписчиків, під'єднаних до мережі, причому кожний термінал з підписчиків сконфігуровано для відправлення контактної інформації, асоційованої з передплатником, на сервер у відповідь на запит зазначеного передплатника; причому запит викликає виконання на терміналі передплатника компіляції контактної інформації в об'єкт електронної бізнес-карти, яка містить одне або декілька текстових полів, і відображення одного або декількох текстових полів електронної бізнес-карти в один або декілька об'єктних атрибутів, що містяться в об'єкті електронної бізнес-карти, і передачі об'єкта електронної бізнес-карти на сервер для зберігання в базі даних. UA 106108 C2 (12) UA 106108 C2 UA 106108 C2 5 10 15 20 25 30 35 40 45 50 55 60 Область винаходу Винахід відноситься до розповсюдження контактної інформації між мережевими підписчиками. Зокрема, але не обмежено, цей винахід відноситься до системи та способу для служби глобального каталогу з використанням об'єктів електронних бізнес-карт. Огляд сучасного рівня техніки Використання електронних бізнес-карт вперше було запропоновано Versit Consortium в 1995 році, а потім прийнято Internet Mail Consortium (IMC). З того часу ІМС розробив низку стандартів для електронних бізнес-карт, таких як vCard або hCard, останнім з яких є відкритий стандарт vCard v3.0. Стандарт vCard v3.0 визначений в двох документах цільової групи інженерної підтримки Інтернету (IETF), а саме в запиті на коментар (RFC) 2425 (тип змісту МІМЕ для інформації каталогу) і в RFC 2426 (профіль каталогу МІМЕ). Як визначено в стандартах, як vCard, так і hCard можуть містити метадані, семантичну інформацію, графіки та зображення, і навіть звукову інформацію та відеокліпи. Таким чином, як визначено в стандартах, як vCard, так і hCard є лише пасивними інформаційними елементами. Один приклад використання vCard розглянуто в європейській патентній заявці № EP 1589730 під назвою "Method for Management of vCard". ЕР 1589730 присвячена способу створення vCard на мобільному терміналі та vCard між мобільними терміналами та іншими пристроями. Способом, описаним в ЕР 1589730, vCard зберігається як дані зображення в форматі JPEG шляхом вставки даних vCard типу МІМЕ в заголовок файла JPEG. У патенті США № 6442263, виданому Beaton et all під назвою "Elelctronic Business Cards" розглядається спосіб надання електронних бізнес-карт для комунікаційних пристроїв. Згідно зі способом, запропонованим Beaton, бізнес-карти створюються з використанням інформації визначення номера телефона, яка передається між користувачами телефонної мережі, та використовуються для автоматичної ініціації дзвінків. Інша система, в якій використовується платформа vCard, розкрита в патенті США №7246099, виданому Feldhahn. Feldhahn дозволити окремим особам зберігати поточну контактну інформацію в контактному програмному забезпеченні інших осіб без необхідності індивідуально повідомляти про це отримуючу окрему особу або вручну пересилати оновлену контактну інформацію окремій особі. Статична контактна інформація окремої особи зберігається на центральному сервері, і їй призначається глобальний унікальний ідентифікатор (ID). Статична контактна інформація містить динамічне посилання з глобальним унікальним ідентифікатором автора, яка може бути використана отримувачами контактної інформації для отримання оновленої контактної інформації. В патенті США № 5493015, виданому Desai, описана система електронних бізнес-карт, яка забезпечує компактну та портативну систему читання та зберігання даних бізнес-карт з бізнескарт, які мають дані у вигляді, придатному для машинного зчитування, що зберігаються на машинозчитуємому носії на бізнес-карті. Система електронних бізнес-карт використовує зчитувач, підключений до комп'ютерної системи керування. Система електронних бізнес-карт також забезпечує засоби організації і маніпулювання для даних бізнес-карт, отриманих системою електронних бізнес-карт. Хоча електронні бізнес-карти, такі як vCard або hCard, можуть використовуватися в низці прикладних програмах, функціональність електронних бізнес-карт у теперішній час дещо обмежена. Очевидною перевагою було б розширення функціональності таких карт так, щоб вони містили функції, скрипти та функціональні елементи. Даний винахід направлений на розгляд такого обмеження існуючих стандартів і реалізацій електронних бізнес-карт. КОРОТКИЙ ОПИС ВИНАХОДУ Розкриття винаходу Відповідно до одного аспекту даного винаходу пропонується спосіб передачі контактної інформації між множиною підписчиків мережі, причому зазначений спосіб включає наступні етапи: збір на терміналі підписчика контактної інформації в електронну бізнес-карту, яка має одне або декілька текстових полів; реєстрація електронної бізнес-карти в каталозі, причому етап реєстрації електронної бізнескарти додатково включає: інкапсуляція електронної бізнес-карти в об'єкт електронної бізнес-карти шляхом відображення текстових полів електронної бізнес-карти в один або декілька об'єктних атрибутів, які містяться в об'єкті електронної бізнес-карти; передача об'єкта електронної бізнес-карти в каталог; і збереження об'єкта електронної бізнес-карти в базі даних; отримання в каталозі набору параметрів пошуку підписчика; 1 UA 106108 C2 5 10 15 20 25 30 35 40 45 50 55 60 пошук в базі даних об'єктів електронних бізнес-карт, які відповідають параметрам пошуку; надання підписчику списку об'єктів електронних бізнес-карт; отримання в каталозі запиту від підписчика на об'єкт електронної бізнес-карти з наданого списку об'єктів електронних бізнес-карт; і пересилання підписчику запитаного об'єкта електронної бізнес-карти. Відповідно, кожен з класів об'єктів електронних бізнес-карт містить атрибути та способи. Способом є функція або підпрограма, яка маніпулює атрибутами, застосовує атрибути або виконує деякі інші функції. Об'єкти електронних бізнес-карт можуть також містити один або декілька елементів великого практичного значення. Ці елементи можуть містити скрипти, які запускають програми, що працюють з внутрішніми пристроями, запускають програми або сервіси, і/або ініціюють функції веб-інтерфейсу або wap-інтерфейсу. Об'єкти електронних бізнес-карт можуть містити метадані, семантичну інформацію, графіки, зображення та навіть відеокліпи і звукові кліпи. У одному варіанті здійснення даного винаходу об'єкт електронної бізнес-карти може бути вказівником або маскою для множини об'єктів електронних бізнес-карт, так що будь-які дії користувача з об'єктом електронної бізнес-карти, який є вказівником на множину об'єктів електронних бізнес-карт, рівноцінно таким же діям, виконаним окремо з кожним об'єктом електронної бізнес-карти в цій множині об'єктів електронних бізнес-карт. Переважно, мережею є мережа мобільного зв'язку, мережа ІР або інша мережа. Етап реєстрації може додатково містити етап перевірки набору мандату підписчика. Мандат підписчика може бути пасивним або активним мандатом, або поєднанням цих двох видів. Пасивний мандат може містити, але не обмежуватися, номер мобільного телефону відправника запиту і/або будь-якої подібної інформації, яка може бути отримана та підтверджена за допомогою SIM-авторизації від вказаного відправника без його відома або участі. Активний мандат містить, але не обмежується, PIN-код, пароль і/або будь-яку таку інформацію, яку сторона має повідомити у явному вигляді. Відповідно, параметрами пошуку може бути набір ключових слів. У цьому випадку етап прийому може містити аналіз отриманих ключових слів перед тим, як ініціювати відповідний запит до бази даних з використанням зазначених ключових слів. Етап видачі списку об'єктів електронних бізнес-карт може містити етап сортування та/або фільтрації результатів запиту у відповідності до вказаних бізнес-правилам. Такі правила можуть містити, але не обмежуватися, відносну вагу, що відповідають перевіреному статусу об'єкта, підтвердженні взаємовідносини в якості атрибуту об'єкта, рівень точності співпадіння ключових слів, новизну інформації, булеві операції, при необхідності, та інші умови. Спосіб може додатково включати етап надання дозволу підписчику або іншій уповноваженій стороні оновлювати або видаляти будь-які з атрибутів об'єкта електронної бізнес-карти. Відповідно, етап оновлення атрибутів об'єкта електронної бізнес-карти може бути виконаним за допомогою множини користувацьких інтерфейсів, включно, але не обмежуючись, за допомогою веб-інтерфейсу, wap-інтерфейсу, локальної прикладної програми або системи меню з використання електронної пошти, SMS, MMS, флеш-повідомлень або IP-технології. Спосіб може також включати етап отримання запиту на синхронізацію або завантаження від підписчика. Відповідно, етап синхронізації додатково включає перевірку існування об'єкта (об'єктів) електронних бізнес-карт, на оновлення або завантаження яких отриманий запит, і перевірку налаштування конфіденційності або рівня доступу об'єкта (об'єктів) електронних бізнес-карт, на оновлення або завантаження яких отриманий запит, і відправлення підтвердження великого практичного значення власнику об'єкта (об'єктів) електронних бізнескарт, на оновлення або завантаження яких отриманий запит, для дозволу або заборони цього запиту, якщо налаштування конфіденційності або рівня доступу об'єкта (об'єктів) електронних бізнес-карт вимагають дозволу перед виконанням синхронізації або завантаження, відправлення синхронізуючого оновлення або копії об'єкта (об'єктів) електронних бізнес-карт, на синхронізацію або завантаження яких отримано запит, відправнику запита, якщо отриманий дозвіл на запит синхронізації або завантаження, або в тому випадку, коли налаштування конфіденційності або рівня доступу цього об'єкта (об'єктів) не вимагають дозволу перед синхронізацією або завантаженням, і відправлення відповідного повідомлення відправнику запиту. Спосіб може також включати етап верифікації і аутентифікації змісту об'єкта електронної бізнес-карти. Етап верифікації і аутентифікації може включати позначення об'єкта, на верифікацію якого надійшов запит, як сертифікованого об'єкта, який пройшoв верифікацію і аутентифікацію даних в складі об'єкта електронної бізнес-карти, з відправленням відповідного повідомлення зацікавленій стороні/сторонам. Альтернативно, етап верифікації і аутентифікації 2 UA 106108 C2 5 10 15 20 25 30 35 40 45 50 55 може включати верифікацію об'єкта електронної бізнес-карти, виконану автоматично з рівнем достовірності, з використанням існуючої оплаченої бази даних підписчиків, використанням достовірних відносин, асоційованих з об'єктом, використанням інформації профілю, тощо або комбінації деяких або всіх цих видів інформації за умови дотримання визначених бізнес-правил і в майбутньому, в ході верифікації, позначення цих об'єктів, як тих, відповідають рівню достовірності не менше встановленої границі. У наступному аспекті даного винаходу пропонується система для забезпечення пересилання контактної інформації між підписчиками мережі, причому згадана мережа включає: щонайменше один сервер, під'єднаний до мережі; щонайменше одну базу даних, під'єднану до серверу; множину терміналів підписчиків, під'єднаних до мережі, причому термінал кожного з підписчиків має конфігурацію для передачі контактної інформації, асоційованої з підписчиком, на сервер у відповідь на запит згаданого підписчика, причому запит викликає виконання на терміналі підписчика компіляції контактної інформації в електронну бізнес-карту, яка має одне або декілька текстових полів, і відображення одного або декількох текстових полів електронної бізнес-карти в один або декілька атрибутів об'єкта електронної бізнес-карти, і передачі об'єкта електронної бізнес-карти на сервер для зберігання в базі даних. Переважно, мережею є мережа мобільного зв'язку, мережа ІР або інша мережа. Підписчик може виконувати пошук і/або огляд множини об'єктів електронних бізнес-карт, які зберігаються в базі даних, причому пошук/огляд може виконуватися за допомогою множини користувацьких інтерфейсів, включно, але не обмежуючись, за допомогою веб-інтерфейсу, wapінтерфейсу, локальної прикладної програми або системи меню з використанням електронної пошти, SMS, MMS, флеш-повідомлень або IP-технології. Система може дозволити підписчику або будь-якій уповноваженій стороні оновлювати або видаляти будь-які з атрибутів об'єкта електронної бізнес-карти. Відповідно, етап оновлення атрибутів об'єкта електронної бізнес-карти може виконуватися за допомогою множини користувацьких інтерфейсів, включно, але не обмежуючись, за допомогою веб-інтерфейсу, wapінтерфейсу, локальної прикладної програми або системи меню з використанням електронної пошти, SMS, MMS, флеш-повідомлень або IP-технології. Об'єкти електронних бізнес-карт, які зберігаються в базі даних, можуть бути помічені як сертифіковані елементи даних. Сертифікований об'єкт бізнес-карти – це такий, для якого сервер надає мінімальний рівень достовірності того, що інформація в цьому об'єкті бізнес-карти містить інформацію про особу або об'єкт, до яких цей об'єкт бізнес-карти має відноситися. Сертифікація електронної бізнес-карти має за основу рівень достовірності, отриманий в результаті процесу верифікації, який може містити, але не обмежуватися, вимоги фізичної присутності і подачі мандату, використання існуючої оплаченої бази даних підписчиків, використанням перевірених відносин, асоційованих з об'єктом, або комбінацією будь-яких або усіх цих ознак, при дотриманні певних бізнес-правил. Окремо від рівня достовірності, який відповідає верифікованому об'єкту електронної бізнес-карти, аналогічним чином використовується верифікований статус для підвищення відносної ваги в результатах пошуку в тих випадках, коли запит дає кілька точних і/або приблизних збігів. Відповідно, система може бути реалізована як розподілена система між множиною мереж. У такому випадку глобальний каталог може містити множину комп'ютерних платформ, під'єднаних до кожної мережі в множини мереж, причому кожна комп'ютерна платформа пристосована надавати доступ, керувати і підтримувати службу глобального каталогу. КОРОТКИЙ ОПИС ГРАФІЧНИХ МАТЕРІАЛІВ Для того щоб можна було краще зрозуміти цей винахід і отримати від нього практичний результат, далі приведені посилання на додані графічні матеріали, які ілюструють переважні варіанти здійснення винаходу, на яких: Фіг. 1 є блок-схемою, на якій показана система для полегшення передачі контактної інформації між підписчиками мережі відповідно до одного варіанта здійснення цього винаходу; На фіг. 2 показано процес оновлення об'єкта електронної бізнес-карти відповідно до одного варіанта здійснення цього винаходу; Фіг. 3 є блок-схемою процедури пошуку відповідно до одного варіанта здійснення цього винаходу. Фіг. 4 є блок-схемою отримання об'єкта електронної бізнес-карти відповідного до одного варіанта здійснення цього винаходу; Фіг. 5 є блок-схемою процесу верифікації і аутентифікації об'єкта електронної бізнес-карти відповідно до одного варіанта здійснення цього винаходу; 3 UA 106108 C2 5 10 15 20 25 30 35 40 45 50 55 60 Фіг. 6 є блок-схемою процесу синхронізації об'єктів електронних бізнес-карт, локальних в мобільному просторі, за допомогою отриманої детальної інформації карт відповідно до одного варіанта здійснення цього винаходу; Фіг. 7А є концептуальною схемою однієї можливої архітектури об'єкта ЕВС (електронної бізнес-карти) відповідно до одного варіанту здійснення цього винаходу; Фіг. 7В є блок-схемою однієї можливої структури меню, отриманої з архітектури об'єкта ЕВС, показаної на фіг. 7А; Фіг. 7С є концептуальною схемою однієї можливої архітектури об'єкта ЕВС відповідно до одного варіанту здійснення цього винаходу; Фіг. 7D є блок-схемою однієї можливої структури меню, отриманої з архітектури об'єкта ЕВС, показаної на фіг. 7C; Фіг. 8А є концептуальною схемою однієї можливої архітектури об'єкта ЕВС з призначенням конкретного контексту відповідно до одного варіанта здійснення цього винаходу; Фіг. 8В є концептуальною схемою однієї можливої архітектури об'єкта ЕВС з призначенням конкретного контексту відповідно до одного варіанта здійснення цього винаходу; Фіг. 8С є концептуальною схемою однієї можливої архітектури об'єкта ЕВС з призначенням конкретного контексту відповідно до одного варіанта здійснення цього винаходу; Фіг. 9 є структурною схемою процесу виявлення сервісів, використовуваною в одному варіанту здійснення цього винаходу; Фіг. 10А є концептуальною схемою однієї можливої архітектури об'єкта ЕВС з призначенням конкретного контексту відповідно до одного варіанта здійснення цього винаходу; Фіг. 10В є концептуальною схемою архітектури об'єкта ЕВС з призначенням конкретного контексту так, як вона розглядається з клієнтського пристрою третьої сторони відповідно до одного аспекту цього винаходу; Фіг. 11 є схемою, яка показує функцію маскування відповідно до одного варіанта здійснення цього винаходу; і Фіг. 12 є структурною схемою, яка показує реалізацію функції маскування відповідно до ще одного варіанта здійснення цього винаходу. ОПИС ВАРІАНТІВ ЗДІЙСНЕННЯ ВИНАХОДУ З посиланням на фіг. 1 проілюстровано систему для полегшення пересилання контактної інформації між множиною підписчиків 100 мережі, яких заявник називає глобальним каталогом. Як показано, глобальний каталог містить щонайменше один сервер 101, з'єднаний з базою даних 102, в якій міститься контактна інформація для однієї або кількох зареєстрованих сторін 104. Як показано, сервер з'єднаний з основною мережею 102, яка надає низку сервісів множині підписчиків 1031, 1032,…, 103n, у тому числі реєстрацію та отримання контактної інформації з глобального каталогу. Кожен підписчик 1031, 1032,…, 103n може звернутися до глобального каталогу для введення своєї контактної інформації. Після реєстрації деталей контактна інформація конкретного користувача може бути отримана будь-яким іншим користувачем 1031, 1032,…, 103n за допомогою запиту до служби глобального каталогу. Різні процедури реєстрації, отримання інформації і т. п. розглянуті більш детально нижче. Хоча вищезгадана система глобального каталогу була описана в термінах серверу, з'єднаного з окремою основною мережею, спеціалісту в цій галузі техніки буде зрозуміло, що глобальний каталог може бути також реалізований у вигляді системи, розподіленої між множиною мереж. У цьому випадку глобальний каталог може містити множину комп'ютерних платформ, з'єднаних у кожній мережі з множиною мереж, причому кожна з комп'ютерних платформ пристосована надавати доступ, керувати та підтримувати службу глобального каталогу. Фіг. 2 ілюструє процедуру 200 реєстрації, яка дозволяє користувачу додати або змінити деталі своєї контактної інформації, які знаходяться в глобальному каталозі відповідно до одного варіанта здійснення цього винаходу. Для того щоб зареєструвати свою інформацію в глобальному каталозі, підписчик має відправити свою інформацію (етап 201) у вигляді електронної бізнес-карти (ЕВС) в службу глобального каталогу. Перед передачею ЕВС інкапсулюється в деякий об'єкт (етап 202), який надалі називається об'єктом ЕВС. Саме цей об'єкт ЕВС потім відправляється (етап 203) в службу глобального каталогу для реєстрації. Інкапсуляція електронної бізнес-карти в об'єкт електронної бізнес-карти переважно є відображенням різних полів vCard, які є переважно текстовою інформацією, в атрибути текстової інформації всередині відповідних атрибутів об'єкта ЕВС. В той же час при відображенні використовується однозначна відповідність між інформацією vCard і атрибутом об'єкта ЕВС, або можлива відповідність, яка визначена за допомогою визначення бізнесправил. 4 UA 106108 C2 5 10 15 20 25 30 35 40 45 50 55 60 Після прийому об'єкта ЕВС (етап 204) служба глобального каталогу виконує перевірку, чи зберігається об'єкт ЕВС в її базі даних (етап 205). Якщо запис об'єкта ЕВС знайдено в глобальному каталозі, то потім виконують верифікацію мандату підписчика (етап 206). Мандат може містити один або кілька з наступних даних: номер мобільного телефону або ідентифікатор SIM-карти або номер ІМЕІ відправника запиту та/або іншу таку інформацію, яку можна отримати від вказаної сторони без її активного інформування або участі, PIN-код, пароль і/або будь-яку таку інформацію, яку сторона має надати явним способом. Якщо мандату достатньо, то попередній елемент даних користувача в базі даних глобального каталогу оновлюють даними, які містяться в об'єкті ЕВС (етап 207). Користувачу відсилається повідомлення про успішне оновлення (етап 208). У випадку, коли в базі даних немає запису для цього об'єкта ЕВС (тобто новий підписчик з запитом про реєстрацію), служба глобального каталогу отримує мандат користувача (етап 209). Після того як служба глобального каталогу отримала потрібний мандат, об'єкт ЕВС зберігається в базі даних глобального каталогу. Після того як об'єкт збережено в глобальному каталозі, виконується відправлення повідомлення підписчику (етап 208). Таким чином, новий елемент даних за промовчанням буде позначений, як той, що не пройшoв перевірки та верифікації. На фіг. 3 показаний процес 300, який дозволяє користувачу шукати інформацію, яка міститься в глобальному каталозі, відповідно до одного з варіантів здійснення цього винаходу. Як показано, процес пошуку ініціюється підписчиком, який вводить набір параметрів пошуку, наприклад набір ключових слів (етап 301). Потім параметри пошуку пересилаються (етап 302) в глобальний каталог. Після отримання параметрів пошуку служба глобального каталогу звертається з запитом до своєї бази даних (етап 303) для знаходження об'єктів ЕВС, які містять атрибути, які відповідають (етап 304) параметрам пошуку. У випадку, якщо в базі даних є об'єкти ЕВС, які відповідають параметрам пошуку, то служба каталогу формує відсортований список цих відповідаючих об'єктів ЕВС (етап 305) з урахуванням параметрів конфіденційності. Відсортований список потім пересилається (етап 306) підписчику для відображення на його терміналі (етап 308). Якщо на етапі 304 не отримано результатів від запиту 303 до бази даних, то глобальний каталог виконує відправлення підписчику повідомлення, яке показує, що жодних результатів не знайдено. Цей нульовий результат потім відображується на терміналі 308 підписчика. Після отримання відсортованого списку результатів на етапі 306 підписчик може потім отримати з глобального каталогу (етап 308) потрібний об'єкт електронної бізнес-карти з урахуванням параметрів конфіденційності. Параметри конфіденційності, які можуть підтримуватися системою, надають спеціальні налаштування конфіденційності, які визначають об'єм, в якому інформація з одного об'єкта ЕВС буде загальнодоступною. Можуть бути встановлені різні рівні доступності інформації для різних груп, причому кожна група визначається встановленими взаємовідносинами з власником об'єкта ЕВС, ступенем взаємовідносин, спільними елементами профілю й іншими такими відповідними відмінностями, які можуть бути використані в якості основи, щоб називати групу групою. Тому об'єкт ЕВС, направлений підписчику, може варіюватися в залежності від підписчика, в залежності від застосування різних рівней керування конфіденційністю, наприклад підписчик може належати до довіреної групи власника об'єкта ЕВС, внаслідок чого об'єкт ЕВС, направлений такому підписчику, буде містити інформаційні атрибути та способи, які можуть бути недоступні іншим підписчикам з інших груп. Відповідно до сучасних тенденцій в інформаційних технологіях особа може мати різні номери телефонів, різні адреси електронної пошти або подібну інформацію. Така множина інформації може утворювати основу для різних конфігурацій об'єктів ЕВС, за умови наявності які налаштування конфіденційності конкретного користувача або переваги, але вся ця інформація відноситься до однієї особи. У таких випадках в глобальному каталозі (GD) даному власнику об'єкта ЕВС може бути призначений внутрішній номер посилання на клієнта (CRN). CRN в подальшому використовується для асоціювання "на льоту" конкретних об'єктів ЕВС для підписчика з відповідною інформацією. Таким чином, для двох підписчиків, які запитують один і той самий об'єкт ЕВС, телефонний номер особи може бути різним, але обидва номера дозволяють зателефонувати одній особі. Оскільки, як розглянуто раніше, CRN однозначно ідентифікує власника об'єкта ЕВС, система аналогічним чином уможливлює використання "функціональних номерів". Функціональні номери - це номери, асоційовані як з власником об'єкта ЕВС, так і з підписчиком, який відправив запит на об'єкт ЕВС. Функціональний номер генерується "на льоту", проте він дійсний в якості унікального ідентифікатора зв'язку (номер телефону, адреса електронної пошти, URL і т. п.) між власником об'єкта ЕВС і підписчиком, який здійснює запит, якщо тільки не буде відмінений 5 UA 106108 C2 5 10 15 20 25 30 35 40 45 50 55 60 іншим чином власником об'єкта ЕВС. З кожним підписчиком, що відправив запит, асоціюється інший функціональний номер, але ця множина функціональних номерів асоційовано з єдиним власником об'єкта ЕВС. Функціональний номер використовує наскрізну асоціацію, оскільки функціональний номер асоційований як з CRN власника об'єкта ЕВС, так і з CRN підписчика, який відправив запит. Це дозволяє двосторонній зв'язок між двома сторонами. Використання функціонального номера, генерованого для підписчика третьою стороною, для з'єднання з власником об'єкта ЕВС або з підписчиком, асоційованим з функціональним номером, не дозволяється, оскільки в цій системі функціональних номерів використовують вбудований механізм аутентифікації. Тобто, тільки особа, для якої було згенеровано функціональний номер, може використати цей функціональний номер для з'єднання з особою на іншому кінці, з якою асоційований цей функціональний номер. Один приклад отримання об'єктів ЕВС з глобального каталогу відповідно до одного з варіантів здійснення цього винаходу показаний на фіг. 4 у вигляді процесу 400. Як показано, підписчику наданий відсортований список об'єктів ЕВС з етапу 308 на фіг. 3. Потім підписчик обирає елемент даних (етап 401) у списку, для якого він бажає отримати об'єкт електронної бізнес-карти. Потім вибір передається в глобальний каталог, в якому виконується пошук налаштувань конфіденційності (етап 402), призначених цьому об'єкта ЕВС. У цьому конкретному випадку об'єкти ЕВС розподіляються на дві групи, тобто конфіденційні списки і публічні списки. Якщо на етапі 403 визначено, що запитаний об'єкт ЕВС має знаходитися в конфіденційному списку, то служба каталогу відправляє запит 404 у вигляді повідомлення великого практичного значення власнику об'єкта ЕВС (етап 405) на дозвіл розкриття інформації, яка міститься в об'єкті ЕВС, відправнику запиту. Після отримання запиту власник відправляє назад в службу каталогу (етап 406) відповідь. Потім служба каталогу визначає, чи дав власник об'єкта ЕВС дозвіл на надання запитаної інформації або відмовив в запиті (етап 407). Якщо власник не надав дозвіл на надання запитаного об'єкта ЕВС, то глобальний каталог виконує відправлення повідомлення про відмову (етап 408) відправнику запиту 409. У випадку, якщо власник об'єкта ЕВС дав дозвіл на видачу запитаної інформації відправнику запиту, служба каталогу виконує отримання об'єкта ЕВС зі своєї бази даних (етап 410). Перед відправленням об'єкта ЕВС (етап 412) відправнику запиту 409 служба каталогу може позначити об'єкт ЕВС (етап 411) як частину списку зворотних контактів для відправника запиту. Як можна побачити на фіг. 4, ці етапи також виконують у тому випадку, коли об'єкт ЕВС визначено як той, що відноситься до публічного списку. З посиланням на фіг. 5 проілюстрована одна можлива конфігурація процедури 500 верифікації й аутентифікації об'єктів електронних бізнес-карт, які зберігаються в глобальному каталозі, відповідно до одного варіанта здійснення цього винаходу. Як показано, глобальний каталог сконфігурований для передачі нагадування кожному підписчику, зареєстрованих в каталозі, тобто кожному підписчику, який має в каталозі збережений об'єкт ЕВС. Після прийому нагадування (етап 501) підписчик має вибір виконати аутентифікацію та верифікацію або відмовитися від цього, як показано на етапі 502. Якщо користувач відмовляється від процедури верифікації, то процес завершується. У випадку, коли користувач обрав виконання процесу верифікації, підписчику надається можливість вибору верифікації вручну або автоматично (етап 503). Якщо підписчик обирає ручну верифікацію, то користувач має фізично відвідати уповноважений центр 504 бездротових даних глобального каталогу (наприклад, центр обслуговування підписчика мобільного зв'язку, і т. п.) і надати потрібну документацію. Потім центр бездротових даних виконує відправлення запиту аутентифікації для користувача (етап 505) в глобальний каталог. Навпаки, вибір варіанта автоматичної аутентифікації викликає передачу запиту аутентифікації безпосередньо від мобільного пристрою (етап 506) підписчика в глобальний каталог. Після отримання запиту на аутентифікацію (етап 507) глобальний каталог виконує перевірку мандату відправляючої сторони (етап 508) для того, щоб визначити, чи відправлений запит через центр бездротових даних або ініційований користувачем (етап 509). Якщо запит був відправлений центром бездротових даних, то об'єкт ЕВС позначається як сертифікований (етап 510), тобто дані, які зберігаються в ЕВС, пройшли незалежну верифікацію й аутентифікацію. Потім підписчику (етап 513) відправляється повідомлення про успішне проходження верифікації та аутентифікації. Якщо глобальний каталог визначає, що запит відправлений підписчиком, то глобальний каталог виконує перевірку усіх доступних даних (етап 511), які відносяться до об'єкта ЕВС, щоб верифікувати й аутентифікувати відправника запиту. Ці дані можуть містити, але не обмежуватися, інформацію про встановлені зв'язки і взаємовідносини об'єкта ЕВС з іншими 6 UA 106108 C2 5 10 15 20 25 30 35 40 45 50 55 60 сертифікованими об'єктами ЕВС, інформацію, яка міститься в базах даних інтернет-провайдера (ISP) або провайдера мобільного зв'язку для підписчика, або в інших базах даних третьої сторони, наприклад, про обліковий запис в соціальній мережі, в базах даних споживачів комунальних послуг і т. п. Якщо отриманих даних достатньо на основі рішення, прийнятого на етапі 512, то запит аутентифікації виконується, і об'єкт ЕВС позначається як сертифікований (етап 510). Потім підписчику висилається повідомлення (етап 513) про успішне проходження верифікації та аутентифікації. Якщо доступних даних недостатньо на основі рішення, прийнятого на етапі 512, щоб дозволити глобальному каталогу верифікацію та аутентифікацію особу відправника запиту, то відправнику запиту (етап 513) відправляється повідомлення про помилку. З опису, наведеного вище, можна побачити, що процес верифікації й аутентифікації призначений для того, щоб забезпечити певний рівень достовірності того, що інформація, яка міститься в об'єкті ЕВС, є коректною інформацією, що відноситься до конкретної фізичної або юридичної особи, вказаної в об'єкті ЕВС. Будь-які дії, виконані підписчиком з інформацією, яка є в несертифікованому об'єкті ЕВС, приймаються на власний ризик підписчика, оскільки глобальний каталог не може забезпечити жодного рівня достовірності, що інформація, яка міститься в несертифікованому об'єкті ЕВС, є точною. Один приклад процесу синхронізації об'єктів електронних бізнес-карт, які зберігаються на мобільному пристрої, з відповідними елементами даних в глобальному каталозі, відповідно до одного з аспектів цього винаходу показаний на фіг. 6. Прооцес синхронізації ініціюється підписчиком, який відправляє в глобальний каталог запит синхронізації (етап 601). Після отримання запиту синхронізації (етап 602) глобальний каталог виконує отримання всіх об'єктів ЕВС, які зберігаються в мобільному пристрої (етап 603) підписчика. Після того, як глобальним каталогом отримав список об'єктів ЕВС з мобільного пристрою, глобальний каталог починає порівнювати елементи даних в отриманому списку об'єктів ЕВС з об'єктами ЕВС, які містяться в базі даних. Як показано, глобальний каталог виконує порівняння першого елемента в отриманому списку об'єктів ЕВС з кожним з об'єктів ЕВС, що зберігаються в базі даних (етап 604). Якщо в базі даних немає запису про об'єкт ЕВС (етап 605), тоді об'єкт ЕВС розглядається елементом даних, доданим вручну, і глобальний каталог пропускає цей елемент даних (етап 607). Потім глобальний каталог визначає, чи є в списку отриманих об'єктів ЕВС ще об'єкти ЕВС, які мають бути перевірені (етап 611), і, якщо це так, тоді глобальний каталог виконує перевірку наступного об'єкта ЕВС у списку отриманих об'єктів ЕВС (етап 604). Якщо на етапі 604 знайдений запис, який відповідає об'єкту ЕВС, отриманому від пристрою підписчика, то глобальний каталог виконує порівняння даних, що містяться в отриманому ЕВС, з даними, що містяться в ЕВС, які зберігаються в базі даних (етап 606). Якщо дані, що містяться в кожному об'єкті ЕВС, однакові на основі перевірки на етапі 608, то інформація, що міститься в ЕВС на пристрої підписчика, вважається актуальною, та не вимагається жодних додаткових дій, і елемент даних пропускається (етап 609). Потім глобальний каталог визначає, чи є в списку отриманих об'єктів ЕВС ще об'єкти ЕВС, які мають бути перевірені (етап 611), і, якщо це так, то глобальний каталог виконує перевірку наступного об'єкта ЕВС у списку отриманих об'єктів ЕВС (етап 604). У випадку, коли дані, які містяться в об'єкті ЕВС, отриманому від пристрою підписчика, не відповідають даним, що містяться в об'єкті ЕВС, що міститься в глобальному каталозі на етапі 608, то каталог вважає, що дані в ЕВС, отриманому від пристрою підписчика, не актуальні і їх необхідно оновити. Потім глобальний каталог надсилає підписчику оновлення, яке містить оновлений об'єкт ЕВС, на пристрій підписчика (етап 610). Після отримання оновлення (етап 612) дані, що містяться в об'єкті ЕВС, який зберігається на пристрої підписчика, замінюються даними, що містяться в повідомленні. Потім глобальний каталог визначає, чи є в списку отриманих об'єктів ЕВС ще об'єкти ЕВС, які мають бути перевірені (етап 611), і, якщо це так, тоді глобальний каталог виконує перевірку наступного об'єкта ЕВС у списку отриманих об'єктів ЕВС (етап 604). Процес синхронізації, як детально описано вище, повторюють для кожного елементу даних у списку об'єктів ЕВС, отриманому глобальним каталогом, доки в списку об'єктів ЕВС, отриманих з пристрою підписчика, не залишиться більше записів. Наприкінці успішної повної синхронізації система може створити об'єкт контрольної точки, так що наступні синхронізації можуть проводитися поступово, а не з виконанням повного сканування. Як було коротко згадано раніше, об'єкт ЕВС містить декілька атрибутів та способів, на фіг. 7А показана концептуальна схема структури одного варіанта здійснення об'єкта ЕВС. У цьому конкретному прикладі об'єкт ЕВС має два атрибути 701 1, 7012 та два способи 7021, 7022. Як було згадано вище, атрибутами є інформаційні атрибути, і вони можуть бути асоційовані з 7 UA 106108 C2 5 10 15 20 25 30 35 40 45 50 55 різними текстовими полями віртуальної бізнес-карти осіб. З іншого боку, способи визначають дії, які можуть бути виконані з об'єктом ЕВС. Для того щоб використовувати переваги об'єктно-орієнтованої парадигми, запропонованої в структурі об'єкта ЕВС, заявник розробив спеціалізований інтерфейс меню. Сьогодні більшість систем меню процесо-орієнтована, тобто системи меню розробляють для відображення послідовності дій користувача, необхідних для виконання конкретної задачі. Інтерфейс меню, запропонований заявником, є об'єктно-орієнтованою системою меню, сфокусованою на тому, що користувач може зробити з конкретним об'єктом. Приклад системи меню для інтерпретації інформації, що зберігається в об'єкті ЕВС в контексті мобільного телефону, показаний на фіг. 7В. У цьому випадку об'єкт ЕВС зчитується механізмом меню системи меню та відображується для користувача у вигляді елемента даних 703 телефонної книги. Для того щоб відобразити об'єкт ЕВС у вигляді елемента даних телефонної книги, механізм меню визначає значення, присвоєне "атрибут імені" об'єкта ЕВС. Як показано в прикладі на фіг. 7А, об'єкт ЕВС містить два атрибута 701 1, 7012. Кожен з цих атрибутів може бути присвоєний в якості атрибуту імені. У цьому прикладі атрибутом імені є атрибут 7011, і він містить відповідну інформацію, яка відноситься до імені особи, наприклад "John Doe". Другий атрибут 7012 в даному випадку асоційований з номером телефону особи. Для простоти опису атрибут, асоційований номерами контактних телефонів особи або з номером, буде далі називатися "телефонним атрибутом". Як і в стандартному пункті елемента даних телефонної книги, користувач вільно може обрати цей пункт для виклику підменю 704. Підменю 704 в даному випадку представляє користувача з вибором доступних способів, асоційованих з відповідними атрибутами об'єкта ЕВС. У даному випадку способам 7021 і 7022 призначені спеціальні задачі "Call" [Дзвінок] і "Send Money" [Відіслати гроші]. Способу 7021 в даному випадку призначена функція "Call" [Дзвінок], і цей спосіб асоційований з атрибутом 7012, тобто з телефонним атрибутом. Вибір дзвінка в меню 704 викликає спосіб 7021, який отримує відповідний номер контакту з телефонного атрибуту 7012 і ініціює дзвінок відповідній стороні. Таким чином, для того щоб ініціювати дзвінок, користувачу не потрібно ніякої додаткової взаємодії з меню. Аналогічно, вибір варіанту "Send Money" [Відіслати гроші] викликає другий спосіб 702 2 для ініціації відповідних дій для переведення грошей в сумі, призначеній користувачем мобільного телефону, на рахунок, заданий в одному з атрибутів 7011, 7012. Як показано, підменю 704 містить також пункт меню за промовчанням "View Details" [Переглянути деталі] 707. Цей пункт меню дозволяє переглянути та редагувати значення інших інформаційних атрибутів, якими можуть бути адреса електронної пошти, день народження й інші, які містяться в одному або кількох атрибутах об'єкта ЕВС. Хоча в прикладах, показаних на фіг. 7А і 7В, використовують два атрибути та способи, для спеціалістів в цій галузі техніки зрозуміло, що об'єкт ЕВС може містити декілька атрибутів і способів. Концептуальна схема структури об'єкта ЕВС, який містить декілька атрибутів і способів, показана на фіг. 7С. Як показано, атрибути можуть бути в діапазоні від 1 до n, де n є верхнім обмеженням. Аналогічно, способи можуть бути від 1 до m, де m є верхнім обмеженням. На фіг. 7D показані меню, генеровані механізмом меню для об'єкта ЕВС, який має структуру, показану на фіг. 7С. Як і в прикладах, раніше розглянутих, в цьому прикладі механізм меню транслює значення атрибуту імені об'єкта ЕВС і представляє інформацію користувачу у вигляді елемента 705 телефонної книги. Вибір елемента даних "John Doe" відображає підменю 706, в якому міститься список доступних способів 7021, 7022,…,702m. Як показано, кількість способів, відображених у вигляді пунктів меню, обмежена тільки низкою таких способів, які можуть вміститися на екрані, мінус один. У прикладі вище, хоча на екран у вигляді пунктів меню вміщуються 5 способів, показані тільки 4 пункти меню, які відповідають способам з 1 по 4 (7021, 7022, 7023, 7024), щоб було можливо вивести потрібний пункт меню "View Details" [Переглянути деталі] 707. Потім механізм меню відображає кнопку на мобільному пристрої, яка забезпечує прокручування на наступний екран, повний пунктів меню. Для цього можуть бути використані кнопки напрямку, вбудованого джойстика або будь-яких "гарячих" клавіш, призначених для такої мети. Таким чином, на наступному повному екрані будуть показані способи з 5 по 9, при цьому на останньому доступному екрані будуть відображені способи від (m-4) до m. У системі меню, запропонованій заявником, можуть бути також надані об'єкти ЕВС з невидимим атрибутом "Context" [Контекст]. Атрибут контексту визначає набір атрибутів за промовчанням і способів, асоційованих з об'єктом ЕВС. Приклад використання атрибуту контексту наведений у таблиці 1 нижче. У цьому конкретному випадку є 3 типи контексту, при цьому кожен контекст містить деякий набір атрибутів за промовчанням і способів. 60 8 UA 106108 C2 Таблиця 1 Кількість атрибутів і способів за промовчанням для різних контекстів Контекст Person [Особа] Institution [Заклад] Device Owner [Власник пристрою] 5 10 15 20 25 30 35 40 45 50 Атрибути 6 4 6 Способи 7 5 5 Спеціалістам в цій галузі техніки зрозуміло, що вищенаведена таблиця є тільки ілюстративною та не обмежує визначення кожного контексту. Так само вона не обмежую кількість контекстів, які можуть бути визначені в запропонованій системі меню. Концептуальні схеми кожної зі структур об'єкта ЕВС для кожного з контекстів, визначених вище, показані на фіг. 8А, фіг. 8В і фіг. 8С. На фіг. 8А показана одна можлива структура класифікації Person [Особа] контексту. Відповідно до вищенаведеної таблиці 1, структура об'єкта ЕВС для цього контексту містить шість атрибутів 801 (містить невидимий атрибут контексту 8011) і 7 способів 802. Атрибути за промовчанням, представлені в цьому контексті, містять атрибути імені 8012 і телефоні 8013 атрибути, як описувалося вище. Крім цих атрибутів структура об'єкта ЕВС також містить додаткові атрибути, які містять додаткову інформацію, яка відноситься до особи, ідентифікованої в атрибуті імені. Ці додаткові атрибути можуть містити, наприклад, атрибут 8014 електронної пошти, атрибут 8015 веб-сайту, атрибут 8016 блогу. Кожен з атрибутів 801 може бути асоційованим з одним або кількома способами 802. Як показано, сім способів, передбачених в контексті "Person" [Особа], можуть включати такі дії, як відправлення повідомлення 8021, дзвінок 8022, відвідання сайту 8023, читати блог 8024, записати 8025, надіслати кошти 8026, а також за промовчанням переглянути деталі 8027. Асоціація різних способів з різними атрибутами більш детально описана нижче. На фіг. 8В показана одна можлива структура об'єкта ЕВС для класифікації контексту "Institution" [Заклад]. Як показано, структура об'єкта ЕВС для цього конкретного контексту включає чотири атрибути 801 і 5 способів 802. Атрибути 801, передбачені для цього конкретного контексту, включають ім'я 8012, телефон 8013, електронну пошту 8014 і невидимий атрибут контексту 8011. Способи 802, асоційовані з атрибутами 801, в цьому випадку включають, окрім способа 8027 за промовчанням переглянути деталі, способи відправлення повідомлення 802 1 і дзвінок 8022, як і в контексті "Особа". На додаток до цих способів, контекст "Заклад" містить низку способів, специфічних для контексту закладу, в цьому конкретному прикладі такими специфічними способами для контексту є способи "see catalog" [дивитися каталог] 8028 і "locate" [знайти] 8029. Як показують назви, спосіб "see catalog" [дивитися каталог] 8028 призначений для того, щоб дозволити користувачу переглянути відповідний каталог товарів закладу, визначеному в асоційованому атрибуті, а спосіб "locate" [знайти] 8029 надає інформацію, яка відноситься до розміщення відповідного закладу, ідентифікованому в відповідному атрибуті імені. Одна можлива структура об'єкта ЕВС для контексту "Device Owner" [Власник пристрою] показана на фіг. 8С. Як вказано в таблиці 1, наведеній вище, контекст "Власник пристрою" включає шість атрибутів 801 і п'ять способів 802. Таким чином, контекст "Власник пристрою" більше орієнтований на інформаційні атрибути 801, а менше на способи 802. Як показано, інформаційні атрибути 801, передбачені в контексті "Власник пристрою", аналогічні інформаційним атрибутам, передбаченим для контексту "Особа". У даному випадку контекст "Власник пристрою" містить додатково до невидимого атрибуту 801 1 контексту, атрибути імені 8012, телефону 8013, електронної пошти 8014, веб-сайту 8015 і блогу 8016. Способи 802, передбачені для цього конкретного контексту, можуть містити, наприклад, "read notes" [читати записи] 80210, "manage money" [керувати грошима] 80211, "check planner" [перевірити планувальника] 80212 і "write blog" [записати блог] 80213. Як і в випадку з контекстом, розглянутих вище, контекст "Власник пристрою" включає також спосіб за промовчанням переглянути деталі 802. Із прикладів, розглянутих вище, можна зазначити, що кожний специфічний контекст об'єкта ЕВС визначає набір за промовчанням атрибутів і способів. З цього можна зробити висновок, що оскільки специфічний контент має набір атрибутів за промовчанням і способів, отримана система меню для об'єктів ЕВС для кожного специфічного контексту буде однаковою. Але не у всіх об'єктів ЕВС одного контексту будуть повністю заповнені всі поля атрибутів. Для того щоб визначити, які способи будуть відображуватися користувачу для даного об'єкта ЕВС, механізм меню використовує процес виявлення сервісів. По суті, механізм меню 9 UA 106108 C2 5 10 15 20 25 30 35 40 45 50 55 60 перевіряє відображення атрибутів і способів. Приклад процесу виявлення сервісів показаний на фіг. 9. Як показано, механізм меню спочатку визначає, чи існує атрибут, що відображений у цьому способу (етап 901). Якщо атрибуту не існує, то спосіб відмічається як недоступний (етап 902), і навпаки, якщо такий атрибут існує, то цей спосіб відмічається, як доступний (етап 903). Потім механізм меню визначає, чи є ще способи, які необхідно перевірити (етап 904) для конкретного об'єкта ЕВС, якщо такі є, то механізм меню повторює етапи 901, 902 або 903 процесу (в залежності від доступності способів), доки більше не залишиться способів, вимагаючих перевірки, після чого механізм меню генерує меню, яке містить тільки ті пункти меню (етап 905), які відповідають способам, відміченим як доступні для даного об'єкта ЕВС. У якості прикладу розглянемо об'єкт контексту "Особа". У цьому контексті об'єкт ЕВС містить спосіб "Read Blog" [читати блог], який відображено в атрибуті блогу. Атрибут блогу може мати в якості свого значення або URL блогу, або нуль. Саме це значення механізм меню зчитує підчас етапу 901 для визначення, чи існує атрибут. Якщо атрибутом блогу є нуль, то спосіб "Read Blog" [читати блог] не стає частиною системи меню, асоційованою з об'єктом ЕВС. З іншого боку, якщо існує значення, яке відповідає атрибуту блогу, тоді спосіб "Read Blog" [читати блог] стає пунктом меню в системі меню, пов'язаною з конкретним об'єктом ЕВС. Хоча описаний вище процес виявлення сервісів виконується "на льоту" по мірі того, як вручну створюють елементи даних в телефонній книзі, система меню, отримана в результаті цього, не є статичною. Механізм меню може приймати оновлення, які можуть змінити появу меню для конкретних об'єктів ЕВС. Такі оновлення можуть бути запущені будь-якою з наступних подій: - Широкомовним повідомленням від власника інформації; - Розподіленням елементів даних в телефонній книзі; - Синхронізацією з службою глобального каталогу (як описано вище). Широкомовне повідомлення від власника інформації з'являється тоді, коли власник інформації використовує мобільну мережу для розповсюдження оновленої копії об'єкта ЕВС, який відноситься до конкретного власника інформації. Власником інформації є той, хто локально визначений у мобільному пристрої як об'єкт ЕВС з контекстом "Device Owner" [Власник пристрою]. Таким власникам інформації доступні певні інструменти для оновлення або навіть зміни або модифікації атрибутів і способів, асоційованих з об'єктом ЕВС. Набір за промовчанням атрибутів і способів, асоційований з таким об'єктом ЕВС, визначається в результаті такого переналаштування. У прикладі, показаному на фіг. 10А, власник інформації (особа А) редагує детальну інформацію про свого об'єкта ЕВС таким чином, що він містить нові атрибути та способи. У цьому конкретному випадку особа А додала два нових атрибути "Social Net" [Соціальна мережа] 10011 і "Chat" [Чат] 10012 до полів атрибутів за промовчанням: невидимого атрибуту 801 контексту, атрибутам імені 8012, телефону 8013, електронної пошти 8014, веб-сайту 8015 і блогу 8016. Аналогічно, два нові способи (див., "Social Net" [Соціальна мережа] 10021 і "Chat" [Чат] 10022) були додані до списку способів за промовчанням для контексту "Device Owner" [Власник пристрою], а сааме: "read notes" [читати записи] 80210, "manage money" [керувати грошима] 80211, "check planner" [перевірити планувальника] 80212 і "write blog" [записати блог] 80213. Спеціалістам у цій галузі техніки буде зрозуміло, що хоча об'єкт ЕВС для особи А розглядається локально як той, що відноситься до контексту "Device Owner" [Власник пристрою], на пристроях інших людей він розглядається як той, що відноситься до контексту "Person" [Особа]. Таким чином, об'єкт ЕВС особи А буде розглядатися локально пристроєм особи В як об'єкт ЕВС, який має, щонайменше, атрибути за промовчанням і способи відповідно до контексту "Person" [Особа], як описано вище. До тих пір, поки особа В зайнята, об'єкт ЕВС, який відноситься до особи А, буде залишатися без атрибутів "Social Net" [Соціальна мережа] і "Chat" [Чат], доки не відбудеться оновлення об'єкта ЕВС особи А, тобто механізм меню особи В прийме оновлення шляхом прийому широкомовного повідомлення від власника інформації, розділення елемента даних телефонної книги з особою А, або відсилання особою В запиту на синхронізацію свого списку об'єктів ЕВС зі службою глобального каталогу (як описано вище у зв'язку з фіг. 6). Розділення об'єкта ЕВС є децентралізованим, у той час як широкомовна передача може бути направленою або простою широкомовною передачею. Направленою широкомовною передачею є одночасне відправлення свого об'єкта ЕВС групі отримувачів, яка звичайно обирається з телефонної книги особи А або з будь-якого визначеного списку отримувачів. З іншого боку, при простій широкомовній передачі ЕВС відсилається всім можливим отримувачам в межах визначеного географічного регіону. У обох випадках результат той самий; отримувач оновленого об'єкта ЕВС буде мати або можливість зберегти оновлення, або відмінити його. 10 UA 106108 C2 5 10 15 20 25 30 35 40 45 50 55 60 Якщо отримувач обирає прийняти оновлений ЕВС, то механізм меню ініціює оновлення меню "на льоту", тобто під час оновлення об'єкта ЕВС, як показано на фіг. 10В. У тому ж прикладі, якщо отримувач вирішує отримати доступ до оновленого ЕВС через свою телефонну книгу, то механізм меню оновлює систему меню так само, як в процесі, ілюстрованому за допомогою процесу виявлення сервісів, аналогічно показаному на фіг. 9. Крім оновлення меню, механізм меню також може виконувати перекомпоновку того, як представлені способи як пункти меню. Для кожного об'єкта ЕВС способи ранжуються на основі наступних критеріїв: - Успіх транзакції - Частота транзакцій - Вартість транзакцій - Інші бізнес-правила Додатково до описаного вище, способи, які, ґрунтуючись на процесі виявлення сервісів, описаному вище, ідентифіковані як недоступні, більше не будуть показані в складі меню, тобто відсутні пункти меню, відповідні способу, які викликають недоступні сервіси. Така адаптивна перекомпоновка пунктів меню виконується на всіх рівнях багаторівневої системи меню. Тому два об'єкти ЕВС, які відносяться до одного й того ж контексту, будуть мати набір пунктів меню, розміщений по-різному. Кожен об'єкт ЕВС буде мати різне розміщення пунктів меню в залежності від того, як власник пристрою взаємодіє з цим об'єктом. Включено також додатковий критерій, суть якого в тому, що об'єкти ЕВС, що не використовують у взаємодії з користувачем протягом попередньо визначеного періоду часу, будуть мати за промовчанням розміщення пунктів, ґрунтуючись на загальній статистиці використання об'єктів ЕВС аналогічних категорій контексту. У системі меню також може використовуватися функція маскування, яка забезпечує взаємодію користувачів з окремими особами без необхідності спеціальної ідентифікації кожної окремої особи. Функція маскування використовує класифікацію контексту, відому як контекст "Group" [Група]. Контекст "Group" [Група] додатково ділиться на локальні та глобальні класи. Об'єкт ЕВС в контексті "local group" [локальна група] – це об'єкт, який є альтернативним ім'ям для групи об'єктів ЕВС, що зберігаються локально на пристрої користувача. Будь-яка дія з альтернативним ім'я є дією з усіма об'єктами ЕВС, зв'язаними з альтернативним ім'ям локальної групи. Проте, такі дії обмежуються тими, які можуть бути виконані в групі, наприклад відправлення SMS. Приклад використання функції маскування для контексту локальної групи показаний на фіг. 11. Як показано, SMS 1101 адресується з використанням альтернативного імені 1102 локальної групи. Функція маскування виконує відправлення SMS кожній окремій особі, ідентифікованій в об'єктах ЕВС 11031, 11032, 11033, 11034, які містяться в локальній групі. Об'єкт ЕВС з контекстом "global group" [глобальна група] може бути реалізований аналогічним чином. Проте, відмінність "локальної групи" від "глобальної групи" в тому, що "локальна група" створюється власником пристрою на пристрої шляхом маскування об'єктів ЕВС, які розміщені на пристрої, а "глобальна група" є об'єктом ЕВС зі служби глобального каталогу, який служить вказівником на інші об'єкти ЕВС. Масковані об'єкти ЕВС в "локальній групі" відомі власнику пристрою, оскільки передбачається, що екземпляри цих маскованих об'єктів зберігаються на пристрої, в той час як масковані об'єкти ЕВС в "глобальній групі" невідомі власнику пристрою. Масковані об'єкти ЕВС в "глобальній групі" зберігаються в базі даних служби каталогу. На фіг. 12 показано використання функції маскування для відправлення повідомлення об'єктам ЕВС в контексті або локальної, або глобальної групи. Як показано, користувач відправляє SMS на альтернативне ім'я групового контексту (етап 1201). Потім функція маскування виконує перевірку, чи є атрибут контекстної групи локальною групою (етап 1202). Якщо визначено, що група є локальною групою, то функція маскування виконує читання атрибута вказівника маски (етап 1204), який ідентифікує об'єкти ЕВС, що містяться в групі. Потім функція маскування виконує отримання об'єктів ЕВС з локального списку об'єктів ЕВС (етап 1205) і відправлення SMS кожній окремій особі, ідентифікованій отриманими об'єктами ЕВС (етап 1206). У випадку, коли ця група є глобальною групою, функція маскування надсилає SMS в службу глобального каталогу (етап 1203). Потім служба глобального каталогу виконує читання вказівника маски (етап 1204) для того, щоб отримати з бази даних відповідні об'єкти ЕВС (етап 1205). Після того, як служба глобального каталогу отримала об'єкти ЕВС, які входять до групи, виконується надсилання SMS кожній з окремих осіб, ідентифікованих отриманими об'єктами ЕВС (етап 1206). 11 UA 106108 C2 Потрібно розуміти, що варіанти здійснення, показані вище, представлені лише в якості прикладу цього винаходу, і що додаткові модифікації і покращення до нього, як буде очевидно спеціалістам в даній галузі техніки, вважаються тими, що знаходяться в межах об'єму цього винаходу, описаного в цьому документі. 5 ФОРМУЛА ВИНАХОДУ 10 15 20 25 30 35 40 45 50 55 60 1. Спосіб передачі контактної інформації між множиною передплатників мережі, причому згаданий спосіб містить етапи, на яких: збирають контактну інформацію на терміналі передплатника в електронну бізнес-карту; реєструють електронну бізнес-карту в каталозі, причому етап реєстрації електронної бізнескарти додатково включає: інкапсуляцію електронної бізнес-карти в об'єкт електронної бізнес-карти шляхом відображення текстових полів електронної бізнес-карти в один або декілька атрибутів, що містяться в об'єкті електронної бізнес-карти; передачу об'єкта електронної бізнес-карти в каталог; і збереження об'єкта електронної бізнес-карти в базі даних; отримують в каталозі набор параметрів пошуку від передплатника; здійснюють пошук в базі даних об'єктів електронної бізнес-карти, які відповідають параметрам пошуку; надають передплатнику списку об'єктів електронних бізнес-карт; отримують в каталозі запит від передплатника на об'єкт електронної бізнес-карти з наданого списку об'єктів електронних бізнес-карт; і пересилають передплатнику запитуваний об'єкт електронної бізнес-карти. 2. Спосіб за п. 1, який відрізняється тим, що етап реєстрації додатково включає етап перевірки дійсності набору мандата передплатника. 3. Спосіб за п. 2, який відрізняється тим, що мандат передплатника містить номер мобільного телефону відправника запиту та/або таку інформацію, яка може бути отримана від зазначеного відправника без його явної згоди або участі. 4. Спосіб за п. 2, який відрізняється тим, що мандат передплатника містить щонайменше одне з наступного: PIN-код, пароль і/або будь-яку подібну інформацію, яку сторона має надати у явному вигляді. 5. Спосіб за будь-яким з попередніх пунктів, який відрізняється тим, що параметри пошуку є набором ключових слів. 6. Спосіб за п. 5, який відрізняється тим, що етап отримання параметрів пошуку додатково включає етап аналізу отриманих ключових слів перед ініціацією пошуку. 7. Спосіб за будь-яким з попередніх пунктів, який відрізняється тим, що етап надання списку об'єктів електронних бізнес-карт додатково включає етап сортування та/або фільтрації результатів пошуку. 8. Спосіб за п. 7, який відрізняється тим, що сортування списку об'єктів електронних бізнескарт виконують відповідно до одного з наступного: зважування відповідно до верифікованого статусу об'єкта; підтвердження взаємовідносин як атрибутів об'єкта; рівня точності відповідності ключових слів; новизни інформації або булевої операції. 9. Спосіб за будь-яким з попередніх пунктів, який відрізняється тим, що додатково включає етап надання дозволу передплатнику або будь-якій уповноваженій стороні оновлювати або видаляти будь-які з атрибутів об'єкта електронної бізнес-карти. 10. Спосіб за п. 9, який відрізняється тим, що етап оновлення атрибутів і/або способів об'єкта електронної бізнес-карти виконують через множину користувацьких інтерфейсів. 11. Спосіб за п. 10, який відрізняється тим, що до складу користувацьких інтерфейсів користувачів входить щонайменше одне з наступного: веб-інтерфейс або wap-інтерфейс, локальна прикладна програма або система меню з використанням електронної пошти, SMS, MMS, флеш-повідомлення або ІР-технології. 12. Спосіб за будь-яким з попередніх пунктів, який відрізняється тим, що додатково включає етап отримання запиту на синхронізацію від передплатника. 13. Спосіб за п. 12, який відрізняється тим, що етап синхронізації додатково включає етапи, на яких: перевіряють існування об'єкта/об'єктів електронних бізнес-карт, на синхронізацію яких отримай запит; перевіряють налаштування конфіденційності або рівня доступу об'єкта/об'єктів електронних бізнес-карт, на синхронізацію яких отримано запит; 12 UA 106108 C2 5 10 15 20 25 30 35 40 45 50 55 60 відправляють повідомлення великого практичного значення власнику об'єкта/об'єктів електронних бізнес-карт, на синхронізацію яких отриманий запит, для надання дозволу або заборони цього запиту, ґрунтуючись на налаштуваннях конфіденційності або рівня доступу об'єкта/об'єктів електронних бізнес-карт; відправляють синхронізоване оновлення або копії об'єкта/об'єктів електронних бізнес-карт, на синхронізацію або завантаження яких отриманий запит, передплатнику, який відправив запит, якщо дозволено запит синхронізації; і відправлення відповідного повідомлення відправнику запиту. 14. Спосіб за будь-яким з попередніх пунктів, який відрізняється тим, що додатково включає етап верифікації і аутентифікації змісту об'єкта електронної бізнес-карти. 15. Спосіб за п. 14, який відрізняється тим, що етап верифікації і аутентифікації додатково включає етапи, на яких: позначають об'єкт, на верифікацію якого отриманий запит, як сертифікованого у випадку успішної верифікації або аутентифікації даних в об'єкті електронної бізнес-карти; і відправляють відповідне повідомлення зацікавленій стороні/сторонам. 16. Спосіб за п. 14, який відрізняється тим, що етап верифікації і аутентифікації додатково включає етапи, на яких: перевіряють об'єкт електронної бізнес-карти шляхом оцінки рівня достовірності; і послідовно позначають ті об'єкти, які відповідають рівню достовірності і перевищують попередньо встановлену граничну величину, яку встановлено під час перевірки. 17. Спосіб за п. 1, який відрізняється тим, що об'єкт електронної бізнес-карти містить один або декілька елементів великого практичного значення. 18. Спосіб за п. 17, який відрізняється тим, що один або декілька елементів великого практичного значення містять скрипти, які запускають прикладну програму, яка працює з внутрішніми пристроями, запускають прикладну програму або сервіси та/або ініціюють вебінтерфейс або wap-інтерфейс. 19. Спосіб за п. 1, який відрізняється тим, що об'єкт електронної бізнес-карти є вказівником та маскою для множини об'єктів електронних бізнес-карт, так що будь-яка дія користувача з об'єктом електронної бізнес-карти, який є вказівником на множину об'єктів електронних бізнескарт, рівноцінна тій же дії, виконаній окремо з кожним із об'єктів електронної бізнес-карти в такій множині об'єктів електронних бізнес-карт. 20. Система для полегшення передачі контактної інформації між передплатниками мережі, причому зазначена система містить: щонайменше один сервер, під'єднаний до мережі; щонайменше одну базу даних, під'єднану до серверу; множину терміналів підписчиків, під'єднаних до мережі, причому кожен термінал передплатника сконфігуровано для відправлення контактної інформації, асоційованої з передплатником, на сервер у відповідь на запит зазначеного передплатника; причому запит викликає виконання на терміналі передплатника компіляції контактної інформації в об'єкт електронної бізнес-карти, який має одне або декілька текстових полів, і відображення одного або декількох текстових полів електронної бізнес-карти в один або декілька об'єктних атрибутів, що містяться в об'єкті електронної бізнес-карти, і передачі об'єкта електронної бізнес-карти на сервер для зберігання в базі даних. 21. Система за п. 20, яка відрізняється тим, що кожний термінал передплатника містить механізм меню, пристосований для читання кожного об'єктного атрибуту, який міститься в об'єкті електронної бізнес-карти, і відображення множини меню, які містять пункти меню, що представляють одну або декілька функцій, які можуть бути виконані відносно контактної інформації, представленої об'єктом електронної бізнес-карти. 22. Система за п. 21, яка відрізняється тим, що об'єкту електронної бізнес-карти призначено контекст, і механізм меню пристосовано для генерування набору пунктів меню за замовчуванням відповідно до призначеного контексту. 23. Система за п. 22, яка відрізняється тим, що механізм меню пристосовано до модифікації набору пунктів меню за замовчуванням для контексту в відповідь на модифікацію одного або кількох атрибутів об'єкта електронної бізнес-карти власника об'єкта електронної бізнес-карти. 24. Система за п. 20, яка відрізняється тим, що об'єкт електронної бізнес-карти містить один або декілька елементів великого практичного значення. 25. Система за п. 24, яка відрізняється тим, що один або декілька елементів великого практичного значення містять скрипти, які запускають прикладну програму, які працюють з внутрішніми пристроями, запускають прикладну програму або сервіс і/або ініціюють інтерфейс, що ґрунтується на Інтернет-технологіях або технологіях WAP. 13 UA 106108 C2 5 26. Система за п. 20, яка відрізняється тим, що об'єкт електронної бізнес-карти є вказівником та маскою для множини об'єктів електронних бізнес-карт, так що будь-яка дія користувача з об'єктом електронної бізнес-карти, який є вказівником на множину об'єктів електронних бізнескарт, рівноцінна тій же дії, виконаній окремо з кожним із об'єктів електронної бізнес-карти в такій множині об'єктів електронних бізнес-карт. 14 UA 106108 C2 15 UA 106108 C2 16 UA 106108 C2 17 UA 106108 C2 18 UA 106108 C2 19 UA 106108 C2 20 UA 106108 C2 21 UA 106108 C2 22 UA 106108 C2 23 UA 106108 C2 Комп’ютерна верстка Л. Литвиненко Державна служба інтелектуальної власності України, вул. Урицького, 45, м. Київ, МСП, 03680, Україна ДП “Український інститут промислової власності”, вул. Глазунова, 1, м. Київ – 42, 01601 24