СПОСОБ УПРАВЛЕНИЯ ЦИФРОВЫМИ ПРАВАМИ НА ОСНОВЕ ТЕХНОЛОГИИ БЛОКЧЕЙНА

Область техники, к которой относится изобретение

Настоящее изобретение относится к управлению цифровыми правами (digital rights management (DRM)), и более конкретно, к реализации такого управления DRM с использованием блокчейнов.

Уровень техники

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

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

Раскрытие изобретения

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

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

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

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

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

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

Краткое описание чертежей

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

Фиг. 1 представляет блок-схему блокчейна, содержащего n блоков и первичный блок;

Фиг. 2 представляет блок-схему компонентов и взаимодействия в одном из вариантов новой системы управления DRM с использованием блокчейна;

Фиг. 3 представляет блок-схему одного из вариантов блокчейна прав (rights blockchain (RBC));

Фиг. 4 представляет блок-схему одного из вариантов защищенного контента;

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

Фиг, 6 представляет логическую схему, иллюстрирующую процедуру генерирования блокчейна RBC, в соответствии с одним из вариантов настоящего изобретения;

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

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

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

Осуществление изобретения

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

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

Структура данных блокчейна представляет собой упорядоченный список блоков. Каждый блок указывает назад строго на своего предшественника до тех пор, пока последовательность указаний не дойдет до первого блока в блокчейне, обычно называемого «порождающим» или первичным блоком ("genesis block"). Эти блоки и целостность их последовательности защищены посредством осуществляющих связь в обратном направлении криптографических хешей.

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

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

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

На Фиг. 1 представлена блок-схема блокчейна 100, содержащего n блоков 110, 120, 130 и первичный блок 140. В одном из вариантов, блок имеет по меньшей мере три элемента: информационную секцию (например, 112), сохраняющую зарегистрированные данные и вспомогательные данные; криптографический хеш (например, 114) из состава предшествующего блока (первичный блок не будет иметь предшествующего блока); и криптографический хеш (например, 116) из состава текущего блока,

На Фиг. 2 представлена блок-схема компонентов и взаимодействия в одном из вариантов новой системы управления DRM 200 с использованием блокчейна. Лицензия, зашифрованная для пользователя/устройства, в традиционной системе управления DRM, содержит и дескремблирующий ключ, и права пользователя, ассоциированные с фрагментом контента или с множеством фрагментов контента. В этой новой системе 200 лицензия заменена блоком в составе блокчейна RBC 210, сохраняющего права пользователя, полученные каким-либо пользователем. Этот блокчейн 210 не защищен с точки конфиденциальности, а защищена только его целостность. На Фиг. 3 представлена блок-схема одного из вариантов блокчейна RBC 210.

В вариантах, иллюстрируемых на Фиг. 2 и 3, система управления DRM 200 содержит блокчейн RBC 210, провайдера 220 контента, идентификационные данные 230 пользователя, службу 240 регистрации, защищенный контент 250 и агента 260 управления DRM. В других вариантах не все инстанции или объекты/данные, показанные на Фиг. 2, необходимы или используются.

Идентификационные данные 230 пользователя уникальны для пользователя и криптографически связаны с идентификатором (ID) пользователя (например, идентификатором ID 322 пользователя, показанным на Фиг. 3) блокчейна RBC 210. Служба 240 регистрации добавляет новые блоки к блокчейну RBC 210 пользователя. Провайдер 220 контента распределяет защищенный контент 250, равно как и ассоциированные права использования, пользователю. Служба 240 регистрации добавляет права использования к блокчейну RBC 210 пользователя. Защищенный контент 250 содержит скремблированный контент (например, скремблированный кинофильм). Агент 260 управления DRM осуществляет функцию управления цифровыми правами. В одном из вариантов агент 260 управления DRM работает в устройстве пользователя, используемом для потребления/просмотра контента. Агент 260 управления DRM принимает защищенный контент 250 и блокчейн RBC 210. Если пользователь уполномочен на доступ к контенту, агент 260 управления DRM дескремблирует защищенный контент 250.

