Способ передачи/приема информации шифрования в мобильной системе вещания и система для такового

Способ передачи/приема информации шифрования в мобильной системе вещания и система для такового

Иллюстрации

Показать все

Реферат

2420-150765RU/016

СПОСОБ ПЕРЕДАЧИ/ПРИЕМА ИНФОРМАЦИИ ШИФРОВАНИЯ

В МОБИЛЬНОЙ СИСТЕМЕ ВЕЩАНИЯ И СИСТЕМА ДЛЯ ТАКОВОГО

ОПИСАНИЕ

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

УРОВЕНЬ ТЕХНИКИ

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

Услуга службы BCAST может быть платной услугой. Чтобы удовлетворять требованию технологии охраны авторского права для предотвращения незаконного копирования и распространения услуги, Проект (3 GPP) партнерства систем связи 3-го поколения или Открытый союз (OMA) по мобильной связи, который является группой разработки стандартов, предложил технологию управления (DRM) правами на цифровые материалы, которая основана на приспособляемости и средстве, предназначенного для Right Object (RO, объект прав) пользователя. Однако мобильная система вещания не дает определения способа шифрования, предназначенного для защиты услуги между объектами, и интерфейсов между объектами, так что имеется потребность дать определение способа шифрования.

Соответственно, имеется потребность в усовершенствованных устройстве и способе для передачи/приема информации шифрования в мобильной системе вещания.

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

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

Согласно одному примерному аспекту настоящего изобретения обеспечивается способ передачи/приема информации шифрования в мобильной системе вещания, поддерживающей службу вещания (BCAST, broadcast), в котором мобильная система вещания включает в себя Управление подпиской службы BCAST(BCAST Subscription Manager, сокращенно BSM), чтобы управлять абонентской информацией терминала и формировать ключ шифрования, с помощью которого терминал расшифровывает, по меньшей мере, одну зашифрованную услугу или контент, и Распространение/адаптацию (BCAST Service Distribution/ Adaptation, сокращенно BSD/A) услуги службы BCAST, чтобы передавать ключ шифрования. Способ содержит этапы передачи посредством BSD/A на BSM первого сообщения запроса, включающего в себя, по меньшей мере, один идентификатор услуги или контента, и запрашивающего доставку материала (Registration Key Material, сокращенно RKM) ключа регистрации, предназначенного для регистрации услуги вещания для терминала, и после приема первого сообщения запроса, осуществления передачи посредством BSM на BSD/A сообщения ответа на первый запрос, включающего в состав RKM.

В одном примерном варианте осуществления способ дополнительно содержит этапы передачи посредством BSD/A на BSM второго сообщения запроса, включающего в себя, по меньшей мере, один идентификатор услуги или контента, и запрашивающего доставку сообщения долгосрочного ключа (Long-Term Key Message, сокращенно LKM), поставленного на терминал в течение подписки на услугу вещания, и после приема второго сообщения запроса, осуществления посредством BSM передачи на BSD/A сообщения ответа на второй запрос, включающего в состав LKM.

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

Согласно другому примерному аспекту настоящего изобретения обеспечивается способ передачи/приема информации шифрования в мобильной системе вещания, поддерживающей службу (BCAST) вещания, в котором мобильная система вещания включает в себя Управление (BSM) подпиской службы BCAST для управления абонентской информацией терминала и формировать ключ шифрования, с помощью которого терминал расшифровывает, по меньшей мере, одну зашифрованную услугу или контент, и Распространение/адаптацию (BSD/A) услуги службы BCAST, чтобы передавать ключ шифрования. Способ содержит стадию передачи посредством BSM на BSD/A первого сообщения доставки, включающего в состав, по меньшей мере, один идентификатор услуги или контента, и включающего материал (RKM) ключа регистрации, предназначенный для регистрации услуги вещания для терминала, и BSD/A осуществляет передачу на BSM первого сообщения подтверждения доставки, включающего в состав информацию, указывающую успех/неудачу в приеме первого сообщения доставки.

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

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

