МУЛЬТИМЕДИЙНЫЙ ТЕРМИНАЛ ДЛЯ МНОЖЕСТВА ПОЛЬЗОВАТЕЛЕЙ

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

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

До внедрения цифровой технологии декодеры подключались к ограниченному количеству устройств, обычно только к телевизорам или, самое большее, к телевизору и видеомагнитофону VHS. Развитие цифровой технологии привело к резкому увеличению круга устройств, которые могут быть подключены к декодеру, равно как и к увеличению функциональных возможностей самого декодера. Например, кроме аналогового выхода Peritel к телевизору и видеомагнитофону VHS, декодер может также соединяться через цифровую шину, такую как шина IEEE 1394, с другими цифровыми устройствами, такими как устройство записи на DVD, персональный компьютер (ПК) и т.п.

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

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

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

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

Профиль пользователя может быть также дополнительно персонализирован для одного или более операторов. Например, после определения профиля пользователя для Интернет-режима работы терминала, можно определить первого Интернет-оператора, имеющего определенные права, и второго оператора, имеющего другие права.

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

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

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

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

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

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

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

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

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

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

Настоящее изобретение в равной степени распространяется на способ работы терминала.

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

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

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

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

на фиг.2 представлены физические элементы декодера, показанного на фиг.1;

на фиг.3 представлена архитектура программного обеспечения системы обработки данных в декодере;

на фиг.4 представлена структура виртуальной машины, используемой в системе обработки данных, показанной на фиг.3;

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

на фиг.6 представлены элементы данных профилей пользователей, сохраняемые в памяти декодера для каждого из профилей пользователей, показанных на фиг.5; и

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

Схема организации системы цифрового телевидения 1 по настоящему изобретению приведена на фиг.1. Это изобретение включает в себя практически обычную систему цифрового телевидения 2, которая использует известную систему сжатия MPEG-2 для передачи сжатых цифровых сигналов. Более подробно, устройство сжатия 3 MPEG-2 в центре вещания принимает поток цифровых сигналов (обычно поток видеосигналов). Устройство сжатия 3 подключено к мультиплексору и скремблеру 4 с помощью канала связи 5.

Мультиплексор 4 принимает множество дополнительных входных сигналов, компонует транспортный поток и передает сжатые цифровые сигналы в передатчик 6 центра вещания через канал связи 7, тип которого, естественно, может быть различным, включая телекоммуникационные каналы. Передатчик 6 передает электромагнитные сигналы через канал "Земля-спутник" 8 на спутниковый ретранслятор 9, где выполняется их обработка электронными средствами и вещание через виртуальный канал "спутник-Земля" 10 на наземный приемник 12, обычно имеющий форму тарелки, принадлежащий конечному пользователю или арендуемый им. Сигналы, принимаемые приемником 12, передаются в совмещенный приемник/декодер 13, принадлежащий конечному пользователю или арендуемый им, и подключенный к телевизору 14 конечного пользователя. Приемник/декодер 13 декодирует сжатый сигнал MPEG-2 в телевизионный сигнал для телевизора 14.

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

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

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

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

Скремблированные данные и зашифрованное слово управления затем принимаются декодером 13, который имеет доступ к эквиваленту рабочего ключа, хранимому на смарт-карте, установленной в декодер, с целью дешифрирования зашифрованного слова управления и последующего дескремблирования передаваемых данных. Оплативший подписку пользователь будет получать, например, в передаваемых ежемесячно "сообщениях управления правами" (ЕСМ - Entitlement Control Message) рабочий ключ, необходимый для дешифрирования зашифрованного слова управления, что дает возможность просмотра передачи

Интерактивная система 16, также подключенная к мультиплексору 4 и приемнику/декодеру 13 и также располагающаяся частично в центре вещания, а частично в декодере, позволяет конечному пользователю взаимодействовать с различными приложениями через модемный обратный канал 17. Модемный обратный канал может быть также использован для связи, используемой в системе условного доступа 15. Интерактивная система может быть использована, например, чтобы дать зрителю возможность немедленно связаться с передающим центром и запросить санкционирование на просмотр конкретной передачи, загрузку приложения и т.п.

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

