Область техники, к которой относится изобретение
Настоящее изобретение относится к приему аудио-видео контента.
Известный уровень техники
Описание "предпосылок к созданию изобретения" в данной спецификации имеет целью представить общий контекст настоящего изобретения. Работа персонально поименованных изобретателей в том объеме, в котором она описана в данном параграфе, равно как и аспекты описания, которые не могут быть квалифицированы иначе, как известный на момент подачи заявки уровень техники, ни однозначно, ни подразумеваемым образом не признаются известным уровнем техники по отношению к настоящему изобретению.
Известная из уровня техники спецификация общего интерфейса ("CI-спецификация") (CI, сокр. от Common Interface) стандарта DVB обеспечивала телевизионному приемнику или телевизионной приставке ("хост-устройству") возможность взаимодействия с защищенным аппаратным модулем (модулем условного доступа или "CAM-модулем" (CAM, сокр. от Conditional Access Module)) с целью выдачи разрешения хост-устройству на дешифрирование контента с управляемым доступом. CI-спецификация определяет интерфейс между хост-устройством и CAM-модулем, чтобы оба устройства работали совместно, если они соответствуют CI-спецификации. Такая функциональная совместимость обеспечивала значительное преимущество CI-систем, т.к. в принципе обеспечивала потребителям возможность выбора совместимых продуктов различных производителей.
В CI-спецификации CAM-модуль взаимодействует со смарт-картой и/или личным идентификационным номером пользователя с целью аутентификации пользователя.
Однако недостатком исходной CI-спецификации является то, что она потенциально дает возможность копирования дешифрованного контента. Такая возможность проистекает из способа взаимодействия хост-устройства и CAM-модуля. В процессе работы хост-устройство посылает зашифрованные данные на CAM-модуль. CAM-модуль проверяет аутентификацию пользователя и, считая, что пользователь аутентифицирован, дешифрует контент с управляемым доступом. Затем CAM-модуль посылает дешифрованный контент обратно в хост-устройство через интерфейс, который, как правило, является PCMCIA-интерфейсом (PCMCIA, сокр. от Personal Computer Memory Card International Association - Международная ассоциация производителей карт памяти для персональных компьютеров), хотя и не ограничивается этим типом интерфейса, например, может использоваться USB-интерфейс. Такое соединение CAM-модуля с хост-устройством является слабым местом с точки зрения безопасности в том смысле, что дешифрованный цифровой контент в принципе может быть перехвачен и незаконно копирован. Эта слабость с точки зрения безопасности приводила к тому, что некоторые провайдеры предпочитали использовать интегрированные устройства, в которых хост-устройство и CAM-модуль объединялись в единое устройство, т.к. это позволяло обеспечить более высокую степень безопасности при передаче дешифрованных данных от CAM-модуля к хост-устройству. Однако это, безусловно, сводило на нет преимущество CI-интерфейса, связанное с потенциальной функциональной совместимостью различных CAM-модулей и хост-устройств.
Чтобы решить эту проблему была предложена спецификация CI Plus, предусматривающая два основных направления решения проблемы. Технология CI Plus обеспечивает безопасный интерфейс между CAM-модулем и хост-устройством, так что дешифрованный контент не пересылается в чистом виде между двумя устройствами. Также технология CI Plus обеспечивает аутентификацию как хост-устройства, так и CAM-модуля в отличие от CI-технологии, обеспечивающей аутентификацию только CAM-модуля.
Система аутентификации использует иерархию сертификатов, так что хост-устройство и CAM-модуль должны иметь сертификаты, выданные полномочным органом (таким как Партнерство с ограниченной ответственностью CI Plus).
PCMCIA-интерфейс между хостом и CAM-модулем защищен посредством шифрования дешифрованного контента перед его передачей с CAM-модуля на хост-устройство и его последующего дешифрования в хост-устройстве. Такое шифрование не связано с шифрованием-дешифрованием при управлении доступом, осуществляемым контент-провайдером, и специфично для каждой пары CAM-модуль-хост-устройство. Обмен ключами между CAM-модулем и хост-устройством осуществляется с использованием технологии обмена ключами Диффи-Хеллмана. Ключи время от времени меняются, так что даже если ключ был рассекречен, он будет в любом случае сменен несколькими секундами позднее.
Спецификация CI Plus позволяет соединять CAM-модули последовательно или в цепь.
Раскрытие изобретения
В данном описании рассматривается способ, определенный в п. 1 формулы изобретения.
Различные дополнительные соответствующие аспекты и отличительные признаки способа определены в прилагаемой формуле изобретения.
Предшествующие абзацы приведены в качестве общей информации и не предполагают какого-либо ограничения объема нижеследующей формулы изобретения. Описанные варианты осуществления изобретения вместе с прочими преимуществами более понятны из нижеследующего подробного описания, сопровождаемого прилагаемыми к описанию чертежами.
Краткое описание чертежей
Более полное понимание изобретения и многих свойственных ему преимуществ следует из приведенного ниже подробного описания конкретных вариантов его осуществления со ссылкой на прилагаемые к описанию чертежи, на которых показано:
на фиг. 1 - схематичный вид хост-устройства с CAM-модулем и смарт-карточкой;
на фиг. 2 - блок-схема системы условного доступа, включающей в себя показанное на фиг. 1 хост-устройство;
на фиг. 3 - блок-схема, иллюстрирующая работу показанной на фиг. 1 системы;
на фиг. 4 - блок-схема хост-устройства с несколькими тюнерами;
на фиг. 5 - схематичный вид устройства мультиплексирования-демультиплексирования;
на фиг. 6а - схематичный вид т.н. M-карточки;
на фиг. 6б - схематичный вид т.н. S-карточки;
на фиг. 7 - схематичный вид пакета транспортного потока;
на фиг. 8 - схематичный вид пакета данных составного потока пакетированного данных;
на фиг. 9 - более подробный схематичный вид устройства мультиплексирования;
на фиг. 10 - схематичный вид пакетов транспортного потока двух услуг;
на фиг. 11 - схематичный вид набора, содержащего последовательность CAM-модулей;
на фиг. 12 - схематичный вид последовательности CAM-модулей с интерфейсами между ними;
на фиг. 13 - блок-схема, иллюстрирующая обработку так называемых призрачных идентификаторов пакетов;
на фиг. 14 - таблица соответствия идентификаторов пакетов;
на фиг. 15 - блок-схема последовательности операций выявления, какой из CAM-модулей способен дешифровать требуемую программную услугу;
на фиг. 16 - блок-схема последовательности операций управления хост-устройством несколькими тюнерами;
на фиг. 17 - схематичное представление процесса мультиплексирования двух отдельных программных услуг;
на фиг. 18 - схематичный вид пакета с расширенным заголовком;
на фиг. 19 - схематичный вид таблицы с тактовой информацией пакетов;
на фиг. 20 - блок-схема последовательности операций формирования заголовка показанного на фиг. 18 пакета;
на фиг. 21 - блок-схема последовательности операций использования показанного на фиг. 18 заголовка пакета;
на фиг. 22 - блок-схема последовательности операций формирования показанной на фиг. 19 таблицы;
на фиг. 23 - блок-схема последовательности операций использования показанной на фиг. 19 таблицы, и
на фиг. 24 - схематичный вид системы постановки и проверки цифровой подписи.
Осуществление изобретения
С целью формирования технического контекста для последующего рассмотрения настоящих вариантов осуществления изобретения сначала со ссылкой на фиг. 1-3 описывается система вещания, имеющая один тюнер и устройство дешифрования.
На фиг. 1 хост-устройство 10 показано в данном случае в виде телевизора, но может быть, к примеру, телевизионной приставкой (имея в виду, что "устройство, предназначенное для размещения наверху телевизора" не означает для специалиста в данной области техники требования конкретного физического положения устройства при его эксплуатации). Хост-устройство принимает телевизионный сигнал 15 с управляемым доступом по широковещательному каналу передачи данных. Это может быть, к примеру, спутниковый телевизионный сигнал, принимаемый непоказанной на чертеже спутниковой тарелкой, наземный телевизионный сигнал, кабельный телевизионный сигнал и т.п., хотя другие типы телевизионного сигнала включают в себя трансляцию или передачу телевизионного сигнала с помощью пакетного сигнала протокола EP (IP-сигнала). Одна из технологий заключается в кодировании транспортного потока стандарта MPEG в IP-пакеты, так что IP-пакет несет в себе несколько (например, 7-8) пакетов транспортного потока. Другая технология зашифровывает телевизионный сигнал в т.н. основной формат медиа-файла BMFF (сокр. от Base Media File Format) Международной организации по стандартизации (ISO), описанный в ссылке: http://en.wikipedia.org/wiki/ISO_base_media_file_format, содержание которой включено в состав настоящего описания посредством ссылки. В таком случае IP-интерфейс в хост-устройстве обычно рассматривается в качестве "тюнера", даже если он может не иметь радиочастотных цепей или функции. Однако он действует подобно радиочастотному тюнеру в том смысле, что он выбирает IP-поток из множества возможных IP-потоков. Он может также обеспечивать буферизацию принимаемого IP-потока.
Упомянутое хост-устройство 10 имеет PCMCIA-разъем 20, включающий в себя электрические соединения и физическое пространство для сменного модуля, причем и то и другое соответствуют стандарту PCMCIA. В других вариантах осуществления изобретения вместо PCMCIA-интерфейса может использоваться универсальная последовательная шина данных (USB) или иной электрический интерфейс.
Модуль условного доступа CI Plus, называемый CICAM-модулем 30, является PCMCIA-модулем, который может вставляться в PCMCIA-разъем 20. Когда CICAM-модуль 30 полностью вставлен в разъем 20, устанавливаются электрические соединения между контактами на CICAM-модуля 30 и взаимодействующими контактами разъема 20.
Сам CICAM-модуль может быть беспроводным модулем или может иметь разъем 40, в который может вставляться т.н. смарт-карточка. Смарт-карточка является съемной и несет информацию, идентифицирующую текущего пользователя приемника контента в защищенным от неумелого обращения, безопасным и энергонезависимым способом. Когда смарт-карточка полностью вставлена в разъем 40, между смарт-карточкой 50 и CICAM-модулем 30 устанавливается электрическое соединение либо посредством взаимодействующих электрических контактов на смарт-карточке 50 и в разъеме 40, либо посредством известной технологии бесконтактного соединения, при которой данные передаются бесконтактно на очень маленькое расстояние (порядка 1-2 см).
На фиг. 2 схематично показано хост-устройство 10 в контексте системы условного доступа. Так называемая головная телевизионная станция 60 представляет собой источник телевизионного сигнала 15 с условным доступом. Упомянутая головная телевизионная станция может представлять собой, например, станцию восходящей связи спутникового вещания или центр распределения сигнала наземной или кабельной вещательной станции. CA-система зашифровывает контент на головной телевизионной станции с помощью CA-системы шифрования. Упомянутая головная телевизионная станция может также вводить в состав шифруемого потока данных другую относящуюся к условному доступу информацию, которая позволяет CICAM-модулю дешифровывать контент и управлять доступом и правами абонентов (пользователей).
Головная телевизионная станция 60 посылает телевизионный сигнал 15 на хост-устройство 10, которое, в свою очередь, направляет сигнал в OCAM-модуль 30 для дешифрования зашифрованного управления доступом. Затем CICAM-модуль 30 повторно шифрует сигнал, используя локальное шифрование, и посылает перешифрованный сигнал обратно на хост-устройство 10 через PCMCIA-разъем. Хост-устройство дешифрирует сигнал, полученный от CICAM-модуля 30 для отображения на экране дисплея или для отправки на другое устройство, такое как устройство видеозаписи на жесткий диск.
На фиг. 3 показана блок-схема алгоритма работы показанной на фиг. 2 системы. Подробное описание работы показанной на фиг. 2 системы приведено в CI Plus-спецификации 1.3 (2010-01), доступной (на момент подачи заявки) на сайте http://www.ci-.3.pdf. Данный документ включен в настоящее описание посредством ссылки. Настоящее описание фиг. 3 дает только общее представление о такой подробной работе с целью увязки соответствующего описания с соответствующим техническим контекстом.
Как упомянуто ранее, на фиг. 3 показаны головная телевизионная станция 60 (получающая сигнал контента от контент-провайдера), хост-устройство 10, CICAM-модуль 30 и смарт-карточка 50. Упомянутый сигнал 15 показан приходящим от головной телевизионной станции 60 на хост-устройство 10. Безопасный интерфейс 80 между хост-устройством 10 и CICAM-модулем 30 называют общим интерфейсом (единым стыком условного доступа для приема телевизионных программ с несколькими декодерами в одном телевизионном приемнике).
Условный доступ
В известных CA-системах предусматривается технология, согласно которой пользователю может быть отказано в доступе или разрешен доступ к цифровому телевизионному потоку. Доступ предоставляется только тем абонентам или пользователям, которые имеют действующие счета платежей. На практике пользователь обеспечивается смарт-картой 50, идентифицирующей его защищенным (в идеале) от подделки способом, а система настроена таким образом, что только пользователи с действующей смарт-картой могут получать доступ к контенту с управляемым доступом.
Управление доступом обеспечивается с использованием скремблирования и шифрования. Сигнал контента скремблируется восьмибитовым контрольным словом, которое часто меняется (до нескольких раз в минуту), чтобы исключить рассекречивание CA-системы из-за знания посторонними лицами контрольного слова. Упомянутые контрольные слова предаются на CICAM-модуль приемника для дескремблирования скремблированного контента в зашифрованном виде в качестве сообщения управления санкционированием (ECM, сокр. от Entitlement Control Message). CICAM-модуль дешифрирует контрольное слово, чтобы разрешить дескремблировать контент с управляемым доступом только тогда, когда модуль авторизован сделать это посредством приема сообщения о санкционировании приема (EMM, сокр. от англ. Entitlement Management Message). EMM-сообщения специфичны для каждого пользователя или группы пользователей; CICAM-модуль подтверждает права, которые предоставляет EMM-сообщение, путем сравнения идентификатора пользователя, содержащегося в EMM-сообщении, с пользовательской информацией, содержащейся в смарт-карте 50. Упомянутые EMM-сообщения могут посылаться менее часто по сравнению с ECM-сообщениями с интервалами между последовательными EMM-сообщениями действующих в ненастоящий момент времени коммерческих системах от 12 минут до шести недель.
ECM- и EMM-сообщения сами по себе являются широко известными типами сообщений в системах распространения телевизионных программ стандарта MPEG. Формат их нагрузок может быть специфичным для используемой CA-системы, причем различия между форматами носят скорее семантический, чем технический характер. В различных вариантах осуществления изобретения ECM- и EMM-данные передаются в потоке пакетированных данных в виде пакетов данных, определяющих информацию дешифрования, и используются в процессе декодирования для декодирования аудио-видео программ из потока пакетированных данных.
Головная телевизионная станция
Головная телевизионная станция 60 содержит CA-дешифратор 61, генератор 62 ключей, блок 63 управления санкционированием и мультиплексор и модулятор 64.
Контент-провайдер 90 предоставляет контент (такой как телевизионные сигналы) головной телевизионной станции 60. Головная телевизионная станция 60 применяет для обеспечения условного доступа скремблирование и шифрование контента.
Более точно, CA-дешифратор 61 шифрует или скремблирует контент, используя CA-ключ в качестве контрольного слова. Упомянутый CA-ключ формируется генератором 62 CA-ключей. Скремблированный контент, генерируемый CA-шифратором, поступает в мультиплексор и модулятор 64.
CA-ключ также поступает на блок 63 управления санкционированием, который создает ECM-сообщения на базе CA-ключей и EMM-сообщения на основе данных абонента, определяющих, кто из абонентов имеет право дескремблировать какой из потоков контента. Упомянутые ECM- и EMM-сообщения поступают в мультиплексор и модулятор 64. Один или несколько скремблированных потоков контента с CA-дешифратора 61, один или несколько нешифрованных (открытый доступ или "открытое некодированное вещание") потоков контента и сообщения управления санкционированием объединяются вместе, чтобы сформировать транспортный поток, такой как транспортный поток MPEG2. Для переноса данных контента и ECM- и EMM-сообщений используются известные форматы. ECM- и EMM-сообщения и данные, определяющие тип скремблирования, используемого в каждом элементарном потоке (соответствующем отдельным скремблированным потокам контента), предоставляются в известном формате и указываются с использованием известных технологий в таблице состава программы (PMT, сокр. от Programme Map Table) и/или в таблице условного доступа (CAT, сокр. от Conditional Access Table), которая имеет заданный идентификатор программы (PID) 0×001, так что CAT-таблица может быть опознана CICAM-модулем.
Мультиплексированный транспортный поток затем модулируется мультиплексором и модулятором 64 для передачи в виде сигнала 15 кабельного, спутникового или наземного телевещания.
Хост-устройство
Хост-устройство 10 содержит тюнер 11, демодулятор и демультиплексор 12, демультиплексор ("demux") 13 и дешифратор 14 управления контентом (CC-дешифратор 14). Обратите внимание, что хост-устройство может иметь другие дополнительные функции, например, оно может обеспечивать прием двух и более программ спутникового вещания, кабельного вещания, наземного вещания и телевизионного вещания по каналам с IP-протоколами.
В зависимости от типа вещательного сигнала 15 тюнер преобразует принятый сигнал обратно в основную полосу частот, так что демодулятор и демультиплексор 12 может выбирать и демультиплексировать один элементарный поток контента и связанные с ним CAT-данные из принятого сигнала. Поток контента и данные ECM- и EMM-сообщений проходят через общий интерфейс 80 в CICAM-модуль 30.
В случае данных контента с управляемым доступом на этом этапе данные контента все еще остаются скремблированными при их прохождении через общий интерфейс 80 к CICAM-модулю 30. Вследствие этого эта часть передачи через общий интерфейс 80 защищена благодаря CA-шифрованию.
При условии, что ECM- и EMM-сообщения позволяют это, CICAM-модуль 30 дескремблирует данные контента и повторно шифрует их посредством шифрования CC-шифрования. Способ осуществления этого процесса описывается ниже. Зашифрованные посредством CC-шифрования данные возвращаются на хост-устройство 10, где они демультиплексируются демультиплексором 13 и дешифруются CC-дешифратором 14, так что они могут отображаться на экране или выдаваться на другое устройство 70 в виде нешифрованного контента.
Таким образом, хост-устройство осуществляет прием аудио и видео контента и имеет декодер контента (к примеру, CAM-модуль), способный декодировать аудио-видео программы из потока пакетированных данных (такого, как транспортный поток) с помощью пакетов данных (таких, как EMM- и ECM-сообщения), несущих информацию дешифрования. Принимаемый транспортный поток может содержать одну или несколько программ, имеющих пакеты данных, идентифицируемые по соответствующим наборам идентификаторов пакетов (таких, как идентификаторы программ) и содержащих программы соответствия идентификационных данных (таблиц состава программ PMT, таблиц распределения программ PAT или таблиц условного доступа CAT) соответствующим наборам идентификаторов пакетов.
CICAM-модуль
CICAM-модуль 30 содержит дешифратор 31, генератор 32 CA-ключей, CC-дешифратор 33 и генератор 34 CC-ключей.
CA-дешифратор 31 и генератор 32 CA-ключей могут рассматриваться в качестве блока управления доступом для декодирования телевизионного контента с управляемым доступом или других данных. Генератор 34 CC-ключей и CC-дешифратор 33 CICAM-модуля 30, и демультиплексор 13 и CC-дешифратор 14 хост-устройства 10 взаимодействуют друг с другом с целью создания зашифрованной линии связи (общего интерфейса 80) для передачи декодированного телевизионного контента с управляемым доступом между CICAM-модулем и хост-устройством.
CA-дешифратор 31 использует ключи, генерируемые из принятых ECM- и EMM-сообщений генератором 32 CA-ключей, используя проверки идентичности пользователя со смарт-карты 50 для дескремблирования принятого контента с управляемым доступом. Эта часть работы CICAM-модуля использует известные CA-технологии поиска и применения CA-ключей.
Данные нешифрованного контента поступают из CA-дешифратора 31 в CC-шифратор 33. Однако в виду того, что эта передача данных происходит полностью внутри CICAM-модуля, она может считаться безопасной и защищенной от копирования известной технологией, такой как размещение CA-дешифратора 31, CC-шифратора 33 и интерфейса нешифрованного контента в пределах одной интегральной схемы.
CC-шифратор 33 шифрует дескремблированный контент, используя CC-ключ, предоставленный генератором 34 CC-ключей. Этот ключ устанавливается посредством безопасного взаимодействия CICAM-модуля 30 и хост-устройства 10 и специфичен для такой пары CICAM-модуль-хост-устройство. Зашифрованный CC-шифратором контент проходит через общий интерфейс 80 в хост-устройство 10. Таким образом, эта часть общего интерфейса также защищена, т.к. данные контента зашифрованы посредством CC-шифрования при прохождении к хост-устройству.
Обмен ключами
Как CICAM-модуль 30, так и хост-устройство 10 содержат логику, встроенные программы или программное обеспечение, обеспечивающие алгоритмы безопасного обмена ключами по методу Диффи-Хеллмана, хеширования и шифрования с использованием известных алгоритмов стандартов SHA-256 (сокр. от Secure Hash (Hashed) Algorithm - алгоритм аутентификации и проверки целостности информации), DES (сокр. от Data Encryption Standard - стандарт шифрования данных), AES (сокр. от Advanced Encryption Standard - усовершенствованный стандарт шифрования данных), соответствующих сертификатов, выданных уполномоченным на то органом, таким как Партнерство с ограниченной ответственностью CI Plus, и личных ключей с соответствующими открытыми ключами.
Когда CICAM-модуль 30 впервые связывается с хост-устройством 10, CICAM-модуль 30 инициирует процесс взаимной аутентификации устройств. В ходе этого процесса каждое устройство верифицирует сертификат устройства-контрагента, и происходит обмен информацией для выработки общего ключа по методу Диффи-Хеллмана с целью безопасного распределения ключей между двумя устройствами. В частности, CICAM-модуль сначала запрашивает у хост-устройства данные его сертификата. CICAM-модуль верифицирует подпись на сертификате хост-устройства. Аналогичный процесс затем выполняется хост-устройством, запрашивающим и верифицирующим сертификат CICAM-модуля. Затем как CICAM-модуль, так и хост-устройство демонстрируют, что они обладают личными ключами, соответствующими открытому ключу в сертификате, путем подписания открытого ключа Диффи-Хеллмана и отсылки его на устройство-контент для валидации. Затем CICAM-модуль получает и верифицирует аутентификационный ключ АКН от хост-устройства. CICAM-модуль и хост-устройство начинают вычислять и обмениваться данными о ключах для шифрования и аутентификационными данными, пересылаемыми через общий интерфейс 80. Таким образом, ключ, пара ключей или другая информация о ключах, установленная CICAM-модулем и хост-устройством для связи через общий интерфейс 80, специфична для конкретной пары CICAM-модуль-хост-устройство.
После аутентификации CICAM-модуль также начинает вычислять CC-ключ. CICAM-модуль может также выдать команду хост-устройству на вычисление CC-ключа. Упомянутый CC-ключ затем используется, как это описано выше, для шифрования данных контента, проходящего через от CICAM-модуль 30 к хост-устройству 10 согласно алгоритму улучшенного стандарта шифрования AES. Таким образом, понятно, что ключи, используемые для безопасного общего интерфейса 80, специфичны для конкретной пары CICAM-модуль-хост-устройство.
Ниже рассматриваются типичные варианты осуществления изобретения, в которых используются несколько тюнеров, хотя многие из технологий также применимы для компоновок, в которых используется только один тюнер.
На фиг. 4 показана блок-схема хост-устройства 100, имеющего несколько тюнеров, обозначенных как тюнер А 102 и тюнер Б 104, каждый из которых принимает радиочастотный входной сигнал. Упомянутый радиочастотный входной сигнал может быть общим сигналом 106, обрабатываемым каждым из нескольких тюнеров, или может быть отличающимся сигналом для каждого из тюнеров (например, один тюнер может работать с сигналом наземной телевизионной станции, а другой тюнер может работать с сигналом спутниковой телевизионной станции). Упомянутая система не ограничивается двумя тюнерами; описываемые принципы применимы для систем с более чем двумя тюнерами, однако для ясности на фиг. 4 показаны только два тюнера.
Выход каждого из тюнеров 102, 104 соединен с соответствующим демодулятором 108, 110. Выходной сигнал может представлять собой данные, такие как поток пакетированных данных или транспортный поток, передаваемый по одному соответствующему каналу передачи, выбранному (из множества настраиваемых каналов передачи) таким тюнером. Демодулятор работает, как это описано выше (в отношении показанного на фиг. 3 демодулятора 12), чтобы демодулировать пакетированный сигнал с выхода соответствующего тюнера. Пакетированные сигналы с нескольких демодуляторов 108, 110 мультиплексируются CI-контроллером 112 для обработки набором 114 из одного или нескольких CAM-модулей, имеющим вид последовательно соединенных двух или более декодеров контента. Ниже рассматриваются различные варианты выполнения набора CAM-модулей, но на базовом техническом уровне набор 114 CAM-модулей способен одновременно декодировать на выходе более одной программной услуги. Например, набор CAM-модулей 114 может предназначаться для одновременного декодирования такого же количества программных услуг, сколько тюнеров имеется в хост-устройстве 100.
Декодированные данные, принятые обратно из набора 114 CAM-модулей, демультиплексируются CI-контроллером 112 в соответствующие сигналы 116, 118, представляющие собой требуемые программные услуги. Сигналы 116, 118 поступают на демультиплексоры 120, 122 программ, имеющие аналогичные показанному на фиг. 3 демультиплексору 13 функции.
Наконец, каждая программная услуга готовится для выдачи соответствующим декодером 124, 126, имеющим аналогичные показанному на фиг. 3 CC-дешифратору 14 функции. Декодеры 124, 126 генерируют соответствующие выходные аудио и видео сигналы 128,130.
Показанное на фиг. 4 хост-устройство работает под управлением центрального процессора 132, который в свою очередь может быть программируемым процессорным устройством, работающим согласно программному обеспечению или встроенной программе, хранящейся в памяти 134 (которая в свою очередь может быть энергонезависимой машиночитаемой памятью, такой как магнитный или оптический диск, или энергонезависимой полупроводниковой памятью).
На фиг. 5 схематично показано устройство мультиплексирования-демультиплексирования, формирующее часть функциональности показанного на фиг. 4 CI-контроллера 112.
В общих словах, в качестве части функциональности CI-контролера 112 по меньшей мере соответствующие части сигналов пакетированных данных с демодуляторов 108, 110 объединяются мультиплексором 140 в составной сигнал пакетированных данных, направляемый в набор 114 из одного или более CAM-модулей, а декодированный вариант составного сигнала пакетированных данных принимается демультиплексором 142, который демультиплексирует его в соответствующие сигналы 116, 118 для декодирования. Однако имеются различные способы достижения этого.
Выход сигналов пакетированных данных двух демодуляторов 108, 110 может представлять собой т.н. транспортные потоки и обычно включает в себя пакеты данных, относящиеся к нескольким аудио-видео программным услугам наряду с различными служебными и управляющими пакетами. Например, один сигнал пакетированных данных может включать в себя пакеты, относящиеся к 3-10 программным услугам, хотя выбор того, сколько программных услуг представлены отдельным транспортным потоком является ровно настолько коммерческим выбором, насколько и техническим; транспортный поток обеспечивает некоторую полосу частот для данных, но за вещателем остается коммерческий выбор, сколько программных услуг будут предоставляться в располагаемой полосе частот. Для кодирования большего количества программных услуг в заданной полосе частот качество кодирования (которое, исходя из опыта, влияет на качество воспроизводимых аудио и видео сигналов) каждой программной услуги должно быть снижено. Но в любом случае при нормальном использовании возможно, что каждый из сигналов пакетированных данных, генерируемых одним из демодуляторов 108, 110, будет содержать пакеты данных, отличающиеся от тех, что необходимы для декодирования конкретной желаемой программной услуги.
Тогда возникает техническая возможность для CI-контроллера 112 по меньшей мере в принципе просто объединять множество сигналов пакетированных данных с демодуляторов 108, 110 таким образом, чтобы вся информация, содержащаяся в каждом сигнале пакетированных данных, сохранялась. Это позволило бы получить составной сигнал пакетированных данных, имеющий ширину полосы данных порядка n, умноженного на ширину полосы отдельного транспортного потока, где n - это количество отдельных транспортных потоков, мультиплексированных вместе мультиплексором 140. Потенциальной проблемой при таком построении является то, что CAM-модули, входящие в набор 114, не смогут обработать такой высокоскоростной сигнал пакетированных данных. Одной из возможных причин является то, что CAM-модули могут быть предназначены для гармоничного использования только с одним сигналом пакетированных данных.
Поэтому в других системах соответствующее подмножество пакетов данных извлекается из каждого из выходных сигналов пакетированных данных демодуляторов 108, 110, и составной сигнал пакетированных данных, который должен поступать в набор 114 из одного или нескольких CAM-модулей, формируется из комбинации таких соответствующих подмножеств. Технология формирования такой комбинации, чтобы генерировать составной сигнал пакетированных данных, рассматривается ниже.
К настоящему рассмотрению относятся два типа CAM-модулей. На фиг. 6а схематично показана т.н. M-карточка (многопоточная карточка) 150, а на фиг. 6б - т.н. S-карточка (однопоточная карточка) 160.
Основное техническое отличие между двумя типами CAM-модулей следующее. M-карточка представляет собой единое устройство, способное одновременно дешифровать более одной программной услуги. Она представляет собой более современный вариант выполнения CAM-модуля, чем S-карточка, которая снята с производства, но все еще находится в эксплуатации и способна дешифровывать только одну программную услугу из транспортного потока. Следует заметить, что М-карточка может работать либо в многопоточном, либо в однопоточном (как S-карточка) режиме. S-карточка может работать только в однопоточном режиме.
На фиг. 7 схематично показан пакет 170 транспортного потока. Упомянутые пакеты одержат 4-битовый заголовок 172 и 184-битовую часть для полезной нагрузки. Это стандартный формат для пакетов транспортного потока, и транспортный поток формируется из последовательности пакетов такого формата. Заголовок 172 включает в себя идентификатор пакета или PID (сокр. от Packet IDentifier). Каждая услуга аудио-видео программы имеет связанный набор из двух или более идентификаторов пакетов. Например, один идентификатор пакета может быть связан с видео пакетами услуги программы, другой идентификатор пакета PID может быть связан с аудио пакетами программной услуги, а еще один идентификатор пакета может быть связан с пакетами управления шифрованием услуги. Таким образом, в рамках одного транспортного потока могут использоваться различные идентификаторы пакетов. Распределение идентификаторов пакетов по различным типам пакетов осуществляется посредством таблицы распределения программ (PAT) и таблицы состава программ (PMT, сокр. от Programme Map Table). Сама таблица распределения программ имеет идентификатор пакета 0 и работает таким образом, чтобы указывать идентификаторы пакетов, несущих таблицу состава программ. Таблица состава программ указывает идентификаторы пакетов, несущих видео и аудио данные, а также идентификаторы пакетов, несущих данные для обнаружения и исправления ошибок в услуге. Для полноты изложения таблица условного доступа (CAT, сокр. от Conditional Access Table) имеет идентификатор пакета 1 и указывает, какие из пакетов несут EMM-сообщение для одной или нескольких систем управления доступом.
Идентификаторы пакетов однозначно определяются в рамках одного транспортного потока в 13-битовом диапазоне (0-8191 в десятичном исчислении). Однако от одного транспортного потока к другому данные, представленные конкретным значением идентификатора пакета, могут быть неоднозначными. Т.е. значение идентификатора пакета может повторно использоваться в различных транспортных потоках. В случае, когда мультиплексором 140 мультиплексируются несколько транспортных потоков, необходим механизм устранения этой потенциальной неоднозначности идентификаторов пакетов.
Одна из технологий обеспечения этого описана в публикации US В 7394834, содержание которой включено в настоящее описание посредством ссылки. Согласно данной публикации пакеты, представляющие желаемые услуги, извлекаются из нескольких транспортных потоков, и идентификаторы пакетов, извлеченных по меньшей мере из одного из транспортных потоков, преобразуются в новые значения идентификаторов пакетов, которые не используются для любых данных, извлеченных из других транспортных потоков. Процесс преобразования включает в себя замену значения идентификатора пакета другим значением идентификатора пакета с записью или занесением в таблицу соответствия идентификаторов пакетов, так что желаемая услуга может быть идентифицирована по новым (преобразованным) значениям идентификаторов пакетов. Такая схема может использоваться для генерации псевдотранспортного потока, который является, так сказать, искусственно созданным транспортным потоком, существующим только в пределах хост-устройства, но который создает впечатление (с точки зрения S-карточки), что он удовлетворяет всем требованиям к формату транслируемого транспортного потока. Т.е. этот псевдотранспортный поток может декодироваться S-карточкой, как будто он транслирован в этом виде, хотя фактически он выработан в пределах хост-устройства путем объединения частей нескольких транслируемых транспортных потоков.
Другая технология заключается в использовании предварительного заголовка, который вставляется в начало каждого пакета транспортного потока и содержит информацию о происхождении этого пакета. Такая технология используется при отправке на М-карточку, работающую в многопоточном режиме. Пример пакета транспортного потока с предварительным заголовком 176 схематично показан на фиг. 8.
Предварительный заголовок 176 содержит 12 бит дополнительных данных и предварительно добавляется к каждому пакету, отправляемому в M-карточку. Т.е. он добавляется в начало каждого пакета. 12 бит дополнительных данных содержат различные поля, включая идентификатор локального транспортного потока, идентифицирующий транспортный поток, из которого были извлечены пакеты, локальную временную метку, данные для обнаружения ошибок в предварительном заголовке и резервные поля данных для последующего или специального использования. Важным для целей настоящего изобретения является то, что идентификатор локального транспортного потока означает, что даже в ситуации, когда пакеты в составном потоке пакетированных данных имеют конфликтующие значения идентификаторов пакетов, они, тем не менее, могут быть выделены по их локальному значению идентификатора транспортного потока, содержащемуся в предварительном заголовке.
Следует заметить, что M-карточка требует наличия дополнительного предварительного заголовка. S-карточка не может работать при наличии дополнительного предварительного заголовка.
Так, в другой схеме мультиплексор 140 объединяет пакеты, извлеченные из нескольких транспортных потоков, в составной поток пакетированных данных для использования M-карточкой, предварительно добавляя к каждому такому пакету по меньшей мере элемент тождественности тому транспортному потоку, из которого он извлечен.
На фиг. 9 показана более подробная блок-схема мультиплексора. Показанная на фиг. 9 блок-схема мультиплексора относится к блок-схеме, в которой генерируется псевдотранспортный поток для декодирования S-карточками и M-карточками при работе в однопоточном режиме.
Каждый входной транспортный поток проходит к соответствующему блоку 180, 182 выбора идентификаторов пакетов, который ссылается на таблицу 184, 186 распределения программ, связанную с этим транспортным потоком, и на данные 188, 190, определяющие требуемую программную услугу, чтобы установить идентификаторы пакетов, которые требуются для декодирования (требуемой программной услуги) как части составного сигнала пакетированных данных.
В вариантах осуществления изобретения блоки 180, 182 выбора задействуются для выполнения одной или нескольких нижеперечисленных операций:
выбора пакетов данных из потока пакетированных данных для требуемой программы согласно набору идентификаторов пакетов, определяемых идентификационными данными для данного потока в отношении требуемой программы;
выбора дополнительных пакетов данных из потока пакетированных данных, из которого выбрана программа, имеющих идентификаторы пакетов, не включенные в идентификационные данные для данного потока пакетированных данных; и
выбора из каждого потока пакетированных данных, из которого выбрана программа, дополнительных пакетов данных, содержащих данные задающего тактового генератора программы, относящиеся к выбранной программе.
Упомянутые особенности работы блоков выбора более подробно описываются ниже.
Данные 188, 190, определяющие требуемую программную услугу, могут быть предоставлены центральным процессором 132, к примеру, в ответ на запрос пользователя непоказанного на чертеже удаленного пульта ДУ или, возможно, в ответ на машинный запрос, например, от устройства видеозаписи, работающего по командам таймера и требующего приема некоторой программной услуги в течение заданного временного интервала для осуществления ее записи. Блок 192, 194 для каждого транспортного потока бракует "нежелательные" пакеты, т.е. пакеты, не имеющие идентификаторов пакетов, определенных при выборе, осуществленном блоками 180, 182 выбора. Блок 196, 198 преобразования идентификаторов пакетов используется для преобразования идентификаторов пакетов одного из транспортных потоков в новые значения идентификаторов пакетов, чтобы исключить любое возможное совпадение со значениями идентификаторов пакетов других транспортных потоков. Следует заметить, что преобразование не происходит в случаях, когда нет несовпадения (в многопакетном режиме) идентификаторов пакетов между различными транспортными потоками, хотя в некоторых вариантах осуществления изобретения все идентификаторы по меньшей мере выбранных пакетов вторичных транспортных потоков могут быть преобразованы в соответствующие отличающиеся идентификаторы пакетов. Следует также заметить, что нет необходимости выполнять операцию преобразования для обоих транспортных потоков (или, если имеется более двух транспортных потоков, то каждого транспортного потока), и в самом деле, в вариантах осуществления изобретения один из транспортных потоков обрабатывается в качестве т.н. "первичного" транспортного потока, для которого не осуществляется преобразование идентификаторов пакетов. Для гибкости, однако, блок 196, 198 преобразования предоставляется для каждого транспортного потока для возможного использования, если потребуется. Также следует заметить, что в преобразовании нуждаются только те идентификаторы пакетов, которые вступают в конфликт (тот же номер идентификатора пакета, что и у пакета из другого транспортного потока), хотя и другие идентификаторы пакетов также могут быть преобразованы. В некоторых вариантах осуществления изобретения идентификаторы пакетов из одного или нескольких "вторичных" транспортных потоков являются кандидатами на преобразование, идентификаторы же пакетов из первичного транспортного потока не являются кандидатами на преобразование.
В других вариантах осуществления изобретения блоки 180 выбора могут учитывать при осуществлении выбора т.н. пакеты задающего тактового генератора программы, так что такие пакеты включаются с составной поток пакетированных данных.
Для справки, для декодирования аудио и видео данных в транспортном потоке в качестве тактовой информации используются данные задающего тактового генератора программы. Данные задающего тактового генератора программы относительно невелики и фактически включены в состав пакетов транспортного потока в т.н. поле адаптации. Упомянутое поле адаптации находится в пределах 184-битовой полезной нагрузки 174 (см. фиг. 7), но с точки зрения функции выступает скорее в виде расширения заголовка (внутрь поля полезной нагрузки 174). Для сигнализации о наличии поля адаптации заголовок несет флажковый указатель (такой, как однобитовый флажок). Кроме того, имеется еще одно сигнальное средство, связанное с полем адаптации, чтобы указывать в свою очередь, что поле адаптации содержит данные задающего тактового генератора программы. Так, блоки 180 выбора могут выявлять пакет, несущий данные задающего тактового генератора программы, посредством первичной проверки флажка "наличия поля адаптации" в заголовке пакета и последующей проверки связанного с полем адаптации флажка, указывающего, что "поле адаптации содержит данные задающего тактового генератора программы".
Упомянутая тактовая информация, указываемая данными задающего тактового генератора программы, как правило, является общей для всех программных услуг в транспортном потоке. Она используется декодерами, так что декодирование контента осуществляется согласно пакетам с данными задающего тактового генератора программы и идентификаторам пакетов, относящимся к требуемой услуге. Таким образом, как правило, необходимо обеспечить один набор данных задающего тактового генератора программы в пределах транспортного потока. В известном уровне техники общим правилом является то, что данные задающего тактового генератора программы для транспортного потока содержатся в полях адаптации пакетов, относящихся к одной произвольно выбранной программной услуге. Идентификаторы пакетов, несущих данные задающего тактового генератора программы для транспортного потока, могут указываться в поле PCR_PID таблицы состава программы.
В схемах, где весь транспортный поток поступает в CAM-модуль для дешифрирования (как это имеет место в схеме "один тюнер - один CAM-модуль" или в схеме с выделением для каждого тюнера или источника транспортного потока своего CAM-модуля) тот факт, что данные задающего тактового генератора программы могут быть в пакетах, относящихся к программной услуге, иной, чем наблюдаемая в настоящий момент или декодируемая в настоящий момент программная услуга, не является проблемой, т.к. данные задающего тактового генератора программы остаются доступными для CAM-модуля и затем для декодера.
Но в рассматриваемых вариантах осуществления изобретения, в которых составной поток пакетированных данных формируется в виде комбинации подмножеств нескольких входных транспортных потоков, причем каждое подмножество относится к требуемой программной услуге, могут возникать ситуации, при которых данные задающего тактового генератора программы для программной услуги отсутствуют, т.к. они содержатся в пакетах, относящихся к иной программной услуге, чем выбранная из данного транспортного потока программная услуга.
Для устранения таких ситуаций блоки 180 выбора могут поверять поле адаптации каждого пакета и (если поле адаптации имеется) флажок наличия данных задающего тактового генератора программы, так что если пакет является пакетом, содержащим данные задающего тактового генератора программы, то упомянутый пакет выбирается независимо от того, относится он или не относится к выбранной программной услуге. Упомянутый пакет, содержащий данные задающего тактового генератора программы, включается в состав отобранных пакетов и таким образом включается в составной поток пакетированных данных.
Отобранные и при необходимости преобразованные пакеты затем объединяются в единый составной поток данных в блоке 200 объединения. Например, это может быть процесс каскадного соединения в цепь, что, проще говоря, означает соединение пакетов бок о бок (один за другим) в составной поток данных. Это не обязательно подразумевает, что пакеты располагаются непосредственно друг за другом (между ними могут иметься промежутки) или что они располагаются в каком-то определенном порядке.
Вследствие этого в потоке пакетированных данных, собранном с использованием такой технологии, могут содержаться данные нескольких источников данных задающего тактового генератора программы. В общем, здесь могут быть пакеты, содержащие данные задающего тактового генератора программы, происходящие из каждого транспортного потока, из которого выбрана программная услуга для включения в составной поток пакетированных данных. Однако в отношении каждой программной услуги декодер способен получить доступ к правильным данным задающего тактового генератора программы. Если данные задающего тактового генератора программы включены в пакеты программной услуги, которая должна декодироваться, то декодер будет использовать эти данные задающего тактового генератора программы. Если данные задающего тактового генератора программы в исходном транспортном потоке были включены в пакеты, относящиеся к другой программной услуге, то эти пакеты будут включены с составной поток пакетированных данных посредством описанного выше механизма. В любом случае, даже если используется преобразование идентификаторов пакетов, данные PCR_PID (преобразованные, если это необходимо) сохраняются для каждой программной услуги в составном потоке пакетированных данных. В самом деле, набор данных из таблицы распределения программ и/или из таблицы состава программ переносится в составной поток пакетированных данных в качестве идентификационных данных составного потока (см. пример, приведенный на фиг. 14) в отношении каждой выбранной программной услуги, например, чтобы указать в составном потоке идентификаторы пакетов, содержащие аудио, видео данные и данные условного доступа, а также для указания PCR_PID.
Следовательно, если этап приема заключается в приеме двух или более потоков пакетированных данных; рассмотренные выше этапы выбора применяются к каждому потоку пакетированных данных, из которого выбирается программа; составной поток пакетированных данных содержит программные данные из двух или более потоков пакетированных данных; и генерация составного потока пакетированных данных заключается в соединении выбранных пакетов с целью формирования составного потока пакетированных данных. На фиг. 10 схематично показаны пакеты 205 транспортного потока двух программных услуг, услуги 1 и услуги 2, объединенные в единый составной поток пакетированных данных.
На фиг. 11 схематично показана последовательность CAM-модулей в качестве примера рассмотренного выше набора 114 CAM-модулей. CAM-модули в наборе расположены последовательно в виде т.н. цепочки, так что составной поток пакетированных данных с выхода CI-контроллера 112 поступает на вход 210 первого CAM-модуля 212 последовательности и направляется с первого CAM-модуля 212 на второй CAM-модуль 214 последовательности, откуда он поступает на третий CAM-модуль 216, прежде чем вернуться обратно на CI-контроллер 112, имея требуемые услуги, дешифрованные на основе идентификаторов пакетов, прошедших к CI-контроллеру 112 вместе или в качестве части идентификационных данных составного потока. CAM-модули в цепочке могут быть приспособлены для дешифрования отличающихся услуг условного доступа, так что какая бы услуга (в рамках услуг и CA-систем, обрабатываемых набором 114) ни была выбрана для дешифрования пользователем или по команде устройства управления, один из CAM-модулей упомянутого набора 114 способен дешифровать ее. Технология, с помощью которой хост-устройство может выбирать подходящий CAM-модуль для дешифрования конкретной программной услуги, описывается ниже со ссылкой на фиг. 15.
Соответственно декодер контента, выполненный в виде набора CAM-модулей или M-карточки условного доступа, способен одновременно декодировать две или более аудио-видео программ из одного потока пакетированных данных, и в таких случаях этап генерации составного потока пакетированных данных включает в себя формирование составного потока пакетированных данных из пакетов, представляющих две или более программы.
Следует заметить, что у каждого CAM-модуля имеется два основных интерфейса. Аудио, видео и некоторые управляющие данные могут поступать в CAM-модуль в качестве части составного потока пакетированных данных, подаваемого на вход 210, и проходить от одного CAM-модуля к другому. Дополнительно между CI-контроллером и CAM-модулем имеется интерфейс управления с существенно меньшей скоростью передачи данных. Сигналы управления, которые рассматриваются ниже, могут мультиплексироваться в составной поток пакетированных данных или передаваться через интерфейс управления.
В общем, только CAM-модуль дешифрует конкретную программную услугу, и CAM-модуль не может дешифровать программную услугу иначе, как после получения команды от хост-устройства на выполнение этого действия.
В некоторых вариантах осуществления изобретения схема, показанная на фиг. 11, может работать, если все CAM-модули в цепочке являются S-карточками (или M-карточками, работающими в однопоточном режиме), или если все CAM-модули в цепочке являются М-карточками, т.к. в любом случае формат данных составного потока пакетированных данных является одинаковым по всей цепочке CAM-модулей. Для ситуаций, когда это не имеет места, на фиг. 12 схематично показана последовательность CAM-модулей 220, 222, 224 с интерфейсами 226, 228 между ними.
Предположим, что в одном из примеров осуществления изобретения CAM-модуль 220 является M-карточкой, CAM-модуль 222 является S-карточкой, а CAM-модуль 224 является М-карточкой. Сигнал 230 составного потока пакетированных данных, принятый от CI-контроллера 112, имеет формат M-карточки, т.е. включает в себя рассмотренный ранее дополнительный предварительный заголовок. Этот сигнал обрабатывается обычным образом M-карточкой 220, но затем, вместо того, чтобы поступать непосредственно на следующую карточку 222 цепочки, поступает на блок 226 интерфейса, где дополнительная информация заголовка, относящаяся к предварительному заголовку, исключается из пакета, и, при необходимости, осуществляется преобразование значения идентификатора пакета, прежде чем составной поток пакетированных данных поступит на S-карточку 222. Блок 226 интерфейса сохраняет исключенные данные и любые данные преобразования идентификатора пакета, относящиеся к исходному составному потоку пакетированных данных и передает эту сохраненную информацию в блок 228 интерфейса, который принимает выходной поток данных с S-карточки 222. Блок 228 интерфейса повторно вставляет предварительный заголовок в каждый пакет и осуществляет обратное преобразование идентификаторов пакетов, чтобы вернуть значениям идентификаторов пакетов их исходный вид. Выходной поток данных из блока 228 интерфейса затем поступает на обработку в M-карточку 224.
На фиг. 13 схематично показана блок-схема алгоритма обработки т.н. "призрачных" идентификаторов пакетов.
Призрачные идентификаторы пакетов относятся к т.н. призрачным пакетам в транспортном потоке стандарта MPEG. Иногда призрачные пакеты могут использоваться участниками системы телевещания, такими как производители хост-устройств, изготовители телевизионных приемников, вещатели, вендоры CA-систем и т.д. для обеспечения конфиденциальности управляющей информацией (такой, например, как "личные" данные) в различных частях хост-устройства и, в частности, в используемом в хост-устройстве CAM-модуле или CAM-модулях.
В общем, считается желательным держать такие пакеты в секрете или по меньшей мере не афишировать их наличие, т.к. они могут содержать информацию, которая может быть полезна для неавторизованного пользователя или хакера с целью осуществления несанкционированного дешифрования одной или нескольких услуг.
В простом примере призрачные пакеты могут включать в себя обновление встроенного программного обеспечения для CAM-модуля, которое, в свою очередь, содержит данные, которые вендоры CA-систем или производители CAM-модулей предпочитают скрывать от потенциальных хакеров. Для достижения необходимой степени конфиденциальности пакеты, содержащие такие данные, могут предаваться с использованием идентификаторов пакетов, которые извлекаются CAM-модулем согласно (например) заданному алгоритму, основанному на текущем времени или других условиях, но которые не указываются в качестве части каких-либо таблиц распределения, формирующих часть такого транспортного потока. Таким образом, призрачные пакеты потенциально важны для работы CAM-модулей, но так как они не включаются ни в какие таблицы распределения, они могут, по сути, отбраковываться показанными на фиг. 9 блоками 192, 194 отбраковки, если только не предпринимаются целенаправленные действия, чтобы избежать этого, и могут отсутствовать в составном потоке пакетированных данных, который реально поступает в CAM-модуль.
Для решения этой потенциальной проблемы блоки 180, 182 выбора и показанные на фиг. 9 блоки 192, 194 отбраковки могут работать согласно следующим показанным на фиг. 13 этапам.
На этапе 250 блоки 180, 182 выбирают идентификаторы пакетов для требуемых программных услуг. Этот режим работы соответствует тому, что уже описан со ссылкой на фиг. 9. Отличие по сравнению фиг. 9, однако, состоит в том, что на этапе 252 блоки выбора также выбирают (для включения в составной поток пакетированных данных) все идентификаторы пакетов, которые не указаны в идентификационных данных (таблицах состава программ, таблицах распределения программ или таблицах условного доступа) для данного транспортного потока. Таким образом, на данном этапе блоки выбора не знают, какие функции несут призрачные идентификаторы пакетов, но они выбирают все идентификаторы пакетов, которые присутствуют в транспортном потоке и которые конкретно не соответствуют программным услугам, отличающимся от требуемой программной услуги. На этапе 254 блоки 196, 198 преобразования осуществляют операцию преобразования, но при этом следует заметить, операция преобразования осуществляется не только в отношении идентификаторов пакетов выбранной услуги, но также и в отношении призрачных идентификаторов пакетов, выбранных на этапе 252. Наконец, на этапе 256 преобразовательные данные, представляющие собой соответствия между идентификаторами пакетов до преобразования и идентификаторами пакетов после преобразования (см. пример, показанный на фиг. 14), посылаются в набор 114 CAM-модулей, так что если CAM-модуль из набора требует доступа к пакету, обозначенному призрачным идентификатором пакета, то CAM-модуль может идентифицировать такой пакет в преобразованных данных, обращаясь к преобразовательной информации, и декодировать идентифицированный пакет соответственно.
Следует заметить, что идентификаторы пакетов, используемые для обозначения призрачных пакетов, могут время от времени меняться. В самом деле, это может быть частью процедуры обеспечения безопасности, связанной с этими пакетами. Также призрачные пакеты могут передаваться не слишком часто. Так, если показанная на фиг. 9 система сначала работает с конкретной программной услугой из конкретного транспортного потока, она не может заранее знать текущий набор призрачных идентификаторов пакетов. Она может узнать его с помощью одной из двух технологий: путем обнаружения (с помощью блока 180, 182 выбора) идентификатора пакета в потоке данных, который отсутствует во всех справочных таблицах, или путем запроса CAM-модулем (например, посредством интерфейса управления) конкретного идентификатора пакета, который упомянутый CAM-модуль считает необходимым, но который отсутствует в составном потоке пакетированных данных. Первая из технологий может считаться упреждающим выбором, вторая - ответным выбором. В любом случае блок 180, 182 выбора может в ответ выбрать такой идентификатор пакета для его включения в составной поток пакетированных данных. В принципе это может случиться сразу, так что по первому запросу такой идентификатор пакета включается в составной поток пакетированных данных. Или может иметь место задержка, в частности, если включение идентификатора пакета в составной поток пакетированных данных осуществляется в ответ на запрос CAM-модуля, запрашивающего отсутствующий идентификатор пакета. Это обусловлено относительно небольшой скоростью передачи данных интерфейсом управления. Но небольшая задержка (например, менее одной секунды) не считается проблемой, т.к. общепринятой практикой является многократная передача любых важных пакетов, не являющихся частью аудио-видео потока. Это делается для того, чтобы учесть возможность включения или выключения телевизора пользователем в любой момент времени, так что при однократной передаче такого критичного пакета пользователь может пропустить такую передачу.
На фиг. 14 схематично показана таблица соответствия идентификаторов пакетов в качестве примера вида преобразовательной информации, которая может передаваться от мультиплексора 140 в набор 114 CAM-модулей на этапе 256 либо в виде данных управления, либо данных, мультиплексированных в составной поток пакетированных данных. Таблица соответствия идентификаторов пакетов содержит идентификатор 260 транспортного потока, из которого был извлечен идентификатор пакета, идентификатор 262 программной услуги, извлеченной их транспортного потока, "прежний" идентификатор 264 пакета (до преобразования) и "новый" идентификатор 266 пакета (после преобразования). Таблица соответствия идентификаторов пакетов может быть мультиплексирована в составной поток пакетированных данных и/или передана в CAM-модуль через интерфейс управления 218. В некоторых вариантах осуществления изобретения показанная на фиг. 14 таблица может служить примером идентификационных данных составного потока. В некоторых вариантах осуществления изобретения данные из показанной на фиг. 14 таблицы могут использоваться для управления декодированием программ из составного потока пакетированных данных одним или несколькими CAM-модулями в соответствии с идентификаторами пакетов, содержащимися в показанной на фиг. 14 таблице соответствия идентификаторов пакетов.
Следует заметить, что для любого транспортного потока может быть несколько входов в показанную на фиг. 14 таблицу соответствия идентификаторов пакетов, относящихся к разным идентификаторам пакетов требуемой программной услуги и различным другим призрачным идентификаторам пакетов, присутствующим в транспортном потоке.
Следует также заметить, что таблица соответствия идентификаторов пакетов может меняться со временем, так что она либо повторно передается на CAM-модули CI-контроллером, либо по меньшей мере частично повторно передается в ответ на изменение в преобразовании. Одной из причин того, что повторное преобразование может измениться, является то, что вновь идентифицированный призрачный пакет имеет идентификатор пакета, который соответствует другому идентификатору пакета в составном потоке пакетированных данных, что вызывает необходимость преобразования одного из них, идентификаторов или обоих идентификаторов пакетов.
На фиг. 15 схематично показана блок-схема операций выявления, какой из CAM-модулей имеющейся последовательности таких модулей способен декодировать требуемую программную услугу.
Показанные на фиг. 15 операции отображают взаимодействие или квитирование установления связи между хост-устройством и каждым CAM-модулем из набора CAM-модулей. Далее рассматриваются операции, относящиеся только к одному CAM-модулю из набора, но следует понимать, что соответствующие операции выполняются в отношении других CAM-модулей из набора.
Этап 300 выполняется при запуске или загрузке системы и состоит в том, что каждый CAM-модуль посылает данные (т.н. индикатор системы условного доступа CA_SYS_ID) для идентификации типа CA-системы, которую данный CAM-модуль способен дешифровать при условии получения соответствующих ECM/EMM-данных для услуги.
Этап 310 имеет место, когда для дешифрования выбрана новая программная услуга, например, с помощью пульта управления или работающего по командам таймера устройства записи, или когда CA-параметры, связанные с программной услугой, изменяются (например, с "нешифрованных" на "шифрованные" или наоборот). Хост-устройство посылает идентификаторы пакетов, относящиеся к требуемой программной услуге, в CAM-модуль набора 114. Каждый CAM-модуль на этапе 320 обнаруживает ECM- и EMM-данные, относящиеся к этой услуге, и на этапе 330 выявляет (со ссылкой на ECM- и EMM-данные, а также собственные возможности CAM-модуля), возможно ли декодирование такой услуги данным CAM-модулем. Естественно, на этапе 310 хост-устройство может решить послать вызывающие вопрос идентификаторы пакетов только на те CAM-модули, которые на этапе 300 показали изначальную (принципиальную) способность декодировать такой тип данных.
На этапе 340 хост-устройство проверяет ответ от текущего запрашиваемого CAM-модуля. Если CAM-модуль может декодировать программную услугу, то затем на этапе 350 хост-устройство распределяет задачу декодирования данной программной услуги текущему запрашиваемому CAM-модулю. Если нет, то затем, если еще остается CAM-модуль, который еще не был запрошен, хост-устройство возвращается к этапу 310, чтобы запросить следующий CAM-модуль. В противном случае, если больше не остается незапрошенных CAM-модулей, и процесс прекращается, а пользователь дополнительно оповещается, что требуемая программная услуга не может быть декодирована имеющимся в системе набором 114 CAM-модулей.
На фиг. 16 схематично показан алгоритм управления несколькими тюнерами 102, 104, реализуемый хост-устройством, в частности, например центральным процессором 132 хост-устройства. На фиг. 16 левая часть блок-схемы относится к операциям, выполняемым хост-устройством, а правая - к операциям, выполняемым CAM-модулем из набора 114.
Данный процесс вводит понятие "первичного" и "вторичного" тюнера, хотя это может рассматриваться в качестве эквивалента "первичному" и "вторичному" транспортному потоку, т.к. в настоящих вариантах осуществления изобретения имеется однозначное соответствие между работой тюнера и приемом транспортного потока, другими словами, в настоящих вариантах осуществления изобретения каждый тюнер принимает один транспортный поток.
На этапе 360 заводской установкой является обозначение тюнера 102 (тюнера А) и принимаемого тюнером 102 транспортного потока определением "первичный", а тюнера 104 (тюнера Б) и принимаемого тюнером 104 транспортного потока - определением "вторичный". Следует заметить, что в нормальном режиме работы только один тюнер требуется для просмотра телепрограммы, как говорят, "вживую"; одной из функций использования другого тюнера является запись второй программной услуги в то время, когда первая услуга просматривается "вживую". Альтернативно, первый из тюнеров или транспортных потоков, первоначально запрошенных для использования, может получить первоначальное обозначение первичного транспортного потока или первичного тюнера.
На этапе 362 центральный процессор 132 выясняет, используется ли вторичный тюнер (транспортный поток), например, для записи программной услуги для последующего просмотра. Если вторичный тюнер не используется, то на этапе 364 центральный процессор 132 или CI-контроллер сообщает набору 114 CAM-модулей о том, что вторичный тюнер свободен, в ответ на что один из CAM-модулей набора может принять решение использовать вторичный тюнер для непросматриваемого приема непросматриваемой информации на этапе 366. Другими словами, если тюнер в данный момент времени не используется для предоставления программы для декодирования, то он считается доступным для использования в целях доступа к каналу (например, настройки на канал), несущему непросматриваемую информацию.
В данном случае термин "непросматриваемый прием" может относиться к приему CAM-модулем непросматриваемой информации, такой как информация управления CAM-модулем, служебные данные, встроенное программное обеспечение или обновления программного обеспечения или т.п., которая может требовать исключительного использования этим CAM-модулем или тюнером в течение неопределенного времени.
Другой пример относится к т.н. "навязыванию видео по требованию". В данной ситуации CAM-модуль может превентивно или по команде от головной телевизионной станции требовать сохранения, к примеру, на жестком диске принимаемых данных, относящихся к видеопрограммам, которые может пожелать просмотреть пользователь. Соответственно, с этой целью CAM-модуль может выступать в роли контроллера управления хранением непросматриваемой информации для последующего доступа. Принятые данные могут относиться ко всей программе, или к анонсу, или рекламе программы или могут обеспечивать достаточный объем буферных данных для мгновенной инициации ответа (по команде пользователя), даже в ходе трансляции программы. Прием данных такого рода особо не запрашивается или не инициируется пользователем; данные принимаются по инициативе CAM-модуля или иной части системы в качестве фонового процесса и рассматриваются в качестве "непросматриваемых данных" или "непросматриваемой информации", т.к. а) такие данные часто передаются с меньшей скоростью, чем скорость передачи декодируемых или просматриваемых данных, и б) пользователь должен предпринять дополнительные шаги (такие как запрос доступа к данным, хранящимся в устройстве записи на жесткий диск), прежде чем даже видимая часть может быть просмотрена. Данные могут быть декодированы CAM-модулем, выступающим в роли декодера непросматриваемой информации.
Непросматриваемая информация может переноситься по меньшей мере одним транспортным потоком.
В течение времени, пока на этапе 366 осуществляется прием служебных или иных непросматриваемых данных, любые другие обращения к этапу 362 будут приводить к индикации занятого состояния вторичного тюнера. Естественно, если пользователь потребует использования вторичного тюнера, например, для записи программной услуги, то использование тюнера CAM-модулем для непросматриваемого фонового приема может быть прекращено. Это осуществляется таким образом, что пользователь даже не знает, что CAM-модуль когда-либо использовал вторичный тюнер.
Возвращаясь к этапу 362, если вторичный тюнер требуется для использования, то на этапе 368 выбираются идентификаторы пакетов программной услуги, которую необходимо принять вторичному тюнеру (и, дополнительно, идентификаторы любых призрачных пакетов в данном транспортном потоке). Это соответствует этапам 250 и 252 на фиг. 13. На этапе 370 идентификаторы пакетов вторичного транспортного потока, выбранные как описано выше, преобразуются (согласно этапу 254 на фиг. 13), и пакеты, соответствующие выбранным идентификаторам пакетов первичного и вторичного тюнеров мультиплексируются для формирования составного потока пакетированных данных. Следует заметить, что как рассмотрено выше, необходимо только преобразовать идентификатор пакета, если имеет место коллизия или конфликт с другим идентификатором пакета из другого транспортного потока. Система может преобразовать все идентификаторы пакетов, выбранных из вторичного транспортного потока, или идентификаторы только тех пакетов, что вступили в конфликт идентификаторов. Однако важным является то, что именно вторичный транспортный поток является потоком, имеющим идентификаторы пакетов, которые по меньшей мере являются кандидатами на преобразование, если преобразование окажется необходимым. Идентификаторы пакетов в первичном потоке не преобразуются, они сохраняют свои исходные значения (какими они были при приеме).
Такой порядок сохраняется до того момента, пока на этапе 372 не будет выявлена смена канала (программной услуги). Смена канала может инициироваться пользователем с помощью пульта управления или машинной операции смены канала, например, по команде таймера управления процессом записи, требующим доступа к конкретной программной услуге. Действия в ответ на обнаружение смены канала зависят от того, в каком тюнере, вторичном или первичном, происходит смена канала.
Если изменяется вторичный транспортный поток, то осуществляется возврат к этапу 362, но не происходит никаких изменений с назначением первичного и вторичного транспортных потоков.
Если, однако, меняется канал на первичном тюнере (транспортном потоке), то осуществляется переход к этапу 374, на котором назначение тюнеров первичным и вторичным меняется на противоположное, и также осуществляется возврат к этапу 362. Т.е. в системе, имеющей два тюнера, каждый из которых принимает соответствующий транспортный поток, один поток, который до этого был назначен первичным, теперь назначается вторичным, а второй поток, который ранее был вторичным, теперь назначается первичным. (В системах, имеющих более двух тюнеров, тюнер, ранее бывший первичным, теперь назначается вторичным).
Результатом этого является то, что транспортный поток, ранее бывший первичным, теперь обрабатывается как вторичный и, таким образом, подлежит процессу преобразования идентификаторов его пакетов на этапе 370, или идентификаторы его пакетов по меньшей мере становятся кандидатами на преобразование. В свою очередь, это означает, что нет необходимости выполнять какое-либо дальнейшее преобразование или изменение идентификаторов пакетов ранее бывшего вторичным транспортного потока, т.к. такой ранее бывший вторичным транспортный поток теперь обрабатывается как первичный. Что касается пользователя, это означает, что просмотр не прерывается на канале, который не изменяется, т.к. тюнер, принимающий этот канал (или транспортный поток, несущий этот канал), теперь назначается первичным и, таким образом, теперь нет необходимости дальнейшего преобразования идентификаторов пакетов, поступающих от этого тюнера.
Изменение назначения транспортного потока с первичного на вторичный в рассматриваемых вариантах осуществления изобретения выполняется сразу, но изменение назначения потока с вторичного на первичный может задерживаться до тех пор, пока не будет выявлено, что вторичный транспортный поток должен быть перенастроен, т.к. не существует текущего первичного потока, в этом случае изменение применяется к упомянутому вторичному транспортному потоку. Следует заметить, такая особенность характерна для систем с двумя и более тюнерами.
Если бы представленная система не имела места, то смена канала первичным тюнером могла бы потребовать повторного преобразования идентификаторов пакетов, принимаемых вторичным тюнером. Это происходит потому, что преобразование, выполненное в отношении идентификаторов пакетов вторичного транспортного потока, осуществляется для исключения конфликта между идентификаторами пакетов первичного тюнера и преобразованными идентификаторами пакетов вторичного тюнера. Если не было изменения в назначении первичного и вторичного тюнеров, то смена программной услуги для первичного тюнера может привести к конфликту идентификаторов пакетов и, таким образом, к последующей необходимости преобразования вторичных идентификаторов пакетов, даже если не происходило смены канала на вторичном тюнере. Соответственно, в отсутствие настоящей технологии смена канала на первичном тюнере могла бы привести к временному прерыванию услуги для программы, принимаемой вторичным тюнером, что, в свою очередь, было бы субъективно неприятно для пользователя.
Этап 374 может быть описан далее следующим образом. В ответ на выявление смены канала или транспортного потока, принимаемого первичным тюнером (или, другими словами, в ответ на выявление использования первичным тюнером другой программы), первичный тюнер может быть переназначен вторичным, а тюнер, ранее бывший вторичным, переназначен первичным. Однако это не подразумевает, что выполняемая на этапе 370 операция преобразования в отношении бывшего вторичным (а ныне первичного) транспортного потока не должна выполняться, и действительно это было бы нежелательно, т.к. это привело бы к возможному прерыванию принимаемой этим тюнером услуги. Но это не означает, что нет необходимости осуществлять какое-либо преобразование вновь назначенных первичных идентификаторов пакетов, чтобы избежать конфликта с предыдущими первичными (теперь вторичными) идентификаторами пакетов после перенастройки.
Другими словами, если выявлено, что выбрана другая программа для декодирования из первичного транспортного потока (по сравнению с декодируемой в настоящее время), или выявлено, что выбран другой транспортный поток (по сравнению с текущим первичным потоком), то вторичный тюнер переназначается первичным.
В случаях, когда в текущий момент первичный тюнер отсутствует (когда первичный тюнер переназначается вторичным, но вторичный тюнер еще не переназначен первичным), то если выявлено, что для декодирования выбрана другая программа из вторичного транспортного потока (по сравнению с декодируемой в настоящее время программой из вторичного транспортного потока), или выявлено, что выбран другой вторичный транспортный поток (по сравнению с текущим вторичным транспортным потоком), то такой вторичный тюнер переназначается первичным.
На фиг. 17 схематично показано мультиплексирование двух отдельных программных услуг.
Используя описанную выше технологию, предлагается механизм объединения выбранных пакетов из двух или более транспортных потоков в единый составной поток пакетированных данных. Пакеты могут мультиплексироваться в правильном порядке, т.е. для любого отдельно принимаемого транспортного потока пакеты, относящиеся к требуемой программной услуге, для декодирования будут появляться в составном потоке пакетированных данных в правильном порядке относительно друг друга. Однако данный механизм не обязательно гарантирует, что мультиплексированные пакеты появятся в согласованном потоке пакетированных данных в правильный временной момент. На практике проблемой может быть ситуация, когда два пакета, предназначенные для включения в составной поток пакетированных данных, будут иметь перекрывающиеся временные позиции; при создании составного потока пакетированных данных один из пакетов должен быть задержан, чтобы быть включенным в составной поток пакетированных данных после другого. Такие временные ошибки могут приводить к соответствующим ошибкам при декодировании или воспроизведении аудио-видео сигнала, представленного упомянутыми пакетами.
На фиг. 17 схематично показан пример такой возможной проблемы. Подмножество пакетов выбирается из каждого из двух транспортных потоков TS1 и TS2. Выбранное подмножество пакетов представляет собой пакеты, вытянутые вдоль временной оси, проходящей на чертеже слева направо. Невыбранные пакеты для ясности просто не показаны на чертеже. Примером временной коллизии является перекрытие по времени пакета 400 из транспортного потока TS1 с пакетом 402 из транспортного потока TS2.
Третий ряд на фиг. 17 (обозначенный "к/от модуля") схематично показывает составной поток пакетированных данных. Видно, что пакет 400 по существу сохранил свое исходное временное положение, но пакет 402 задержан по времени, чтобы попасть в составной поток пакетированных данных после пакета 400.
Четвертый и пятый ряды на фиг. 17 представляют отдельные потоки пакетированных данных, реконструированные после дешифрования набором 114 CAM-модулей и демультиплексирования. И снова видно, что дешифрованный пакет 400' сохранил свое исходное временное положение, в то время как дешифрованный вариант пакета 402 (дешифрованный пакет 402') претерпел временную задержку 404. Аналогичную временную задержку 406 претерпевает последний пакет в транспортном потоке TS2.
Такое изменение во временных положениях пакетов в транспортных потоках делает временные метки задающего тактового генератора программы в потоке пакетированных данных далее неточными. В результате тактовый генератор приемника, необходимый для декодирования программной услуги стандарта MPEG, будет не достаточно точным, и это может вызвать субъективно неприятные ощущения у пользователя, такие как ошибки синхронизации артикуляции губ с речью.
Для решения этой проблемы далее рассматриваются две возможных технологии. На фиг. 18 схематично показан пакет 410 (имеющий предварительный заголовок или не имеющий его, как это описано выше), который также включает в себя расширенный заголовок 412, содержащий по меньшей мере время прибытия пакета в виде временной метки, присваиваемой каждому пакету транспортного потока, приходящему с соответствующего демодулятора, или, другими словами, соотносимой со временем формирования составного потока пакетированных данных.
На фиг. 19 схематично показана таблица с тактовой информацией пакетов, хранящая аналогичные данные, хотя и не в форме заголовка пакета, позволяющие восстановить исходное распределение пакетов транспортного потока по времени на финальной стадии декодирования. Таблица может поступать в CAM-модули через интерфейс управления, к примеру, в виде конфиденциальных DVB-данных или виде табличных данных. Такие данные могут передаваться в виде пакета конфиденциальных данных, располагающегося в составном потоке пакетированных данных по соседству с пакетом, к которому они относятся. Это связывает упомянутые данные с соответствующим пакетом.
При первичном детальном рассмотрении фиг. 9 видно, что таблица с тактовой информацией пакетов содержит пять полей для каждого пакета транспортного потока. Это последовательный номер 420, присваиваемый хост-устройством каждому входящему пакету транспортного потока как части последовательности, это значение 422 идентификатора пакета, взятое из его заголовка, это время 424 прибытия пакета, представляющее собой временную метку, присваиваемую хост-устройством или CI-контроллером каждому пакету транспортного потока, приходящему из соответствующего демодулятора, это флажок 426 "Sent" ("Отправлено"), означающий, что пакет транспортного потока послан в набор 114 CAM-модулей для дешифрования, и это флажок "Received" ("Принято"), означающий, что пакет транспортного потока получен из набора 114 CAM-модулей после дешифрования.
Используя информацию, содержащуюся в таблице с тактовой информацией пакетов, CI-контроллер может вставлять принятые обратно из набора 114 CAM-модулей дешифрованные пакеты в их исходные временные положения согласно временам прибытия пакетов, хранящимся в таблице. Естественно, здесь может иметь место небольшая задержка всех пакетов в восстанавливаемом транспортном потоке (т.к. пакеты не могут быть повторно вставлены в транспортный поток раньше, чем время, когда они будут приняты обратно из набора CAM-модулей), но относительный временное положение всех пакетов в восстановленном транспортном потоке может быть сохранено правильным путем использования данных о прибытии пакетов, хранящихся в таблице с тактовой информацией пакетов.
Аналогичная задача может быть решена с использованием данных показанного на фиг. 18 расширенного заголовка 412.
На фиг. 20 схематично показан процесс формирования представленного на фиг. 18 пакета, а фиг. 21 иллюстрирует процесс использования представленного на фиг. 18 пакета.
Из фиг. 20 видно, что на этапе 430 CI-контроллер определяет текущее время прибытия пакета транспортного потока в CI-контроллер, а на этапе 432 добавляет по меньшей мере упомянутое время прибытия в расширенный заголовок 412.
Согласно фиг. 21, когда пакет получен обратно из набора CAM-модулей после дешифрования, упомянутый CI-контроллер на этапе 434 распознает тактовую информацию, ранее вставленную в расширенный заголовок 412, и на этапе 436 либо генерирует управляющую информацию для управления декодированием данного пакета в правильное время, либо повторно вставляет пакет обратно в восстановленный транспортный поток в правильное время (или, как это описано выше, по меньшей мере в правильное относительно других пакетов в восстановленном транспортном потоке время).
На фиг. 22 схематично показан процесс формирования показанной на фиг. 19 таблицы, а на фиг. 23 - процесс использования этой таблицы.
Согласно фиг. 22 на этапе 440 CI-контроллер определяет время прибытия пакета транспортного потока от соответствующего демодулятора, а на этапе 422 сохраняет это время прибытия в качестве части таблицы, подобной показанной на фиг. 19 таблице, наряду с последовательным номером и идентификатором пакета, извлеченным из заголовка пакета. Если CI-контроллер направляет такой пакет на дешифрование, то CI-контроллер выставляет флажок 426 "Sent" ("Отправлено"), чтобы указать, что этот пакет имел место быть.
Согласно фиг. 23, когда пакет получен обратно после процесса дешифрования, CI-контроллер выставляет на этапе 444 флажок 428 "Received" ("Принято") и затем, на этапе 446, получает доступ к тактовой информации из поля 424 таблицы, используя идентификатор 422 пакета, и последовательный номер 420 для обозначения данных правильного пакета. Дополнительно, раз уж получен доступ к ряду данных для пакета, он может быть удален из показанной на фиг. 19 таблицы, чтобы избежать слишком большого роста объема данных в этой таблице. Как и ранее, на этапе 448 CI-контроллер либо управляет процессом декодирования данного пакета, которое должно осуществляться в правильный момент времени, либо управляет вставкой пакета в восстанавливаемый транспортный поток в правильное время или по меньшей мере в правильное относительно других пакетов в таком восстанавливаемом транспортном потоке время.
Двумя отличительными признаками некоторых систем условного доступа, которые повышают безопасность системы, являются т.н. процедура избегания и т.н. процедура аннулирования.
Избегаемые данные включаются в виде т.н. таблицы описания служб (Service Description Table) в состав транслируемых данных, таких, например, как служебные данные, включающие в себя информацию безопасной авторизации хост-устройств (приемников контента). Избегание позволяет хост-устройству быть уведомленным о запрете использования пиратских или иных неавторизованных CAM-модулей или о запрете приема и дешифрования некоторых услуг. Неавторизованные модули или услуги определяются данными таблицы описания служб. Соответственно, избегание накладывает обязательство на хост-устройство не использовать CAM-модуль.
Аннулирование включает в себя предписание головной телевизионной станции хост-устройству пропускать в CAM-модуль данные, содержащие указание модулю не взаимодействовать с конкретным номером модели фирмы-производителя как с хост-устройством. С другой стороны, аннулирование может использоваться в ситуациях, когда безопасность конкретной модели скомпрометирована, чтобы защитить целостность всей системы условного доступа. Таким образом, аннулирование накладывает на CAM-модуль запрет на оказание услуг дешифрования какому-либо хост-устройству. Данные аннулирования передаются путем ввода в EMM-сообщение указания CAM-модулю, где найти файл данных сигнала аннулирования (Revocation Signalling Data) в карусели данных общего интерфейса CI Plus.
В ситуации избегания или аннулирования хост-устройство выявляет на основе данных таблицы описания служб, авторизовано ли данное хост-устройство декодировать принятые программные данные. Хост-устройство может дополнительно извещать пользователя о наступлении такой ситуации, например, посредством непоказанной на чертеже экранной индикации.
Данные аннулирования обычно подписываются сертификатом оператора, который в свою очередь подписывается корневым сертификатом, и таким образом, описываемые ниже меры предосторожности больше относятся к данным избегания, чем к данным аннулирования.
Все эти данные содержатся в транспортном потоке. В системе с одним тюнером и одним CAM-модулем целостность избегаемых и/или аннулируемых данных может быть по существу гарантирована тюнером, обходящим CAM-модуль, проверяющим данные таблицы описания служб на наличие любых избегаемых или аннулируемых данных, относящихся к текущему хост-устройству и/или CAM-модулю, и пропускающим упомянутые избегаемые или аннулируемые данных в CAM-модуль для исполнения. Такие меры позволяют исключить манипулирование CAM-модулем данными в транспортном потоке до того момента, пока эти данные не будут проверены хост-устройством. (Это опасно в ситуации, когда CAM-модуль скомпрометирован).
Ситуация еще больше усложняется в случае множества тюнеров и мультиплексированного составного потока пакетированных данных. Здесь не просто обойти набор CAM-модулей в контексте составного потока пакетированных данных. Так, существует опасность, что один или несколько CAM-модулей из набора могут исказить содержащиеся в таблице описания служб избегаемые или аннулируемые данные или манипулировать ими, прежде чем хост-устройство будет действовать согласно этим данным в контексте процесса выявления, авторизовано ли хост-устройство работать с CAM-модулем, например, должно ли оно избегать CAM-модуль (к примеру, посредством команды на CAM-модуль не декодировать принимаемые программные данные) или отказываться от взаимодействия с конкретным CAM-модулем.
На фиг. 24 схематично показана конфигурация, позволяющая по меньшей мере смягчить эту проблему в контексте, например, показанного на фиг. 4 хост-устройства.
Согласно фиг. 24 мультиплексированный (составной) поток данных, сформированный CI-контроллером 112, подписывается блоком 460 цифровой подписи, используя секретный криптографический ключ. Подписанный цифровой подписью мультиплексированный поток данных затем поступает в набор 114 CAM-модулей, выступающий в роли декодера контента для декодирования двух и более программ из составного потока пакетированных данных согласно идентификаторам пакетов, содержащимся в идентификационных данных потоков. После дешифрования подпись проверяется блоком 462 проверки подписи (который проверяет действенность подписи), прежде чем данные вернутся обратно в демультиплексор 142.
Здесь могут использоваться известные технологии цифровой подписи с использованием личного ключа и проверки с использованием открытого ключа. Такой ключ может быть уникальным для приемника, например, секретно закладываться в память приемника при изготовлении. Такая цифровая подпись является примером признака цифровой безопасности.
Секретный ключ может передаваться между блоком 460 цифровой подписи и блоком 462 проверки подписи посредством защищенной линии 464 передачи данных. Пара, состоящая из личного и открытого ключей, может отличаться от хост-устройства к хост-устройству для повышения потенциально возможной достоверности системы проверки.
Цифровая подпись может применяться для всего составного потока пакетированных данных или только для данных таблицы описания служб в потоке данных. Так, в некоторых вариантах осуществления изобретения цифровая подпись применяется по меньшей мере к данным таблицы описания служб, включенным в состав мультиплексированного потока. Цифровая подпись может вставляться в поток данных или может передаваться отдельно между блоками 460 и 462.
Если хост-устройство обнаружит, что цифровая подпись искажена, оно может действовать по-разному. Оно может сообщить об этом пользователю, например, путем отображения на экране. Оно может с помощью интерфейса управления 218 по очереди включать и выключать CAM-модули, чтобы выявить, какой из CAM-модулей вызывает искажение, и затем постоянно или практически постоянно деактивировать этот CAM-модуль. В любом случае CI Plus-спецификация извещает, что хост-устройство не позволяет испорченному или избегаемому CAM-модулю дешифровывать текущий контент для просмотра пользователем на экране или для записи.
Следует иметь в виду, что некоторые из вышеописанных технологий, например технологии генерации составного потока пакетированных данных, относятся к системам, использующим по меньшей мере два транспортных потока. Другие технологии относятся к системам, использующим один или несколько транспортных потоков.
Варианты осуществления изобретения также включают в себя сигнал данных, представляющий собой сигнал в рамках описанного устройства, в частности, (хотя и не исключительно), сигнал, проходящий от хост-устройства к CAM-модулю или набору CAM-модулей, или обратный сигнал. Носитель данных, такой как память, с помощью которого сохраняется такой сигнал, также считается вариантом осуществления изобретения. Носитель данных может представлять собой, к примеру, энергонезависимый машиночитаемый носитель данных.
В контексте фиг. 24 примером такого сигнала является сигнал аудио-видео данных, содержащий составной поток пакетированных данных, имеющий программные данные двух или более потоков пакетированных данных, имеющих подмножество пакетов данных двух или более принимаемых потоков пакетированных данных, подмножество, включающее в себя пакеты аудио-видео данных, которые относятся к тем программам, которые декодируются, и служебные данные, включающие в себя защищенную информацию авторизации для приемников контента, служебные данные, имеющие примененный цифровой индикатор безопасности.
Когда речь идет хотя бы о частичной реализации изобретения с использованием программно-управляемого устройства обработки, следует понимать, что такое программное обеспечение и носитель, на котором предоставляется упомянутое программное обеспечение (такой как энергонезависимый машиночитаемый носитель данных, например, магнитный или оптический диск или энергонезависимая память), также считаются вариантами осуществления настоящего изобретения.
Приведенные ниже варианты осуществления изобретения предусматривают использование рассмотренных выше отличительных признаков в их различных комбинациях.
В вариантах осуществления изобретения может предлагаться способ работы приемника аудио-видео контента, имеющего декодер контента, пригодный для декодирования аудио-видео программы из потока пакетированных данных с использованием пакетов данных, определяющих информацию дешифрования, причем способ содержит следующие этапы:
этап приема закодированного аудио-видео контента в виде потока пакетированных данных, содержащего одну или несколько программ, имеющих пакеты данных, идентифицируемые по соответствующим наборам из одного или нескольких идентификаторов пакетов, и содержащего программы построения соответствий идентификационных данных соответствующим наборам идентификаторов пакетов;
этап выбора пакетов данных из потока пакетированных данных для требуемой программы в соответствии с набором идентификаторов пакетов, определенных идентификационными данными для этого потока в отношении требуемой программы;
этап выбора дополнительных пакетов данных из потока пакетированных данных, из которого выбрана программа, имеющих идентификаторы пакетов, не включенные в состав идентификационных данных для данного потока пакетированных данных;
этап генерирования составного потока пакетированных данных из выбранных пакетов;
этап генерирования идентификационных данных составного потока, указывающих идентификаторы пакетов, включенных в составной поток пакетированных данных; и
этап подачи составного потока пакетированных данных в декодер контента для декодирования программы из составного потока пакетированных данных в соответствии с идентификаторами пакетов, содержащимися в идентификационных данных составного потока.
В вариантах осуществления изобретения может предлагаться способ работы приемника аудио-видео контента, имеющего декодер контента, пригодный для одновременного декодирования двух и более аудио-видео программ из одного потока пакетированных данных, причем способ содержит следующие этапы:
этап приема закодированного аудио-видео контента в виде двух или более потоков пакетированных данных, причем каждый поток содержит одну или несколько программ, имеющих пакеты данных, идентифицированные по соответствующим наборам из одного или нескольких идентификаторов пакетов, причем каждый поток пакетированных данных содержит программы построения соответствий идентификационных данных соответствующим наборам идентификаторов пакетов;
этап генерирования составного потока пакетированных данных, содержащего программные данные из двух или более потоков пакетированных данных, посредством:
назначения одного из потоков пакетированных данных, из которого должны декодироваться программные данные, в качестве первичного потока пакетированных данных, а других потоков пакетированных данных, из которых должны декодироваться программные данные, в качестве вторичных потоков пакетированных данных;
выбора пакетов данных из потока пакетированных данных для каждой требуемой программы в соответствии с наборами идентификаторов пакетов, определяемыми идентификационными данными для этого потока в отношении требуемой программы;
построения соответствий идентификаторов по меньшей мере тех пакетов, которые были выбраны из вторичного(ных) потока(ков) пакетированных данных и которые имеют идентификаторы пакетов, идентичные идентификаторам пакетов из другого потока пакетированных данных, другим соответствующим идентификаторам пакетов, и не построения соответствий идентификаторов тех пакетов, которые были выбраны из первичного потока пакетированных данных; и
этап генерации идентификационных данных составного потока, определяющих идентификаторы пакетов данных в составном потоке пакетированных данных;
этап декодирования двух или более программ из составного потока пакетированных данных в соответствии с идентификаторами пакетов, содержащимися в идентификационных данных составного потока;
этап переназначения потока пакетированных данных с первичного на вторичный поток пакетированных данных в ответ на выявление выбора другой программы для декодирования из первичного потока пакетированных данных или выбора для приема другого потока пакетированных данных вместо первичного потока пакетированных данных.
В вариантах осуществления изобретения может предлагаться способ работы приемника аудио-видео контента, имеющего декодер контента, пригодный для одновременного декодирования двух и более аудио-видео программ из одного потока пакетированных данных посредством использования пакетов данных, определяющих информацию дешифрования, причем способ содержит следующие этапы:
этап приема закодированного аудио-видео контента в виде двух или более потоков пакетированных данных, причем каждый поток содержит одну или несколько программ, имеющих пакеты данных, идентифицируемые по соответствующим наборам из одного или нескольких идентификаторов пакетов, причем каждый поток пакетированных данных содержит программы построения соответствий идентификационных данных соответствующим наборам идентификаторов пакетов и служебные данные, включающие в себя информацию безопасной авторизации приемников контента;
этап генерирования составного потока пакетированных данных, содержащего программные и служебные данные из двух или более потоков пакетированных данных;
этап применения цифрового индикатора безопасности по меньшей мере к служебным данным, включенным в составной поток пакетированных данных;
этап подачи составного потока пакетированных данных в декодер контента для декодирования двух или более программ из составного потока пакетированных данных в соответствии с идентификаторами пакетов, содержащимися в идентификационных данных составного потока;
этап приема служебных данных от декодера контента;
этап определения достоверности цифрового индикатора безопасности, применяемого для служебных данных; и
этап выявления, авторизован ли приемник контента декодировать принимаемые программные данные в ответ на служебные данные.
В вариантах осуществления изобретения может предлагаться способ работы приемника аудио-видео контента, имеющего декодер контента, пригодный для одновременного декодирования двух и более аудио-видео программ из одного потока пакетированных данных, состоящего из закодированных пакетов аудио-видео данных, причем способ содержит следующие этапы:
этап приема закодированного аудио-видео контента в виде двух или более потоков пакетированных данных, причем каждый поток данных содержит одну или несколько программ, имеющих соответствующие закодированные пакеты аудио-видео данных;
этап генерирования составного потока пакетированных данных, содержащего программные данные из двух или более потоков пакетированных данных, посредством выбора подмножества пакетов данных из двух или более принимаемых потоков пакетированных данных, причем подмножество содержат аудио-видео данные, относящиеся к тем программам, которые должны декодироваться;
этап хранения тактовой информации, указывающей по меньшей мере время прибытия тех пакетов аудио-видео данных, которые включены в составной поток пакетированных данных; и
этап декодирования и выдачи данных аудио-видео программы из составного потока пакетированных данных в соответствии с временными показателями, хранящимися для каждого декодированного аудио-видео пакета.
В вариантах осуществления изобретения может предлагаться приемник аудио-видео контента для приема и декодирования сигналов с аудио-видео данными, передаваемыми по каналам передачи данных, причем по меньшей мере один канал передачи данных несет не просматриваемую информацию, приемник, содержащий:
тюнер, способный одновременно настраиваться на два или более канала передачи данных;
мультиплексор, предназначенный для генерации составного сигнала данных из принятых аудио-видео сигналов, относящихся к требуемой для декодирования программе;
декодер контента, пригодный для одновременного декодирования двух и более аудио-видео программ из составного сигнала данных;
детектор, предназначенный для выявления, не используется ли один или несколько настроенных тюнером каналов передачи данных для предоставления программы для декодирования;
контроллер, реагирующий на выявление, что канал передачи данных в настоящее время не используется, для управления тюнером с целью настройки этого канала на канал передачи, несущий непросматриваемую информацию; и
декодер непросматриваемой информации для декодирования принимаемой непросматриваемой информации.
В вариантах осуществления изобретения может предлагаться способ работы приемника аудио-видео контента, имеющего декодер контента, пригодный для декодирования аудио-видео программы из потока пакетированных данных посредством использования пакетов данных, определяющих информацию дешифрования, причем способ содержит следующие этапы:
этап приема закодированного аудио-видео контента в виде потоков пакетированных данных, содержащих одну или несколько программ, имеющих пакеты данных, идентифицируемые по соответствующим наборам из одного или нескольких идентификаторов пакетов, и программы построения соответствий идентификационных данных соответствующим наборам идентификаторов пакетов;
этап выбора пакетов данных из потока пакетированных данных для каждой требуемой программы в соответствии с набором идентификаторов пакетов, определяемым идентификационными данными для этого потока в отношении требуемой программы;
этап выбора дополнительных пакетов данных из каждого потока пакетированных данных, из которого выбрана программа, которые содержат данные задающего тактового генератора, относящиеся к выбранной программе, в том случае, если данные задающего тактового генератора программы не включены в пакеты, относящиеся к выбранной программе;
этап генерирования составного потока пакетированных данных из выбранных пакетов; и
этап генерирования идентификационных данных составного потока, определяющих идентификаторы пакетов данных в составном потоке пакетированных данных; и
этап подачи составного потока пакетированных данных в декодер контента для декодирования в соответствии с данными задающего тактового генератора программы и идентификаторами пакетов, содержащимися в идентификационных данных составного потока.
Очевидно, что в свете представленных выше идей возможны многочисленные модификации и вариации предмета настоящего изобретения. Вследствие этого понятно, что в рамках прилагаемой формулы изобретения упомянутая технология может осуществляться иными способами, чем конкретно описано в настоящем документе.
Изобретение относится к приему и дешифрованию аудио-видео контента. Техническим результатом является скрытая передача некоторых пакетов так, что пользователь об этом не знает, что позволяет передавать приемнику данные, которые потенциальному хакеру трудно обнаружить и использовать незаконным образом. Указанный технический результат достигается тем, что принимают кодированный аудио-видео контент в виде потока пакетированных данных, содержащего одну или более программ, имеющих пакеты данных, идентифицируемые посредством соответствующих наборов из одного или более идентификаторов пакетов, и содержащего идентификационные данные, устанавливающие соответствие между программами и соответствующими наборами идентификаторов пакетов; выбирают пакеты данных из потока пакетированных данных для требуемой программы в соответствии с набором идентификаторов пакетов, определяемым идентификационными данными для этого потока в отношении требуемой программы; выбирают дополнительные пакеты данных из потока пакетированных данных, из которого выбрана программа, содержащие идентификаторы пакетов, не включенные в идентификационные данные для этого потока пакетированных данных; генерируют составной поток пакетированных данных из выбранных пакетов; генерируют идентификационные данные составного потока, указывающие идентификаторы пакетов, включенных в составной поток пакетированных данных, и подают составной поток пакетированных данных в декодер контента для декодирования программы из составного потока пакетированных данных согласно идентификаторам пакетов, содержащимся в идентификационных данных составного потока. 3 н. и 13 з.п. ф-лы, 24 ил. 
1. Способ работы приемника аудио-видео контента, содержащего декодер контента, выполненный с возможностью декодирования аудио-видео программы из потока пакетированных данных с использованием пакетов данных, определяющих информацию дешифрования, причем способ содержит этапы, на которых:
принимают закодированный аудио-видео контент в виде потока пакетированных данных, содержащего одну или более программ, содержащих пакеты данных, идентифицируемые посредством соответствующих наборов из одного или более идентификаторов пакетов, и содержащего идентификационные данные, устанавливающие соответствие между программами и соответствующими наборами идентификаторов пакетов;
выбирают из потока пакетированных данных пакеты данных для требуемой программы в соответствии с набором идентификаторов пакетов, определяемым идентификационными данными для упомянутого потока в отношении требуемой программы;
выбирают дополнительные пакеты данных из потока пакетированных данных, из которого выбрана программа, содержащие идентификаторы пакетов, не включенные в состав идентификационных данных для упомянутого потока пакетированных данных;
генерируют составной поток пакетированных данных из выбранных пакетов;
генерируют идентификационные данные составного потока, указывающие идентификаторы пакетов, включенных в составной поток пакетированных данных; и
подают составной поток пакетированных данных в декодер контента для декодирования программы из составного потока пакетированных данных в соответствии с идентификаторами пакетов в идентификационных данных составного потока.
2. Способ по п. 1, содержащий этап, на котором выбирают из каждого потока пакетированных данных, из которого выбрана программа, дополнительные пакеты данных, содержащие задающие тактовые данные программы, относящиеся к выбранной программе.
3. Способ по п. 1 или 2, содержащий этап, на котором включают идентификационные данные составного потока в составной поток пакетированных данных.
4. Способ по п. 1 или 2, в котором:
декодер контента выполнен с возможностью одновременного декодирования двух или более аудио-видео программ из одного потока пакетированных данных;
при этом на этапе генерирования составного потока пакетированных данных формируют составной поток пакетированных данных из пакетов, представляющих две или более программ.
5. Способ по п. 4, в котором:
на этапе приема принимают два или более потоков пакетированных данных;
применяют этапы выбора к каждому потоку пакетированных данных, из которых выбирается программа;
составной поток пакетированных данных содержит программные данные из двух или более потоков пакетированных данных; и
на этапе генерирования составного потока пакетированных данных объединяют выбранные пакеты в составной поток пакетированных данных.
6. Способ по п. 5, содержащий этап, на котором устанавливают соответствие между идентификаторами пакетов, выбранных по меньшей мере из одного потока пакетированных данных, и отличающимися от них идентификаторами пакетов.
7. Способ по п. 6, содержащий этапы, на которых:
назначают один из принимаемых потоков пакетированных данных первичным потоком пакетированных данных, а остальные принимаемые потоки пакетированных данных вторичными потоками пакетированных данных; и
устанавливают соответствие для идентификаторов пакетов из вторичных потоков пакетированных данных и не устанавливают соответствие идентификаторов пакетов из первичного потока пакетированных данных.
8. Способ по п. 5, содержащий этап, на котором:
идентифицируют источник каждого выбранного пакета путем вставки дополнительной информации в начало каждого пакета, входящего в составной поток пакетированных данных.
9. Способ по п. 1 или 2, содержащий этапы, на которых:
указывают посредством декодера контента, что декодеру контента требуются пакеты из потока пакетированных данных с определенным идентификатором пакета, не включенным в идентификационные данные для упомянутого потока пакетированных данных; и
выбирают пакеты с упомянутым идентификатором пакета из упомянутого потока пакетированных данных для включения с составной поток пакетированных данных.
10. Носитель данных, хранящий компьютерную программу, которая при выполнении компьютером вызывает выполнение компьютером способа по любому из пп. 1-9.
11. Приемник аудио-видео контента, содержащий:
декодер контента, выпаленный с возможностью декодирования аудио-видео программы из потока пакетированных данных с использованием пакетов данных, определяющих информацию дешифрования;
тюнер, выполненный с возможностью приема кодированного аудио-видео контента в виде потока пакетированных данных, содержащего одну или более программ, содержащих пакеты данных, идентифицируемые по соответствующим наборам из одного или более идентификаторов пакетов, и содержащего идентификационные данные, устанавливающие соответствие между программами и соответствующими наборами идентификаторов пакетов;
блок выбора, выполненный с возможностью выбора из потока пакетированных данных пакетов данных для требуемой программы в соответствии с набором идентификаторов пакетов, определяемым идентификационными данными для упомянутого потока в отношении требуемой программы, и выбора дополнительных пакетов данных из потока пакетированных данных, из которого выбрана программа, содержащих идентификаторы пакетов, не включенные в идентификационные данные для упомянутого потока пакетированных данных; и
генератор составного потока пакетированных данных, выполненный с возможностью генерирования составного потока пакетированных данных из выбранных пакетов и генерирования идентификационных данных составного потока, указывающих идентификаторы пакетов, включенных в состав составного потока пакетированных данных;
причем упомянутый декодер контента выполнен с возможностью приема составного потока пакетированных данных, поступающего от генератора составного потока пакетированных данных, для декодирования программы из составного потока пакетированных данных в соответствии с идентификаторами пакетов, содержащимися в идентификационных данных составного потока.
12. Приемник по п. 11, в котором блок выбора выполнен с возможностью выбора дополнительных пакетов данных из каждого потока пакетированных данных, из которого выбрана программа, содержащих задающие тактовые данные программы, относящиеся к выбранной программе.
13. Приемник по п. 11 или 12, в котором декодер контента содержит два или более последовательно соединенных декодера контента.
14. Приемник по п. 11, в котором генератор составного потока пакетированных данных выполнен с возможностью включения идентификационных данных составного потока в составной поток пакетированных данных.
15. Приемник по п. 11, характеризующийся тем, что выполнен с возможностью:
приема двух или более потоков пакетированных данных;
при этом блок выбора выполнен с возможностью работы с каждым потоком пакетированных данных, из которого выбрана программа;
составной поток пакетированных данных содержит программные данные из двух или более потоков пакетированных данных; а
генератор составного потока пакетированных данных выполнен с возможностью объединения выбранных пакетов для формирования составного потока пакетированных данных.
16. Приемник по п. 15, в котором генератор составного потока пакетированных данных выполнен с возможностью идентификации источника каждого выбранного пакета путем вставки дополнительной информации в начало каждого пакета составного потока данных.
| ЛАПЧАТЫЙ ЗАЖИМ ДЛЯ ПРИКРЕПЛЕНИЯ ГЛУХОГО ФЛАНЦА К ФЛАНЦАМ ПАРОВОЗНЫХ ПАРОПРОВОДНЫХ ТРУБ И АРМАТУРНЫХ ЧАСТЕЙ ПРИ ГИДРАВЛИЧЕСКОМ ИХ ИСПЫТАНИИ | 1926 |
|
SU4650A1 |
| WO 03085985 A2, 2003-10-16 | |||
| Вибрационный (инерционный) грохот | 1946 |
|
SU77650A1 |
| US 2011298981 A1, 2011-12-08 | |||
| US 2003123657 A1, 2003-07-03 | |||
| RU 2009135053 A, 2011-03-27 | |||
| ПЕРЕДАЧА ИНФОРМАЦИИ, КАСАЮЩЕЙСЯ ГРУПП СЕРВИСОВ, В СИСТЕМЕ ЦИФРОВОЙ ПЕРЕДАЧИ | 1999 |
|
RU2262209C2 |
