ИЗБИРАТЕЛЬНОЕ УПРАВЛЕНИЕ ПРАВАМИ НА ПОТОКОВЫЙ КОНТЕНТ Российский патент 2010 года по МПК H04L9/08 

Область техники

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

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

Растет популярность передачи потоков видеосигналов, потоков данных и широкополосной цифровой трансляции в беспроводных сетевых приложениях, например, при групповом вещании в рамках сетевого протокола IP (Internet Protocol). Для поддержки этих беспроводных приложений системы беспроводной передачи, которые поддерживают передачу данных ко многим беспроводным терминалам одновременно, передают контент из данных. Цифровой медиаконтент или другие данные передают с использованием различных прикладных протоколов, протоколов переноса и сетевых протоколов. Например, трансляционная система обеспечивает такую трансляцию IP-данных, при которой передача аудиовизуальных услуг передается так, что видеоданные в формате MPEG4-AVC, аудиоданные в формате MPEG4-AAC и вспомогательные компоненты данных пакетируются и инкапсулируются в транспортный протокол реального времени (RTP, Real-Time Transport Protocol) и/или ALC. Затем пакеты форматируют в UDP и IP и передают по МРЕ в формате MPEG2-TS (например, DVB-H). В домене с коммутацией пакетов концепция мультимедийного сеанса связи может потребовать, чтобы один или более компонентов сеанса связи (в вышеуказанном случае, аудиоданные, видеоданные и вспомогательные данные) были логически связаны. Порции мультимедийного сеанса связи посылают между обычным временем начала и временем окончания. Однако в оборудовании для трансляции все приемники, которые в состоянии принимать сигнал трансляции, могут принять данные, которые переносятся в сигнале трансляции. Важно, чтобы продавец контента ограничил доступ к мультимедийному контенту так, чтобы только уполномоченные приемники могли представить мультимедийный контент пользователям.

Системы управление правами на цифровые материалы (DRM, Digital Rights Management), например система DRM Открытого мобильного союза (ОМА, Open Mobile Alliance), используются для продажи доступа к дискретным файлам, например к файлам с цифровым контентом (DCF, Digital content files) ОМА DRM. Одним из возможных решений является устройство (проинструктированное пользователем, т.е. человеком), которое принимает от провайдера контента файл DCF (например, музыкальный файл в формате МР3), который зашифрован ключом контента. Устройство отдельно получает (то есть покупает) от держателя прав (RI, Rights Issuer) объект прав (RO, Right Object), который может включать (помимо прочего) две части: ключ контента для дешифровки файла DCF и права использования для файла DCF. Права использования контролируют способ, посредством которого устройство (и, таким образом, пользователь-человек) может использовать дешифрованный контент файла DCF, например временные пределы для использования контента, возможность копирования контента и т.д. Различные держатели прав могут продавать объекты прав для одного и того же файла DCF по различным ценам и с различными правами использования.

Часто, например в случае управления ОМА DRM, права использования выражены на Языке выражения прав (REL, Rights Expression Language), который может содержать условие, основанное на таких переменных, как дни недели, время дня, количество дней и т.д. Например, может быть заявлено, что конкретное право использования простирается на некоторый период времени. Примеры языка REL включают Открытый язык прав на цифровые материалы (ODRL, Open Digital Rights Language) и расширяемый язык разметки для прав (XrML, eXtensible rights Markup Language).

С недавнего времени системы DRM развертываются для продажи потоковых услуг в дополнение к дискретным файлам DCF. Специальным случаем таких потоковых услуг являются потоковые услуги по обычной радиотрансляции (ниже - услуги трансляции), при которых множество устройств получают один и тот же поток трансляции. Например, управление ОМА DRM было предложено для продажи и покупки услуг по трансляции данных в Интернете (IPDC, IP datacast), и для этого решения разрабатывается стандарт Организацией цифрового телевидения (DVB, Digital Video Broadcasting), чтобы (помимо прочего) поддерживать переносные телевизоры на пике технологии цифровой телетрансляции для переносных систем (DVB-H).

Типичные организационные роли в службах трансляции включают 1) транслятор, который получает потоковый контент от провайдеров оперативной информации и транслирует его в зашифрованном виде по радиотракту, и 2) множество держателей прав (RI), которые продают объекты прав (RO) для дешифровки контента и устанавливают права использования контента в устройствах, принимающих трансляцию. Объекты прав могут доставляться по тому же радиотракту трансляции, что и сам зашифрованный контент, или через отдельные интерактивные каналы, например посредством сотовых носителей данных (например, по системе пакетной радиосвязи общего пользования - GSM GPRS, General Packet Radio Service).

