Защищенный медиа тракт и блок разрешения отклика на отказ

Изобретение относится к архитектуре и способу для установления защищенного медиа тракта для доставки контента доверяемым способом от множества разнообразных источников к любому из множества разнообразных приемников посредством общей базы. Изобретение позволяет доставлять контент по защищенному медиа тракту от любой из множества систем управления правами, каждая из которых не обязательно совместима с каждой другой системой управления правами. В защищенном медиа тракте для доставки контента от источника к приемнику блок доверенной инстанции источника (SOTA) в интересах источника принимает решение в отношении политики, соответствующей контенту, что конкретный тип действий с контентом не должен выполняться, и предоставляет конкретный блок разрешения в приложение. Предоставленный блок разрешения включает в себя информацию и методы, необходимые приложению для получения данных, необходимых для ответа на отказ. Приложение принимает блок разрешения через его интерфейс, и интерфейс применяет общую процедуру взаимодействия для выполнения блока разрешения для получения данных, необходимых для ответа на отказ. 2 н. и 14 з.п. ф-лы, 6 ил.

 

Настоящая заявка на патент претендует на приоритет по заявке на патент США № 10/820,673, поданной 8 апреля 2004 года, которая претендует на приоритет по заявке на патент США № 60/513,831, поданной 23 октября 2003 года, содержание которых включено в настоящее описание во всей своей полноте в качестве ссылки.

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

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

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

На Фиг.1 показано, что, как известно, в связи с цифровым контентом (12), таким как цифровая аудиоинформация, цифровая видеоинформация, цифровая текстовая информация, цифровые данные, цифровое медиа и т.д., в случае, где такой цифровой контент (12) подлежит распространению среди пользователей, весьма желательна система управления правами (УП, RM) и обеспечения их соблюдения. При получении этого контента пользователем такой пользователь воспроизводит или “проигрывает” цифровой контент при помощи соответствующего устройства воспроизведения, такого как мультимедийный проигрыватель на персональном компьютере (14), переносное устройство воспроизведения или подобные им устройства.

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

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

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

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

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

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

Правила могут быть определены в соответствии с любым подходящим для этого языком или синтаксисом. Например, язык может просто определять атрибуты и значения, которые должны быть соблюдены (например, ДАТА должна быть более поздней, чем Х), или могут требовать выполнения функций в соответствии с указанным сценарием (например, ЕСЛИ ДАТА больше, чем Х, ТО СДЕЛАТЬ ….).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Осуществление изобретения

КОМПЬЮТЕРНАЯ СРЕДА

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

Как показано на Фиг.2, иллюстративная вычислительная система общего назначения включает в себя традиционный персональный компьютер (120) или подобный ему, включающие в себя процессор (121), системную память (122) и системную шину (123), которая соединяет различные компоненты системы, включая системную память, с процессором (121). Системная шина (123) может относиться к любому из нескольких типов структур шины, включая шину памяти или контроллер памяти, периферийную шину и локальную шину, использующие любую из множества архитектур шины. Системная память включает в себя постоянное запоминающее устройство (ПЗУ, ROM) (124) и оперативное запоминающее устройство (ОЗУ, RAM) (125). Базовая система (126) ввода/вывода (BIOS), содержащая базовые процедуры, способствующие передаче информации между элементами внутри персонального компьютера (120), например, при запуске, хранится в ПЗУ (124).

Персональный компьютер (120) может, кроме того, включать в себя накопитель (127) на жестких магнитных дисках для считывания с жесткого магнитного диска (на чертеже не показан) и записи на него, дисковод (128) для магнитного диска, предназначенный для считывания со съемного магнитного диска (129) или записи на него, и дисковод (130) для оптического диска, предназначенный для считывания со съемного оптического диска (131), такого как ПЗУ на компакт-диске (CD-ROM) или другие оптические носители информации, или записи на него. Накопитель (127) на жестких магнитных дисках, дисковод (128) для магнитного диска и дисковод (130) для оптического диска подсоединены к системной шине (123) посредством интерфейса (132) накопителя на жестких магнитных дисках, интерфейса (133) дисковода для магнитного диска и интерфейса (134) дисковода для оптического диска, соответственно. Дисководы и соответствующие им машиночитаемые носители информации обеспечивают энергонезависимое хранение машиночитаемых команд, структур данных, программных модулей и других данных для персонального компьютера (20).

Хотя иллюстративная среда, описанная в данном документе, использует жесткий магнитный диск, съемный магнитный диск (129), и съемный оптический диск (131), следует иметь в виду, что в иллюстративной операционной среде могут также быть использованы и другие типы машиночитаемых носителей информации, которые могут хранить данные, доступ к которым может осуществлять компьютер. Такие другие типы носителей информации включают в себя магнитную кассету, карточку флэш-памяти, цифровой видеодиск, картридж Бернулли, оперативное запоминающее устройство (ОЗУ), постоянное запоминающее устройство (ПЗУ) и тому подобное.

