Как стать автором патента на изобретение и получить его за 2,5 месяца

История про совместную работу разработчика и патентного поверенного

Привет, Хабр! Меня зовут Михаил, я руководитель отдела внутренних технических проектов в ГК InfoWatch. 26 апреля прошёл международный день интеллектуальной собственности, так что расскажу вам одну историю по теме. Недавно я принял участие в новом для меня проекте, связанном с патентованием технологии «Система и способ контролируемого доступа к веб-ресурсу», которую я разработал. Опыт оказался интересным, мы получили патент всего за 2,5 месяца вместо стандартных от 6 месяцев до 1,5 лет, поэтому захотелось рассказать о том, какой путь проходит технология от её изобретения до защиты. А именно:

• Зачем вообще защищать инновационные разработки

• Какие задачи можно решить путем этой защиты

• Особенности совместной работы разработчика и патентного поверенного

• Чем для меня оказался полезен этот новый опыт

• И многое другое на примере нашего случая

Впрочем, обо всём по порядку.

Начну с того, что в InfoWatch процесс патентования инновационных технологий отлажен. Мы технологическая компания, а значит наша задача защищать свои разработки, чтобы они становились защищенным активом. На данный момент у нас 29 патентов на способы защиты и анализа данных в России и за рубежом. 

В моем случае я был единственным разработчиком технологии, а за юридическую сторону дела отвечала наш патентный поверенный, Екатерина Антонова, которая, кстати, также помогала мне с подготовкой этой статьи.

Путь технологии. От идеи к защите

Каждая технология начинается с её идеи. Любая идея, просто оформленная в тексте (хоть в каком-то виде), уже становится объектом авторского права. Просто по умолчанию. И де-факто любая фиксация идеи в письменном виде — это первая ступень защиты, так как в дело вступает авторское право. 

Но важно, чтобы об этом авторском праве знали не только вы (разработчик и юрист конкретной компании), но и в целом мир снаружи. И здесь на помощь приходит процесс, который называется депонированием. Это слово не просто так похоже на «депозит» — оно тоже про размещение, просто не вклада, а зафиксированной на бумаге сути технологии. Если проще, получается, что перед более глубоким процессом патентования архитектуры, мы защищаем первый пласт — сущность технологии, описанной пока техническим, а не патентным языком, то есть фиксируем концептуально за собой технологию в виде так называемой альфа-версии, и подаём этот документ в Российский центр оборота прав на результаты творческой деятельности. Это современная система на блокчейне, которая работает вот так:

• Сотрудник (обычно менеджер продукта) готовит описание идеи.

• Описание подаётся в систему.

• Центр фиксирует дату подачи и автора.

• Это не полноценная государственная регистрация, а надёжная фиксация доказательства авторства и приоритета.

Депонирование для нас очень важно, оно позволяет фиксировать факт создания технологии на уровне государственной организации еще до полноценного патентования. И это недорого — 1 500 рублей в год. Система работает на блокчейне и связана с государственными органами, поэтому доказательство легко использовать в суде — суд просто запрашивает нужные данные и тут же их получает. Если вы хотели узнать о каком-то практическом использовании блокчейна в стране — вот вам пример.

Это промежуточный этап, который предваряет патентование (куда более долгий и сложный процесс, нежели депонирование). После коммерческого релиза в плане защиты технология переходит на следующий уровень — патентование изобретения. Это долго. Один патент может готовиться целый год, при этом требуется активное участие разработчиков и патентного поверенного.

Перед подачей заявки обязательно проводится патентное исследование — глубокий поиск аналогов по всем мировым базам данных (Espacenet, Patentscope, поисковая система ФИПС и многие другие).

При подаче заявки на изобретение готовятся несколько ключевых документов:

• Описание изобретения — самый объёмный и трудоемкий документ (обычно от 15 до 100 страниц). В нём подробно описывается суть изобретения и его реализация.

• Формула изобретения — самый важный документ. Именно она и определяет объём правовой охраны. Всё, что в ней написано = то, что компания реально защищает.

• Реферат — краткое (одна страница) описание технологии.

• Чертежи — для наглядности реализации изобретения.

Какие задачи решает защита инновационных разработок 

Инновационные. Суть патента — государственное подтверждение инновационного уровня. Это снимает задачу доказывать и обосновывать свою технологичность партнерам и клиентам.

Юридические. Наличие патента, как подтверждения обладания исключительными правами, дает возможность быстрого подтверждения (без сбора дополнительных доказательств) своих прав в суде при использовании изобретения без разрешения правообладателя. 

Коммерческие. Наличие регистрационных документов, свидетельствующих о правообладании технологией, позволяет быстро подтвердить свои права в процедуре различных закупок и тендеров. 