Декодер 13 содержит центральный процессор 20, включающий в себя связанные с ним элементы памяти, выполненный с возможностью приема входных данных от последовательного интерфейса 21, параллельного интерфейса 22 и модема 23 (подключенного к модемному обратному каналу 17, показанному на фиг.1).

Декодер выполнен с дополнительной возможностью принимать входные сигналы от инфракрасного пульта дистанционного управления 25 через управляющий блок 26 и от переключающих контактов 24 на передней панели декодера. Декодер также имеет два устройства 27 и 28 считывания смарт-карт, приспособленные для считывания банковских карточек и подписной смарт-карты соответственно. Входные сигналы могут также приниматься от клавиатуры с инфракрасным интерфейсом (не показана). Устройство 28 для считывания подписной смарт-карты взаимодействует с установленной в него подписной картой и с блоком условного доступа 29, чтобы передать необходимое слово управления демультиплексору/дескремблеру 30 и сделать возможным дескремблирование зашифрованного вещательного сигнала. Декодер также включает в себя обычный тюнер 31 и демодулятор 32 для приема и демодуляции передачи со спутника перед тем, как она будет профильтрована и демультиплексирована блоком 30.

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

Архитектура системы декодера

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

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

Уровень 42 промежуточного программного обеспечения написан на таком языке, как ANSI С, и включает в себя виртуальную машину 44 и множество интерфейсов 45, в том числе графический интерфейс 46, интерфейс 47 флэш-памяти и ППЗУ, интерфейс 48 протоколов и интерфейс 49 устройств.

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

Уровень 43 интерфейса приложений (API) включает в себя ряд высокоуровневых модулей 50-55, написанных на объектно-ориентированном интерпретируемом языке, таком как Java. Эти модули обеспечивают интерфейс между приложениями, создаваемыми провайдером услуг (интерактивное руководство по программам (программный гид), дистанционные покупки, Internet-браузер и т.д.), и виртуальной машиной системы. Примеры таких приложений приведены ниже.

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

Уровень интерфейса приложений

На фиг.3 показан уровень 43 интерфейса приложений, упомянутый выше; модули этого уровня написаны на объектно-ориентированном языке, таком как Java. Каждый модуль определяет набор библиотек классов, вызываемых во время работы системы. В данной системе установлены следующие модули.

Модуль 50 Lang/Util (Язык/Утилиты). Этот модуль определяет классы, необходимые для работы виртуальной машины с объектами. Такие библиотеки классов обычно образуют часть стандартной библиотеки, ассоциированной с выбранным объектно-ориентированным языком.

Модуль 51 MHEG-5. Этот модуль определяет классы, связанные с манипулированием графическими объектами на телевизионном экране. Такие объекты отличаются от аудиовизуальных данных и могут образовывать, например, идентификаторы каналов или текст, накладываемый поверх выводимых на экран изображений. Определение классов в этом модуле должно соответствовать требованиям MHEG-5, определяемым стандартами ETS 300777-3 и ISO/ISE 13522-5 (и стандартом ISO/ISE 13522-6 в случае системы, реализованной на языке Java).

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

Модуль 53 устройств. Этот модуль определяет классы, необходимые для управления периферийными устройствами, подключенными к приемнику/декодеру, упомянутыми выше, в том числе модемом, устройствами считывания смарт-карт, тюнером потока MPEG и т.д.

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

Модуль 55 DSMCC-UU. Этот модуль реализует протоколы, необходимые для обмена информацией между клиентом и сервером для поиска файлов данных и их считывания. Реализация этого модуля должна соответствовать требованиям ISO/IEC 13818-6 и директивам, определенным в части 9 DAVIC.

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

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

Модули 43 предоставляют библиотеки классов для объектно-ориентированной среды программирования. Поведение их классов будет зависеть от выбранного языка. В случае Java-приложения, например, будет соблюдаться структура классов с единичным наследованием.

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

Интерфейсный уровень

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

