Статус документа: Техническая спецификация

Правовой режим: Объект авторского права и исключительного права на метод

Назначение документа: Фиксация архитектуры экосистемы и детальное описание охраняемых элементов метода

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

Оглавление

Преамбула

Раздел 1. Введение и стратегическое позиционирование
1.1. Миссия и цели Экосистемы
1.2. Проблематика цифровой среды
1.3. Концепция управляемой пользовательской среды
1.4. Архитектурные принципы Nexus

Раздел 2. Архитектура Экосистемы Nexus
2.1. Браузерное расширение Nexus и его функции
2.2. Приложение-детектор Nexus и его функции
2.3. Протокол локального взаимодействия
2.4. Модель Verified Nexus ID
2.5. Модель реестра сайтов-партнёров (Белый список)
2.6. Модель чёрного списка (пиратские ресурсы)
2.7. Ограничение вмешательства в работу внешних ресурсов
2.8. Разделение функций

Раздел 3. Модуль управления подписками и доступом
3.1. Трёхуровневая подписочная модель
3.2. Проверка статуса подписки
3.3. Механизм блокировки и пропуска рекламы
3.4. Удаление элементов интерфейса на оплаченных сайтах

Раздел 4. Модуль контроля соблюдения правил экосистемы
4.1. Локальное выявление наличия расширений
4.2. Выявление сторонних расширений-блокировщиков
4.3. Система уведомлений
4.4. Приостановка функционирования до устранения нарушения
4.5. Автоматическое отключение при деактивации автозагрузки
4.6. Общая логика приостановки функционирования

Раздел 5. Модуль непрерывной верификации
5.1. Определение непрерывной верификации
5.2. Механизм непрерывной верификации
5.3. Обязательная автозагрузка приложения
5.4. Фиксация факта загрузки рекламы
5.5. Жизненный цикл доверенной сессии

Раздел 6. Модуль фиксации загрузки рекламы
6.1. Общие принципы
6.2. Использование штатных возможностей браузера
6.3. Определение наличия рекламных элементов
6.4. Передача информации детектору
6.5. Ограничение ответственности

Раздел 7. Модуль верификации пользователя и защиты от ботов
7.1. Уникальный идентификатор Nexus ID
7.2. Верификация рекламы
7.3. Выявление аномальной активности
7.4. Обработка аномальной активности
7.5. Принцип некриминализации пользователя

Раздел 8. Облачная инфраструктура
8.1. Реестр сайтов-партнёров
8.2. Синхронизация статусов подписок
8.3. Защищённое хранение данных пользователя

Раздел 9. Модуль аналитики и управления партнёрской эффективностью
9.1. Протокол детерминированной агрегации данных
9.2. Сегментация аудиторных контуров
9.3. Метрики вовлечённости
9.4. API-интеграция и отчётность

Раздел 10. Экономическая модель Экосистемы
10.1. Общие принципы
10.2. Двухуровневая подписочная модель
10.3. Стандартизация рекламы при бесплатной подписке
10.4. Блокировка рекламы при платной подписке
10.5. Распределение вознаграждений
10.6. Привязка экономической модели к архитектуре Метода

Раздел 11. Принципы обработки и минимизации данных
11.1. Категории обрабатываемых данных
11.2. Данные, которые не собираются
11.3. Правовые основания обработки
11.4. Принцип минимизации
11.5. Псевдонимизация и защита
11.6. Сроки хранения
11.7. Права субъекта данных
11.8. Трансграничная передача

Раздел 12. Протокол юридического комплаенса и правового посредничества
12.1. Статус технического агента пользователя
12.2. Модель согласованного рекламного взаимодействия
12.3. Соответствие требованиям различных юрисдикций

Раздел 13. Антимонопольная нейтральность и открытая архитектура
13.1. Добровольность участия
13.2. Отсутствие эксклюзивности
13.3. Совместимость и интероперабельность
13.4. Алгоритмическая нейтральность
13.5. Недискриминационный доступ

Раздел 14. Ограничение ответственности и пределы технологической гарантии
14.1. Отсутствие абсолютной гарантии
14.2. Ответственность за действия третьих лиц
14.3. Отсутствие статуса провайдера связи
14.4. Отсутствие статуса финансового посредника
14.5. Технологические ограничения
14.6. Ограничение убытков

Раздел 15. Интеллектуальная собственность и защита технологий
15.1. Консолидированный перечень охраняемых методов
15.2. Архитектурные алгоритмы, подлежащие правовой защите
15.3. Правовой режим компонентов Экосистемы
15.4. Защита облачной инфраструктуры
15.5. Лицензионная модель использования технологий
15.6. Ограничения на воспроизведение и модификацию