Имиджевые. Укрепляется имидж компании как технологической, которая не только развивается в плане инновационных разработок, но и трепетно к ним относится. 

Готовим описание изобретения

Я раньше считал, что самое сложное в патентовании – это бюрократические процедуры, связанные с оформлением документов. Как оказалось, сейчас документы оформляются легко и достаточно быстро подаются в электронном виде в Роспатент. Основная трудность возникает именно в сутевой части, а именно в описании изобретения и составлении формулы. 

Выше я уже отметил, что описание — это самый объёмный, трудоемкий и сложный документ. Изобретение может быть сколько угодно передовым и инновационным, но если оно описано некачественно, «тема не раскрыта», не приведены адекватные и понятные примеры, то заявка может «завязнуть» на экспертизе в Роспатенте, а в результате можно получить отказ от выдачи патента. 

Для подготовки описания очень важен слаженный симбиоз работы патентного поверенного и разработчика. Разработчик описывает главные признаки технологии, технический результат, пример осуществления технологии. А патентный поверенный должен перевести все это с технарского языка на патентно-юридический язык, на котором будет описываться технология. И ускорить процесс патентования можно только за счет налаживания контакта между командой разработки и патентными поверенными. 

А теперь опишу всё по шагам на нашем примере.

Как возникла идея технологии

В текущих ИБ-условиях компании частенько оказываются на развилке — обеспечить высокий уровень безопасности доступа к внутренним веб-ресурсам или сохранить приемлемую скорость работы пользователей.

Да, есть решения на базе nginx, Apache и других обратных прокси, но у них много недостатков — в основном они используют статику на основе URL-пути или множества DNS-имён (IP-адресов). Кроме того, для правильной работы публикуемого ресурса часто требовалось вмешательство в его конфигурацию, что было не то чтобы желательно. Запросы на доступ были недостаточно защищены от подделки со стороны пользователя, а весь процесс проверок доступа занимал слишком много времени.

В общем, так возникла задача — создать систему и способ доступа к веб-ресурсу, которые позволяли бы:

• осуществлять строгий контроль доступа для определённых пользователей;

• надёжно защищать запросы от подделки;

• не снижать, а даже увеличивать скорость доступа, несмотря на наличие дополнительных проверок.

Что было сложного при разработке

Решение — это клиент-серверное приложение, в основе которого лежит собственный реверс-прокси портал с поддержкой веб-сокетов. Для клиентской части был разработан веб-плагин на WebRequest API и DeclarativeNetRequest API в рамках Manifest V3.

Основная техническая сложность заключалась в следующем: браузер должен был в разных вкладках загружать разные веб-ресурсы, при этом внешне обращаясь к одному и тому же DNS-имени и базовому URL-пути. Так как браузер активно использует кеширование, то он пытается переиспользовать данные, поэтому динамическое переопределение загрузки контента требовало нескольких итераций поиска оптимального решения.

В итоге плагин научился выполнять несколько весьма важных функций:

• отслеживать клиентские запросы в сторону реверс-портала;

• уточнять статусы готовности удалённых веб-ресурсов;

• осуществлять конечное согласование подключения;

• автоматически создавать и настраивать новую вкладку браузера;

• создавать динамические правила и маркировать все запросы из новой вкладки специальными клиентскими заголовками (ID-вкладки браузера и затребованного номера маршрута).

Идентификатор вкладки создаётся лишь в момент открытия новой вкладки и заранее неизвестен ни самому пользователю, ни реверс-порталу. Эти идентификаторы фиксируются как на стороне клиента в окружении веб-плагина, так и на стороне реверс-портала, причем хранятся до закрытия либо конкретной вкладки, либо всего браузера. Так мы обеспечиваем надёжную защиту запросов от подделки требуемого маршрута.

А реверс-портал анализирует входящие запросы, ищет специальные клиентские заголовки и осуществляет обратное проксирование к необходимому веб-ресурсу на основе значения маршрута и установленных политик доступа.

Что на стороне пользователя

Доступ для клиента реализован как веб-сервис с поддержкой веб-сокетов. Пользователь сначала проходит авторизацию, а затем получает список разрешённых маршрутов (веб-ресурсов) согласно политикам доступа. Пользователь единожды устанавливает веб-плагин из общедоступного хранилища расширений.

Затем плагин настраивается на работу с конкретным реверс-порталом и работает с ним в тесной связке. Пользователь выбирает нужный маршрут из списка и отправляет запрос, а реверс-портал проверяет легитимность этого маршрута и доступность ресурса. Веб-плагин играет ключевую роль в этом процессе: он перехватывает запросы, формирует динамические правила и обеспечивает правильную загрузку контента в новой вкладке браузера.