Графический модуль 46, например, обеспечивает создание графических объектов и управление ими. Он запрашивает у низкоуровневой ОС отображение основных графических примитивов, таких как единичные пиксели, линии, прямоугольники и т.д. Реализация этого модуля зависит от графических возможностей низкоуровневой ОС производителя. Являясь в некоторой степени дополнениями к модулю 51 MHEG-5, эти функции могут более эффективно выполняться на этом уровне кода по сравнению с высокоуровневым кодом, выбранным для уровня интерфейса приложений над ним.

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

Модуль 48 управления протоколами определяет библиотеку протоколов обмена данными, которая может вызываться при обмене информацией через, например, TCP/IP-уровень декодера.

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

Описание виртуальной машины

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

Виртуальная машина состоит из ряда элементов, которые взаимодействуют, в целом, как показано на фиг.4.

Планировщик 60, состоящий из сервиса 61 менеджера потоков и сервиса 62 менеджера монитора, является центральным компонентом многопоточной машины. Планировщик 60 задает порядок выполнения потоков, создаваемых приложениями вне виртуальной машины и создаваемых самой виртуальной машиной (например, потока "сборщика мусора", упомянутого ниже).

Менеджер 63 событий ведет таблицу маршрутизации событий и списки событий, получаемых потоками, и централизует диспетчеризацию обработки событий.

Менеджер 64 памяти обрабатывает выделение и освобождение областей памяти в памяти системы, а также выполняет удаление из памяти объектов, на которые нет ссылок ("сборку мусора" -утилизация памяти, освобождаемой в процессе работы программы или системы).

Менеджер 65 классов загружает классы кода приложения, загружаемого из вещательного сигнала, взаимодействуя с менеджером 66 безопасности для проверки целостности загружаемого кода, и с менеджером 68 файлов, который формирует приложения.

Менеджер 68 файлов поддерживает реализацию файлов системы и управляет механизмом загрузки интерактивных приложений и данных.

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

Интерпретатор 67, включающий в себя сервис 69 интерпретации байт-кода и сервис 70 интерпретации "m-кода", выполняет интерпретацию приложений, написанных в одном из этих двух кодов, причем байт-код соответствует приложениям Java, а m-код - это название, данное собственному коду, разработанному заявителем.

Профили пользователей

Возрастание вычислительной мощности аппаратных средств декодера привело к увеличению роли декодеров в маршрутизации данных между множеством потенциальных пользователей системы. Например, один IRD (Integrated Receiver/Decoder - совмещенный приемник/декодер) может служить точкой входа для передаваемого путем вещания MPEG-потока, который обрабатывается и направляется к одному или нескольким подключенным телевизорам, аналоговому видеомагнитофону VHS, подключенному через канал связи Peritel, персональному компьютеру (ПК) или устройству записи на DVD, подключенному через шину IEEE 1394, и т.п.

Центральной идеей рассматриваемой реализации является определение множества "пользователей" декодера, причем каждому пользователю ставится в соответствие некоторый специфический профиль пользователя. Например, высокоуровневое приложение может определить множество профилей пользователей, для зрителя телепередач, для лица, записывающего передачи на видеомагнитофон VHS, лица, непосредственно использующего декодер для доступа к Интернет, лица, использующего декодер для направления данных в ПК, и т.д. На фиг.5 представлен пример набора типичных профилей пользователей. Этот список может быть расширен, чтобы включить, например, устройство DVD, подсоединенное к декодеру, и т.п.

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

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

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

Например, менеджер пользователей может предоставить пользователю "ВИДЕОМАГНИТОФОН" такой приоритет, что запрос этого пользователя на использование некоторого ресурса будет иметь приоритет перед запросом пользователя "ЗРИТЕЛЬ" на использование того же ресурса. В частности, пользователь "ВИДЕОМАГНИТОФОН" может иметь преимущество перед пользователем "ЗРИТЕЛЬ", когда речь идет о выборе канала демультиплексора. Таким образом приложение не допускает, чтобы сигнал переключения канала, принятый от зрителя, имел более высокий приоритет, чем выбор канала лицом, желающим записать программу, передаваемую в это же время.