Согласно дополнительно еще одному примерному аспекту настоящего изобретения обеспечивается мобильная система вещания, поддерживающая службу вещания (BCAST). Примерная мобильная система вещания включает в себя управление подпиской (BSM) службы BCAST, чтобы управлять абонентской информацией терминала, и для передачи на распространение/адаптацию (BSD/A) услуги BCAST первое сообщение доставки, включающее материал ключа регистрации (RKM), предусмотренный для регистрация услуги вещания терминала и включающего в состав, по меньшей мере, один идентификатор или услуги, или контента; и BSD/A для передачи на BSM сообщение подтверждения первой доставки, включает информацию, указывающую успех/неудачу в приеме первого сообщения доставки, и передает RKM на терминал.

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

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

Согласно следующему примерному аспекту настоящего изобретения обеспечивается мобильная система вещания, поддерживающая службу (BCAST) вещания. Примерная мобильная система вещания включает в себя Распространение/адаптацию (BSD/A) услуги службы BCAST, чтобы передавать на Управление (BSM) подпиской службы BCAST первое сообщение запроса, запрашивающее доставку Материала (RKM) ключа регистрации, предназначенного для регистрации услуги вещания терминала, и включающего в состав, по меньшей мере, один идентификатор услуги или контента, и после приема RKM от BSM, передавать RKM на терминал и BSM для осуществления управления абонентской информацией терминала, и после приема первого сообщения запроса, передавать на BSD/A сообщение ответа на первый запрос, включающее RKM.

В примерном варианте осуществления BSD/A передает на BSM второе сообщение запроса, запрашивающее доставку Сообщения (LKM) долгосрочного ключа, поставленного на терминал в течение подписки на услугу вещания и включающего в состав, по меньшей мере, один идентификатор услуги или контента, и после приема LKM от BSM, передает LKM на терминал и после приема второго сообщения запроса BSM передает на BSD/A второе сообщение ответа запроса, включающее LKM.

В примерном варианте осуществления BSD/A передает на BSM третье сообщение запроса, запрашивающее доставку сообщения (SKM) краткосрочного ключа, включающее в состав Ключ (TEK) шифрования трафика, используемый терминалом для расшифровывания услуги вещания, и включающее в состав, по меньшей мере, один идентификатор услуги или контента, и после приема SKM от BSM, передает SKM на терминал и после приема третьего сообщения запроса BSM передает на BSD/A третье сообщение ответа запроса, включающее в состав SKM.

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

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

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

Фиг.2A и 2B - схемы, иллюстрирующие поток информации между объектами сервера согласно примерному варианту осуществления настоящего изобретения, для Защиты услуги (Service Protection) и Защиты контента (Content Protection), соответственно;

Фиг.3A и 3B - схемы, иллюстрирующие способ обмена сообщениями между BSA и BSM для Защиты контента согласно примерному варианту осуществления настоящего изобретения;

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

Фиг.5A и 5B - схемы, иллюстрирующие способ получения TEK посредством BSD/A для Защиты услуги согласно примерному варианту осуществления настоящего изобретения;

Фиг.6 - схема, иллюстрирующая стек протоколов для интерфейса между BSD/A и BSM для Защиты услуги согласно примерному варианту осуществления настоящего изобретения;

Фиг.7А и 7B - схемы, иллюстрирующие способ получения SKM посредством BSD/A согласно примерному варианту осуществления настоящего изобретения;

Фиг.8А и 8B - схемы, иллюстрирующие способ получения LKM посредством BSD/A согласно примерному варианту осуществления настоящего изобретения;

Фиг.9А и 9B - схемы, иллюстрирующие способ получения RKM посредством BSD/A для Защиты услуги и Защиты контента согласно примерному варианту осуществления настоящего изобретения;

