Система ініціювання з’єднання між пристроями зв’язку щонайменш двох сторін

Реферат: Система ініціювання з'єднання між пристроями зв'язку щонайменш двох сторін складається з першого комунікативного пристрою для ініціації зв'язку між принаймні першим та другим комунікативними пристроями відповідно першої та другої сторін комунікації, включає: модуль конвертації, вбудований до машиночитаної пам'яті, для отримання коду-ідентифікатора абонента-отримувача від першої сторони, де код-ідентифікатор абонента-отримувача це рядок символів, серед яких принаймні один є нецифровим та відповідає даним ідентифікатора другої сторони; модуль передачі, вбудований до машиночитаної пам'яті, для прямої чи непрямої передачі запиту на визначення адреси до хост-сервера, де зберігається інформація про відповідний ідентифікатор абонента-отримувача. Запит на визначення адреси включає дані, що вказують на ідентифікатор абонента-отримувача; та модуль управління викликами, вбудований до машиночитаної пам'яті, для отримання відповіді на запит на визначення адреси, включаючи адресу абонента-отримувача - користувача другого комунікаційного пристрою, при цьому друга сторона є доступною, а також для ініціювання зв'язку між першим та другим комунікаційними пристроями. UA 71547 U (54) СИСТЕМА ІНІЦІЮВАННЯ З'ЄДНАННЯ МІЖ ПРИСТРОЯМИ ЗВ'ЯЗКУ ЩОНАЙМЕНШ ДВОХ СТОРІН UA 71547 U UA 71547 U 5 10 15 20 25 30 35 40 45 50 55 60 Корисна модель стосується ініціювання зв'язку. Раніше набір номеру на будь-якому комунікативному пристрої був можливий лише за допомогою цифр. Наприклад, RFC 3966 (запит коментарів для груп мережі, "Ідентифікатор ресурсів для телефонних номерів", 2004), що визначає URI (Універсальний код ресурсу) схеми "тел", який відображає ресурси, закріплені за телефонними номерами. Згідно з RFC, телефонний номер являє собою рядок десяткових цифр, який однозначно вказує на кінцеву точку мережі. Номер містить інформацію, необхідну для маршрутизації виклику до цієї точки. Місцезнаходження кінцевої точки номера телефону URI "тел" не обмежується рамками певної мережі. Це може бути як телефонна мережа загального користування, так і приватна телефонна мережа або Інтернет. Кінцева точка може бути фіксованим або бездротовим пристроєм і направляти сигнал до стаціонарного дротового, мобільного чи рухомого термінала. Термінал, до якого направляється сигнал, може підтримувати будь-які послуги електронного зв'язку (ECS), включаючи передачу голосу, даних та факсимільні повідомлення. URI може відноситись до ресурсів, що ідентифікуються телефонним номером як сторони, що викликає, так і сторони, що приймає дзвінок, і не тільки. Відтоді були розроблені методи та системи, що дозволяють переведення алфавітноцифрових символів у цифрові символи для набору номера. Наприклад, патент US2004018852 ("Методи та пристрої для конверсії алфавітно-цифрової адресної книги для пристроїв бездротового зв'язку", опубліковано у 2004) представляє систему та метод, що спрощує конвертацію алфавітно-цифрових символів у числові символи для набору номера. Система може також включати кишеньковий персональний комп'ютер (КПК), як частину пристрою бездротового зв'язку. Блок приймає введену інформацію з пам'яті, яка відображується на екрані КПК. Для набору номера будь-які алфавітно-цифрові символи, що записані в адресній книзі телефону, будуть автоматично конвертовані в цифрові еквіваленти. Наприклад, номер, записаний як 1-800-2EUDORA, при наборі конвертується у 18002383672. Система приймає введені до пам'яті дані та направляє їх до конвертора алфавітно-цифрових символів у цифрові, де літери та нецифрові символи конвертуються числа для набору номеру. Конвертоване число проводиться через фільтр невизначених символів, де невизначені символи відфільтровуються. Отримані в результаті дані передаються на дисплей комунікативного пристрою, де спочатку виконується вибіркове підтвердження, після чого набирається потрібний номер. Патент US 7,065,385 ("Пристрої, методи та комп'ютерні програмні продукти для набору телефонних номерів з використанням алфавітної вибірки", опубліковано у 2006 р.) описує метод набору телефонного номера з комунікаційного пристрою, до конструкції якого входить пристрій введення алфавітно-цифрових символів. Алфавітно-цифровий пристрій введення дозволяє проводити вибірку з цілого ряду алфавітних та цифрових символів. Вибраний з-поміж інших алфавітний символ зчитується пристроєм. Зчитаний алфавітний символ конвертується у цифровий. Цифровий символ, вибраний окремо з ряду алфавітних символів, зчитується. Відбувається набор номеру, який включає конвертований та зчитаний цифрові символи. Мобільні телефони, такі як стільникові чи телефони інших типів, зазвичай оснащені адресною книгою (тж. може називатись "телефонна книга"). Проте, телефонні книги включають лише певну встановлену кількість номерів, отже, для набору номеру, не введеного заздалегідь до адресної книги, користувач повинен спочатку ввести номер до адресної книги. Крім того, користувачі іноді використовують спеціальні прикладні програми для зберігання особистих даних та інформації (РІМ), наприклад, кишенькові персональні комп'ютери (КПК). Патент US 2006/0015819 («Комплексне портативне комп'ютерне обладнання, системи та послуги телекомунікації», опубліковано у січні 2006 p.), наприклад, надає аналіз інтегрованого портативного комп'ютера та телекомунікаційної системи. Функції портативного кишенькового комп'ютера та системи телефонного зв'язку поєднані як на фізичному, так і на оперативному рівні. Як приклад, надається інтегрований мобільний (стільниковий) комп'ютер-телефон. Крім усього іншого, функції портативного комп'ютера чітко та логічно відокремлені від функцій телефонної системи. Проте, вони можуть інтегруватись на оперативному рівні. Наприклад, прикладна програма системи телефонного зв'язку запускається на процесорі кишенькового комп'ютера. Аналогічно, портативний комп'ютер може виконувати прикладні програми, наприклад, телефонну книгу, яка може бути використана для запуску прикладних програм телефонії. У патенті US 5,337,347 ("Методи та способи прогресивного пошуку по базі даних, його припинення та динамічного подання інформації з використанням телефону", опубліковано у 1994 р.) подається метод та система пошуку віддаленої бази даних, використовуючи телефонний апарат, що з'єднується із системою обробки даних. Система обробки даних має 1 UA 71547 U 5 10 15 20 25 30 35 40 45 50 55 доступ до віддаленої бази даних, а телефонний пристрій включає компоненти передавача для передачі двотональних багаточастотних сигналів, в якому двотональні багаточастотні сигнали генеруються за допомогою клавіатури, з'єднаної з телефонним апаратом. Алфавітно-цифрові клавіші клавіатури використовуються для генерації запиту та посилання команди до системи обробки даних. Патент US 5,457,738 ("Методи та способи пошуку он-лайн довідників з телефонної станції", опубліковано у 1995 р.) надає опис способу та методів обробки та відображення об'єктів при пошуку бази даних користувачем телефонної станції. Телефонна станція являє собою комп'ютер з монітором, до якого під'єднаний вказівний пристрій. За методом згідно з патентом US 5,457,738, база даних, а також перший список показників виводиться на екран монітора, відображуючи масив об'єктів на екрані. Метод також включає отримання першого набору сигналів, пов'язаних із принаймні одним з об'єктів ряду, відображеного на моніторі; формування перших критеріїв пошуку на основі першого набору сигналів; відображення ряду даних з першого списку показників на основі перших критеріїв пошуку; отримання сигналу, що відноситься до одного з відображених даних та сигналу, що ідентифікує дані, вибрані користувачем. І, наприкінці, метод за патентом US 5,457,738, включає етап відображення щонайменш одного об'єкта, що являє собою номер телефону, що відповідає вибраним зі списку даним. Також існують навчальні публікації, що інструктують користувачів на предмет набору номерів інших користувачів без пошуку та попереднього запису їх номерів. Наприклад, патент US 6,963,638 ("Метод використання алфавітно-цифрових символів як номеру виклику", опубліковано у 1991 р.) описує спосіб використання алфавітно-цифрових символів для виклику номера з метою встановлення телефонного зв'язку, а також внутрішнього зв'язку всередині телекомунікаційних мереж та між ними. Проте, зазначені методи та способи потребують відповідного рівня техніки, що дозволятиме користувачеві проводити набір номерів інших користувачів без попереднього збереження їх номерів, оскільки набір номеру відбувається не з сервера набору телефонних номерів, а з комунікаційного пристрою користувача. В заявленій корисній моделі, пропонується система ініціювання з'єднання між пристроями зв'язку щонайменш двох сторін. Згідно із втіленням корисної моделі, система, яка складається з першого комунікативного пристрою для ініціації зв'язку між принаймні першим та другим комунікативними пристроями відповідно першої та другої сторін комунікації, включає: модуль конвертації, вбудований до машиночитаної пам'яті, для отримання кодуідентифікатора абонента-отримувача від першої сторони, де код-ідентифікатор абонентаотримувача це рядок символів, серед яких принаймні один є нецифровим та відповідає даним ідентифікатора другої сторони; модуль передачі, вбудований до машиночитаної пам'яті, для прямої чи непрямої передачі запиту на визначення адреси до хост-сервера, де зберігається інформація про відповідний ідентифікатор абонента-отримувача, при цьому запит на визначення адреси включає дані, що вказують на ідентифікатор абонента-отримувача; та модуль управління викликами, вбудований до машиночитаної пам'яті, для отримання відповіді на запит на визначення адреси, включаючи адресу абонента-отримувача користувача другого комунікаційного пристрою, при цьому друга сторона є доступною, а також для ініціювання зв'язку між першим та другим комунікаційними пристроями. Для з'ясування суті корисної моделі та можливості його практичного застосування, варіанти втілення корисної будуть описані шляхом варіативних прикладів, з доданням рисунків (схем), які: Фіг. 1 показує схему, що дозволяє нецифровий набір номеру, як один з варіантів втілення та реалізації корисної моделі. Фіг. 2 показує систему управління персональними даними інформації, що зберігається в інформаційному сервері зберігання даних, відповідно до одного з варіантів втілення корисної моделі. На фіг. 3 представлена блок-схема, яка ілюструє реєстрацію особистих даних абонентів. На початку та в модулі управління, відповідно до одного з варіантів втілення корисної моделі. На фіг. 4 представлена блок-схема, яка ілюструє реєстрацію особистих даних абонентів на сервері зберігання інформації, відповідно до одного з варіантів втілення корисної моделі. На фіг. 5 представлена блок-схема, яка ілюструє реєстрацію особистих даних абонентів на сервері зберігання інформації, відповідно до одного з альтернативних варіантів втілення корисної моделі. 2 UA 71547 U 5 10 15 20 25 30 35 40 45 50 55 Фіг. 6 включає в себе графічні ілюстрації реєстрації та оновлення екранів, відповідно до кількох варіантів втілення корисної моделі. На фіг. 7 представлена графічна ілюстрація, яка описує головну процедуру ініціювання телефонного з'єднання між першим абонентом та другим, відповідно до одного з варіантів втілення корисної моделі. На фіг. 8 представлена діаграма, яка ілюструє та включає основні модулі в 5 комунікаційних пристроях, відповідно до одного з варіантів втілення корисної моделі. На фіг. 9 представлена блок схема, яка ілюструє ініціалізацію активного телефонного з'єднання, відповідно до одного з варіантів втілення корисної моделі. На фіг. 10 представлена блок-схема, яка ілюструє ініціалізацію пасивного телефонного з'єднання, відповідно до одного з варіантів втілення корисної моделі. На фіг. 11 представлена блок-схема, яка ілюструє операції прийняття активного виклику, відповідно до одного з варіантів втілення корисної моделі. На фіг. 12 показана діаграма, яка ілюструє активний виклик, відповідно до одного з варіантів втілення корисної моделі. Фіг. 13 наводить приклад HTTP-запиту, що використовується для виділення/конвертування 15 ідентифікаторів абонентів, відповідно до одного з варіантів втілення корисної моделі. На фіг. 14 наведено приклад HTTP-відповіді, що надається у випадку отримання запиту на визначення адреси, відповідно до одного з варіантів втілення корисної моделі. Наступний опис містить компоненти, які є загальними для більшості малюнків, тому вони позначатимуться однаковими номерами. Фіг. 1 ілюструє системи 101, які дозволяють нецифровий набір номеру, відповідно до одного з варіантів корисної моделі. Згідно з варіантом, комунікаційні пристрої 102, такі, як мобільні телефони або, точніше, стільникові телефони, з'єднані із сервером зберігання інформації 103. Згідно з корисною моделлю, коли користувач, що має комунікаційний пристрій 102, бажає набрати номер з метою ініціювання телефонного з'єднання, наприклад, телефонного дзвінка, передачі коротких повідомлень (SMS), передачі мультимедійних повідомлень (MMS), ініціювання факсимільного зв'язку тощо, то замість набору номера призначення, він може набрати рядок, що ідентифікує номер абонента-отримувача. Набраний рядок передається на сервер зберігання інформації 103, де він конвертується у числове значення. Слід зазначити, що набраний рядок може включати будь-які символи і не обмежується тільки цифровими символами (для зручності, цифрові символи можуть називатись "цифри"). Точніше, відповідно до запропонованої корисної моделі, набраний рядок містить хоча б один нецифровий символ. Надалі, абонент, що набирає номер,являтиме собою "викликаючого абонента" або "першу сторону", тоді як номер або рядок, що набираються, належатимуть до "абонента-отримувача" або "другої сторони". Комунікаційний пристрій 102, з якого рядок набирається, являтиме собою "викликаючий комунікаційний пристрій". Набраний рядок, поданий на сервер зберігання інформації 103, отримує декілька альтернативних вихідних варіантів. Відповідно до одного з варіантів, сервер зберігання інформації 103, або додатковий пристрій набору номера 104, набирає заданий номер в порядку, відповідному до дзвінка за місцем призначення. Потім сервер зберігання інформації 103 або додатковий пристрій набору номера 104 передає дзвінок на комунікаційний пристрій, який викликається, таким чином встановлюючи зв'язок між викликаючим абонентом та отримувачем виклику. Крім того, сервер зберігання інформації 103 передає набраний номер викликаючому комунікаційному пристрою, що дозволяє здійснити виклик абонента-отримувача. Слід зазначити, що хоча на Фіг. 1 показані п'ять комунікаційних пристроїв 102, не існує ніяких обмежень для кількості комунікаційних пристроїв 102, з'єднаних із сервером зберігання інформації 103. Крім того, на малюнку, пристрій набору номера 104 ілюструється як зовнішній, відносно сервера зберігання інформації 103. Тим не менш в інших варіантах втілення корисної моделі пристрій набору номеру 104 може бути вбудованим у сервер зберігання інформації 103. У тих випадках, коли сервер зберігання інформації 103 передає конвертований номер до мобільного телефону абонента 102, в системі 101 може і не бути пристрою набору номера 104. Крім того, незважаючи на те, що на малюнках всі комунікаційні пристрої ілюстровані як мобільні телефони, слід зазначити, що це не є обмеженням для інших комунікаційних пристроїв, таких як кишенькові комп'ютери, дротові-телефони, факсимільні апарати та інші комунікаційні пристрої, що дозволяють телефонний зв'язок мінімум двох сторін. Відповідно, замість використання терміну "з'єднання по телефону" (наприклад, у словосполученні "ініціація з'єднання по телефону"), використовуватиметься більш загальний термін "зв'язок" (як, наприклад, "ініціювати зв'язок"). 3 UA 71547 U 5 10 15 20 25 30 35 40 45 50 55 60 Слід зазначити, що в контексті запропонованої корисної моделі, сервер зберігання інформації 103, може належати "організації", яка, в свою чергу, може бути приватною, громадською організацією або навіть фізичною особою. Наприклад, певна компанія може мати сервер зберігання інформації 103, де зберігаються особисті дані співробітників компанії. Або, інший приклад, сервер зберігання інформації 103 належить телекомунікаційній компанії, і ця компанія може зберігати на вказаному сервері персональні дані абонентів, які користуються її послугами. Отже, надалі, за винятком окремих зазначених випадків, термін "абонент" означатиме особу, чиї особисті дані зберігаються на сервері зберігання інформації 103, при тому, що, відповідно до корисної моделі, персональні дані включають принаймні один телефонний номер абонента. Проте, особисті дані можуть включати також і додаткову інформацію, а саме: адресу електронної пошти абонента (e-mail), адресу його веб-сторінки, його домашню адресу, номер робочого телефону, номер домашнього телефону, номер мобільного телефону, робочу адресу та адресу робочої електронної пошти, IMS адресу тощо. Організація може управляти персональними даними, що зберігаються на сервері 103, зокрема додавати та видаляти особисті дані, що зберігаються в ньому. Наприклад, приймаючи на роботу нового співробітника, рекрутер може додати особисті дані нового співробітника на свій сервер зберігання інформації 103. На фіг. 2 зображено систему 201 для управління особистими даними, що зберігаються на сервері інформації 103, відповідно до одного з варіантів втілення корисної моделі. Вхідний координуючий модуль 202, під'єднаний до сервера зберігання інформації 103, використовується для управління персональними даними, що зберігаються на сервері 103. Проте, хоча на малюнку показаний тільки один вхідний координуючий модуль 202, слід мати на увазі, що кількість таких модулів може бути різною, або ж такий модуль може бути взагалі відсутнім. До того ж, окрім вхідного координуючого модуля 202, для управління інформацією, що зберігається на сервері 103, можна використовувати альтернативні вхідні координуючі модулі 202, такі як мобільні телефони 203 та інші пристрої, з'єднані із сервером зберігання інформації. Окрім використання вхідних координуючих модулів 202, управління інформацією на сервері 103 можна здійснювати за допомогою також альтернативних вхідних координуючих модулів, таких як мобільні телефони 203 та інші пристрої, під’єднанні до сервера зберігання інформації. Так, наприклад, користувач, особисті дані якого зберігаються на сервері 103, може додати до інформації на цьому сервері свій інший або додатковий номер телефону, який зберігатиметься там. Слід також зазначити, що телефон 203, що використовується для управління персональною інформацією, може бути використаний і як комунікаційний пристрій 102 для набору рядка символів. Однак це не є обов'язковим, отже, інколи телефони 203 не використовуються для набору рядків. Крім того, можна використовувати додаткові або альтернативні вхідні координуючі модулі, наприклад, кишенькові персональні комп'ютери (КПК) 204 та/або веб-браузери 205 чи інші. Таким чином, будь-який пристрій, з'єднаний із сервером зберігання інформації, що використовується для управління персональними даними на зазначеному сервері, може вважатись вхідним координуючим модулем. Спираючись на фіг. 1 та 2, слід відзначити, що відповідно до запропонованої корисної моделі, серверів зберігання інформації 103 може бути більше, ніж один. Сервер зберігання інформації 103 може належати більш, ніж одній організації, і, в той же час, кожна організація може мати один або кілька серверів зберігання інформації 103, тож водночас може існувати більш, ніж один сервер зберігання інформації 103. На сьогодні існує аналогічна ситуація щодо серверів електронної пошти, коли різні організації мають один або декілька серверів електронної пошти. Таким чином, згідно з корисною моделлю, кожен сервер зберігання інформації 103 має відповідний унікальний ідентифікатор, тобто "ідентифікатор сервера". Ідентифікатор сервера може бути унікальною комбінацією значень, в тому числі рядком, що включає алфавітно-цифрові символи та знаки пунктуації, такі як '.', '_' та інші. Відповідно до одного з варіантів втілення корисної моделі, ідентифікатор сервера може являти собою "ім'я домену", за яким зазвичай ідентифікується сервер, наприклад, в мережі Інтернет або поштовий сервер. Таким чином, кожний абонент, відповідні особисті дані якого зберігаються на сервері зберігання інформації 103, має ідентифікатор, який є унікальним для конкретного сервера 103. Вказаний ідентифікатор є "ідентифікатором абонента", який, так само як ідентифікатор сервера, може бути унікальною комбінацією значень, в тому числі рядком, що включає алфавітно-цифрові символи та знаки пунктуації, такі як '.', '_' та інші. Відтак, певний інформаційний сервер 103, ідентифікатор якого, наприклад, "SOMESERVER", може зберігати інформацію тільки про одного абонента, ідентифікатор якого "ALMONI", персональної інформації інших абонентів з ідентифікатором "ALMONI" на інформаційному сервері SOMESERVER бути не може. Тим не менш, інший інформаційний сервер 103 з 4 UA 71547 U 5 10 15 20 25 30 35 40 45 50 55 60 ідентифікатором, наприклад, "ANOTHERSERVER", також може зберігати особисті інформаційні дані іншого абонента з ідентифікатором ALMONI, у той же час слід враховувати, що абоненти ідентифіковані як ALMONI на SOMESERVER та ANOTHERSERVER можуть бути однаковими або різними. Тут і далі, сервер зберігання інформації, який зберігає інформацію певного абонента, називається "хост-сервер зберігання інформації". В останньому прикладі, SOMESERVER - це хост-сервер, що зберігає інформацію ALMONI. Слід зазначити, однак, що відповідно до одного з варіантів втілення корисної моделі, ідентифікатор абонента та ідентифікатор сервера завжди розглядаються як рядки, навіть у тих випадках, коли ідентифікатор складається тільки з цифр. Це відрізняється від звичайних телефонних номерів, наприклад, де ідентифікатори відповідають телефонним лініям (а не абонентам) і в яких набір здійснюється по номерах. В різних варіантах, де ідентифікатор абонента, також розглядається як рядок, ідентифікатор абонента повинен містити принаймні один нечисловий символ, та, згідно з ще одним варіантом втілення корисної моделі, ідентифікатор не повинен містити жодного числового символу. Більш того, аналогічні чи інші принципи можуть бути використані для ідентифікаторів сервера та для ідентифікаторів абонента. Наприклад, ідентифікатори сервера, згідно з однією з модифікацій, можуть включати цифрові символи, проте ідентифікатори абонента не можуть, і т.д. Надалі "дозвіл абонента" означає отримання ідентифікатора абонента-користувача та передачу знайдених відповідних персональних даних або їх частини. Виходячи з того, що може існувати більш ніж один сервер зберігання інформації, та у випадку наявності більше одного сервера зберігання інформації, поєднаних між собою, зрозуміло, що для того, щоб надати дозвіл абонента, ідентифікатор абонента, а також відповідний ідентифікатор сервера, повинні бути визначені. Відповідно до одного з варіантів, якщо ідентифікатор сервера відомий заздалегідь, можна отримати тільки ідентифікатор абонента. Наприклад, якщо відомо, що дозвіл абонента повинен бути наданий на SOMESERVER, цього достатньо для отримання ідентифікатора абонента (наприклад, "ALMONT"), щоб отримати особисті дані абонента. Проте, це не є обов'язковим, і в інших модифікаціях може вимагатись, щоб ідентифікатор сервера завжди надходив разом з ідентифікатором абонента. На малюнку 3 представлена блок-схема, яка показує реєстрацію персональних даних абонента у вхідному модулі управління 202, відповідно до одного з варіантів втілення корисної моделі. Відповідно до зазначеної блок-схеми, надаються ідентифікатор абонента та ідентифікатор сервера, хоча, як вже відомо, інші варіанти також допустимі. Відповідно до блоксхеми, вхідний модуль управління 202 отримує (301) рядок ідентифікатора абонента (ідентифікатор абонента) та рядок ідентифікатора сервера (ідентифікатор сервера). Вхідний модуль управління 202 може отримувати ідентифікатор з будь-якого доступного джерела, наприклад, з клавіатури комп'ютера або телефону абонента. Модуль може зчитувати рядок ідентифікатора з бази даних, та може отримати його з лінії зв'язку і т. д. Слід врахувати, таким чином, що вхідний модуль управління 202 може працювати в ручному режимі (наприклад, коли оператор вводить дані вручну) або він може працювати в автоматичному режимі (наприклад, при зчитуванні інформації з бази даних та її використання з метою оновлення даних на сервері). Після отримання рядків ідентифікаторів в 301 вказаний сервер з'єднується з 302. Потім, на 303 вхідний модуль управління 202 отримує персональні дані абонента та на 304 він передає ці дані на сервер. Як зазначено, згідно з 301, на 303 вхідний модуль управління 202 може отримувати персональні дані з будь-якого доступного джерела, наприклад, з клавіатури комп'ютера або телефону абонента. Він може зчитувати персональну інформацію з бази даних та може отримати її з лінії зв'язку і т.д. Слід зазначити, що, також, посилаючись на 303, вхідний модуль управління 202 може працювати в ручному режимі (наприклад, коли оператор вводить дані вручну) або він може працювати в автоматичному режимі (наприклад, при зчитуванні інформації з бази даних та її використання з метою оновлення даних на сервері). Процес повторюватиметься, доки на 305 не з'являться додаткові абоненти, чиї персональні дані мають бути зареєстровані. Таким чином, в тих випадках, коли 301 і 304 працюють в автоматичному режимі, завершення реєстрації може проходити автоматично, не потребуючи ручного введення. Цей спосіб може бути використаний для реєстрації персональних даних окремого абонента, а також для реєстрації персональних даних багатьох абонентів, наприклад, для "масової реєстрації". Проте, блок-схема на фіг. 3, не є остаточною чи незмінною, її альтернативні модифікації також можливі. Наприклад, відповідно до однієї з модифікацій, коли 301 отримує рядки ідентифікатора абонента та ідентифікатора сервера це може відбуватися одночасно з отриманням на 303 даних абонента. Крім того, рядок ідентифікатора сервера може бути отриманий в одній операції, наприклад, в 301, в якому рядок ідентифікатора абонента та його дані отриманні в іншій операції, наприклад, в 303. Іноді немає необхідності безпосереднього 5 UA 71547 U 5 10 15 20 25 30 35 40 45 50 55 60 підключення до сервера (операція 302) з метою забезпечення передачі рядку ідентифікатора та відповідної інформації про абонента (304), і т.д. На фіг. 4 представлена блок-схема ілюструє реєстрацію персональних даних абонента на сервері 103, відповідно до одного з варіантів втілення корисної моделі. Після отримання на 401 рядку з ідентифікатором абонента та його персональними даними, сервер перевіряє на 402 чи існує вже запис рядка ідентифікатора абонента, схожий на один з отриманих. Якщо це так, та унікальний рядок ідентифікатора абонента вже є в пам'яті сервера, сервер відмовляється реєструвати особисті дані абонента. У такому випадку сервер передає на 403 вказівку зі статусом помилки, вказує помилку та її причини. Однак, якщо на 402 сервер отримує дані про те, що такого рядка ідентифікатора абонента не існує, на 404 він зберігає отриманий рядок ідентифікатора абонента та асоціює його із отриманими персональними даними абонента, і на 405 сервер передає вказівку зі статусом успішної реєстрації. При зберіганні отриманого рядка ідентифікатора абонента він асоціюється з отриманими персональними даними абонента, існують різні способи асоціювання. Наприклад, відповідно до одного з варіантів, отримані персональні дані абонента зберігаються в базі даних, в той час як отриманий рядок ідентифікатора абонента використовується як ключ. Згідно з іншим варіантом, отримані персональні дані абонента зберігаються у файлі, в той час як ім'ям файла буде отриманий рядок ідентифікатора абонента. Інші альтернативи допустимі також, тільки у разі, якщо персональні дані абонента можуть бути знайдені, з використанням рядка ідентифікатора абонента як ключа пошуку. Слід зазначити, що відповідно до варіанта блок-схеми на фіг. 4 не має механізму для забезпечення поновлення персональних даних абонента. Таким чином, в альтернативному варіанті, показаному як приклад на рисунку 5, оновлення особистих даних не допускається. Як і в схемі на малюнку 4, так і в цьому випадку, по отриманні на 501 рядка ідентифікатора абонента та персональних даних, сервер перевіряє на 502 чи існує вже запис рядка ідентифікатора абонента, схожий на один з отриманих. Однак, на відміну від малюнка 4, якщо рядок ідентифікатора абонента вже існує, сервер 103 виконує перевірку на 503 для отримання вказівки, щодо оновлення персональних даних абонента. Така вказівка може бути отримана, наприклад, як код операції разом з рядком ідентифікатора абонента та його персональних даних, або будь-яким іншим способом, який застосовуються в залежності від попередньої конфігурації сервера. Якщо персональні дані абонента мають бути оновленими, на 504 персональні дані отримані на 501 зберігаються, таким чином замінюючи існуючі персональні дані отриманими персональними даними, а з 505 сервер 103 передає вказівку того, що персональні дані абонента були повністю оновлені. Крім того, якщо на 503 сервер 103 визначає, що персональні дані абонента не повинні бути оновлені, на 506 передається індикатор статусу помилки. При поверненні на 502, якщо сервер 103 визначає, що такого рядка ідентифікатора абонента не існує, на 507 він зберігає отриманий рядок ідентифікатора абонента та асоціює його з отриманими персональними даними абонента, і на 408 сервер передає індикатор того, що абонент був успішно зареєстрований. З цією метою, персональні дані зберігається як "одиниці персональних даних". Одиниця персональних даних може включати в себе поля для зберігання інформації. Після реєстрації або при оновленні персональних даних абонента, визначаються дані, що відносяться до одного або більше з доступних полів. Крім того, відповідно до одного з варіантів, кожна одиниця персональних даних може мати одне з включених до неї полів, яке є активним. Наприклад, до персональних даних Almoni додається номер його домашнього, мобільного та робочого телефону. Коли абонент Almoni перебуває вдома, він може встановити свій домашній телефонний номер як активне поле. Коли Almoni йде з дому по дорозі в офіс, він встановлює свій номер мобільного телефону як активне поле, а потім, по прибутті до офісу, він встановлює номер робочого телефону як активне поле. Відповідно до цього прикладу, абонент може використовувати мобільний телефон або будь-який зовнішній модуль управління для того, щоб встановити активне поле. Крім того, абонент Almoni також можете встановити таймер для автоматичної зміни активних полів відповідно одиницям його особистих даних. Наприклад, на 8:00 ранку номер мобільного телефону Almoni автоматично переходить до активного поля, а о 9:30 ранку до активного поля автоматично передається робочий номер телефону Almoni, о 19:00 вечора активним полем автоматично стає номер мобільного телефону Almoni, а в 19:30 вечора номер його домашнього телефону стає активним полем. Абонент може використовувати зовнішній модуль управління також для оновлення персональних даних або їх частини, тобто, для того, щоб оновити дані, які зберігаються в одному або декількох полях його одиниць персональних даних. Дані абонента можуть бути представлені у вигляді форми, яка включає поля, підтримувані сервером 103, після чого йому пропонується заповнити обов'язкові поля (наприклад, 6 UA 71547 U 5 10 15 20 25 30 35 40 45 50 55 60 ідентифікатор абонента) та необов'язкові поля. Коли абонент завершує внесення його персональних даних або їх частини до форми, він підтверджує передачу введених даних на сервер 103. Крім того, можливі деякі варіанти втілення, що дозволяють абонентам надавати текстові команди, наприклад, за допомогою командного рядка на комп'ютері зовнішнього модуля управління, надіславши коротке повідомлення (SMS) з мобільного телефону, або шляхом передачі таких текстових команд з програми запущеної на зовнішньому модулі управління до сервера 103. Текстова команда повинна включати, принаймні вказівки до тих полів, зміст та персональні дані яких повинні бути оновленими. Крім того, слід зазначити, що текстові команди можуть бути використані для реєстрації нових абонентів, а також для оновлення персональних даних вже зареєстрованих абонентів. Малюнок 6 подає графічні ілюстрації екранів реєстрації та оновлення, згідно з декількома варіантами втілення корисної моделі. Абонент, який реєструється з ідентифікатором абонента "ALMONI" вводить номери своїх домашнього та мобільного телефонів, відповідно 111111 та 222222. Відповідно до цього, наприклад, тільки поля ідентифікатори абонента є обов'язковим, і, дійсно, ALMONI не надає ні інформацію для поля з номером робочого телефону, ні для іншого поля. 601 відображує реєстраційне поле, яке з'являється перед тим, як абонент передає інформацію на сервер 103. Коли ALMONI вирушає у подорож, він додає свій готельний номер у поле "інший номер", як показано на 602. Готельний номер 333333. Слід зазначити, що абонент не оновлює свій домашній та мобільний номери при оновленні його готельного номеру, залишивши їх 111111 та 222222 відповідно. Згідно з цим варіантом, інша інформація має включати вказівку на тип інформації, включаючи слово "готель". Проте, зазначена вказівка не є обов'язковою умовою, тобто в інших варіантах номер "333333" може бути вказаний як персональні дані (без слова "Готель"). По повернені додому, Almoni бажає видалити готельний номер з його персональних даних. 603 ілюструє екрани реєстрації та оновлення, які з'являються перед тим, як дані будуть передані на сервер, і сервер отримає вказівку на видалення зазначених даних абонента. Згідно з даним варіантом, абонент, шляхом команди видалення, вказує, що він бажає видалити вміст запису, збереженого в полі для іншої інформації. У цьому прикладі безпосередньо вказівкою на видалення буде . З прикладу, наведеного в 601, 602 і 603, виходить, що один і той же абонент (в даному випадку Almoni) може за бажанням оновлювати свої персональні дані у будь-який момент. Враховуючи, що при експлуатації, наприклад, мобільного телефону, абонент зазвичай щоразу застосовує один і той же пристрій, для збереження використовуваної інформації можна застосовувати пам'ять телефону. Згідно з даним прикладом, можна зберігати ідентифікатор абонента "Almoni" або навіть повний набір персональних даних у тому вигляді, в якому вони нещодавно оновлені або зареєстровані. Отже, форми можуть бути заповнені автоматично і включати найбільш актуальну, нещодавно оновлену інформацію. В іншому варіанті, замість використання помітки для видалення, абонент може видалити інформацію шляхом введення "порожньої інформації" у певне поле, яка буде передана на сервер зберігання інформації. Таким чином, порожня інформація в цьому варіанті вважатиметься командою видалення. В іншому випадку, якщо абонент хоче замінити інформацію, що зберігається в одному чи більше полів, він просто набирає оновлену інформацію в бажаних полях, замінюючи стару інформацію новою. 604 показує екран оновленого поля після реєстрації (див., наприклад, 601); абонент залишає свій домашній номер без змін, додає номер робочого телефону (555555) та інший номер (готельний номер 333333), а також змінює номер свого мобільного телефону на 444444 (замість 222222). Потім, в 605, відповідно до останнього варіанта, абонент видаляє інший номер, шляхом передання порожньої інформації до настроюваного поля. Після збереження персональних даних на сервері 103, інформація, незалежно від того, чи вона була новозареєстрованою або оновленою, може бути використана для автоматичного набору номерів телефонної книги в режимі он-лайн. Замість набору телефонного номера, як це зазвичай відбувається при виконанні виклику з телефону, згідно з одним з варіантів втілення корисної моделі, викликаючий абонент може набрати ідентифікатор абонента-отримувача. Відповідно, телефон передасть ідентифікатор абонента на сервер зберігання даних для конвертування номера абонента-отримувача, який буде набраний і, отже, викликаючий абонент матиме змогу провести телефонну розмову з абонентом-отримувачем. Припустимо умовно, що абонент хоче викликати свого товариша "Almoni Johns", який працює в компанії "Someplace". Компанія "Someplace" зберігає інформацію на власному сервері 7 UA 71547 U 5 10 15 20 25 30 35 40 45 50 55 під назвою "SomeServer", тобто SomeServer є хост-сервером, де зберігається інформація Almoni. Ідентифікатором абонента Almoni Johns є Almoni, отже, викликаючий абонент набирає "almoni " на своєму телефоні. Слідом телефон абонента передає ідентифікатор "almoni" на сервер зберігання інформації "SomeServer", де він конвертується у номер 7777777. Таким чином, набирається номер 7777777, дозволяючи викликаючому абоненту провести телефонну розмову із абонентом Almoni Johns. Відповідно до одного з варіантів втілення корисної моделі, телефон чи будь-який інший пристрій зв'язку 102, яким користується викликаючий абонент, повинен бути оснащений "модулем конвертації", який, зокрема, може бути комп'ютерною програмою. Відповідно до одного з варіантів, показаного на малюнку 7, після отримання ідентифікатора абонента на 701, модуль конвертації передає його на 702, до відповідного хост-сервера зберігання інформації. При передачі на хост-сервер, ідентифікатор абонента є запитом на визначення адреси або його компонентом. Відповідно до одного з варіантів, для того, щоб передати на хост-сервер запит на визначення адреси, модуль конвертації під'єднується до сервера зберігання інформації за замовчуванням, який є "базовим сервером зберігання інформації". Модуль конвертації передає запит на визначення адреси до відповідного базового сервера зберігання інформації, який далі передає його на хост-сервер зберігання інформації. Передача може бути прямою або непрямою, при цьому пряма передача означає, що базовий сервер зберігання інформації передає запит на визначення адреси безпосередньо на хост-сервер, тоді як непряма передача означає, що базовий сервер зберігання інформації передає запит на визначення адреси до певного доступного проміжного об'єкта, що передає запит на визначення адреси, який, в свою чергу, врешті надходить на хост-сервер. Проміжним об'єктом може бути сервер зберігання інформації, проте це може бути також будь-який інший об'єкт, пристосований для передачі даних з одного сервера зберігання інформації до іншого. Таким чином, і якщо інше не вказано конкретно, передання чи отримання даних модулем конвертації (в тому числі персональних даних, запиту на визначення адреси, номерів телефонів та/або будь-яких інших даних) на сервер зберігання інформації або з нього означатиме можливість прямого чи непрямого передання або отримання даних модулем конвертації. Крім того, існує більш ніж один спосіб передання ідентифікатора абонента на відповідний хост-сервер зберігання інформації. Одним з таких способів є використання служби коротких повідомлень (SMS), коли запит передається за допомогою повідомлення SMS, яке надсилається на базовий сервер зберігання інформації. При цьому, враховуючи, що ідентифікатор абонента може передаватись шляхом SMS - повідомлення, це означає, що його також можна передавати за допомогою Служби мультимедійних повідомлень (MMS). Іншими можливостями з'єднання з базовим сервером зберігання інформації є: підключення до сервера та передача повідомлень із запитом через мережу Інтернет; передача ідентифікатора абонента за допомогою USSD (Технологія передачі неструктурованих даних в GSM-мережах); передача ідентифікатора абонента через CAMEL (Європейський інститут телекомунікаційних стандартів, "Кастомізовані програми для мобільних мереж з розширеною логікою"); передача через HTTP (Протокол передачі гіпертексту), тощо. Повертаючись до схеми на фіг. 7, після передачі запиту на визначення адреси на базовий сервер зберігання інформації, на 703 телефон викликаючого абонента ініціює телефонний зв'язок з абонентом-отримувачем. Однак слід зазначити, що корисна модель не обмежується використанням лише телефонів, замість яких можуть бути використані також інші комунікаційні пристрої, як було зазначено вище, див., наприклад, фіг. 1. Для ініціювання телефонного зв'язку може використовуватись модуль управління викликами. Модуль конвертації 801 та модуль управління викликами 802 подаються на малюнку 8, який являє собою блок-схему, що показує основні модулі, які входять до комунікаційного пристрою 102, відповідно до одного з варіантів втілення корисної моделі. Комунікаційний пристрій 102 на рис. 8 включає в себе також модуль передачі 803 для передачі запиту на визначення адреси до сервера зберігання інформації. Розглянемо модуль управління викликами 802, зважаючи на те, що ініціація зв'язку може бути або пасивною, або активною. Фіг. 9 представляє блок-схему для ілюстрації активної ініціації зв'язку, згідно з одним з варіантів втілення корисної моделі. На 901 модуль управління викликами 802 отримує номер телефону, який є номером телефону абонента-отримувача, як відповідь на повідомлення із запитом, а на 902 він автоматично набирає отриманий номер для ініціації зв'язку. Проте, це не єдиний з можливих варіантів ініціації зв'язку - замість автоматичного набору номера модуль управління викликами 802 може відобразити його на екрані комунікаційного пристрою, таким чином дозволяючи оператору ініціювати виклик вручну. 8 UA 71547 U 5 10 15 20 25 30 35 40 45 50 55 60 На фіг. 10 представлена блок-схема для ілюстрації пасивної ініціації зв'язку, згідно з одним з варіантів втілення корисної моделі. Пасивна ініціація виклику означає, що виклик є активно ініційованим іншою стороною, наприклад, базовим сервером зберігання інформації чи будьяким іншим суб'єктом виклику, призначеним для вказаної задачі. Суб'єкт виклику викликає номери абонента-отримувача та викликаючого абонента, з'єднуючи обидва виклики. Згідно з цим варіантом, на 1001 модуль управління викликами 802 отримує запит на з'єднання, наприклад, запит на з'єднання системи сигналізації № 7 (СКС-7), запит на з'єднання Протоколу ініціації сеансу (SIP), або будь-який інший запит на з'єднання в залежності від типу комунікаційного пристрою, який використовується. Реагуючи на запит на з'єднання, на 1002 модуль управління викликами 802 подає користувачеві сигнал запиту на з'єднання, який може бути, наприклад, дзвінком, миганням екрана тощо, і дозволяє оператору відреагувати на виклик. Фіг. 11 представляє блок-схему, що показує операції, виконувані суб'єктом виклику, відповідно до одного з варіантів корисної моделі. Відповідно до запиту, на 1101 суб'єкт виклику отримує номер телефону. Слід пам'ятати, що зазначений телефонний номер є номером абонента-отримувача (або "другої сторони"). Крім того, для функціонування корисної моделі передбачене використання не тільки цифрових символів. Наприклад, замість номера телефону, суб'єкт виклику може отримати адресу Інтернет-телефону або сервісу для обміну повідомленнями із можливістю голосового спілкування тощо. Тому, замість слова "номер" в термінах "номер телефону", "номер телефону абонента-отримувача", "телефонний номер другого абонента" і т.д., може бути використане слово "адреса" (напр., "адреса абонентаотримувача", "адреса другого абонента" і т.д.) На 1102 суб'єкт виклику надсилає запит на підключення викликаючій стороні, очікуючи відповіді з боку викликаючої сторони (див. 1103 та 1104). Виклик між суб'єктом виклику та викликаючою стороною називатиметься «першим викликом», при цьому слід враховувати, що, якщо лінія викликаючої сторони зайнята, то, відповідно до певних варіантів корисної моделі, суб'єкт виклику повторюватиме спроби встановлення першого виклику. Проте, допускаються також інші варіанти, наприклад, безпосереднє припинення подальших спроб при з'ясуванні, що лінія зайнята. Крім того, якщо на лінію викликаючої сторони надходить дзвінок, або суб'єкт виклику отримує сигнал на очікування виклику, суб'єкт виклику може як певний час очікувати відповіді абонента на виклик, так і відмінити виклик. Коли викликаючий абонент відповідає на перший виклик (на 1103), на 1105 суб'єкт виклику надсилає запит на підключення абоненту-отримувачу, для ініціації з'єднання, що буде "другим викликом". Хоча це не показано на блок-схемі, суб'єкт виклику, знову-таки, може повторити спробу підключення до зайнятої лінії та/або чекати на сигнал виклику/очікування виклику тощо, доки абонент-отримувач не відповість на виклик, потім на 1106, суб'єкт виклику, відповідно до запропонованої корисної моделі, з'єднує перший та другий виклик, забезпечуючи відтак зв'язок між двома сторонами. Однак, згідно з іншим варіантом втілення корисної моделі, відразу ж після підключення до абонента на 1103, суб'єкт виклику може запросити з'єднання з абонентом-отримувачем (1105) та на 1106 з'єднати обидва виклики. У цьому випадку, наприклад, якщо лінія абонента-отримувача буде зайнята, викликаючий абонент почує сигнал зайнятої лінії. Слід мати на увазі, що суб'єкт виклику може з'єднати два виклики, використовуючи для кожного різні протоколи та техніку. Наприклад, перший виклик може бути звичайним телефонним дзвінком (напр., за допомогою СКС-7), тоді як другий виклик може бути з пристрою інтернет-телефонії (напр., за допомогою SIP). В цьому випадку суб'єкт виклику виступає як шлюз, що дозволяє зв'язок між двома сторонами з використанням різних протоколів. На фіг. 12 подана блок-схема, що показує суб'єкт виклику 1201, відповідно до одного з варіантів корисної моделі. Згідно з продемонстрованим варіантом, суб'єкт виклику включає в себе модуль підключення СКС-7, 1202, який дозволяє встановити з'єднання та ініціювати виклики між двома звичайними телефонами, отже, він підключається до звичайних телефонних мереж за допомогою кабелів. При використанні комунікаційних засобів IP-телефонії (VoIP), з'єднання зазначеного суб'єкту виклику відбувається за допомогою устаткування для IP-з'єднань і включає SIP модуль підключення 1203. Окрім вищезазначеного, суб'єкт виклику може підключитись до будь-якого необхідного комунікаційного устаткування, за умови наявності підключеного відповідного модуля. Представлений суб'єкт виклику дозволяє, зокрема, з'єднання з протоколом користувача через модуль з'єднання протоколу користувача 1204. Крім модулів підключення 1202, 1203 та інших, суб'єкт виклику 1201 включає також міст модуля з'єднання викликів 1205 (див., напр., 1106 на фіг. 11). Слід зазначити, що описані вище варіанти втілення корисної моделі надають опис зв'язку між двома сторонами. Однак, використання корисної моделі не обмежується рішеннями для зв'язку між лише двома сторонами, отже, в ході подальшого ознайомлення із характеристикою 9 UA 71547 U 5 10 15 20 25 30 35 40 45 50 55 корисної моделі, фахівці з'ясували, що корисну модель можна використати також і для комунікації декількох сторін, наприклад, для конференц-зв'язку. Слід також зазначити, що під час прийому-виклику сучасні комунікативні пристрої зазвичай відображують на екрані номер викликаючого абонента (ідентифікуюча інформація). Згідно з іншим варіантом втілення корисної моделі, при отриманні виклику з ідентифікуючою інформацією, телефон абонента-отримувача може прямо чи опосередковано передати зворотний запит на визначення адреси до хост-сервера, де зберігається інформація (103), в якому зворотний запит на визначення адреси включає дані ідентифікуючої інформації. Слід врахувати, що в цьому випадку зворотний запит на визначення адреси вказує ідентифікуючу інформацію про виклик, яка зазвичай є номером телефону, тоді як відповідь на зворотний запит на визначення адреси може включати будь-яку інформацію, що зберігається в полі персональних даних викликаючого абонента, якщо такі дані є в наявності. Таким чином виходить, що після отримання відповіді на зворотний запит на визначення адреси разом із даними викликаючого абонента, зазначена інформація може відображатись на екрані пристрою абонента-отримувача. Наприклад, можливим є відображення імені викликаючого абонента замість його номеру. Крім того, в інших випадках, може бути показана його адреса, посада чи звання (напр., звернення Пан, Пані, Доктор і т. і.) або будь-яка інша інформація, отримана у відповідь на зворотний запит на визначення адреси. Слід звернути увагу на конвертацію, зокрема, у 702 на фіг. 7, про яку йшлося в контексті пояснення можливостей передання ідентифікатора абонента шляхом наприклад, SMS, MMS, USSD, HTTP або CAMEL, тобто протоколів, відомих фахівцям у відповідній області. На фіг. 13 наведено приклад запиту HTTP для конвертації ідентифікатора абонента, відповідно до одного з варіантів втілення корисної моделі, де "закодовані дані" представляють собою ідентифікатор абонента, який потрібно конвертувати. Слід зазначити, що ідентифікатор абонента, представлений запитом, може бути закодованим у разі потреби, проте, це не є обов'язковим. На додаток, слід звернути увагу, що запит на визначення адреси, показаний на фіг. 13, містить тільки один запит на визначення одного ідентифікатора абонента. Але, окрім цього, існує також можливість включення до одного запиту двох або більше ідентифікаторів абонента. Фіг. 14 надає приклад HTTP-відповіді при отриманні запиту, відповідно до одного з варіантів втілення корисної моделі. На малюнку повідомлення хх (згідно з довжиною вмісту поля) позначає довжину тексту відповіді в байтах, ЗАКОДОВАНЕ_ІМ'Я позначає ідентифікатор абонента, ЗАКОДОВАНИЙ_ДОМЕН позначає ідентифікатор сервера, а поля НОМЕР, ЕЛЕКТРОННА АДРЕСА та АДРЕСА можуть у разі необхідності використовуватись для внесення даних адреси абонента-отримувача. Слід зазначити, що на прикладі фіг. 14, для тексту повідомлення застосовується розширювана мова розмітки (XML). Так само, як і у прикладі фіг. 13, дані можуть бути закодовані (наприклад, дані абонента та/або ідентифікатори серверів), якщо у цьому є потреба, однак це не обов'язково. Слід також зазначити, що відповідь на запит може бути складена з більш ніж одного повідомлення, однакових або різних протоколів. Наприклад, якщо відповідь на запит включала більше одного ідентифікатора абонента, існує можливість передання кількох адрес абонента в одному повідомленні (напр., одне HTTPповідомлення містить "всі" адреси абонента) або більш ніж в одному повідомленні (напр., більше одного HTTP повідомлення, кожен з яких містить певну адресу одного абонента). Проте, існують також інші варіанти, зокрема, у випадку передачі більш, ніж одного повідомлення як відповіді на запит, можливі різні формати одного й того ж повідомлення. Наприклад, окрім адреси абонента у запиті може передаватись також його фото (або фото іншого абонента). У такому випадку бажаною буде передача адреси в повідомленні одного типу (наприклад, HTTP або SMS), а передача фото - в повідомленні іншого типу (наприклад, MMS або USSD). У зв'язку з цим слід мати на увазі, що відповідь на запит може передаватись, як правило, у вигляді принаймні одного з коротких повідомлень (SMS), мультимедійних повідомлень (MMS), повідомлення USSD (Технологія передачі неструктурованих даних в GSM-мережах), Протоколу передачі гіпертексту (HTTP) та інших протоколів. Крім того, на додаток до всіх показаних варіантів втілення корисної моделі, слід зазначити, що корисна модель може функціонувати у вигляді належним чином запрограмованого комп'ютера. Отже, втілення корисної моделі передбачає створення спеціальної відповідної комп'ютерної програми. Фізично, втілення методики корисної моделі передбачає використання машиночитаної пам'яті, що забезпечуватиме виконання команд. 10 UA 71547 U ФОРМУЛА КОРИСНОЇ МОДЕЛІ 5 10 15 Система ініціювання з'єднання між пристроями зв'язку щонайменш двох сторін, яка складається з першого комунікативного пристрою для ініціації зв'язку між принаймні першим та другим комунікативними пристроями відповідно першої та другої сторін комунікації, включає: модуль конвертації, вбудований до машиночитаної пам'яті, для отримання коду-ідентифікатора абонента-отримувача від першої сторони, де код-ідентифікатор абонента-отримувача це рядок символів, серед яких принаймні один є нецифровим та відповідає даним ідентифікатора другої сторони; модуль передачі, вбудований до машиночитаної пам'яті, для прямої чи непрямої передачі запиту на визначення адреси до хост-сервера, де зберігається інформація про відповідний ідентифікатор абонента-отримувача, при цьому запит на визначення адреси включає дані, що вказують на ідентифікатор абонента-отримувача; та модуль управління викликами, вбудований до машиночитаної пам'яті, для отримання відповіді на запит на визначення адреси, включаючи адресу абонента-отримувача - користувача другого комунікаційного пристрою, при цьому друга сторона є доступною, а також для ініціювання зв'язку між першим та другим комунікаційними пристроями. 11 UA 71547 U 12 UA 71547 U 13 UA 71547 U 14 UA 71547 U 15 UA 71547 U 16 UA 71547 U 17 UA 71547 U 18 UA 71547 U 19 UA 71547 U 20 UA 71547 U 21 UA 71547 U 22 UA 71547 U 23 UA 71547 U Комп’ютерна верстка А. Крулевський Державна служба інтелектуальної власності України, вул. Урицького, 45, м. Київ, МСП, 03680, Україна ДП “Український інститут промислової власності”, вул. Глазунова, 1, м. Київ – 42, 01601 24