Раздел 16. Управление рисками и регуляторная адаптивность
16.1. Система управления рисками
16.2. Мониторинг изменений законодательства
16.3. Процедура адаптации к новым нормативным требованиям
16.4. Взаимодействие с регуляторами и надзорными органами
16.5. Процедура внутреннего аудита комплаенса
16.6. Механизм корректировки алгоритмов в случае регуляторных требований

Раздел 17. Информационная безопасность и контроль целостности
17.1. Модель контроля доступа
17.2. Разграничение полномочий внутри инфраструктуры
17.3. Шифрование и защита каналов передачи
17.4. Логирование и контроль целостности
17.5. Процедура реагирования на инциденты

Раздел 18. Корпоративная структура и операционная модель
18.1. Юридическая структура Экосистемы
18.2. Разграничение ролей между операционными единицами
18.3. Договорная модель взаимодействия с партнёрами
18.4. Принципы прозрачности и отчетности
18.5. Управление конфликтами интересов

Раздел 19. Международное масштабирование и стратегическая адаптация
19.1. Локализация в различных юрисдикциях
19.2. Адаптация к национальным требованиям
19.3. Стратегические партнёрства и интеграции
19.4. Масштабирование облачной инфраструктуры
19.5. Управление трансграничными операциями

Раздел 20. Применимое право и разрешение споров
20.1. Выбор применимого права
20.2. Претензионный порядок
20.3. Арбитраж
20.4. Обеспечительные меры
20.5. Разделимость положений документа

Раздел 21. Заключительные положения
21.1. Приоритет настоящего документа
21.2. Порядок внесения изменений
21.3. Вступление документа в силу
21.4. Официальные версии и языковые редакции

ТЕХНИЧЕСКОЕ ПРИЛОЖЕНИЕ

Раздел 22. Референтная реализация и эскроу
22.1. Референтная реализация
22.2. Обязанность по актуализации
22.3. Эскроу и доказательная база
22.4. Доступ к материалам

Раздел 23. Признаки нарушения и презумпции
23.1. Признаки нарушения
23.2. Презумпция использования
23.3. Бремя доказывания

Раздел 24. Экономическая архитектура Метода
24.1. Экономическая модель
24.2. Распределение доходов

Раздел 25. Функциональная эквивалентность и производные системы
25.1. Функциональная эквивалентность
25.2. Частичное воспроизведение Метода
25.3. Производные системы
25.4. Архитектурное влияние Метода
25.5. Границы Метода

Раздел 26. Методика расчёта активных пользователей
26.1. Критерии признания пользователя активным
26.2. Формула расчёта
26.3. Логи и аудит

Раздел 27. Учёт пользователей сублицензиатов
27.1. Обязанность по предоставлению данных
27.2. Методика расчёта при отсутствии прямого учёта
27.3. Аудит сублицензиатов

Раздел 28. Формы отчётности
28.1. Язык и валюта отчётности
28.2. Формат и подписание
28.3. Обязательные поля отчёта
28.4. Санкции за нарушение

Раздел 29. Критерии независимой разработки
29.1. Методология сравнения
29.2. Допустимые доказательства независимости
29.3. Верификация доказательств
29.4. Подтверждение независимого происхождения решений

Раздел 30. Протокол локального взаимодействия модулей
30.1. Структура сигнала подтверждения

Раздел 31. Порядок внесения изменений

Раздел 32. Закрепление идентичности метода


Преамбула

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

Документ является публичным описанием архитектуры для фиксации приоритета и одновременно содержит техническую спецификацию Охраняемого Метода.

Экосистема Nexus не ограничивает доступ пользователя к интернет-ресурсам. Ограничения применяются исключительно к функционалу самой экосистемы.

Раздел 1. Введение и стратегическое позиционирование

1.1. Миссия и цели Экосистемы

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

1.2. Проблематика цифровой среды

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

1.3. Концепция управляемой пользовательской среды

Пользователь самостоятельно выбирает модель взаимодействия с сайтами реестра Nexus: бесплатная подписка со стандартизированной рекламой либо платная подписка без рекламы. Все изменения отображения осуществляются на стороне устройства пользователя.

1.4. Архитектурные принципы Nexus

Самостоятельным объектом правовой охраны признаётся функционально-архитектурный Метод, включающий:

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

• логику распределения прав доступа и монетизации.

Метод Nexus является неделимым. Защите подлежит архитектурная логика и алгоритмы взаимодействия компонентов; программный код является лишь одной из вариативных форм реализации Метода. Охрана распространяется вне зависимости от формы реализации.

Раздел 2. Архитектура Экосистемы Nexus

2.1. Браузерное расширение Nexus и его функции

Браузерное расширение Nexus является прикладным модулем, устанавливаемым пользователем в браузер.

Назначение:

• блокировка рекламного контента на сайтах реестра Nexus (при платной подписке) и на сайтах чёрного списка (пиратские ресурсы);

• пропуск рекламного контента на сайтах реестра Nexus (при бесплатной подписке);