Фиг.10 - схема, иллюстрирующая стек протоколов для интерфейса между BSD/A и BSM для Защиты услуги согласно примерному варианту осуществления настоящего изобретения;

Фиг.11 - схема, иллюстрирующая стек протоколов для интерфейса между BSD/A и BSM для Защиты контента согласно примерному варианту осуществления настоящего изобретения;

Фиг.12 - схема, иллюстрирующая Терминал в мобильной системе вещания согласно примерному варианту осуществления настоящего изобретения.

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

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

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

В нижеследующем подробном описании будут представлены примерные варианты осуществления настоящего изобретения для достижения вышеупомянутых и других целей. Хотя для удобства будут использоваться именования объектов, определенных в Проекте (3 GPP) партнерства систем связи 3-го поколения, который является стандартом асинхронной мобильным связи, или Открытым союзом (Open Mobile alliance, сокращенно OMA) по мобильной связи, который является стандартом по приложениям терминала, стандарты и именования не должны ограничивать объем настоящего изобретения, и настоящее изобретение может быть применимо к системам, имеющим сходные технические исходные данные.

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

Примерная мобильная система вещания и поток сообщений в ней теперь будут описаны подробно со ссылкой на Фиг.1.

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

Сначала будет описана функция каждого объекта по Фиг.1. Создание контента (Content Creation, сокращенно CC) 10 является поставщиком услуги Службы вещания (BCAST). Услуга BCAST может включать в себя услугу вещания аудио/видео, услугу загрузки по сети файла музыки/данных, и подобное.

Приложение услуги (Service Application) (BSA) 20 службы BCAST обрабатывает данные услуги BCAST, поставленные от Создания контента 10 в формате, соответствующем сети (с поддержкой) BCAST, формирует данные услуги BCAST, и формирует стандартизированные метаданные, необходимые для руководства мобильного вещания.

Распространение/адаптация услуги (BSD/A) 30 службы BCAST устанавливает средство связи, через которое оно будет передавать данные услуги BCAST, поставленные от BSA 20, определяет план доставки услуги BCAST, и формирует руководство мобильного вещания.

Управление подпиской (BSM) 40 службы BCAST управляет информацией о подписке и информацией о предоставлении (подготовке) услуг для приема услуги BCAST, и информацией относительно устройства для приема услуги BCAST.

Терминал 50 является терминалом, способным принимать услуги BCAST, и может быть соединен с сетью сотовой связи в соответствии с возможностью терминала. При этом будет полагаться, что терминал 50 является терминалом, который может быть соединен с сетью сотовой связи.

Теперь будет выполнено описание Защиты контента и Защиты услуги в соответствии с примерным вариантом осуществления настоящего изобретения. «Защита контента» защищает пересылаемые файлы и потоки. Управление правами в отношении контентов выполняется посредством терминала. Защищенные контенты зашифровываются посредством BSA 20 и затем пересылаются на терминал 50. Защита услуги защищает пересылаемые файлы и потоки, и шифрование над контентом выполняется посредством BSD/A 30. Защита контента является подобной Защите услуги в терминах защиты контентов. Однако, в отличие от Защиты услуги, Защита контента различается согласно использованию/не использованию DRM. То есть Защита контента включает в себя функцию управления действительным диапазном для контентов, которые терминал получил, и возможностью создания копии контентов. Относительно Защиты контента, контенты зашифровываются посредством BSA 20 и затем пересылаются на Терминал 50.

И для Защиты услуги, и для Защиты контента BSM 40 выполняет управление подпиской на терминале. Если услуга вещания поставлена на терминал 50 через объекты для каждой функции, пользователь терминал 50 может пользоваться услугой. В документе сообщение, относящееся к Защите услуги и Защите контента, будет называться 'информацией шифрования'.