На жестком магнитном диске, магнитном диске (129), оптическом диске (131), в ПЗУ (124) или ОЗУ (125) может храниться ряд программных модулей, включая операционную систему (135), одну или более прикладных программ (136), другие программные модули (137) и данные (138) программ. Пользователь может осуществлять ввод команд и информации в персональный компьютер (120) посредством устройств ввода, таких как клавиатура (140) и указательное устройство (142). Другие устройства ввода (не показанные на чертеже) могут включать в себя микрофон, джойстик, игровую панель, параболическую спутниковую антенну, сканер или подобные им устройства. Часто эти и другие устройства ввода соединены с процессором (121) посредством интерфейса (146) последовательного порта, подсоединенного к системной шине, но могут быть соединены и посредством других интерфейсов, таких как параллельный порт, игровой порт или универсальная последовательная шина (USB). Монитор (147) или другой тип устройства отображения также подсоединен к системной шине (123) через интерфейс, такой как видеоадаптер (148). В дополнение к монитору (147), персональный компьютер обычно включает в себя другие периферийные устройства вывода (не показанные на чертеже), такие как громкоговорители и принтеры. Иллюстративная система, показанная на Фиг.2, также включает в себя хост-адаптер (155), шину (156) Интерфейса малых компьютерных систем (SCSI) и внешнее запоминающее устройство (162), соединенное с шиной SCSI (156).

Персональный компьютер (120) может функционировать в сетевой среде, используя логические соединения с одним или более удаленными компьютерами, такими как удаленный компьютер (149). Удаленный компьютер (149) может быть другим персональным компьютером, сервером, маршрутизатором, сетевым персональным компьютером (ПК, РС), одноранговым устройством или другим узлом общей сети, и обычно включает в себя многие или все элементы, описанные выше в отношении персонального компьютера (120), хотя на Фиг.2 показана только память (150). Логические соединения, изображенные на Фиг.2, включают в себя локальную сеть (LAN) (151) и глобальную сеть (WAN) (152). Такие сетевые среды часто используются в офисах, сетях масштаба предприятия, интрасетях и в сети Интернет.

При использовании в сетевой среде LAN персональный компьютер (120) соединен с LAN (151) посредством сетевого интерфейса или адаптера (153). При использовании в сетевой среде WAN персональный компьютер (120) обычно включает в себя модем (154) или другие средства для установления связи через глобальную сеть (152), такую как сеть Интернет. Модем (154), который может быть внутренним или внешним, подсоединен к системной шине (123) через интерфейс (146) последовательного порта. В сетевой среде программные модули, изображенные в отношении персонального компьютера (120), или их части могут храниться в удаленном запоминающем устройстве. Следует иметь в виду, что показанные сетевые соединения являются иллюстративными и могут быть использованы и другие средства установления линии связи между компьютерами.

ЗАЩИЩЕННЫЙ МЕДИА ТРАКТ

“Защита контента” обозначает спектр способов и технологий, предназначенных для такой защиты цифрового контента (12), при которой такой контент (12) не может быть использован в манере, противоречащей пожеланиям владельца контента и/или его поставщика. Способы включают в себя, среди прочего, защиту от копирования (ЗК, СР), защиту линии связи (ЗЛС, LP), условный доступ (УД, CD), управление правами (УП, RM) и управление цифровыми правами (УЦП, DRM). Базой любой системы защиты контента является то, что только доверенное приложение, обеспечивающее надлежащее следование подразумеваемым и/или явно выраженным правилам использования защищенного контента (12), может осуществлять доступ к этому контенту в его незащищенной форме. Обычно контент (12) защищен тем, что зашифрован некоторым способом, при том, что дешифровать этот контент могут только доверенные стороны.

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

Управление цифровыми правами представляет собой расширяемую архитектуру, в которой правила, касающиеся санкционированного использования конкретного фрагмента контента (12), явно выражены и привязаны к самому контенту (12) или связаны с ним. Механизмы управления цифровыми правами могут поддерживать более богатые по содержанию и более выразительные правила, чем другие способы, предоставляя при этом более высокую степень контроля и гибкости на уровне индивидуальных фрагментов контента или даже подкомпонентов этого контента. Пример системы управления цифровыми правами приводится в заявке на патент США № 09/290,363, поданной 12 апреля 1999 года, и предварительной заявки на патент США № 60/126,614, поданной 27 марта 1999 года, включенных в настоящее описание во всей своей полноте в качестве ссылки.

Управление правами представляет собой форму управления цифровыми правами, организационно основанную на том, что контент (12) может быть защищен таким образом, чтобы быть доступным только в пределах организации или ее подразделения. Пример системы управления правами приводится в заявках на патент США, № 10/185,527 и №10/185,278, поданных 28 июня 2002 года и включенных в настоящее описание во всей своей полноте в качестве ссылки.

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

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

Аналогичным образом, каждый из одного или более приемников (32) является системой, которая принимает или куда “стекает” контент (12) и может представлять собой любую подходящую систему, и это не выходит за рамки сущности и объема настоящего изобретения, но вновь при том, конечно, условии, что приемник (32) может взаимодействовать с данной архитектурой. Например, приемник (32) может представлять собой аудиосистему для приема аудиоданных, подлежащих доставке громкоговорителю, видеосистему для приема видеоданных, подлежащих доставке устройству отображения, систему управления световым излучением для приема сигналов управления световым излучением, подлежащих доставке контроллеру системы светового излучения, систему управления электродвигателем для приема сигналов управления электродвигателем, подлежащих доставке контроллеру системы электродвигателя и тому подобное. Кроме того, приемник (32) может быть просто интерфейсом, соединяющим с кабелепроводом, таким как сеть или кабель передачи данных. Необходимо отметить, что как и в случае с источником (30) приемник (32) может доставлять реальный контент (12) куда угодно. Например, контент в случае с аудиоданными может быть доставлен удаленному громкоговорителю посредством такого приемника (32), как звуковая карта на вычислительном устройстве (14). Необходимо отметить, что данный приемник (32) связан с ресурсом вывода, а не с системой защиты контента. В любом примере приемника (32) может иметься или может отсутствовать связанная с ним система защиты контента.

