ВЫДАЧА ЛИЦЕНЗИЙ НА ИСПОЛЬЗОВАНИЕ СРЕДСТВА ПУБЛИКАЦИИ В АВТОНОМНОМ РЕЖИМЕ В СИСТЕМЕ УПРАВЛЕНИЯ ПРАВАМИ НА ЦИФРОВОЕ СОДЕРЖИМОЕ DRM Российский патент 2008 года по МПК G06F12/14 H04L9/32 G06F21/20 

Нижеследующие заявки на патенты США раскрывают объект настоящего изобретения и полностью включены здесь в качестве ссылки.

Заявка на патент США за номером 10/185.527, зарегистрированная 28 июня 2002 года, номер реестра поверенного MSFT-1330, и называемая «Obtaining a Signed Rights Label (SRL) for Digital Content and Obtaining a Digital License Corresponding to the Content Based on the SRL in a Digital Rights Management System».

Заявка на патент США за номером 10/185.278, зарегистрированная 28 июня 2002 года, номер реестра поверенного MSFT-1333, и называемая «Using a Rights Template to Obtain a Signed Rights Label (SRL) for Digital Content in a Digital Rights Management System».

Заявка на патент США за номером 10/185.511, зарегистрированная 28 июня 2002 года, номер реестра поверенного MSFT-1343, и называемая «Systems And Methods For Issuing Usage Licenses For Digital Content And Services».

Заявка на патент США, зарегистрированная под номером реестра поверенного MSFT-1498 и называемая «Publishing Digital Content Within an Organization in Accordance with a Digital Rights Management (DRM) System».

Заявка на патент США, зарегистрированная под номером реестра поверенного MSFT-1569 и называемая «Publishing Digital Content Within an Organization in Accordance with a Digital Rights Management (DRM) System».

Заявка на патент США, зарегистрированная одновременно с настоящей заявкой, номер реестра поверенного MSFT-1536, и называемая «Enrolling/Sub-Enrolling a Digital Rights Management (DRM) Server Into a DRM Architecture».

Настоящее изобретение относится к системе Управления Правами на цифровое содержимое (DRM). В частности, изобретение относится к использованию DRM-системы для публикации (продвижения в сеть) цифрового содержимого в организации, например учреждении или корпоративной организации и т.д., при этом воспроизведение и использование содержимого внутри организации могут быть ограничены согласно соответствующим условиям использования или условиям лицензии. Еще более конкретно настоящее изобретение относится к публикации содержимого без связи с сервером для разрешения и к выдаче себе лицензии на использование средства публикации для воспроизведения опубликованного содержимого без связи с сервером для разрешения.

Управление правами на цифровое содержимое и принудительное выполнение требований требуются в отношении цифрового содержимого, например цифровых звуковых данных, цифровых видеоданных, цифрового текста, цифровых данных, цифровых мультимедийных данных и т.д., где указанное цифровое содержимое должно быть распределено одному или большему количеству пользователей. Цифровое содержимое может быть статическим, например, текстовый документ, или может быть представлено в виде потока, например в виде потока звуковых данных/видеоданных происходящего события. Обычные режимы распределения включают материальные устройства, такие как магнитный (гибкий) диск, магнитная лента, оптический (компактный) диск (CD) и т.д., и нематериальные средства, такие как электронная доска объявлений, электронная сеть, Интернет и т.д. При получении цифрового содержимого пользователь осуществляет воспроизведение или 'проигрывает' цифровое содержимое, используя соответствующее устройство воспроизведения, такое как медиаплеер на персональном компьютере или подобное устройство.

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

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

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

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

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

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

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

По меньшей мере частично упомянутым выше потребностям удовлетворяет настоящее изобретение, в котором публикующий пользователь публикует цифровое содержимое и выдает себе соответствующую цифровую лицензию на средство публикации для обеспечения себе возможности воспроизведения опубликованного цифрового содержимого. Публикующий пользователь снабжается сертификатом публикации из сервера управления правами на цифровое содержимое (DRM), где сертификат публикации имеет открытый ключ (PU-OLP) и соответствующий секретный ключ (PR-OLP), шифрованный открытым ключом, соответствующим публикующему пользователю (PU-ENTITY), для формирования (PU-ENTITY(PR-OLP)).

Содержимое разрабатывается и шифруется в соответствии с ключом содержимого (CK), и для шифрованного содержимого создается метка прав с (CK), шифрованным открытым ключом DRM-сервера (PU-DRM), для формирования (PU-DRM(CK)). Из сертификата публикации восстанавливается (PU-ENTITY(PR-OLP)), секретный ключ (PR-ENTITY), соответствующий (PU-ENTITY), применяется к (PU-ENTITY(PR-OLP)) для получения (PR-OLP), и созданная метка прав подписывается (PR-OLP) для создания подписанной метки прав (SRL). Затем созданная SRL и сертификат публикации соединяются с шифрованным содержимым для формирования пакета содержимого, который может быть распределен другому пользователю, который должен связаться с DRM-сервером для получения в нем соответствующей лицензии с (CK) для воспроизведения шифрованного содержимого. Существенно, что только такой DRM-сервер имеет секретный ключ (PR-DRM), соответствующий (PU-DRM), и может применить (PR-DRM) к (PU-DRM(CK)) для получения (CK).

Также создаются данные лицензии, соответствующие пакету содержимого, которые имеют (CK), шифрованный (PU-ENTITY), для формирования (PU-ENTITY(CK)), созданные данные лицензии подписываются (PR-OLP) для создания лицензии на средство публикации, и сертификат публикации присоединяется к лицензии на средство публикации. Только публикующий пользователь, имеющий (PR-ENTITY), соответствующий (PR-ENTITY), может применить такой (PR-ENTITY) к (PU-ENTITY(CK)) из лицензии на средство публикации для получения (CK) и расшифровки посредством (CK) шифрованного содержимого для воспроизведения.

В частности, публикующий пользователь осуществляет проверку сертификата публикации на основе цепочки сертификатов, получает (PU-OLP) из сертификата публикации и использует полученный (PU-OLP) для проверки подписи лицензии на средство публикации. После этого публикующий пользователь восстанавливает (PU-ENTITY(CK)) из проверенной лицензии на средство публикации, применяет к (PU-ENTITY(CK)) секретный ключ (PR-ENTITY), соответствующий (PU-ENTITY), для получения (CK) и применяет (CK) к CK(содержимого) (CK(content)) для вывода содержимого. Затем содержимое направляется приложению воспроизведения для фактического воспроизведения.

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

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

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

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

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

Фиг.4A является структурной схемой, изображающей структуру подписанной метки прав, созданной способом фиг.4.

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

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

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

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

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

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

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

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

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

Фиг.14 и 15 являются блок-схемами, изображающими основные этапы, выполняемые регистрирующими и входящими DRM-серверами фиг.13 и 14 для регистрации (фиг.14) или под-регистрации (фиг.15) входящего DRM-сервера.

Среда вычислительного устройства

Фиг.1 и последующее описание предназначены для краткого общего описания соответствующей вычислительной среды, в которой может быть реализовано настоящее изобретение. Однако, следует иметь в виду, что для использования настоящего изобретения подходят переносные, портативные и другие вычислительные устройства всех видов. Хотя ниже описан универсальный компьютер, он является только одним возможным вариантом, и для настоящего изобретения требуется только «тонкий» клиент (малофункциональный, маломощный сетевой клиент-терминал), имеющий возможность взаимодействия и обмена данными с сетевым сервером. Следовательно, настоящее изобретение может быть реализовано в среде сетевых услуг при взаимодействии с главной вычислительной машиной, в которую включены очень небольшие или минимальные ресурсы клиента, например, в сетевой среде, в которой устройство-клиент служит только в виде браузера (программы просмотра Web-страниц) или интерфейса с всемирной паутиной WWW (собрание гипертекстовых и иных документов, доступных по всему миру через сеть Internet).

Хотя это не является требованием, изобретение может быть реализовано через программный интерфейс приложений API (набор функций, предоставляемый некоторой программой) для использования разработчиком и/или включено в программное обеспечение просмотра сети, которое будет описано в основном контексте инструкций, выполнимых компьютером, таких как программные модули, выполняемые одним или большим количеством компьютеров, например рабочими станциями клиента, серверами или другими устройствами. По существу, программные модули включают в себя процедуры, программы, объекты, компоненты, структуры данных и т.д., выполняющие конкретные задачи или реализующие определенные абстрактные типы данных. По существу, функциональность программных модулей может быть скомбинирована или распределена согласно требованиям различных вариантов осуществления. Кроме того, для знающих технику очевидно, что изобретение может быть практически осуществлено в системах компьютеров с другими системными конфигурациями. Для использования в связи с настоящим изобретением подходят другие известные вычислительные системы, среды и/или конфигурации, например, персональные компьютеры (PC), банкоматы, компьютеры-серверы, переносные и портативные устройства, многопроцессорные системы, системы, основанные на микропроцессорах, программируемая бытовая электроника, сетевые PC, миникомпьютеры, универсальные компьютеры и т.д. Изобретение также может быть практически осуществлено в распределенной вычислительной среде, где задачи выполняются удаленными устройствами обработки, связанными посредством сети связи или другой среды передачи данных. В распределенной вычислительной среде программные модули могут быть размещены в запоминающих средах локальных и удаленных компьютеров, включая запоминающие устройства.

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

Согласно фиг.1 возможная система для реализации изобретения содержит универсальное вычислительное устройство в виде компьютера 110. Компоненты компьютера 110 могут содержать, в частности, процессор 120, системную память 130 и системную шину 121, соединяющую различные компоненты системы, включая системную память, с процессором 120. Системной шиной 121 может быть любой из нескольких типов структур шины, включая шину памяти или контроллер памяти, периферийную шину и локальную шину, использующую любую из многих архитектур шины. В качестве примера, такие архитектуры включают шину ISA архитектуры, соответствующей промышленному стандарту (АПС), шину MCA микроканальной архитектуры (МКА), шину EISA расширенной стандартной архитектуры для промышленного применения (РАПС), локальную шину VESA Ассоциации по стандартам в области видеоэлектроники (АСВЭ), и 32-разрядную системную шину PCI с возможностью расширения до 64 разрядов, взаимодействие через которую происходит без участия центрального процессора (также известную, как шина Mezzanine) и т.д.

