info@intellectprava.ru
+7 (812) 983-45-83

МКТУ и критерий однородности товаров и услуг в российской практике регистрации товарных знаков.

Прикладной анализ для IT-бизнеса с рассмотрением SaaS как частного случая.

1. Введение.

Международная классификация товаров и услуг для регистрации знаков (МКТУ, Ниццкая классификация) является обязательным инструментом формализации перечня товаров и услуг в заявках на товарные знаки, однако сама по себе не решает вопрос об объеме правовой охраны и не определяет однородность товаров и услуг. Российская судебная практика и методические подходы Роспатента исходят из того, что однородность представляет собой самостоятельную оценочную категорию, основанную на вероятности того, что потребитель отнесет товары или услуги к одному источнику происхождения. Это обстоятельство приобретает особую значимость в сфере информационных технологий, где один и тот же коммерческий продукт или комплекс услуг часто сочетает признаки товара, услуги, облачной инфраструктуры, образовательного сервиса, телекоммуникационного решения и консалтинга.
Для научной точности необходимо разграничивать IT-бизнес как широкую категорию предпринимательской деятельности и SaaS-бизнес как одну из его частных моделей. IT-бизнес охватывает, в частности, разработку и лицензирование программного обеспечения, создание аппаратно-программных комплексов, системную интеграцию, техническое сопровождение, телекоммуникационные сервисы, кибербезопасность, обработку данных, цифровое обучение и иные технологические услуги. SaaS, напротив, представляет собой модель предоставления программного обеспечения как услуги, то есть доступ к функционалу программы через сеть без передачи пользователю программного продукта как самостоятельного объекта оборота в традиционном смысле.
Актуальность темы усиливается вступлением в силу 13-й редакции МКТУ с 1 января 2026 года, изменением терминологии в ряде классов, усложнением цифровых бизнес-моделей и повышением значения точного перечня товаров и услуг на фоне новых тарифных подходов к пошлинам за регистрацию товарных знаков. В этих условиях юридическая квалификация смежных классов, прежде всего связки 9, 35, 38, 41 и 42 классов, становится не просто техническим вопросом классификации, а инструментом управления регистрационными, финансовыми и судебными рисками для различных сегментов IT-рынка, включая SaaS как наиболее показательную, но не единственную модель.
Цель настоящей статьи состоит в том, чтобы на основе официальных актов, судебной практики и наиболее содержательных доктринальных материалов раскрыть соотношение МКТУ и критерия однородности, показать пределы использования классов как классификационного инструмента и выработать прикладную модель выбора классов для IT-бизнеса с отдельным рассмотрением SaaS как частного случая.

2. Нормативная и методологическая основа.

2.1 Ниццкая классификация как классификатор, а не критерий конфликта.

Ниццкая классификация учреждена Ниццким соглашением и представляет собой международную систему распределения товаров и услуг по 45 классам для целей регистрации товарных знаков. ВОИС прямо указывает, что классификация служит административным и регистрационным целям, а Роспатент применяет ее в национальном делопроизводстве в актуальной редакции, в том числе в редакции МКТУ 13-2026, вступившей в силу с 1 января 2026 года.
При этом ключевое для темы статьи положение вытекает из статьи 2 Ниццкого соглашения: классификация не влияет на оценку однородности товаров и услуг. Суд по интеллектуальным правам и Верховный Суд Российской Федерации неоднократно воспроизводили этот тезис, подчеркивая, что товары и услуги, отнесенные к разным классам МКТУ, могут быть признаны однородными, а однородность может существовать и между товаром и услугой.
Следовательно, класс МКТУ выполняет функцию начальной систематизации, но не подменяет правовой анализ риска смешения. Для практики регистрации товарных знаков это означает, что подбор классов не может строиться по принципу механического копирования заголовков классов или регистрации «во всех близких классах», а требует оценки фактической модели потребления, коммерческого назначения и логики рынка.

2.2 Критерии однородности в практике Роспатента и судов.

