Основная задача — до регистрации понять, что действительно принадлежит компании, что
стоит защищать и где скрыты риски.
Мы не предлагаем регистрировать всё
подряд: сначала проверяем продукт, документы и историю разработки, а
затем рекомендуем только то, что усиливает актив и оправдано с точки
зрения риска, целей и бюджета.
Многие воспринимают регистрацию программы как универсальную защиту. На практике это лишь фиксация конкретной версии кода. Авторское право возникает автоматически, а Роспатент не проверяет, кто на самом деле писал этот код и есть ли у компании права на него.
Регистрация не превращает идею в монополию и не останавливает конкурента, который напишет свой код с нуля. Поэтому мы рекомендуем начинать с аудита: проверить цепочку прав, историю создания и только потом решить, какую версию продукта и каким инструментом защищать.
Мы не стремимся продать вам максимум регистраций. Наша задача — определить, какие активы у вас есть на самом деле, кому они принадлежат и какой способ защиты даст реальный результат при разумном бюджете.
Если завтра инвестор, заказчик, суд или бывший разработчик попросит подтвердить права на продукт — сможет ли компания показать не только свидетельство, но и непрерывную доказательственную цепочку?
В реестр вносятся сведения, сообщённые заявителем. Если они неточны, свидетельство не устраняет проблему — оно может сделать противоречие заметнее для контрагента или процессуального оппонента.
Аудит проходит по шести связанным контурам. Каждый заканчивается конкретным выводом, а не общим юридическим комментарием.
Определяем архитектурную границу продукта, самостоятельные модули, репозитории, релиз, commit/hash (техническую метку конкретной версии кода) и коммерчески значимую версию.
Сопоставляем людей, периоды работы, Git-аккаунты, задачи и характер творческого вклада. Отделяем авторов от руководителей, тестировщиков и постановщиков задач.
Проверяем трудовые документы, служебные задания, договоры с подрядчиками, акты, отчуждение, авторский заказ, реорганизации и переходы между компаниями.
Выявляем библиотеки, SDK, API, фреймворки, купленный и перенесённый код, open source, шрифты, иконки и использование AI-инструментов.
Выбираем материалы, достаточные для идентификации версии, но не содержащие ключей, паролей, персональных данных, клиентских секретов и лишнего ноу-хау.
Проверяем, нужны ли отдельно товарный знак, база данных, промышленный образец на интерфейс, режим коммерческой тайны и патентный анализ технического способа.
Программа как текст кода охраняется авторским правом. Но если она реализует новый способ решения технической задачи и даёт объективный технический результат — например, снижает нагрузку, повышает скорость или точность обработки, улучшает безопасность либо управляет устройствами, — может потребоваться патентный скрининг.
Регистрация программы защищает конкретную реализацию. Патент при соблюдении критериев способен охранять технический способ или систему в пределах формулы, даже если конкурент перепишет код на другом языке.
Обсуждаем цели бизнеса, историю продукта, участников разработки, срочность и режим конфиденциальности.
Договоры, акты, трудовые документы, материалы из Git, сведения о компонентах и версиях.
С ответственным юристом и техническим представителем; точечные уточнения с авторами при противоречиях.
Формируем перечень недостающих материалов и зоны, которые нужно закрыть до подачи.
План исправлений и рекомендация по регистрации и другим способам защиты.
Результат аудита — рабочий пакет, который можно использовать для регистрации, переговоров, due diligence (проверки актива перед сделкой), лицензирования и подготовки к спору.
Название, назначение, архитектурная граница, модули, версия, commit/hash, репозитории и владельцы технических доступов.
Кто создавал существенные элементы, когда, в каком статусе и какими материалами подтверждается вклад.
От автора к работодателю, заказчику, приобретателю или текущему правообладателю — с указанием каждого основания перехода.
Компоненты, лицензии, ограничения, обязательные notices (уведомления об авторстве, требуемые лицензией) и рекомендации по корректному использованию.
Красные блокеры, жёлтые исправимые риски, зелёные подтверждённые позиции и серые области, где не хватает информации.
Какой документ или техническое действие требуется, кто отвечает и что подтвердит закрытие риска.
Подавать сейчас, подавать после исправлений либо отказаться от подачи в выбранном виде.
Что регистрировать отдельно, что оставить в режиме ноу-хау и что направить на патентный поиск.
Вы получаете не просто отчет с юридическими выводами,а понятный план действий: что именно защищать, на кого оформить права, какие риски закрыть в первую очередь и какие шаги действительно нужны вашему бизнесу.
В судебных делах регистрация помогала правообладателям тогда, когда работала вместе с договорами, служебными документами, исходным кодом и технической фиксацией.
Глубина проверки зависит от истории разработки продукта и поставленной задачи.
Стоимость и срок фиксируются после короткой вводной встречи и оценки
объёма материалов.
Для бизнеса это может быть очевидно фактически, но юридическая принадлежность проверяется по каждому существенному вкладу. Особенно уязвимы подрядчики, код основателей до создания компании и субподрядчики внешней команды.
Git хорошо подтверждает историю изменений, но сам по себе не отвечает, на каком основании исключительное право перешло компании и законно ли использованы сторонние компоненты.
Оплата не всегда равна отчуждению исключительного права. Значение имеют вид договора, формулировки о правах, идентификация результата, акты и статус исполнителя.
Объём доступа и материалов для депонирования можно минимизировать. Секреты, ключи, персональные данные и наиболее ценное ноу-хау исключаются; порядок передачи материалов фиксируется заранее, при необходимости — по NDA (соглашению о неразглашении) и через защищённый канал.
Итог аудита может быть и отрицательным: не регистрировать отдельный модуль, не выходить в ненужную страну, не патентовать непатентоспособную идею. Мы продаём обоснованное решение, а не количество заявок.
После конфликта автор может стать недоступен или отказаться подписывать документы, а поздно созданные подтверждения будут оцениваться критичнее. Исправления задним числом недопустимы — поэтому лучше закрыть вопрос заранее.
Начнем с вводной встречи на 30–45 минут.
До встречи не нужно передавать
весь исходный код — достаточно общей схемы продукта, перечня участников
разработки и основных договоров.