Компьютер 110 обычно содержит несколько носителей информации, считываемых компьютером. Носитель информации, считываемый компьютером, может быть любым доступным носителем информации, к которому может осуществить доступ компьютер 110, и включает в себя энергозависимый и энергонезависимый носитель информации, съемный и несъемный носитель информации. В качестве возможного варианта, носитель информации, считываемый компьютером, может включать носитель информации компьютера, средство связи и т.д. Носитель информации компьютера включает в себя энергозависимый и энергонезависимый, съемный и несъемный носитель информации, реализованный любым способом или технологией для хранения информации, такой как инструкции, считываемые компьютером, структуры данных, программные модули или другие данные. Носитель информации компьютера включает в себя, в частности, оперативное запоминающее устройство RAM (ОЗУ), постоянное запоминающее устройство ROM (ПЗУ), EEPROM (СППЗУ), флэш-память или память, использующую другую технологию, компакт-диск CD-ROM, универсальные цифровые диски DVD (УЦД) или другой оптический накопитель на дисках, магнитные кассеты, магнитную ленту, магнитный накопитель на дисках или другие магнитные запоминающие устройства или любое другое средство, которое может использоваться для хранения необходимой информации и к которому может осуществить доступ компьютер 110. Средство связи обычно воплощает инструкции, считываемые компьютером, структуры данных, программные модули или другие данные в модулированном сигнале данных, например несущей или другом механизме переноса информации, и включает в себя любое средство доставки информации. Термин «модулированный сигнал данных» означает сигнал, который имеет одну или большее количество из набора его характеристик, или измененный таким образом, чтобы кодировать информацию в сигнале. В качестве возможного варианта, средство связи включает в себя проводное средство, такое как проводная сеть или прямое кабельное соединение, и беспроводное средство, такое как акустическое, радио, инфракрасное и другое беспроводное средство и т.д. Комбинации любых упомянутых выше средств также должны быть включены в контекст носителей информации, считываемых компьютером.

Системная память 130 включает в себя носитель информации компьютера в виде энергозависимой и/или энергонезависимой памяти, например ПЗУ 131 и ОЗУ 132. Базовая система 133 ввода/вывода BIOS (БИОС), содержащая базовые процедуры, способствующие передаче информации между элементами внутри компьютера 110, например, используемые при запуске, в основном, хранится в ПЗУ 131. ОЗУ 132, в основном содержит данные и/или программные модули, к которым можно осуществить доступ немедленно и/или с которыми в текущее время оперирует процессор 120. В качестве возможного варианта фиг.1 изображает операционную систему 134, прикладные программы 135, другие программные модули 136 и данные 137 программы.

Компьютер 110 также может содержать другие съемные/несъемные, энергозависимые/энергонезависимые носители информации компьютера. Исключительно в качестве возможного варианта фиг.1 изображает накопитель 141 на жестких дисках, осуществляющий считывание с несъемного, энергонезависимого магнитного носителя информации или запись на него, накопитель 151 на магнитных дисках, который осуществляет считывание со съемного энергонезависимого магнитного диска 152 или запись на него, и накопитель 155 на оптических дисках, который осуществляет считывание со съемного энергонезависимого оптического диска 156, например, компакт-диска или другого оптического носителя информации, или запись на него. Другие съемные/несъемные, энергозависимые/энергонезависимые носители информации компьютера, которые могут быть использованы в возможной операционной среде, включают в себя кассеты на магнитной ленте, карточки флэш-памяти, универсальные цифровые диски, цифровую видеомагнитофонную ленту, твердотельное ОЗУ, твердотельное ПЗУ и т.д. Накопитель 141 на жестких дисках, в основном, подсоединен к системной шине 121 посредством интерфейса несъемной памяти, например интерфейса 140, а накопитель 151 на магнитных дисках и накопитель 155 на оптических дисках, в основном подсоединен к системной шине 121 посредством интерфейса съемной памяти, например, интерфейса 150.

Накопители на дисках и соответствующие им носители информации компьютера, описанные выше и изображенные на фиг.1, обеспечивают хранение инструкций, считываемых компьютером, структур данных, программных модулей и других данных для компьютера 110. Например, на фиг.1 накопитель 141 на жестких дисках изображен как хранящий операционную систему 144, прикладные программы 145, другие программные модули 146 и данные 147 программы. Следует отметить, что указанные компоненты могут быть идентичными операционной системе 134, прикладным программам 135, другим программным модулям 136 и данным 137 программы или отличаться от них. Здесь операционной системе 144, прикладным программам 145, другим программным модулям 146 и данным 147 программы даны другие ссылочные позиции для пояснения, что, как минимум, они являются другими копиями. Пользователь может осуществлять ввод инструкций и информации в компьютер 110 посредством устройств ввода, таких как клавиатура 162 и указательное устройство 161, обычно определяемое как мышь, шаровой указатель или сенсорная панель. В число других устройств ввода (не изображены) могут входить микрофон, джойстик, игровая панель, спутниковая антенна, сканер и т.д. Часто эти и другие устройства ввода соединены с процессором 120 посредством интерфейса 160 пользователя, подсоединенного к системной шине 121, но они могут быть соединены с процессором посредством другого интерфейса и другими структурами шины, такими как параллельный порт, игровой порт или универсальная последовательная шина USB (УПШ).

К системной шине 121 также посредством интерфейса, вида видеоинтерфейса 190 подсоединен монитор 191 или другой вид устройства отображения. К системной шине 121 также может быть подсоединен графический интерфейс 182, например Northbridge (Северный мост). Northbridge является набором микросхем, связанных с центральным процессором CPU или процессором главной вычислительной машины 120, и отвечает за связь с ускоренным графическим портом AGP (УГП). С графическим интерфейсом 182 может взаимодействовать один или большее количество графических процессоров 184 GPU (ГП). В этом смысле графические процессоры GPU 184, в основном, содержат внутриканальную память, такую как регистровый класс памяти, и связаны с видеопамятью 186. Однако графические процессоры 184 GPU являются одним возможным вариантом сопроцессора и, следовательно, компьютер 110 может содержать разные устройства совместной обработки данных. Также к системной шине 121 подсоединен монитор 191 или другой вид устройства отображения посредством интерфейса, вида видеоинтерфейса 190, в свою очередь связанный с видеопамятью 186. В дополнение к монитору 191 компьютеры могут также содержать другие периферийные устройства вывода, например динамики 197 и принтер 196, которые могут быть подсоединены посредством периферийного интерфейса 195 вывода.

Компьютер 110 может функционировать в среде с сетевой структурой, используя логические соединения с одним или большим количеством удаленных компьютеров, например удаленным компьютером 180. Удаленный компьютер 180 может быть персональным компьютером, сервером, маршрутизатором, сетевым персональным компьютером, одноранговым устройством или другим узлом общей сети, и обычно содержит многие или все элементы, описанные выше в отношении компьютера 110, хотя фиг.1 изображает только запоминающее устройство 181. Логические соединения, указанные фиг.1, включают в себя локальную сеть связи LAN (ЛС) 171 и глобальную сеть связи WAN (ГС) 173, но могут также включать другие сети связи. Такие сетевые среды часто используются в офисах, корпоративных вычислительных сетях, сетях интранет (корпоративных локальных сетях повышенной надежности с ограниченным доступом) и Интернете.

При использовании в сетевой среде ЛС компьютер 110 соединяется с ЛС 171 посредством сетевого интерфейса или адаптера 170. При использовании в сетевой среде ГС компьютер 110 обычно содержит модем 172 или другое средство для установления связи через ГС 173, например Интернет. Модем 172, который может быть внутренним или внешним, может быть подсоединен к системной шине 121 посредством интерфейса 160 пользователя для ввода или другого соответствующего механизма. В среде с сетевой структурой программные модули, указанные в отношении компьютера 110, или их части, могут храниться в удаленном запоминающем устройстве. В качестве возможного варианта фиг.1 изображает удаленные прикладные программы 185, как размещенные на запоминающем устройстве 181. Ясно, что изображенные сетевые соединения являются возможным вариантом и могут быть использованы другие средства установления линии связи между компьютерами.

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

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

Фиг.2 обеспечивает схематическое представление возможной вычислительной среды с сетевой структурой или распределенной вычислительной среды. Распределенная вычислительная среда содержит вычислительные объекты 10a, 10b и т.д. и вычислительные объекты или устройства 110a, 110b, 110c и т.д. Эти объекты могут содержать программы, способы, информационные хранилища, программируемую логику и т.д. Объекты могут содержать части таких же или других устройств, как персональные цифровые ассистенты PDA, телевизоры, MP3-плееры, персональные компьютеры и т.д. Каждый объект может осуществлять связь с другим объектом посредством сети 14 связи. Сеть связи сама может содержать другие вычислительные объекты и вычислительные устройства, обеспечивающие услуги для системы фиг.2. Согласно аспекту изобретения каждый объект 10 или 110 может содержать приложение, для которого могут требоваться способы аутентификации настоящего изобретения для конвейера(ов) для выполнения графических операций на доверительных отношениях.

Следует также отметить, что объект, например 110c, может быть назначен ведущим узлом на другом вычислительном устройстве 10 или 110. Следовательно, хотя изображенная физическая среда может изображать присоединенные устройства в виде компьютеров, такая иллюстрация является просто возможным вариантом, и физическая среда в другом варианте может быть изображена или описана содержащей разные цифровые устройства, такие как PDA, телевизоры, MP3-плееры и т.д., объекты программного обеспечения в виде интерфейсов, COM-объектов и т.д.

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

В домашних сетевых средах существует по меньшей мере четыре неравноправных сетевых средства передачи информации, каждое из которых может поддерживать уникальный протокол, такие как линия питания, средство передачи данных (радиосвязь и проводная связь), средство передачи речи (например, телефон) и средство передачи развлекательной информации. Большинство домашних устройств управления, например выключателей света и электроприборов, для соединения могут использовать линию питания. Услуги передачи данных могут поступать в дом в виде широкополосной сети (например, DSL (цифровая абонентская линия) или Кабельный модем) и доступны посредством использования радиосвязи (например, HomeRF или 802.11b) или проводной связи (например, Home PNA, Cat5, линия питания). Речевой трафик может поступать в дом в виде проводной связи (например, Cat3) или радиосвязи (например, сотовые телефоны) и может распределяться внутри дома с использованием проводки Cat3. Средства передачи развлекательной информации могут проникать в дом через спутник или кабель и обычно распределяются по дому с использованием коаксиального кабеля. Также обнаруживаются IEEE 1394 и DVI в виде цифровой связи для кластеров устройств хранения данных. Все указанные и другие сетевые среды, которые могут обнаруживаться как стандарты протоколов, могут быть взаимосвязаны для формирования интранет, которая может быть соединена с внешним миром посредством Интернета. Короче говоря, существует несколько неравноправных источников для хранения и передачи данных и, следовательно, для вычислительных устройств требуются способы защиты содержимого во всех частях конвейера обработки данных.