Необходимо отметить, что в данной архитектуре (а мы рассматриваем теперь Фиг.3) каждый источник (30) и приемник (32) может быть интегрирован с блоком (34) реализации политики из медиа базы (36) на вычислительном устройстве (14) посредством предоставления соответствующего блока доверенной инстанции источника (ДИИС, SOTA) (38) или блока доверенной инстанции приемника (ДИПР, SITA) (40), соответственно, или осуществления доступа в эти блоки. Таким образом, каждый источник (30) и каждый приемник (32) могут быть локальными или удаленными по отношению к вычислительному устройству (14), но каждый соответствующий блок SOTA (38) или блок SITA (40) локален по отношению к вычислительному устройству (14), в силу чего он действует в, по меньшей мере, некоторых аспектах, в качестве агента или представителя соответствующего источника (30) и приемника (32). Необходимо отметить, что практически любой источник (30) или приемник (32) может быть частью архитектуры медиа базы и защищенного медиа тракта, имея соответствующий ему блок SOTA (38) или блок SITA (40), соответственно.

Каждый блок SOTA (38) представляет в защищенном медиа тракте (39), определенном данной архитектурой, соответствующий источник (30) и функционирует таким образом, что предоставляет функциональные возможности по дешифрованию для дешифрования контента (12) из источника (30) в случае, если это необходимо, а также преобразует политику, связанную с контентом (12), из собственного формата в формат, воспринимаемый блоком реализации политики (34). Как можно понять, политика, по сути своей, представляет собой правила и требования для доступа и воспроизведения контента (12), как, например, те, что могут быть изложены в лицензии (16), показанной на Фиг.1. Необходимо отметить, что блок SOTA (38) может также действовать от имени источника (30), особенно, в отношении вопросов, касающихся доверия, политики и прав.

Аналогичным образом, каждый блок SITA (40) представляет в защищенном медиа тракте (39), определенном данной архитектурой, соответствующий приемник (32) и функционирует таким образом, что предоставляет функциональные возможности по шифрованию для шифрования контента (12), подлежащего доставке в приемник (32), в случае, если это необходимо, а также преобразует политику, связанную с контентом (12), из формата блока (34) реализации политики в формат, воспринимаемый приемником (32). Таким образом, приемник (32) принимает контент (12) и соответствующую политику, дешифрует принятый контент (12) в случае, если это необходимо, и воспроизводит его, основываясь при этом на принятой политике. Необходимо отметить, что блок SOTA (38) может аналогичным образом действовать от имени приемника (32), особенно, в отношении вопросов, касающихся доверия, политики и прав.

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

Блок (34) реализации политики, входящий в состав медиа базы (36), является центральной частью архитектуры защищенного медиа тракта и отвечает за обеспечение соблюдения политики от имени каждого блока SOTA (38). Таким образом и в соответствии с тем, что будет изложено ниже, блок (34) реализации политики проводит согласование политики между каждым применимым источником (30) и каждым применимым приемником (32), включая требуемые системы защиты контента у приемника, направленную вовне политику на системах защиты контента у приемника, и включение и исключение компонентов медиа тракта. Блок (34) реализации политики также предоставляет защищенную среду, внутри которой принятый контент (12) может быть обработан с определенным уровнем уверенности в том, что контент (12) защищен от кражи злонамеренным субъектом.

Медиа база (36), обладающая блоком (34) реализации политики, по сути своей, представляет собой общую совокупность функций, необходимых для обеспечения общей инфраструктуры для осуществления обработки контента (12) из какого-либо конкретного источника (30) и для доставки обработанного контент (12) в какой-либо конкретный приемник (32). Необходимо отметить, что хотя форматы контента (12) и связанной с ним политики могут меняться от источника (30) к источнику (30), медиа база (36) может обрабатывать такой контент (12) и связанную с ним политику по той причине, что каждый источник (30) имеет соответствующий блок SOTA (38), который дешифрует контент (12) в случае, если это необходимо, и преобразует связанную с ним политику из вышеупомянутого собственного формата в вышеупомянутый формат, воспринимаемый блоком реализации политики (34). Аналогичным образом, хотя форматы контента (12) и связанной с ним политики могут меняться от приемника (32) к приемнику (32), медиа база может обрабатывать такой контент (12) и связанную с ним политику по той причине, что каждый приемник (32) имеет соответствующий блок SITA (40), который шифрует контент (12) в случае, если это необходимо, и преобразует связанную с ним политику из вышеупомянутого формата, воспринимаемого блоком (34) реализации политики, в вышеупомянутый формат, воспринимаемый приемником (32).

Более конкретно, медиа база (36) предоставляет общую инфраструктуру, которая обеспечивает прохождение контента (12) в защищенные среды и из них, предоставляя защищенную среду в операционной системе вычислительного устройства (14), общий механизм для преобразования и согласования прав, правил и политики при пересечении границ защищенной среды и общий механизм для шифрования/дешифрования мультимедийных данных, передаваемых с высокой скоростью передачи битов, при безопасной передаче этих данных между защищенной средой на вычислительном устройстве (14) и другими защищенными средами. Таким образом, медиа база (36) допускает прохождение защищенного контента (12) в защищенном режиме по направлению из вычислительного устройства (14), в него и через него и предусматривает осуществление произвольной обработки защищенного контента (12). В результате любая заинтересованная сторона может добавлять в операционную систему на вычислительном устройстве (14) средства обеспечения защиты произвольного контента, распространяя соответствующие блоки SOTA (38) и/или блоки SITA (40), в зависимости от того, что требуют обстоятельства.

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