Теперь со ссылкой Фиг.1 будет описан примерный способ доставки сообщения информации шифрования. Чтобы использовать пересылаемые услугу и контенты, Терминал 50 должен зарегистрироваться в BSM 40 и затем принять Материал (RKM) ключа регистрации на этапе 100. После этого, если Терминал 50 выполняет подписку на конкретную услугу вещания, он должен получить на этапе 110 сообщение (LKM) долгосрочного ключа. Кроме этого, Терминал 50 должен получить на этапе 120 Сообщение (SKM) краткосрочного ключа, используемое для фактического расшифровывания зашифрованных контентов и услуги. Терминал 50 может расшифровывать LKM с использованием RKM, и может расшифровывать SKM с использованием Ключа (SEK) шифрования услуги, полученного в результате расшифровывания. SKM включает в себя Ключ (TEK) шифрования трафика, и Терминал 50 может фактически расшифровывать зашифрованную услугу и контенты, используя TEK. На Фиг.1 показано, что сообщения информации шифрования, такие как RKM, LKM и SKM, доставляются от BSD/A 30 на Терминал 50 по каналу вещания. Терминал 50, способный использовать интерактивный канал, хотя не показано на Фиг.1, может в качестве альтернативы принимать RKM и LKM через прямую связь с BSM 40.

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

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

Таблица 1Формат Req-1 сообщения запроса
Поле Name	Тип	Категория	Количество элементов	Описание	Тип данных
Tag	E	М	1	Тип сообщения	Integer (целое)
Version	E	O	1	Версия стандарта, поддерживаемого этим сообщением	Integer
Message ID	E	М	1	Идентификатор данного сообщения	String(строковый)
Destination	E	М	1	Идентификатор получателя сообщения	String
Source	E	М	1	Идентификатор источника сообщения	String
Service/Content Info	E	М	1	Связанная информация, такая как идентификатор услуги/контента	String
Time	E	0	1	Время, когда доставлено сообщение	String

Таблица 2Формат Res-1 сообщения ответа
Поле Name	Тип	Категория	Количество элементов	Описание	Тип данных
Tag	E	М	1	Тип сообщения	Integer
Version	E	O	1	Версия стандарта, поддерживаемого данным сообщением	Integer
Message ID	E	М	1	Идентификатор сообщения запроса	String
Destination	E	М	1	Идентификатор получателя сообщения	String
Source	E	М	1	Идентификатор источника сообщения	String
Service/Content Info	E	O	1	Связанная информация, такая как идентификатор услуги/контента	String
Status	E	М	1	Результат ответа на сообщение	Integer
Data	E	O	1	Информация, планируемая для доставки получателю	Binary
Time	E	O	1	Время, в которое доставлено сообщение	String

Таблица 3Формат Res-2 сообщения ответа
Поле Name	Тип	Категория	Количество элементов	Описание	Тип данных
Tag	E	М	1	Тип сообщения	Integer
Message ID	E	М	1	Идентификатор сообщения запроса	String
Status	E	М	1	Результат ответа на сообщение	Integer
Data	E	0	1	Информация, планируемая для доставки получателю	Binary(двоичный)

Таблица 4Формат Tra-1 сообщения доставки
Поле Name	Тип	Категория	Количество элементов	Описание	Тип данных
Tag	E	М	1	Тип сообщения	Integer
Version	E	O	1	Версия стандарта, поддерживаемого данным сообщением	Integer
Target Terminal	E	М	1	Целевой терминал для этого сообщения	String
Message ID	E	М	1	Идентификатор данного сообщения	String
Destination	E	М	1	Идентификатор получателя сообщения	String
Source	E	М	1	Идентификатор источника сообщения	String
Service/ContentInfo	E	М	1	Связанная информация, такая как идентификатор услуги/контента	String
Data	E	М	1	Информация, планируемая для доставки получателю	Binary
Time	E	O	1	Время, в которое доставлено сообщение	String