'Интернет' обычно относится к совокупности сетей и шлюзов, использующих набор протоколов TCP/IP, которые известны в области техники, относящейся к работе в вычислительной сети. TCP/IP является акронимом для «Протокола Управления Передачей / Программы Интерфейса». Интернет может быть описан как система территориально распределенных удаленных вычислительных сетей, соединяемых компьютерами, выполняющими сетевые протоколы, обеспечивающие возможность взаимодействия пользователей и совместного использования ими информации через сети. Из-за такого широко разнесенного совместного использования информации удаленные сети, такие как Интернет, до текущего момента, в основном, развертывались в открытую систему, для которой разработчики могут, по существу, без ограничения разрабатывать программные приложения для выполнения специализированных операций или услуг.

Следовательно, сетевая инфраструктура обеспечивает возможность возлагать функции ведущего узла на какой-либо элемент для топологии сети, такой как клиент/сервер, одноранговой архитектуры или гибридной архитектуры. «Клиент» является элементом класса или группы, которая использует услуги другого класса, или группы, к которой он не относится. Следовательно, при вычислении клиент является процессом, то есть ориентировочно набором инструкций или задач, запрашивающих услуги, обеспечиваемые другой программой. Клиент-процесс (обслуживаемый процесс) использует запрошенные услуги без необходимости «получения информации» о каких-либо подробностях работы другой программы или непосредственно услуги. В архитектуре клиент/сервер, в частности в системе с сетевой структурой клиент обычно является компьютером, имеющим доступ к совместно используемым сетевым ресурсам, обеспечиваемым другим компьютером, например сервером. В возможном варианте фиг.2 компьютеры 110a, 110b и т.д. можно рассматривать как клиентов, а компьютеры 10a, 10b и т.д. можно рассматривать как сервера, где сервера 10a, 10b и т.д. поддерживают данные, которые затем копируются в компьютеры-клиенты 110a, 110b и т.д.

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

Клиент и сервер осуществляют связь друг с другом, используя функциональные возможности, обеспечиваемые уровнем протокола. Например, Протокол Передачи Гипертекстовых Файлов (HTTP) является общим протоколом, используемым совместно с Всемирной Паутиной (WWW). Обычно для взаимной идентификации компьютеров-клиентов и компьютеров-серверов используется адрес вычислительной сети вида Унифицированного Указателя Информационного Ресурса (URL) или адреса Интернет-протокола (IP). Сетевой адрес может быть определен как Унифицированный Указатель Информационного Ресурса (URL). Например, связь может быть обеспечена посредством среды связи. В частности, для связи с высокой пропускной способностью канала клиент и сервер могут быть соединены друг с другом через соединения TCP/IP.

Следовательно, фиг.2 иллюстрирует возможную среду с сетевой структурой или распределенную среду, в которой может быть использовано настоящее изобретение, с сервером, связанным с компьютерами-клиентами посредством сети связи/шины. Более подробно согласно настоящему изобретению несколько серверов 10a, 10b и т.д. связаны посредством сети 14 связи/шины, которой может быть LAN, WAN, интранет, Интернет и т.д. с несколькими клиентами или удаленными вычислительными устройствами 110a, 110b, 110c, 110d, 110e и т.д., такими как портативный компьютер, переносной компьютер, тонкий клиент, сетевое устройство или другое устройство, например кассетный видеомагнитофон VCR, телевизор TV, термостат, индикатор, нагреватель и т.д. Следовательно, предполагается, что настоящее изобретение можно применить к любому вычислительному устройству, в отношении которого требуется обработать, сохранить или воспроизвести защищенное содержимое из достоверного источника.

В сетевой среде, в которой сетью 14 связи/шиной является, например, Интернет, серверами 10 могут быть Web-сервера, с которыми связаны клиенты 110a, 110b, 110c, 110d, 110e и т.д. посредством любого из нескольких известных протоколов, таких как HTTP. Сервера 10 также могут служить в качестве клиентов 110, что может быть характерно для распределенной вычислительной среды. Связь может быть проводной или беспроводной, где это целесообразно. Устройства-клиенты 110 могут осуществлять или не осуществлять связь посредством сети 14 связи/шины и могут иметь к тому же соответствующую автономную связь. Например, в случае TV или VCR, для их управления может существовать или не существовать аспект сетевой структуры. Каждый компьютер-клиент 110 и компьютер-сервер 10 могут быть оснащены разными модулями прикладной программы или объектами 135 и соединениями или доступом к различным видам элементов хранения информации или объектам, в которых могут храниться файлы или в которые может загружаться или переноситься часть(и) файлов. Следовательно, настоящее изобретение может использоваться в среде вычислительной сети, имеющей компьютеры-клиенты 110a, 110b и т.д., которые обеспечены возможностью доступа и связи с вычислительной сетью/шиной 14 и компьютерами-серверами 10a, 10b и т.д., которые могут осуществлять связь с компьютерами-клиентами 110a, 110b и т.д. и другими устройствами 111 и базами данных 20.

Общее представление об Управлении Правами на Цифровое содержимое (DRM)

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

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

Однако после того, как произошло распределение, владелец содержимого обладает очень небольшим контролем над цифровым содержимым 12, если обладает вообще. В то же время DRM-система 10 обеспечивает возможность управляемого воспроизведения или проигрывания произвольных видов цифрового содержимого 12, причем такое управление является гибким и определяется владельцем содержимого цифрового содержимого. Обычно содержимое 12 распределяется пользователю в виде пакета 13 через любой соответствующий канал распределения. Пакет 13 цифрового содержимого при распределении может содержать цифровое содержимое 12, шифрованное симметричным ключом шифрования/расшифровки (KD) (то есть (KD(CONTENT))), а также другую информацию, идентифицирующую содержимое, относительно способа приобретения лицензии на содержимое и т.д.

DRM система 10, основанная на доверительных отношениях, обеспечивает возможность владельцу цифрового содержимого 12 определить правила лицензии, которые должны быть удовлетворены прежде, чем разрешается воспроизведение цифрового содержимого 12 на вычислительном устройстве 14 пользователя. Правила лицензии могут содержать упомянутое выше временное требование и могут быть включены в цифровую лицензию или документ использования (далее по тексту 'лицензию') 16, которую должен получить пользователь/вычислительное устройство 14 пользователя (далее по тексту эти термины являются взаимозаменяемыми, если из контекста не следует иное) от владельца содержимого или его агента. Лицензия 16 также содержит ключ расшифровки (KD) для расшифровки цифрового содержимого, возможно шифрованного в соответствии с ключом, который расшифровывается вычислительным устройством пользователя.

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

Правомочный компонент 18 обычно имеет блок 20 оценки лицензии, который определяет, является ли лицензия 16 действительной, просматривает правила и требования в действительной лицензии 16 и определяет на основе просмотра правил и требований в лицензии, имеет ли запрашивающий пользователь право осуществлять воспроизведение запрошенного цифрового содержимого 12, и т.д. Должно быть понятно, что блоку 20 оценки лицензии в DRM-системе 10 доверяется выполнение требований владельца цифрового содержимого 12 в соответствии с правилами и требованиями в лицензии 16, и пользователь не должен иметь возможности в своих целях просто изменить такой правомочный элемент.

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

Правила и требования могут быть определены в лицензии 16 в соответствии с любым соответствующим языком и синтаксисом. Например, язык может просто определять параметры и значения, которые должны быть удовлетворены (например, дата DATE должна быть после X), или может требовать выполнения функций в соответствии с определенным сценарием (например, Если DATE Больше X, То ...).

После определения блоком 20 оценки лицензии, что лицензия 16 является действительной и что пользователь удовлетворяет находящиеся в ней правила и требования, может быть осуществлено воспроизведение цифрового содержимого 12. В частности, для воспроизведения содержимого 12 из лицензии 16 получается ключ расшифровки (KD) и применяется к (KD(CONTENT)) из пакета 13 содержимого для получения в результате фактического содержимого 12 и затем действительно воспроизводится фактическое содержимое 12.

Публикация цифрового содержимого.

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

В частности, для публикации защищенного цифрового содержимого используются три объекта: приложение 302 подготовки содержимого, выполняемое на клиенте 300 и подготавливающее содержимое к публикации, программный интерфейс 306 приложений (API) управления правами на цифровое содержимое (DRM), также резидентно размещенный на устройстве-клиенте 300, и DRM-сервер 320, соединенный посредством связи с клиентом 300 через сеть 330 связи, например Интернет, локальную или глобальную сеть связи, или их комбинацию.

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

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

API 306 клиента передает шифрованное цифровое содержимое и данные прав на DRM-сервер 320. Используя процесс, подробно описанный ниже, DRM-сервер 320 определяет, может ли он обеспечить принудительное выполнение указанных данных прав, и если может, то подписывает данные прав для формирования подписанной метки 308 прав (SRL). Однако, в основном, любой правомочный объект может подписать данные прав, предпочтительно используя ключ, доверенный DRM-сервером 320. Например, клиент может подписать данные прав с использованием ключа, обеспеченного ему DRM-сервером 320.

Метка 308 прав может включать данные, представляющие описание прав, ключ шифрованного содержимого и цифровую подпись, следующую за описанием прав и ключом шифрованного содержимого. Если DRM-сервер 320 подписывает метку прав, то он передает подписанную метку 308 прав обратно клиенту через API 306 клиента, который сохраняет подписанную метку 308 прав на устройстве-клиенте 300. Затем приложение 302 подготовки содержимого сопоставляет подписанную метку 308 прав файлу 304 шифрованного цифрового содержимого, например посредством соединения, для формирования файла 310 содержимого с управляемыми правами. Тем не менее следует отметить, что SRL 308 может быть сохранена в известном местоположении, отдельном от файла 304 содержимого со ссылкой на SRL 308, соединяемую с файлом 304 содержимого, для формирования файла 310 содержимого.

Фиг.4 показан один способ публикации цифрового содержимого с управляемыми правами. На этапе 402 приложение 302 формирует ключ содержимого (CK), который используется для шифрования цифрового содержимого. Ключ содержимого (CK) обычно является симметричным ключом, хотя для шифрования цифрового содержимого может использоваться любой ключ. Как известно, симметричный ключ применяется алгоритмом с использованием симметричного ключа для шифрования и расшифровки. Соответственно при совместном использовании отправителем и получателем (CK) должен быть хорошо скрыт. На этапе 404 приложение 302 шифрует цифровое содержимое с использованием (CK) для формирования шифрованного цифрового содержимого 304 (то есть (CK(CONTENT))). Дополнительно, средством публикации содержимого или другим объектом формируются данные прав, соответствующие (CK(CONTENT)). Следует отметить, что данные прав могут быть созданными данными прав или данными прав, полученными из предварительно определенного шаблона. Как описано выше, данные прав могут включать список объектов, которым будет дано право использовать содержимое, определенные права, которыми обладает каждый из объектов в отношении содержимого, и любые условия, которые могут налагаться на указанные права.

