1) Использование open-source компонентов (ссылка на пятую статью)
2) Рассматриваем описание архитектуры ПО для реестра
3) Рассмотрим так же ()
Раздел про архитектуру в заявке — это тот момент, где экспертиза «заглядывает внутрь» вашего продукта. И именно по нему часто формируется общее впечатление о том, насколько система прозрачна, управляема и соответствует требованиям реестра.
Проблема в том, что разработчики привыкли описывать архитектуру «для своих»: через схемы сервисов, названия технологий, внутренние обозначения модулей. Внутри команды это работает прекрасно, но для эксперта, который видит продукт впервые, такое описание превращается в набор терминов, из которых сложно сделать выводы. А экспертиза в этом разделе ищет вполне конкретные ответы.
Её интересует: где находится ключевая логика системы, какие компоненты входят в состав программного обеспечения, как они взаимодействуют между собой и где происходит обработка и хранение данных. Если это клиент-серверное приложение — где проходит граница между клиентской и серверной частью. Если это SaaS — где расположена инфраструктура и как пользователи получают доступ к системе.
Именно поэтому архитектурное описание должно быть не только технически корректным, но и понятным и читаемым для любого человека вне вашей команды.
Одна из самых частых ошибок — избыточная техническая детализация. Когда в описании появляются названия конкретных библиотек, протоколов, внутренние названия сервисов, которые ничего не говорят эксперту. В итоге основная логика системы теряется, а важные для экспертизы моменты остаются «между строк».
Вторая крайность — слишком общее описание, в котором нет понимания, как система устроена на самом деле. Тогда экспертиза не может сделать вывод о контроле над продуктом, о его самостоятельности и о том, где происходят ключевые процессы.
Хорошее архитектурное описание — это баланс между технической точностью и понятностью. Это текст, который позволяет последовательно проследить путь данных и логики внутри системы: от момента, когда пользователь взаимодействует с интерфейсом, до того, где и как обрабатываются данные, какие модули участвуют в этом процессе и где они размещены.
Особое внимание здесь уделяется внешним зависимостям. Если система использует сторонние сервисы, open-source компоненты или внешние API, это должно быть отражено таким образом, чтобы было понятно, какую роль они играют и не создают ли критической зависимости. Мы подробно говорили об этом в статье про open-source компоненты, и здесь эта тема напрямую проявляется в архитектуре.
Для SaaS-продуктов архитектура становится вообще центральным элементом заявки, потому что именно она показывает, что система находится под контролем правообладателя и соответствует требованиям к размещению и управлению.
Именно по архитектуре экспертиза часто делает вывод о зрелости продукта и качестве подготовки заявки. Когда описание чёткое, логичное и согласованное с другими разделами — это значительно снижает количество вопросов на этапе проверки.
Мы разберём ещё один частый вопрос, который возникает у разработчиков: нужно ли регистрировать программу в Роспатенте перед подачей в реестр и как эти два процесса на самом деле связаны.
Требования к серверной инфраструктуре и размещению данных
В какой-то момент любая команда, которая готовится к включению в реестр, сталкивается с вопросом инфраструктуры. Особенно остро это проявляется у SaaS-продуктов, но на самом деле касается практически всех современных систем. Потому что сегодня программное обеспечение редко существует «в вакууме» — оно всегда связано с серверами, базами данных, облачными платформами и внешними сервисами. И именно здесь начинается зона повышенного внимания со стороны экспертизы.
Реестр российского ПО — это не только про код. Это про управляемость, доступность и контроль над системой. Государство должно быть уверено, что программное обеспечение может функционировать в российских условиях, что оно критически не зависит от зарубежной инфраструктуры и что правообладатель способен управлять этим продуктом.
Поэтому в заявке всегда анализируется: где физически размещены серверы, в какой юрисдикции находятся дата-центры, кто управляет инфраструктурой, где хранятся данные пользователей и каким образом обеспечивается доступ к системе.
Самая распространённая ошибка — формулировка «мы используем облако». С точки зрения экспертизы это ничего не объясняет. Облако — это просто модель. Важно: чьё это облако, где оно расположено, на каких условиях используется и кто имеет доступ к управлению.
Если ключевые элементы инфраструктуры находятся за пределами российской юрисдикции и правообладатель не имеет над ними полного контроля, это может стать серьёзным основанием для вопросов. Особенно если речь идёт о хранении и обработке пользовательских данных.
Это не означает, что использование облачных решений запрещено. На практике множество продуктов успешно включаются в реестр с использованием облачных платформ. Но критично то, чтобы эти решения были размещены в допустимой юрисдикции и находились под контролем правообладателя.
Именно поэтому инфраструктурное описание в заявке должно быть конкретным и прозрачным. Оно должно показывать: где находятся ключевые компоненты системы, как они взаимодействуют, где происходит обработка данных и каким образом обеспечивается доступ пользователей.
Этот раздел напрямую связан с архитектурным описанием, о котором мы говорили ранее. Потому что инфраструктура — это физическое отражение архитектуры. И если между этими разделами есть несоответствия, это сразу вызывает вопросы.
Отдельное внимание уделяется вопросам резервирования, отказоустойчивости и управляемости. Необязательно подробно расписывать технические детали, но важно показать, что система не зависит от одного внешнего провайдера и может стабильно функционировать.
В реальности именно инфраструктурный блок часто становится слабым местом для SaaS-продуктов, которые изначально строились на зарубежных сервисах. Но даже в таких случаях почти всегда есть решения — вопрос в том, как грамотно выстроить архитектуру и описать её в заявке.
И если вы сомневаетесь, соответствует ли ваша инфраструктура требованиям — лучше разобраться с этим до подачи заявки. Потому что этот блок гораздо проще скорректировать на этапе подготовки, чем объяснять уже в процессе экспертизы.
Далее мы перейдём к частному, но очень популярному кейсу — мобильным приложениям и их включению в реестр.
Включение мобильных приложений в реестр
Мобильные приложения — это отдельный пласт продуктов, который вызывает много вопросов у разработчиков. Особенно у тех, кто создаёт экосистемные решения: веб-платформа, серверная часть и мобильное приложение как интерфейс для пользователя.
Возникает логичный вопрос: можно ли включить мобильное приложение в реестр как самостоятельный продукт или оно рассматривается только как часть общей системы?
Правильный ответ — возможны оба варианта. Но всё зависит от того, как устроен продукт и как оформлены права.
Мобильное приложение может быть самостоятельным программным обеспечением, если оно выполняет отдельные функции, имеет собственную логику и может рассматриваться как независимый продукт. В этом случае оно может подаваться в реестр как отдельный объект.
Но чаще всего мобильное приложение — это клиент к серверной системе. Оно выступает интерфейсом, через который пользователь взаимодействует с основной логикой, расположенной на сервере. И в таком случае экспертиза смотрит не только на само приложение, но и на всю систему.
И здесь снова ключевым становится архитектурное описание, которое мы подробно разбирали в одной из предыдущих статей. Нужно показать: где находится основная логика, какие функции выполняет мобильное приложение, какие данные обрабатываются на устройстве пользователя, а какие — на сервере.
Отдельное внимание уделяется правам на приложение. Часто мобильная разработка передаётся на аутсорс или выполняется отдельной командой. И если права на код оформлены некорректно, это может стать проблемой при подаче заявки.
Поэтому при подготовке к включению мобильного приложения в реестр важно проверить два блока: архитектуру и правообладание. Если всё оформлено корректно, мобильные приложения без проблем включаются в реестр — как отдельно, так и в составе комплексных решений.
Следующий логичный вопрос, который возникает у продуктовых команд: как быть с обновлениями и модулями, когда продукт постоянно развивается.
Включение модулей и обновлений в реестр
Любой живой продукт развивается. Появляются новые функции, модули, интеграции, меняется интерфейс, обновляется архитектура. И в какой-то момент команда задаётся вопросом: как всё это соотносится с реестром? Нужно ли каждый раз проходить процедуру заново?
Здесь важно понять базовый принцип: в реестр включается не абстрактный продукт, а конкретное программное обеспечение с определёнными характеристиками, архитектурой и функциональностью.
Когда вы подаёте заявку, вы фиксируете определённую версию продукта, его состав и структуру. И если в дальнейшем изменения носят эволюционный характер: улучшается интерфейс, добавляются небольшие функции, оптимизируется работа — это не требует повторного включения. Но если появляются новые крупные модули, которые существенно расширяют функциональность или фактически создают новый класс программного обеспечения, это уже может потребовать отдельной заявки или внесения изменений.
Проблема в том, что многие компании изначально слишком узко описывают продукт в заявке. Они фиксируют только текущий функционал, не учитывая развитие. И в результате любое расширение начинает выходить за рамки описанного продукта.
Гораздо более грамотный подход — изначально описывать систему как платформу или комплексное решение с модульной архитектурой. Тогда развитие продукта органично вписывается в уже включённое ПО. Это напрямую связано с архитектурным описанием и тем, как вы формулируете назначение и функциональность продукта.
Если вы изначально закладываете в описание возможность масштабирования и развития, вам гораздо проще работать с реестром в дальнейшем.
Именно поэтому мы всегда рассматриваем заявку не как формальность, а как стратегический документ, который должен работать на бизнес в долгосрочной перспективе.
Можно ли включить ПО, разработанное по заказу
Это один из самых тонких и юридически сложных вопросов во всём процессе включения в реестр, потому что он напрямую связан с правами на программное обеспечение.
Очень часто компании разрабатывают продукты под заказ клиентов. Это могут быть корпоративные системы, отраслевые решения, платформы для конкретных организаций. И в какой-то момент разработчик или заказчик задумывается: можно ли включить такой продукт в реестр? Ответ зависит от того, кому принадлежат исключительные права.
Если по договору все права переданы заказчику, именно он становится правообладателем. И именно он имеет право подавать заявку в реестр. Разработчик в этом случае уже не может распоряжаться продуктом как своим активом.
Если же права остаются у разработчика, а заказчику передаётся лицензия на использование, ситуация меняется. Тогда разработчик может выступать заявителем и включать продукт в реестр.
Но на практике часто встречаются смешанные конструкции: частичная передача прав, совместное владение, ограниченные лицензии. И именно здесь возникает наибольшее количество ошибок. Потому что формально продукт может быть разработан российской компанией, но юридически права на него принадлежат другому лицу, в том числе иностранной структуре. И это автоматически делает невозможным включение в реестр.
Именно поэтому перед подачей заявки всегда необходимо проводить аудит договоров и структуры прав. Нужно чётко понимать: кто является правообладателем, какие права переданы и на каких условиях.
Если на этом этапе есть ошибки — их лучше исправить заранее. Потому что после подачи заявки изменить структуру прав гораздо сложнее.