В одном из вариантов каждый из модулей в компьютерной системе выполнен отдельно (например, провайдер 220 контента, служба 240 регистрации и агент 260 управления DRM). В одном из вариантов вся компьютерная система может быть расположена в одном месте или объединена (например, провайдер 220 контента и служба 240 регистрации работают в одной и той же серверной системе), либо здесь могут принимать участие дополнительные системы, не показанные на чертежах (например, несколько систем пользователей, таких как мобильный телефон и/или планшетный компьютер, и несколько сетевых систем распределения контента).

В варианте, показанном на Фиг. 3, информационный блок 321 в составе первичного блока 320 сохраняет по меньшей мере один идентификатор ID 322 пользователя. Этот идентификатор ID 322 пользователя может быть анонимным, тогда как блокчейн RBC 210 может быть публичным. Идентификатор ID 322 пользователя не является конфиденциальным. Первичный блок 320 содержит также хеш 324 своего информационного блока 321. Последующий блок (например, блок 1 (310)) также содержит хеш 318 текущего блока и хеш 319 предшествующего блока.

Информационный блок (например, 311 для блока 1) из состава последующих блоков (блок 1 (310), ..., блок n (330)) содержит по меньшей мере один идентификатор контента (ID) (например, 312 для блока 1), права использования (например, 314 для блока 1) и цифровую сигнатуру (например, 316 для блока 1).

Идентификатор ID 312 контента однозначно идентифицирует один фрагмент контента или работы. Работа может представлять собой какую-либо конкретную версию контента, либо это может быть сам контент независимо от форматов. Провайдер 220 контента управляет и определяет идентификатор ID 312 контента. Права 314 использования определяют права пользователя, которые были предоставлены пользователю или приобретены пользователем для этой работы. Формат может представлять собой стандартизованный язык прав, такой как расширяемый язык прав (Rights Markup Language (XrML)) или открытый язык цифровых прав (Open Digital Rights Language (ODRL)), интеллектуальный контракт или какой-либо собственный формат. Служба 240 регистрации выпускает цифровую сигнатуру 316. Эта сигнатура 316 охватывает информационный блок 311.

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

В одном из примеров вариантов, блокчейн использует следующую информацию и формат: идентификатор ID 322 пользователя представляет собой 2048-битовое число, предоставляемое службой 240 регистрации, когда пользователь регистрируется и создает первичный блок 320; идентификатор ID контента (110) использует регистр идентификаторов развлечения (Entertainment. Identifier Registry (EIDR)) для контента (см., например, eidr.org); права использования (например, права 314) представляют собой структуру данных, содержащую список лицензированных аудио языков и список лицензированных субтитров; и все хеши (например, хеши 318, 319, 324) представляют собой хеши SHA-512, кодированный в коде base64. Для block_n, сигнатура (например, сигнатура 316 для блока 1) представляет собой сигнатуру RSA 2048 (Ривест, Шамир и Адельмана (Rivest, Shamir и Adelmana; криптосистема с открытым ключом)), содержащую три поля – идентификатор ID контента (например, 312), права использования (например, 314) и хеш (например, 319) для block_n-1. Служба 240 регистрации генерирует сигнатуру с использованием своего секретного ключа для корневой подписи (root signing private key). Для первичного блока сигнатура RSA 2048 содержит поле идентификатора ID пользователя (например, 322). Хеш (например, 318, 314) блока охватывает информационный блок 311 и хеш предшествующего блока (например, 319). Хеш 324 первичного блока 320 охватывает только информационный блок 321.

На Фиг. 4 представлена блок схема одного из вариантов защищенного контента 250. Защищенный контент 250 содержит по меньшей мере идентификатор ID 410 контента, скремблированное содержание 420 контента и зашифрованное управляющее слово 430 (зашифрованное слово CV). Идентификатор ID 410 контента идентифицирует работу. Это происходит так же, как с использованием блокчейна RBC 210. Скремблированное содержание 420 контента представляет собой результат скремблирования чистого содержания контента (т.е. контент в чистой форме, без скремблирования) с использованием управляющего слова (CW), которое представляет собой случайное число, генерируемое провайдером 220 контента. В одном из вариантов алгоритм скремблирования представляет собой алгоритм AES 128-бит в режиме CBC. Иными словами, скремблированное содержание = AES_(CW) (чистое содержание). Зашифрованное слово CW 430 представляет собой результат шифрования слова CW (используется для скремблирования этого содержания) с ключом, известным агенту 260 управления DRM (например, с использованием секретного ключа или пары открытый ключ – секретный ключ).