В дополнение к функциональным возможностям, предоставляемым ключевыми компонентами (42) медиа базы (36), и в случае, если это необходимо, любая заинтересованная сторона может добавлять в операционную систему на вычислительном устройстве (14) средства обеспечения для дополнительных произвольных защищенных функциональных возможностей, распространяя соответствующие дополнительные компоненты или “плагины” (44), которые предназначены для работы в сопряжении с медиа базой (36) с тем, чтобы предоставлять такие дополнительные функциональные возможности. Как можно понять, каждый плагин (44) может представлять собой любой подходящий плагин, и это не выходит за рамки сущности и объема настоящего изобретения. Использование таких плагинов (44) является широко известным или должно быть очевидным для специалистов в данной области техники, и потому не нуждается здесь в сколь бы то ни было подробном изложении.

В одном варианте осуществления настоящего изобретения медиа база (36) активируется для создания защищенного медиа тракта (39) между каждым из одного или более выбранных источников (30) и каждым из одного или более выбранных приемников (32), причем, выбранных мультимедийным приложением (46) на вычислительном устройстве (14). Предполагается, что мультимедийное приложение (46) находится под контролем пользователя или другого приложения на вычислительном устройстве (14) или где-нибудь в другом месте. Так, мультимедийное приложение (46) выбирает контент (12) для воспроизведения и, делая это, выбирает один или более выбранных источников (30), и, если это необходимо, выбирает один или более приемников (32). После этого мультимедийное приложение (46) не участвует в воспроизведении защищенного контента (12) через созданный защищенный медиа тракт (39), за исключением, возможно, случая, когда оно отдает команды управления воспроизведением, такие как пуск, останов, повтор, перемотка в обратном направлении, быстрая перемотка вперед и подобные им команды.

В одном варианте осуществления настоящего изобретения медиа база (36) и созданный ею защищенный медиа тракт (39) одни ответственны за управление контентом (12) в пределах такого созданного защищенного медиа тракта (39) и, соответственно, приложение (46) не имеет контроля над контентом (12) в пределах такого созданного защищенного медиа тракта (39). Таким образом, приложение (46) распоряжается воспроизведением контента (12) посредством медиа базы (36) и созданного ею защищенного медиа тракта (39), но не имеет никакого реального доступа к такому контенту (12) или контроля над ним, особенно, в какой бы то ни было незащищенной форме. В частности, медиа базе (36) и защищенному медиа тракту (39) не может быть отдано приложением (46) или любым другим элементом распоряжение произвести действие в отношении контента (12), противоречащее политике, соответствующей контенту (12). Необходимо отметить, что в результате приложению (46) не нужно каким-либо образом специально устанавливать тот факт, что оно является доверяемым в связи с защищенным медиа трактом (39), показанным на Фиг.3, и фактически приложению (46) не доверено обрабатывать контент (12) каким-либо доверяемым способом. Конечно, такое отсутствие доверия к приложению (46) не имеет никаких нежелательных последствий, принимая во внимание тот факт, что приложение (46) фактически не обрабатывает контент (12) иначе, как отдавая команды управления воспроизведением, такие как те, что приведены выше, в ходе операции, выполняемой медиа базой (36) и созданным ею защищенным трактом (39) медиа.

Подводя итог сказанному, медиа база (36), функционируя под управлением приложения (46), создает защищенный медиа тракт (39), посредством которого контент (12) из одного или нескольких источников (30) подлежит доставке в один или более приемников (32). Предположим, что медиа база (36) производит некоторые операции над контентом (12) при его прохождении по созданному защищенному медиа тракту (39) при том, что такие операции над таким контентом (12), производимые такой медиа базой (36), могут быть настолько минимальны или настолько максимальны, насколько это необходимо. Необходимо отметить, что, прежде чем каждый источник (30) позволит своему контенту (12) пройти по созданному защищенному медиа тракту (39) и согласно одному из вариантов осуществления настоящего изобретения, источник (30) убеждается в том, что медиа база (36), ее блок (34) реализации политики, каждый ее используемый компонент (42), каждый ее используемый плагин (44), каждый принимающий приемник (32) и любой другой элемент, который касается или “затрагивает” контент (12), является (а) доверяемым и (b) имеет права затрагивать контент (12), основанные на политике, связанной с контентом (12).

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

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

Как показано на Фиг.4, в одном варианте осуществления изобретения, архитектура защищенного медиа тракта, приведенного на Фиг.3, используется для доставки контента (12) из одного или более источников (30) в один или более приемников (32), осуществляемой следующим образом. Предварительно, приложение (46) по распоряжению пользователя или другого элемента изъявляет желание передать контент (12) из одного или более источников (30) в один или более приемников (32), и, следовательно, обращается к медиа базе (36) с определением контента (12), каждого такого источника (30), из которого контент (12) должен быть получен, и каждого такого приемника (32), в который контент (12) должен быть доставлен (этап 401).