• стандартизация отображения рекламы при бесплатной подписке (устранение всплывающих окон, приведение к единому формату);

• фиксация факта загрузки рекламы с использованием штатных возможностей браузера без перехвата и анализа сетевого трафика;

• передача агрегированной информации детектору через локальный протокол взаимодействия.

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

2.2. Приложение-детектор Nexus и его функции

Приложение-детектор Nexus является вспомогательным приложением, устанавливаемым пользователем на устройство.

Назначение:

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

• проверка наличия и активности расширения Nexus в браузере;

• выявление сторонних расширений-блокировщиков только на сайтах реестра Nexus;

• отображение пользователю уведомлений;

• обеспечение обязательной автозагрузки приложения.

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

2.3. Протокол локального взаимодействия

Обмен данными между расширением и детектором осуществляется локально на устройстве пользователя (localhost) без передачи содержимого страниц или сетевого трафика.

2.4. Модель Verified Nexus ID

Nexus ID представляет собой уникальный идентификатор пользователя в экосистеме. Назначение: совершение оплаты подписок, настройка рекламных предпочтений (рекомендательный характер), верификация рекламы и выявление аномальной активности.

2.5. Модель реестра сайтов-партнёров (Белый список)

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

2.6. Модель чёрного списка (пиратские ресурсы)

Блокировка рекламного контента на сайтах чёрного списка осуществляется независимо от статуса подписки пользователя.

2.7. Ограничение вмешательства в работу внешних ресурсов

Экосистема не вмешивается в серверную логику сайтов. Все изменения отображения осуществляются исключительно на стороне пользовательского устройства.

На сайтах, не входящих в реестр Nexus (за исключением чёрного списка), работа внешних блокировщиков не запрещается, не отслеживается и не влечёт санкций.

2.8. Разделение функций

Строгое разделение ролей:

• Браузерное расширение: фиксация загрузки рекламы, блокировка/пропуск/стандартизация рекламы, удаление элементов интерфейса на оплаченных сайтах.

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

Раздел 3. Модуль управления подписками и доступом

3.1. Трёхуровневая подписочная модель

• Бесплатная подписка: стандартизация рекламы (настройки предпочтений носят рекомендательный характер).

• Платная подписка на отдельный сайт: блокировка рекламы + возможность удаления элементов интерфейса.

• Платная подписка на все сайты реестра: блокировка рекламы на всех сайтах реестра + возможность удаления элементов интерфейса.

3.2. Проверка статуса подписки

Расширение Nexus проверяет статус подписки пользователя в отношении конкретного сайта реестра через облачную инфраструктуру Nexus. Проверка осуществляется автоматически при каждом обращении к сайту реестра.

3.3. Механизм блокировки и пропуска рекламы

• На сайтах реестра Nexus: при активной платной подписке — блокировка рекламы; при бесплатной подписке — стандартизация отображения.

• На сайтах чёрного списка: блокировка рекламного контента независимо от статуса подписки пользователя.

• На сайтах, не входящих в реестр Nexus и не включённых в чёрный список: расширение не блокирует и не стандартизирует рекламу.

3.4. Удаление элементов интерфейса на оплаченных сайтах

Пользователь, оплативший подписку на конкретный сайт, вправе с помощью расширения Nexus удалять любые элементы интерфейса данного сайта. Изменения осуществляются на клиентской стороне в рамках разрешённых API браузера и не изменяют исходный код ресурса.

Раздел 4. Модуль контроля соблюдения правил экосистемы

4.1. Локальное выявление наличия расширений

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

4.2. Выявление сторонних расширений-блокировщиков

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

При обнаружении активного стороннего блокировщика на сайте реестра детектор отображает пользователю уведомление о необходимости устранения нарушения.

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

4.3. Система уведомлений

Пользователь уведомляется о выявлении сторонних расширений, влияющих на отображение рекламы на сайтах реестра Nexus. Форма уведомления определяется типом устройства.

4.4. Приостановка функционирования до устранения нарушения

При игнорировании уведомления функционирование экосистемы приостанавливается до момента устранения нарушения. Доступ пользователя к сайтам не ограничивается; ограничения применяются исключительно к функционалу экосистемы Nexus.

4.5. Автоматическое отключение при деактивации автозагрузки

При деактивации функции «работать в фоне» устройство автоматически отключается от экосистемы Nexus.

4.6. Общая логика приостановки функционирования

Функционирование системы Nexus напрямую зависит от соблюдения пользователем установленных правил. Любое нарушение, включая отключение функции «работать в фоне» или использование сторонних блокировщиков рекламы на сайтах реестра Nexus, влечёт автоматическую приостановку функционирования системы до момента устранения нарушения.

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

Раздел 5. Модуль непрерывной верификации

5.1. Определение непрерывной верификации