Методологической основой оценки однородности в российской практике остаются подходы, закрепленные в методических рекомендациях Роспатента по определению однородности товаров и услуг и воспроизводимые в судебной практике. Согласно этим подходам, при определении однородности учитываются род и вид товаров, их назначение, вид материала, из которого они изготовлены, условия сбыта, круг потребителей, взаимозаменяемость, взаимодополняемость и другие обстоятельства.
Пункт 162 Постановления Пленума Верховного Суда Российской Федерации № 10, на который постоянно ссылаются аналитические и судебные материалы, исходит из того, что однородность устанавливается через принципиальную возможность возникновения у обычного потребителя представления о принадлежности товаров или услуг одному производителю либо одному коммерческому источнику. Иначе говоря, правовой вопрос ставится не о формальной классификации, а о вероятности ассоциативной связи в восприятии рынка.
Такой подход принципиально важен для цифровой экономики. В IT-сфере потребитель, даже если он корпоративный, нередко воспринимает программный продукт, облачную платформу, услуги внедрения, техническую поддержку и инфраструктурные сервисы как элементы единой технологической экосистемы. Поэтому границы между товаром и услугой, а также между различными сервисными категориями, оказываются более проницаемыми, чем в традиционных секторах производства.

3. МКТУ и однородность - разграничение.

3.1 Почему один класс не означает однородность, а разные классы не означают ее отсутствие.

В российской практике нередко используется упрощенная формула, по которой товары одного класса презюмируются близкими, а товары разных классов — различными. Однако и доктрина, и судебная практика опровергают такое упрощение. Статьи, комментирующие подход СИП, подчеркивают, что принадлежность товаров к разным классам МКТУ не свидетельствует об отсутствии однородности, а принадлежность к одному классу не гарантирует автоматического вывода об однородности для всех позиций внутри класса.
Причина этого заключается в структуре самой классификации. МКТУ решает задачу административного распределения терминов, а не задачу моделирования потребительского поведения и конкурентной взаимосвязанности рынков. Как следствие, внутри одного класса могут находиться разнородные по коммерческому происхождению товары, а в разных классах — товары и услуги, которые потребитель в реальном обороте связывает между собой.
Для IT-сектора это проявляется особенно наглядно. Программное обеспечение как загружаемый цифровой продукт традиционно тяготеет к 9 классу, тогда как разработка программного обеспечения, SaaS, облачные вычисления и техническое консультирование относятся к 42 классу. Однако IT-бизнес не исчерпывается этой парой: телекоммуникационные платформы и сервисы передачи сообщений могут тяготеть к 38 классу, образовательные цифровые платформы — к 41 классу, а управленческий и маркетинговый цифровой консалтинг — к 35 классу. Несмотря на принадлежность к разным классам, эти объекты в глазах потребителя могут иметь единый коммерческий источник, а потому конфликтность между ними оценивается как правдоподобная.

3.2 Однородность как континуум, а не двоичная категория.

Современные юридические обзоры справедливо подчеркивают, что однородность нельзя понимать как жесткое деление на «однородно» и «неоднородно».
Судебная практика исходит из того, что однородность всегда оценивается в совокупности со степенью сходства обозначений: чем выше сходство знаков, тем меньшая степень однородности может оказаться достаточной для вывода о риске смешения, и наоборот.
Такой подход особенно существенен в цифровых и инновационных секторах.
На насыщенном IT-рынке даже умеренно смежные товары и услуги могут оказаться конфликтными, если используются практически идентичные обозначения и направлены на одну и ту же пользовательскую аудиторию. Следовательно, при анализе МКТУ в IT нельзя ограничиваться только номером класса; необходимо соотносить перечень с фактической архитектурой продукта, каналами монетизации и способом восприятия бренда на рынке.

4. Судебная практика: роль МКТУ при оценке однородности.

4.1 Подход Суда по интеллектуальным правам.