В этом примере, когда каждому пользователю присваивается одно значение приоритета, пользователь "ВИДЕОМАГНИТОФОН" будет всегда иметь приоритет перед пользователем "ЗРИТЕЛЬ" при доступе к любому ресурсу. В альтернативном варианте могут присваиваться несколько значений приоритетов, так что в отношении одних определенных ресурсов будет иметь приоритет "ЗРИТЕЛЬ", в отношении других ресурсов - "ВИДЕОМАГНИТОФОН", и т.д.

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

Каждый профиль пользователя включает в себя, в дополнение к значению идентификатора пользователя, набор настроек, сохраняемых в кэш-памяти декодера, например во флэш-памяти декодера. Эти настройки будут вызываться приложением при каждой загрузке декодера. Как показано на фиг.6, данные 80 профилей пользователей включают в себя данные 81 о ресурсах, данные 82 об атрибутах и данные 83 о действиях.

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

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

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

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

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

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

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

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

На фиг.7 показан класс 90 UserCacheManager, который используется для того, чтобы предоставить приложениям возможность доступа к данным профилей пользователей, хранимым в кэш-памяти системы, и работы с ними. Этот класс является статическим классом. Как и в обычных архитектурах программного обеспечения, основанных на принципах объектно-ориентированного проектирования, библиотека классов включает в себя набор методов или команд, таких как метод initialise() для инициализации кэш-памяти, метод getMaxUserProfiles(), позволяющий узнать максимальное количество пользователей, которое может поддерживать система, метод getActiveUserID(), позволяющий узнать количество пользователей, активных на данный момент времени, и т.д. Этот класс может также быть ассоциирован с набором событий, сообщающих приложению о происшедшем событии, например о создании или удалении профиля пользователя.

В число этих классов входит также класс 91 UserProfile. Этот класс является родовым классом, позволяющим создавать, множество профилей пользователей. Этот класс включает в себя набор методов, таких как методы getUserID(), позволяющий получить идентификатор пользователя, getPriorityLevel(), позволяющий выяснить приоритет по доступу к ресурсам, setGeneralAttribute(), позволяющий установить значения какого-либо общего параметра, и т.д. Этот класс также ассоциирован с набором событий, сообщающих, например, о запросе от пользователя на переключение канала и т.п.

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

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

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

В частности, классы 92 ViewerProfile, 93 RecorderProfile, 94 InternetProfile, 95 DataBridgeProfile определяют методы, специфические для определения профилей пользователей ЗРИТЕЛЬ, ВИДЕОМАГНИТОФОН, ИНТЕРНЕТ, ШЛЮЗ_ДЛЯ_ДАННЫХ и т.д. Классы 92-95 могут иметь методы, унаследованные от родового класса 91 UserProfile. Например, используя команду setGeneralAttribute (Attribute, Value of Attribute), можно определить предпочтительное значение атрибута, ассоциированного с тем или иным профилем пользователя.

В случае профиля пользователя для зрителя, в котором должен быть установлен уровень программ, которые может смотреть этот зритель, с точки зрения морали и нравственности, в контексте программирования профилей для пользователя ЗРИТЕЛЬ команда

setGeneralAttribute(Morality-Level, 18)

установит возрастной лимит санкционирования для этого пользователя. Это значение будет устанавливаться и вызываться высокоуровневым приложением; оно может быть использовано для того, чтобы сделать невозможным доступ пользователя ЗРИТЕЛЬ к определенным каналам демультиплексора до тех пор, пока этот оператор не сообщит свой возраст. Для каждого лица, имеющего доступ к декодеру в режиме ЗРИТЕЛЬ, может быть определен набор настроек в экземплярах класса ЗРИТЕЛЬ.

Понятно, что определение в API набора классов для создания идентифицированного "пользователя" дает системе возможность легко задавать множество профилей пользователей для каждого из этих пользователей. Введение класса UserCacheManager позволяет оперировать находящимися в кэш-памяти данными профилей, относящимися к пользователю, а родовые классы UserProfile и подклассы ViewerProfile, RecorderProfile и т.д. предоставляют инструментарий, необходимый для определения отдельных профилей пользователей.

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