Непрерывная верификация — процесс фиксации событий загрузки рекламных элементов браузерным расширением Nexus и локального выявления сторонних расширений приложением-детектором Nexus без анализа содержимого страниц и сетевого трафика.

5.2. Механизм непрерывной верификации

Приложение-детектор Nexus осуществляет непрерывный локальный мониторинг браузерной среды пользователя при условии активированной функции «работать в фоне» (автозагрузка), которая является обязательным условием функционирования системы.

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

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

5.3. Обязательная автозагрузка приложения

При установке приложения Nexus пользователь даёт явное согласие на функцию «работать в фоне». Отсутствие согласия или его последующая деактивация является основанием для отказа в предоставлении функционала экосистемы Nexus до момента восстановления фонового режима.

5.4. Фиксация факта загрузки рекламы

Расширение Nexus с использованием штатных возможностей браузера (включая webRequest API и DOM API) фиксирует факт загрузки рекламного контента и передаёт агрегированный статус детектору через локальный протокол взаимодействия.

5.5. Жизненный цикл доверенной сессии

Полная последовательность:

• Пользователь открывает сайт реестра Nexus.

• Расширение проверяет наличие активного детектора (функция «работать в фоне»).

• Расширение проверяет статус подписки.

• В зависимости от статуса расширение блокирует или стандартизирует рекламу.

• Расширение фиксирует факт загрузки рекламы и передаёт информацию детектору.

• Детектор осуществляет локальное выявление сторонних расширений. При обнаружении блокировщика на сайте реестра — уведомление пользователя.

• При игнорировании уведомления — приостановка функционирования экосистемы до устранения нарушения.

• При деактивации автозагрузки — автоматическое отключение от экосистемы.

Раздел 6. Модуль фиксации загрузки рекламы

6.1. Общие принципы

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

6.2. Использование штатных возможностей браузера

Расширение использует webRequest API и DOM API для фиксации факта загрузки рекламных элементов без анализа содержимого страниц и сетевого трафика.

6.3. Определение наличия рекламных элементов

Определение осуществляется на основе стандартных признаков рекламного контента.

6.4. Передача информации детектору

В приложение-детектор передаётся агрегированный статус без передачи содержимого страниц или сетевых запросов.

6.5. Ограничение ответственности

Расширение не осуществляет перехват сетевого трафика на уровне операционной системы, не модифицирует серверную инфраструктуру издателя и не фильтрует трафик на системном уровне.

Раздел 7. Модуль верификации пользователя и защиты от ботов

7.1. Уникальный идентификатор Nexus ID

Nexus ID — уникальный идентификатор пользователя в экосистеме, формируемый при добровольной регистрации.

7.2. Верификация рекламы

Nexus ID используется для подтверждения сайтам-партнёрам, что рекламу просматривает реальный человек, а не бот.

7.3. Выявление аномальной активности

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

7.4. Обработка аномальной активности

При выявлении аномальной активности клики пользователя не засчитываются для целей монетизации. Доступ пользователя к экосистеме сохраняется.

7.5. Принцип некриминализации пользователя

Система не блокирует доступ пользователя и не применяет санкций к нему за выявленную аномальную активность.

Раздел 8. Облачная инфраструктура

8.1. Реестр сайтов-партнёров

Централизованный реестр (Белый список), синхронизируемый с локальными модулями.

8.2. Синхронизация статусов подписок

Обеспечивает синхронизацию статусов подписок между устройствами пользователя.

8.3. Защищённое хранение данных пользователя

Персональные данные пользователя (включая настройки рекламных предпочтений) хранятся в зашифрованном виде.

Раздел 9. Модуль аналитики и управления партнёрской эффективностью

9.1. Протокол детерминированной агрегации данных

Для партнёрских узлов предоставляется доступ к интерфейсу партнёрской аналитики, обеспечивающему системную агрегацию технических показателей.

9.2. Сегментация аудиторных контуров

Формирование отчётности по сегментам: бесплатная подписка, платная подписка на отдельный сайт, платная подписка на все сайты.

9.3. Метрики вовлечённости

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

9.4. API-интеграция и отчётность

Данные могут передаваться во внешние системы партнёра через защищённый API.

Раздел 10. Экономическая модель Экосистемы

10.1. Общие принципы

Экосистема Nexus функционирует в рамках единой подписочной модели. Экономическая модель является неотъемлемой частью архитектуры Метода.

10.2. Двухуровневая подписочная модель

• Оплата подписки на отдельный сайт реестра Nexus.

• Оплата подписки на все сайты реестра Nexus.

10.3. Стандартизация рекламы при бесплатной подписке

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

10.4. Блокировка рекламы при платной подписке

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

10.5. Распределение вознаграждений

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

10.6. Привязка экономической модели к архитектуре Метода