Таблица 5Формат Con-1 сообщения подтверждения
Поле Name	Тип	Категория	Количество элементов	Описание	Тип данных
Tag	E	M	1	Тип сообщения	Integer
Version	E	O	1	Версия стандарта, поддерживаемого данным сообщением	Integer
Message ID	E	M	1	Идентификатор сообщения доставки	String
Destination	E	М	1	Идентификатор получателя сообщения	String
Source	E	М	1	Идентификатор источника сообщения	String
Service/ContentInfo	E	O	1	Связанная информация типа идентификатор услуги/контента	String
Status	E	М	1	Результат Подтверждения сообщения	Integer
Time	E	O	1	Время, в которое доставлено сообщение	String

Таблица 6Формат Con-2 подтверждения сообщения
Поле Name	Тип	Категория	Количество элементов	Описание	Тип данных
Tag	E	М	1	Тип сообщения	Integer
Message ID	E	М	1	Идентифиактор сообщения доставки	String
Status	E	М	1	Результат Подтверждения сообщения	Integer

В таблицах поле Name (поле имени) указывают имена элементов и атрибутов, образующих соответствующее сообщение. «Тип» (type) указывает соответствие соответствующего имени типу элемента или атрибута. Каждый элемент имеет значения E1, E2, E3 и E4. E1 означает верхний элемент для целого сообщения, E2 указывает подэлемент E1, E3 указывает подэлемент E2, и E4 указывает подэлемент E3. Атрибут обозначается посредством A, и А указывает атрибут соответствующего элемента. Например, А под E1 указывает атрибут E1. 'Category' (категория) используется для указания, является ли соответствующий элемент или атрибут обязательным, и имеет значение M, если значение является обязательным, и значение O, если значение является необязательным. 'Cardinality' (количество элементов в связи) указывает связи между элементами, и имеет значения {0, 0..1, 1, 0..n, 1..n}, где "0" означает необязательную связь, "1" означает обязательную связь, и 'n' означает возможность наличия множества значений. Например, '0..n' означает возможность, что соответствующего элемента нет или есть n соответствующих элементов. 'Description' (описание) определяет значение соответствующего элемента или атрибута. 'Data Type' (тип данных) указывает тип данных соответствующего элемента или атрибута.

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

В сообщении ответа и сообщении подтверждения значение Status='0' указывает, что сообщения запроса и доставки были приняты успешно, и связанный пункт был выполнен, и значение Status='1' указывает, что прием сообщений запроса и доставки был неудачным, и исполнение связанного пункта было неудачным.

Каждое сообщение может получить улучшение характеристики, используя Res-2 или Con-2, которые являются сокращенным сообщением, предусмотренным использующим Message ID, как показано в поле Применяемый формат сообщения из Таблицы 7 ниже.

Таблица 7Тип Сообщения и Применяемый формат сообщения на основе поля Tag
Поле Tag	Тип сообщения	Применяемый формат сообщения	Информация доставки
1	Сообщение запроса TEK	Req-1	TEK
2	Ответное сообщение на запрос TEK	Res-1 или Res-2
3	Сообщение доставки TEK	Tra-1
4	Сообщение подтверждения доставки TEK	Con-1 или Con-2
5	Сообщение запроса SKM	Req-1	SKM
6	Ответное сообщение на запрос SKM	Res-1 или Res-2
7	Сообщение доставки SKM	Tra-1
8	Сообщение подтверждения доставки SKM	Con-1 или Con-2
9	Сообщение запроса LKM	Req-1	LKM
10	Ответное сообщение на запрос LKM	Res-1 или Res-2
11	Сообщение доставки LKM	Tra-1
12	Сообщение подтверждения доставки LKM	Con-1 или Con-2
13	Сообщение запроса RKM	Req-1	RKM
14	Ответное сообщение на запрос RKM	Res-1 или Res-2
15	Сообщение доставки RKM	Tra-1
16	Сообщение подтверждения доставки RKM	Con-1 или Con-2