В таком сценарии обычно ключ в каждом RO не может дешифровать потоковый контент непосредственно, поскольку потоковый контент непрерывен (в отличие от дискретных файлов DCF. Одним из известных способов дешифровки контента является иерархия ключей, например, используемая при условном доступе в цифровом телевидении. Транслятор посылает последовательности потокового контента, каждый из которых зашифрован ключом трафика (ТК, Traffic key), и периодически меняет ключ трафика. По меньшей мере всякий раз, когда ключ трафика меняется, посылается сообщение о потоке ключей (KSM, Key Stream Message), содержащее ключ трафика, зашифрованный служебным ключом (SK, service key). RO содержит служебный ключ. Поэтому приемные устройства могут использовать служебный ключ в RO для дешифровки ключей трафика в сообщениях KSM. Затем приемные устройства могут использовать ключи трафика для дешифровки потокового контента. На практике, чтобы обеспечить быстрое "переключение канала" с одного обслуживания на другое, сообщения KSM должны передаваться очень часто.

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

Как сказано выше, RO для службы трансляции предназначен, чтобы дешифровать и сделать доступным потоковый контент в течение периода действительности RO. Как и в случае файла DCF, RO может также использоваться для заявления прав использования, выраженных на языке REL, в течение того же самого периода действительности. Например, рассмотрим службу телевизионной трансляции для переносных систем DVB-Н. Обычно устройству позволено визуализировать на дисплее (так, чтобы пользователь-человек мог наблюдать) телевизионную службу, например программу на канале, по мере ее приема. Права использования могут утверждать, чтò именно устройство/пользователь может сделать с потоковым контентом, который может быть телевизионной службой. Например, права использования могут разрешить запись контента для воспроизведения в более позднее время, копирование на другое устройство, только просмотр и т.п., в зависимости от того, какие права предоставлены.

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

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

В другом аспекте настоящего изобретения предлагаются способы, устройства и системы для доставки защищенного мультимедийного контента в приемное устройство. Части защищенного мультимедийного контента и ассоциированной ключевой информации вставляют в тот же самый пакет временного разделения. Следовательно, ключевая информация может часто меняться при сохранении синхронизации с мультимедийным контентом. В одном варианте выполнения настоящего изобретения пакет временного разделения посылают из передающего устройства в приемное устройство посредством системы связи, которая включает систему DVB-H, систему DVB-Т, систему ATSC и систему ISDB-T. Каждое из сообщений KSM, которые посылаются очень часто, содержит малое количество такой информации программной категории, которая преобразуется в переменную REL и, таким образом, выбирает условные права использования из объектов прав всех держателей прав или (в другой реализации) из объекта прав каждого держателя прав индивидуально. В одном из вариантов выполнения настоящего изобретения выбор может зависеть от телевизионной программы.

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

на фиг.1 показана передача услуг в рамках протокола маршрутизации в среде Интернет (IP) с использованием передачи с временным разделением согласно одному из вариантов выполнения настоящего изобретения;

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

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

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

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

на фиг.6 показана модификация конфигурации компонентов, показанной на фиг.4, согласно варианту выполнения настоящего изобретения;

на фиг.7 показана модификация конфигурации компонентов, показанной на фиг.4, согласно варианту выполнения настоящего изобретения;

на фиг.8 показана модификация конфигурации компонентов, показанной на фиг.4, согласно варианту выполнения настоящего изобретения;

на фиг.9 показана модификация конфигурации компонентов, показанной на фиг.4, согласно варианту выполнения настоящего изобретения;

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

на фиг.11 показана модификация конфигурации компонентов, показанной на фиг.10, согласно варианту выполнения настоящего изобретения;

на фиг.12 показана модификация конфигурации компонентов, показанной на фиг.10, согласно варианту выполнения настоящего изобретения;

на фиг.13 показана модификация конфигурации компонентов, показанной на фиг.10, согласно варианту выполнения настоящего изобретения;

на фиг.14 показана модификация конфигурации компонентов, показанной на фиг.10, согласно варианту выполнения настоящего изобретения;

на фиг.15 показана модификация конфигурации компонентов, показанной на фиг.10, согласно варианту выполнения настоящего изобретения;

на фиг.16 показана модификация конфигурации компонентов, показанной на фиг.10, согласно варианту выполнения настоящего изобретения;

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

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

на фиг.19 показана система для защищенной передачи контента, которая поддерживает службы DBV-H IPDC (трансляцию данных в формате IP) согласно известному техническому решению;

на фиг.20 показана система, которая поддерживает службы DBV-H IPDC согласно варианту выполнения настоящего изобретения;

на фиг.21 показана последовательность операций для передачи служб DBV-H IPDC в системе, изображенной на фиг.20, согласно варианту выполнения настоящего изобретения;

на фиг.22 показана система, которая поддерживает службы DBV-H IPDC согласно варианту выполнения настоящего изобретения;

на фиг.23 показана система, которая поддерживает службы DBV-H IPDC согласно варианту выполнения настоящего изобретения;

на фиг.24 показано устройство, которое поддерживает модуль передачи, изображенный на фиг.20, 22, и 23, согласно варианту выполнения настоящего изобретения;

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

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

на фиг.27 показана система для использования защитного сменного программного модуля согласно варианту выполнения настоящего изобретения;

на фиг.28 иллюстрируется пример известного способа создания зашифрованного контента;

на фиг.29 иллюстрируется способ создания зашифрованного потокового контента согласно варианту выполнения настоящего изобретения;

на фиг.30 иллюстрируется способ трансляции потокового контента согласно варианту выполнения настоящего изобретения;

на фиг.31 показана временная линия изменений ключей трафика согласно варианту выполнения настоящего изобретения;

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

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

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

Для лучшей структуры и для простоты изложения подробное описание разбито на два раздела. Сначала, на фиг.1-27, даны детали способов посылки и приема контента согласно аспектам настоящего изобретения. Затем, на фиг.28-33, раскрыты детали способов и устройства для управления правами использования частей контента.

Способы и устройство для предоставления потокового контента

На фиг.1 показана служба передачи в протоколе маршрутизации в среде Интернет (IP) с использованием передачи во временных интервалах согласно одному из вариантов выполнения настоящего изобретения. Базовая станция транслирует пакеты данных для множества служб IP с использованием потоков 101, 103, 105 и 107 данных. (Каждому потоку данных назначена часть пропускной способности передачи данных.) В данном варианте выполнения настоящего изобретения базовая станция может поддерживать функциональные возможности, которые типично предполагаются присущими базовой приемопередающей станции (BTS, Base transceiver station), контроллеру базовой станции (BSC, Base station controller), комбинации базовой приемопередающей станции и контроллера базовой станции и узлу В, что является названием базовой приемопередающей станции третьего поколения (3G). Передача данных происходит по существу непрерывно, так что пакеты данных для службы IP непрерывно передаются в потоке данных.

Для уменьшения объема потерь пакетов данных потоки 101, 103, 105 и 107 данных отображаются базовыми станциями в серии пакетов 109, 111, 113 и 115 данных соответственно, и именно эти серии передаются по радиоканалам, а не потоки 101, 103, 105 и 107 данных. Каждый поток (101, 103, 105 и 107) данных, а следовательно, каждая серия (109, 111, 113, и 115) поддерживает по меньшей мере одну передачу данных. Таким образом, каждая серия может поддерживать множество передач данных (например, группу связанных служб по передаче данных).

Скорости передачи данных, связанные с сериями 109, 111, 113 и 115, обычно больше, чем скорости передачи данных, которые связаны с потоками 101, 103, 105 и 107 данных, так что соответствующее количество пакетов данных можно послать за меньшее время. В данном варианте выполнения настоящего изобретения потоки 101, 103, 105 и 107 данных соответствуют непрерывным скоростям передачи данных приблизительно 100 килобит/с. Серии 109, 111, 113 и 115 обычно соответствуют приблизительно 4 Мбит/с (но скорость может превышать 10 Мбит/с) при продолжительности приблизительно 1 с. Однако в других вариантах выполнения настоящего изобретения могут использоваться другие скорости передачи данных для потоков 101-107 данных и для серий 109-115.

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

Серии обычно передаются базовой станцией периодически. Например, последующая серия может происходить через Т секунд после серии 109, т.е. серия передается каждые Т секунд. Беспроводной терминал может поддерживать точную синхронизацию, например, с использованием Глобальной системы определения местоположения (GPS, Global Positioning System) для определения абсолютного времени, в которое передается каждая серия. В другом варианте выполнения настоящего изобретения беспроводной терминал получает информацию о времени в каждой серии и, таким образом, получает информацию о последующей серии. В варианте выполнения настоящего изобретения информация о временном периоде включает параметр в реальном времени (соответствующий "дельта-t" (delta-t) в DBV-H), который указывает интервал времени от начала серии до начала следующей серии для той же службы, и сигнализация об этом происходит в заголовке секции МРЕ. Временной период может быть включен в пакет IP, кадр, инкапсулированный в мультипротокол, любой другой кадр пакета и канал третьего поколения (3G) или системы пакетной радиосвязи общего пользования (GPRS) или модуляционные данные, например в сигнализацию о параметрах передатчика. Альтернативно беспроводной терминал может обнаружить возникновение серии по получению преамбулы сигнала, которая может быть последовательностью данных, априорно известной беспроводному терминалу. В другом варианте выполнения настоящего изобретения беспроводной терминал может получать служебное сообщение по служебному каналу из базовой станции. Служебное сообщение может содержать информацию синхронизации относительно появления серий. Служебный канал может логически или физически отличаться от нисходящего радиоканала, который поддерживает передачу серий.

Серии 109, 111, 113 и 115 могут быть отформатированы с использованием мультипротокольной инкапсуляции в соответствии с разделом 7 Европейского стандарта EN 301 192 "Digital Video Broadcasting" (DVB), DVB specification for data broadcasting. Инкапсуляция может быть приспособлена к стандартам протокола маршрутизации в среде Интернет (IP).

В варианте выполнения настоящего изобретения цифровая телевизионная трансляция (DVB-H) обеспечивает мобильное медиаобслуживание беспроводных терминалов, например переносных беспроводных блоков. В варианте выполнения настоящего изобретения система DVB-H совместима с DVB-T (digital video broadcast for terrestrial operation - цифровая телевизионная трансляция для наземных операций) и поддерживает расширения для лучшей поддержки работы беспроводных переносных терминалов. Система DVB-H поддерживает службы передачи данных на основе протокола IP, в которых информация может быть передана в виде дейтаграмм IP. Система DVB-H включает расширения (по отношению к системе DVB-T), которые облегчают доступ к службам DVT на основе протокола IP для беспроводных переносных терминалов. (Альтернативные варианты выполнения настоящего изобретения поддерживают разнообразные цифровые телевизионные системы трансляции, включая DVB-T, ATSC и ISDB-T.) Расширения DVB-H основаны на физическом уровне физического уровня DVB-T, при этом несколько расширений служебного уровня направлено на повышение срока службы аккумулятора и прием в переносное оборудование. Таким образом, расширения DVB-H поддерживают существующие цифровые наземные службы, предлагая при этом провайдерам услуг возможность расширения рынка на область беспроводной переносной техники.

На фиг.2 показан стек 200 IP, который поддерживает передачу мультимедийных данных в соответствии с одним из вариантов выполнения настоящего изобретения. Цифровой медиаконтент или другие данные передают с использованием различных прикладных протоколов, транспортных протоколов и сетевых протоколов. С использованием стека 200 IP трансляция данных IP поддерживает аудиовизуальную службу, включающую компонент 201 видео MPEG4-AVC, компонент 203 аудио MPEG4-AAC и компонент 205 вспомогательных данных. Каждый компонент (201, 203 или 205) обрабатывается кодером 207, кодером 209 или кодером 211 для получения пакетов, которые отформатированы для уровня 213 протокола реального времени (RTP). Затем пакеты (дейтаграммы) обрабатываются на уровне 215 протокола пользовательских дейтаграмм (UDP, user datagram protocol) и уровне 217 протокола маршрутизации в среде Интернет (IP). Дейтаграммы ассоциируют с пакетами временных интервалов путем форматирования дейтаграмм с использованием мультипротокольной инкапсуляции (типично соответствующей уровню связи в модели OSI), например, в соответствии с разделом 7 из Европейского стандарта EN 301 192 "Digital Video Broadcasting (DVB), DVB specification for data broadcasting." Инкапсуляция может соответствовать стандартам протокола IP.

Мультимедийный сеанс связи обычно ассоциируется с одним или более компонентами сеанса связи (в вышеуказанном случае - аудио, видео и вспомогательными данными), которые логически связаны. Части сеанса связи посылаются между обычным временем начала и временем окончания. Как время начала, так и время окончания могут быть определенными или неопределенными.

На фиг.3 показана конфигурация 300 компонентов мультимедийного сеанса 301 связи согласно одному из вариантов выполнения настоящего изобретения. Компонент 303 соответствует множеству дейтаграмм (включая дейтаграммы 309 и 315); компонент 305 соответствует множеству дейтаграмм (включая дейтаграммы 311 и 317) и компонент 307 соответствует множеству дейтаграмм (включая дейтаграммы 313 и 319). Компоненты 303, 305 и 307 передаются внутри пакетов IP, которые инкапсулированы в сообщения канала нижнего уровня. Каждый компонент 303, 305 и 307 имеет определенный IP-адрес источника, IP-адрес назначения и порт, используемый в IP-пакетах, которые переносят данные, ассоциированные с компонентом. Различные компоненты могут иметь независимо определенный IP-адрес источника, IP-адрес назначения и порт. В модификациях варианта выполнения настоящего изобретения мультимедийный сеанс связи может иметь другое количество компонентов.

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

На фиг.4 показана конфигурация 400 компонентов для мультимедийного сеанса 401 связи согласно еще одному варианту выполнения настоящего изобретения. Компоненты 403, 405 и 407 зашифрованы с использованием того же самого ключа, который периодически изменяется в потоке 409 ключей в течение мультимедийного сеанса 401 связи. (На фиг.4-16 дейтаграмма, которая зашифрована с использованием ключа k_i, обозначена как E_i. (Поток 409 ключей - это логический канал, который содержит информацию о ключах и отделен от медиакомпонентов.) Аналогично дейтаграмма, связанная cj-ым компонентом и зашифрованная с использованием i-го ключа, ассоциированного с j-ым компонентом, обозначена как E_ji.) Этот вариант выполнения настоящего изобретения поддерживает другие способы шифрования по отношению к компоненту 403, 405 или 407, включая:

- IPSEC-ESP (так называемое шифрование на уровне IP, см. RFC в IPSEC-ESP),

- полезную нагрузку зашифрованного пакета прикладного сеанса связи (например, SRTP или DCF для ОМА DRM1.0 или 2.0),

- шифрование.

Вышеуказанные способы шифрования могут применяться по отдельности или в комбинации в течение мультимедийного сеанса связи 401. Компоненты 403, 405 и 407 соответствуют различному множеству дейтаграмм контента. Поток 409 ключей включает множество ассоциированных дейтаграмм, причем каждая ассоциированная дейтаграмма соответствует ключу шифрования. Шифрование обычно проводится на основе индивидуальной дейтаграммы (например, пакета). Например, дейтаграммы 415, 425, 427, 435 и 437 контента шифруются с использованием ключа k₁ (соответствует ассоциированной дейтаграмме 411), а дейтаграмма 417 контента шифруется с использованием ключа k₂ (соответствует ассоциированной дейтаграмме 413).

Поток 409 ключей использует протокол доставки, например RTP, ALC/FLUTE, UHTTP, DVBSTP, IP с полезной нагрузкой и UDP с полезной нагрузкой. Ключи, доставляемые в потоке 409 ключей, обычно защищены другим ключом, который имеется в предназначенном приемнике для доступа к контентам потока 409 ключей, в котором переносятся ключи, таким образом обеспечивая доступ к компонентам 403, 405 и 407. Как вариант, доставка потока 409 ключей синхронизирована с компонентами 403, 405 и 407, например, с помощью временных меток протокола RTP с использованием протокола управления RTP (RTP Control Protocol).

На фиг.5 показана модификация конфигурации компонентов, изображенной на фиг.4, согласно еще одному варианту выполнения настоящего изобретения. Конфигурация 500 компонентов аналогична конфигурации 400 компонентов. Мультимедийный сеанс 501 связи включает компоненты 503, 505 и 507 и поток 509 ключей. Компонент 505 шифруется с использованием ключей из потока 509 ключей, а компоненты 503 и 507 нет.

На фиг.6 показана модификация конфигурации компонентов, изображенной на фиг.4, согласно еще одному варианту выполнения настоящего изобретения. Конфигурация 600 компонентов аналогична конфигурации 400 компонентов. Однако поток 609 ключей включает три серии ключей 611, 613 и 615, которые соответствуют компонентам 603, 605 и 607 соответственно. Ключи могут меняться периодически, но независимо, в течение мультимедийного сеанса 601 связи, а могут быть синхронизированы друг с другом.

На фиг.7 показана модификация конфигурации компонентов, изображенной на фиг.4, согласно еще одному варианту выполнения настоящего изобретения. Конфигурация 700 компонентов аналогична конфигурации 600 компонентов, за исключением того, что ключи для каждого компонента переносятся в различных потоках ключей, которые меняются в течение мультимедийного сеанса 701 связи. Вместо использования одного потока ключей в конфигурации 700 используются три потока 709, 711 и 713 ключей. Потоки 709, 711 и 713 ключей соответствует компонентам 703, 705 и 707 соответственно.

На фиг.8 показана модификация конфигурации компонентов, изображенной на фиг.4, согласно еще одному варианту выполнения настоящего изобретения. В конфигурации 800 компонентов компонент 805 шифруется с использованием ключей из потока 809 ключей. Однако поток 809 ключей предоставляет ключи, которые в настоящее время могут использоваться для дешифровки компонента 805, а также ключи, которые будут использоваться при дешифровке компонента 805 позднее. В примере, показанном в фиг.8, в настоящее время применяется ключ k₁ (соответствующий дейтаграмме 811), в то время как ключ k₂ (соответствующий дейтаграмме 813) и ключ k₃ (соответствующий дейтаграмме 815) используются позднее. Хотя компоненты 803 и 807 не шифруются в течение мультимедийного сеанса 801 связи, компоненты 803 и 807 могут шифроваться в других модификациях этого варианта выполнения настоящего изобретения. Наличие ключей, которые будут применяться впоследствии, позволяет приемному устройству снизить жесткость требований на передачу ключей в течение мультимедийного сеанса 801 связи. Например, приемное устройство может сконфигурировать стек IP с использованием нового ключа для уменьшения прерываний при дешифровке дейтаграмм контента.

На фиг.9 показана модификация конфигурации компонентов, изображенной на фиг.4, согласно еще одному варианту выполнения настоящего изобретения. Поток 909 ключей содержит ключ, в настоящее время применяемый к компоненту 905 для шифрования, а также ключи, которые будут применены впоследствии, если передача ключа происходит в пределах заранее заданного возрастания текущего времени. Например, перед передачей 951 ключа поток 909 ключей содержит как ключ k₁ (соответствующий дейтаграмме 911), так и k₂ (соответствующий дейтаграмме 913) и включает только k₂ (соответствующий дейтаграмме 915) после передачи 951 ключа. Как и в конфигурации 800 компонентов конфигурация 900 компонентов позволяет приемному устройству снизить жесткость требований на передачу ключей.

На фиг.10 показана конфигурация 1000 компонентов для мультимедийного сеанса 1001 связи согласно еще одному варианту выполнения настоящего изобретения. Однако по сравнению с конфигурациями 400-900 компонентов ключи переносятся в одном или более компонентах вместо того, чтобы имелся отдельный поток ключей для передачи ключей. В конфигурации 100 компонентов компонент 1005 содержит дейтаграммы контента (например, дейтаграмму 1011 контента), а также дейтаграмму 1009, которая предоставляет ключ k₁, используемый для шифрования компонентов 1003, 1005 и 1007.

На фиг.11 показана модификация конфигурации компонентов, изображенной на фиг.10, согласно еще одному варианту выполнения настоящего изобретения. В конфигурации 1100 компонентов компонент 1107 обеспечивает ключ k₁ (соответствующий дейтаграмме 1109) и ключ k₂ (соответствующий дейтаграмме 1111), которые применены к компоненту 1105 в течение мультимедийного сеанса 1101 связи. В примере, изображенном на фиг.11, компоненты 1103 и 1107 не шифруются ключами, предоставляемыми компонентом 1107.

На фиг.12 показана модификация конфигурации компонентов, изображенной на фиг.10, согласно еще одному варианту выполнения настоящего изобретения. Конфигурация 1200 элементов аналогична конфигурации 1100 элементов. Однако в течение мультимедийного сеанса 1201 связи ключи применяются как к компоненту, переносящему информацию о ключах (компонент 1205), так и к другому компоненту (компонент 1203). Однако в примере, показанном на фиг.12, компонент 1207 не шифруется.

На фиг.13 показана модификация конфигурации компонентов, изображенной на фиг.10, согласно еще одному варианту выполнения настоящего изобретения. В конфигурации 1300 компонентов каждый компонент 1303, 1305 и 1307 переносит ключи, которые применяются к этому же компоненту в течение мультимедийного сеанса 1301 связи. Например, ключ k₁₁ (соответствующий дейтаграмме 1309) и ключ k₁₂ (соответствующий дейтаграмме 1311) применяются к компоненту 1303. Ключ k₂₁ (соответствующий дейтаграмме 1313) и ключ k22 (соответствующий дейтаграмме 1315) применяются к компоненту 1305. Ключ k₃₁ (соответствующий дейтаграмме 1317) и ключ k₃₂ (соответствующий дейтаграмме 1319) применяются к компоненту 1307.

На фиг.14 показана модификация конфигурации компонентов, изображенной на фиг.10, согласно еще одному варианту выполнения настоящего изобретения. В конфигурации 1400 компонентов каждый компонент 1403, 1405 и 1407 переносит ключи, которые применяются к другому компоненту в течение мультимедийного сеанса 1401 связи. Например, ключ k₁₁ (соответствующий дейтаграмме 1413 и переносимый компонентом 1405) и ключ k₁₂ (соответствующий дейтаграмме 1419 и переносимый компонентом 1407) применяются к компоненту 1403. Ключ k₂₂ (соответствующий дейтаграмме 1417 и переносимый компонентом 1407) и ключ k₂₂ (соответствующий дейтаграмме 1411 и переносимый компонентом 1403) применяются к компоненту 1405. Ключ k₃₁ (соответствующий дейтаграмме 1409 и переносимый компонентом 1403) и k₃₂ (соответствующий дейтаграмме 1415 и переносимый компонентом 1405) применяется к компоненту 1407.

На фиг.15 показана модификация конфигурации компонентов, изображенной на фиг.10, согласно еще одному варианту выполнения настоящего изобретения. В конфигурации 1500 компонентов информацию о ключе переносят в дейтаграмме контента, а не в отдельной дейтаграмме. Например, ключ k₁ включен в дейтаграмму 1509 контента в пределах сцепленной части (или со специальным заголовком) 1511, а ключ k₂ включен в дейтаграмму 1513 контента в пределах сцепленной части (или со специальным заголовком) 1515. Ключи k₁ и k₂ применены к дейтаграммам в компонентах 1503, 1505 и 1507.

На фиг.16 показана модификация конфигурации компонентов, изображенной на фиг.10, согласно еще одному варианту выполнения настоящего изобретения. Конфигурация 1600 компонентов аналогична конфигурации 800 компонентов, в которой предоставлены как текущий ключ, так и последующие ключи. Например, компонент 1605 переносит ключ k₁ (соответствующий дейтаграмме 1609) и ключ k₂ (соответствующий дейтаграмме 1611), причем ключ k₁ в настоящее время применяется к компонентам 1603 и 1607, а ключ k₂ применяется позднее в течение мультимедийного сеанса 1601 связи. Аналогично ключ k₂ (соответствующий дейтаграмме 1613) и ключ k₂ (соответствующий дейтаграмме 1615) впоследствии переносятся в компоненте 1605. Как и в случае конфигурации 800 компонентов конфигурация 1600 компонентов позволяет приемному устройству снизить жесткость требований на передачу ключей.

На фиг.17 показана архитектура 1700 для приема мультимедийного сеанса связи в соответствии с одним из вариантов выполнения настоящего изобретения. В архитектуре 1700 приемное устройство принимает серию данных 1701 интервала времени, содержащих как компоненты сеанса связи IP, так и поток ключей, относящийся к компонентам сеанса связи. Множество дейтаграмм 1705, 1707 и 1709 контента соответствует компоненту 1, компоненту 2 и компоненту 3 соответственно. Множество дейтаграмм 1711 соответствует потоку ключей. Серия 1701 хранится в промежуточном буфере 1713 перед передачей дейтаграмм (пакетов) в стек 1721 IP. Приемное устройство сначала извлекает из промежуточного буфера 1713 ключи (соответствующие дейтаграмме 1717) для принятой серии 1701 интервала времени. Во-вторых, приемное устройство инсталлирует извлеченные ключи в базу 1719 данных Ассоциации по безопасности IPSec (IPSec Security Association). Кроме того, приемное устройство извлекает оставшиеся дейтаграммы 1715 из промежуточного буфера и передает их в стек 1721 IP. После дешифровки обработанные дейтаграммы передаются в приложения 1723 для представления мультимедийного контента. Следовательно, стек 1721 IP не отбрасывает дейтаграммы контента (если только не имеются дейтаграммы контента, для которых приемное устройство не имеет соответствующего ключа, который должен быть доставлен в текущем кванте времени или в предыдущем кванте времени). Процесс повторяется для следующей принятой серии 1703.

На фиг.18 показана последовательность 1800 операций для архитектуры, иллюстрированной на фиг.17, согласно еще одному варианту выполнения настоящего изобретения. На шаге 1801 приемное устройство принимает серию интервала времени по каналу связи, например по беспроводному каналу. На шаге 1803 приемное устройство выделяет компоненты (например, аудиокомпоненту и видеокомпоненту) из принятой серии. На шаге 1805 приемное устройство извлекает ассоциированный набор ключей из потока ключей. Извлеченные ключи можно применить для дейтаграмм контентов, содержащихся в серии или в последующих сериях. Кроме того, этот вариант выполнения настоящего изобретения поддерживает конфигурации, в которых различные ключи используются для различных дейтаграмм в серии. На шаге 1807 извлеченные ключи применяют к базе данных Ассоциации по безопасности IPSec (IPSec Security Association) (например, SA BD 1719, показанной на фиг.17). На шаге 1809 дейтаграммы контента извлекают из буфера (например, промежуточного буфера 1713) и посылают (шаг 1811) в стек IP (например, в стек 1721). Дейтаграммы контентов затем дешифруют и посылают в соответствующее приложение.

На фиг.19 показана система 1900 для защищенной передачи контента, которая поддерживает службы DVB-H IPDC (IP-трансляцию данных), организованные согласно известному техническому решению. Система 1900 обеспечивает защищенную передачу контента для служб DVB-H с использованием трансляции IPDC, как определено в документе "Interim DVB-Н IP Datacast Specifications: IP Datacast Baseline Specification: Specification of Interface I_MT", DVB Document A080, April 2004. В соответствии с этими техническими требованиями части данных, ассоциированные с безопасностью, передают в электронную служебную директорию (ESG, electronic service directory) в карусель 1921 SA в виде SA файла 1919 защиты DRM (который выдается менеджером 1909 прав на цифровые данные (DRM, digital rights manager), выполняющим функцию защиты), и файла 1911 политики IPSec. Поскольку данные карусели обычно обновляются нечасто (например, один раз в день), система 1900 не обеспечивает эффективного решения доставки ключей, особенно, если происходит обновление или частая замена одного или нескольких ключей.

Мультимедийный контент 1901 (соответствующий дейтаграммам IP) шифруется модулем 1903 шифрования с использованием ключей 1905 IPSec и передается (посредством передающей системы 1925) в виде пакетов интервалов времени (после мультипротокольной инкапсуляции, кодирования с упреждающей коррекцией ошибок (FEC), формирования серий) в приемное устройство 1926. Объект 1923 прав (RO) (который выдается генератором 1922 объектов прав) передается в приемное устройство 1926 по интерактивному каналу, причем приемное устройство 1926 снабжено средством для двунаправленной связи, например, с функциональными возможностями мобильного телефона. Пользователь приемного устройства 1926 может заказать службу (контент) и, следовательно, принять соответствующий объект 1933 прав (RO), который позволяет пользователю дешифровать контент заказанной службы. В варианте выполнения настоящего изобретения объект 1933 прав обычно не содержит ключей 1905 IPSec.

Приемное устройство 1926 обрабатывает серии интервалов времени с помощью обрабатывающего модуля 1927. Для получения контента 1935 принятые пакеты дешифровываются модулем 1929 дешифровки с использованием ключа, предоставленного модулем 1931 извлечения ключей. Ключи определяются объектом 1933 прав. Ключи обычно доставляются в карусель SA в виде SA файла защиты DRM. Объект 1933 прав позволяет приемному устройству 1926 извлекать ключи.

На фиг.20 показана система 2000, которая поддерживает службы DVB-Н IPDC согласно одному из вариантов выполнения настоящего изобретения. Мультимедийный контент 2001 (соответствующий дейтаграммам контента) шифруется модулем 2003 шифрования с использованием ключей 2005 IPSec. Передающая система 2025 получает как зашифрованные дейтаграммы контента из модуля 2003 шифрования, так и соответствующие ключи от менеджера DRM 2009. Передающая система 2025 формирует соответствующие дейтаграммы, которые содержат ключи, использованные для шифрования дейтаграмм контента. Передающая система 2025 вставляет как зашифрованные дейтаграммы контента, так и соответствующие дейтаграммы в серию, которая передается в приемное устройство 2026 по каналу связи. Хотя на фиг.20 явно не показан радиомодуль, вариант выполнения настоящего изобретения может включать возможность беспроводной передачи сигнала для передачи серии в приемное устройство 2026 по беспроводному каналу.

Приемное устройство 2026 обрабатывает принятую серию, причем дейтаграммы с зашифрованным контентом и соответствующие дейтаграммы (содержащие соответствующие ключи, которые используются для шифрования принятых дейтаграмм контента) отделяются (демультиплексируются) модулем 2027 обработки серий. В данном варианте выполнения настоящего изобретения приемное устройство 2026 содержит широкополосный приемник, предназначенный для приема сигналов DVB, которые включают серии, и приемопередатчик для двунаправленной связи в беспроводной сети. Двунаправленные связи поддерживают заказ службы пользователем, обмен сообщениями ОМА и установку защитного сменного модуля. Этот вариант выполнения настоящего изобретения поддерживает различные сигнальные конфигурации, в которых ключи включены в отдельный поток ключей или в которых ключи включены в мультимедийные компоненты, как обсуждалось выше при описании фиг.4-16. Модуль 2031 извлечения ключей извлекает ключи из соответствующих дейтаграмм для дешифровки дейтаграмм контента, как это делает модуль 2029 дешифровки. Модуль дешифровки выдает дешифрованный контент 2035 в приложение (не показано), так чтобы контент можно было использовать.

Кроме того, в ответ на заказ на поставку объект 2023 управления правами (определенный генератором 2022 объектов прав) отдельно передается в приемное устройство 2026. Следовательно, приемное устройство 2026 принимает объект 2033 прав, чтобы определить, разрешено ли приемному устройству 2026 обработать принятый контент.

На фиг.21 показана последовательность 2100 операций для передачи данных для служб для DVB-H IPDC в системе 2000 согласно одному из вариантов выполнения настоящего изобретения. На шаге 2101 передающее устройство (например, передающая система 2025) определяет, следует ли включить полученную дейтаграмму контента в текущую серию интервала времени. Если нет, серию (с полученными ранее дейтаграммами контента и ассоциированными ключами) посылают в приемное устройство на шаге 2109.

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

На фиг.22 показана система 2200, которая поддерживает службы DVB-Н IPDC согласно одному из вариантов выполнения настоящего изобретения. На фиг.22 элементы 2201, 2203, 2205, 2222, 2223, 2227, 2229, 2231, 2233 и 2235 соответствуют элементам 2001, 2003, 2005, 2022, 2023, 2027, 2029, 2031, 2033 и 2035 на фиг.20. Как и в случае системы 2000, система 2200 передает дейтаграммы контента и соответствующую информацию о ключах в той же самой серии. Информация о ключах выдается в передающую систему 2225 генератором 2206 сообщений о ключах. Генератор сообщений о ключах может зашифровать ключи, так чтобы зашифрованная информация о ключах была передана в приемное устройство 2226 передающей системой 2225. Менеджер DRM 2209 совместно с генератором 2222 объектов прав выдает объект 2233 прав, который соответствует желаемой службе DVB-H IPDC, в приемное устройство 2226.

Файлы 2211 политики IPSec (которые могут содержать информацию, связанную с безопасностью) отдельно передаются в карусель 2221 SA из служебных (контента) и ключевых сообщений, которые мультиплексированы и переданы с использованием квантования времени IPDC. В данном варианте выполнения настоящего изобретения карусель 2221 SA передается как часть электронного руководства по услугам (ESG, electronic service guide).

На фиг.23 показана система 2300, которая поддерживает службы DVB-Н IPDC согласно еще одному варианту выполнения настоящего изобретения. Система 2300 поддерживает условный доступ (СА, conditional access), который может обеспечить второй уровень шифрования с использованием соответствующего секретного ключа. (Как будет обсуждаться в связи с описанием фиг.26, ключи IPSec могут шифроваться менеджером DRM, a также модулем СА.) Приемное устройство 2326 содержит секцию приемника и секцию терминала. Секция приемника выполняет обработку серий, демультиплексирование и дешифровку ключей. Секция приемника включает также установку сменного модуля СА и дешифратор ключей. Менеджер DRM 2351 посылает пакет 2353 установки сменного модуля СА в менеджер DRM 2314, так чтобы новый сменный модуль СА был установлен в приемном устройстве 2326, как ниже обсуждается при описании фиг.27. Дешифровку ключей выполняют в защищенном оборудовании для обработки. Секция терминала выполняет управление ключами и дешифровку ключей в дополнение к дешифровке (соответствует модулю 2329 дешифровки) и представлению контента (соответствует контенту 2335).

Шифрование ключей 2305 (которые используются для шифрования контента 2301 модулем 2303 шифрования) выполняется модулем 2311 шифрования ключей. Модуль 2311 шифрования ключей содержит модуль 2308 СА и менеджер DRM 2309. Таким образом, модуль 2311 шифрования ключей может обеспечить два уровня шифрования. Как зашифрованная ключевая информация, так и дейтаграммы контента включаются в ту же самую серию временного интервала передающей системой 2325.

Соответственно, дешифровка принятой информации о ключах, выполняется модулем 2317 дешифровки ключей. Модуль 2317 дешифровки ключей содержит менеджер DRM 2314 и модуль 2315 СА. Модуль 2317 дешифровки ключей осуществляет два уровня дешифровки, которые соответствуют двум уровням шифрования. Модуль 2327 обработки серий дешифрует принятые дейтаграммы контента с использованием дешифрованных ключей, выданных менеджером 2313 ключей. Принятые дейтаграммы контента дешифровываются модулем 2329 дешифровки в секции терминала. Менеджер 2313 ключей принимает информацию о ключах, которая демультиплексирована модулем 2327, и передает ее в модуль 2317 дешифровки ключей (который связан с надежным в смысле безопасности оборудованием) для дешифровки DRM и СА.

В данном варианте выполнения настоящего изобретения объект прав (RO) передается как сообщение ОМА DRM 2 (согласно предложенной версии 2.0 прав на цифровые материалы Открытого мобильного союза) из менеджера DRM 2309 в менеджер DRM 2314. Объект прав обычно передается отдельно от серий.

На фиг.24 показано устройство 2400, которое поддерживает систему передачи (например, 2025, 2225 и 2325), изображенную на фиг.20, 22 и 23, согласно одному из вариантов выполнения настоящего изобретения. В данном варианте выполнения настоящего изобретения устройство 2400 выполняет функции, обычно ассоциированные с уровнем канала (второй уровень модели протокола OSI). Процессор 2405 получает зашифрованные дейтаграммы из модуля шифрования (не показан) через интерфейс 2401 шифрования и соответствующую информацию о ключах из генератора ключей (не показан) через интерфейс 2403 ключей. Интерфейс 2407 передачи кодирует дейтаграммы для прямого исправления ошибок в приемном устройстве, выполняет мультипротокольную инкапсуляцию и форматирует серию с использованием закодированных дейтаграмм. (В данном варианте выполнения настоящего изобретения дейтаграммы включают как дейтаграммы контента, так и соответствующие дейтаграммы с ключами.)

На фиг.25 показано устройство 2500 для приемного устройства (например, приемных устройств 1926, 2026, 2226 и 2326, изображенных на фиг.19, 20, 22 и 23 соответственно), которое принимает мультимедийную трансляцию и применяет ключи IPSec в соответствии с данным вариантом выполнения настоящего изобретения. Устройство 2500 обрабатывает серию (например, серии 2501 и 2503) для извлечения дейтаграмм контента и ассоциированного потока ключей. В варианте выполнения настоящего изобретения, показанном на фиг.25, серия 2501 или серия 2503 содержит дейтаграммы контента (например, дейтаграммы 2505, 2507 и 2509 контента) с EPS-инкапсулированными пакетами IP, содержащими служебный контент и соответствующие ключевые дейтаграммы (например, соответствующую дейтаграмму 2511), включающие сообщения UDP о ключах. Ключи в сообщении UDP о ключах могут быть защищены с использованием менеджера DRM.

Устройство 2500 способно различать служебный контент и сообщения о ключах. Следовательно, модуль 2551 приемника отделяет дейтаграммы контента от дейтаграмм ключей. В данном варианте выполнения настоящего изобретения передающее устройство (не показано) присваивает дейтаграммам ключей более высокий приоритетный уровень, чем дейтаграммам контента. В данном варианте выполнения настоящего изобретения приоритетный уровень, ассоциированный с дейтаграммой, обозначен полем, например полем типа службы (ToS, type of service) или полем дифференцированных служб. Таким образом, дейтаграммы ключей посылаются в стек 2553 IP перед соответствующими дейтаграммами контента, так чтобы больше времени оставалось на обработку ключей модулем 2555 дешифровки ключей. Модуль дешифровки ключей получает зашифрованные ключи из стека 2553 IP через менеджер 2559 ключей.

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

Дешифрованные ключи подаются в модуль 2557 IPSec, так чтобы ассоциированные дейтаграммы контента в стеке 2553 IP можно было дешифровать и представить клиенту 2561.

На фиг.26 показано устройство 2600, которое принимает мультимедийную трансляцию и дешифрует принятые ключи 2601 IPSec в соответствии с еще одним вариантом выполнения настоящего изобретения. Менеджер 2653 ключей направляет зашифрованный ключ IPSec в сервер 2655 DRM для дешифровки второго уровня шифрования с использованием открытого алгоритма дешифровки и секретного ключа 2603. Сервер 2655 DRM возвращает в менеджер 2653 ключей ключ 2607, дешифрованный на втором уровне. Если менеджер 2653 ключей решает, что ключ зашифрован посредством шифрования первого уровня, менеджер 2653 ключей направляет ключ, дешифрованный на втором уровне, в сменный программный модуль 2657 СА. Сменный модуль 2657 СА использует секретный алгоритм дешифровки и секретный ключ 2605 для дешифровки ключа 2607, дешифрованного на втором уровне. В варианте выполнения настоящего изобретения секретный алгоритм дешифровки соответствует обычному алгоритму скремблирования (CSA, common scrambling algorithm) DVB, который распространяется Европейским институтом стандартизации в области связи (ETSI, European Telecommunications Standards Institute). Сменный программный модуль 2657 СА возвращает дешифрованный ключ 2609 в менеджер 2653 ключей, который пересылает дешифрованный ключ 2609 в стек 2651 IP.

В данном варианте выполнения настоящего изобретения сменный модуль 2657 СА выполняет первый уровень дешифровки, который является опционным и основан на специфическом для оператора СА-методе, который включает ассоциированный секретный ключ и ассоциированный алгоритм дешифровки. Второй уровень шифрования основан на открытом стандарте, например ОМА DRM2. Поскольку первый уровень шифрования является опционным, менеджер 2653 ключей определяет, был ли первый уровень шифрования применен к ключу 2607, дешифрованному на втором уровне. Если да, то менеджер 2653 ключей направляет ключ 2607, дешифрованный на втором уровне, в сменный программный модуль 2657 СА. В противном случае менеджер 2653 ключей направляет ключ 2607, дешифрованный на втором уровне, непосредственно в стек 2651 IP, поскольку ключ 2607, дешифрованный на втором уровне, оказывается полностью дешифрованным.

В данном варианте выполнения настоящего изобретения менеджер 2653 ключей определяет, был ли ключ 2607, дешифрованный на втором уровне, зашифрован на первом уровне, по исследованию ассоциированного индикатора шифрования (не показан), например, заголовка или поля сообщения. Ассоциированный индикатор шифрования утверждает "ДА", если ключ 2607, дешифрованный на втором уровне, был зашифрован на первом уровне, и "НЕТ", если ключ 2607, дешифрованный на втором уровне, не был зашифрован на первом уровне. Если ключ 2607, дешифрованный на втором уровне, был зашифрован на первом уровне, ассоциированный индикатор шифрования не является зашифрованным на первом уровне.

На фиг.27 показана система 2700 для развертывания нового защитного сменного программного модуля 2701 в приемном устройстве 2750 согласно одному из вариантов выполнения настоящего изобретения. Защитный сменный программный модуль 2701 сформатирован в виде инсталляционного пакета 2705 (например, SIS-файла, поддерживаемого Symbian). Инсталляционный пакет 2705 защищен (например, с использованием OMA-DRM2) с формированием защищенного пакета 2707 и доставляется в приемное устройство с использованием механизма доставки. Данный вариант выполнения настоящего изобретения поддерживает в механизме доставки различные каналы связи, включая канал беспроводной связи, в котором приемное устройство является беспроводным терминалом. Принятый защищенный пакет 2707 направляют в инсталлятор 2751 приложения, которому можно доверять. Инсталлятор 2751 приложения извлекает новый защитный сменный программный модуль 2701 из защищенного пакета 2707 и заменяет текущий защитный сменный программный модуль 2755, который установлен в приемном устройстве 2750 в настоящее время, на новый защитный сменный программный модуль 2701. Для извлечения нового защитного сменного программного модуля 2701 приемное устройство 2750 принимает объект 2703 прав, который обрабатывается менеджером DRM 2753. Следовательно, менеджер DRM 2753 указывает инсталлятору 2751 приложения, что замена защитного сменного программного модуля разрешена.

В вариантах выполнения настоящего изобретения конфигурации компонентов, изображенные на фиг.3-16, могут быть включены в системы, показанные на фиг.20, 22 и 23.

Способы и устройство для обеспечения избирательных прав пользователя

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

Управление правами на потоковый контент несколько затруднительно, поскольку имеется ограниченная ширина полосы. Естественное решение этой проблемы состоит в том, чтобы создавать и доставлять нормальным способом объекты прав (RO) с очень короткими периодами действительности, возможно содержащие тот же самый служебный ключ, но с другими правами использования. Однако это может быть тяжело реализовать на практике, поскольку служебные ключи меняют намного реже, чем, например, телевизионные программы на телевизионном канале. В качестве другого решения объекты прав или только выражения права можно было бы поставлять в сообщениях о потоке ключей (KSM, Key Stream Message). Однако частая посылка полных объектов прав в сообщениях KSM занимала бы довольно значительную часть ширины полосы, поскольку они должны быть адресованы каждому абоненту (или группе абонентов) по отдельности, так чтобы права получили только те, кто произвел оплату. Даже если права одинаковы для всех абонентов и доступ к сообщению KSM ограничен другими средствами, так чтобы сообщение KSM должно было содержать только часть объекта прав с выражением права, это выражение права может потребовать значительного количества битов, особенно если используется язык выражения прав типа XML. Типичные решения этой проблемы включают различные способы сжатия для приведения выражения прав к двоичной форме или сведения возможных прав к нескольким заранее заданным случаям ("состояниям использования"). Однако эти возможные решения не обеспечивают такого адекватного предоставления держателям прав (RI) достаточно избирательного управления в режиме, щадящем для ширины полосы, который можно было бы принять для практического использования.

На фиг.28 представлен пример известного технического решения. Контент шифруют (Е) ключом контента (СК) и передают в приемник (не показан). Приемник отдельно получает объект 2860 прав (RO), который включает ключ СК с набором прав использования. Принятый зашифрованный контент можно затем просматривать или использовать иначе, как предусмотрено в RO согласно полученным правам использования. Однако это известное техническое решение не слишком подходит для потокового контента.

На фиг.29 иллюстрируется аспект настоящего изобретения. Потоковый контент 2910 подают в транслятор и шифруют в блоке 2915 шифрования с использованием ключа 2925 трафика (ТК). В приемник (не показан) поступает ключ ТК 2925 с сообщением 2940 о потоке ключей (KSM), причем сообщение KSM 2940 сформировано путем шифрования 2930 с использованием служебного ключа (SK) 2950 и ключа ТК 2925. Поток ключей, который идет в сообщениях KSM, объявляется пользователям, имеющим определенный IP-адрес и номер порта. Поскольку ключ ТК 2925 шифруется ключом SK 2950, устройство использует объект 2960 прав (RO), который содержит ключ SK 2950, для дешифровки сообщения KSM 2940, чтобы быть в состоянии дешифровать потоковый контент 2910. В дополнение к обеспечению ключа SK 2950 объект 2960 прав (RO) обеспечивает также права 2965 использования.

Как правило, ключ ТК периодически меняется. На фиг.31 показан пример такой ситуации. Видно, что ключ ТК меняется несколько раз, в то время как ключ SK остается действительным. На практике количество изменений ключа ТК может быть намного более высоким. Когда ключ ТК меняется, новое сообщение KSM 2940 (фиг.29) подается в приемник с новым ключом ТК, зашифрованным тем же самым ключом SK 2950. Таким образом, хотя ключ SK 2950 остается тем же самым, объект 2960 прав позволяет приемнику дешифровать потоковый контент. Однако когда ключ SK меняется, необходим новый объект прав, так чтобы можно было дешифровать сообщения KSM, посланные в устройство, и использовать потоковый контент в разрешенном объеме. Обычно, чтобы механизм сообщений DRM мог работать, объект прав, купленный у держателя прав (RI), должен иметь относительно большие периоды действительности. В одном из вариантов выполнения настоящего изобретения, когда получен родительский объект прав, может также быть получен дочерний объект прав. Как обсуждалось выше в отношении ключей на фиг.4-16, в одном варианте выполнения настоящего изобретения ключи ТК поставляют в сообщении KSM до начала периода их действительности, так чтобы пользователь (устройство) мог дешифровать ключ (ключи) и битовые комбинации прежде, чем будет фактически принят потоковый контент (или его сегмент). Аналогично объект прав может быть приобретен до начала периода его действительности.

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

На фиг.30 различные провайдеры контента (СР, content provider) предоставляют контент транслятору. Кроме того, различные держатели прав (RI) общаются с транслятором или для определения категории программы, или для предоставления категорий программы, как обсуждается ниже. Следует отметить, что держатели прав и провайдеры контента могут как быть одним объектом, так и не быть. Контент шифруют, а затем передают в приемники. Следует отметить, что шифрование контента может быть произведено провайдером контента или транслятором, а ключи шифрования распределены соответственно между шифратором и держателем прав.

Например, рассмотрим службу и устройство для трансляции. От конкретного держателя прав (RI) устройство получает объект прав (RO) для получения доступа к определенному контенту, и в объекте прав на языке REL имеется описание прав использования контента. Хотя описание не меняется в течение периода действительности, язык REL может содержать права использования, которые являются условными и зависят от переменной "категория программы" языка REL. Таким образом, когда сообщения KSM меняют значение переменной "категория программы" в языке REL, (условные) текущие права использования в действительности могут измениться.

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

Перед обсуждением того, как "категории программы" могут быть переданы в приемник, рассмотрим фиг.32, на которой показан пример различных частей контента. Например, потоковый контент 3210 может включать категорию 3215 "новости", категорию 3217 "спорт", категорию 3219 "документалистика" и категорию 3221 "кинофильмы". Категория "новости" может быть дополнительно разделена на n категорий 3215-1, 3215-2…, 3215-n. Эти категории могут, например (но это не является ограничением), представлять заголовки, местные новости, новости из-за рубежа и т.д. Аналогично категория 3217 "спорт" может также быть дополнительно разделена на такие категории, как основные факты, счет, трансляция в прямом эфире и т.д. Альтернативно категории могут не иметь никакого отношения к типу контента, а просто быть определены для каждого различного набора разных прав использования. Например, могут быть категории "с большими ограничениями", "с некоторыми ограничениями", "нормальная" и "либеральная", что отражает степени разрешения, данного пользователю.

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

В первом способе определения категории программы в языке REL в одном из аспектов настоящего изобретения транслятор "сортирует" потоковый контент на различные категории. Например, количество категорий программ может быть относительно малой величиной, например 4 различными категориями, или может быть относительно большой величиной, например 256 различными категориями программ. Естественно, что при увеличении количества категорий программ понадобятся дополнительные биты, и, таким образом, два бита могут обеспечить информацию о четырех категориях программ, в то время как 8 битов необходимы для обеспечения информации о 256 категориях программ. Например, в службе телевидение для переносных систем каждая телевизионная программа отнесена к одной из множества категорий программ, которые могут включать новости, низкорейтинговые (Iv, low value) шоу, высокорейтинговые (hv, high value) шоу, низкорейтинговые спортивные состязания, высокорейтинговые спортивные состязания, старые кинофильмы, новые кинофильмы и т.д. Держатели прав (RI) не могут влиять на категории (которые установлены транслятором и одинаковы для всех держателей прав), но они могут свободно использовать широкий диапазон значений переменной "категория программы" в языке REL (например, от 0 до 255) для своих прав использования, выраженных в объектах прав (RO) языка REL, которые они поставляют в устройство. Однако, как правило, на практике оптимальным является небольшое количество категорий программ, например 12-16. Между транслятором и держателями прав не требуется никакой дополнительной связи. Каждый из таких сегментов программы может быть ассоциирован с набором прав использования (в настоящем описании: "категориями программ"), включая "просмотр в прямом эфире", "запись и воспроизведение в течение 48 часов", "запись и воспроизведение в любое время", "ретрансляцию и копирование (пересылку) в любое время" или некоторые другие аналогичные примеры.

Таким образом, объект прав (RO) может включать условные права, выраженные на языке REL, которые зависят от значения категории программы. Таким образом, пользователь может купить полные права, так чтобы объект прав обеспечивал максимально допустимые права для контента. Альтернативно пользователь может выбрать свободный льготный объект прав, который обеспечивает намного более ограниченные права и может позволить просматривать только часть потокового контента. Периодически объект прав будет обновляться, когда меняется ключ SK, и, таким образом, права использования могут меняться от одного объекта прав к другому. Пользователь принимает один или несколько объектов прав при заказе/покупке/абонировании/возобновлении обслуживания или его части. В одном варианте выполнения настоящего изобретения пользователь может сначала получить "родительский" [базовый] объект прав, а "дочерние" объекты прав может приобрести или создать позже. Если пользователь не заказал (купил/абонировал) сегмент программы, который принял, пользователю сообщают об этом ("Вы не имеете прав на эту программу/(сегмент программы)") и/или ему сообщают о том, как купить права.

В другом аспекте настоящего изобретения, как показано на фиг.33, держатели прав (RI) устанавливают категории и передают их транслятору, который затем помещает эти категории в сообщения KSM. Поскольку имеется множество держателей прав, может быть полезно ограничить количество битов, которые доступны держателю прав, до двух битов. В таком случае диапазон категорий программ может составлять 0…3. Однако этот диапазон зависит от держателя прав и поэтому может непосредственно касаться прав использования специфической части потокового контента (вместо типа потокового контента в более общем случае). В этом случае, вместо предоставления единственного объекта прав, можно предоставить четыре объекта прав, каждый с набором прав использования, сформированным держателем прав.

В механизме объекта прав, используемом на фиг.33, должно иметься средство для индикации, какое значение категории к какому держателю прав относится, но предпочтительно без использования идентификаторов держателя прав (которые занимают более двух битов). В одном из вариантов выполнения настоящего изобретения каждое сообщение KSM 3340 содержит вектор из N значений категории (для некоторого N), где каждое значение категории может занимать два бита. В другом варианте выполнения настоящего изобретения значения категории могут занимать более двух битов. Объект прав, переданный в приемник, содержит индекс держателя прав (RI), лежащий в диапазоне 1…N, так чтобы значение категории в каждом индексе от RI_1 до RI_N соответствовало набору объектов прав. В других вариантах выполнения настоящего изобретения для значений категории могут использоваться один или более битов или комбинаций битов внутри сообщения KSM. Хотя сообщение KSM может включать указанный вектор, для создания значения категории, ассоциированного с держателем прав, могут использоваться и другие форматы и протоколы. Кроме того, в одном из вариантов выполнения настоящего изобретения множество битов и/или наборов двоичных знаков в пределах вектора могут храниться для последующего использования.

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

Как показано выше, в этом случае пользователь получает от держателя прав #1 четыре объекта прав, каждый с некоторым классом прав использования. Преимущество использования классов прав использования состоит в том, что общее количество и размер объектов прав может быть меньше, чем в случае полного набора объектов прав, если права использования предлагаются для покупки на уровне сегментов программы. Когда пользователь принимает сообщение KSM, несущее действительный ключ ТК, набор битов в положении, соответствующем RI#1, позволяет пользователю выбрать объект прав (RO), который соответствует его покупке. Например, значение 0 в позиции RI#1 соответствует RO1, значение 1 соответствует RO2, значение 2 соответствует RO3 и значение 3 соответствует RO4. Поскольку ключи ТК могут меняться от одного сегмента программы к другому, пользователь может использовать свои права в соответствии со своим заказом (покупкой). Следует отметить, что пользователь "слушает" сообщения KSM, которые ему анонсированы (имеют его IP-адрес и номер порта).

Например, в службе телевидения для переносных систем, основанной на расписании программы передач, держатели прав выбирают одну из этих 4 категорий для каждой программы, сообщают их транслятору, и транслятор включает эти категории в сообщения KSM. Для некоторого держателя прав эти четыре категории могут быть 1) разрешением на просмотр только в прямом эфире, 2) разрешением записи и воспроизведения в течение 48 часов, 3) разрешением записи и воспроизведения в любое время и 4) разрешением записи, воспроизведения и копирования на другие устройства в любое время. Этот пример, однако, является просто иллюстрацией, и могут предоставляться другие наборы прав.