Экономическая модель, включая двухуровневую подписочную систему, механизмы стандартизации и блокировки рекламы, охраняется в составе Метода Nexus как его неотъемлемая часть. Воспроизведение указанной экономической модели в сочетании с техническими принципами Метода рассматривается как использование Метода или его производной реализации.

Раздел 11. Принципы обработки и минимизации данных

11.1. Категории обрабатываемых данных

Технические данные среды исполнения, событийные данные взаимодействия, псевдонимизированные идентификаторы (Nexus ID), агрегированные аналитические данные.

11.2. Данные, которые не собираются

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

11.3. Правовые основания обработки

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

11.4. Принцип минимизации данных

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

11.5. Псевдонимизация и защита

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

11.6. Сроки хранения

Технические логи — ограниченный период, необходимый для диагностики и безопасности; агрегированные статистические данные — в обезличенном виде без ограничения срока; данные профиля — до момента удаления учётной записи или истечения договорных обязательств.

11.7. Права субъекта данных

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

11.8. Трансграничная передача

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

Раздел 12. Протокол юридического комплаенса и правового посредничества

12.1. Статус технического агента пользователя

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

12.2. Модель согласованного рекламного взаимодействия

Nexus выступает технологическим посредником между пользователем и партнёрским ресурсом в части управления рекламной моделью доступа.

12.3. Соответствие требованиям различных юрисдикций

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

Раздел 13. Антимонопольная нейтральность и открытая архитектура

13.1. Добровольность участия

Участие в Экосистеме Nexus является полностью добровольным для всех участников. Nexus не навязывает установку программного обеспечения и не создаёт технических барьеров для выхода из системы.

13.2. Отсутствие эксклюзивности

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

13.3. Совместимость и интероперабельность

Nexus проектируется с учётом принципов совместимости и открытых стандартов. API-интерфейсы документированы и доступны для партнёрской интеграции.

13.4. Алгоритмическая нейтральность

Механизмы фильтрации принимают решения на основе объективных технических критериев и не предоставляют преференций аффилированным структурам.

13.5. Недискриминационный доступ

Доступ к статусу «Белого списка» определяется прозрачными и единообразными критериями. Отказ в подключении возможен исключительно при несоответствии требованиям безопасности, выявлении вредоносной активности или нарушении правил Экосистемы.

Раздел 14. Ограничение ответственности и пределы технологической гарантии

14.1. Отсутствие абсолютной гарантии

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

14.2. Ответственность за действия третьих лиц

Nexus не несёт ответственности за действия или бездействие издателей, рекламных сетей, поведение пользователей или вред, причинённый внешними сервисами.

14.3. Отсутствие статуса провайдера связи

Nexus не является оператором связи, интернет-провайдером и не осуществляет маршрутизацию общего интернет-трафика.

14.4. Отсутствие статуса финансового посредника

Nexus не является финансовой организацией. Платежные операции осуществляются через лицензированных платёжных провайдеров.

14.5. Технологические ограничения

Эффективность работы Nexus может зависеть от версии операционной системы, архитектурных ограничений устройства, конфликтов с иным программным обеспечением, ограничений браузера и сетевой инфраструктуры.

14.6. Ограничение убытков

В максимально допустимой применимым законодательством степени Nexus не несёт ответственности за косвенные убытки, упущенную выгоду или репутационные потери.

Раздел 15. Интеллектуальная собственность и защита технологий

15.1. Консолидированный перечень охраняемых методов

Охране подлежат следующие методы:

• метод организации взаимодействия браузерного расширения и приложения-детектора;

• метод управления подписками;

• метод контроля сторонних блокировщиков рекламы только на сайтах реестра Nexus;

• метод непрерывной верификации;

• метод фиксации факта загрузки рекламы с использованием штатных возможностей браузера;

• метод верификации пользователя (Nexus ID) и защиты от ботов.

15.2. Архитектурные алгоритмы, подлежащие правовой защите

Защите подлежит функциональный Метод и архитектурная логика. Поскольку Правообладатель защищает именно Метод, факт отсутствия или наличия конкретного программного кода не влияет на объём исключительных прав. Любая программная реализация признаётся лишь производной формой воплощения Охраняемого Метода.

15.3. Правовой режим компонентов Экосистемы

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

15.4. Защита облачной инфраструктуры

Облачная инфраструктура (реестр сайтов-партнёров, синхронизация подписок) охраняется как ноу-хау.

15.5. Лицензионная модель использования технологий

Использование Метода Nexus осуществляется на основании лицензии. Исключительные права на Метод остаются за Правообладателем.

15.6. Ограничения на воспроизведение и модификацию

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

Раздел 16. Управление рисками и регуляторная адаптивность

16.1. Система управления рисками

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

16.2. Мониторинг изменений законодательства

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

16.3. Процедура адаптации к новым нормативным требованиям