Примерные варианты осуществления настоящего изобретения обеспечивают способ для обмена между BSA 20 и BSM 40, и между BSD/A 30 и BSM 40 информацией о шифровании, такой как TEK, SKM, LKM и RKM, относящейся к Защите услуги и Защите контента. На Фиг.2A и 2B показана информация, обмениваемая между объектами, и подробные примеры будут описаны со ссылкой на сопроводительные чертежи.

На Фиг.2A и 2B показаны схемы, иллюстрирующие информационный поток между объектами сервера в соответствии с примерным вариантом осуществления настоящего изобретения для Защиты услуги и Защиты контента, соответственно. Что касается Фиг.2A и 2B, объект для исполнения Защиты услуги включает в себя Защиту-шифрование услуги (SP-E) 31 и Распространение ключа-защиты услуги (SP-KD) 32 в BSD/A 30. SP-E 31 используется, чтобы шифровать услугу, и SP-KD 32 используется, чтобы передавать связанную информацию ключа шифрования на Терминал 50 по каналу вещания. BSM 40, включающее в себе Защиту-управление услуги (SP-M) 41, управляет подпиской терминала и формированием ключа шифрования.

Для Защиты контента (объект) Распространение файла (FD) 33 в BSD/A 30 принимает информацию о ключе шифрования, доставленную от BSM 40, и по каналу вещания доставляет принятую информацию о ключе шифрования на терминал. BSM 40, включающее в себе Защиту-управление контента (CP-M) 42, управляет подпиской терминала и формированием ключа шифрования. BSA 20, включающее в себе Защиту-шифрование контента (CP-E) 21, управляет шифрованием контентов. На Фиг.3А и 3B показаны схемы, иллюстрирующие способ обмена информацией между BSA 20 и BSM 40 для Защиты контента в соответствии с примерным вариантом осуществления настоящего изобретения, и будет описана информация, передаваемая для Защиты контента. В примерном способе Защиты контента, поскольку шифрование выполняется в BSA 20, то сформированный BSM 40 ключ шифрования поставляется на BSA 20. Поскольку ключом, используемым для шифрования контента в мобильной системе вещания, является TEK, то, что сформированный посредством BSM 40 TEK должен быть доставлен на BSA 20.

Как показано на Фиг.3A, примерный способ доставки начинается с сообщения запроса TEK, передаваемого от BSA 20 на этапе 300, и поле Tag, указывающее сообщение запроса TEK, установлено в '1'. Поле Destination указывает BSM 40, и поле Source указывает BSA 20. После приема сообщения запроса TEK, CP-M 42 в BSM 40 на этапе 310 передает ответное сообщение на запрос TEK со значением Tag='2'. Если поле Status в ответе установлено в '0', TEK сохраняется в поле Data перед передачей, и если TEK не передается, поле Status перед передачей устанавливается в '1'.

В способе по Фиг.3B, BSM 40 передает TEK без запроса от BSA 20. В примерном варианте осуществления CP-M 42 в BSM 40 на этапе 320 передает на CP-E 21 в BSA 20 сообщение доставки TEK со значением Tag='3' с наличием TEK, включенного в поле Data. В ответ BSA 20 на этапе 330 передает на BSM 40 сообщение подтверждения доставки TEK со значением Tag='4'. В примерном варианте осуществления поле Status установлено в '0', указывая нормальный прием TEK. Если прием TEK является неудачным, поле Status установлено в '1'.

На Фиг.4 иллюстрируется стек протоколов, образующий интерфейс обмена информацией между BSA 20 и BSM 40 в соответствии с примерным вариантом осуществления настоящего изобретения. Что касается Фиг.4, BSA 20 и BSM 40 могут обмениваться данными путем достижения совместимости друг с другом, используя протокол. Защита доставки данных между BSA 20 и BSM 40 может реализовывать защиту данных без ограничения протокола и данных верхнего уровня, используя протокол IPSec. Протоколы TCP и TTP/TTP присутствуют в качестве верхнего уровня IPSec, и CP-E 21 в BSA 20 и CP-M 42 в BSM 40 присутствуют на нем для обмена сообщениями и связанного действия интерфейса.