В вышеуказанной ситуации все покупатели набора объектов прав у этого держателя прав могут иметь одинаковый набор прав. Например, сегмент RI#J в сообщении KSM 3340 может соответствовать конкретному пакетному соглашению, в то время как второй сегмент RI#J+1 может соответствовать другому пакетному соглашению. Однако следует отметить, что категория программы для каждого держателя прав специфична для ключа ТК; таким образом, тот же самый набор объектов прав может обеспечить различные права использования для различных ключей ТК, а кроме того, различные наборы объектов прав могут обеспечить различные наборы и/или комбинации прав использования.

Таким образом, для одного набора объектов прав сегмент RO1 может обеспечить права использования только на просмотр, в то время как в другом наборе объектов прав сегмент RO1 может разрешить сдвиг во времени.

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

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

Таким образом, аспекты настоящего изобретения обеспечивают эффективный в смысле ширины полосы способ предоставления прав, применимый ко всем абонентам, но который может меняться от программы к программе и от временного периода к временному периоду и при этом обеспечивать возможность использования всего богатства языка REL для определения этих прав для каждой категории программы. Изобретение может быть использовано для служб IPDC в системах DVB-T, DVB-H, MediaFLO, ОМА Broadcast и других.

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

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

Изобретение относится к области доставки защищенного мультимедийного контента. Технический результат заключается в уменьшении используемой ширины полосы. Сущность изобретения заключается в том, что транслятор обеспечивает потоковый контент, который шифруют с использованием ключа трафика. Ключ трафика предоставляют пользователям посредством сообщения о потоке ключей, которое зашифровывают служебным ключом. Пользователь получает по меньшей мере один объект прав от держателя прав, и этот по меньшей мере один объект прав содержит служебный ключ, необходимый для использования потокового контента. Этот по меньшей мере один объект прав содержит также информацию о правах использования, которые могут формулироваться держателем прав так, чтобы в зависимости от пользователя и/или приемного устройства предоставлялись различные права. Сообщение о потоке ключей может включать значение переменной "категория программы", которая указывает тип контента и, совместно с объектом прав, определяет, какие права использования имеются для данного потокового контента. 7 н. и 14 з.п. ф-лы, 33 ил.