В одном из вариантов, агент 260 управления DRM имеет уникальный 128-битовый ключ DRM_KEY, используемый для шифрования, слово CW и шифрование использует усовершенствованный стандарт шифрования (Advanced Encryption Standard (AES)). В одном из вариантов, слово CW представляет собой 128-битовый специальный параметр, формируемый генератором случайных чисел. Иными словами,

Зашифрованное (Encrypted) CW = AES _{(DRM_KEY)} (CW)

В одном из вариантов, провайдер 220 контента может использовать несколько технологий управления DRM. В этом случае каждый поддерживаемый агент 260 управления DRM идентифицирован посредством своего идентификатора DRM-ID агента. Структура данных для защищенного контента 250 содержит список пар из идентификатора DRM-ID и соответствующего зашифрованного слова CW 430. Каждое зашифрованное слово CW 430 представляет собой слово CW, зашифрованное секретным ключом DRM_KEY соответствующего агента 260 управления DRM.

На Фиг. 5 представлена логическая схема 500, иллюстрирующая процедуру управления цифровыми правами (DRM) с использованием блокчейна в соответствии с одним из вариантов настоящего изобретения. В одном из вариантов процедура управления DRM осуществляется в агенте 260 управления DRM, показанном на Фиг. 2.

В варианте, показанном на Фиг. 5, принимают защищенный контент 250 в блоке 510. В блоке 520 запрашивают и принимают идентификационные данные 230 пользователя и указатель на блокчейн RBC 210 пользователя. В блоке 530 проверяют действительность принятого блокчейна RBC 210. Действительность этого блокчейна RBC 210 проверяют посредством определения, являются ли хеши (например, хеши 318, 319 для блока 1, показанные на Фиг. 3) для каждого блока и хеш первичного блока (например, хеш 324 в показанном на Фиг. 3 первичном блоке) согласованными. Для каждого непервичного блока процедура определения действительности верифицирует, что вычисленный хеш этого блока равен хешу 318, и что вычисленный хеш предшествующего блока равен хешу 319. Для первичного блока процедура определения действительности верифицирует, что вычисленный хеш этого блока равен хешу 324.

После этого выполняют верификацию того, что принятый блокчейн RBC 210 фактически принадлежит рассматриваемому пользователю. В одном из вариантов, в блоке 540 осуществляют проверку для определения, соответствует ли идентификатор ID 322 пользователя в составе блокчейна RBC 210 принятым идентификационным данным 230 пользователя. Если имеет место соответствие, можно определить, что все права использования (например, права 314 в блоке 1 в составе блокчейна RBC 210, показанного на Фиг. 3), перечисленные в принятом блокчейне RBC, ассоциированы с рассматриваемым пользователем.

Когда определено, что принятый блокчейн RBC ассоциирован с пользователем, ищут, в блоке 550, в составе этого блокчейна RBC блок, содержащий идентификатор ID защищенного контента. Затем в соответствующем найденном блоке проверяют, в блоке 560, сигнатуру информационного блока и прав использования. Если в блоке 570 определено, определено, что права использования действительны, расшифровывают в блоке 530 зашифрованное слово CW 430 с применением секретного ключа (т.е. ключа DRM_KEY) и выделяют чистое слово CW. В блоке 590 дескремблируют скремблированное содержание с использованием чистого слова CW.

В варианте, показанном на Фиг. 5, процедура управления DRM с использованием блокчейна не использует централизованный лицензионный сервер или централизованный контейнер прав. Вместо контейнера прав используется ассоциирование блокчейна RBC 210 и службы 240 регистрации. Аналогично роль лицензионного сервера распределяют между блокчейном RBC 210, определяющим права использования, защищенным контентом 250, сохраняющим зашифрованное слово CW 430 и агентом 260 управления DRM, который приводит в исполнение права использования.

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

Если провайдер 220 контента дополняет или изменяет свою технологию управления DRM, ему нужно просто выпустить новую версию защищенного контента 250 с новым зашифрованным словом CW 430 для нового агента 260 управления DRM.