Ключевая линия судебной практики состоит в том, что МКТУ сама по себе не определяет однородность товаров и услуг.
В ряде решений и аналитических обзоров СИП подчеркивал, что товары, содержащиеся в разных классах МКТУ, могут считаться однородными, и такая однородность может существовать между товаром и услугой. Это означает, что юрист, оценивающий риски регистрации, обязан выходить за рамки формального номера класса и анализировать товарный или сервисный рынок как экономическое явление.
В материалах, анализирующих рекомендации НКС при СИП, отмечено, что при установлении однородности суд ориентируется на род деятельности, назначение услуги и связь спорных объектов с конкретной сферой оборота. Для IT-бизнеса это означает, что программные продукты, инфраструктурные решения, управленческий цифровой консалтинг, образовательные платформы и телекоммуникационные функции должны оцениваться не абстрактно, а в контексте того, являются ли они воспринимаемыми как части одной технологической экосистемы.

4.2 Значение точных формулировок перечня.

Одна из наиболее важных тенденций судебной практики состоит в том, что результат анализа часто зависит не от названия класса, а от того, как именно сформулирован перечень товаров и услуг. В некоторых обзорах, посвященных алгоритму оценки однородности, обращено внимание на вывод СИП о том, что услуги 35 класса без уточнения ассортимента реализуемых товаров или сферы деятельности не всегда могут считаться однородными конкретным товарам.
Суд подчеркнул, что абстрактные услуги по продаже товаров и рекламе, не связанные с определенным товарным ассортиментом, отличаются по своей природе и назначению от конкретного товара и не обязательно порождают риск смешения.
Этот вывод имеет прямое прикладное значение для IT-компаний. Если заявитель включает в перечень 35 класс в виде предельно широких формулировок вроде «реклама», «управление бизнесом» или «продажа товаров», это не всегда усиливает его правовую позицию; напротив, слишком широкое описание может повысить конфликтность заявки, не дав пропорционального увеличения объема охраны. Более точные формулировки, например связанные с внедрением CRM, автоматизацией продаж, цифровой бизнес-аналитикой, обработкой данных в коммерческих целях или консультациями по использованию программных решений, как правило, лучше отражают реальную модель деятельности и облегчают аргументацию в случае спора.

4.3 Однородность и использование знака.

Доктринальные материалы подчеркивают еще один важный аспект: критерий однородности играет различную роль в спорах о регистрации и в спорах о досрочном прекращении правовой охраны за неиспользование. Для целей регистрации однородность может расширять зону конфликта между знаками, однако для целей сохранения охраны правообладатель должен доказывать использование именно в отношении тех товаров и услуг, для которых знак зарегистрирован, а не просто для однородных им позиций.
Из этого следует важный стратегический вывод: чрезмерное расширение перечня за счет смежных классов, не поддерживаемых реальным использованием, способно создать будущий риск частичного аннулирования знака. Для IT-бизнеса, склонного к регистрации «про запас» в 9, 35, 38, 41 и 42 классах, этот риск особенно велик, поскольку не вся цифровая активность заявителя в действительности монетизируется или используется как самостоятельная услуга.
9 класс МКТУ
13 редакция 2026 года: аппараты и инструменты, оборудование для информационных технологий...
38 класс МКТУ
Услуги, дающие возможность, по меньшей мере, одному лицу установить связь с другим лицом, в частности, услуги вещания и передачи данных.
41 класс МКТУ
Услуги обучения и профессиональной подготовки, целью которых являются увеселение, развлечение и отдых людей, а также услуги по предоставлению публике произведений визуального искусства или литературы в культурных или образовательных целях.
42 класс МКТУ
Класс включает услуги в областях деятельности: химии, физики, программировании, web разработке.

5. Особенности IT-бизнеса в системе МКТУ.

5.1 IT-бизнес как широкая категория технологической деятельности.

В контексте МКТУ IT-бизнес следует понимать как совокупность разнородных, но технологически связанных моделей предпринимательской деятельности. В нее могут входить разработка коробочного и встроенного программного обеспечения, создание мобильных приложений, SaaS, PaaS и облачные сервисы, системная интеграция, кибербезопасность, центры обработки данных, телекоммуникационные платформы, цифровое образование, анализ данных и технологический консалтинг.
С точки зрения классов МКТУ это означает, что у IT-бизнеса нет одного универсального «собственного класса».
Для части компаний доминирующим будет 9 класс как класс программных продуктов;
  • для части — 42 класс как класс технических и программных услуг;
  • для операторов коммуникационных сервисов существенным становится 38 класс;
  • для edtech-платформ с коммерциализированным обучением — 41 класс;
  • для digital-консалтинга и автоматизации бизнес-процессов — 35 класс.