Идея патентования

Возникла она благодаря хорошо налаженной системе распространения информации внутри компании. Год назад (на момент начала разработки технологии) наш отдел упомянул о нескольких своих разработках в корпоративной газете, а юридический департамент регулярно отслеживает такую информацию. Со мной связались юристы, организовали совещание, после чего сразу несколько технологий задепонировали как научные произведения. Мою технологию решили изучить глубже, ибо в ней наблюдался высокий изобретательский уровень.

Затем провели патентный поиск аналогов на рынке и (внезапно) ничего близкого не нашли. Поэтому начали активно готовить все необходимое для патентования.

Как мы готовили документы для патентования

Подготовка исходных данных для патента сильно отличается от привычных разработчику процессов (исследование — требования — разработка — тестирование). Здесь главная задача именно в формировании правильно структурированного с точки зрения логики документа, который раскрывает сущность изобретения, но при этом не раскрывает коммерческое содержимое. Да, вот такая развилка.

Патентный поверенный провела со мной несколько сложных технических интервью и полностью разобралась в структуре проекта, подготовила первоначальный документ и сама создала все блок-схемы взаимодействия компонентов. Я же принимал самое активное участие: обсуждения проходили примерно раз в неделю по несколько часов. 

Сложнее всего было описывать так называемый пример реализации, а именно — собственную реализация на golang реверс-прокси с контролем вебсокетов. В процессе создания описания мы разобрались в возможности применения конфигураций без перезапуска самого приложения, контроля сетевых соединений с автоматическим разрывом, например, когда учетная запись пользователя портала выключается администратором.

К слову, очень советую коллегам-разработчикам проходить процедуру написания примера реализации технологии вместе с патентным поверенным, так как в процессе происходит самопроверка созданного решения, что может в итоге положительно повлиять на его качество. 

Роль автора и патентного поверенного в подготовке документов

Хотя описание и формула изобретения должны быть составлены по правилам Роспатента и этим занимается патентный поверенный, без активного участия автора (читай — разработчика) написать качественный документ невозможно.

На авторе лежит ключевая задача:

• подробно пояснить технологию патентному поверенному;

• помочь выявить технический результат;

• чётко сформулировать техническую проблему, которую решает изобретение.

Обсуждали мы это примерно раз в неделю по несколько часов, плюс я параллельно анализировал всё написанное Екатериной. В итоге описание изобретения составило более 30 страниц.

Что ещё важно — пример реализации изобретения пишется полностью разработчиком, это необходимо как для проведения патентного поиска, так и для формирования полноценной заявки на изобретение.

Как сделать так, чтобы разработчик был активным участником процесса патентования своей технологии? Для этого мы проводим регулярные вебинары и рассказываем команде разработки про все нюансы. Конечно, в ходе такого обучения приходится затрагивать и чисто патентные аспекты: техническая проблема, технический результат, назначение изобретения, существенные признаки технического решения. Однако, именно такой порядок обучения позволяет поднять уровень знаний наших технических специалистов в этом вопросе. Более того, мы обучаем разработчиков начальному уровню патентного поиска и анализу в целом заявок и патентов. То есть ведем активную работу. 

Что в итоге

Уникальность нашего кейса заключается в сроках: получение патента через 2,5 после подачи заявки в Роспатент. Для российского рынка это исключительно быстрый результат — доказательство, что при правильной организации процесса можно успешно защитить сложную технологию.

Главное — тесное взаимодействие, глубокое понимание технической сути изобретения и внимательное отношение к каждому этапу подготовки документов.

Какую пользу я для себя извлек 

Лично для меня такая работа в связке с патентным поверенным оказалась полезной сразу с нескольких сторон.

Во-первых, было много познавательного ресерча: как на стороне серверной части (бэка), так и на cтороне фронта — именно с точки зрения применения API нового манифеста V3 для создания плагина для браузера. В итоге хорошо разобрались в структуре работы и написания расширений, порядке обработки клиентских запросов и ответов, возможных ограничениях самого API, под которые приходится реально подстраиваться, чтобы реализовать необходимый функционал.

Во-вторых, с точки зрения патентования — это вообще отдельный мир тонкостей. Тут особенно важна логика построения документации, начиная с уровня техники и заканчивая раскрытием сущности изобретения, где важно избегать двояких смыслов. Другими словами, нужно суметь программную реализацию (как в нашем случае) так описать технически простым языком, чтобы эксперту было совершенно понятно, какие технологии применяются, в какой последовательности и с какой целью.

В общем, для общего развития разработчика — очень рекомендую.