Один из вариантов рассчитан на работу с технологией E-sell through (EST). Пользователь получает лицензионные права для просмотра контента на конкретном рассматриваемом языке (или группе языков) и с потенциальными субтитрами на конкретном языке (или группе языков). Лицензия является бессрочной (или действует в течение по меньшей мере разумного числа лет) и независимой от качества просматриваемого события контента. В одном таком варианте провайдер 220 контента использует одну процедуру управления DRM.

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

Для создания блокчейна RBC, пользователь A осуществляет регистрацию путем генерирования пары ключей RSA 2048 и вхождения в контакт со службой 240 регистрации. Служба 240 регистрации затем выполняет следующие операции: запрашивает открытый ключ пользователя A; верифицирует, зарегистрирован ли уже этот открытый ключ; если этот ключ уже зарегистрирован, запрашивает у пользователя A генерацию другой пары ключей; верифицирует, с использованием запросно-ответного протокола, имеет ли пользователь A соответствующий секретный ключ; создает идентификатор ID 322 пользователя с использованием открытого ключа пользователя A; создает первичный блок 320 для пользователя A в соответствии с блокчейном RBC 210; и передает созданный первичный блок 320 этому пользователю A.

На Фиг. 6 представлена логическая схема 600, иллюстрирующая процедуру генерирования блокчейна RBC в соответствии с одним из вариантов настоящего изобретения. В варианте, показанном на Фиг. 6, в блоке 600 служба регистрации принимает от пользователя запрос регистрации. В ответ на этот запрос служба регистрации запрашивает, в блоке 620, от пользователя открытый ключ и верифицирует, в блоке 630, является ли этот открытый ключ уже зарегистрированным. В блоке 640 служба регистрации запрашивает от пользователя генерацию другой пары ключей, если ключ оказался уже зарегистрирован. После этого служба регистрации верифицирует, в блоке 650, с применением запросно-ответного протокола, имеет ли пользователь соответствующий секретный ключ, создает, в блоке 660, идентификатор (ID) пользователя с использованием открытого ключа этого пользователя, создает и передает пользователю, в блоке 670, блокчейн прав с первичным блоком для этого блокчейна RBC.

Для получения конкретного контента и добавления прав использования выполняют следующие операции: пользователь A передает блокчейн RBC провайдеру 220 контента; провайдер 220 контента информирует службу 240 регистрации, что пользователь A получает контент; пользователь (или провайдер 220 контента) предоставляет блокчейн RBC 210, идентификатор ID (например, идентификатор ID 312 для блока 1) заказанного контента, и ассоциированные права использования (например, идентификатор ID 314 для блока 1), такие как список лицензированных языков и языков субтитров; служба 240 регистрации проверяет действительность/целостность предоставленного блокчейна RBC (т.е. не был ли блокчейн RBC скомпрометирован или взломан); служба 240 регистрации добавляет новый блок с предоставленными данными и хешами (например, хеши 318, 319 для блока 1, показанного на Фиг. 3) для информации в новом блоке и предшествующем блоке, если блокчейн RBC 210 действителен; и служба 240 регистрации возвращает блокчейн RBC 210 провайдеру 220 контента, который возвращает блокчейн RBC 210 пользователю A.

На Фиг. 7 представлена логическая схема 700, иллюстрирующая процедуру для получения некоего конкретного контента и добавления прав использования к блокчейну RBC в соответствии с одним из вариантов настоящего изобретения. В варианте, иллюстрируемом на Фиг. 7, когда пользователь, в блоке 710, получает рассматриваемый конкретный контент от провайдера контента, этот провайдер контента информирует, в блоке 720, службу регистрации, что пользователь получает контент. Провайдер контента предоставляет идентификатор ID заказанного контента и ассоциированные права использования, такие как список лицензированных языков и языков субтитров, в блоке 730, в службу регистрации. Служба регистрации затем проверяет целостность предоставленного ей блокчейна RBC, в блоке 740, и добавляет, в блоке 750, новый блок с предоставленными данными и хешами для информации в этот новый блок и в предшествующий блок, если блокчейн RBC действителен и не был скомпрометирован или взломан. В блоке 760 служба регистрация возвращает блокчейн RBC пользователю.

