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

Спосіб функціонування електронної інформаційної системи укладання контрактів, який відрізняється тим, що системою реєструють учасників, системою наділяють їх внутрішніми ідентифікаторами, користувачі конфіденційно, автентично та ЦІЛІСНО отримують ідентифікатори доступу, які передаються системою, застосовують корпоративний ПІДХІД сторони до укладання контракту (ідентифікатори доступу мають різні типи політик ідентифікатори користувачів, що приймають рішення при укладанні угоди, ідентифікатори користувачів з частковою обмеженістю дій у системі, ідентифікатори користувачів з повною обмеженістю дій у системі), учасники укладають генеральну угоду з системою, при доступі користувачів з частковою та повною обмеженістю дій встановлюють захищений канал зв'язку користувача з електронною інформаційною системою укладання контрактів, системою розпізнають політику переданих ідентифікаторів, системою запрошують користувачів встановити власну автентичність, користувачі передають власні сертифікати з відкритими ключами шифрування, системою оброблюють сертифікати, системою запрошують користувачів передати до системи найменування та ІНШІ дані, які визначають користувачів, цю інформацію шифрують секретним ключем користувача, шифровані дані передають до системи, системою дешифрують дані, використовуючи відкритий ключ, переданий раніше з сертифікатом, системою порівнюють введені дані з даними сертифікату, системою дозволяють або забороняють доступ користувача до системи, під цим ім'ям (найменуванням), використовуючи поточні ідентифікатори, при створенні контракту з електронною інформаційною системою укладання контрактів використовують додаткові засоби, на етапі створення сторони, які укладають договір, можуть користуватися інтерактивною дискусійною системою, шифруючи сеансовим ключем дані, які передають, у процесі доробки та редагування контракту, сторони визначають пріоритети внесення змін кожною із сторін, сторона, чий пріо ритет найвищий, ставить змінені дані у чергу завантаження, щоб змінити поточні дані, сторониініціатори змін супроводжують повідомленням, де коментують внесені зміни, ІНШІ сторони ознайомлюють з поправками, внесеними стороноюініціатором змін, ІНШІ сторони розглядають запропоновані зміни, приймають рішення про твердження або відхилення змін, при частковій або повній незгоді сторін з пропонованими змінами, вони відхиляють пропозицію, вказують причину та можливе компромісне рішення, знімають поточну змінену інформацію з черги завантаження, доробляють, ураховуючи компромісне рішення, та знову подають у чергу завантаження, придбавши пріоритет, при підтримці зміни усіма сторонами контракту, системою генерують значення, яким характеризують згоду сторін, це значення передають всім сторонам, використовуючи захищені канали зв'язку, шифруючи відкритим ключем сторони, яким передають, сторони дешифрують це значення власним секретним ключем та знову шифрують це значення власним секретним ключем і передають до системи, системою дешифрують кожне шифроване значення ВІДПОВІДНИМ відкритим ключем користувача, який це значення шифрував, всі дешифровані значення порівнюють системою, і якщо ВИХІДНІ дані всіх сторін рівні, це означає одностайну думку всіх сторін та рішення приймають, якщо ні - то навпаки, при підтвердженні одностайної думки учасників договору здійснюють заміщення поточних даних угоди в системі на нові, при передачі даних контракту до електронної інформаційної системи укладання контрактів системою імітування цих даних (даних контракту) використовують спосіб інтегрування електронної інформаційної системи укладання контрактів з системою емітування контрактів, яким гарантують ЦІЛІСНІСТЬ, конфіденційність та автентичність передачі згенерованих даних для підтвердження учасниками та уповноваженою електронною інформаційною системою укладання контрактів, у залежності від політик, які супроводжують дані, що передають, з системою емітування контрактів визначають повний, частковий дозвіл або недозвіл на втручання та редагування даних, переданих сторонами, які беруть участь в укладанні угоди за предметом переданих даних, політики на дані, які передають, визначають у системі емітування контрактів перед їх О) 7704 дійсною передачею до електронної інформаційної системи укладання контрактів, при одностайному рішенні про затвердження контракту в електронну інформаційну систему укладання контрактів, системою встановлюють остаточнузаборону на зміну даних угоди (блокують функцію редагування) та затверджують угоду: сторони шифрують згенероване значення, яке означає блокування функції редагування секретним ключем і передають до системи, системою дешифрують кожне шифроване значення відповідним відкритим ключем користувача, всі дешифровані значення порівнюють системою: якщо вихідні дані всіх сторін рівні, це означає одностайну думку всіх сторін та рішення про затвердження угоди системою приймають, якщо ні - то навпаки, якщо підтверджується одностайна думка учасників договору, то системою формують архів шифрованої інформації даних угоди секретними ключами учасників, присвоюють значення терміну дії та іншу додаткову інформацію; архів шифрують секретним ключем електронної інформаційної системи укладання контрактів, затверджений секретним ключем архів розпізнають, дешифруючи відкритим ключем сертифіката електронної інформаційної системи укладання контрактів, затверджений договір за бажанням користувачів зберігають в електронній інформаційній системи укладання контрактів на термін його дії, до затвердженого контракту встановлюють окремі ідентифікатори доступу, для затвердження в електронній інформаційній системи укладання контрактів приймають формалізовані та неформалізовані дані, по закінченні терміну дії договору в електронній інформаційній системи укладання контрактів передбачають два варіанти відповідних дій: попереднє лонгування або видалення із бази даних електронної інформаційної системи укладання контрактів про що повідомляють сторін, при лонгуванні одна із сторін стає ініціатором лонгування, генерують відповідне значення про лонгування, це значення передають всім сторонам, використовуючи захищені канали зв'язку, шифруючи відкритим ключем сторон, яким передають, сторони дешифрують значення про лонгування секретним ключем та знову шифрують це значення секретним ключем і передають до системи, системою дешифрують кожне шифроване значення відповідним відкритим ключем користу вача, який це значення шифрував, всі дешифровані значення порівнюють системою: якщо вихідні дані всіх сторін рівні, це означає одностайну думку всіх сторін та рішення про лонгування приймають, якщо ні - то навпаки, лонгування угоди може бути з попереднім редагуванням договору, щоб внести зміни у дані контракту, сторони визначають пріоритети внесення змін кожною із сторін, сторона, чий пріоритет найвищий, ставить змінені дані у чергу завантаження, щоб змінити поточні дані, сторони-ініціатори змін супроводжують повідомленням, де коментують внесені зміни, інші сторони ознайомлюють з поправками, внесеними стороною-ініціатором зміни, інші сторони розглядають запропоновані зміни, приймають рішення про затвердження або відхилення змін, при частковій або повній незгодні сторін з пропонованими змінами, вони відхиляють пропозицію, вказують причину та можливе компромісне рішення, знімають поточну змінену інформацію з черги завантаження, доробляють, ураховуючи компромісне рішення, та знову подають у чергу завантаження, придбавши пріоритет, при підтримці зміни усіма сторонами контракту, системою генерують значення, яким характеризують згоду сторін, це значення передають всім сторонам, використовуючи захищені канали зв'язку, шифруючи відкритим ключем сторони, яким передають, сторони дешифрують це значення власним секретним ключем та знову шифрують це значення власним секретним ключем і передають до системи, системою дешифрують кожне шифроване значення відповідним відкритим ключем користувача, який це значення шифрував, всі дешифровані значення порівнюють системою: якщо вихідні дані всіх сторін рівні, це означає одностайну думку всіх сторін та рішення приймають, якщо ні - то навпаки, при підтвердженні одностайної думки учасників договору здійснюють заміщення поточних даних угоди в системі на нові, після остаточних виправлень угоду затверджують, при непідтримці однієї із сторін думки більшості (про лонгування), якщо останні сторони мають рацію продовжити виконання контракту без участі цієї сторони, то вони генерують новий обліковий запис договору у системі з новими ідентифікаторами, угоду вважають розірваною в електронній інформаційній системи укладання контрактів, якщо це підтверджують всі сторони контракту. Корисна модель відноситься до області інформаційних систем та систем в електронній комерції типу В2В, В2С і може бути використаний при розробці та укладанні контрактів в інтерактивному режимі. В основу корисної моделі поставлена задача розробки способу функціонування електронної інформаційної системи укладання контрактів (далі ЕІСУК), який надасть можливості інтерактивної розробки угоди у середовищі системи, укладання договору у системі необмеженою кількістю учасників, фактичного затвердження контракту при пере дачі його з будь-якої системи, яка емітує контракт до ЕІСУК, як уповноваженою системою. Поставлена задача досягається тим, що системою реєструють учасників, системою наділяють їх внутрішніми ідентифікаторами, користувачі конфіденційно, автентичне та цілісно отримують ідентифікатори доступу, які передаються системою, застосовують корпоративний підхід сторони до укладання контракту (ідентифікатори доступу мають різні типи політик: ідентифікатори користувачів, що приймають рішення при укладанні угоди, ідентифікатори користувачів з частковою обмеже 7704 ністю дій у системі, ідентифікатори користувачів з повною обмеженістю дій у системі), учасники укладають генеральну угоду з системою, при доступі користувачів з частковою та повною обмеженістю дій встановлюють захищений канал зв'язку користувача з електронною інформаційною системою укладання контрактів (ЕІСУК), системою розпізнають політику переданих ідентифікаторів, системою запрошують користувачів встановити власну автентичність, користувачі передають власні сертифікати з відкритими ключами шифрування, системою оброблюють сертифікати, системою запрошують користувачів передати до системи найменування та інші дані, які визначають користувачів, цю інформацію шифрують секретним ключем користувача, шифровані дані передають до системи, системою дешифрують дані, використовуючи відкритий ключ, переданий раніше з сертифікатом, системою порівнюють введені дані з даними сертифікату, системою дозволяють або забороняють доступ користувача до системи, під цим ім'ям (найменуванням), використовуючи поточні ідентифікатори, при створенні контракту в ЕІСУК використовують додаткові засоби, на етапі створення, сторони, які укладають договір, можуть користуватися інтерактивною дискусійною системою, шифруючи сеансовим ключем дані, які передають, у процесі доробки та редагуванні контракту, сторони визначають пріоритети внесення змін кожною із сторін, сторона, чий пріоритет найвищий ставить змінені дані у чергу завантаження, щоб змінити поточні дані, сторони-ініціатори змін супроводжують повідомленням, де коментують внесені зміни, інші сторони ознайомлюють з поправками, внесеними стороною-ініціатором змін, інші сторони розглядають запропоновані зміни, приймають рішення про твердження або відхилення змін, при частковій або повній незгодні сторін з пропонованими змінами, вони відхиляють пропозицію, вказують причину та можливе компромісне рішення, знімають поточну змінену інформацію з черги завантаження, доробляють ураховуючи компромісне рішення та знову подають у чергу завантаження придбавши пріоритет, при підтримці зміни усіма сторонами контракту, системою генерують значення, яким характеризують згоду сторін, це значення передають всім сторонам, використовуючи захищені канали зв'язку, шифруючи відкритим ключем сторони, якій передають, сторони дешифрують це значення власним секретним ключем та знову шифрують це значення власним секретним ключем і передають до системи, системою дешифрують кожне шифроване значення відповідним відкритим ключем користувача, який це значення шифрував, всі дешифровані значення порівнюють системою: якщо вихідні дані всіх сторін рівні, це означає одностайну думку всіх сторін та рішення приймають, якщо ні - то навпаки, при підтвердженні одностайної думки учасників договору, здійснюють заміщення поточних даних угоди в системі на нові, при передачі даних контракту до ЕІСУК системою емітування цих даних (даних контракту) використовують спосіб інтегрування електронної інформаційної системи укладання контрактів з системою емітування контрактів (СЕК), яким гара нтують цілісність, конфіденційність та автентичність передачі згенерованих даних для підтвердження учасниками та уповноваженою системою (ЕІСУК), у залежності від політик, які супроводжують дані, що передають з СЕК визначають на повний, частковий дозвіл або недозвіл на втручання та редагування даних, переданих сторонами, які беруть участь в укладанні угоди за предметом переданих даних, політики на дані, які передають визначають у СЕК перед їх дійсною передачею до ЕІСУК, при одностайному рішенні про затвердження контракту в ЕІСУК, системою встановлюють остаточну заборону на зміну даних угоди (блокують функцію редагування) та затверджують угоду: сторони шифрують згенероване значення, яке означає блокування функції редагування, секретним ключем і передають до системи, системою дешифрують кожне шифроване значення відповідним відкритим ключем користувача, всі дешифровані значення порівнюють системою: якщо вихідні дані всіх сторін рівні, це означає одностайну думку всіх сторін та рішення про затвердження угоди системою приймають, якщо ні - то навпаки, якщо підтверджується одностайна думка учасників договору, то системою формують архів шифрованої інформації даних угоди секретними ключами учасників, привласнюють значення терміну дії та іншу додаткову інформацію; архів шифрують секретним ключем ЕІСУК, затверджений секретним ключем архів розпізнають, дешифруючи відкритим ключем сертифікату ЕІСУК, затверджений договір за бажанням користувачів зберігають в ЕІСУК на термін його дії, до затвердженого контракту встановлюють окремі ідентифікатори доступу, для затвердження в ЕІСУК приймають формалізовані та неформалізовані дані, по витіканню терміну дії договору в ЕІСУК передбачають два варіанти відповідних дій: попереднє лонгування або видалення із бази даних ЕІСУК про що повідомляють сторін, при лонгуванні одна із сторін стає ініціатором лонгування, генерують відповідне значення про лонгування, це значення передають всім сторонам, використовуючи захищені канали зв'язку, шифруючи відкритим ключем сторони, якій передають, сторони дешифрують значення про лонгування секретним ключем та знову шифрують це значення секретним ключем і передають до системи, системою дешифрують кожне шифроване значення відповідним відкритим ключем користувача, який це значення шифрував, всі дешифровані значення порівнюють системою: якщо вихідні дані всіх сторін рівні, це означає одностайну думку всіх сторін та рішення про лонгування приймають, якщо ні - то навпаки, лонгування угоди може буди с попереднім редагуванням договору, щоб внести зміни у дані контракту, сторони визначають пріоритети внесення змін кожною із сторін, сторона, чий пріоритет найвищий ставить змінені дані у чергу завантаження, щоб змінити поточні дані, сторони-ініціатори змін супроводжують повідомленням, де коментують внесені зміни, інші сторони ознайомлюють з поправками, внесеними стороною-ініціатором зміни, інші сторони розглядають запропоновані зміни, приймають рішення про твердження або відхиленя змін, при частковій або 7704 повній незгоді сторін з пропонованими змінами, вони відхиляють пропозицію, вказують причину та можливе компромісне рішення, знімають поточну змінену інформацію з черги завантаження, доробляють ураховуючи компромісне рішення та знову подають у чергу завантаження, придбавши пріоритет, при підтримці зміни усіма сторонами контракту, системою генерують значення, яким характеризують згоду сторін, це значення передають всім сторонам, використовуючи захищені канали зв'язку, шифруючи відкритим ключем сторони, якій передають, сторони дешифрують це значення власним секретним ключем та знову шифрують це значення власним секретним ключем і передають до системи, системою дешифрують кожне шифроване значення відповідним відкритим ключем користувача, який це значення шифрував, всі дешифровані значення порівнюють системою: якщо вихідні дані всіх сторін рівні, це означає одностайну думку всіх сторін та рішення приймають, якщо ні - то навпаки, при підтвердженні одностайної думки учасників договору, здійснюють заміщення поточних даних угоди в системі на нові, після остаточних виправлень угоду затверджують, при не підтримці однієї із сторін думки більшості (про лонгування), якщо останні сторони мають рацію продовжити виконання контракту без участі цієї сторони, то вони генерують новий обліковий запис договору у системі з новими ідентифікаторами, угоду вважають розірваною в ЕІСУК якщо це підтверджують всі сторони контракту. Згідно з корисною моделлю, ЕІСУК реєструє учасників на основі виданих їм цифрових сертифікатів, які встановлюють автентичність учасника, і відповідно, на основі цих фактів Система наділяє їх власними внутрішніми ідентифікаторами, шифруючи їх відкритим ключем сертифікату користувача. Користувач конфіденційно, автентично та цілісно отримує передані ідентифікатори доступу, дешифруючи їх власним секретним ключем (парним відкритому у сертифікаті). Паралельним етапом реєстрації учасника в ЕІСУК, є укладення генеральної угоди.Генеральну угоду укладають в електронному вигляді (підтверджують дійсними електронними сертифікатами або електронним цифровим підписом (ЕЦП)), у разі неможливості укладення угоди раніше описаним способом, її укладають традиційним способом. Угоду створюють відповідно до чинного, на момент його укладання сторонами, законодавства. Нові умови Угоди вважаються прийнятими будь-яким з учасників ЕІСУК, який продовжив свою участь у процедурах після встановлення нових умов Угоди. Користувачів реєструють на строк, відповідний строку придатності електронного сертифікату. Передані ідентифікатори доступу можуть передаватися іншими способами, наприклад, додатком до генеральної угоди у письмовій формі або, використовуючи іншу електронну модель передачі ідентифікаторів. Ідентифікатори мають три типи політик, на які вони розповсюджуються. • Перший вид ідентифікаторів: ідентифікатори для головного користувача, який приймає основні рішення при затвердженні угоди в ЕІСУК, його політика - повного доступу. Під цим ідентифікатором 8 може виступати тільки одна особа, сертифікат якої міститься у системі. • Другий вид ідентифікаторів: ідентифікатори для користувачів з частковою обмеженістю дій у системі, він може виступати у ролі радника для головного користувача. Під цим ідентифікатором може виступати необмежена кількість учасників, яка регулюється тільки головним користувачем. • Третій вид ідентифікаторів: ідентифікатори для користувачів з повною обмеженістю дій у системі, він може виступати тільки у ролі спостерігача. Під цим ідентифікатором може виступати необмежена кількість учасників, яка регулюється тільки головним користувачем. Примітка: Головний користувач може встановити заборону на будь-якого користувача з меншим пріоритетом політики, терміново або безстроково виключив його зі списку допущених користувачів Такий метод застосовується для можливості корпоративного підходу до контракту, який укладають. Різновид ідентифікаторів дозволяє здійснювати інтерактивні внутрішні корпоративні переговори у захищеній середі ЕІСУК. При доступі користувачів з частковою та повною обмеженістю дій, використовується наступний процес (див. Схема 1 "Процес доступу користувачів з частковою та повною обмеженістю"): встановлюється захищений канал зв'язку користувача з ЕІСУК на рівні захищеного протоколу передачі даних, що забезпечує конфіденційну та цілісну передачу даних; користувач передає ідентифікатори до системи; система розпізнає політику переданих ідентифікаторів та запрошує користувача встановити власну автентичність; користувач передає власний сертифікат з відкритим ключем; системою оброблюється сертифікат на предмет витікання строку використання; після успішної перевірки, система запрошує передачу найменування та інші дані, які визначають користувача, до системи, ця інформація шифрується секретним ключем користувача; шифровані дані передаються до системи; система дешифрує дані, використовуючи відкритий ключ, переданий раніше з сертифікатом; системою порівнюються введені дані з даними сертифікату; системою дозволяється доступ користувача до системи, під цим ім'ям (найменуванням), використовуючи поточні ідентифікатори або забороняється такий доступ. До ідентифікаторів належать не тільки ідентифікатори доступу але й ключ (якщо симетричні) або ключі (якщо парні: відкритий та секретний) для внутрішнього шифрування/дешифрування даних в ЕІСУК. Система має два основних типи затвердження даних угоди: коли дані створюються у системі та коли дані передаються до системи іншою системою, де вони генеруються. Затвердження створених та редагованих даних в ЕІСУК. У випадку створення контракту в ЕІСУК використовуються додаткові засоби для цього здійснення (інтегрування ЕІСУК з різними додатковими системами, архівними базами даних, тощо). На етапі створення, сторони, які укладають договір 7704 можуть користуватися інтерактивною дискусійною системою, шифруючи сеансовим ключем дані, які передаються. Процес доробки та редагування має наступну форму (див. Схема 2 "Процес прийняття змін у поточних документах, яки мають бути затвердженими в ЕІСУК"): щоб внести зміни у дані контракту, сторони повинні визначити пріоритети внесення змін кожною із сторін; сторона, чий пріоритет найвищий (яка перша запропонувала зміну) ставить змінені дані у чергу завантаження, щоб зміни поточні дані, сторона-ініціатор зміни супроводжує повідомленням, де коментує внесені зміни; інші сторони ознайомлюються з поправками, внесеними стороною-ініціатором зміни, коментують зміни, які пропонуються, приймають рішення про твердження або відхилення змін. У випадку, коли одна із сторін частково або цілком не згодна з пропонованими змінами, вона відхиляє пропозицію, вказує причину та можливе компромісне рішення. У випадку, якщо всі сторони підтримують цю сторону (сторону-опозицію сторони ініціатора зміни) та сама сторона-ініціатор зміни, то остання знімає поточну змінену інформацію з черги завантаження, доробляє ураховуючи компромісне рішення та знову подає у чергу завантаження, придбавши пріоритет. У випадку, якщо зміну підтримують всі сторони контракту (див. Схема З "Процес підтвердження користувачів в ЕІСУК"), системою генерується деяке значення (яке характеризує згоду сторін) та це значення передається всім сторонам, використовуючи захищені канали зв'язку, шифруючи відкритим ключем сторони, якій передається; кожна із сторін дешифрує це значення секретним ключем та знову шифрує це значення секретним ключем і передає до системи; система дешифрує кожне шифроване значення відповідним відкритим ключем користувача, який це значення шифрував; всі дешифровані значення порівнюються системою: якщо вихідні дані всіх сторін рівні, це означає одностайну думку всіх сторін та рішення приймається, якщо ні - то навпаки. Якщо підтверджується одностайна думку учасників договору, то здійснюється заміщення поточних даних угоди в системі на нові (виправлені). Примітка: Якщо сторона-ініціатор зміни доробляє поправки, ураховуючи компромісне рішення, яке було встановлене усіма сторонами, при відправці на заміщення, дані, які відправляються повинні містити усі зміни, які були внесені протягом терміну з пропонування до надбання пріоритету завантаження даних. Примітка: Редагування та зміна даних відбувається у залежності від політик, які поширюються на редагування та можливості редагування в інтерактивному режимі чи можливості інтеграції даних з системою редактору таких даних. Затвердження переданих даних до ЕІСУК. У випадку передачі даних контракту до ЕІСУК системою емітування цих даних (даних контракту) використовується спосіб інтегрування електронної інформаційної системи укладання контрактів з системою емітування контрактів (СЕК), який гарантує цілісність, конфіденційність та автентичність 10 при передачі згенерованих даних для підтвердження учасниками та уповноваженою системою (ЕІСУК) щоб надати угоді юридичну силу. У залежності від політик, які супроводжують дані, що передаються з СЕК визначені на повний, частковий дозвіл або недозвіл на втручання та редагування переданих даних сторонами, які беруть участь в укладанні угоди за предметом переданих даних. Політики на дані, які передаються визначаються у СЕК перед їх дійсною передачею до ЕІСУК. Це пояснюється вимогами, які ставляться перед даними у СЕК. Таким чином, дані можуть передаватися з метою затвердження без можливості зміни; з метою затвердження з попереднім редагуванням деяких сегментів переданих даних (політика поширюється на недозвіл на втручання до деякої інформації); з метою затвердження даних з попереднім редагуванням. Затвердження даних договору в ЕІСУК. При одностайному рішенні про затвердження контракту в ЕІСУК, системою встановлюють остаточну заборону на зміну даних угоди (блокують функцію редагування) та затверджують угоду (див. Схема 4 "Процес затвердження і підписання даних в ЕІСУК"): кожна із сторін шифрує згенероване значення, яке означає блокування функції редагування, секретним ключем і передає до системи; система дешифрує кожне шифроване значення відповідним відкритим ключем користувача, який угоду шифрував; всі дешифровані значення порівнюються системою: якщо вихідні дані всіх сторін рівні, це означає одностайну думку всіх сторін та рішення про затвердження угоди системою приймається, якщо ні - то навпаки. Якщо підтверджується одностайна думка учасників договору, то система формує архів шифрованої інформації даних угоди секретними ключами учасників; привласнюється значення терміну дії та інша додаткова інформація; архів шифрується секретним ключем ЕІСУК. Затверджений секретним ключем архів можна розпізнати, дешифруючи відкритим ключем сертифікату ЕІСУК. Затверджений договір за бажанням користувачів можна зберегти в ЕІСУК на термін його дії. До затвердженого контракту встановлюються окремі ідентифікатори доступу з метою отримання інтерактивного доступу в будьякий час кожною із сторін-учасників згоди, які брали участь при укладенні. Для затвердження в ЕІСУК, дані не повинні обов'язково мати визначений характер та формалізований вигляд, якщо це відеоматеріали конференції (де сторони укладають усну угоди), протоколи процесу, тощо. Лонгування даних угоди в УІСУК. По витіканню терміну дії договору в ЕІСУК передбачається два варіанти відповідних дій: попереднє лонгування або видалення із бази даних ЕІСУК про що повідомляють сторін. Лонгування можливе лиши при одностайному рішенні про це усіх сторін згоди (див. Схема 5 "Процес лонгування договорів в ЕІСУК"). Для цього одна із сторін стає ініціатором лонгування: генерується відповідне значення про лонгування, це значення передається всім сторонам, використовуючи захищені канали зв'язку, шифру 15 16 7704 Схема 2 "Процес прийняття змін у поточних документах, які мають бути затвердженими в ЕІСУК" Сторона приймає пріоритет на зміну інформації Змінює поточну інформацію та пропонує її затвердження Сторона-ініціатор зміни ставить у чергу завантаження; супровідним повідомленням коментує внесені зміни Інші сторони розглядають пропозицію сторони-ініціатора зміни, коментують пропоновані виправлення (поправки), приймають \ не приймають внесені зміни Приймається зміна усіма сторонами контракту Див. Схема 3 "Процес підтвердження в ЕІСУК" Не приймається зміна однією або декількома сторонами Коментування та кінцеве усунення поточних змінених даних з черги завантаження 17 7704 18 Схема 3 "Процес підтвердження в ЕІСУК" Системою генерується деяке значення, яке характеризує підтвердження Сторони, які приймають участь в укладенні договору, у випадку згоди, шифрують це значення секретним ключем Передають це шифроване значення до системи Система дешифрує шифроване значення відповідним ключем Порівняння вихідних дешифрованих даних Приймання рішення Не приймання рішення 19 20 7704 Схема 4 "Процес затвердження і підписання даних в ЕІСУК' У системі встановлюється остаточна заборона на зміну даних угоди Сторони, які приймають участь в укладенні договору, у випадку згоди, шифрують дані угоди секретним ключем Передають це шифроване значення до системи Дешифрування системою відповідним ключем Порівняння вихідних дешифрованих даних Приймання рішення Не приймання рішення Системою генерується архів шифрованої інформації даних угоди секретними ключами учасників Архів шифрується секретним ключем ЕІСУК і Система генерує і передає ідентифікатор доступу до угоди 7704 21 22 Схема 5 "Процес лонгування договорів в ЕІСУК' Системою генерується значення лонгування контракту t > Сторони, які приймали участь в затвердженні договору, шифрують значення лонгування секретним ключем І > Передають шифроване значення лонгування до системи )f Дешифрування системою відповідним ключем f Порівняння вихідних дешифрованих даних > Приймання рішення про лонгування І Не приймання рішення про лонгування J 23 24 7704 Схема 5а "Процес лонгування договорів в ЕЇСУК з попередньою зміною' Процес за схемою 2 "Процес прийняття змін у поточних документах, яки мають бути затвердженими в ЕІСУК" і Процес за схемою 3 "Процес підтвердження в ЕІСУК" { Системою генерується значення лонгування контракту ( Сторони, які приймали участь в затвердженні договору, шифрують значення лонгування секретним ключем f > Передають шифроване значення лонгування до системи f > Дешифрування системою відповідним ключем І Порівняння вихідних дешифрованих даних і > Приймання рішення про лонгування Комп'ютерна верстка Д. Дорошенко \І Не приймання рішення про лонгування Підписне Тираж 28 прим Міністерство освіти і науки України Державний департамент інтелектуальної власності, вул Урицького, 45, м Київ, МСП, 03680, Україна ДП "Український інститут промислової власності", вул Глазунова, 1, м. Київ - 4 2 , 01601