В случае вступления в силу новых нормативных требований Лицензиат проводит анализ влияния, разрабатывает план адаптации и внедряет необходимые изменения в разумный срок. Изменения, затрагивающие ключевые охраняемые элементы Метода, требуют письменного согласия Правообладателя.

16.4. Взаимодействие с регуляторами и надзорными органами

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

16.5. Процедура внутреннего аудита комплаенса

Лицензиат проводит внутренний аудит комплаенса не реже одного раза в год. Результаты аудита предоставляются Правообладателю по письменному запросу.

16.6. Механизм корректировки алгоритмов в случае регуляторных требований

При получении предписания регулятора Лицензиат незамедлительно уведомляет Правообладателя и совместно разрабатывает план корректировки. Изменения, затрагивающие ключевые охраняемые элементы Метода, требуют письменного согласия Правообладателя.

Раздел 17. Информационная безопасность и контроль целостности

17.1. Модель контроля доступа

Лицензиат обеспечивает многоуровневую модель контроля доступа к инфраструктуре Экосистемы Nexus (физический, сетевой, прикладной и уровень данных).

17.2. Разграничение полномочий внутри инфраструктуры

Доступ осуществляется на основе принципа минимальных привилегий. Роли доступа фиксируются в соответствующих внутренних документах Лицензиата.

17.3. Шифрование и защита каналов передачи

Все данные, передаваемые между компонентами Экосистемы, шифруются с использованием TLS версии не ниже 1.2. Данные пользователя хранятся в зашифрованном виде.

17.4. Логирование и контроль целостности

Лицензиат обеспечивает ведение логов всех значимых событий в неизменяемом виде не менее 3 лет.

17.5. Процедура реагирования на инциденты

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

Раздел 18. Корпоративная структура и операционная модель

18.1. Юридическая структура Экосистемы

Лицензиат самостоятельно определяет юридическую структуру, через которую осуществляется управление Экосистемой Nexus. Все юридические лица, участвующие в управлении, обязаны соблюдать условия настоящего Регламента.

18.2. Разграничение ролей между операционными единицами

Лицензиат обеспечивает чёткое разграничение ролей между операционными единицами (операционная компания, техническая инфраструктура, платёжная инфраструктура).

18.3. Договорная модель взаимодействия с партнёрами

Взаимодействие с сайтами-партнёрами осуществляется на основании типовых договоров, включающих условия включения сайта в реестр, порядок распределения дохода и ответственность сторон.

18.4. Принципы прозрачности и отчётности

Лицензиат обеспечивает прозрачность функционирования Экосистемы для Правообладателя и партнёров в пределах, предусмотренных настоящим Регламентом.

18.5. Управление конфликтами интересов

Лицензиат утверждает политику управления конфликтами интересов, исключающую использование Метода в ущерб интересам Правообладателя.

Раздел 19. Международное масштабирование и стратегическая адаптация

19.1. Локализация в различных юрисдикциях

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

19.2. Адаптация к национальным требованиям

Лицензиат вправе адаптировать функционал Экосистемы для соответствия требованиям конкретной юрисдикции. Адаптация не должна изменять ключевые охраняемые элементы Метода без письменного согласия Правообладателя.

19.3. Стратегические партнёрства и интеграции

Лицензиат вправе заключать стратегические партнёрства с иными компаниями для расширения Экосистемы. Стратегические партнёрства не освобождают Лицензиата от обязательств по выплате роялти Правообладателю.

19.4. Масштабирование облачной инфраструктуры

Лицензиат обеспечивает масштабируемость облачной инфраструктуры для обслуживания растущего числа пользователей. Переход к расширенному функционалу (Stage 3) осуществляется на основании подписания всех документов Stage 2 и начала фактических выплат в размере 640 000 руб./мес, а также подтверждённого запуска экосистемы в сеть и начала операционной активности (первые пользователи).

19.5. Управление трансграничными операциями

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

Раздел 20. Применимое право и разрешение споров

20.1. Выбор применимого права

Применимое право определяется в соответствии с местом регистрации операционной компании, созданной для управления экосистемой Nexus (далее — «Оператор экосистемы»), которая указана в отдельном соглашении Сторон. Место регистрации Оператора экосистемы фиксируется на дату заключения настоящего Регламента и не может быть изменено в одностороннем порядке без письменного согласия Сторон.

20.1.1. Если Оператор экосистемы зарегистрирован в Российской Федерации, применимым является право Российской Федерации.

20.1.2. Если Оператор экосистемы зарегистрирован в любой иной стране, применимым является право Дубайского международного финансового центра (DIFC), а в части, не урегулированной правом DIFC, — материальное право Объединённых Арабских Эмиратов (ОАЭ) без применения коллизионных норм.

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

20.2. Претензионный порядок

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

20.3. Арбитраж