На этапе 406 API 306 формирует второй ключ шифрования (K2), используемый для шифрования ключа содержимого (CK). Предпочтительно (K2) также является симметричным ключом. На этапе 408 API 306 шифрует (CK) с использованием (K2) для получения в результате (K2(CK)). На этапе 410 API 306 сбрасывает (CK), вследствие чего (CK) теперь может быть получен только посредством расшифровки (K2(CK)). Чтобы удостовериться, что (CK(CONTENT)) защищен центральным DRM-сервером 320 и все «лицензионные требования» на содержимое централизованы в соответствии с данными прав, API 306 на этапе 412 связывается с обеспеченным DRM-сервером 320 и восстанавливает его открытый ключ (PU-DRM). На этапе 414 API 306 шифрует (K2) с использованием (PU-DRM) для получения в результате (PU-DRM(K2)). Следовательно, (CK) может быть защищен (PU-DRM) для обеспечения DRM-сервера 320 в виде единственного объекта, обеспечивающего возможность получения доступа к (CK), необходимого для расшифровки (CK(CONTENT)). На этапе 416 API 306 шифрует данные прав (то есть, список объектов, обладающих правами, и соответствующих прав и условий, соответствующих каждому объекту в списке, обладающему правами) с использованием (K2) для получения в результате ключа данных прав (K2(rightsdata)).

В другом варианте осуществления (CK) может использоваться для непосредственного шифрования данных прав для получения в результате (CK(rightsdata)), а (PU-DRM) может использоваться для непосредственного шифрования (CK) для получения в результате (PU-DRM(CK)), вследствие этого использование (K2) полностью исключается. Однако использование (K2) для шифрования данных прав и (CK) обеспечивает возможность согласования (K2) с любым конкретным алгоритмом, который может подчиняться DRM-серверу, в то время как (CK) может быть определен объектом, независимым от DRM-сервера и может ему не подчиняться.

На этапе 418 приложение 302 защиты содержимого представляет (PU-DRM(K2)) и (K2(rightsdata)) DRM-серверу 320 в виде метки прав для подписания. В другом варианте непосредственно клиент может подписать данные прав способом, изложенным ниже. Если данные прав представляются для подписания серверу, то на этапе 420 DRM-сервер 320 осуществляет доступ к данным прав и проверяет, что он может обеспечить принудительное выполнение прав и условий из представленной метки прав. Для проверки возможности обеспечения принудительного выполнения указанного в данных прав, DRM-сервер 320 применяет секретный ключ (PR-DRM), соответствующий (PU-DRM), к (PU-DRM(K2)) для получения в результате (K2) и затем применяет (K2) к (K2(rightsdata)) для получения в результате данных прав в исходном виде. Затем сервер 320 может осуществить проверку любых стратегий, чтобы удостовериться, что пользователи, права и условия, определенные в данных прав, не выходят за рамки какой-либо стратегии, принудительное выполнение которой обеспечивается сервером 320. Сервер 320 подписывает представленную исходную метку прав, включающую (PU-DRM(K2)) и (K2(rightsdata)), для получения в результате подписанной метки 308 прав (SRL), где подпись основана на секретном ключе DRM-сервера 320 (PR-DRM), и возвращает SRL 308 обратно к API 306, который затем представляет возвращенную SRL 308 приложению 302 клиента.

SRL 308 является документом с цифровой подписью, которая делает его защищенным от несанкционированного вмешательства. Дополнительно, SRL 308 является независимой от действительного типа ключа и алгоритма, используемого для шифрования содержимого, но поддерживает строгую зависимость один к одному (1-1) в отношении содержимого, которое она защищает. В одном варианте осуществления настоящего изобретения согласно фиг.4A, SRL 308 может содержать информацию относительно содержимого, которая является основой SRL 308, включая, возможно, среди другой информации идентификатор ID содержимого; информацию о DRM-сервере, который подписывает SRL 308, включая (PU-DRM(K2)) и справочную информацию, такую как URL нахождения DRM-сервера в сети и информация о нейтрализации неисправности, если URL не исправен; информацию, описывающую непосредственно SRL 308; (K2(rightsdata)):(K2(CK)); и цифровую подпись (S(PR-DRM)). Убедившись, что правомочный объект подписывает данные прав для создания подписанной метки 308 прав, DRM-сервер 320 подтверждает, что он выдаст лицензии на содержимое в соответствии с условиями, установленными средством публикации, как описано в данных прав метки 308 прав. Должно быть ясно, что от пользователя требуется получение лицензии для воспроизведения содержимого, в основном, поскольку лицензия содержит ключ содержимого (CK). Когда пользователю требуется получить лицензию на шифрованное содержимое, он может представить запрос на лицензию, включающий SRL 308 для содержимого, и сертификат, подтверждающий мандат (учетную запись с параметрами доступа пользователя, сформированными после его успешной аутентификации) пользователя, в DRM-сервер 320 или другому объекту, выдающему лицензии. Затем объект, выдающий лицензии, может расшифровать (PU-DRM(K2)) и (K2(rightsdata)) для получения данных прав, составить список всех прав, предоставляемых автором (если такие имеются) объекту, запросившему лицензию, и создать лицензию, включающую только эти конкретные права.

Как изложено выше, при получении приложением 302 SRL 308 приложение 302 соединяет подписанную метку 308 прав с соответствующим (CK(CONTENT)) 304 для формирования цифрового содержимого с управляемыми правами. В другом варианте данные прав хранятся в известном местоположении со ссылкой на это местоположение, обеспечиваемой шифрованным цифровым содержимым. Следовательно, приложение воспроизведения, которое получает разрешение DRM, может обнаружить подписанную метку 308 прав через фрагмент содержимого, которое оно пытается воспроизвести. Обнаружение (метки) запускает инициализацию приложением воспроизведения запроса на лицензию к серверу 320 лицензирования DRM. Приложение 302 публикации, например, может хранить URL сервера 320 лицензирования DRM, или сервер 320 лицензирования DRM может внедрить свой URL в виде фрагмента метаданных в метку прав перед подписанием ее цифровой подписью, чтобы API 306 клиента DRM, вызываемый приложением воспроизведения, мог идентифицировать правильный сервер 320 лицензирования DRM.

Получение лицензии для опубликованного содержимого

Согласно фиг.5, описаны система и способ лицензирования цифрового содержимого с управляемыми правами. Термин «лицензирование» используется здесь в отношении процесса, который осуществляет приложение, или услуга для запроса и получения лицензии, обеспечивающей возможность объекту, названному в лицензии, использовать содержимое в соответствии с условиями, определенными в лицензии. Входные данные для процесса лицензирования могут включать подписанную метку 308 прав (SRL), соответствующую содержимому, для которого запрашивается лицензия, и сертификат(ы) открытого ключа объекта(ов), для которого запрашивается лицензия. Следует отметить, что объект, запрашивающий лицензию, не обязательно должен быть объектом, для которого запрашивается лицензия. Обычно лицензия включает описание прав из SRL 308, шифрованный ключ, который может расшифровать шифрованное содержимое, и цифровую подпись после описания прав и шифрованного ключа для подтверждения правомерности и предотвращения фальсификации.

Предварительно API 306 клиента направляет подписанную метку 308 прав содержимого 310 с управляемыми правами на DRM-сервер 320 через сеть 330 связи. Как описано выше, метка 308 прав включает ключ содержимого (CK), шифрованный в соответствии с открытым ключом DRM-сервера 320 (PU-DRM) (то есть (PU-DRM(CK))). Затем в процессе выдачи лицензии DRM-сервер 320 применяет (PR-DRM) к (PU-DRM(CK)) для получения (CK). Затем он использует открытый ключ (PU-ENTITY) в сертификате открытого ключа, который передан в запросе на лицензию, для повторного шифрования (CK) (то есть (PU-ENTITY(CK))). Затем заново шифрованный (PU-ENTITY(CK)) помещается в лицензию. Вследствие этого лицензия может быть возвращена вызывающей программе без риска раскрытия (CK), так как только держатель секретного ключа (PR-ENTITY), соответствующего (PU-ENTITY), может восстановить (CK) из (PU-ENTITY(CK)). Затем API 306 клиента использует (CK) для расшифровки шифрованного содержимого для формирования расшифрованного цифрового содержимого 312. Клиент-приложение 302 может затем использовать расшифрованное цифровое содержимое 312 в соответствии с правами, обеспеченными лицензией.

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

Согласно Фиг.6A и 6B, описан способ лицензирования цифрового содержимого с управляемыми правами. На этапе 602 объект, выдающий лицензию, например DRM-сервер 320 получает запрос на лицензию, включающий сертификат открытого ключа или идентификатор для каждого из одного или большего количества лицензиатов. Предположительно, если определен идентификатор, то DRM-сервер 320 может заказать соответствующий сертификат открытого ключа из каталога, базы данных и т.д. Если лицензия запрашивается только для одного лицензиата, то указывается только один сертификат или идентификатор. Если лицензия запрашивается для нескольких лицензиатов, то может быть указан сертификат или идентификатор для каждого потенциального лицензиата. На этапе 604, если требуется, аутентифицируется запрашивающий объект (то есть объект, делающий запрос на лицензию). На этапе 606, опять же, если требуется, определяется, разрешено ли объекту запрашивать лицензию.

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

Подразумевается, что DRM-сервер 320 имеет сертификат открытого ключа по меньшей мере для одного потенциального лицензиата, затем на этапе 616 DRM-сервер 320 проверяет достоверность правомочности каждого сертификата лицензиата. Если достоверность не подтверждается, DRM-сервер 320 определяет, что эмитент (объект выдачи) сертификата лицензиата не находится в списке правомочных эмитентов, то запрос для этого лицензиата получает отказ, и на этапе 614 формируется информация об ошибке. Следовательно, любой потенциальный лицензиат, сертификат которого не выдан правомочным эмитентом, не может получить лицензию.