Для «упаковки» контента, в одном из вариантов, провайдер 220 контента осуществляет следующие операции: регистрирует эту версию контента, в регистре EIDR для приема идентификатора ID контента (например, 312 для блока 1); генерирует случайное 128-битовое число, которое станет словом CW; вычисляет соответствующее зашифрованное слово CW 430 для каждого поддерживаемого события управления DRM путем шифрования слова CW с использованием соответствующего ключа DRM_KEY; скремблирует чистое содержание с применением слова CW для генерирования скремблированного содержания 420; и упаковывает всю эту информацию в защищенный контент 250. В одном из вариантов процедура скремблирования использует стандарт AES в режиме счетчика (CTR). Защищенный контент 250 можно распределять свободно, поскольку он является самозащищенным.

На Фиг. 8 представлена логическая схема 800, иллюстрирующая способ упаковки контента у провайдера контента в соответствии с одним из вариантов настоящего изобретения. В варианте, иллюстрируемом на Фиг. 8, провайдер контента регистрирует текущую версию контента в регистре EIDR для приема идентификатора ID этого контента, в блоке 810. Провайдер контента затем, в блоке 820, генерирует случайное число, которое станет управляющим словом (CW), и вычисляет соответствующее зашифрованное слово CW для каждого поддерживаемого события управления DRM посредством шифрования слова CW с использованием соответствующего секретного ключа (DRM_KEY), в блоке 830. Провайдер контента также скремблирует чистое содержание с использованием слова CW для генерирования скремблированного содержания, в блоке 840, и упаковывает всю информацию в состав защищенного контента.

Для потребления этого контента (например, просмотра защищенного контента) агент 260 управления DRM выполняет следующие операции: принимает от пользователя A блокчейн RBC 210 и защищенный контент 250; верифицирует действительность блокчейна RBC 210; выделяет идентификатор ID 322 пользователя; верифицирует, имеет ли пользователь A секретный ключ, соответствующий идентификатору ID 322 пользователя, с использованием запросно-ответного протокола; проверяет, присутствует ли идентификатор ID (например, 312 для блока 1) защищенного контента 250 в составе блокчейна RBC 210 пользователя A; верифицирует, содержат ли права использования (например, 314 для блока 1) список языка и языка субтитров, запрашиваемых пользователем A, если идентификатор ID контента присутствует в блокчейне RBC 210 пользователя A; расшифровывает зашифрованное слово CW 430 с использованием своего секретного ключа DRM_KEY и выделяет чистое слова CW, если права использования верифицированы; и дескремблирует и передает скремблированное содержание 420 вместе со словом CW пользователю A для потребления.

В другом варианте, один и тот же блокчейн RBC 210 работает с несколькими независимыми провайдерами 220 контента. Каждый провайдер 220 контента может использовать своего собственного агента 260 управления DRM или использовать агента 260 управления DRM совместно с другими провайдерами.

На Фиг. 9 представлена логическая схема 900, иллюстрирующая процедуру потребления контента в соответствии с одним из вариантов настоящего изобретения. В иллюстрируемом на Фиг. 9 варианте, в блоке 910, агент управления DRM принимает блокчейн RBC и защищенный контент и верифицирует действительность блокчейна RBC в блоке 920. Затем, в блоке 930, выделяют идентификатор ID пользователя из блокчейна RBC, и агент управления DRM, в блоке 940, верифицирует, имеет ли пользователь секретный ключ, соответствующий идентификатору ID пользователя, с использованием запросно-ответного протокола. В блоке 950 проверяют идентификатор ID защищенного контента, чтобы определить, присутствует ли он в блокчейне RBC. Затем, в блоке 960, агент управления DRM верифицирует, указывают ли права использования язык и язык субтитров, запрошенные пользователем, если идентификатор ID контента присутствует в блокчейне RBC. Агент управления DRM в блоке 970 расшифровывает зашифрованное слово CW с использованием секретного ключа и выделяет чистое слово CW, если права использования верифицированы. Скремблированное содержание в блоке 980 дескремблируют и передают вместе со словом CW пользователю для потребления.

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

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

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