Патентування програмного забезпечення (ПЗ) — тема, яку активно вже обговорюють понад 40 років. Завдяки численним судовим рішенням та розвитку законодавства сьогодні є певна визначеність, що дає змогу ІТ-винахідникам успішно патентувати розроблене ПЗ.
 |
Маєте Телеграм? Два кліки - і ви не пропустите жодної важливої юридичної новини. Нічого зайвого, лише #самасуть. З турботою про ваш час! |
Проаналізуємо, як ці питання врегульовані у двох ключових для українських розробників юрисдикціях — ЄС та США.
Європейський Союз
Дисклеймер: у цьому розділі йдеться про підходи Європейського патентного офісу (ЄПО) до експертизи заявок на винаходи. Важливо зауважити, що кожна країна — член ЄС може адаптувати свої національні підходи до визнання певних рішень як патентоздатних, тому деякі аспекти можуть змінюватися залежно від конкретної країни ЄС.
Фактор №1. Технічне завдання як ключ до патентування ПЗ
На рівні ст.ст. 52(2), 52(3) Європейської патентної конвенції (ЄПК) зазначено, що програми для комп’ютерів як такі не вважаються винаходами. Логічний акцент у цьому випадку падає саме на «як такі», що виключає патентування ПЗ, яке не вирішує конкретне технічне завдання (або низку завдань).
Те, що до патентування допускається виключно ПЗ, яке вирішує технічні завдання, підкреслюється, зокрема, у ст. 42(1) ЄПК, що зобов’язує заявників вказувати в описі винаходу: 1) галузь техніки (technical field), до якої належить винахід, а також 2) технічну проблему та її запропоноване розв’язання (technical problem and its solution).
Заборона патентування ПЗ як такого зумовлена бажанням уникнути випадків, коли патенти, замість унікальних технічних рішень, монополізують права на цілі пласти математичних методів (хоч і викладених мовою програмування). Інакше кажучи, патенти були б настільки широкими та розмитими, що наразили б усіх розробників ПЗ на дамоклів меч патентних позовів (а також на ризик патентного тролінгу) та зробили б будь-які інновації в ІТ-сфері в рази більш ризикованими та складними.
Наприклад, програмний код для прогнозування поведінки ринку цінних паперів, заявлений як такий (тобто що розв’язує важливе для споживача бізнес-завдання, але не має впливу на наявний рівень техніки), не вважатиметься патентоздатним насамперед тому, що не матиме технічної проблеми, яку він призначений розв’язувати.
Фактор №2. Технічне середовище як обов’язкова умова патентування ПЗ
Правило 43(1) ЄПК зобов’язує заявників складати формулу винаходу так, щоб об’єкт був визначений у «термінах технічних ознак» (technical features of the invention). Іншими словами, під час патентування програмного забезпечення необхідно розкрити, як саме воно досягає технічного ефекту — наприклад, через взаємодію з апаратурою, що окремо описується у формулі, або під час виконання на будь-якому комп’ютері без необхідності уточнення його специфікації.
Характерним тут є термін, що використовується в Рекомендаціях з експертизи патентних заявок Європейського патентного офісу (Рекомендації) щодо винаходів, які містять ПЗ, а саме «винаходи, реалізовані за допомогою комп’ютера» (computerimplemented inventions). Така назва підкреслює, що ПЗ виконує поставлене завдання, використовуючи певний технічний носій (який може бути окремо описаний в одному з пунктів формули винаходу).
У розд. 3.9 Рекомендацій наведено перелік таких носіїв, а саме: 1) комп’ютери, 2) комп’ютерні мережі, 3) інші програмовані пристрої. Окрім того, на рівні розділу (п. 3.9.3) прямо передбачена можливість заявляти у формулі винаходу таке ПЗ, що оперує одразу вдекількох середовищах, наприклад, на персональному комп’ютері та в хмарі.
Зазначений підхід дає змогу поєднувати в одній формулі пункти, що стосуються принципово різних середовищ (які об’єднані для реалізації певного програмного алгоритму), та є особливо актуальним в умовах розвитку штучного інтелекту, який часто поєднує хмарні обчислення з виконанням на локальному обладнанні.
Фактор №3. Як оцінюється винахідницький рівень програмного забезпечення?
Переконавшись, що ПЗ виконує технічну функцію, заявку (що включає ПЗ) буде оцінено на предмет наявності:
1) новизни (відсутності аналогічних рішень у рівні техніки);
2) винахідницького рівня (інновацій, які ПЗ привносить до наявного рівня техніки, що не є очевидними для фахівця в цій галузі);
3) промислової придатності (здатності ПЗ до практичного використання в промислових/ комерційних цілях).
У контексті програмних винаходів логічний акцент падає саме на винахідницький рівень, оскільки оцінці підлягають лише технічні ознаки ПЗ (наприклад, ПЗ, що безпосередньо взаємодіє з апаратними засобами, такими як сервоприводи, жорсткі диски чи виробничі системи), тоді як нетехнічні ознаки (наприклад, ПЗ для бізнес-планування чи оптимізації кадрів усфері технологій, естетичні аспекти), що не мають технічного ефекту, не враховуються під час оцінки винахідницького рівня. Цей підхід був закріплений рішенням Європейського патентного офісу всправі T641/00 (Comvik) від 26 вересня 2002 року.
Такий підхід фактично унеможливлює патентування комп’ютерних ігор, більшості SaaS-моделей, програм для бухгалтерії та дизайнерської роботи, оскільки більшість із них не передбачає технічної взаємодії з апаратним забезпеченням і спрямована на задоволення нетехнічних потреб споживачів.
Цей підхід виглядає доволі обмежуючим, але, з іншого боку, ПЗ, яке досягає технічних результатів через взаємодію з апаратними засобами (і водночас є неочевидним рішенням), має великі шанси пройти експертизу. Перелік такого ПЗ є досить різноманітним, зокрема: ШІ-моделі, системи кібербезпеки, програми для обробки даних, математичні моделі для вирішення практичних задач, системи управління базами даних та багато іншого.
Фактор №4. Єдиний патентний суд
Окремої згадки в контексті програмних винаходів у ЄС заслуговують унітарний патент і Єдиний патентний суд (UPC), що запрацювали із червня 2023 року. Тепер заявники програмних винаходів (зокрема і з України), які отримали європейський патент, можуть подати запит на надання йому унітарного ефекту. Ключова перевага унітарного патенту — автоматичне надання охорони одразу в багатьох країнах — учасницях системи UPC (станом на квітень 2025 року— 17 країн ЄС) замість необхідності національної валідації (як у європейському патенті).
Водночас спори щодо унітарних патентів (а також класичних європейських патентів, якщо не застосовано процедуру opt-out) розглядає саме UPC, що надає як перевагу централізованого захисту, так і симетричний ризик централізованого анулювання патенту для всіх цих країн одним рішенням.
Сполучені Штати Америки
Вихідною точкою (та першою перепоною) для розробників, які прагнуть отримати патентну охорону програмного забезпечення в США, є необхідність довести, що їхнє рішення не є простою «абстрактною ідеєю». Логіка тут перегукується з європейською— чим менш прикладне застосування має ідея, тим більший шанс небезпечної монополізації широких пластів абстрактних знань (математичних, економічних та інших).
Заборона на патентування абстрактних ідей у США ґрунтується не на законі, а на судовій практиці, насамперед на рішеннях у справах Mayo Collaborative Services v. Prometheus Laboratories, Inc. (2012) та Alice Corp. v. CLS Bank International (2014). Саме вони сформували так званий фреймворк Alice/ Mayo — алгоритм, який використовується для експертизи заявок на винаходи, зокрема у сфері програмних винаходів.
Фреймворк Alice/Mayo застосовується в Керівництві для експертів Патентного офісу США (Manual of Patent Examining Procedure, Керівництво) та формує такий алгоритм:
Крок №1. Чи зводиться ПЗ до абстрактної ідеї?
На рівні судової практики США сформульовано загальний підхід — чим більше ідея реалізує конкретне технічне рішення через взаємодію з апаратними засобами або покращує їхнє функціонування, тим менш абстрактною вона визнається.
Наприклад, суди США визнавали завідомо неабстрактним ПЗ для покращення роботи комп’ютера, зокрема для оптимізації роботи комп’ютерної бази даних (Enfish, LLC v. Microsoft Corp, 2016), або для полегшення процесу анімації персонажів комп’ютерних ігор (McRO, Inc. v. Bandai Namco Games, 2016).
Найбільш оптимальним для розробників програмного забезпечення є недопущення класифікації їхнього програмного винаходу як абстрактної ідеї вже на кроці №1. Як зазначає USPTO у Керівництві, уникнути такої класифікації допомагає, зокрема, розв’язання конкретної технічної проблеми або обмеження застосування ідеї до конкретних технічних пристроїв чи конфігурацій (§2106.05 Керівництва).
(Так, ПЗ зводиться до абстрактної ідеї)— перехід до кроку №2.
(Ні, ПЗ не зводиться до абстрактної ідеї) — перехід до стадії аналізу відповідності іншим критеріям патентоздатності:
1) новизни (як і в ЄС, винахід не має бути відомим із рівня техніки);
2) неочевидності (американський відповідник винахідницького рівня);
3) корисності (вимога наявності певної практичної користі. Цей критерій у США вважається менш суворим порогом, ніж європейська «промислова придатність»).
Крок № 2. Чи має абстрактна ідея практичне застосування?
Фактично, сьогодні це питання є ключовим у дослідженні патентоздатності ПЗ, оскільки велика кількість програмних винаходів одразу підпадає під визначення абстрактної ідеї на кроці №1.
Так, програмний винахід може вважатися «інтегрованим у практичне застосування», якщо він, наприклад, покращує роботу комп’ютера чи іншої технічної системи, розв’язує конкретну технічну проблему або реалізує інноваційний технічний підхід у межах наявних технологій. Водночас добре відомі, рутинні, конвенційні (well-understood, routine, conventional activity) елементи ПЗ не беруться до уваги.
На практиці це означає, що навіть якщо ідея (наприклад, ПЗ для бухгалтерських обчислень) на перший погляд здається занадто абстрактною, але її реалізація підвищує продуктивність комп’ютера (наприклад, ефективність обробки даних), то ПЗ може визнаватися таким, що інтегрує абстрактну ідею у практичне технологічне застосування.
(Так, має практичне застосування) — перехід до аналізу ПЗ за критеріями патентоздатності.
(Ні, не має практичного застосування) — перехід до кроку №3.
Крок №3. Чи є в ПЗ «щось більше», ніж абстрактна ідея?
Перехід на цей етап у експертизі заявки означає, що експерт встановив факт надмірної абстрактності заявки, яка не інтегрує абстракцію в щось практичне. Фактично, це останній шанс для експерта врятувати заявку на програмний винахід.
Ключовим тут є запитання: «Чи містить програмний винахід додаткові елементи, які роблять його значно більшим (significantly more), ніж проста абстрактна ідея?». Такі додаткові елементи мають накладати значущі обмеження (meaningful limit) на абстрактну ідею для того, щоб уникнути монополізації широких пластів ідей без їхньої інноваційної реалізації в техніці.
Дуже важливо, що на цьому третьому кроці винахідницька концепція може полягати в тому, як саме комбінація 1) технічних і 2) нетехнічних аспектів трансформує абстрактну ідею в патентоздатне рішення (наприклад, інноваційне втілення бізнес-аналітики, яке приводить до покращення роботи комп’ютера чи хмари). Такий підхід є набагато ліберальнішим, ніж підхід Comvik, що застосовується у ЄС (у якому нетехнічні елементи не беруться до предметного розгляду під час визначення винахідницького рівня).
Наприклад, у справі DDR Holdings, LLC v. Hotels. com, L.P., 2014 суд визнав таким, що містить винахідницьку концепцію, технічне рішення для утримання користувача в межах сайту (завдяки створенню гібридної вебсторінки), а в справі Bascom Global Internet Services, Inc. v. AT&T Mobility LLC, 2016 достатньо винахідливим було визнане технічне рішення фільтрації інтернет-контенту через серверні налаштування.
Отже, патентування програмних винаходів у США є більш динамічним і менш передбачуваним, ніж у ЄС. З іншого боку, систему США можна вважати більш гнучкою завдяки фреймворку Alice/Mayo, який надає можливість розробникам демонструвати винахідницьку концепцію з урахуванням як технічних, так і нетехнічних елементів заявки, тоді як у ЄС стандарт Comvik та практика Європейського патентного офісу практично не враховують нетехнічні елементи заявки під час оцінки винахідницького рівня.