Дополнительно, DRM-сервер 320, предпочтительно, выполняет проверку достоверности цифровой подписи для всех объектов в цепочке сертификатов от сертификатов правомочных эмитентов до сертификатов открытого ключа индивидуального лицензиата. Процесс проверки достоверности цифровых подписей в цепочке является известным алгоритмом. Если достоверность сертификата открытого ключа для данного потенциального лицензиата не подтверждается, или достоверность сертификата из цепочки не подтверждается, то потенциальный лицензиат не является правомочным и, следовательно, такому потенциальному лицензиату лицензия не выдается. Иначе на этапе 618 может быть выдана лицензия. На этапе 620 процесс повторяется, пока не будут обработаны все объекты, для которых была запрошена лицензия.

Согласно фиг.6B, DRM-сервер 320 переходит к проверке достоверности подписанной метки 308 прав, полученной в запросе на лицензию. В одном варианте осуществления DRM-сервер 320 имеет эталон каждой подписанной им метки прав. Затем, во время (обработки) лицензии (на этапе 622), DRM-сервер 320 может восстановить эталон метки прав. Эталон метки прав может быть более новым, чем копия метки прав, переданная в запросе на лицензию и, следовательно, будет являться меткой прав, используемой для создания запрошенной лицензии. Если эталон метки прав не найден, то DRM-сервер 320 на этапе 624 определяет в соответствии с предварительно определенной стратегией, выдать ли лицензию на основе метки прав, находящейся в запросе. Если стратегия не обеспечивает такой возможности, то запрос на лицензию получает отказ на этапе 626 и к API 306 на этапе 628 возвращается информация об ошибке.

На этапе 630 DRM-сервер 320 проверяет достоверность SRL 308 и особенно ее цифровую подпись. Если достоверность SRL 308 не подтверждена, то запрос на лицензию получает отказ на этапе 626, и к API 306 на этапе 628 возвращается информация об ошибке.

После проведения всех проверок достоверности DRM-сервер создает лицензию для каждой утвержденной лицензии на основе SRL 308. На этапе 632 DRM-сервер 320 формирует соответствующее описание прав для лицензии, которая будет выдана каждому лицензиату. Для каждого лицензиата DRM-сервер 320 оценивает идентификатор, указанный в сертификате открытого ключа этого лицензиата относительно идентификаторов, указанных в описании прав в метке прав. На этапе 636 DRM-сервер 320 получает (PU-DRM(K2)) и (K2(CK)) из SRL 308 и применяет (PR-DRM) для получения (CK). Затем выдающий объект повторно шифрует (CK) с использованием (PU-ENTITY) из сертификата открытого ключа лицензиата для получения в результате (PU-ENTITY(CK)). На этапе 638 DRM-сервер 320 соединяет сформированное описание прав с (PU-ENTITY(CK)) и подписывает цифровой подписью полученную в результате структуру данных с использованием (PR-DRM) (то есть, S(PR-DRM)). Следовательно, подписанная структура данных является лицензией для данного конкретного лицензиата. На этапе 640 DRM-сервер 320 определяет, что больше нет лицензий, которые следует сформировать по данному конкретному запросу. Затем на этапе 642 сформированные лицензии возвращаются к запрашивающему объекту вместе с соответствующей цепочкой сертификатов, которая привязывает лицензии обратно к правомочному авторитетному источнику.

Самостоятельная публикация подписанной метки 308 прав SRL

В одном варианте осуществления настоящего изобретения SRL 308 может быть подписана непосредственно запрашивающим/публикующим пользователем. Соответственно, такому пользователю не требуется связываться с DRM-сервером 320 для получения SRL 308 для соответствующего фрагмента содержимого. В результате самостоятельная публикация также может быть определена как автономная публикация. В таком варианте осуществления публикующий пользователь должен быть также обеспечен возможностью выдать себе лицензию на средство публикации, в основном, поскольку самостоятельно опубликованное содержимое теперь является DRM-защищенным, и от лицензии на средство публикации требуется разрешение для публикующего пользователя на воспроизведение защищенного содержимого. Также должно быть понятно, что публикующий пользователь может быть обеспечен возможностью выдавать лицензии другим пользователям.

В частности, в варианте осуществления согласно фиг.7 автономный публикующий пользователь, во-первых, обеспечивается возможностью автономной публикации, получая от DRM-сервера 320 сертификат 810 автономной публикации (OLP), включающий открытый ключ (PU-OLP) и соответствующий секретный ключ (PR-OLP), шифрованный в соответствии с открытым ключом (PU-ENTITY), непосредственно или опосредованно доступным для правомочного компонента 18 (фиг.11) пользователя, для получения в результате (PU-ENTITY(PR-CERT)). Следует отметить, что (PU-ENTITY), например, может быть открытым ключом правомочного компонента 18 или открытым ключом пользователя, который является доступным посредством открытого ключа правомочного компонента 18. Сертификат 810 OLP должен быть подписан секретным ключом DRM-сервера 320 (PR-DRM), чтобы DRM-сервер 320 мог осуществлять проверку сертификата OLP, как будет подробно описано ниже.

Дополнительно, сертификат 810 OLP должно включать цепочку сертификатов от (PU-DRM) обратно к правомочному авторитетному источнику, который находится в доверительных отношениях с правомочным компонентом 18 публикующего пользователя или другого пользователя для того, чтобы правомочный компонент 18 мог осуществлять проверку сертификата 810 OLP и любых других сертификатов или лицензий, связанных с сертификатом 810 OLP, как будет описано ниже. Вкратце, должно быть понятно, что цепочка сертификатов начинается с корневого сертификата, подписанного секретным ключом правомочного авторитетного источника и имеющего открытый ключ следующего сертификата в цепочке. Затем, каждый промежуточный сертификат в цепочке подписан секретным ключом, соответствующим открытому ключу предыдущего сертификата в цепочке, и имеет открытый ключ следующего сертификата в цепочке. В заключение, сертификат или лицензия, к которым присоединена цепочка, подписаны секретным ключом, соответствующим открытому ключу последнего сертификата в цепочке. Следовательно, для проверки сертификата или лицензии, к которым присоединена цепочка, получается информация относительно открытого ключа, соответствующего секретному ключу правомочного авторитетного источника, и этот открытый ключ правомочного авторитетного источника используется для проверки подписи корневого сертификата в цепочке. Предполагается, что подпись корневого сертификата проверена, затем из корневого сертификата получается открытый ключ и используется для проверки подписи первого промежуточного сертификата в цепочке. Процесс повторяется последовательно по цепочке, пока в ней не будет проверена каждая подпись, и затем получается открытый ключ последнего промежуточного сертификата в цепочке, который используется для проверки подписи сертификата или лицензии, к которой присоединена цепочка.

Должно быть понятно, что сертификат 810 OLP создает линию доверительных отношений в цепочке между содержимым 304, которое должно публиковаться автономно, и DRM-сервером 320, который должен выдавать лицензию для содержимого 304. Сертификат 810 OLP может быть создан на основе языка XML/XrML или любого другого соответствующего языка.

Также должно быть понятно, что сертификат 810 OLP и присоединенная цепочка сертификатов авторизуют публикующего пользователя для самостоятельной публикации. Дополнительно, должно быть понятно, что пара ключей (PU-OLP, PR-OLP) является независимой от (PU-ENTITY, PR-ENTITY) и используется специально для самостоятельной публикации. Следует отметить, что пара ключей (PU-OLP, PR-OLP) может быть распределена, в этом случае сертификат 810 DRM включает только открытый ключ пользователя (PU-ENTITY) и подписывается секретным ключом DRM-сервера 320 (PR-DRM), чтобы DRM-сервер 320 мог осуществлять его проверку.

Самостоятельная публикация отличается от публикации, иллюстрируемой фиг.4, тем, что пользователь, по существу, занимает место DRM-сервера 320 в отношении выполняемых этапов. Существенно, что пользователь подписывает представленную метку прав, включающую (PU-DRM(K2)) и (K2(rightsdata)) или включающую (PU-DRM(CK)) и (CK(rightsdata)) (последние изображены Фиг.7 и 8) с использованием (PR-OLP), полученного из сертификата 810 DRM (то есть S(PR-OLP)) для получения в результате подписанной метки 308 прав (SRL). Правомочный компонент 18 клиента при использовании сертификата 810 OLP обычно проверяет его на основе присоединенной цепочки сертификатов. Должно быть понятно, что правомочный компонент 18 пользователя получает (PR-OLP) из сертификата 810 OLP, получая из сертификата 810 OLP (PU-ENTITY(PR-OLP)) и применяя к нему (PR-ENTITY). Однако следует отметить, что публикующий пользователь не может проверить, что DRM-сервер 320 может обеспечить принудительное выполнение прав из самостоятельно опубликованной SRL 308. Соответственно, непосредственно DRM-сервер 320 должен выполнить такую проверку во время запроса на лицензию на основе самостоятельно опубликованной SRL 308.

После того, как публикующий пользователь самостоятельно публикует SRL 308, он присоединяет самостоятельно опубликованную SRL 308 и сертификат 810 OLP, использованный для ее создания, к содержимому 304, и содержимое 304 с SRL 308 и сертификатом 810 DRM распределяется другому пользователю в виде содержимого 310 с управляемыми правами. После этого другой пользователь запрашивает и получает лицензию на содержимое 304/310 из DRM-сервера 320, по существу, способом, идентичным изображенному фиг.6A и 6B. Тем не менее, здесь пользователь, запрашивающий лицензию, представляет DRM-серверу 320 и самостоятельно опубликованную SRL 308 и сертификат 810 OLP, присоединенные к содержимому 304. Затем DRM-сервер 320 проверяет S(PR-DRM) в сертификате 810 OLP на основе соответствующего (PU-DRM) и получает (PU-OLP) из сертификата 810 DRM. Затем DRM-сервер 320 проверяет S(PR-OLP) в SRL 308 на основе полученного (PU-CERT) и продолжает работу, как описано выше. Тем не менее, следует отметить, что, так как публикующий пользователь не проверял возможность обеспечения DRM-сервером 320 принудительного выполнения прав в SRL 308, как было изложено выше, проверку должен выполнить непосредственно DRM-сервер 320 в этот момент времени.

Следует отметить также, что DRM-серверу 320 требуется проверить только S(PR-DRM) в сертификате 810 OLP, так как, очевидно, что он находится в доверительных отношениях с самим собой. Соответственно, нет необходимости передавать DRM-серверу 320 вместе с сертификатом 810 OLP соответствующую цепочку сертификатов сертификата 810 OLP, если, конечно, цепочка не требуется по другим причинам, например, если цепочка непосредственно не является по меньшей мере частично основой для S(PR-DRM).

