Спосіб здійснення безготівкових платежів

1. Спосіб здійснення безготівкових платежів з рахунку платника у фінансовій установі платника на рахунок отримувача у фінансовій установі отримувача у межах платіжної системи, у якому платник здійснює передачу у фінансову установу платника авторизованого умовного платіжного доручення, що містить принаймні суму платежу, після цього у фінансовій установі платника генерують ключовий код, який разом з умовним платіжним дорученням зберігають у інформаційній системі та надсилають платнику, який далі передає одержаний ключовий код отримувачу, після цього отримувач здійснює передачу у фінансову установу отримувача авторизованого запиту, що містить принаймні ключовий код, одержаний від платника, причому, а) якщо фінансова установа платника є фінансовою установою отримувача, то після перевірки на відповідність умовного платіжного доручення, одержаного від платника, із авторизованим запитом, одержаним від отримувача, на то тожність принаймні ключового коду, присутнього в них, здійснюють переказ коштів, або б) якщо фінансова установа платника не є фінансовою установою отримувача, то фінансова установа отримувача здійснює передачу авторизованого запиту, що містить принаймні ключовий код, у платіжну організацію, після чого платіжна організація здійснює передачу авторизованого запиту, що містить принаймні ключовий код, у фінансову установу платника і після перевірки на відповідність умовного платіжного доручення, одержаного від платника, із авторизованим запитом, одержаним від платіжної організації, на тотожність принаймні ключового коду, присутнього в них, здійснюють переказ коштів, при цьому передачу вказаних даних здійснюють з терміналів, сполучених між собою за допомогою телекомунікаційних мереж. 2. Спосіб за п.1, який відрізняється тим, що тер 2 (19) 1 3 36638 Корисна модель відноситься до галузі автоматизації комерційних угод і може бути використаний у торгівлі та у сфері надання різних видів послуг. За його допомогою можна здійснювати різні види платежів і розрахунків у межах платіжної системи, в тому числі за послуги зв'язку (мобільного, провідного, суп утникового, IP та ін.). за послуги Інтернет, комунальні послуги, оплату товарів і послуг, переказу коштів та ін. Відома система продажу через торгові автомати телефонних карт з попередньою оплатою [WO 9801815. МПК G06F17/60], але вона має. вузьку спеціалізацію, обмежені функціональні можливості оскільки може бути використана тільки для оплати телефонних розмов зі спеціалізованих телефонних автоматів. Відомий також спосіб сплати і отримання послуг і товарів з використанням карток [див. патент США №5225977, МПК G06F15/30], згідно з яким формують запит з зазначенням даних ідентифікатора картки, що зчитується з картки за допомогою пристрою зчитування, і вартості послуги, виконують передачу цього запиту з локального контролера у центральний контролер, формують відповідне повідомлення з урахуванням даних, що містяться у базі даних, у якій записані відповідні рахунки, виконують передачу зворотного повідомлення у локальний контролер, ініціюють роботу пристрою по наданню послуг. До недоліків описаного способу можна віднести те, що він не забезпечує достатній рівень безпеки, оскільки дані картки стають відомими продавцям при здійсненні кожної платіжної операції. Найбільш близьким до корисної моделі, що заявляється, є спосіб здійснення безготівкових платіжних операцій клієнтами банків, [описаний в патенті України на винахід №64840, МПК G06F17/60, G07F19/00, Н04М17/00]. Вказаний спосіб включає передачу покупцем з мобільного термінала покупця повідомлення до центру обробки платіжних трансакцій, де ідентифікують того, хто передає повідомлення, та отримують його реквізити і надсилають у відповідь повідомлення, що генерують у центрі обробки платіжних трансакцій, після цього у центрі обробки платіжних трансакцій здійснюють перевірку трансакції у фінансовій установі покупця, до якої його підключено через мережу передачі даних, а після здійснення трансакції надсилають підтвердження покупцю та продавцю, причому спочатку здійснюють відправлення продавцем до центру обробки платіжних трансакцій запиту із зазначенням суми трансакції, ідентифікацію продавця у центрі обробки платіжних трансакцій та отримання реквізитів продавця з його ідентифікатора, після цього у центрі обробки платіжних трансакцій генерують ключовий код трансакції, який заносять в базу даних, згенерований ключовий код трансакції передають продавцю за неавтономним запитом із зазначенням суми трансакції для передачі його покупцю, з мобільного термінала покупця ключовий код трансакції вводять до центру обробки платіжних трансакцій, а трансакцію здійснюють після перевірки отриманого ключового коду трансакції в базі даних. Схе 4 ма здійснення безготівкових платежів за способом, описаним в І.ІА № 64840. представлена на Фіг. 1. Недоліком відомого способу є його недостатня надійність при здійсненні платіжних трансакцій. [У патенті UA 64840 С2] покупець контактує безпосередньо з центром обробки платіжних трансакцій, в якому акумулюються дані про рахунки всіх покупців. Зосередження конфіденційної інформації в центрі обробки платіжних трансакцій є ризикованим, оскільки у разі її недобросовісного використання можуть постраждати інтереси всіх клієнтів, дані яких зберігаються у вказаному центрі. В основу даної корисної моделі поставлена задача - спростити спосіб здійснення безготівкових платежів за рахунок вилучення зі способу здійснення безготівкових платежів посередників. Поставлена задача досягається тим, що в способі здійснення безготівкових платежів з рахунку платника у фінансовій установі платника на рахунок отримувача у фінансовій установі отримувача у межах платіжної системи платник здійснює передачу у фінансову установу платника авторизованого умовного платіжного доручення, що містить принаймні суму платежу, після цього у фінансовій установі платника генерують ключовий код. який разом з умовним платіжним дорученням зберігають у інформаційній системі та надсилають платнику, який далі передає одержаний ключовий код отримувачу, після нього отримувач здійснює передачу у фінансову установу отримувача авторизованого запиту, що містить принаймні ключовий код, одержаний від платника, причому, а) якщо фінансова установа платника є фінансовою установою отримувача, то після перевірки на відповідність умовного платіжного доручення, одержаного від платника, із авторизованим запитом, одержаним від отримувача, на то тожність принаймні ключового коду. присутнього в них, здійснюють переказ коштів, або б) якщо фінансова установа платника не є фінансовою установою отримувача, то фінансова установа отримувача здійснює передачу авторизованого запиту, що містить принаймні ключовий код, у платіжну організацію, після чого платіжна організація здійснює передачу авторизованого запиту, що містить принаймні ключовий код у фінансову установу платника і після перевірки на відповідність умовного платіжного доручення. одержаного від платника, із авторизованим запитом, одержаним від платіжної організації, на тотожність принаймні ключового коду, присутнього в них. здійснюють переказ коштів. При цьому передачу вказаних даних здійснюють з терміналів, сполучених між собою за допомогою телекомунікаційних мереж. Термінал мас принаймні мікропроцесор та дисплей. Термінал вибраний з групи, яка включає мобільний телефон, персональний комп'ютер, кишеньковий персональний комп'ютер або пейджер. Авторизований запит, який направляє отримувач у фінансову установу о тримувача, містить ключовий код та суму платежу, одержані від плат 5 36638 ника, а перевірка на відповідність умовного платіжного доручення з авторизованим запитом включає перевірку на тотожність вказаних ключового коду та суми платежу. До здійснення переказу коштів якщо фінансова установа платника є фінансовою установою отримувача, фінансова установа надсилає авторизоване повідомлення гарантії оплати отримувачу, або, якщо фінансова установа платника не є фiнaнcoвoю установою отримувача, фінансова установа платника надсилає авторизоване повідомлення гарантії оплати платіжній організації, яка надсилає авторизоване повідомлення гарантії оплати у фінансову установу отримувача, а фінансова установа отримувача надсилає авторизоване повідомлення гарантії оплати отримувачу. Повідомлення гарантії надсилають відразу після перевірки на відповідність умовного платіжного доручення, одержаного від платника, із авторизованим запитом, одержаним від отримувача, у фінансовій установі платника. До генерування ключового коду фінансова установа платника виконує перевірку платника, щодо можливості акцептування умовного платіжного доручення. Переказ коштів виконують протягом визначеного платіжною системою строку. Фінансовою установою платника є банкемітент, а фінансовою установою отримувача є банк-еквайєр. Далі наводяться терміни, які використовуються в даному описі та їх визначення. Платіжна система - платіжна організація, члени платіжної системи та сукупність відносин, що виникають між ними при проведенні переказу коштів. Проведення переказу коштів є обов'язковою функцією, що має виконувати платіжна система. Платник - учасник платіжної системи, який ініціює платіж засобами платіжної системи. Отримувач - учасник платіжної системи, який отримує кошти засобами платіжної системи. Банк-емітент член платіжної системи фінансово-кредитна установа, що обслуговує платника. Банк-еквайєр - член платіжної системи фінансово-кредитна установа, що обслуговує о тримувача. Ключовий код - послідовність символів, яку для кожної події емісії створює банк-емітент. Умовне платіжне доручення - доручення, що містить, принаймні суму платежу. яке надає платник банку-емітента на переказ коштів отримувачу. Інформаційна система - сукупність програмних та апаратних засобів, які застосовуються для зберігання і обробки інформації та розмежування прав доступу до окремих її частин. SSL - відкритий протокол, розроблений компанією Netscape, який визначає механізм підтримки безпеки даних на рівні між протоколом TCP/IP та протоколами, які використовують програми високого рівня (Hypertext Transfer Protocol [HTTP], Telnet, Network News Transfer Protocol [NNTPJ или File Transfer Protocol [FTP]). SSL підтримує шифрування даних, аутентифікацію серверів та клієнтів. Був затверджений консорціумом W3C в якості 6 стандартного засобу безпеки WEB браузерів і серверів. RSA - метод ши фр ування, який був розроблений у 1997 році RSA Data Security. Метод оснований на системі с подвійними ключами приватним та публічним. (RSA це скорочення, яке утворене від перших літер прізвищ трьох засновників RSA Data Security -Rivest. Shamir. Adelman.) Персональний засіб авторизації (ПЗА) - пристрій, що призначений для суворої аутентифікації користувача та збереження його персональних ключів шифрування. 1ІЗА тимчасово приєднується до термінального пристрою та на апаратному рівні підтримує роботу з цифровими сертифікатами та електронним цифровим підписом. Аутентифікація - процедура ідентифікації особи користувача та перевірки його прав доступу до інформації або виконання певних дій. Ключ шифр ування - набір секретних параметрів для алгоритму шифр ування, які визначають його унікальні умови засекречування (або розсекречування) інформації. Далі наводиться приклади практичної реалізації заявленої корисної моделі. Приклад 1 Приклад 1 описує випадок, коли банк-емітент і банк-еквайєр є різними банками. З метою поповнення рахунку у оператора зв'язку клієнт на сайті оператора отримує. інформацію про мінімальний платіж. Після цього клієнт відвідує WEB сторінку власного банку-емітента, який обслуговує його картковий рахунок, та завантажує звідти програму авторизації, активує програму авторизації та авторизується шляхом підключення персонального засобу авторизації (ПЗА) до ГSB порту комп'ютера. Програма авторизації запитує у клієнта сум у платежу та формує умовне платіжне доручення банку. Це доручення програма авторизації завантажує у ПЗА, у якому знаходиться мікросхема, заздалегідь запрограмована на алгоритм цифрового підпису. ПЗА підписує умовне платіжне доручення, використовуючи алгоритм RSA та повертає його програмі авторизації. Програма авторизації за допомогою протоколу SSL встановлює з'єднання з банком-емітентом через мережу Інтернет та передає банку умовне платіжне доручення. Банк-емітент обчислює за алгоритмом RSA набір символів з яких складається умовне платіжне доручення та порівнює отриману послідовність символів з публічним електронним ключем клієнта, що зберігається в інформаційній системі банку. У разі тотожності банк-емітент перевіряє кошти клієнта на рахунку на відповідність встановленим лімітам з урахуванням суми умовного доручення. Якщо ліміти не перевищені, банк-емітент акцептує, умовне платіжне доручення, генерує ключовий код та зберігає його разом з умовним платіжним дорученням у власній інформаційній системі. Після чого, банк-емітент передає ключовий код програмі авторизації. 7 36638 Програма авторизації повідомляє клієнта про вдале акцептування умовного платіжного доручення та пред'являє клієнту ключовий код. Клієнт копіює ключовий код у кліпбоард та переносить його у спеціальну форму на сайті оператора. Отримавши ключовий код, оператор формує запит гарантії оплати, який містить ключовий код та суму платежу, додає до нього власний електронний підпис, встановлює SSL з'єднання з банкомеквайєром, який обслуговує оператора, авторизується за механізмом, що передбачений банком, та передає запит гарантії оплати у інформаційну систему банка-еквайєра. Отримавши запит гарантії оплати, інформаційна система банка-еквайєра перевіряє електронний підпис оператора і у разі тотожності, за встановленим платіжною системою алгоритмом на основі ключового коду встановлює який банкемітент згенерував ключовий код, і у випадку якщо це інший банк. додає, до запиту гарантії оплати електронний підпис банка-еквайєра та передає до інформаційної системи (ІC) платіжної системи. Отримавши запит гарантії оплати, ІC платіжної системи перевіряє електронний підпис банкаеквайєра. і у разі тотожності, за встановленим платіжною системою алгоритмом на основі ключового коду встановлює, який банк-емітент згенерував кдючовий код. перевіряє залишки по лімітах банка-емітента в платіжній системі з урахуванням суми. яка зазначена у запиті, і у разі не перевищення лімітів, додає до запита гарантії оплати власний електронний підпис та передає запит гарантії оплати до відповідної о банку-емітента. Отримавши запит гарантії оплати, ІC банкуемітента, перевіряє електронний підпис платіжної системи, і у разі тотожності перевіряє запит гарантії оплати на відповідність будь-якому умовному платіжному дорученню, що зберігається в ІC банку-емітента за тотожністю ключового коду. Якщо таке умовне доручення існує, банк-емітент додає до запита гарантії оплати власний електронний підпис та повертає гарантію оплати до ІC платіжної системи. Отримавши гарантію оплати від банку емітента, ІC платіжної системи перевіряє електронний підпис банка-емітента, і у разі тотожності, зменшує ліміт банку-емітенту у платіжній системі, додає до гарантії власний електронний підпис та повертає гарантію оплати ІC бапку-еквайєру. Отримавши гарантію оплати від банку емітента, ІC банка-еквайєра перевіряє електронний підпис платіжної системи, і у разі тотожності, додає до гарантії власний електронний підпис та повертає гарантію оплати оператору. Отримавши гарантію оплати від банкаеквайєра, оператор перевіряє електронний підпис банка-еквайєра та у разі тотожності, поповнює рахунок клієнта у власній білінговій системі та повідомляє про це клієнта. Схема здійснення безготівкового платежу, що описана в Прикладі 1, представлена на Фіг.2 В кінці поточного банківського дня банкиучасники проводять клірінг та за його результатами перераховують кошти з рахунку клієнта у бан 8 ку-емітенту до рахунка оператора v банку-еквайєрі з врахуванням комісії членів платіжної системи та розподіляють комісію між собою. У результаті виконаних операцій відбувається поповнення рахунку клієнта у оператора зв'язку. Приклад 2 Приклад 2 стосується випадку, коли банкемітент і банк-еквайєр є одним банком. З метою поповнення рахунку у оператора зв'язку клієнт на сайті оператора отримує інформацію про мінімальний платіж. Після цього клієнт відвідує WEB сторінку власного банку-емітента, який обслуговує його картковий рахунок, та завантажує звідти програму авторизації. Потім активує завантажену програму авторизації та авторизується шляхом підключення персонального засобу авторизації (ПЗА) до USB порту комп'ютера. Програма авторизації запитує у клієнта сум у платежу та формує умовне платіжне доручення банку. Це доручення програма авторизації завантажує у ПЗА. у якому знаходиться мікросхема, заздалегідь запрограмована на алгоритм цифровою підпису. ПЗА підписує умовне платіжне доручення, використовуючи алгоритм RSA та повертає його програм і авторизації. Програма авторизації за допомогою протоколу SSL встановлює з'єднання з банком-емітентом через мережу Інтернет та передає банку умовне платіжне доручення. Банк-емітент обчислює за алгоритмом RSA набір символів, з яких складається умовне платіжне доручення, та порівнює отриману послідовність символів з публічним електронним ключем клієнта, що зберігається в інформаційній системі банку. У разі тотожності, банк-емітент перевіряє кошти клієнта на рахунку на відповідність встановленим лімітам з урахуванням суми умовного доручення. Якщо ліміти не перевищені, банк-емітент акцептує умовне платіжне доручення, генерує ключовий код та зберігає його разом з умовним платіжним дорученням у власній інформаційній системі. Після чого. банк-емітент передає ключовий код програмі авторизації. Програма авторизації повідомляє клієнта про вдале акцептування умовного платіжного доручення та пред'являє клієнту ключовий код. Клієнт копіює ключовий код у кліпбоард та переносить його у спеціальну форму на сайті оператора. Отримавши ключовий код, оператор формує запит гарантії оплати, який містить ключовий код та сумуплатежу, додає до нього власний електронний підпис, встановлює SSL з'єднання з банкомеквайєром, який обслуговує оператора, авторизується за механізмом, що передбачений банком, та передає запит гарантії оплати у інформаційну систему банка-еквайєра. Отримавши запит гарантії оплати, інформаційна система банка-еквайєра перевіряє електронний підпис оператора і. у разі тотожності, за встановленим платіжною системою алгоритмом на основі ключового коду встановлює, який банкемітент згенерував ключовий код. і. у випадку, якщо банк-емітент і банк-еквайєр співпадають, 9 36638 додає до запита гарантії оплати власний електронний підпис, та перевіряє запит гарантії оплати на відповідність будь-якому умовному платіжному дорученню, ідо зберігається у власній ІC за тотожністю ключового коду. Якщо такс умовне доручення існує, банкеквайєр додає до запита гарантії оплати власний електронний підпис та повертає гарантію оплати оператору. Отримавши гарантію оплати від банкуеквайєра. оператор перевіряє електронний підпис банка-сквайєра та. у разі тотожності, повідомляє 10 клієнта про акцептування платежу та надає клієнту код поповнення рахунку у власній білінговій системі. В кінці поточного банківського дня банкеквайєр перераховує кошти з ра хунку платника у на рахунок оператора з врахуванням власної комісії. У результаті виконаних операцій відбувається поповнення рахунку клієнта у оператора зв'язку. Схема здійснення безготівкового платежу, що описана в Прикладі 2. представлена на Фіг.3. 11 Комп’ютерна в ерстка Н. Лисенко 36638 Підписне 12 Тираж 28 прим. Міністерство осв іт и і науки України Держав ний департамент інтелектуальної в ласності, вул. Урицького, 45, м. Київ , МСП, 03680, Україна ДП “Український інститут промислов ої в ласності”, вул. Глазунова, 1, м. Київ – 42, 01601