Следовательно, при научном и прикладном анализе необходимо разводить общее понятие IT-бизнеса и его отдельные подвиды. Без этого возникает риск неверного обобщения, при котором SaaS-модель ошибочно принимается за универсальную правовую модель всей индустрии информационных технологий.

5.2 SaaS как частный случай IT-бизнеса.

SaaS представляет собой частную форму эксплуатации программного обеспечения, при которой пользователю предоставляется удаленный доступ к функционалу программы как к сервису. Именно поэтому для SaaS центральным является 42 класс, поскольку в нем сосредоточены формулировки, относящиеся к предоставлению программного обеспечения как услуги, облачным вычислениям и техническому сопровождению.
Однако даже в SaaS-модели не исключается значение 9 класса, если проект предполагает мобильное приложение, десктопный клиент, программный агент, загружаемый модуль, SDK или иной цифровой компонент, который пользователь получает как самостоятельный программный объект. Таким образом, SaaS не устраняет значения 9 класса, а лишь смещает центр тяжести правовой охраны в сторону 42 класса.
В этом и заключается причина, по которой SaaS удобен как аналитический пример, но не должен подменять собой весь IT-бизнес. Там, где речь идет о системной интеграции без собственного программного продукта, о телекоммуникационной платформе, об образовательной IT-среде или о кибербезопасности как сервисе, классовая логика может отличаться от типового SaaS-сценария.

5.2 Несколько типовых моделей IT-бизнеса вне SaaS.

Для полноты картины целесообразно выделить несколько типовых моделей IT-бизнеса, которые не сводятся к SaaS.
Первая модель — коробочное или on-premise программное обеспечение. Здесь ядром нередко выступает 9 класс, поскольку основной объект оборота — программный продукт, передаваемый пользователю для установки и эксплуатации на его стороне. При наличии услуг внедрения, адаптации и сопровождения может подключаться 42 класс.
Вторая модель — системная интеграция и кастомная разработка. В этом случае центральным обычно становится 42 класс как класс разработки программного обеспечения, технического проектирования и технологического консалтинга. Если одновременно поставляются собственные программные модули или программно-аппаратные решения, возрастает значение 9 класса.
Третья модель — телекоммуникационная или коммуникационная цифровая платформа. Здесь, помимо 42 класса для разработки и поддержки, существенным может быть 38 класс, если коммерческая суть сервиса состоит в передаче сообщений, видеосвязи, телефонии, маршрутизации коммуникаций или ином телекоммуникационном функционале.
Четвертая модель — образовательная IT-платформа. Если бренд используется не только для программной среды, но и для коммерциализированного обучения, онлайн-курсов, сертификации или цифровой академии, возникает значимость 41 класса наряду с 42 и, возможно, 9 классом.

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

6. SaaS как частный кейс внутри IT-бизнеса.

6.1 Почему именно SaaS является показательной моделью.

SaaS-модель особенно показательна для исследования однородности, потому что в ней наиболее ярко размывается граница между цифровым товаром и цифровой услугой. Пользователь может взаимодействовать с сервисом через браузер, мобильное приложение или локальный агент, однако экономическая ценность заключается не в приобретении экземпляра программы, а в доступе к функционалу, данным, вычислительным мощностям и обновляемой инфраструктуре поставщика.
Эта модель позволяет наглядно показать, почему механическое понимание классов МКТУ недостаточно. С точки зрения формы взаимодействия продукт может иметь признаки 9 класса, а с точки зрения бизнес-модели — 42 класса; дополнительные сервисы внедрения, обучения и коммуникаций могут тяготеть к 35, 41 и 38 классам соответственно.