1. Способ передачи потока данных в устройство, включающий:
(A) передачу другим устройством потокового контента, зашифрованного ключом трафика;
(B) передачу упомянутым другим устройством сообщения о потоке ключей, зашифрованного с использованием служебного ключа, причем сообщение о потоке ключей включает ключ трафика, при этом с первым держателем прав ассоциировано первое значение категории программы, а со вторым держателем прав ассоциировано второе значение категории программы;
(C) предоставление упомянутым другим устройством первого объекта прав со служебным ключом, в результате чего служебный ключ обеспечивает дешифровку сообщения о потоке ключей, а сообщение о потоке ключей обеспечивает дешифровку потокового контента, и
(D) предоставление упомянутым другим устройством второго объекта прав, третьего объекта прав и четвертого объекта прав, причем первый, второй, третий и четвертый объекты прав формируют набор объектов прав,
при этом по меньшей мере одно из первого и второго значений категории программы соответствует одному из первого, второго, третьего и четвертого объектов прав.

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

3. Способ по п.2, в котором первое и второе значения категории программы выражены двумя битами или большим количеством битов.

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

5. Способ по п.1, дополнительно включающий:
(Е) изменение ключа трафика; и (F) повторение шагов (А) и (В).

6. Способ по п.1, в котором упомянутое устройство является приемником.

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

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

9. Способ по п.8, в котором шаг (В) включает:
(i) прием устройством значения категории программы.

10. Способ по п.8, в котором шаг (Е) включает: (1) отображение устройством потока данных.

11. Способ по п.8, в котором шаг (Е) включает: (i) сохранение устройством потока данных.

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

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

14. Способ приема потока данных от системы связи в течение мультимедийного сеанса связи, включающий:
(A) прием устройством зашифрованного потока данных, причем этот поток данных зашифрован ключом трафика;
(B) прием устройством зашифрованного сообщения о потоке ключей, причем это зашифрованное сообщение о потоке ключей включает ключ трафика;
(C) использование устройством ключа графика и служебного ключа для дешифровки потока данных; и
(D) повторение устройством шагов (А), (В) и (С) после изменения ключа трафика.

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

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

17. Способ по п.16, дополнительно содержащий:
повторение шагов (А) и (В) при изменении ключа трафика.

18. Способ по п.17, дополнительно содержащий:
прием второго значения категории программы, которое ассоциировано со вторым правом использования в объекте прав.

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

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

21. Устройство по п.20, в котором множество прав использования ассоциировано с множеством значений категории программы.