На Фиг.5A и 5B иллюстрируется способ получения TEK, в котором BSD/A 30 шифрует и осуществляет вещание услуги для Защиты услуги в соответствии с примерным вариантом осуществления настоящего изобретения.

Что касается Фиг.5A, SP-E 31 в BSD/A 30 на этапе 400 передает на BSM 40 сообщение запроса TEK. Сообщение запроса TEK имеет значение Tag '1', и его поля Destination и Source указывают BSM 40 и BSD/A 30, соответственно. В ответ на сообщение запроса TEK, BSM 40 на этапе 410 передает ответное сообщение на запрос TEK со значением Tag='2'. BSM 40 устанавливает значение поля Status в '0', когда оно передает запрошенный TEK. В противном случае BSM 40 устанавливает значение Status в '1'. Когда значение Status установлено в '0', TEK сохраняется в поле Data сообщения ответа на запрос TEK.

В примерном варианте осуществления, показанном на Фиг.5B, BSM 40 сразу передает TEK без запроса от BSD/A 30. Что касается Фиг.5B, SP-M 41 в BSM 40 на этапе 420 передает на BSD/A 30 сообщение доставки TEK со значением Tag='3' с наличием TEK, включенного в него. В ответ BSD/A 30 на этапе 430 передает на BSM 40 сообщение подтверждения доставки TEK со значением Tag='4'. Если BSD/A 30 успешно принял TEK, он устанавливает в '0' значение Status в сообщении подтверждения доставки TEK. Однако, если BSD/A 30 потерпел неудачу в приеме TEK, он устанавливает значение Status в '1'.

На Фиг.6 показана схема, иллюстрирующая стек протоколов для интерфейса обмена информацией между BSD/A 30 и BSM 40 для Защиты услуги в соответствии с примерным вариантом осуществления настоящего изобретения. Безопасность между интерфейсами защищается с использованием протокола IPSec, и протокол, относящийся к способу защиты услуги передается через TCP и HTTP/HTTPS. Переданной от BSM 40 информацией о шифровании управляет BSD/A 30, и информация шифрования включает в себя RKM, LKM, SKM и TEK.

На Фиг.7A и 7B показаны схемы, иллюстрирующие способ получения SKM посредством BSD/A 30 в соответствии с примерным вариантом осуществления настоящего изобретения. Этот примерный способ можно применяться для Защиты услуги и/или контента. SKM является ключом шифрования, с помощью которого терминал может расшифровывать услугу или контент, зашифрованные посредством BSD/A 30. SKM может быть доставлен от BSM 40 на Терминал 50 по интерактивному каналу. Однако в среде канала вещания, SKM должен доставляться от BSD/A 30 на Терминал 50 по каналу вещания.

Что касается Фиг.7A, BSD/A 30 на этапе 500 передает на BSM 40 сообщение запроса SKM. В BSM 40, объектом для обработки сообщения может быть SP-M 41 для Защиты услуги и/или CP-M 42 для Защиты контента. Сообщение запроса SKM имеет значение '5' поля Tag, и его поля Destination и Source указывают BSM 40 и BSD/A 30, соответственно. В ответ на сообщение запроса SKM, BSM 40 на этапе 510 передает сообщение ответа на запрос SKM со значением Tag='6'. Когда BSM 40 передает запрошенное SKM, оно устанавливает значение Status в '0' и поле Data в SKM. В противном случае, когда BSM 40 не может передавать SKM, оно устанавливает значение Status в '1'.

