Спосіб авторизації транзакції із застосуванням мобільного телефону

Реферат: Спосіб авторизації транзакції із застосуванням мобільного телефону включає стадії отримання (102, 202) від користувача (UR), за допомогою комунікаційного сервера (CS), запиту для встановлення голосового з'єднання з телефонним номером, який ідентифікує транзакцію; авторизації транзакції шляхом перевірки (112, 206) прав користувача (UR); приймання (106, 214) чи відхилення (108, 216) голосового виклику; надсилання запиту (116, 220) користувачу (UR) для введення необхідних параметрів транзакції; введення (118, 222) затребуваних параметрів транзакції; перевірку (120, 224), системою авторизації (AS), валідності введеного параметра; визначення того, чи (122, 226) було введено користувачем (UR) усі необхідні UA 104892 C2 (12) UA 104892 C2 параметри транзакції, включаючи авторизацію користувача для фінансування транзакції та, переважно, пароль, який авторизує транзакцію; приймання фінансування транзакції стороною транзакції, що відповідає за це (124, 228), та, у разі приймання, надсилання повідомлення з інструкцією для резервування достатніх коштів (126, 230) у стороні, яка фінансує транзакцію, для розрахунку за транзакцию; визначення (128, 232), де система авторизації (AS) була забезпечена усіма необхідними параметрами транзакції; збереження (130, 234) транзакції для додаткової обробки або її передачі (132, 236) для розрахунку. UA 104892 C2 5 10 15 20 25 30 35 40 45 50 55 60 Галузь винаходу Даний винахід, загалом, до фінансових послуг, особливо до способів здійснення платежів із застосуванням мобільних телефонів. Галузь техніки. Існують відомі способи здійснення платіжних транзакцій із застосуванням мобільних телефонів. Серед них існують способи, винахідником яких є Заявник даного винаходу, що були подані у патентне відомство Польщі під номерами Р-357402, Р-357403, Р-363338. Перший комерційний сервіс мобільних платежів у Польщі, сервіс mPay, був успішно втілений, виходячи з цього способу. Це рішення засновано на нетарифікованому сервісі USSD (Неструктуровані додаткові сервісні дані), та потребує тісного співробітництва з оператором мобільного зв'язку (MNO), серед іншого, щоб мати доступну однорідну неструктуровану систему нумерації USSD. Іншою проблемою з каналом USSD є обмежений діапазон його системи нумерації, що обмежує діапазон можливих застосувань, що можуть мати перевагу при наданні послуг. Остаточно, останньою проблемою є сам формат системи нумерації, що не є інтуїтивно зрозумілим та тому не завжди зрозумілим для користувачів. Існують втілення систем мобільних платежів, що використовують SMS повідомлення, та не потребують явного співробітництва з MNO. Проте, вони не пропонують рівень безпеки та/або надійності, що є бажаним для фінансових послуг. Також, існують рішення, що застосовують голосовий канал для мобільних платежів, або голосовий канал разом із SMS технологією, яку застосовують, серед іншого, у мобільному сервісі PayPal. Проте, рішення такого типу не набули широкого сприйняття, через довгий час виконання транзакцій (зокрема, необхідності в очікування зворотного виклику) або проблем з передачею послідовності цифр протягом голосової сесії, або транзакції коштів у платіжних системах обмежено внутрішніми рахунками платіжної системи. Служба передачі даних, що здається найкраще придатною для здійснення платіжних послуг або авторизації на будь-якій моделі, являє собою USSD (неструктуровані додаткові сервісні дані). Основною перевагою даної послуги є те, що логічну сесію без повторного з'єднання встановлюють між телефоном користувача та сервером для обміну текстовими повідомленнями. Після встановлення сесії, повідомленнями обмінюються віртуально у режимі реального часу. Якщо, з будь-якої причини, сесію не встановлено, (наприклад, через перенавантаження мережі), повідомленнями взагалі не обмінюються. USSD сервіс дозволяє тому потім визначати чітко та швидко, чи може бути встановлений зв'язок та чи можна обмінюватися повідомленнями. Іншою перевагою цієї послуги порівняно з SMS є те, що сесія обміну даними не залишає слідів або залишкових даних (подібно до SMS повідомленню) у пам'яті телефону. Тому покращується безпека комунікацій, що є особливо важливим у випадку обміну PIN кодами чи іншими важливими фінансовими даними. На жаль, сервіс USSD страждає від двох серйозних недоліків. Сесію з сервером встановлюють з телефону користувача у відповідь на набір користувачем послідовності номері у форматі *1XX*NNNN#, де XX є коротким кодом у діапазоні 00-99. Відносно вузький діапазон коротких кодів (максимум 99) не дозволяє запропонувати послуги великого різноманіття та складності. Звичайно, цифри, що йдуть за коротким кодом (NNN) можуть бути використані для додаткової ідентифікації послуг, проте, ідентифікація такого сервісу стає більш складною (наприклад, *134*145#). Іншою проблемою останнього підходу є той факт, що такий запит/команда (на відміну від, наприклад, команд на основі SMS) може бути використаний тільки у межах домашньої мережі користувача, тобто, послуги не можуть бути надані користувачам інших мереж, де б вони не знаходилися, в умовах роумінгу, у межах мережі, в якій надаватиметься сервіс. Ще однією проблемою є те, що USSD сервіс не підтримується мережами CDMA, у цьому випадку необхідною є SMS технологія для здійснення платежів або пов'язаних з цим функцій аутентифікації/авторизації, що призводить до нижчої якості надання послуг. Існуючі рішення відносяться до конкретних втілень мобільних платежів. Практично, не існує відомих шляхів застосування мобільних телефонів для типових цілей авторизації. Стислий опис винаходу У першому аспекті даний винахід охоплює спосіб авторизації транзакції із застосуванням мобільних телефонів використанням мобільного телефону. Користувача, що розпочинає транзакцію, та транзакцію, що підлягає авторизації, ідентифікують за допомогою унікального номеру телефону (MSISDN), призначеного ним у системі авторизації. Користувач, що авторизує транзакцію, розпочинає сесію через голосовий канал з його/її телефону з номером телефону, що ідентифікує транзакцію, яка підлягає авторизації. Запит на з'єднання надходить до системи авторизації, де обслуговується через комунікаційний сервер. Комунікаційний сервер виконує ідентифікацію телефонного номеру користувача, який авторизує транзакцію та номер 1 UA 104892 C2 5 10 15 20 25 30 35 40 45 50 55 транзакції, яку авторизують, який був набраний користувачем. Виходячи з ідентифікованих телефонних номерів та даних, приписаних ним у базі даних комунікаційного серверу, комунікаційний сервер визначає, чи підлягає транзакція авторизації через голосовий виклик або обмін текстовими повідомленнями. У випадку голосового виклику сервер приймає запит на вхідний виклик та встановлює голосове телефонне з'єднання. У випадку запиту на авторизацію транзакції з використанням обміну текстовими повідомленнями, запит на вхідний виклик відхилюється та наступна комунікація з використанням якої авторизують транзакцію, проводиться за допомогою обміну повідомленнями USSD або SMS. У деяких випадках може бути переважним, щоб встановити негайне телефонне з'єднання та потім закрити його. Це викликано фактом, що компоненти мережі часто інтерпретують запит для встановлення кодів відхилення голосового з'єднання довільно та часто помилково. Одночасно, номери користувача, який авторизує транзакцію (що дзвонить MSISDN) та транзакції, яку авторизують (що дзвонить MSISDN), надсилають за допомогою комунікаційного сервера до системи авторизації, що ідентифікує користувача та транзакцію, та перевіряє, чи може бути транзакція, вказана користувачем, авторизована ним. Якщо після верифікації отримано негативний результат, відповідне голосове чи текстове повідомлення надсилається користувачу. В іншому разі, на наступних стадіях користувач вводить параметри транзакції, затребувані системою авторизації, правильність яких перевіряється системою у режимі реального часу. Потім, система визначає чи були отримані усі необхідні параметри транзакції. Якщо система авторизації не має усі необхідні параметри транзакції, вона надсилає запит користувачу який авторизує транзакцію для завершення їх надання. Після того, як користувач вводить необхідні параметри транзакції, процедуру перевірки виконують для визначення того, чи має система авторизації усі параметри, необхідні для авторизації та встановлення транзакції. Якщо сума платежу відома та прийнята платником, повідомлення надсилається для резервування суми транзакції на рахунку платника. Протягом виконання усіх стадій транзакції (включаючи підтвердження суми транзакції платником та одержувачем платежу) транзакцію зберігають зі статусом очікування. Після того, як система авторизації завершує усі необхідні стадії, включаючи шляхом успішної авторизації обома сторонами та згоди сплати транзакції, транзакцію передають до системи розрахунків для подальшої обробки Спосіб включає стадії отримання, за допомогою комунікаційного сервера системи авторизації, запиту для встановлення голосового з'єднання для голосового з'єднання з телефонним номером транзакції, яку авторизують, та наступного приймання чи відхилення запиту на вхідний виклик, якщо запит на з'єднання визначений як запит для авторизації транзакції, виходячи з обміну текстовими повідомленнями. На наступних стадіях, інформація про запит на вхідний з'єднання передається з комунікаційного сервера до системи авторизації, інформація, що включає щонайменше телефонний номер терміналу, що розпочинає зв'язок (що дзвонить MSISDN) разом із набраним номером призначення (що дзвонить MSISDN). та потім вводяться та перевіряються усі необхідні параметри транзакції. Після того, як параметри транзакції перевірені та авторизація обох сторін успішна, кошти резервуються на вихідному рахунку, та припускаючи, що забезпечені усі необхідні параметри транзакції, транзакцію передають до системи розрахунків для подальшої обробки. В другому аспекті, даний винахід охоплює мережу передачі даних, що складається з системи авторизації та комунікаційного сервера, адаптованого для обслуговування процедур авторизації транзакцій з використанням голосового зв'язку, SMS обміну повідомленнями та/або USSD обміну даними. Комунікаційний сервер адаптовано для приймання запиту для встановлення голосового з'єднання для голосового з'єднання з телефоном користувача який авторизує транзакцію та приймання чи відхилення цього запиту для встановлення голосового з'єднання, виходячи з визначення того, чи призначено запит для послуг на основі голосу чи даних (тобто USSD чи SMS) комунікації. Комунікаційний сервер також адаптовано для передачі, до системи авторизації, інформації про запит на вхідний виклик, що містить щонайменше телефонний номер користувача, який авторизує транзакцію (що дзвонить MSISDN) та номер транзакції, яку авторизують (що дзвонить MSISDN), та для передачі інформації між системою авторизації та користувачем, який авторизує транзакцію для отримання та перевірки параметрів транзакції. Інші елементи даного винаходу описані у залежних пунктах формули винаходу. Стислий опис креслень Даний винахід додатково пояснено з посиланням на креслення, що додаються, в яких: Фіг. 1 показано спосіб надання послуг у мережі передачі даних у першому втіленні даного винаходу; 2 UA 104892 C2 5 10 15 20 25 30 35 40 45 50 55 60 Фіг. 2 показано спосіб надання послуг у мережі передачі даних у другому втіленні даного винаходу; На Фіг. 3 -5 показано мережу передачі даних у різних втіленнях даного винаходу; На Фіг. 6 показано спосіб обслуговування запиту для встановлення голосового з'єднання при телефонному обміні оператору зв'язку. Детальний опис Даний винахід, в його різних втіленнях, дозволяє користувачу авторизувати транзакції із застосуванням мобільних телефонів будь-якого типу за допомогою стандартних сервісів, доступних у мережі передачі даних. Відсутня необхідність у додатковому програмному забезпечення для встановлення на мобільному телефоні, для здійснення цієї послуги, ця послуга може бути доступна з будь-якої мережі передачі даних, та можуть бути авторизовані транзакції дебету на рахунку, а також кредиту на рахунку. Сервіс може функціонувати як процедура попередньої авторизації, якщо усі параметри, необхідні для повної авторизації, невідомі, та як повна процедура авторизації, що дозволяє завершення транзакції та далі для розрахунку по ній. Фіг. 1 та 2 демонструють способи реалізації авторизації транзакції з використанням мобільного телефону в одному втіленні даного винаходу. Тип транзакції, що підлягає авторизації, та спосіб розрахунків по ній не є об'єктами даного винаходу. Втілення конкретних послуг додатково включено у цей опис. У першому способі, показаному на Фіг. 1, комунікаційний сервер CS (показаний на Фіг. 3, 4, та 5) отримує, 102, запит для встановлення голосового з'єднання від користувача UR на телефонний номер, який ідентифікує транзакцію, яку авторизують. Комунікаційний сервер CS ідентифікує телефонний номер користувача, та виходячи з цього визначає, 104, чи авторизація має бути здійснена через в голосове з'єднання, він встановлює голосове з'єднання, 106, у цьому разі, або відхиляє голосове з'єднання, 108, у протилежному випадку. Потім, комунікаційний сервер CS передає, 110, інформацію про з'єднання до системи авторизації AS, що перевіряє, 112, чи має користувач UR права для авторизації транзакції, яку розглядають, та, якщо результат перевірки негативний, вона надсилає 114, повідомлення користувачу UR через комунікаційний сервер CS для інформування користувача UR про негативний результат перевірки. Якщо результат перевірки, 112, є позитивним, система авторизації AS надсилає, через комунікаційний сервер CS, запит, 116, користувачу UR для введення, 118, конкретного параметра транзакції. якій потім перевіряють, 120, на предмет правильності, системою авторизації AS. Якщо результат перевірки, 120, параметра, є негативним, то система авторизації AS запитує, 116. дозвіл повторного введення параметрів. Якщо результат перевірки, 120, є позитивним, то система авторизації AS визначає, 122, чи забезпечив користувач UR усі параметри, необхідні для авторизації транзакції. У разі відсутності деяких необхідних параметрів, запит надсилається користувачу UR, 116, для завершення введення відсутніх параметрів. Після її підтвердження, на стадії перевірки того, 122, що користувач UR ввів усі необхідні параметри транзакції, виконують стадію перевірки, 124, для визначення того, чи прийняла сторона, що розраховується, суму транзакції, та, якщо надсилається підтверджуюче повідомлення, 126, з інструкціями для резервування відповідної суми на рахунку користувача. Переважно, суму резервують на рахунку, що управляється установою зовнішніх фінансових послуг. Потім, система авторизації AS визначає, 128, чи були забезпечені усі параметри транзакції (включаючи ті, що були затребувані іншою стороною, що приймає участь у транзакції). Якщо були забезпечені усі параметри транзакції, то транзакцію направляють, 132, для розрахунку; в іншому разі її зберігають у системі зберігання, 130, як транзакцію, "що виконується". Переважно, розрахунки транзакцій здійснюють за допомогою системи програмного забезпечення, що також має функцію авторизації та таким чином складає модуль авторизації/розрахунків. Переважно, авторизацію транзакції та процедури розрахунків виконують за зовнішніми рахунками, наприклад, банківськими рахунками чи платіжними картками. Це усуває необхідність у сплаті рахунків, безпосередньо присутніх у системі авторизації. Якщо авторизацію та процедури розрахунків здійснюють за зовнішніми рахунками, то відповідні повідомлення надсилають до їх відповідних систем управління, що містять інструкції по управлінню коштами. Розрахунки за транзакціями є окремою процедурою передачі коштів між рахунками та відповідним контролем фінансових зобов'язань сторін транзакції та не є об'єктом даного винаходу. У другому втіленні, показаному на Фіг. 2, комунікаційний сервер CS отримує, 202, запит для встановлення голосового з'єднання від користувача UR на номер, що ідентифікує транзакцію, яку авторизують. Інформація про виклик, що надходить, передається, 204, до системи авторизації, що перевіряє, 206, права користувача UR для авторизації транзакції. У випадку 3 UA 104892 C2 5 10 15 20 25 30 35 40 45 50 55 60 негативного результату перевірки, 206, встановлюється голосовий канал, 208, та повідомлення відображається, інформуючи користувача UR про негативний результат перевірки. У випадку позитивного результату перевірки прав, 206, виконують додаткову перевірку, 212, для визначення того, чи може бути авторизація транзакції виконана через голосовий канал, у такому разі голосове з'єднання, 214, встановлюють, тоді як у протилежному випадку запит для встановлення голосового з'єднання відхилюється, 218. На наступній стадії, система авторизації AS надсилає, через комунікаційний сервер CS, запит, 220, користувачу UR щодо введення зазначеного параметра транзакції, якій, після введення, 222, користувачем UR та передачі до системи авторизації AS через комунікаційний сервер CS, перевіряється, 224, системою авторизації AS на предмет правильності. Якщо результат перевірки параметрів, 224, є негативним, то система авторизації AS знову запитує, 220, цей параметр. Якщо результат перевірки, 224, є позитивним, то система авторизації AS визначає, 226, чи забезпечив користувач UR усі параметри, необхідні для авторизації транзакції. У разі відсутності деяких необхідних параметрів, запит надсилається користувачу UR. 220, для завершення введення відсутніх параметрів. Після підтвердження на стадії перевірки. 226, що користувачем UR було введено усі необхідні параметри транзакції, виконують стадію для визначення, 228, чи отримав платник суму транзакції. Позитивний результат призводить до надсилання повідомлення, 126, з інструкціями для резервування відповідної суми на рахунку платника. Переважно, кошти резервують на зовнішньому рахунку, який веде спеціалізована фінансова установа. Система авторизації AS перевіряє, 232, чи були забезпечені усі параметри транзакції, включаючи параметри, затребувані від іншої сторони, що приймає участь у транзакції. Якщо були забезпечені усі параметри транзакції, то транзакцію передають, 236, для розрахунку; в іншому разі її зберігають у системі зберігання, 234, як транзакцію, "що виконується". Якщо комунікаційний сервер CS перевірив, 104, 212, що авторизація транзакції має бути виконана через голосове з'єднання, потім, після встановлення цього з'єднання. 106, 214, обмін повідомленнями між системою авторизації AS та користувачем UR через комунікаційний сервер CS виконують через голосовий канал. В іншому разі, якщо комунікаційний сервер CS перевірив, 104, 212, що авторизація транзакції має бути виконана з використанням текстових повідомлень, комунікаційний сервер CS відхиляє 106, 218 запит для встановлення голосового з'єднання, та всю комунікацію між системою авторизації AS та користувачем UR через комунікаційний сервер CS виконують з використанням SMS або USSD повідомлень. На Фіг. 3 продемонстровано втілення даного винаходу у мережі передачі даних, яку використовують для здійснення сервісу з авторизації транзакцій із застосуванням мобільних телефонів використанням мобільного телефону. У даному винаході, користувач UR набирає телефонний номер, який ідентифікує транзакцію, яку авторизують, що призводить до запиту для встановлення голосового з'єднання, 302, CALL REQUEST, що надходить до комунікаційного сервера CS, та комунікаційний сервер CS відхиляє цей запит на з'єднання та передає, 304, інформацію про цей з'єднання до системи авторизації AS. Система авторизації AS зв'язується, 306, з використанням UR, через комунікаційний сервер CS за допомогою SMS текстових повідомлень або USSD повідомлень. Після того, як процедуру авторизації транзакції завершено, система авторизації AS передає, 308, транзакції для розрахунку. В іншому втіленні, показаному на Фіг. 4, користувач UR, для авторизації транзакції, набирає телефонний номер, що призводить до запиту для встановлення голосового з'єднання, 402, CALL REQUEST, що надходить до комунікаційного сервера CS. Цей запит приймається та встановлюється голосовий зв'язок, 406, за допомогою якого виконують зв'язок між системою авторизації AS та користувачем UR, зв'язують через комунікаційний сервер CS, 404. із системою авторизації AS для підтвердження та перевірки параметрів транзакції. Після підтвердження параметрів транзакції, система авторизації AS передає, 408, транзакції для розрахунку. У прикладах, від Фіг. 3, а також Фіг. 4, у випадку запиту на встановлення з'єднання, ЗАПИТ НА ВИКЛИК, надходить на комунікаційний сервер CS, інформація про запит може бути передана, 304, 404, до системи авторизації AS для перевірки прав користувача UR. У випадку негативного результату перевірки прав користувача, AR надає інструкції CS прийняти запит на вхідний виклик для відображення голосового повідомлення, що інформує користувача UR про негативний результат перевірки прав, тоді як у випадку позитивного результату перевірки прав користувача запит на з'єднання відхилюється, як на Фіг. 3, чи приймається, як на Фіг. 4. Телефонний номер, набраний користувачем UR, який ідентифікує транзакції, може варіюватися в залежності від транзакції. або може бути таким самим (одним) номером для кожної конкретної сторони, що пропонує продукт чи сервіс, наприклад, торговцем/продавцем, бенефіціаром передачі коштів, білетною касою чи веб-сайтом. Номер, набраний користувачем 4 UA 104892 C2 5 10 15 20 25 30 35 40 45 50 55 60 UR, може також включати параметри транзакції, що можуть бути включені у стандартний телефонний номер, або їх вводять як продовження номеру та вони можуть бути відділені символами "*" чи "#". Переважно, набраний номер, який ідентифікує транзакції, є стандартним телефонним номером, який типово використовують для встановлення голосового з'єднання, модифікують шляхом включення додаткових параметрів, зокрема "*" або "#" символів, та обробляють мережами передачі даних як запит на авторизацію транзакції. Замість встановлення голосового з'єднання с мережею, приєднаний термінал, зв'язаний з цим номером, мережа передачі даних передає запит на встановлення з'єднання на комунікаційний сервер CS для обслуговування транзакції, одна сторона якої ідентифікована за цим телефонним номером. Реалізація такого рішення показана на Фіг. 5. запит на встановлення голосового з'єднання, 502, що надходить від користувача UR, надходить на телефонний комутатор MSC оператора мережі, в якому перевіряється набраний номер, та, якщо запит має обслуговуватися як стандартний голосовий виклики, він передається, 506, на відповідний термінал чи мережевий вузол, DT, та потім встановлюється просте голосове з'єднання. Якщо виклик, що находить, розпізнається як виклик для обслуговування транзакції, він передається, 504, на комунікаційний сервер CS, що у свою чергу передає, 508, інформацію про цей виклик до системи авторизації AS. На Фіг. 6 показано спосіб обслуговування запиту для встановлення голосового з'єднання у телефонному комутаторі оператора мережі передачі даних. Після того, як комутатор MSC отримує запит, 602, номер, набраний користувачем, аналізується, 604, на його довжину, та, якщо це стандартний MSISDN номер, запит передається для обробляння наступним елементом мережі передачі даних. Якщо набраний номер є розширеним номером та/або містить спеціальний символ "*" чи "'#", то запит на встановлення з'єднання обробляється як запит для авторизації транзакції та передається, 608, на комунікаційний сервер CS, який, у свою чергу, передає, 508, інформацію про з'єднання до системи авторизації AS. На Фіг. 3, 4, та 5 показано мережу передачі даних 300, 400, 500 у різних втіленнях даного винаходу. Користувач UR використовує телефонний термінал як мережу мобільного зв'язку, адаптовану для здійснення голосових з'єднань та обміну SMS повідомленнями, та, переважно, USSD повідомленнями. Виклики, що надходять від користувача UR. обслуговуються комутатором MSC, який передає їх на комунікаційний сервер CS системи авторизації AS. Комунікаційний сервер CS адаптовано для обслуговування голосових з'єднань та обміну SMS та USSD повідомленнями. Для використання модифікованих телефонних номерів при авторизації транзакції, комутатор MSC адаптовано для ідентифікації таких викликів, як транзакцій обслуговування викликів та передачі їх на комунікаційний сервер CS. У випадку використання тільки стандартної системи нумерації при авторизації транзакції, та модифікація комутатора MSC не потрібна. Приклад авторизації транзакції із застосуванням мобільних телефонів з використанням мобільного телефону, відповідно до даного винаходу, наведено нижче. Приклад 1 Користувач UR має мобільний телефон з системою підтримки повідомлень USSD, та номер мобільного телефону реєструють за допомогою системи авторизації AS, що підлягає авторизації для виконання платіжних транзакцій. Попередня реєстрація користувача UR у системі авторизації AS є необхідною та перевіряється на стадіях 112 та 206 на Фіг. 1 та 2. Користувач UR робить покупку через Інтернет-магазин. Останньою стадією у процесі покупки є платіж. На веб-сайті магазину відображаються цифри телефонного номеру. Номер може також відображатися у графічній формі, кодованій у фотокоді. Користувач UR вручну вводить номер через клавіатуру на телефонній трубці або, в альтернативному втіленні, використовує програмне забезпечення, встановлене на телефоні користувача, що зчитує фотокод, відображений на веб-сторінці, та декоду фотокод для одержання та набору номера. Набір номера призводить до надсилання запиту на встановлення з'єднання, 302, у мережі передачі даних, які одержує, 102, за допомогою комунікаційного сервера CS. Виходячи з даних, наявних у його базі даних, комунікаційний сервер CS визначає, 104, що авторизація транзакції буде здійснена з використанням обміну повідомленнями через канал USSD, відхиляє, 108, запит про встановлення голосового виклику, та потім передає, 110, інформацію про запит на вхідний виклик до системи авторизації AS. Система авторизації AS підтверджує, 112, права користувача UR для авторизації транзакції, та надсилає, 116, повідомлення на комунікаційний сервер CS, що містить інформацію про транзакцію та запит на авторизацію від користувача, яку потім доставляють користувачу, 306, при обміні повідомленнями USSD. Користувач UR авторизує транзакцію шляхом введення, 118, PIN коду як параметра транзакції. Система авторизації AS перевіряє, 120, PIN код, введений користувачем знову його базу даних, та потім визначає, 122, 5 UA 104892 C2 5 10 15 20 25 30 35 40 45 50 55 60 чи було введено користувачем UR усі очікувані параметри транзакції. Потім, система авторизації AS визначає, 124, чи може сторона транзакції, рахунок якої має бути дебетований (користувач UR у цьому прикладі), прийняти суму транзакції, та. якщо це підтверджено, повідомлення надсилається з інструкціями для резервування суми, 126, на банківський рахунок. Після вимоги лише ΡIN коду та параметра транзакції, після того, як завершено стадію перевірки PIN коду 128, транзакцію передають далі для розрахунку, 32. Приклад 2 Користувач UR є власником мобільного телефону з номером, не зареєстрованим у системі авторизації; AS бажає здійснити покупку напою у торгівельному автоматі. Користувач UR набирає номер на мобільному телефоні, який зв'язаний з транзакцією та, наприклад, відображений на торгівельному автоматі. Набір номеру призводить до надсилання запиту для встановлення голосового з'єднання, 302, до мережі передачі даних, який одержують за допомогою комунікаційного сервера CS. Комунікаційний сервер CS передає, 204, інформацію про запит для встановлення голосового з'єднання до системи авторизації AS, що перевіряє, 206, у цьому разі з негативним результатом, права користувача UR. завершує встановлення голосового виклику, 208, та використовує голосовий виклик для передачі повідомлення, 210, про недостатні права користувача для використання системи. Приклад 3 Користувач UR, бажає передати, з використанням мобільного телефону користувача, суму PLN 20 з рахунку електронного гаманця користувача особі, ідентифікованій телефонним номером 1234567. Користувач UR набирає послідовність 1234567*20 на телефоні. Запит на встановлення з'єднання, 502, надсилається на телефонний комутатор MSC. Комутатор MSC отримує, 602, запит на встановлення з'єднання, та, виходячи з факту, 604, що це модифікований телефонний номер з включеним символом "*", розпізнає його як запит на обслуговування транзакції та передає його, 504, 608, на комунікаційний сервер CS. Комунікаційний сервер CS отримує, 102, запит на встановлення з'єднання, та визначає, 104, чи буде авторизація транзакції буде здійснена з використанням SMS повідомлень, відхиляє, 108, запит на виклик, та надсилає інформацію про з'єднання, що обслуговується, до системи авторизації AS. Система авторизації AS визначає, чи зареєстрований користувач UR у системі авторизації AS, та перевіряє. 112, права користувача. Після того, як права користувача UR перевірені, система авторизації AS передає користувачу інформацію про транзакцію та запит, 116, для приймання/дозволення транзакції. Користувач UR приймає транзакції шляхом надання PIN коду користувача. Система авторизації AS перевіряє, 120, приймання транзакції (тобто, підтверджує правильність PIN коду), та потім вона перевіряє, 122, чи забезпечив користувач UR усі затребувані параметри транзакції (наприклад, чи може бути відома сума транзакції). Потім, система авторизації AS визначає, 124, чи може сторона транзакції, рахунок якої має бути дебетований (рахунок користувача UR у цьому прикладі), прийняти суму переказу та, у разі підтвердження цього, повідомлення надсилається з інструкціями для резервування суми, 126, на рахунку електронного гаманця користувача, якій зберігається системою авторизації AS. Потім, система авторизації AS визначає, 128, чи відомі усі параметри, необхідні для розрахунку за транзакцією, (наприклад, чи було отримано підтвердження від одержувача переказу), на направляє транзакцію для розрахунку, 132. Приклад 4 Користувач UR здійснює покупку взуття через телемагазин. Продукту призначають конкретний номер. Користувач UR набирає номер, видимий на екрані, що призводить до надсилання запиту для встановлення голосового з'єднання, 402, для з'єднання з цим конкретним номером. Запит отримують, 102, за допомогою комунікаційного сервера CS, який визначає, 104, що транзакція буде виконана з використанням голосового каналу, та встановлює, 106, 406, голосовий виклик. Інформація про запит на з'єднання, яке обслуговується, надсилається, 110, до системи авторизації AS, яка, після перевірки, 112, прав користувача, надсилає запит користувачу, 116, для введення розміру взуття. Цей параметр, після введення користувачем, 118, перевіряється, 120, торговцем/продавцем, на наявність продукту із затребуваним розміром. У разі відсутності продукту із затребуваним розміром користувачу UR надсилається запит, 116, для введення іншого розміру, після чого, 188, процедуру перевірки повторюють, 120. На наступній стадії, система авторизації AS визначає, 122, чи були введені усі очікувані параметри транзакції, та надсилає запит, 116, для авторизації транзакції за допомогою PIN коду. Користувач UR вводить, 118, PIN код, який перевіряється, та потім виконують наступну станцію перевірки, 122, для визначення того, чи користувач UR надав усі необхідні параметри транзакції. Потім, система авторизації AS визначає, 124, чи може сторона транзакції, рахунок якої має бути дебетований (користувач UR у цьому прикладі), 6 UA 104892 C2 5 10 15 20 25 30 35 40 45 50 55 60 прийняти суму транзакції та, я разі підтвердження, повідомлення надсилається з інструкціями для резервування суми, 126, на банківський рахунок користувача. Потім, система авторизації AS перевіряє, 128, чи відомі усі параметри транзакції (наприклад, чи може бути транзакція прийнята продавцем, чи може бути вказана сума транзакції, та ін.), та передає транзакцію для розрахунку, 132. Приклад 5 Користувач UR, з використанням NFC (стандарту ближнього зв'язку), сумісного з мобільним телефоном, здійснює платіж у білетній касі. Платіж ідентифікується за телефонним номером, роздрукованим на пасивному стікері, за технологією радіочастотної ідентифікації (RFID), або який стає видимим на активному дисплеї з радіочастотної ідентифікації, де номер також зберігають в електронній формі. Транзакція призведе до занесення на рахунок на платіжну картку (зв'язану системою авторизації AS номера мобільного телефону користувача). Для виконання транзакції, користувач UR проводить телефонною трубкою біля RFID стікера, з якого вказаний телефонний номер зчитується NFC трансівером та автоматично набирається телефоном користувача. Запит на встановлення з'єднання отримується, 102, за допомогою комунікаційного сервера CS, який визначає, 104, що додаткова обробка цього запиту на виклик буде здійснені через USSD канал, та відхиляє, 108, голосове з'єднання. Потім, інформація про запит, який обслуговується, надсилається, 110, до системи авторизації AS, яка, після перевірки прав користувача, 112, передає користувачу UR, 116, відповідну інформацію про транзакцію та запит на авторизацію транзакції з паролем. Система авторизації AS перевіряє, 120, пароль, введений користувачем UR, 118, визначає, 122, що користувачем UR було введено усі необхідні параметри транзакції та визначає, 124, чи сторона транзакції, рахунок якої має бути дебетований (користувач UR у цьому прикладі) прийняла суму транзакції. У разі підтвердження користувачу картки чи до центру розрахунків надсилається повідомлення про авторизацію, що містить інструкції для резервування суми, 126, на банківський рахунок користувача, пов'язаний із карткою. На наступній стадії, система авторизації AS визначає, 128, чи були забезпечені усі параметри транзакції, необхідні для розрахунків за транзакцією, та, у разі підтвердження, передає, 132, транзакцію для розрахунку. Приклад 6 Користувач UR з мобільним телефоном бажає сплатити за паркування. Запропонований спосіб дозволяє користувачеві сплачувати за фактичний час паркування, тобто, активувати послугу на час початку паркування, та дезактивувати на час закінчення паркування. ідентифікатором транзакції паркування є телефонний номер. Набір цього номера призводить до запиту для встановлення голосового з'єднання, що надходить на комунікаційний сервер CS, 202, який надсилає, 204, відповідну інформацію про запит на встановлення з'єднання до системи авторизації AS. Після того, як були підтверджені права користувача на авторизацію транзакції, 206, виносять рішення, 212, про здійснення авторизації через USSD обмін повідомленнями, та запит для встановлення голосового з'єднання відхилюється, 218. Потім, запит надсилається користувачу UR, 220, для введення максимальної суми, до якої буде дозволено транзакцію паркування. Саме введення суми, 222, представлено також для авторизації транзакції. Введена сума перевіряється, 224, системою авторизації AS, та після того, як необхідні параметри перевірені, 226, визначають, чи прийняв користувач UR суму транзакції, та повідомлення надсилається, 230, з інструкціями для резервування суми на телефонний рахунок оператора мобільного зв'язку користувача. Потім, виконують стадію перевірки, 232, для визначення того, чи відомі усі параметри транзакції. Оскільки сума транзакції, введена користувачем UR, не є точною сумою транзакції, яка буде визначена пізніше, виходячи з фактичного витраченого часу паркування транзакцію зберігають, 234, у системі авторизації AS, як транзакцію, що очікує, для завершення та розрахунку, коли будуть відомі усі параметри транзакції. Фактична сума транзакції відома після дезактивації сервісу паркування: користувачем UR наприкінці періоду паркування. або постачальником послуг з паркування, коли сервіс дезактивують, або системою авторизації AS, або постачальником послуг з паркування, після перевищення максимальної суми, наданої користувачем UR. Після закінчення транзакції, її передають, разом із фактичною сумою, для розрахунку. Максимальна сума транзакції, введена, 222, користувачем UR, може бути введена як частина послідовності набору (частина номеру, що дзвонить для виклику сервісу), шляхом відділення параметра суми з телефонного номеру з ''*" символом. Наприклад, для обслуговування телефонного номера 1234567 та суми PLN 5,50, фактична послідовність, набрана користувачем, може мати таку форму: 1234567*5*50. Якщо параметр суми включений у набраний номер, то запит, 220, для введення цього параметра, 222, 224, не використовують. Приклад 7 7 UA 104892 C2 5 10 15 20 25 30 35 40 45 50 55 60 Дитина, яка є користувачем UR сервісу, бажає запитати від батька, що має телефон з номером 1234567, переказу PLN 30. Користувач UR набирає телефонний номер батька на мобільному телефоні користувача разом із затребуваною сумою, відділеною символом "#". Послідовність, набрана користувачем UR, має такий формат: 1234567#30. Після того, як послідовність набрано, запит надсилається, 502, до терміналу MSC, що розпізнає спеціальний символ "#" та надсилає, 504, запит на встановлення з'єднання на комунікаційний сервер CS. Комунікаційний сервер CS отримує, 102, запит на встановлення голосового виклику та, після визначення, 104, що процедура авторизації має бути здійснена через USSD канал, відхиляє, 108, запит на встановлення голосового виклику, надсилає, 110, відповідну інформацію про запит, який обслуговується, до системи авторизації AS, яка, перевіряє, 112, права користувача, та передає користувачу відповідну інформацію про транзакцію разом із запитом, 116, для приймання транзакції. Після того, як користувач UR приймає, 118, транзакцію та система авторизації AS перевіряє стадію приймання на предмет правильності, 120, вона перевіряє, 122, чи очікуються будь-які інші параметри. Потім, система авторизації AS перевіряє, 124, чи прийняла сторона транзакції, рахунок якої має бути дебетований (батько, у цьому прикладі), суму транзакції. Оскільки сума транзакції не була прийнята стороною, яка надає кошти, додаткова перевірка, 128, проводиться для визначення повноти параметрів транзакції. Оскільки батько не авторизував транзакцію, транзакції зберігають, 130, у системі авторизації AS для подальшої обробки. Для завершення транзакції, батько набирає, з телефону батька, "*" послідовність, яка, як запит на встановлення з'єднання, 502, надсилається до терміналу MSC, де ідентифікується на спеціальне значення та передається, 504, на комунікаційний сервер CS. Після того як комунікаційний сервер CS отримує, 102, запит на встановлення з'єднання та визначає, що авторизація має бути проведена через USSD канал, запит для встановлення голосового з'єднання відхилюється, 108, та відповідна інформація про запит на виклик надсилається до системи авторизації AS, яка перевіряє валідність батьківського UR, та надсилає USSD повідомлення, що містить інформацію про транзакцію переказу коштів, що очікує, та запит для її авторизації з PIN кодом. Після того, як батько UR вводить, 118, PIN код, який перевіряється, 120, системою авторизації AS банку, що підтримує зберігання батьківського рахунку, з якого буде розрахована транзакція та, одночасно, сума транзакції резервується та одночасно кошти на рахунку блокуються. Після визначення того, 122, що це останній параметр транзакції, затребуваний від батька, та визначення того, що батька прийняв суму транзакції, повідомлення надсилається з інструкціями для резервування, що місить команду блокувати суму, 126, на банківському рахунку користувача. Потім, виходячи з цього визначення, 128, що система авторизації AS завершила розгляд параметрів транзакції, транзакцію передають, 132, для додаткового розрахунку. Якщо, після набору послідовності символів*", виявляється, що батько має множину транзакцій, що очікують його/її приймання, транзакції послідовно надають для приймання. Також, батько може попередньо вибрати конкретну транзакцію, що очікує на авторизацію, шляхом введення цілого повного номеру (або його частини) транзакції, що очікує, яка виконується. Наприклад, якщо номер дитини 33344455, потім, після набору послідовності номера33344455*, батькові буде запропоновано для авторизації транзакцію. що очікує, що надходить безпосередньо з номеру. Також, батько може вказати суму транзакції, наприклад, 3334455*20 (для суми PLN 20 з номером 333444555), та, якщо вона відрізняється від затребуваної суми з цього номеру, система авторизації AS надсилає відповідне повідомлення щодо невідповідності між значенням параметра суми, та транзакції. зберігають, 130, як транзакцію "що очікує", доки сторони не узгодять суму. Представлене рішення має декілька переваг порівняно із існуючим на ринку. По-перше, сервіс може бути запропонований в усіх мережах та з використанням будь-якого мобільного телефону - відсутня потреба в установці спеціального телефонного обладнання. Для авторизації транзакції команда є аналогічною до здійснення телефонного виклику іншій особі, що є надзвичайно просто для кожного користувача мобільного телефону. Необов'язково у цьому рішенні, параметри транзакції можуть бути необов'язково включені у набраний номер, переважно відділений спеціальними символами "*" чи "#". Також, це рішення дозволяє попередню авторизацію транзакції, тобто, попередню авторизацію транзакції у випадку відсутності деяких параметрів транзакції, які ще не були надані. Як транзакції з кредитом на рахунку, так і транзакції з дебетом на рахунку, можуть бути авторизовані. Найбільш важливою перевагою цього рішення є спосіб, коли параметри транзакції збирають окремо від узгоджених з кожною стороною транзакції окремо, та тільки після успішної авторизації транзакції усіма задіяними сторонами, транзакції. передають для розрахунку на стадії розрахунку. Такий підхід призводить до великого степеню гнучкості, дозволяючи авторизувати транзакції будь-якого типу. 8 UA 104892 C2 ФОРМУЛА ВИНАХОДУ 5 10 15 20 25 30 35 40 45 50 55 60 1. Спосіб авторизації транзакції із застосуванням мобільного телефону, що включає стадії: отримання (102, 202) за допомогою комунікаційного сервера (CS) запиту для встановлення голосового з'єднання з телефонним номером, що однозначно ідентифікує транзакцію: відхилення (108, 218) запиту для встановлення голосового з'єднання, якщо такий запит був визначений (104, 212) як запит на авторизацію транзакції для виконання з використанням текстового каналу, або приймання цього запиту та встановлення (106, 214) голосового з'єднання, якщо запит був визначений як запит авторизації для виконання через голосовий канал; передачу (110, 204), від комунікаційного сервера (CS) до системи авторизації (AS), інформації про запит, що містить щонайменше телефонний номер користувача (UR) та телефонний номер, що ідентифікує транзакцію; передачу, від системи авторизації (AS) користувачу (UR), запиту (116, 220) для введення необхідних параметрів транзакції; передачу (118, 222) необхідних параметрів транзакції з телефонної трубки користувача; перевірку (120-122, 224-226) правильності та повноти параметрів транзакції, отриманих системою авторизації (AS); визначення (126, 228), чи може бути сума транзакції прийнята стороною транзакції, відповідальною за фінансування транзакції, та, у разі прийняття, надсилання повідомлення, що містить інструкцію для резервування (128, 230) достатньої кількості коштів для транзакції стороною, що фінансує рахунок, для розрахунку по транзакції; перевірку (128, 232) повноти усіх параметрів транзакції, отриманих системою авторизації (AS); передачу (132, 236) транзакції для розрахунку, якщо стадію перевірки було успішно завершено. 2. Спосіб за пунктом 1 або 2, що включає стадію зберігання (130, 234) даних транзакції для подальшої обробки у випадку неуспішної верифікації (128, 232). 3. Спосіб за пунктом 1 або 2, де номер, що ідентифікує транзакцію, є номером, що ідентифікує одержувача платежу. 4. Спосіб за пунктом 1 або 2, де номер, що ідентифікує транзакцію, є номером, що ідентифікує електронний апарат точки продажу. 5. Спосіб за пунктом 1 або 2, де номер, що ідентифікує транзакцію, є номером, що ідентифікує продукт чи сервіс. 6. Спосіб за пунктом 1 або 2, де у випадку відхилення (108, 218) запиту на встановлення голосового з'єднання, з'єднання між системою авторизації (AS) та користувачем (LJR) полегшується за допомогою комунікаційного сервера (CS) через SMS канал. 7. Спосіб за пунктом 1 або 2, де у випадку відхилення (108, 218) запиту на встановлення голосового з'єднання, з'єднання між системою авторизації (AS) та користувачем (UR) полегшується за допомогою комунікаційного сервера (CS) через USSD канал. 8. Спосіб за пунктом 1 або 2, де після того, як комунікаційний сервер (CS) отримує (202) запит на встановлення з'єднання, комунікаційний сервер (CS) передає інформацію про виклик до системи авторизації (AS), та система авторизації (AS) виконує перевірку прав користувача (UR), та у випадку неуспішної перевірки (206) прав користувача, система авторизації (AS) надсилає інструкцію на комунікаційний сервер (CS) для встановлення голосового з'єднання, в якому відображається повідомлення (210), де пояснюються причини неуспішної перевірки прав. 9. Спосіб за будь-яким з пп. 1-8, де після того, як комунікаційний сервер (CS) отримує (102) запит на встановлення з'єднання, комунікаційний сервер (CS) визначає (104) тип з'єднання для використання для авторизації транзакції, та потім комунікаційний сервер (CS) передає (110) інформацію про запит, що надходить, до системи авторизації (AS), що у випадку неуспішної перевірки (112) прав користувача, застосовує комунікаційний сервер (CS) для надсилання (114) повідомлення користувачу (UR) з поясненням неуспішної перевірки прав. 10. Спосіб за будь-яким з пп. 1-9, де параметрами однієї транзакції, які запитує (116, 220) система авторизації (AS) та вводить (118, 222) користувач (UR), є пароль користувача. 11. Спосіб за будь-яким з пп. 1-9, де параметрами однієї транзакції, які запитує (116, 220) система авторизації (AS) та вводить (118, 222) користувач (UR), є явна авторизація транзакції. 12. Спосіб за будь-яким з пп. 10-11, де пароль є явною авторизацією транзакції. 13. Спосіб за будь-яким з пп. 10-12, де аутентифікацію користувача (UR) запитує система авторизації (AS) від зовнішньої системи керування коштами користувача. 14. Спосіб за будь-яким з пп. 1-2, де після того, як встановлено голосове з'єднання (106, 214), відбувається взаємодія з використанням DTMF технології. 9 UA 104892 C2 5 10 15 20 25 30 35 40 45 50 55 60 15. Спосіб за будь-яким з пп. 1-2, де після того, як встановлено голосове з'єднання (106, 214), відбувається взаємодія з використанням голосового з'єднання та технології розпізнавання речі. 16. Спосіб за будь-яким з пп. 1-2, де деякі параметри транзакції кодують у стандартному телефонному номері, який ідентифікує транзакцію. 17. Спосіб за будь-яким з пп. 1-2, де деякі параметри транзакції включають у модифікований телефонний номер, який ідентифікує транзакції. 18. Спосіб за будь-яким з пп. 1-2 та 17, де телефонний номер, який ідентифікує транзакції, містить спеціальний символ "*" чи ''#". 19. Спосіб за будь-яким з пп. 1-2 та 16-18, де користувач (UR) має телефонну трубку з безконтактною технологією та телефонний номер, який ідентифікує транзакцію, віддалено зчитує з безконтактного чипа або електронного емітера. 20. Спосіб за будь-яким з пп. 1-2 та 16-18, де користувач (UR) має телефонну трубку з програмним забезпеченням, що розпізнає та обробляє штрих-коди та таке забезпечення отримує телефонний номер, що ідентифікує транзакції, кодовані штрих-кодом. 21. Спосіб за будь-яким з пп. 1-2 та 16-18, де користувач (UR) має телефонну трубку, що підтримує безпровідний стандарт ближнього зв'язку, та телефонний номер, який ідентифікує транзакції, передається через телефон користувача через цей зв'язок. 22. Спосіб за будь-яким з пп. 1-2, де замість відхилення (108, 218) запиту для встановлення голосового з'єднання, встановлюється виклик, який закінчується після зазначеного періоду часу. 23. Спосіб за пунктом 18, де користувач (UR), що здійснює виклик на неповний телефонний номер, який ідентифікує транзакції, додатково включає спеціальний символ "*" або "#" у набраній послідовності, авторизує транзакції, вказані системою авторизації (AS), в якому номер, що ідентифікує транзакції, починається з неповного номера, набраного користувачем (UR). 24. Спосіб за пунктом 18, де користувач (UR), що здійснює виклик на телефонний номер, який ідентифікує транзакції та складається тільки з символу "*" або "#", авторизує транзакції, вказані системою авторизації (AS). 25. Мережа передачі даних (300, 400), що містить комунікаційний сервер (CS), адаптований для отримання запиту для встановлення голосового з'єднання на телефонний номер, телефонний номер, що ідентифікує транзакцію, та для відхилення запиту для встановлення голосового з'єднання, якщо запит був визначений як запит для здійснення процедури авторизації через текстовий канал, або для приймання запиту та для встановлення голосового виклику, якщо запит був визначений як запит для здійснення процедури авторизації через голосовий канал; та додатково комунікаційний сервер (CS) адаптований для надсилання до системи авторизації (AS), інформації про запит на встановлення голосового з'єднання, що містить щонайменше телефонний номер користувача (UR) та телефонний номер, що ідентифікує транзакцію; систему авторизації (AS), що з'єднується з комунікаційним сервером (CS), адаптовано для надсилання запиту користувачу (UR) для введення необхідних параметрів транзакції; та телефонну трубку користувача адаптовано для надсилання запиту на встановлення з'єднання, та надсилання необхідних параметрів транзакції; та систему авторизації (AS) адаптовано для перевірки правильності отриманих параметрів транзакції та передачі транзакції для розрахунку, якщо стадія перевірки успішна. 26. Мережа передачі даних (300, 400) за п. 25, де отримання параметрів транзакції виконують через голосовий канал. 27. Мережа передачі даних (300, 400) за п. 25, де отримання параметрів транзакції виконують через USSD канал. 28. Мережа передачі даних (300, 400) за п. 25, де отримання параметрів транзакції виконують через SMS повідомлення. 29. Мережа передачі даних (300, 400) за п. 25, де комунікаційний сервер (CS) входить до складу системи авторизації (AS). 30. Мережа передачі даних (500) за будь-яким з пп. 25-29, де запит на встановлення з'єднання (502) від телефонної трубки користувача надходить на телефонний комутатор (MSC), та якщо номер, який набирають, є стандартним номером, то запит обробляють як стандартний голосовий виклик (506) наступним елементом (DT) мережі передачі даних, тоді, якщо це модифікований номер, MSC передає (504) запит на комунікаційний сервер (CS). 31. Мережа передачі даних (500) за п. 30, де комутатор (MSC) передає запит на встановлення з'єднання на комунікаційний сервер (CS), якщо наявний спеціальний символ "*" або "#" у номері, який набирають. 32. Мережа передачі даних (500) за п. 30, де комунікаційний сервер (CS) не обслуговує голосові виклики, та запит для встановлення голосового з'єднання (502) відхиляється комутатором 10 UA 104892 C2 (MSC), та інформація про відхилений запит на виклик передається тільки (504) на комунікаційний сервер (CS). 11 UA 104892 C2 12 UA 104892 C2 Комп’ютерна верстка Л. Ціхановська Державна служба інтелектуальної власності України, вул. Урицького, 45, м. Київ, МСП, 03680, Україна ДП “Український інститут промислової власності”, вул. Глазунова, 1, м. Київ – 42, 01601 13