6.2 Базовая ось SaaS: 9 и 42 классы.

Для большинства SaaS-проектов именно сочетание 9 и 42 классов образует юридическое ядро регистрации. Если компания распространяет загружаемые компоненты, клиентские приложения, плагины, агенты, SDK или мобильное приложение, необходимость 9 класса представляется очевидной. Если основной бизнес строится на доступе к функционалу через облако, подписке, SaaS, техническом сопровождении и доработке решений, центральным становится 42 класс.
Сложность заключается в том, что один и тот же SaaS-продукт часто одновременно использует обе модели. Пользователь может скачать приложение из магазина приложений, но фактически оплачивать не программу как товар, а доступ к сервисной инфраструктуре и обработке данных на стороне поставщика. Поэтому многие специалисты считают связку 9 и 42 корреспондирующей, то есть такой, в которой риск смешения может распространяться между товарной и сервисной частью цифрового бренда.

6.3 Смежные классы 35, 38 и 41 в SaaS-практике.

После определения ядра 9/42 встает вопрос о смежных классах.
Для части SaaS-продуктов значим 35 класс, если под брендом оказываются услуги по бизнес-консалтингу, автоматизации процессов продаж, маркетинговой аналитике, внедрению CRM или управленческому сопровождению. Однако этот класс является одним из самых рискованных в силу своей абстрактности: широкие формулировки способны сделать заявку более конфликтной, не обеспечив ясной связи с конкретной цифровой функцией продукта.
38 класс приобретает значение в тех случаях, когда суть сервиса связана не просто с использованием интернета, а именно с телекоммуникацией, передачей сообщений, омниканальными коммуникациями, VoIP, видеосвязью или инфраструктурой доставки коммуникаций. Если же SaaS только работает через интернет, это не означает автоматической необходимости 38 класса.
41 класс становится оправданным при наличии самостоятельного образовательного продукта: платных курсов, академии пользователей, сертификации, обучающих платформ или коммерциализированного контента по использованию сервиса. Если обучение ограничивается onboarding-поддержкой и не выступает как отдельная услуга, включение 41 класса нередко оказывается избыточным.