Тем не менее, является существенным, что публикующий пользователь должен быть обеспечен возможностью воспроизводить защищенное содержимое 304/310 без необходимости обращения к DRM-серверу 320 за лицензией. Иначе, публикующий пользователь, который автономно публикует содержимое 304/310, не обращаясь на DRM-сервер 320, на основе сертификата 810 OLP, должен быть обеспечен возможностью также автономно выдать себе лицензию, не обращаясь к DRM-серверу 320 для возможности воспроизведения пользователем автономно опубликованного содержимого 304/310. Соответственно, публикующий пользователь может продолжать работать с самостоятельно опубликованным содержимым 310 без какой-либо связи с DRM-сервером 320.

Следовательно, в одном варианте осуществления настоящего изобретения согласно фиг.8 публикующий пользователь выдает себе автономную лицензию 820 на средство публикации, подписанную (PR-OLP) основанную на самостоятельно опубликованной SRL 308 и включающую сертификат 810 OLP и его цепочку сертификатов. Предположительно, лицензия 820 на средство публикации предоставляет публикующему пользователю полный доступ к самостоятельно опубликованному содержимому 310, хотя может быть предоставлен менее полный доступ. Лицензия 820 на средство публикации может быть написана на языке XML/XrML или на другом языке, так же как другие лицензии DRM. Должно быть понятно, что лицензия 820 на средство публикации включает ключ содержимого (CK), шифрованный в соответствии с (PU-ENTITY), который может быть получен правомочным компонентом 18 вычислительного устройства 14 пользователя для формирования (PU-ENTITY(CK)).

Следовательно, цепочка для лицензии 820 на средство публикации идет от лицензии 820 до сертификата 810 OLP и затем обратно к корневому сертификату из правомочного авторитетного источника, возможно, посредством одного или большего количества промежуточных сертификатов. Так как правомочный компонент 18 пользователя, предположительно, может получить открытый ключ, соответствующий секретному ключу правомочного авторитетного источника, который был использован для подписания корневого сертификата, то правомочный компонент 18 может самостоятельно проверить лицензию 820 на средство публикации посредством ее цепочки сертификатов и затем после проверки может получить из нее (PU-ENTITY(CK)), применить к нему (PR-ENTITY) для получения (CK) и применить (CK) к (CK(content)) для получения в результате содержимого 304 для осуществления его воспроизведения. В результате публикующий пользователь может продолжать работать с содержимым 310, опубликованным им автономно, при этом оставаясь автономным.

Следовательно, в соответствии с описанным выше, публикующий пользователь автономно публикует содержимое 304/310 и выдает себе автономную лицензию 820 на средство публикации для содержимого 304/310 следующим способом согласно фиг.9.

Предположительно, что должно быть понятно, содержимое 304 разрабатывается соответствующим способом и шифруется в соответствии с ключом содержимого (CK) (этап 901), и публикующий пользователь создает метку прав для содержимого 304 с соответствующей информацией {например, (PU-DRM(CK)) и (CK(rightsdata))} (этап 903). После этого публикующий пользователь, который, предположительно, уже является потенциальным владельцем сертификата 810 OLP из DRM-сервера 320, получает сертификат 810 OLP (этап 905) и проверяет его на основе его подписи и цепочки сертификатов, ведущей обратно к корневому авторитетному источнику (этап 907). Должно быть понятно, что такая проверка фактически выполняется правомочным компонентом 18 на вычислительном устройстве 14 публикующего пользователя. Предполагается, что проверка была успешной, затем публикующий пользователь/правомочный компонент 18 (далее по тексту 'публикующий пользователь') восстанавливает (PU-ENTITY(PR-OLP)) из сертификата 810 OLP (этап 909), применяет (PR-ENTITY) к (PU-ENTITY(PR-OLP)) для получения (PR-OLP) (этап 911) и затем подписывает созданную метку прав с использованием (PR-OLP) для создания SRL 308 (этап 913).

После этого публикующий пользователь соединяет SRL 308 и сертификат 810 OLP, использованный для ее создания, к содержимому 304 для формирования самостоятельно опубликованного содержимого 310 (этап 915), и, следовательно, такое содержимое 310 с управляемыми правами может быть распределено другому пользователю. Однако для продолжения использования или воспроизведения содержимого 310 публикующим пользователем ему необходимо выдать себе соответствующую автономную лицензию 820 на средство публикации.

Вследствие этого публикующий пользователь создает лицензию 820 на средство публикации посредством определения для себя соответствующих данных прав и шифрования их в соответствии с ключом содержимого (CK) для получения в результате (CK(rightsdata)) (этап 917). Здесь следует отметить, что данные прав могут быть получены из SRL 308 из содержимого 310, возможен некоторый заданный по умолчанию набор данных прав, предоставляющий публикующему пользователю частичный или полный доступ к самостоятельно опубликованному содержимому 310, или данные прав могут быть получены из другого источника. Дополнительно, публикующий пользователь шифрует ключ содержимого (CK) в соответствии с (PU-ENTITY) для формирования (PU-ENTITY(CK)) (этап 919). Затем (CK(rightsdata)) и (PU-ENTITY(CK)) форматируются в лицензию 820 на средство публикации (этап 921), присоединяются сертификат 810 OLP и его цепочка сертификатов (этап 923), и лицензия 820 на средство публикации подписывается на основе (PR-OLP), полученного на этапе 911 (этап 925). Здесь следует отметить, что содержимое 304 (то есть (CK(CONTENT))), лицензия 820 на средство публикации, и сертификат OLP в комбинации формируют цепочку 830 цифровых элементов обратно к правомочному авторитетному источнику.

Согласно фиг.10, публикующему пользователю, чтобы воспроизвести опубликованное содержимое 310, не требуется связываться с DRM-сервером 320, взамен он получает открытый ключ, соответствующий секретному ключу правомочного авторитетного источника, который был использован для подписания корневого сертификата (этап 1001), проверяет корневой сертификат (этап 1003) и затем проверяет каждый промежуточный сертификат в цепочке (этап 1005) посредством получения для каждого промежуточного сертификата открытого ключа из предыдущего сертификата и использования его для проверки подписи промежуточного сертификата. После этого (PU-DRM) из последнего сертификата в цепочке используется для проверки подписи сертификата 810 OLP (то есть S(PR-DRM)) (этап 1007), из сертификата 810 OLP получается (PU-OLP) (этап 1009), и (PU-OLP) используется для проверки подписи лицензии 820 на средство публикации (то есть S(PR-OLP)) (этап 1010).

Если лицензия 820 на средство публикации проверена, то из нее восстанавливаются (CK(rightsdata)) и (PU-ENTITY(CK)) (этап 1011), (PR-ENTITY) применяется к (PU-ENTITY(CK)) для получения в результате (CK) (этап 1013), и (CK) применяется к (CK(rightsdata)) для получения в результате данных прав (этап 1015). Должно быть понятно, что данные прав просматриваются правомочным компонентом 18 вычислительного устройства 14, публикующего пользователя для определения, что данные прав обеспечивают возможность осуществления воспроизведения искомым способом (этап 1017), следовательно, правомочный компонент 18 применяет (CK) к (CK(content)) из содержимого 310 для получения в результате содержимого (этап 1019), и затем содержимое передается соответствующему приложению воспроизведения для действительного воспроизведения (этап 1021). Следовательно, этапы фиг.10 действительно прослеживают цепочку 830 цифровых элементов от правомочного авторитетного источника до содержимого 304.

Следует отметить, что правомочный компонент 18 может, предположительно, применить (CK) к (CK(content)) для получения в результате содержимого без первоначального просмотра данных прав и независимо от того, что разрешают или не разрешают данные прав, но содержимое становится доверительным и структурируется для действительного создания содержимого только после просмотра данных прав и их выполнения, где данные прав разрешают воспроизведение содержимого. Еще раз, в результате наличия лицензии 820 на средство публикации публикующий пользователь может продолжать работать с содержимым 310, опубликованным им автономно, при этом оставаясь автономным, поскольку нет необходимости в связи с DRM-сервером 320.

Регистрация документов и под-регистрация документов DRM-сервером

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

Например, согласно фиг.12, в отдельной организации может иметься один или большее количество DRM-серверов 320 уровня пользователя для подписания меток прав для создания меток 308 SRL, выдачи лицензий 16, предоставления лицензий на публикацию, выдачи сертификатов пользователям, выдачи сертификатов вычислительным устройствам 14 и т.д. Каждый DRM-сервер 320 уровня пользователя может быть назначен, например, на основе территориального принципа или на основе функции или нагрузки. Аналогично, для контроля за несколькими DRM-серверами 320 уровня пользователя организация может иметь один или большее количество административных DRM-серверов 320. Если это необходимо, DRM-серверы 320 на основе организации могут быть размещены после брандмауэра организации.

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

Критично, чтобы каждый DRM-сервер 320 в архитектуре фиг.12 был способен доказать, что он является правомочным. Следовательно, как должно быть понятно из описания цепочки сертификатов, каждый DRM-сервер 320 после вхождения в архитектуру обеспечивается сертификатом 1310 регистрации, как видно из фиг.13. Является существенным, как имеет место в одном варианте осуществления настоящего изобретения, что сертификат 1310 регистрации обеспечивается входящему DRM-серверу 320 (далее по тексту «DRM-E сервер 320») другим 'регистрирующим' DRM-сервером 320, уже существующим в архитектуре (далее по тексту «DRM-R сервер 320»). Также является существенным, что к сертификату 1310 регистрации, обеспечиваемому регистрирующим DRM-R сервером 320, присоединяется цепочка сертификатов 1320, включающая сертификат 1310 регистрации регистрирующего DRM-сервера 320, сертификат 1310 регистрации DRM-сервера 320, который зарегистрировал регистрирующий DRM-R сервер 320, и так далее обратно, вплоть до корневого DRM-сервера 320. Корневым DRM-сервером 320 может быть представлен корневой или правомочный авторитетный источник, или цепочка сертификатов 1320 может продолжаться дальше для достижения корневого или правомочного авторитетного источника. Как теперь должно быть понятно, сертификат 1310 регистрации и цепочка сертификатов 1320 в комбинации формируют цепочку сертификатов, присоединенных к сертификату 810 OLP, обеспечиваемому зарегистрированным или вошедшим DRM-E сервером 320 публикующему пользователю, например, как изображено фиг.8.

В одном варианте осуществления настоящего изобретения сертификат 1310 регистрации, обеспечиваемый DRM-R сервером 320 DRM-E серверу 320, имеет вид сертификата, основанного на XrML 1.2. Как может быть понятно, такой вид сертификата 1310 не представляется независимо какой-либо третьей стороной, и, следовательно, такой вид сертификата 1310 не представляет вид какого-либо независимого поручительства третьим лицом за держателя такого сертификата 1310.