В ответ на это медиа база (36), основываясь на этих определенных в контенте (12) источнике (30) и приемнике (32) устанавливает защищенный медиа тракт (39) для осуществления такой доставки (этап 403). Необходимо отметить, что делая это, медиа база (36) может выбрать один или более своих компонентов (42), которые должны обрабатывать контент (12) и оперировать им, при его доставке по защищенному медиа тракту (39), и может выбрать один или более своих плагинов (44), которые также должны обрабатывать контент (12) и оперировать им, при его доставке по защищенному медиа тракту (39). Медиа база (36) может использовать для установления защищенного медиа тракта (39) и выбора компонентов (42) и плагинов (44) любую подходящую методологию, и это не выходит за рамки сущности и объема настоящего изобретения. Такое установление защищенного медиа тракта (39) и выбор компонентов (42) и плагинов (44) медиа базой (36) известны или должны быть очевидны для специалистов в данной области техники, и потому не нуждается здесь в сколь бы то ни было подробном изложении. Например, действия, производимые медиа базой (36) и в связи с ней согласно настоящему изобретению, могут включать в себя те действия, которые приведены в Приложении.

Необходимо отметить, что после того, как медиа база (36) установит защищенный медиа тракт (39), создается блок SOTA (38), соответствующий каждому источнику (30) этого определенного тракта (39), и он создается в качестве защищенного контейнера, соединяющего источник (30) с медиа базой (36), как это видно на Фиг.3 (этап 405 на Фиг.4). Такое создание может быть произведено источником (30), медиа базой (36) или ими совместно, и это не выходит за рамки сущности и объема настоящего изобретения. Как указывалось выше, каждый блок SOTA (38) является доверенной инстанцией и представляет соответствующий источник (30) в защищенном медиа тракте (39), и функционирует таким образом, что предоставляет функциональные возможности по дешифрованию для контента (12) из источника (30) в случае, если это необходимо, а также преобразует политику, связанную с контентом (12), из собственного формата в формат, воспринимаемый блоком (34) реализации политики, входящим в медиа базу (36). Необходимо отметить также, что блок SOTA (38) может также действовать от имени источника (30), особенно, в отношении вопросов, касающихся доверия, политики и прав.

Также необходимо отметить, что после того, как медиа база (36) установит защищенный медиа тракт (39), создается блок SITA (40), соответствующий каждому приемнику (32) этого определенного тракта (39), и он создается в качестве защищенного контейнера, соединяющего приемник (32) с медиа базой (36), как это видно на Фиг.3 (этап 407 на Фиг.4). Такое создание может также быть произведено приемником (32), медиа базой (36) или ими совместно, и это не выходит за рамки сущности и объема настоящего изобретения. Как также было указано выше, каждый блок SITA (40) является доверенной инстанцией и представляет соответствующий приемник (32) в защищенном медиа тракте (39) и функционирует таким образом, что предоставляет функциональные возможности по шифрованию для контента (12), подлежащего доставке в приемник (32), в случае, если это необходимо, а также преобразует политику, связанную с контентом (12), из формата блока (34) реализации политики в формат, воспринимаемый приемником (32). Также необходимо отметить, что блок SITA (40) может также действовать от имени приемника, особенно, в отношении вопросов, касающихся доверия, политики и прав.

В одном варианте осуществления настоящего изобретения блок SOTA (38), действуя от имени источника (30), устанавливает доверие в отношении защищенного медиа тракта (39). После этого, и как только доверие установлено, блок SOTA (38) распространяет политику, соответствующую контенту (12), подлежащему воспроизведению, который был определен приложением (46) на этапе 401. В частности, блок SOTA (38) устанавливает доверие, в первую очередь устанавливая доверие в отношении блока (34) реализации политики, входящего в медиа базу (36) (этап 409). После этого доверенный блок (34) реализации политики устанавливает доверие в отношении остальных составляющих защищенного медиа тракта (39), включая каждый компонент (42), каждый плагин (44) и каждый приемник (32), представленный своим блоком SITA (40) (этап 411).

При установлении доверия, согласно сказанному выше, элемент может быть признан доверяемым на основе предъявления маркера, такого как цифровой сертификат от подтверждающей инстанции, который подтверждает этот элемент. Такой маркер/сертификат мог бы включать в себя хэш-функцию облекаемого доверием элемента, проверяемую на основе ключа в сертификате, благодаря чему установление доверия к элементу может включать в себя проверку хэш-функции. Необходимо отметить, что если на какой-либо стадии доверие к элементу не установлено, такому элементу отказывают в доступе к контенту (12). А следовательно, элемент должен быть удален из защищенного медиа тракта (39), если это возможно. Если же это невозможно, то блок SOTA (38) не выпускает контент (12) в защищенный медиа тракт (39).

Предположим, что доверенный блок (34) реализации политики действительно установит доверие с каждым элементом защищенного медиа тракта (39), включая каждый компонент (42), каждый плагин (44) и каждый приемник (32), представленный своим блоком SITA (40), тогда блок SOTA (38) осуществляет распространение политики, соответствующей контенту (12), подлежащему воспроизведению. В частности, блок SOTA (38) осуществляет распространение такой политики в блок (34) реализации политики (этап 413). Делая это, блок SOTA (38) использует, при необходимости, имеющиеся у него функциональные возможности для преобразования политики из собственного формата в формат, воспринимаемый блоком (34) реализации политики, входящим в медиа базу (36), и затем передает преобразованную политику в блок (34) реализации политики.