В примерном показанном на Фиг.7B варианте осуществления BSM 40 сразу передает SKM без запроса от BSD/A 30. BSM 40 на этапе 520 передает на BSD/A 30 сообщение доставки SKM со значением Tag='7' с наличием SKM, включенного в него. В ответ BSD/A 30 на этапе 530 передает на BSM 40 сообщение подтверждения доставки SKM со значением Tag='8'. Если BSD/A 30 успешно принял SKM, он устанавливает значение Status в сообщении подтверждения поставки SKM в '0'. Однако, если BSD/A 30 потерпел неудачу в приеме SKM, он устанавливает значение Status в '1'.

Для Защиты услуги этот процесс управляется посредством SP-KD 32 в BSD/A 30 и SP-M 41 в BSM 40. Для Защиты контента этот процесс управляется посредством FD 33 в BSD/A 30 и CP-M 42 в BSM 40.

На Фиг.8A и 8B показаны схемы, иллюстрирующие способ получения LKM посредством BSD/A 30 в соответствии с примерным вариантом осуществления настоящего изобретения. В способе Защиты услуги/контента информацией LKM обмениваются с использованием канала вещания. LKM может доставляться от BSM 40 на Терминал 50 по интерактивному каналу. Однако в среде канала вещания LKM должно быть доставлено от BSD/A 30 на Терминал 50 по каналу вещания.

Что касается Фиг.8A, на этапе 600 BSD/A 30 передает на BSM 40 сообщение запроса LKM. Сообщение запроса LKM имеет значение '9' поля Tag, и его поля Destination и Source указывают BSM 40 и BSD/A 30, соответственно. В ответ на сообщение запроса LKM, BSM 40 на этапе 610 передает сообщение ответа на запрос LKM со значением Tag='10'. Когда BSM 40 намеревается передавать запрошенный LKM, оно устанавливает значение Status в '0'. В противном случае BSM 40 устанавливает значение Status в '1'. Когда значение Status установлено в '0', LKM сохраняется в поле Data. Когда значение Status установлено в '1', сообщение ответа на запрос LKM передается без поля Data.

В случае Фиг.8B, BSM 40 напрямую передает LKM без ответа от BSD/A 30. В этом случае BSM 40 на этапе 620 передает на BSD/A 30 сообщение доставки LKM со значением Tag='11' с наличием включенного в него LKM. В ответ BSD/A 30 на этапе 630 передает на BSM 40 сообщение подтверждения доставки LKM со значением Tag='12'. Если BSD/A 30 успешно принял LKM, он устанавливает в '0' значение Status сообщения подтверждения поставки LKM. Однако, если BSD/A 30 потерпел неудачу в приеме LKM, он устанавливает значение Status в '1'.

Для Защиты услуги этот процесс управляется посредством SP-KD 32 в BSD/A 30 и SP-M 41 в BSM 40. Для Защиты контента этот процесс управляется посредством FD 33 в BSD/A 30 и CP-M 42 в BSM 40.

На Фиг.9A и 9B показаны схемы, иллюстрирующие способ получения RKM посредством BSD/A 30 для Защиты услуги и Защиты контента в соответствии с примерным вариантом осуществления настоящего изобретения.

RKM может доставляться от BSM 40 на Терминал 50 по интерактивному каналу. Однако в среде канала вещания RKM должен быть доставлен от BSM 40 на Терминал 50 по каналу вещания.

Что касается Фиг.9A, BSD/A 30 на этапе 700 передает на BSM 40 сообщение запроса RKM. Сообщение запроса RKM имеет значение '13' поля Tag, и его поля Destination и Source указывают BSM 40 и BSD/A 30, соответственно. В ответ на сообщение запроса RKM, BSM 40 на этапе 710 передает на BSD/A 30 сообщение ответа на запрос RKM со значением Tag='14'. Когда BSM 40 намеревается передавать запрошенный RKM, он устанавливает значение Status в '0'. В противном случае BSM 40 устанавливает значение Status в '1'. Если значение Status установлено в '0', RKM сохраняется в поле Data перед передачей. Однако, если значение Status установлено в '1', сообщение ответа на запрос RKM передается без