20.3.1. Если применимым правом является право Российской Федерации, все споры, разногласия или требования, возникающие из настоящего Регламента или в связи с ним, которые не были урегулированы в претензионном порядке, подлежат разрешению в Международном коммерческом арбитражном суде при Торгово-промышленной палате Российской Федерации (МКАС) в г. Москве в соответствии с его Регламентом. Местом арбитража (seat) является г. Москва. Арбитраж проводится на русском языке, одним арбитром. Решение арбитража является окончательным и обязательным для Сторон.

20.3.2. Если применимым правом является право DIFC / ОАЭ, все споры, разногласия или требования, возникающие из настоящего Регламента или в связи с ним, которые не были урегулированы в претензионном порядке, подлежат окончательному разрешению в Международном арбитражном центре Дубая (DIAC) в соответствии с Регламентом DIAC. Местом арбитража (seat) является г. Дубай. Арбитраж проводится на русском языке (или, по соглашению Сторон, на английском языке), одним арбитром, назначаемым в соответствии с Регламентом DIAC. Решение арбитража является окончательным и обязательным для Сторон и приводится в исполнение в соответствии с Нью-Йоркской конвенцией 1958 года о признании и приведении в исполнение иностранных арбитражных решений.

20.4. Обеспечительные меры

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

20.5. Разделимость положений документа

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

Раздел 21. Заключительные положения

21.1. Приоритет настоящего документа

Настоящий Архитектурный Регламент является неотъемлемой частью Соглашения о владении интеллектуальной собственностью и применяется совместно с ним. В случае противоречия приоритет имеют положения настоящего Регламента как содержащие специальные и детализированные условия.

21.2. Порядок внесения изменений

Изменения в настоящий Регламент вносятся исключительно по взаимному письменному соглашению Сторон. Любые односторонние изменения, вносимые Лицензиатом, признаются недействительными и являются существенным нарушением Соглашения.

21.3. Вступление документа в силу

Настоящий Регламент вступает в силу с даты его подписания обеими Сторонами.

21.4. Официальные версии и языковые редакции

Официальной версией настоящего Регламента является версия на русском языке. В случае расхождения между русскоязычной версией и версией на ином языке приоритет имеет русскоязычная версия.

ТЕХНИЧЕСКОЕ ПРИЛОЖЕНИЕ

Раздел 22. Референтная реализация и эскроу

22.1. Референтная реализация

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

22.2. Обязанность по актуализации

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

22.3. Эскроу и доказательная база

Референтная реализация Метода подлежит депонированию до начала использования Метода Лицензиатом на Stage 3.

22.4. Доступ к материалам

В случае возникновения спора независимый эксперт получает доступ к материалам, хранящимся в escrow-депозитарии, исключительно в зашифрованном виде и только для целей сравнения с разработанным Лицензиатом решением. Расходы на предоставление доступа несёт сторона, запросившая экспертизу, с последующим перераспределением по правилам, установленным в разделе 29.

Раздел 23. Признаки нарушения и презумпции

23.1. Признаки нарушения

Наличие следующих признаков в разработке Лицензиата создаёт презумпцию использования Метода:

• использование браузерного расширения совместно с отдельным приложением-детектором, где расширение осуществляет блокировку/пропуск рекламы на сайтах реестра и блокировку на сайтах чёрного списка независимо от подписки, а детектор осуществляет обязательное сканирование браузера на наличие установленных расширений;

• реализация подписочной модели с разделением на бесплатный и платный доступ;

• механизм приостановки функционирования экосистемы до момента устранения нарушения при игнорировании пользователем требования отключить сторонний блокировщик на сайте реестра Nexus;

• фиксация факта загрузки рекламы с использованием штатных возможностей браузера;

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

23.2. Презумпция использования

При наличии совпадения одного или более ключевых признаков или создания разработки после даты, когда Лицензиат получил доступ к Методу, возникает презумпция использования Метода. Бремя доказывания независимости разработки переходит на Лицензиата.

23.3. Бремя доказывания

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

Раздел 24. Экономическая архитектура Метода

24.1. Экономическая модель

Метод Nexus включает экономическую модель функционирования экосистемы, обеспечивающую архитектуру и принципы функционирования единой подписочной системы, а также распределение доходов между участниками экосистемы.

24.2. Распределение доходов

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

Раздел 25. Функциональная эквивалентность и производные системы

25.1. Функциональная эквивалентность

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

25.2. Частичное воспроизведение Метода

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

25.3. Производные системы

Производной системой Метода Nexus признаётся любая система, продукт, платформа или технологическое решение, созданное на основе Метода либо использующее его архитектурные принципы, функциональные механизмы или экономическую модель полностью или частично, включая модифицированные, упрощённые, оптимизированные либо адаптированные версии таких элементов.

25.4. Архитектурное влияние Метода

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

25.5. Границы Метода

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

Раздел 26. Методика расчёта активных пользователей