После этого блок (34) реализации политики, имеющий преобразованную политику, устанавливает тот факт, что каждый компонент (42) и каждый плагин (44) медиа базы (36) имеют право затрагивать контент (12) или осуществлять к нему доступ в соответствии с преобразованной политикой. В частности, на основе преобразованной политики блок (34) реализации политики при необходимости определяет, что каждый такой компонент (42) и каждый плагин (44) медиа базы (36) удовлетворяет условиям преобразованной политики (этап 415). Необходимо отметить, что элемент, который облечен доверием, может, тем не менее, исходя из политики, все-таки не иметь права затрагивать контент (12) или осуществлять к нему доступ. Например, согласно тому, что было сказано выше, если политика указывает, что элемент должен иметь, по меньшей мере, определенный номер версии, а элемент имеет более ранний номер версии, то элемент, хотя и облечен доверием, все-таки не имеет права затрагивать контент (12) или осуществлять к нему доступ. Необходимо отметить, что если на какой-либо стадии доверенный элемент не имеет права осуществлять доступ к контенту (12) или затрагивать его, согласно тому, что определено блоком (34) реализации политики, то такому элементу отказывают в доступе к контенту (12). А следовательно, элемент должен быть удален из защищенного медиа тракта (39), если это возможно. Если же это невозможно, то блок SOTA (38) не выпускает контент (12) в защищенный медиа тракт (39).

Помимо этого, блок (34) реализации политики, имеющий преобразованную политику, устанавливает тот факт, что каждый приемник (32) в защищенном медиа тракте (39) имеет право затрагивать контент (12) или осуществлять к нему доступ в соответствии с преобразованной политикой. В частности, блок (34) реализации политики осуществляет распространение такой преобразованной политики в блок SITA (40) приемника (32). При этом блок SITA (40) аналогичным образом использует, при необходимости, имеющиеся у него функциональные возможности для повторного преобразования преобразованной политики в формат, воспринимаемый приемником (32), и затем передает повторно преобразованную политику в блок SITA (40). После этого доверительно полагается, что приемник (32) и его блок SITA (40) в качестве облеченных доверием элементов защищенного медиа тракта (39) следуют такой повторно преобразованной политике.

В одном варианте осуществления настоящего изобретения блок (34) реализации политики, в качестве дополнения или альтернативы сказанному, запрашивает приемник (32) посредством его блока SITA (40) о действии, которое приемник (32) намеревается произвести в отношении контента (12), соответствующего политике (этап 419). Такое действие может, например, содержать воспроизведение контента (12), копирование контента (12), экспортирование контента (12) в незащищенный формат и тому подобное. Необходимо отметить, что, поскольку защищенный медиа тракт (39), включающий в себя блок SITA (40) и относящийся к нему приемник (32), был установлен по распоряжению приложения (46), такой блок SITA (40)/приемник (32) должен иметь явно или косвенно выраженное знание того, какое действие предполагается произвести в отношении контента (12). Также необходимо отметить, что хотя блок (34) реализации политики мог бы о таком действии спросить приложение (46), приложению (46) не доверяют в том, что оно отвечает правдиво, в то время как приемник (32)/блок SITA (40) фактически таким доверием пользуется.

Во всяком случае, доверенный приемник (32)/блок SITA (40) дает ответ, касающийся такого действия, и блок (34) реализации политики передает этот ответ дальше в блок SOTA (38) (этап 421). После этого, блок SOTA (38) принимает решение о том, может ли блок SITA (40)/приемник (32) производить это действие, предположительно со ссылкой на политику, соответствующую контенту (12), и информирует об этом блок (34) реализации политики (этап 423). Как должно быть ясно, если действие не может быть произведено, то блок SOTA (38) не позволит выпустить контент (12) в защищенный медиа тракт (39).

Предположим, что действие может быть произведено, тогда блок (34) реализации политики информирует об этом приложение (46) (этап 425), и приложение (46) может после этого приступать к нему, отдав команды медиа базе (36) на выполнение такого действия и связанных с ним действий (этап 427). Например, приложение может отдать команду медиа базе (36) на воспроизведение контента (12) и также может позже отдать команду медиа базе (36) на остановку, обратную перемотку, быструю перемотку вперед, проскок вперед, проскок назад и тому подобное.

Необходимо отметить, что в ходе осуществления действия, контент (12) проходит по защищенному медиа тракту (39), созданному медиа базой (36). В частности, медиа база (36) получает контент (12) из источника (30), использует функциональные возможности блока SOTA (38) по дешифрованию для дешифрования контента (12) в случае, если это необходимо, и затем отправляет контент (12) далее. Таким образом, медиа база (36) и ее компоненты (42) и плагины (44) выполняют над контентом (12) любые необходимые процессы, и затем медиа база (36) использует функциональные возможности блока SITA (40) по шифрованию для шифрования контента (12) в случае, если это необходимо, и доставляет контент (12) в приемник (32). Конечно, приемник (32) затем направляет контент (12) по месту его конечного назначения.

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

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

Также должно быть ясно, что согласно настоящему изобретению медиа база (36) может получить указание установить защищенный медиа тракт (39), основанный на некоторой произвольной или почти произвольной комбинации источников (30) и приемников (32). Необходимо отметить, что какой бы тракт (39) не был установлен, архитектура, описанная в настоящем изобретении, позволяет такому тракту (39) быть аттестованным как доверяемому и как удовлетворяющему требованиям политики или прав, соответствующих контенту (12), который должен передаваться по такому тракту. Кроме того, даже хотя тракт (39) устанавливается по распоряжению приложения (46), такое приложение (46) само не должно быть доверяемым, поскольку приложение (46) само никогда не затрагивает или не осуществляет доступ к контенту (12) способом, при котором приложение (46) могло бы быть умышленно или неумышленно использовано для кражи такого контента (12).

БЛОК РАЗРЕШЕНИЯ ОТКЛИКА НА ОТКАЗ И ЕГО ИНТЕРФЕЙС