7. Подбор классов для IT-бизнеса с учетом SaaS как частного случая.

  • Юридическая декомпозиция технологической модели:
    Профессиональный подбор классов в IT не может начинаться с поиска по ключевому слову «программа» или «сервис». Сначала требуется юридическая декомпозиция бизнес-модели: что именно продается, каким способом поставляется, какие компоненты скачиваются, какие предоставляются как облачная услуга, какие блоки монетизируются отдельно и что планируется в ближайшие 2–3 года.
    Для IT-проекта в целом целесообразно выделять как минимум следующие блоки: программный компонент как цифровой товар; сервисный компонент как доступ к функционалу; техническая разработка и сопровождение; управленческий или отраслевой консалтинг; обучение пользователей; коммуникационная инфраструктура, если она составляет самостоятельную ценность продукта. Для SaaS-модели к этим блокам добавляется обязательный вопрос о соотношении загружаемого интерфейса и удаленно предоставляемой функциональности.
  • Определение ядра перечня:
    После декомпозиции формируется ядро классов. Для значительной части IT-проектов ядром становится либо 9, либо 42 класс, либо их сочетание; для SaaS-проектов в большинстве случаев центральным оказывается 42 класс, а при наличии скачиваемых компонентов — 9 и 42 вместе.
    Этот выбор должен основываться не на «модности» класса, а на реальном механизме потребления: если ценность для клиента состоит в использовании функционала через облако, защита только по 9 классу будет недостаточной; если существует самостоятельное мобильное приложение, защита только по 42 классу также может оказаться неполной.
    При этом формулировки внутри класса должны быть максимально точными и одновременно достаточно широкими, чтобы не дробить перечень на десятки частных позиций. Так, в 42 классе предпочтительнее опираться на устойчивые формулы вроде «предоставление программного обеспечения как услуги [SaaS]», «разработка программного обеспечения», «техническое консультирование в области программного обеспечения», а в 9 классе — на «программное обеспечение», «мобильные приложения», «загружаемые компьютерные программы» в той мере, в какой они соответствуют реальному использованию.
  • Оценка смежных классов через риск смешения:
    Следующий этап состоит не в автоматическом добавлении 35, 38 и 41 классов, а в оценке вопроса, может ли потребитель связать соответствующие услуги с тем же коммерческим источником, что и ядро продукта.
    В этом месте как раз и работает критерий однородности в полном объеме: назначение, каналы сбыта, круг потребителей, функциональная взаимосвязь и коммерческая логика рынка.
    Если IT-компания осуществляет кастомную разработку и бизнес-консалтинг по цифровой трансформации, 35 класс может быть оправдан наряду с 42.
    Если сервис включает собственную систему коммуникаций, встроенную телефонию или сервис обмена сообщениями как самостоятельную функцию, оправдан анализ 38 класса.
    Если под брендом разворачивается корпоративная академия или лицензируемая обучающая среда, возникает разумное основание для 41 класса.
    В SaaS-сегменте эти же выводы действуют как частный случай, но не должны автоматически переноситься на все IT-модели без анализа фактической деятельности.
  • Проверка на конфликтность и риск неиспользования:
    После определения перечня необходимо провести его проверку на два встречных риска: риск отказа по п. 6 ст. 1483 ГК РФ в связи с более ранними сходными обозначениями и риск будущего частичного прекращения охраны за неиспользование. Именно этот двойной фильтр позволяет сбалансировать консервативный и экономный подходы к регистрации.
    Консервативная стратегия ориентирована на максимально широкий охват смежных классов, чтобы не оставить окна для конкурентов.
    Экономная стратегия ограничивает регистрацию ядром и несколькими реально используемыми смежными услугами, снижая стоимость процедуры и уязвимость к спорам о неиспользовании.
    Обоснованным представляется промежуточный подход: регистрация должна охватывать только те классы и позиции, которые соответствуют текущей модели бизнеса или обоснованно прогнозируемому развитию в разумной перспективе.

8. Влияние редакции МКТУ 13-2026 и тарифных изменений на IT-стратегию.

8.1 Что изменила редакция 13-2026.

Роспатент сообщил, что с 1 января 2026 года вступила в силу 13-я редакция МКТУ, в которой были уточнены и перераспределены термины, в том числе между 9, 10 и 12 классами, а также изменены и удалены отдельные позиции.
Практические обзоры новой редакции отмечают, что обновление классификации отражает развитие технологий и экономики, а для IT-сферы особенно важно появление и уточнение терминов, связанных с цифровыми сервисами и новыми форматами программных услуг.

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

8.2 Тарифные изменения и оптимизация перечня.

Практические обзоры 2025–2026 годов подчеркивают, что дополнительные пошлины теперь чувствительны не только к количеству классов, но и к количеству наименований товаров и услуг внутри класса сверх базового порога.
Для IT-бизнеса, где существует соблазн включить широкий набор цифровых, консультационных, коммуникационных и образовательных формулировок, это означает, что каждая избыточная позиция увеличивает не только конфликтность, но и стоимость регистрации.

В этих условиях особое значение приобретает работа с обобщающими и юридически устойчивыми формулировками. Цель состоит не в максимальном перечислении частных функций продукта, а в построении такого перечня, который адекватно охватывает модель бизнеса, но не распадается на десятки дублирующих терминов. Для SaaS-платформы такой подход особенно рационален, но он применим и к другим IT-моделям: несколько сильных формулировок в 42 классе и, при необходимости, ограниченный набор позиций в 9, 38, 41 или 35 классе нередко обеспечивают лучшую правовую и экономическую эффективность, чем широкая регистрация «на все цифровое».

Параметры заявки на товарный знак

Укажите количество классов МКТУ и число наименований товаров или услуг в каждом классе.