В одном варианте осуществления настоящего изобретения способ регистрации конкретного DRM-E сервера 320 в архитектуре зависит от того, имеет ли регистрирующий DRM-R сервер 320 доверительную информацию или причину относиться доверительно к входящему DRM-E серверу 320. Если нет, то DRM-E серверу 320 требуется подтвердить DRM-R серверу 320 свою надежность и то, что он поддерживает DRM архитектуру. Если да, то от DRM-E сервера 320 не требуется подтверждение своей надежности для DRM-R сервера 320 по меньшей мере не в такой степени. Следовательно, DRM-R сервер 320, не имеющий информацию/не относящийся доверительно, 'регистрирует' DRM-E сервер 320, в то время, как DRM-R сервер 320, имеющий информацию/относящийся доверительно 'под-регистрирует' DRM-E сервер 320.

Обычно DRM-R сервер 320 имеет информацию/относится доверительно в отношении DRM-E сервера 320, если они оба эксплуатируются одной организацией или в интересах одной организации, хотя наличие информации/доверительное отношение может также являться результатом других ситуаций, не выходящих за рамки области настоящего изобретения. Следовательно, способ регистрации конкретного DRM-E сервера 320 в архитектуре обычно зависит от того, является ли регистрирующий DRM-R сервер 320 сервером на основе организации, или сервером не на основе организации. В результате DRM-R сервер 320 не на основе организации 'регистрирует' DRM-E сервер 320, в то время как DRM-R сервер 320 на основе организации 'под-регистрирует' DRM-E сервер 320.

Регистрация

В одном варианте осуществления настоящего изобретения согласно фиг.14, не имеющий информацию/не относящийся доверительно DRM-R сервер 320 регистрирует DRM-E сервер 320 следующим способом.

Предварительно, должно быть понятно, что DRM-E сервер 320, которому требуется зарегистрироваться DRM-R сервером 320, не имеющим информацию/не относящимся доверительно, вероятно, не известен DRM-R серверу 320. Соответственно, в одном варианте осуществления настоящего изобретения DRM-E сервер 320 должен заказать сертификат 1330 поручительства третьей стороны, согласной поручиться за DRM-E сервер 320 (этап 1401). Обычно для выполнения поручительства третьей стороной является независимый агент, выдающий сертификаты, находящийся в доверительных отношениях с DRM-R сервером 320, например VERISIGN Corporation of Montain view, Калифорния. Сертификат 1330 поручительства может иметь, например, вид сертификата, такого как X.509. Следует отметить, что в DRM-R сервере 320, основывающемся на поручительстве правомочной третьей стороны за DRM-E сервер 320, ответственность DRM-R сервера 320 за какие-либо неправильные действия DRM-E сервера 320 смягчена.

Должно быть понятно, и это является обычным, согласно фиг.13 сертификат 1330 поручительства включает в себя открытый ключ (PU-V) и соответствующий секретный ключ (PR-V), подписывается правомочной третьей стороной, и для проверки достоверности может сопровождаться цепочкой сертификатов, приводящей к известному корню. Также является обычным, что (PR-V) внутри сертификата 1330 поручительства защищен способом, доступным для «поручившегося за» DRM-E сервер 320, что является основой сертификата 1330 поручительства. Например, как видно из фиг.13, (PR-V) может быть шифрован в соответствии с соответствующим открытым ключом.

Внутри архитектуры DRM входящий DRM-E сервер 320 должен иметь уникальный идентификатор. Здесь должно быть понятно, что DRM-идентификатор, вероятно, отличен от (PU-V, PR-V), хотя DRM-идентификатор также может совпадать с (PU-V, PR-V), что не выходит за рамки области настоящего изобретения. Соответственно для установки такого идентификатора, DRM-E сервер 320 формирует или получает новую пару открытый ключ/секретный ключ (PU-E, PR-E) (этап 1403). Также, внутри архитектуры DRM DRM-E сервер 320 регистрации должен принять решение, какие объекты могут аннулировать участие своего авторитетного источника. Соответственно, DRM-E сервер 320 идентифицирует каждый аннулирующий объект в списке, возможно посредством его открытого ключа (этап 1405).

DRM-E сервер 320 должен иметь возможность доказать регистрирующему DRM-R серверу 320, что он действительно обладает сертификатом 1330 поручительства, полученным на этапе 1401. Соответственно, DRM-E сервер 320 использует (PR-V) из сертификата 1330 поручительства для шифрования (PU-E) для получения в результате (PR-V(PU-E)) в виде признака принадлежности или подписывает (PU-E) с использованием (PR-V) для получения в результате (PU-E)S(PR-V) в виде признака принадлежности (этап 1407). В любом случае использование (PU-V) для расшифровки (PU-E) или проверка подписи доказывает обладание (PR-V) и, следовательно, сертификатом 1330 поручительства. К текущему моменту DRM-E сервер 320 имеет сертификат 1330 поручительства, (PU-E) и (PR-E), список аннулирования авторитетного источника и (PR-V(PU-E)) или (PU-E)S(PR-V) в виде признака принадлежности. Затем DRM-E сервер 320 для запроса регистрации передает сертификат 1330 поручительства, (PU-E), список аннулирования авторитетного источника и (PR-V (PU-E)) или (PU-E)S(PR-V) в виде признака принадлежности на DRM-R сервер 320 (этап 1409), и DRM-R сервер 320 продолжает регистрировать запрашивающий DRM-E сервер 320. Следует отметить, что запрос или его часть может иметь вид сертификата, подписанного (PR-E).

В частности, DRM-R сервер 320 проверяет достоверность сертификата 1330 поручительства на основе его подписи правомочной третьей стороной и цепочки сертификатов, приводящей к известному корню (этап 1411). Следовательно, DRM-R сервер 320 устанавливает, что за DRM-E сервер 320 было поручительство. Также, DRM-R сервер 320 проверяет признак принадлежности, применяя (PU-V) из запроса для расшифровки (PU-E) или для проверки подписи и вследствие этого устанавливает обладание (PR-V) и, следовательно, сертификатом 1330 поручительства для запроса (этап 1410). Дополнительно, является существенным, что DRM-R сервер 320 выполняет любые заказные логические схемы, необходимые для принятия решения, следует ли удовлетворить запрос (этап 1413). Заказные логические схемы могут быть любыми соответствующими логическими схемами, что не выходит за рамки области настоящего изобретения, и могут, например, содержать фоновую проверку DRM-E сервера 320 и/или его оператора, определение того, имеет ли DRM-E сервер 320 действительный правомочный компонент 18 и/или операционную систему и т.д., определение того, не находится ли DRM-E сервер 320 в списке аннулирования или другом списке, за которым ведется наблюдение, и т.д.

Предполагается, что заказные логические схемы разрешают удовлетворить запрос, затем в одном варианте осуществления настоящего изобретения DRM-R сервер 320 формирует сертификат 1310 регистрации для DRM-E сервера 320 (этап 1415). В частности, как видно из фиг.13, DRM-R сервер 320 включает в сертификат 1310 регистрации:

идентификатор DRM-R сервера 320, например его открытый ключ (PU-R),

идентификатор DRM-E сервера 320, например (PU-E),

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

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

список аннулирования авторитетного источника,

подпись на основе секретного ключа DRM-R сервера 320 (PR-R), соответствующего (PU-R),

и любую другую соответствующую информацию.

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

Должно быть понятно, что при формировании сертификата 1310 регистрации, DRM-R сервер 320 первоначально может сформировать информацию сертификата и затем разрешить заказным логическим схемам сформировать дополнительную информацию или изменить существующую информацию. Заказные логические схемы могут, например, обеспечить включение в DRM-R сервер 320 соответствующей информации или предписать предварительно определенную стратегию архитектуры DRM. Безусловно, подпись сертификата 1310 регистрации создается после выполнения любых заказных логических схем. Также должно быть понятно, что DRM-R сервер 320 присоединяет цепочку сертификатов 1320, которая приводит обратно к правомочному корневому авторитетному источнику для сформированного сертификата 1310 регистрации, чтобы можно было подтвердить сформированный сертификат 1310 регистрации на основе цепочки сертификатов 1320. В частности, следует отметить, что идентифицирующий признак из сертификата 1330 поручительства, помещенный внутри сертификата 1310 регистрации, будет всегда перемещаться с сертификатом 1310 регистрации и действовать в виде моста к сертификату 1330 поручительства. Следовательно, вновь идентифицирующий признак везде является доказательством, что DRM-R сервер 320, давая поручительство за DRM-E сервер 320, основывается на эмитенте сертификата 1330 поручительства правомочной третьей стороны и ответственность DRM-R сервера 320 за любые неправильные действия DRM-E сервера 320 смягчена.

Затем после успешного формирования DRM-R сервером 320 сертификата 1310 регистрации с присоединенной цепочкой сертификатов 1320, DRM-R сервер 320 возвращает его на запрашивающий DRM-E сервер 320 (этап 1417), и вновь зарегистрированный DRM-E сервер 320 хранит его в соответствующем местоположении для дальнейшего использования (этап 1419). Как описано выше, (PU-E) в сертификате 1310 регистрации и соответствующий (PR-E) являются парой открытый ключ/секретный ключ, которую DRM-E сервер 320 будет использовать как (PU-DRM) и (PR-DRM) при подписании метки прав для создания SRL 308, выдачи сертификата 810 OLP и другого участия внутри архитектуры DRM. Соответственно, сертификат 1310 регистрации и цепочка сертификатов 1320 в комбинации формируют цепочку сертификатов, которые присоединяются к сертификату 810 OLP и т.д.

Под-регистрация

В одном варианте осуществления настоящего изобретения, согласно фиг.15 DRM-R сервер 320, имеющий информацию/относящийся доверительно к DRM-E серверу 320, под-регистрирует его следующим способом.

Должно быть понятно, что предварительно для DRM-E сервера 320, которому требуется быть под-зарегистрированным DRM-R сервером 320, имеющим информацию/относящимся доверительно, остается требование идентифицировать себя для DRM-R сервера 320, поскольку наличие информации или доверительное отношение не могут быть полными. Однако не требуется идентификация уровня представления правомочной третьей стороной, поскольку DRM-R сервер 320 имеет некоторую информацию/определенные доверительные отношения с DRM-E сервером 320. Соответственно, в одном варианте осуществления настоящего изобретения DRM-E сервер 320 получает или ему предоставляются некоторого вида мандаты 1340 (фиг.13), которые являются распознаваемыми и, ожидается, будут удовлетворительными для DRM-R сервера 320 и достаточно идентифицирующие DRM-E сервер 320 для DRM-R сервера 320 (этап 1501).