Как было сказано выше в связи со способом, показанным на Фиг.4, доверенный приемник (32)/блок SITA на этапе 421 в ответ на запрос блока (34) реализации политики сообщают о действии, которое намереваются произвести, а блок SOTA (38) на этапе 423 принимает решение о том, могут ли приемник (32)/блок SITA (40) произвести это действие, и информирует о нем блок (34) реализации политики. Если блок SOTA (38) отказывается разрешить произвести это действие, то блок SOTA (38) не позволяет выпустить контент (12) в защищенный медиа тракт (39).

Такой отказ при обычных обстоятельствах вызвал бы окончание процесса, показанного на Фиг.4, без дальнейших пояснений, что, возможно, произвело бы на пользователя приложения (46) менее чем удовлетворительное впечатление. Однако следует иметь в виду, что основания для, по меньшей мере, некоторых типов отказов можно предвидеть заранее, что, по меньшей мере, некоторые такие основания могут быть обработаны сравнительно просто, и что блок SOTA (38) может, поэтому, быть сконструирован таким образом, чтобы включать в себя или иметь доступ к функциональным возможностям, позволяющим обращаться к основаниям, по меньшей мере, некоторых отказов. Таких отказов много, и они разнообразны и могут включать в себя: отсутствие надлежащей лицензии (16) (см. Фиг.1), отсутствие текущей версии элемента, включение в состав тракта приемника (32), настроенного на выполнение ненадлежащей функции, и тому подобное. В одном варианте осуществления настоящего изобретения на этот случай архитектура защищенного медиа тракта (39) снабжена функциональными возможностями по отклику на отказ, предназначенными для отклика на, по меньшей мере, некоторые отказы.

Необходимо отметить, что такие функциональные возможности по отклику на отказ могли бы быть включены в состав медиа базы (36), и это не выходит за рамки сущности и объема настоящего изобретения. Однако, поскольку такие функциональные возможности по отклику на отказ, вероятно, тесно связаны с конкретным источником (30), более удобно, чтобы такие функциональные возможности были включены в блок SOTA (38), соответствующий такому источнику (30), или были для него доступны.

Необходимо отметить, что выдача отклика на отказ может в некоторых случаях потребовать ввода данных пользователем посредством приложения (46), а в некоторых случаях, наоборот, обойтись без такого ввода данных пользователем в случае, когда блок SOTA (38) выдает отклик без помощи пользователя. Однако согласно требованию добросовестной практики, пользователь приложения всегда должен принимать участие в отклике на отказ, особенно, в случае, когда отклик требует, чтобы некоторый элемент или информация были получены из удаленного источника, такого как сеть. Как показано на Фиг.5, в одном из вариантов осуществления настоящего изобретения в этом случае, каждый блок SOTA (38) предусматривает один или более блоков (48) разрешения ответчика на отказ, каждый для отклика на конкретный отказ, а приложение (46) включает в себя интерфейс (50) ответчика, который может осуществлять интерфейс с каждым блоком (48) разрешения предоставляемых через медиа базу (36).

Таким образом, очевидно, что предоставленный блок (48) разрешения и интерфейс (50) предоставляют абстрактный уровень для реализации подробностей откликов на отказ блока SOTA (38) через приложение (46). В частности, предоставленный блок (48) разрешения из блока SOTA (38) приводит процедуры отклика на конкретный его отказ, включая один или более адресов для получения информации, входные данные, требуемые от пользователя, и тому подобное, а интерфейс (50) определяет последовательную процедуру взаимодействия между приложением (46) и блоком (48) разрешения, предоставленным через медиа базу (36). Необходимо отметить, что хотя предоставленные блоки (48) разрешения изменяются от отказа к отказу и от источника (30) к источнику (30), интерфейс (50) всегда использует одни и те же интерфейсные процедуры независимо от того, с каким источником (30)/блоком SOTA (38) связан блок (48) разрешения. Таким образом, приложение (46) для выполнения отклика на отказ использует любые функции, которые доступны из предоставленного блока (48) разрешения, при этом нет необходимости различать конкретный источник (30), предоставивший такой блок (48) разрешения. Необходимо отметить, что хотя приложение (46) не облечено доверием, любая информация или данные, полученные через блок (48) разрешения, поставляются медиа базе (36) и/или защищенному медиа тракту (39) и могут сами быть вынуждены доказывать то, что они являются доверяемыми в контексте такой медиа базы (36) и/или защищенного медиа тракта (39). Это означает, что мероприятия, которые приложение (46) проводит тогда, когда интерфейс (50) выполняет блок (48) разрешения, доверием, вытекающим из их происхождения, не обладают.

Как показано на Фиг.6, в связи с защищенным медиа трактом (39) доверенный блок SITA (40) на этапе 421 сообщает о действии, которое предполагается произвести, в ответе блоку (34) реализации политики, как это было на этапе 421, а блок SOTA (38) на этот раз отказался позволить блоку SITA (40) произвести это действие по причине какого-то обнаруженного недостатка, как на этапе 423 (этап 601). Однако блок SOTA (38) также распознал, что основание для отказа может быть сообщено посредством применения конкретного блока (48) разрешения, доступного для блока SOTA (38) или включенного в него (этап 603), и блок SOTA (38), таким образом, предоставляет конкретный блок (48) разрешения приложению (46) через медиа базу (36) (этап 605). Необходимо отметить, что медиа база (36) может иметь указатель или другую ссылку на интерфейс (50) и может, таким образом, направить блок разрешения в интерфейс (50) приложения (46) при помощи этого указателя или другой ссылки.