Для подачи и формальной экспертизы доплата считается со 2-го класса.
Доплата 500 ₽ считается отдельно по каждому классу.
Если в классе 10 позиций или меньше, доплата не начисляется.
Электронное свидетельство уже входит в пошлину за регистрацию.
Итоговая сумма пошлин
35 000 ₽
1 класс, максимум 10 позиций в классе, без бумажного свидетельства.

Детализация

Формула расчёта

Подача и формальная экспертиза = 4 000 ₽ + 1 000 ₽ × (классы − 1, если классов больше 1)
Экспертиза по существу = 13 000 ₽ + 2 500 ₽ × (классы − 1, если классов больше 1) + 500 ₽ × сумма всех позиций сверх 10 по каждому классу
Регистрация = 18 000 ₽ + 2 000 ₽ × (классы − 5, если классов больше 5)
Бумажное свидетельство = 3 000 ₽ по желанию заявителя

Примеры стандартных расчётов

Сценарий Подача + формальная Экспертиза Регистрация Итог

9. Выводы.

Первое, МКТУ должна рассматриваться как административно-классификационный инструмент, а не как самостоятельный критерий правового конфликта между обозначениями. Российская судебная практика последовательно исходит из того, что вопрос однородности решается независимо от формального номера класса, исходя из восприятия среднего потребителя и совокупности экономико-функциональных признаков товара или услуги.
Второе, для IT-бизнеса традиционные границы между товаром и услугой объективно размыты, однако степень этой размытости различна в зависимости от конкретной технологической модели. SaaS является частным, хотя и очень показательным, случаем такого размывания: программный продукт может существовать одновременно как загружаемый объект 9 класса и как сервисное решение 42 класса, а вокруг него могут формироваться корреспондирующие функции 35, 38 и 41 классов.
Третье, современная доктрина и практика подтверждают, что наиболее уязвимыми являются две крайности: регистрация только в одном «очевидном» классе и регистрация чрезмерно широкого перечня смежных классов без опоры на реальное использование. Первая стратегия создает окна для конкурентов, вторая повышает риск отказа, удорожает процедуру и увеличивает вероятность частичного прекращения охраны за неиспользование.
Четверное, с учетом МКТУ 13-2026 и новых тарифных параметров, оптимальной научно и practically ориентированной стратегией для IT-компаний следует признать модель «ядро + обоснованные смежные классы»: 42 класс как основа для программных и технических услуг, 9 класс при наличии загружаемых компонентов, а 35, 38 и 41 классы — только при доказуемой самостоятельной коммерческой функции соответствующих блоков продукта. Для SaaS-сегмента эта модель конкретизируется в виде приоритетной связки 42 и, при необходимости, 9 класса.
Проблематика МКТУ в российском праве давно вышла за пределы технического вопроса о выборе номера класса. На современном этапе она представляет собой сложный институт, в котором пересекаются нормы международной классификации, административная практика Роспатента, судебные стандарты оценки однородности и экономические интересы правообладателей. В цифровой экономике это проявляется особенно отчетливо, поскольку IT-бизнес включает множество различных технологических моделей, а SaaS является лишь одной из них, хотя и особенно наглядной для анализа границы между товаром и услугой.
Научно обоснованный подход к выбору классов для IT-бизнеса должен строиться на четырех принципах: независимость анализа однородности от формального номера класса; приоритет восприятия потребителя и рыночной функции; точность и экономичность формулировок перечня; корреляция между заявляемым объемом охраны и реальным либо планируемым использованием знака. Только при соблюдении этих условий МКТУ выполняет свою надлежащую роль — не как механический перечень рубрик, а как инструмент правовой архитектуры товарного знака в меняющейся цифровой среде.

Услуги патентного бюро:

Регистрация товарного знака в Роспатенте.
Услуги по регистрации товарных знаков, бренда в России юридическими лицами и самозанятыми.
Регистрация международного товарного знака (WIPO).
Услуги по международной регистрации товарных знаков по Мадридской системе.
Ускоренная регистрация товарного знака в ФИПС.
Услуга срочной регистрации товарного знака за 2-е недели в Роспатенте.
МКТУ - Международный классификатор товаров и услуг.
Полный перечень классов согласно международной классификации товаров и услуг.