26.1. Критерии признания пользователя активным

Активным признаётся уникальный идентификатор Nexus ID, при котором пользователь добровольно установил как браузерное расширение Nexus, так и приложение-детектор, и оба компонента функционируют в соответствии с правилами экосистемы (наличие активной сессии, активная функция «работать в фоне», отсутствие нарушений правил использования на сайтах реестра Nexus).

Сессионная активность: не менее одной подтверждённой пользовательской сессии в календарном месяце.

Анти-фрод верификация: исключение сессий, идентифицированных системой как подозрительные.

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

Active Users = MAX(MAU₁, MAU₂, MAU₃), где MAU₁, MAU₂, MAU₃ — количество активных пользователей за каждый из трёх месяцев отчётного квартала.

26.3. Логи и аудит

Система учёта обязана вести неизменяемые логи всех сессий, включая исключённые. По письменному запросу Правообладателя Лицензиат обязан предоставить полный отчёт в формате .csv с хэш-суммами SHA-256 для верификации целостности данных.

Раздел 27. Учёт пользователей сублицензиатов

27.1. Обязанность по предоставлению данных

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

27.2. Методика расчёта при отсутствии прямого учёта

Если прямой учёт невозможен, применяется презумпция: роялти, подлежащее уплате за деятельность сублицензиата, составляет не менее 50 % от суммы роялти, уплаченной Лицензиатом за тот же отчётный период, но не менее суммы, рассчитанной пропорционально доле выручки такого сублицензиата в общей выручке Экосистемы за предыдущий квартал (если такая доля превышает 30 %).

27.3. Аудит сублицензиатов

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

Раздел 28. Формы отчётности

28.1. Язык и валюта отчётности

Все отчёты предоставляются на русском языке. Все финансовые показатели указываются в рублях Российской Федерации.

28.2. Формат и подписание

Ежеквартальный отчёт предоставляется в электронном виде (.xlsx или .csv) и должен быть подписан квалифицированной электронной подписью генерального директора или финансового директора Лицензиата. К отчёту прилагается файл с хэш-суммой SHA-256.

28.3. Обязательные поля отчёта

Reporting Quarter, Max Active Users, Monthly Breakdown, Total Revenue, Revenue Breakdown, Anti-Fraud Exclusions, List of Sublicensees (если применимо).

28.4. Санкции за нарушение

Предоставление неполного отчёта или непредоставление отчёта в установленный срок признаётся существенным нарушением и влечёт начисление пени в размере 0,05 % от суммы роялти за отчётный период за каждый день просрочки.

Раздел 29. Критерии независимой разработки

29.1. Методология сравнения

Разработка Лицензиата признаётся производной от Метода, если она воспроизводит один или более ключевых признаков, перечисленных в разделе 23 настоящего документа, и создана после даты, когда Лицензиат или любое лицо, получившее доступ к Методу, получило доступ к Методу.

29.2. Допустимые доказательства независимости

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

29.3. Верификация доказательств

Все доказательства, предоставляемые Лицензиатом, подлежат проверке независимой цифровой экспертизой. Расходы на проведение экспертизы несёт Лицензиат, если в результате экспертизы будет подтверждён факт использования Метода.

29.4. Подтверждение независимого происхождения решений

Если Лицензиат заявляет, что разработанное им решение было создано независимо от Метода Nexus, Лицензиат обязан по разумному письменному запросу Правообладателя предоставить документацию, подтверждающую самостоятельное происхождение соответствующего решения.

Раздел 30. Протокол локального взаимодействия модулей

30.1. Структура сигнала подтверждения

Сигнал, формируемый расширением Nexus и передаваемый детектору, должен содержать: Session ID (псевдонимизированный идентификатор сессии), Timestamp (временная метка), Event Type (тип события), Subscription Status (статус подписки пользователя в отношении конкретного сайта).

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

Раздел 31. Порядок внесения изменений

Изменения в настоящее Приложение вносятся исключительно по взаимному письменному соглашению Сторон. Любые односторонние изменения, вносимые Лицензиатом, признаются недействительными и являются существенным нарушением.

Раздел 32. Закрепление идентичности метода

Архитектурная и алгоритмическая структура, описанная в настоящем документе, признаётся референтной технической спецификацией Охраняемого Метода.

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

Любая техническая реализация, достигающая существенно идентичной системной логики и функционального результата (включая разделение функций между браузерным расширением и приложением-детектором с обязательным сканированием браузера на наличие установленных расширений, подписочную модель с блокировкой/пропуском рекламы, механизм блокировки на сайтах чёрного списка независимо от подписки, механизм приостановки функционирования экосистемы при игнорировании требований детектора только на сайтах реестра, локальный мониторинг при условии активной функции «работать в фоне»), презюмируется производной от Охраняемого Метода, если иное не доказано посредством независимой технической экспертизы.