Как должно быть ясно, предоставленный блок (48) разрешения включает в себя всю информацию и способы, необходимые для получения приложением (46) посредством своего интерфейса (50) любой информации или данных, которые необходимы для отклика на отказ, вызвавший необходимость в таком предоставленном блоке (48) разрешения. Таким образом, предоставленный блок (48) разрешения принимается из блока SOTA (38) интерфейсом (50) приложения (46) через медиа базу (36) (этап 607), и интерфейс (50) применяет упомянутую выше последовательную процедуру взаимодействия, чтобы фактически исполнить предоставленный блок (48) разрешения (этап 609). Таким образом, имея предоставленный блок (48) разрешения и введенные данные, получение которых от пользователя необходимо и/или целесообразно, приложение (46) и его интерфейс (50) фактически пытаются получить любые данные или информацию, потребность в которых вызвана отказом, из любого необходимого источника, будь он локальным или удаленным (этап 611). Конечно, уровень взаимодействия с пользователем неизбежно меняется в зависимости от обстоятельств. Например, при некоторых обстоятельствах достаточно получить разрешение пользователя перед загрузкой данных или информации, особенно, если загрузка бесплатна. Однако, если установлена плата, то конечно же необходимо получить разрешение пользователя внести плату, не говоря уже о конкретных указаниях, по поводу того, каким образом эту плату внести.

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

Однако предположим, что причина отказа на самом деле устранима путем получения необходимых данных и информации, тогда приложение (46) направляет такие данные или информацию медиа базе (36) (этап 613), и медиа база (36) соответствующим образом использует такие данные так, как необходимо (этап 615), например, сохранив лицензию в хранилище лицензий, установив текущую версию компонента, скорректировав настройки приемника (32) или другим подобным образом.

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

Во всяком случае, после уведомления блока SOTA (38) о том, что отклик завершен, как на этапе 617, блок SOTA (38) снова принимает решение о том, может ли блок SITA (40)/приемник (32) произвести действие, в котором первоначально им было отказано (этап 619). Если блок SOTA (38) снова отказывается позволить произвести это действие, то блок SOTA (38) снова не позволяет выпустить контент (12) в защищенный медиа тракт (39), но вместо этого снова, как на этапе 603, может распознать, что на основание для отказа может быть дан отклик посредством применения конкретного блока (48) разрешения, доступного такому блоку SOTA (38) или включенного в его состав, и блок SOTA (38), таким образом, снова предоставляет конкретный блок (48) разрешения приложению (46) через медиа базу (36), как и на этапе 605.

Однако предположим, что блок SOTA (38) на самом деле теперь позволяет блоку SITA (40) произвести запрошенное действие, тогда блок SOTA (38) в этом случае позволяет выпустить контент (12) в защищенный медиа тракт (39), и блок (34) реализации политики информирует об этом приложение (46), как на этапе 425, показанном на Фиг.4. Как теперь должно быть ясно, приложение (46) может в таком случае приступить к действию, отдав команду медиа базе (36) выполнить такое действие и связанные с ним действия так, как это было на этапе 427, показанном на Фиг.4.

Как теперь должно быть ясно, блок SOTA (38) использует блок (48) разрешения, который исполняется интерфейсом (50) приложения (46) и позволяет блоку SOTA (38) заставить пользователя и/или приложение (46) осуществить отклик для блока SOTA (38) в случае, когда блок SOTA (38) отказывает в действии, запрошенном блоком SITA (40). Хотя блок SOTA (38), возможно, мог бы осуществить этот отклик сам, однако согласно требованию добросовестной практики, пользователь приложения всегда должен принимать участие в отклике на отказ, особенно, в случае, когда отклик требует, чтобы данные или информация были получены из удаленного источника, такого как сеть. Кроме того, в любом случае бывают ситуации, когда такое участие пользователя приложения (46) является необходимым.

Заключение

Настоящее изобретение может быть осуществлено в отношении любого подходящего источника (30) и приемника (32) при условии, что такие источник (30) и приемник (32) имеют соответствующие блок SOTA (38) и блок SITA (40), соответственно, посредством которых может быть достигнута связь с медиа базой (36). Соответственно, защищенный медиа тракт (39) согласно настоящему изобретению должен толковаться как охватывающий любой блок SOTA (38), медиа базу (36) и блок SITA (40), которые могут устанавливать такой защищенный медиа тракт (39) произвольным образом с тем, чтобы доставлять контент от источника (30) в приемник (32).

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

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

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

Из приведенного выше описания можно понять, что настоящее изобретение содержит новую и полезную архитектуру и способ, которые определяют защищенный медиа тракт (39) для контента (12) из любого из множества источников (30), подлежащего доставке в любой из множества приемников (32). Способ в связи с такой архитектурой определяет то, каким образом этот тракт устанавливается как доверяемый и удовлетворяющий политике, соответствующей контенту (12).

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

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

2. Способ по п.1, содержащий этап, на котором блок SOTA предоставляет приложению конкретный блок разрешения, предоставляя приложению при помощи медиа базы ссылку на конкретный блок разрешения.

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

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

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

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

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

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

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

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

11. Способ по п.10, содержащий этап, на котором блок SOTA предоставляет приложению конкретный блок разрешения, предоставляя приложению при помощи медиа базы ссылку на конкретный блок разрешения.

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

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

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

15. Способ по п.10, содержащий этап, на котором блок SOTA периодически принимает извещение о ходе выполнения от интерфейса приложения.

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