Если DRM-R сервер 320 и DRM-E сервер 320 находятся внутри одной организации, такие мандаты 1340 могут быть мандатами на основе организации, например сетевой идентификатор ID, если оба сервера 320 находятся в общей сети, ID домена, если оба сервера 320 совместно используют общий домен и т.д. Если DRM-R сервер 320 и DRM-E сервер 320 не находятся внутри одной организации, то мандатами 1340 могут оставаться сетевые ID, если оба сервера 320 находятся в общей сети, ID домена, если оба сервера 320 совместно используют общий домен, или т.д., или могут быть другие мандаты, например такие как мандаты, выданные третьей стороной и распознаваемые DRM-R сервером 320.

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

Как прежде, внутри архитектуры DRM входящий DRM-E сервер 320 должен иметь уникальный идентификатор. Здесь подразумевается, что DRM-идентификатор, вероятно, отличен от мандатов 1340, хотя DRM-идентификатор может также совпадать с мандатами 1340, что не выходит за пределы области настоящего изобретения. Соответственно, для установления идентификатора DRM-E сервер 320 формирует или получает новую пару открытый ключ/секретный ключ (PU-E, PR-E) (этап 1503). Так же как прежде, внутри архитектуры DRM DRM-E сервер 320 под-регистрации должен принять решение, какие объекты могут аннулировать участие своего авторитетного источника. Соответственно, DRM-E сервер 320 идентифицирует каждый аннулирующий объект в списке, возможно посредством его открытого ключа (этап 1505).

К этому моменту DRM-E сервер 320 имеет мандаты 1340, (PU-E) и (PR-E) и список аннулирования авторитетного источника. Затем для запроса под-регистрации DRM-E сервер 320 передает мандаты 1340, (PU-E) и список аннулирования авторитетного источника на DRM-R сервер 320 (этап 1507), и DRM-R сервер 320 продолжает под-регистрацию запрашивающего DRM-E сервера 320. Следует отметить, что как прежде, запрос или часть его может иметь вид сертификата, подписанного (PR-E).

В частности, DRM-R сервер 320 проверяет достоверность мандатов 1340 на основе любой логики или ресурсов, которые доступны и необходимы для проверки достоверности (этап 1509). Следовательно, DRM-R сервер 320 устанавливает на основе подтвержденных мандатов 1340, что DRM-E сервер 320 является правомочным и выполняет условия DRM архитектуры. Дополнительно, и как прежде, DRM-R сервер 320 выполняет любые заказные логические схемы, необходимые для принятия решения относительно удовлетворения запроса (этап 1511).

Предполагается, что заказные логические схемы разрешают удовлетворить запрос, затем в одном варианте осуществления настоящего изобретения DRM-R сервер 320 формирует сертификат 1310 под-регистрации для DRM-E сервера 320 (этап 1513). В частности, как видно из фиг.13, DRM-R сервер 320 включает в сертификат 1310 под-регистрации:

идентификатор DRM-R сервера 320, например его открытый ключ (PU-R),

идентификатор DRM-E сервера 320, например (PU-E),

мандаты 1340 или ссылку на них,

любую информацию области проверки достоверности, определяющую область, в пределах которой сертификат 1310 под-регистрации является допустимым, например интервал времени,

список аннулирования авторитетного источника,

подпись на основе секретного ключа DRM-R сервера 320 (PR-R), соответствующего (PU-R),

и любую другую соответствующую информацию.

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

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

Затем после успешного формирования DRM-R сервером 320 сертификата 1310 под-регистрации с присоединенной цепочкой сертификатов 1320, DRM-R сервер 320 возвращает его на запрашивающий DRM-E сервер 320 (этап 1515), и теперь под-регистрированный DRM-E сервер 320 хранит его в соответствующем местоположении для последующего использования (этап 1517). Как прежде, (PU-E) в сертификате 1310 под-регистрации и соответствующий (PR-E) являются парой открытый ключ/секретный ключ, которую DRM-E сервер 320 должен использовать, как (PU-DRM) и (PR-DRM) при подписании метки прав для создания SRL 308, выдачи сертификата 810 OLP и другого участия внутри архитектуры DRM. Соответственно, такой сертификат 1310 под-регистрации и цепочка сертификатов 1320 в комбинации формируют цепочку сертификатов, которая присоединяется к сертификату 810 OLP и т.д.

Заключение

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

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

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

Изобретение относится к системе управления цифровыми правами (DRM). Техническим результатом является возможность публикации содержимого без первоначального получения разрешения из сервера и выдачи себе лицензии для воспроизведения опубликованного содержимого без разрешения от сервера. Публикующий пользователь снабжается сертификатом на публикацию из сервера DRM, разрабатывает содержимое, шифрует его ключом содержимого (СК), создает метку прав для этого содержимого с открытым ключом DRM-сервера (PU-DRM) для формирования (PU-DRM(CK)), восстанавливает (PU-ENTITY(PR-OLP)) из сертификата публикации, применяет секретный ключ (PR-ENTITY), соответствующий (PU-ENTITY), к (PU-ENTITY(PR-OLP)) для получения (PR-OLP), подписывает созданную метку прав посредством (PR-OLP), соединяет SRL и сертификат публикации с зашифрованным содержимым для формирования пакета содержимого, распределяемого другому пользователю, который должен связаться с сервером DRM для получения в нем лицензии с (СК) для воспроизведения содержимого, создает данные лицензии, соответствующие пакету содержимого, с (СК), шифрованным (PU-ENTITY), для формирования (PU-ENTITY(CK)), подписывает данные лицензии посредством (PR-OLP), присоединяет сертификат публикации к лицензии на средство публикации. 4 н. и 16 з.п. ф-лы, 17 ил.

1. Способ публикации цифрового содержимого публикующим пользователем и выдачи себе соответствующей цифровой лицензии на средство публикации для обеспечения себе возможности воспроизведения опубликованного цифрового содержимого, по которому публикующий пользователь снабжается сертификатом на публикацию из сервера управления правами на цифровое содержимое (DRM), сертификат публикации имеет открытый ключ (PU-OLP) и соответствующий секретный ключ (PR-OLP), шифрованный открытым ключом, соответствующим публикующему пользователю (PU-ENTITY), для формирования (PU-ENTITY(PR-OLP)), способ включает:

разработку содержимого и шифрование разработанного содержимого в соответствии с ключом содержимого (CK),

создание метки прав для шифрованного содержимого с (CK), шифрованным открытым ключом DRM-сервера (PU-DRM), для формирования (PU-DRM(CK)),

восстановление (PU-ENTITY(PR-OLP)) из сертификата публикации,

применение секретного ключа (PR-ENTITY), соответствующего (PU-ENTITY), к (PU-ENTITY(PR-OLP)) для получения (PR-OLP),

подписание созданной метки прав посредством (PR-OLP) для создания подписанной метки прав (SRL),

соединение созданной SRL и сертификата публикации с шифрованным содержимым для формирования пакета содержимого, распределяемого другому пользователю, который должен связаться с DRM-сервером для получения в нем соответствующей лицензии с (CK) для воспроизведения шифрованного содержимого, причем только такой DRM-сервер имеет секретный ключ (PR-DRM), соответствующий (PU-DRM), и может применить (PR-DRM) к (PU-DRM(CK)) для получения (CK),

создание данных лицензии, соответствующих пакету содержимого, с (CK), шифрованным (PU-ENTITY) для формирования (PU-ENTITY(CK)),

подписание созданных данных лицензии посредством (PR-OLP) для создания лицензии на средство публикации и

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

проверку сертификата публикации на основе его подписи и цепочки сертификатов, приводящей обратно к корневому авторитетному источнику, и восстановление (PU-ENTITY(PR-OLP)) из проверенного сертификата публикации,

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

проверку сертификата публикации на основе цепочки сертификатов,

получение (PU-OLP) из сертификата публикации,

использование полученного (PU-OLP) для проверки подписи лицензии на средство публикации,

восстановление (PU-ENTITY(CK)) из проверенной лицензии на средство публикации,

применение к (PU-ENTITY(CK)) секретного ключа (PR-ENTITY), соответствующего (PU-ENTITY), для получения (CK),

применения (CK) к (CK(content)) для получения в результате содержимого, и

направление содержимого приложению воспроизведения для действительного воспроизведения.

разработку содержимого и шифрование разработанного содержимого в соответствии с ключом содержимого (CK),

создание метки прав для шифрованного содержимого с (CK), шифрованным открытым ключом DRM-сервера (PU-DRM), для формирования (PU-DRM(CK)),

восстановление (PU-ENTITY(PR-OLP)) из сертификата публикации,

применение секретного ключа (PR-ENTITY), соответствующего (PU-ENTITY), к (PU-ENTITY(PR-OLP)) для получения (PR-OLP),

подписание созданной метки прав посредством (PR-OLP) для создания подписанной метки прав (SRL),

соединение созданной SRL и сертификата публикации с шифрованным содержимым для формирования пакета содержимого, распределяемого другому пользователю, который должен связаться с DRM-сервером для получения в нем соответствующей лицензии с (СК) для воспроизведения шифрованного содержимого, причем только такой DRM-сервер имеет секретный ключ (PR-DRM), соответствующий (PU-DRM), и может применить (PR-DRM) к (PU-DRM(CK)) для получения (CK),

создание данных лицензии, соответствующих пакету содержимого, с (CK), шифрованным (PU-ENTITY) для формирования (PU-ENTITY(CK)),

подписание созданных данных лицензии посредством (PR-OLP) для создания лицензии на средство публикации и

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

проверку сертификата публикации на основе его подписи и цепочки сертификатов, приводящей обратно к корневому авторитетному источнику, и восстановление (PU-ENTITY(PR-OLP)) из проверенного сертификата публикации,

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

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

проверку сертификата публикации на основе цепочки сертификатов,

получение (PU-OLP) из сертификата публикации,

использование полученного (PU-OLP) для проверки подписи лицензии на средство публикации,

восстановление (PU-ENTITY(CK)) из проверенной лицензии на средство публикации, применение к (PU-ENTITY(CK)) секретного ключа (PR-ENTITY), соответствующего (PU-ENTITY), для получения (CK),

применение (CK) к (CK(content)) для получения в результате содержимого, и

направление содержимого приложению воспроизведения для действительного воспроизведения.