Системы и способы на основе механизма управления цифровыми правами

012918 Эта заявка притязает на приоритет предварительной патентной заявки США 60/728,089, поданной 18 октября 2005 г., предварительной патентной заявки США 60/772,024, поданной 9 февраля 2006 г., предварительной патентной заявки США 60/744,574, поданной 10 апреля 2006 г., предварительной патентной заявки США 60/791,179, поданной 10 апреля 2006 г., предварительной патентной заявки США 60/746,712, поданной 8 мая 2006 г., предварительной патентной заявки США 60/798,925, поданной 8 мая 2006 г., и предварительной патентной заявки США 60/835,061, поданной 1 августа 2006 г. Предварительные патентные заявки США 60/728,089, 60/772,024, 60/744,574, 60/791,179,60/746,712, 60/798,925 и 60/835,061 включены сюда посредством ссылки в полном объеме для любых целей. Определение авторских прав Часть раскрытия этого патентного документа содержит материал, подлежащий защите авторских прав. Владелец авторских прав не возражает против факсимильного воспроизведения кем-либо патентного документа или раскрытия патента, представленного в виде файла или записи в Патентное Ведомство, но в остальном сохраняет за собой все авторские права. Уровень техники В современных вычислительных системах часто бывает желательно ограничивать доступ к ресурсам электронного контента, услуг и/или обработки, и/или разрешать осуществлять определенные действия только определенным сущностям. Для обеспечения такого управления были разработаны или предложены различные методы. Эти методы часто называют методами управления цифровыми правами(DRM), поскольку, в целом, их целью является регулирование прав различных сущностей в отношении цифрового или иного электронного контента, услуг или ресурсов. Проблема, с которой сталкиваются многие методы, отвечающие уровню техники, заключается в том, что они чрезмерно сложны, обременены большим количеством ограничений, сравнительно негибки, неспособны обеспечивать определенные естественные типы соотношений и процессов, и/или неспособны взаимодействовать с другими системами DRM. Здесь описаны системы и способы, относящиеся к усовершенствованным методам DRM, которые можно использовать для решения некоторых или всех этих проблем. Очевидно, что варианты осуществления описанного здесь изобретения можно реализовать по-разному, в том числе посредством процессов,аппаратов, систем, устройства, способов, компьютерно-считываемых носителей и/или их комбинации. Существующие системы для управления доступом к контенту иногда включают в себя компоненты,которые обращаются к лицензии в связи с авторизацией доступа к электронному контенту. Однако такие компоненты обычно осуществляют негибкие вычисления цепей или графов информации управления правами, связей или узлов, связанных с лицензией. Они часто неспособны адаптироваться к различным схемам авторизации и/или работать с определенными системами DRM для авторизации доступа к контенту. Варианты осуществления настоящего изобретения преодолевают такие недостатки за счет сохранения, использования и/или выполнения дополнительных процедур или программ управления в связи с лицензией, что позволяет обеспечивать динамические особенности авторизации, обеспечивать авторизацию распределенных ресурсов и/или другие функции доступа к потоку. Кроме того, многие существующие системы предназначены только для случаев, когда поддерживаются простые данные, связанные с авторизацией/состоянием. Эти системы неспособны разрешать ситуации, когда для авторизации доступа может потребоваться зависимость от множественных уровней данных, например определение условий на основании ранее выведенных данных, связанных с другими узлами. Варианты осуществления настоящего изобретения преодолевают эти недостатки за счет реализации базы данных состояний совместно с программами управления DRM для обеспечения особенностей хранения состояний, которые являются защищенными, обеспечивают устойчивые информационные состояния от вызова к вызову, или иначе обеспечивают функции чтения и записи состояний, что позволяет улучшать выполнение программ управления и/или осуществлять более эффективную авторизацию доступа. Дополнительно, существующие системы могут реализовать лицензии или структуры DRM, включающие в себя компоненты, которые предусматривают использование открытых ключей для защиты компонентов лицензии. Однако недостатки этих систем включают в себя возможность того, что хакеры могут подделать цифровые подписи, необходимые для доступа или реализации лицензии, или иначе воспользоваться соответствующими соотношениями, существующими в структуре лицензии DRM. Один или несколько вариантов осуществления настоящего изобретения преодолевают такие недостатки путем реализации цифровой и/или блокирующей подписи объектов лицензия, включающей в себя использование конкретных защищенных ключей. Преимущества этих вариантов осуществления включают в себя предотвращение неавторизованного доступа посредством открытых ключей, а также соответствующих особенностей, выведенных из соотношений между элементами лицензии. Другие существующие системы могут включать в себя компоненты, которые могут определять близость между первой сущностью и второй сущностью, например, между двумя сущностями управления правами. Такие системы могут применять правила, указывающий, что фрагмент защищенного контента нельзя копировать за пределы определенной среды, например, путем реализации громоздких процедур-1 012918 проверки близости. Однако недостатком этих систем является то, что они не способны также предоставлять защиту защищенному контенту без ненужного принудительного осуществления проверки близости. Варианты осуществления настоящего изобретения преодолевают этот и другие недостатки за счет обеспечения лаконичного протокола обнаружения близости, защищенного особенностями, связанными с передачей случайных чисел и/или секретных порождающих чисел. Соответствующие преимущества одного или нескольких вариантов осуществления включают в себя криптографическую нереализуемость для нарушителя определение правильного ответа, даже в случае перехвата запроса. В итоге, существует необходимость в системах, которые могут адекватно авторизовать доступ к электронному контенту, не прибегая к чрезмерно сложным, обремененным большим количеством ограничений и/или сравнительно негибким методам, в системах, которые способны обеспечивать определенные естественные типы соотношений и процессов, и/или в системах, которые способны взаимодействовать с другими системами DRM. Раскрытие изобретения Системы, способы и изделия производства, отвечающие изобретению, относятся к авторизации доступа к электронному контенту и связанной с этим обработке данных. В одном иллюстративном варианте осуществления, предусмотрен способ авторизации доступа к фрагменту электронного контента, хранящемуся в памяти. Способ, согласно этому иллюстративному варианту осуществления, может включать в себя прием запрос на доступ к электронному контенту, извлечение лицензии, связанной с электронным контентом, и выполнение первой программы управления с использованием механизма управления цифровыми правами для определения, можно ли удовлетворить запрос. Другие иллюстративные варианты осуществления могут включать в себя вычисление одного или нескольких объектов связь, хранящихся в памяти, и выполнение второй программы управления для определения, действительна(ы) ли связь(и) и/или выполняются ли одно или несколько условий. Следует понимать, что вышеизложенное общее описание и нижеследующее подробное описание носят исключительно иллюстративный и пояснительный характер и не призваны ограничивать изобретение. Кроме того, могут быть обеспечены признаки и/или вариации помимо изложенных здесь. Например,настоящее изобретение может относиться к различным комбинациям и подкомбинациям раскрытых признаков и/или комбинациям и подкомбинациям некоторых других признаков, раскрытых ниже в подробном описании. Краткое описание чертежей Изобретение легче понять, обратившись к нижеследующему подробному описанию, приведенному совместно с прилагаемыми чертежами, в которых: фиг. 1 - иллюстративная система управления использованием электронного контента; фиг. 2 - более подробный пример системы, которую можно использовать для практического применения вариантов осуществления изобретения; фиг. 3 - демонстрирует действие иллюстративного механизма управления цифровыми правами(DRM) в сети, которая использует DRM; фиг. 4 - совокупность узлов и связей, используемая для моделирования соотношений в системеDRM; фиг. 5 - логическая блок-схема, демонстрирующая, как вариант осуществления механизма DRM может определять, авторизовано ли запрошенное действие; фиг. 6 - пример лицензии DRM согласно одному варианту осуществления изобретения; фиг. 7 А и 7 В - пример использования агентов в одном варианте осуществления; фиг. 8 - пример лицензии DRM; фиг. 9 - более подробный пример того, как механизм DRM может определять, авторизовано ли запрошенное действие; фиг. 10 - более подробный пример того, как механизм DRM выполняет программу управления в одном варианте осуществления; фиг. 11 - иллюстративный вариант осуществления механизма DRM, выполняющегося на устройстве; фиг. 12 - логическая блок-схема, демонстрирующая этапы, предусмотренные при выполнении программы управления в одном варианте осуществления; фиг. 13 - элементы, составляющие клиентское приложение, потребляющее контент, в одном варианте осуществления; фиг. 14 - элементы, составляющие приложение упаковки контента в одном варианте осуществления; фиг. 15 - механизм вывода ключа согласно одному варианту осуществления; фиг. 16 - пример системы DRM; фиг. 17 - пример системы DRM, которая обеспечивает временный вход; фиг. 18 - высокоуровневая архитектура иллюстративной системы для управления документацией предприятия; фиг. 19 - пример того, как систему, например, показанную на фиг. 18, можно использовать для-2 012918 управления доступом к документу или другим его использованием; фиг. 20 - дополнительный пример того, как систему, например, показанную на фиг. 18, можно использовать для управления доступом к документу или другим его использованием; фиг. 21 - дополнительные особенности примера, показанного на фиг. 20; фиг. 22 - другая иллюстративная система для управления электронным контентом на предприятии; фиг. 23 - применение описанных здесь систем и способов для управления записями системы здравоохранения; фиг. 24 - демонстрирует, как представленные здесь системы и способы можно использовать в контексте службы электронной подписки; фиг. 25 - демонстрирует, как описанные здесь системы и способы можно использовать в контексте домена домашней сети; фиг. 26 - взаимодействия, которые имеют место между приложением хоста и механизмом клиентаDRM в одном иллюстративном варианте осуществления; фиг. 27 - взаимодействия, которые имеют место между приложением хоста и механизмом упаковки в одном иллюстративном варианте осуществления; фиг. 28 А - более подробная иллюстрация лицензии согласно одному варианту осуществления; фиг. 28 В - соотношение между связями и узлами в одном иллюстративном варианте осуществления; фиг. 29 - операционная среда иллюстративной реализации виртуальной машины; фиг. 30 - структура данных расширенного блока состояний согласно одному варианту осуществления; фиг. 31 А - образ памяти для сегмента данных в одном варианте осуществления; фиг. 31 В - пример образа памяти для сегмента кода в одном варианте осуществления; фиг. 31 С - пример образа памяти для элемента экспорта в одном варианте осуществления; фиг. 31D - общий пример элемента таблицы экспорта в одном варианте осуществления; фиг. 31 Е - пример элемента таблицы экспорта для иллюстративной точки входа; фиг. 32 - пример протокола передачи лицензии; фиг. 33 - другой пример протокола передачи лицензии согласно одному варианту осуществления; фиг. 34 - механизм защиты целостности объектов лицензия в одном варианте осуществления; фиг. 35 - механизм защиты целостности объектов лицензия в другом варианте осуществления; фиг. 36 - протокол проверки близости согласно одному варианту осуществления; фиг. 37 - демонстрирует использование протокола проверки близости согласно одному варианту осуществления; фиг. 38 - взаимодействие между клиентом и сервером лицензий в одном варианте осуществления; фиг. 39 - более подробная иллюстрация взаимодействия между клиентом и сервером лицензий в одном варианте осуществления; фиг. 40 - пример сущности с множественными ролями; фиг. 41 - протокол загрузки согласно одному варианту осуществления; фиг. 42 - соотношение между с 14n-ex и иллюстративной XML-каноникализацией в одном варианте осуществления. Осуществление изобретения Ниже представлено подробное описание изобретения. Хотя описано несколько вариантов осуществления, следует понимать, что изобретение не ограничивается каким-либо вариантом осуществления, но,напротив, охватывает многочисленные альтернативы, модификации и эквиваленты. Кроме того, хотя в нижеследующем описании приведены многочисленные конкретные детали для обеспечения исчерпывающего понимания изобретения, некоторые варианты осуществления можно применять на практике без некоторых или всех этих деталей. Кроме того, для ясности, определенные технические сведения, известные в уровне техники, не описаны подробно во избежание ненужного затемнения изобретения. В совместно поданной патентной заявке США 10/863,551,2005/0027871 А 1 (далее - "заявке'551"), которая, таким образом, включена сюда посредством ссылки, описаны варианты осуществления архитектуры управление цифровыми правами (DRM) и нового механизма DRM, которые преодолевают некоторые недостатки, характерные для многих предыдущих реализаций DRM. В данной заявке описаны усовершенствования, расширения и модификации, а также альтернативные варианты осуществления архитектуры и механизма DRM, описанных в заявке '551, а также новые компоненты, архитектуры и варианты осуществления. Таким образом, очевидно, что описанный здесь материал можно использовать в контексте архитектуры и/или механизма DRM, например, описанных в заявке '551, а также в других контекстах. 1. Иллюстративная система DRM. На фиг. 1 показана иллюстративная система 100 для управления электронным контентом. Согласно фиг. 1, сущность 102, обладающая правами на электронный контент 103, упаковывает контент для распространения и потребления конечными пользователями 108 а-е (совместно именуемыми "конечными пользователями 108", где позиция 108 в равной степени относится к конечному пользователю и к вычис-3 012918 лительной системе конечного пользователя, а к чему именно, будет ясно из контекста). Например, сущность 102 может являться владельцем, создателем или поставщиком контента, например, музыкантом,киностудией, издательством, компанией по разработке программного обеспечения, автором, поставщиком услуг мобильной связи, службой загрузки или подписки на контент в интернете, поставщиком кабельного или спутникового телевещания, служащим корпорации и т.п., или сущностью, действующей от его имени, и контент 103 может содержать любой электронный контент, например цифровой видео-, аудио- или текстовый контент, фильм, песню, видеоигру, фрагмент программного обеспечения, сообщение электронной почты, текстовое сообщение, документ текстового редактора, отчет или любой другой развлекательный, деловой или другой контент. В примере, показанном на фиг. 1, сущность 102 использует механизм упаковки 109, связывающий лицензию 106 с упакованным контентом 104. Лицензия 106 основана на политиках 105 или других желаниях сущности 102, и указывает разрешенные и/или запрещенные режимы использования контента и/или одно или несколько условий, которым должны удовлетворять режимы использования контента, или которые должны выполняться как условие или следствие использования. Контент также может быть защищен одним или несколькими криптографическими механизмами, например, методами шифрования или цифровой подписи, для чего доверенный орган 110 можно использовать для получения соответствующих криптографических ключей, сертификатов и/или т.п. Согласно фиг. 1, упакованный контент 104 и лицензии 106 можно предоставлять конечным пользователям 108 любыми пригодными средствами, например, по сети 112 наподобие интернета, локальной сети 103, беспроводной сети, виртуальной частной сети 107, глобальной сети, и/или т.п., посредством кабельной, спутниковой, широковещательной или сотовой связи 114, и/или через записываемые носители 116, например, компакт-диск (CD), цифровой универсальный диск (DVD), карту флэш-памяти (например, карту Security Digital (SD, и/или т.п. Упакованный контент 104 можно доставлять пользователю совместно с лицензией 106 в одном пакете или передаче 113, или в отдельных пакетах или передачах,принимаемых от одного или разных источников. Система конечного пользователя (например, персональный компьютер 108 е, мобильный телефон 108 а, телевизор и/или телевизионная приставка 108 с, портативный аудио- и/или видеопроигрыватель,устройство чтения электронных книг и/или т.п.) содержит прикладное программное обеспечение 116,оборудование и/или специализированное логическое устройство, которое способно извлекать и представлять контент. Система пользователя также включает в себя программное обеспечение и/или оборудование, именуемое здесь механизмом 118 управления цифровыми правами, для оценивания лицензии 106, связанной с упакованным контентом 104, и применения ее условий (и/или разрешения приложению 116 применять эти условия), например, путем избирательного предоставления пользователю доступа к контенту только, если это разрешает лицензия 106. Механизм 118 управления цифровыми правами может быть структурно или функционально объединен с приложением 116 или может содержать отдельный фрагмент программного обеспечения и/или оборудования. Альтернативно или дополнительно, система пользователя, например система 108 с, может осуществлять связь с удаленной системой, например системой 108b, (например, сервером, другим устройством в сети устройств пользователя, например, персональным компьютером или телевизионной приставкой, и/или т.п.), которое использует механизм управления цифровыми правами для определения 120, предоставлять ли пользователю доступ к контенту, ранее полученному или запрошенному пользователем. Механизм управления цифровыми правами, и/или другое программное обеспечение, находящееся в системе пользователя или осуществляющее дистанционную связь с ней, также может записывать информацию, относящуюся к доступу пользователя к защищенному контенту или другому его использованию. В некоторых вариантах осуществления, эта информация, полностью или частично, может передаваться удаленной стороне (например, в расчетный центр 122, создателю, владельцу или поставщику контента 102, менеджеру пользователя, сущности, действующей от его имени, и/или т.п.), например, для использования при начислении выручки (например, гонорара, платы за развлечение и т.д.), определении предпочтений пользователя, применении системных политик (например, мониторинге использования конфиденциальной информации), и/или т.п. Очевидно, что, хотя фиг. 1 показана иллюстративная архитектураDRM и совокупность иллюстративных соотношений, описанные здесь системы и способы можно применять на практике в любом подходящем контексте, и, таким образом, очевидно, что фиг. 1 приведена в целях иллюстрации и объяснения, но не в целях ограничения. На фиг. 2 показан более подробный пример системы 200, которую можно использовать для практического применения вариантов осуществления изобретения. Например, система 200 может содержать вариант осуществления устройства 108 конечного пользователя, устройства 109 поставщика контента и/или т.п. Например, система 200 может содержать вычислительное устройство общего назначения, например, персональный компьютер 108 е или сетевой сервер 105, или специализированное вычислительное устройство, например, сотовый телефон 108 а, карманный персональный компьютер, портативный аудио- или видеопроигрыватель, телевизионную приставку, киоск, игровую систему и т.п. Система 200 обычно включает в себя процессор 202, память 204, пользовательский интерфейс 206, порт 207, куда вставляется сменная память 208, сетевой интерфейс 210 и одну или несколько шин 212 для соединения-4 012918 вышеупомянутых элементов. Работой системы 200 обычно управляет процессор 202, действующий под управлением программ, хранящихся в памяти 204. Память 204 обычно включает в себя высокоскоростную оперативную память (ОЗУ) и энергонезависимую память, например, магнитный диск и/или флэшЭСППЗУ. Некоторые участки памяти 204 могут быть заблокированы, что не позволяет другим компонентам системы 200 производить на них операции чтения и записи. Порт 207 может содержать дисковод или разъем памяти для приема компьютерно-считываемых носителей 208, например, дискет, CD-ROM,DVD, карт памяти, SD-карт, других магнитных или оптических носителей и/или т.п. Сетевой интерфейс 210 обычно способен обеспечивать соединение между системой 200 и другими вычислительными устройствами (и/или сетями вычислительных устройств) через сеть 220, например, интернет или интрасеть(например, LAN, WAN, VPN и т.д.), и может применять одну или несколько технологий связи для физического создания такого соединения (например, беспроводного, Ethernet, и/или т.п.). В некоторых вариантах осуществления, система 200 также может включать в себя блок обработки 203, защищенный от злонамеренного использования пользователем системы 200 или другими сущностями. Такой защищенный блок обработки может способствовать повышению безопасности важных операций, например,управления ключами, проверки подписи, и других аспектов процесса управления цифровыми правами. Согласно фиг. 2, память 204 вычислительного устройства 200 может включать в себя различные программы или модули, управляющие работой вычислительного устройства 200. Например, память 204 обычно включает в себя операционную систему 220 для управления выполнением приложений, работой периферийных устройств, и т.п.; приложение хоста 230 для представления защищенного электронного контента; и механизм DRM 232 для реализации некоторых или всех описанных здесь функций управления правами. Как описано здесь в другом месте, механизм DRM 232 может содержать, взаимодействовать с, и/или управлять различными другими модулями, например, виртуальной машиной 222 для выполнения программ управления и базой данных состояний 224 для хранения информации состояния, используемой виртуальной машиной 222, и/или одним или несколькими криптографическими модулями 226 для осуществления криптографических операций, например, шифрования и/или дешифрования контента, вычисления хэш-функций и кодов аутентификации сообщения, оценивания цифровых подписей и/или т.п. Память 204 также обычно включает в себя защищенный контент 228 и соответствующие лицензии 229, а также криптографические ключи, сертификаты и т.п. (не показаны). Специалисту в данной области техники очевидно, что описанные здесь системы и способы можно применять на практике с использованием вычислительных устройств, аналогичных или идентичных изображенным на фиг. 2, или с использованием практически любого другого подходящего вычислительного устройства, в том числе вычислительного устройства, которое не обрабатывает некоторые из компонентов, показанных на фиг. 2, и/или вычислительного устройства, которое обрабатывает другие компоненты, которые не показаны. Таким образом, очевидно, что фиг. 2 приведена в целях иллюстрации, но не ограничения. Здесь описаны механизм управления цифровыми правами и соответствующие системы и способы,которые можно использовать для обеспечения некоторых или всех функций управления правами в системах, например, показанных на фиг. 1 и 2, или в системах других типов. Кроме того, ниже описаны различные другие системы и способы, которые можно использовать в контексте систем, например, показанных на фиг. 1 и 2, а также в других контекстах, в том числе, контекстах, не связанных с управлением цифровыми правами. 2. Архитектура механизма DRM. В одном варианте осуществления, сравнительно простой, открытый и гибкий механизм управления цифровыми правами (DRM) используется для реализации базовых функций DRM. В предпочтительном варианте осуществления, этот механизм DRM должен сравнительно легко интегрироваться в среду вебуслуг, которая, например, описана в заявке '551, и в практически любую среду хоста или архитектуру программного обеспечения. В предпочтительном варианте осуществления, механизм DRM не зависит от конкретных медиа-форматов и криптографических протоколов, что дает разработчикам свободу выбора стандартных или собственных технологий в соответствии с конкретной ситуацией. Предпочтительные варианты осуществления механизма DRM используют простую модель администрирования, но ее можно использовать для выражения сложных соотношений и бизнес-моделей. Некоторые иллюстративные варианты осуществления механизма DRM, которые описаны ниже, относятся к иллюстративной реализации, именуемой "Octopus"; однако очевидно, что настоящее изобретение не ограничивается конкретными деталями иллюстративного Octopus, которые приведены в целях иллюстрации, но не ограничения. 2.1. Обзор. На фиг. 3 показано, как иллюстративный механизм DRM 303 а может функционировать в системе 302, которая использует DRM. Согласно фиг. 3, в одном варианте осуществления механизм DRM 303 а встроен или интегрирован в приложение хоста 304 а (например, приложение представления контента, например, аудио- и/или видеопроигрывателя, приложение представления текста, например, программу электронной почты, текстовый редактор, программу чтения электронных книг или программу чтения документов и/или т.п.) или осуще-5 012918 ствляет связь с ним. В одном варианте осуществления, механизм DRM 303 а осуществляет функции DRM и опирается на приложение хоста 304 а на предмет таких услуг, как шифрование, дешифрование, управление файлами и/или других функций, которые хост может обеспечивать более эффективно. Например, в предпочтительном варианте осуществления, механизм DRM 303 а способен манипулировать объектамиDRM 305, которые содержат лицензию 306 на защищенный контент 308. В некоторых вариантах осуществления, механизм DRM 303 а также может передавать ключи приложению хоста 304 а. Согласно фиг. 3,механизм DRM 303 а и/или приложение хоста 304 а может использовать веб-услуги 305 а и/или услуги хоста 306 а для обработки и/или информацию, необходимую для решения соответствующих задач. В заявке '551 приведены примеры таких услуг, а также показано, каким образом механизм DRM 303 а и приложение хоста 304 а могут взаимодействовать с ними. В примере, показанном на фиг. 3, механизм DRM 303 а, приложение хоста 304 а, услуги хоста 306 а,и интерфейс веб-услуг 305 а загружаются в устройство 300 а, например персональный компьютер (ПК) конечного пользователя. Устройство 300 а поддерживает связь с сервером 300b, от которого поступают контент 308 и лицензия 306, а также с портативным устройством 300d, на которое устройство 300 а может пересылать контент 308 и/или лицензию 306. Каждое из этих других устройств может включать в себя механизм DRM 303, аналогичный или идентичный механизму DRM 300 а, который может быть интегрирован в конкретное приложение хоста и среду хоста устройства. Например, сервер 300b может включать в себя приложение хоста 304b, которое осуществляет массовую упаковку контента и/или лицензий и использует механизм DRM 300 а для оценивания объектов управления, связанных с упаковываемым контентом, для согласования с любыми ограничениями на повторное распространение. Аналогично, устройство 300 с может включать в себя приложение хоста 304 с, способное представлять и упаковывать контент, тогда как устройство 300 а может включать в себя приложение хоста, способное просто представлять контент. В порядке еще одного примера возможного разнообразия сред хоста, устройство 300d может не включать в себя интерфейс веб-услуг, но, вместо этого, может опираться на связь с устройством 300 а и интерфейс веб-услуг 305 а постольку, поскольку приложение хоста 304d и/или механизмDRM 303d требуют использования каких-либо веб-услуг. На фиг. 3 показан только один пример системы, в которой можно использовать механизм DRM; очевидно, что описанные здесь варианты осуществления механизмов DRM можно реализовать и объединять с приложениями и системами самыми разнообразными способами, не ограничиваясь иллюстративными примерами, показанными на фиг. 3. 2.2. Объекты. В предпочтительных вариантах осуществления, объекты защиты и администрирования контента используются для представления сущностей в системе, для защиты контента, для связывания правил пользования с контентом и для определения, можно ли предоставить запрошенный доступ. Как описано более подробно ниже, в одном варианте осуществления, используются следующие объекты: 2.2.1. Объекты узел. Объекты узел используются для представления сущностей в системе. На практике, узел обычно представляет пользователя, устройство или группу. С объектами узел также обычно связаны атрибуты,которые представляют определенные свойства сущности, связанной с узлом. Например, на фиг. 4 показаны два пользователя (Ксан 400 и Нокс 402), два устройства (ПК 404 и портативное устройство 406), и несколько сущностей, которые представляют группы (например, членов семьи Кери 408, абонентов публичной библиотеки 410, подписчиков на конкретные музыкальные услуги-6 012918 412, устройств 414, одобренных RIAA (Американской ассоциацией звукозаписывающих компаний), и устройств 416, изготовленных конкретной компанией), с каждой из которых связан объект узел. В одном варианте осуществления объекты узел включают в себя атрибуты, указывающие, что представляет узел. Один пример атрибута это тип узла. Помимо представления пользователей, групп или устройств, атрибут тип узла можно использовать для представления других сущностей. В некоторых вариантах осуществления, объект узел также может включать в себя информацию криптографического ключа, например, при использовании варианта осуществления методов вывода и распространения ключа,описанных здесь в другом месте. В некоторых вариантах осуществления, объекты узел также включают в себя пару асимметричных ключей конфиденциальности, которая используется для нацеливания конфиденциальной информации на подсистемы, имеющие доступ к конфиденциальным частям объекта узел. Это может быть сущность, которую представляет узел (например, Музыкальные услуги 412) или некоторая сущность,отвечающая за управление узлом (например, конечный пользователь (например, Нокс 402) может отвечать за управление своим портативным устройством 406). 2.2.2. Объекты связь. В предпочтительном варианте осуществления, объекты связь представляют собой подписываемые объекты, используемые для показа соотношения между двумя узлами. Например, согласно фиг. 4,связь 418 от узла ПК 404 к узлу Нокс 402 показывает право собственности. Связь от узла Нокс 402 к узлу семья Кери 408 показывает принадлежность, как и связь от узла семья Кери 408 к узлу подписчики на музыкальные услуги 412. В одном варианте осуществления, объекты связь выражают соотношение между двумя узлами, и, таким образом, соотношения, показанные на фиг. 4, можно представить с использованием десяти связей. Согласно фиг. 4, граф 420 можно использовать для выражения соотношения между узлами, где объекты связь являются ориентированными ребрами между узлами. Например, на фиг. 4, соотношение между узлом семья Кери 408 и узлом музыкальные услуги 412 указывает, что существует ориентированное ребро 422 в графе, вершинами которого являются узел семья Кери 408 и узел музыкальные услуги 412. Нокс 402 и Ксан 400 являются членами семьи Кери 408. Поскольку Нокс 402 связан с семьей Кери 408, и семья Кери 4 08 связана с Музыкальными услугами 412, должен быть путь между Ноксом 402 и Музыкальными услугами 412. Механизм DRM рассматривает узел как доступный из другого узла,когда существует путь от этого узла к другому узлу. Это позволяет записать управляющий элемент, который позволяет разрешать доступ к защищенному контенту на основании того условия, что узел доступен из устройства, на котором выполняется приложение, которое запрашивает доступ к защищенному контенту. Как описано более подробно ниже, объекты связь также могут, в необязательном порядке, содержать некоторые криптографические данные, которые позволяют выводить ключи контента. Объекты связь также могут содержать программы управления, которые задают условия, при которых связь можно считать действительной. Такие программы управления могут выполняться или интерпретироваться (эти термины используются здесь взаимозаменяемо) виртуальной машиной механизма DRM для оценивания действительности связи (например, для определения, можно ли использовать связь для достижения данного узла в графе авторизации). В одном варианте осуществления, связи являются подписываемыми. Можно использовать любой подходящий механизм цифровой подписи, и в одном варианте осуществления механизм DRM не задает,как подписываются объекты связь, и не оценивает никакие соответствующие сертификаты, вместо этого, он опирается на систему хоста для проверки любых таких подписей и/или сертификатов. Это позволяет архитектору или администратору системы задавать срок действия объекта связь, отменять его и т.д. (например, с использованием истечения срока действия, отмены и/или т.п. ключей или сертификатов), тем самым обеспечивая дополнительный уровень управления политикой и безопасности на вершине управления политикой и безопасности, обеспечиваемых оцениванием программ управления и объектов DRM механизмом DRM в контексте конкретных фрагментов защищенного контента и/или связей(например, истечение срока действия связи можно, альтернативно или дополнительно, реализовать путем включения соответствующей программы управления в сам объект связь, которая, при выполнении,будет применять дату окончания срока действия или другой период действия). В одном варианте осуществления, механизм DRM является общим и работает с любой подходящей схемой шифрования, цифровой подписи, отмены и/или другой схемой безопасности, которая используется приложением и/или средой хоста. Таким образом, например, если механизму DRM нужно определить, имеет ли конкретная связь надлежащую подпись, он может просто вызвать приложение хоста (и/или криптографическую службу хоста или системы) для проверки подписи в соответствии с конкретной схемой подписи, выбранной проектировщиком системы, детали которой могут быть неизвестны механизму DRM. В других вариантах осуществления, механизм DRM сам осуществляет фактическое оценивание подписи, с опорой на хост, просто для указания использования надлежащего алгоритма подписи. 2.2.3. Защита и администрирование контента. Согласно фиг. 3, в типичном случае, поставщик контента 300b использует приложение 304b, кото-7 012918 рое включает в себя механизм упаковки для шифрования или иной криптографической защиты фрагмента электронного контента 308, и создает лицензию 306, которая регламентирует доступ к этому контенту или другое его использование. В одном варианте осуществления, лицензия 308 содержит набор объектов 305, которые указывают, как можно использовать контент 308, а также включает в себя ключ(и) шифрования контента и/или информацию, необходимую для его(их) получения. В одном варианте осуществления, контент 308 и лицензия 306 логически разделены, но связаны друг с другом внутренними ссылками(например, с использованием ID объекта 310). Во многих случаях, удобно сохранять и/или доставлять контент и лицензию совместно; однако в предпочтительных вариантах осуществления это не требуется. В одном варианте осуществления, лицензию можно применять к более чем одному элементу контента, и более чем одну лицензию можно применять к любому отдельно взятому элементу контента. Согласно фиг. 3, когда приложение хоста 304 а, выполняющееся на клиентском устройстве 300 а, хочет осуществить действие на конкретном фрагменте контента 308, оно просит механизм DRM 303 а проверить, разрешено ли действие, которое оно намеревается совершить (например, "воспроизведение"). В одном варианте осуществления, механизм DRM 303 а, из информации, содержащейся в объектах 305,содержащих лицензию контента 306, загружает и выполняет программу управления, связанную с контентом 308, и разрешение на осуществление действия дается или не дается на основании результата, возвращенного программой управления. Для дачи разрешения обычно требуется выполнение некоторых условий, например, условия доступности узла из узла, представляющего запрашивающую(ее) сущность/устройство 300 а. На фиг. 5 показана логическая блок-схема, демонстрирующая, как механизм DRM, согласно варианту осуществления, может определять, авторизовано ли запрошенное действие (например, просмотр фрагмента контента). Согласно фиг. 5, принимается (500) запрос на оценивание лицензии на данное действие. Например, этот запрос может поступать от приложения хоста, после того, как хост принимает от пользователя запрос на осуществление указанного действия. Согласно фиг. 5, механизм DRM оценивает указанную лицензию (502) и определяет, авторизовано ли запрошенное действие (504). Например, лицензия может содержать программу управления, которую выполняет механизм DRM, выход которой используется для принятия решения на авторизацию. Если лицензия авторизует запрошенное действие(т.е. на выходе "да" блока 504), то механизм DRM указывает приложению хоста, что запрос удовлетворен (506). В противном случае, механизм DRM указывает приложению хоста, что запрос отклонен (508). В некоторых вариантах осуществления, механизм DRM может также возвращать приложению хоста различные метаданные, которые, например, связывают условия с предоставлением авторизации (например,обязательства и/или обратные вызовы) или обеспечивают дополнительную информацию, касающуюся причины отказа в авторизации. Например, механизм DRM может указать, что запрошенное действие разрешено только, если приложение хоста регистрирует определенную информацию, относящуюся к осуществлению запрошенного действия, или при условии, что приложение хоста осуществляет обратные вызовы механизма DRM с заранее заданными интервалами времени, например, для повторного оценивания лицензии. Дополнительная информация о таких обязательствах, обратных вызовах, и другие метаданные, возвращаемые механизмом DRM, описаны ниже. Если запрошенное действие авторизовано,ключ контента извлекается (например, из объекта ContentKey лицензии) и используется для отпуска контента для запрашиваемого использования. 2.2.4. Объекты DRM лицензии. Согласно фиг. 6, в предпочтительном варианте осуществления лицензия 600 представляет собой совокупность объектов. В примере, показанном на фиг. 6, лицензия 600 содержит объект ContentKey 602,объект протектор 604, объект контороллер 606, и объект управления 608. Согласно фиг. 6, объектContentKey 602 включает в себя зашифрованные данные ключа 610 (например, зашифрованную версию ключа, необходимого для дешифрования зашифрованного элемента контента 612) и информацию, относящуюся к криптосистеме, используемой для шифрования данных ключа. Объект протектор 604 связывает объект ContentKey 602 с одним или несколькими объектами контент 614. Согласно фиг. 6, объект управления 608 включает в себя и защищает программу управления 616, которая указывает, как регламентируется объект контент 614. В предпочтительном варианте осуществления, программа управления 616 является фрагментом исполнимого байт-кода, который выполняется на виртуальной машине,используемой механизмом DRM. Программа управления определяет, можно ли осуществлять определенные действия на контенте, проверяя выполнение условий, указанных в программе управления, например, доступны ли определенные узлы с использованием действительных объектов связь, сохранены ли определенные объекты состояния, имеет ли среда хоста определенные характеристики, и/или т.п. Согласно фиг. 6, объект контроллер 606 используется для связывания одного или нескольких объектовContentKey 602 с объектом управления 608. Лицензия 600 также может содержать дополнительные объекты, например, метаданные, обеспечивающие описание, считываемое машиной или человеком, условий доступа к контенту, требуемых лицензией. Альтернативно или дополнительно, такие метаданные могут быть включены в качестве расширения ресурсов одного из других объектов (например, объекта управления 608). Согласно варианту осуществления, показанному на фиг. 6, объект управления 608 и объект контроллер 606 являются подписы-8 012918 ваемыми, что позволяет системе удостовериться в том, что информация управления поступила из доверенного источника, прежде чем использовать ее для принятия решений относительно доступа к контенту. В одном варианте осуществления, действительность объекта управления 608 также можно проверять путем проверки защищенного хэша, включенного в объект контроллер 606. Объект контроллер 606 также может содержать значение хэша для каждого из ключей или других данных ключа, содержащихся в объекте(ах) ContentKey 602, на который(е) он ссылается, благодаря чему нарушителю довольно трудно подделать его представление путем установления связи между данными ключа и объектом ContentKey. Согласно фиг. 6, в одном варианте осуществления контент 612 зашифрован и включен в объект контент 614. Используемый ключ дешифрования 610 включен в объект ContentKey 602 (или представлен им), и связь между ними представлена объектом протектор 604. Согласно фиг. 6, уникальные ID используются для облегчения установлению связи объектом контент 614 и объектом ContentKey 602. Правила, которые регламентируют использование ключа 610 для дешифрования контента 612, включены в объект управления 608, и связь между объектом управления 608 и объектом ContentKey 602 представлена объектом контроллер 606, опять же, с использованием уникальных ID. Очевидно, что, хотя на фиг. 6 показаны объекты, содержащие лицензию в одном предпочтительном варианте осуществления, описанные здесь системы и способы DRM не ограничиваются использованием этой структуры лицензии. Например, без ограничения, можно использовать лицензии, в которых функции различных объектов, показанных на фиг. 6, объединены в меньшее количество объектов, или распределены по дополнительным объектам, или разбиты между объектами иным образом. Альтернативно или дополнительно, варианты осуществления описанных здесь систем и способов можно применять на практике с лицензиями, которым недостает некоторых функций, обеспечиваемых структурой лицензии,показанной на фиг. 6, и/или, в которых предусмотрены дополнительные функции. Таким образом, очевидно, что можно использовать любой подходящий механизм для связывания лицензий с контентом в соответствии с описанными здесь принципами, хотя в предпочтительных вариантах осуществления используется преимущественная структура, показанная на фиг. 6. 2.3. База данных состояний. В одном варианте осуществления, механизм DRM включает в себя защищенное постоянное хранилище объектов, или имеет доступ к нему, которое можно использовать для обеспечения механизма защищенного хранилища состояний. Такое приспособление полезно для обеспечения программ управления, способных считывать и записывать информацию состояния, которая сохраняется от вызова к вызову. Такую базу данных состояний можно использовать для сохранения объектов состояния, например счетчиков воспроизведения, даты первого использования, совокупного времени представления и/или т.п., а также состояния принадлежности и/или любых других пригодных данных. В некоторых вариантах осуществления, механизм DRM, выполняющийся на первой системе, может не иметь доступа к локальной базе данных состояний, и может иметь возможность обращаться к удаленной базе данных состояний,например, с использованием веб-услуг и/или услуг хоста. В ряде случаев, механизму DRM, выполняющемуся на первой системе, может понадобиться доступ к информации состояния, хранящейся в базе данных на удаленной системе. Например, первая система может не включать в себя базу данных состояний, или может не иметь информации, в которой она нуждается, в своей собственной базе данных состояний. В некоторых вариантах осуществления, когда механизм DRM сталкивается с подобной ситуацией, он может обращаться к удаленной базе данных состояний через интерфейс услуг, и/или с использованием программ-агентов, что описано более подробно ниже. 2.4. О программах управления. Описанные здесь системы и способы используют программы управления в различных контекстах. Например, программы управления, содержащиеся в объектах управления, можно использовать для выражения правил и условий, регламентирующих использование защищенного контента. Кроме того, программы управления в объектах связь можно использовать для выражения правил и условий, используемых для определения, пригодна ли связь для данной цели (например, анализа доступности узла). Такие программы управления иногда называются здесь ограничениями по связи. Еще один контекст, в котором можно использовать программы управления, это объекты агент или делегат, где код управления используется для осуществления действия от имени другой сущности (в случае агентских программ управления) или от имени другого объекта управления (в случае делегатских программ управления). В одном варианте осуществления, программы управления выполняются или интерпретируются виртуальной машиной, базирующейся на механизме DRM, а не выполняющейся непосредственно физическим процессором. Однако очевидно, что можно легко построить физический процессор или иное логическое устройство для выполнения программ управления. В одном варианте осуществления, программы управления имеют формат байт-кода, что дает дополнительную возможность взаимодействия между платформами. В предпочтительном варианте осуществления, программы управления написаны на языке ассемблера и преобразованы в байт-код программой ассемблера. В других вариантах осуществления можно использовать шаблоны и/или языки выражения прав высокого уровня для обеспечения начального выражения прав, правил и/или условий, и можно использовать компилятор для преобразования выражения-9 012918 высокого уровня в байт-код для выполнения механизмом DRM согласно описанному здесь варианту осуществления. Например, выражения прав, записанные в собственном формате DRM, можно, с помощью соответствующего компилятора, преобразовать или транслировать в функционально эквивалентное выражение на уровне байт-кода для выполнения на механизме DRM согласно описанному здесь варианту осуществления, что позволяет использовать защищенный фрагмент контента, в соответствии с условиями, указанными поставщиком контента, на системах, которые понимают собственный формат DRM, а также системах, которые включают в себя механизм DRM, например, описанный здесь. Также очевидно,что описанные здесь системы и способы на основе механизма управления цифровыми правами не ограничиваются использованием выражений прав в формате байт-кода, интерпретируемых виртуальной машиной. Напротив, в некоторых вариантах осуществления, права можно выражать любым подходящим способом (например, с использованием языка выражения прав высокого уровня (REL), шаблона, и т.д.),и граф авторизации и/или другие описанные здесь методы, осуществляемые с использованием прикладной программы, предназначенной для распознавания и оценивания таких выражений прав. 2.4.1. Условия. Как указано выше, программы управления обычно выражают одно или несколько условий, которые должны выполняться для удовлетворения запроса на использование фрагмента контента, для того, чтобы связь была признана действительной, и/или т.п. Можно использовать любые подходящие условия, в зависимости от требований поставщика контента или архитектора системы, и/или функций, обеспечиваемых системой. В предпочтительных вариантах осуществления, виртуальная машина, используемая механизмомDRM, поддерживает программы любой сложности, которые способны проверять выполнение условий,например некоторые или все из следующих: Условия на основе времени: сравнение значения времени клиента со значением или значениями,указанным(и) в программе управления. Нацеливание конкретного узла: проверка, доступен ли определенный узел из другого узла. Эта концепция обеспечивает поддержку таких моделей, как домены, подписки, отношения принадлежности и т.п. Проверка, совпадают ли атрибуты определенного узла с указанными значениями: проверка любых атрибутов узла, например, удовлетворяют ли возможности представления устройства, связанного с узлом, требованиям верности. Проверка, обновлены ли метаданные, связанные с безопасностью, на клиенте: проверка, например,имеет ли клиент приемлемую версию клиентского программного обеспечения, и точное измерение времени. В некотором варианте осуществления, такая проверка может опираться, например, на утверждения в одном или нескольких сертификатах от службы сертификации данных. Условия на основе состояния: проверка информации в базе данных состояний. Например, база данных состояний может содержать информацию, сгенерированную в результате предыдущего выполнения программ управления, и/или жетоны, свидетельствующие о владении подписками, принадлежности и/или т.п., что позволяет оценивать условия, определяемые счетчиками (например, количество актов воспроизведения, количество актов экспорта, пределы истекшего времени и т.д.) и другую информацию,относящуюся к зарегистрированным событиям и условиям. Характеристики среды. Например, проверка, имеет ли оборудование и/или программное обеспечение в среде хоста определенные характеристики, например, способность распознавать и применять обязательства; проверка наличия или отсутствия определенных программных или аппаратных компонентов,например, защищенного выходного канала; проверка информации близости, например, близости запрашивающего устройства к другому устройству или приложению; проверка характеристик удаленных систем и/или хранящихся в них данных, с использованием сетевых услуг и/или агентов; и/или т.п. С использованием этих или любых других подходящих условий, объект управления может выражать правила, которые регламентируют представление, перенос, экспорт и/или т.п. контента. Очевидно,что вышеприведенный список условий носит иллюстративный характер, и что можно задать и использовать любые подходящие условия, например, путем реализации системного вызова для использования при проверке выполнения нужного условия. Например, без ограничения, если желательно потребовать, чтобы устройство находилось в конкретной подсети, можно задать системный вызов (например,GetIPConfig), который способен возвращать информацию IPConfig устройства хоста (или информациюIPConfig удаленного устройства, если системный вызов запущен на удаленном устройстве с использованием агента), который может использовать программа управления для проверки, находится ли устройство в предписанной подсети. 2.4.2. Агенты. Предпочтительные варианты осуществления описанных здесь систем и способов на основе механизма DRM обеспечивают поддержку независимых объектов, несущих программы управления. Такие"агенты" могут распространяться на механизм DRM, выполняющийся на удаленной системе, для выполнения указанных функций, например, записи в защищенное хранилище состояний удаленного механизмаDRM. Например, агент может передаваться вследствие контакта с удаленной службой или выполнения- 10012918 удаленной программы управления. Агент также можно использовать для осуществления операции перемещения контента, для инициализации счетчика, для отмены регистрации узла и/или т.п. В порядке еще одного примера, агент можно использовать для осуществления анализа доступности из удаленного узла к другому узлу. Такой агент, например, может быть полезен при применении политики, запрещающей второму пользователю регистрировать устройство, зарегистрированное первым пользователем. Если второй пользователь запросил регистрацию, агент может быть направлен на устройство вторым пользователем или службой регистрации, действующей от его имени, для определения, было ли устройство ранее зарегистрировано для первого пользователя, в каковом случае запрос второго пользователя на регистрацию будет отклонен. На фиг. 7 А и 7 В показано использование агентов в одном варианте осуществления. Согласно фиг. 7 А, предположим, что две сущности - система А 700 и система В 702 - желают связаться друг с другом через компьютерную сеть 703, и что используется система DRM, способная описывать и применять правила для определенных операций, например, доступа к защищенному контенту или создания объектовDRM, которые можно использовать для представления отношений принадлежности, состояния регистрации и/или т.п. в ряде случаев, правило(а) оцениваются на системе А 700, но для этого требуется информация, которая зависит от состояния системы В 702. Система DRM 704, которая применяет правило (а) на системе А 700, должна доверять этой информации. Например, система DRM 704 на системе А 700 может оценивать/применять правило осуществления дистанционного представления контента из системы А 700 в системе В 702, и правило может указывать,что такая операция разрешена только, если система В 702 входит в состав определенной группы устройств, причем принадлежность к этой группе подтверждается наличием объекта состояние 711 в защищенной базе данных состояний 716, доступной на системе В 702. Способ, используемый в предпочтительном варианте осуществления для работы в таких ситуациях,использует агенты. Например, если системе А 700 нужна информация из системы В 702, система А 700 подготавливает агент 705, который, в одном варианте осуществления, является программой управления(например, последовательностью команд, которые могут выполняться механизмом DRM), которая передается из системы А 700 в систему В 702. В одном варианте осуществления, система А 700 передает агентский код 705 в систему В 702 по аутентифицированному каналу связи 720, благодаря чему система А 700 может быть уверена, что агент 705 будет выполняться именно в системе В 702. В некоторых вариантах осуществления, помимо агентского кода 705, система А 700 также может передавать системе В 702 один или несколько параметров, которые агентский код 705 может использовать для осуществления своей работы. Согласно фиг. 7 В, система В 702 принимает агент 705 и любые параметры, связанные с агентом, и запускает агентский код 705. Когда агент 705 выполняется на системе В 702, он обращается к базе данных состояний 716 системы В, извлекает информацию состояния 711 и/или осуществляет одно или несколько вычислений над ней, и передает результаты 713 обратно в систему А 700, предпочтительно по аутентифицированному каналу связи 710, благодаря этому, система А 700 имеет информацию, которая ей нужна для продолжения своего оценивания. 2.4.3. Ограничения по связи. В одном варианте осуществления, набор процедур, которые представляют правила, регламентирующие осуществление определенной операции (например "воспроизведение") на элементе контента,называется "управляющий элемент действия". Набор процедур, которые представляют ограничения по действительности на объекте связь называется "ограничение по связи". Наподобие управляющих элементов действия, в предпочтительных вариантах осуществления ограничения по связи могут выражать любую подходящую комбинацию условий. Также аналогично управляющим элементам действия, ограничения по связи можно оценивать локально и/или дистанционно с использованием интерфейса услуг или агента. 2.4.4. Обязательства и обратные вызовы. В одном варианте осуществления, определенные действия, когда они разрешены, требуют дополнительного участия приложения хоста. Обязательства представляют операции, которые должно осуществлять приложение хоста после использования ключа контента, которые они запрашивают. Обратные вызовы представляют вызовы одной или нескольких процедур программы управления, которые должно осуществлять приложение хоста после использования ключа контента, которые они запрашивают. Примеры обязательств включают в себя, без ограничения, требование, чтобы определенные выходы и/или управляющие элементы были отключены в ходе представления контента (например, для предотвращения записи контента в незащищенный выход или для предотвращения перемотки вперед определенных важных сегментов контента); требование, чтобы информация, относящаяся к использованию контента записывалась (например, информация измерения или аудита) и/или передавалась в удаленное место (например, в расчетный центр, поставщику услуг и т.п.); требование, чтобы программа-агент выполнялась локально или дистанционно; и/или т.п. Примеры обратных вызовов включают в себя, без ограничения требование, чтобы хост осуществлял обратный вызов программы управления в определенное абсолютное время, по истечении определенного времени (например, времени пользования контентом), по наступле- 11012918 нии определенного события (например, по завершении периода пробного представления контента), когда использование контента остановлено, и/или т.п. Например, обратный вызов по истечении определенного времени можно использовать для увеличения или уменьшения бюджетов, счетчиков воспроизведения и т.п. (например, дебетования бюджета пользователей только, если они используют фрагмент контента в течение, по меньшей мере, определенного времени), что защищает пользователя от списания с его лицевого счета в случае, если он непреднамеренного нажмет кнопку воспроизведения, но сразу же нажмет кнопку остановки. В одном варианте осуществления, существуют разные типы обязательств и обратных вызовов, и если приложение сталкивается с каким-либо критическим обязательством или обратным вызовом, которое(ый) он не поддерживает или не понимает (например, потому, что тип обязательства был задан после реализации приложения), приложение должно отказаться от продолжения действия, для которого было возвращено это(т) обязательство или параметр обратного вызова. 2.4.5. Пример. На фиг. 8-12 показан пример того, как иллюстративный вариант осуществления механизма DRM может управлять использованием фрагмента контента. Согласно фиг. 8, предположим, что механизмDRM принял запрос на воспроизведение группы 800 элементов контента 802, 804. Например, элементы контента 802, 804 могут содержать разные подчасти мультимедиа-представления, различные треки альбома, различные фрагменты контента, полученные от службы подписки, вложенные файлы электронной почты и т.п. Запрос может приниматься механизмом DRM от приложения хоста, которое, в свою очередь, приняло запрос от пользователя вычислительного устройства, после чего приложение хоста было выполнено. Запрос от приложения хоста обычно идентифицирует запрошенное действие, фрагмент или фрагменты контента, после которых должно быть выполнено действие, и лицензию(и), которая(ые) управляют контентом. Механизм DRM выполняет процесс, показанный на фиг. 5, для определения, нужно ли удовлетворить запрос. На фиг. 8 и 9 обеспечен более подробный неограничительный пример процесса, показанного на фиг. 5. Согласно фиг. 9, после приема запроса на доступ к элементам контента 802 и 804 (блок 900), механизм DRM проверяет лицензию(и), указанные в запросе, или иначе связанную(ые) с ним, чтобы определить, существует ли действительная лицензия. Например, механизм DRM может сначала идентифицировать объекты протектор 806 и 808, которые содержат уникальные идентификаторы элементов контента 802 и 804 (т.е. NS:007 и NS:008, соответственно) (блок 902 на фиг. 9). Затем, механизм DRM обнаруживает объекты ContentKey 810 и 812, указанные в объектах протектор 806 и 808 (блок 904 на фиг. 9), что, в свою очередь, позволяет механизму DRM идентифицировать контроллер 814, который ссылается на оба объекта ContentKey 810 и 812 (блок 906 на фиг. 9). В предпочтительном варианте осуществления, контроллер 814 подписан, и механизм DRM проверяет его подпись (или запрашивает услуги хоста для ее проверки). Механизм DRM использует контроллер 814 для идентификации объекта управления 816, который регламентирует использование объекты ContentKey 810 и 812 (и, таким образом, элементы контента 802 и 804) (блок 908 на фиг. 9). В предпочтительном варианте осуществления, механизм DRM проверяет целостность объекта управления 816 (например, путем вычисления дайджеста объекта управления 816 и сравнения его с дайджестом, содержащимся в контроллере 814). Если проверка целостности успешна, механизм DRM выполняет код управления, содержащийся в объекте управления 816 (блок 910), и возвращает результат (блок 912) приложению хоста, которое использует его для удовлетворения или отклонения запроса пользователя на доступ к контенту. Результат кода управления также может, в необязательном порядке, указывать одно или несколько обязательств или обратных вызовов, которые понадобиться выполнить приложению хоста. На фиг. 10 показан более подробный пример того, как механизм DRM может осуществлять действия, указанные в блоках 910 и 912 на фиг. 9 (т.е. выполнять программу управления и возвращать результат). Согласно фиг. 10, идентифицировав соответствующий объект управления, механизм DRM загружает байт-код, содержащийся в объекте управления, в виртуальную машину, которая, предпочтительно,базируется на механизме DRM (блок 1000). Механизм DRM и/или виртуальная машина также обычно инициализирует среду выполнения виртуальной машины (блок 1002). Например, виртуальная машина может выделять память, необходимую для выполнения программы управления, инициализировать регистры и другие переменные среды, и/или получать информацию о среде хоста, в которой действует виртуальная машина (например, делая вызов System.Host.GetObject, описанный ниже). Очевидно, что в некоторых вариантах осуществления блоки 1000 и 1002 можно эффективно комбинировать или перемежать и/или обращать их порядок. Согласно фиг. 10, виртуальная машина затем выполняет байт-код программы управления (блок 1004). Как описано здесь в другом месте, для этого можно делать вызовы кода другой виртуальной машины, извлекать информацию состояния из защищенного хранилища и/или т.п. По окончании выполнения программы управления, она обеспечивает выход (например, в предпочтительном варианте осуществления, ExtendedStatusBlock), который может использовать, например, вызывающее приложение для определения, был ли удовлетворен запрос, и, если это так, связаны ли с ним какие-либо обязательства или обратные вызовы; был ли отклонен запрос, и, если это так, по какой причине; или произошли ли какие-либо ошибки в ходе выполнения (блок 1006).- 12012918 Как указано выше, код управления, содержащийся в объекте управления 816, указывает условия или другие требования, которые должны быть выполнены для осуществления запрошенного использования элементов контента 802 и 804. Описанные здесь системы и способы позволяют задавать наборы условий любой сложности; однако, в целях этого примера, предположим, что программа управления призвана требовать, чтобы, для воспроизведения элементов контента 802 и 804, (а) данный узел пользователя был доступен из устройства, на котором был сделан запрос на воспроизведение контента, и (b) текущая дата была позже указанной даты. На фиг. 11 показано, как иллюстративный вариант осуществления механизма DRM 1100, выполняющийся на устройстве 1102, может выполнять вышеописанную иллюстративную программу управления, и на фиг. 12 показана логическая блок-схема этапов, предусмотренных при выполнении процесса. Согласно фиг. 11, механизм DRM 1100 создает контекст выполнения виртуальной машины (например,путем вызова System.Host.SpawnVm) 1104 и загружает программу управления. Виртуальная машина 1104 начинает выполнение программы управления в точке входа, указанной механизмом DRM 1100 (например, в положении процедуры Control.Actions.Play.perform). В этом примере, программа управления нуждается в определении, доступен ли данный узел из узла индивидуальных особенностей устройства 1102, на котором выполняется механизм DRM 1100. Чтобы произвести такое определение, программа управления вызывает 1105 услугу менеджера связей 1106, предоставляемую механизмом DRM 1100,указывая узел, с которым требуется установить связь (блок 1200 на фиг. 12). Менеджер связей 1106 отвечает за оценивание объектов связь для определения, доступен ли один узел из другого. Чтобы делать это эффективно, менеджер связей 1106 может предварительно вычислять, существует ли путь от узла индивидуальных особенностей 1110 устройства 1102 к различным узлам 1114, указанным в любых объектах связь, которыми обладает это устройство 1102. Таким образом, менеджер связей 1106 может,просто проверяя поля "к" и "от" связей, к которым он обращается, определять, какие узлы потенциально доступны из узла индивидуальных особенностей 1110 устройства 1102. Когда менеджер связей 1106 принимает вызов 1105 от виртуальной машины 1104, он определяет, доступен ли указанный узел 1112,сначала определяя, существует ли путь от узла индивидуальных особенностей 1110 к указанному узлу 1112 (например, проверяя ID узла в списке узлов, которые ранее были определены как теоретически доступные) (блок 1202 на фиг. 12). Если путь существует, менеджер связей 1106 оценивает любые программы управления, содержащиеся в связях, чтобы определить, действительны ли связи (блоки 1204-1210 на фиг. 12). Чтобы оценить программы управления в объектах связь (блок 1206 на фиг. 12), менеджер связей 1106 может использовать свою собственную виртуальную машину 1108, на которой он выполняет программы управления, включенные в объекты связь. Менеджер связей 1106 возвращает результаты своего определения (т.е. доступен ли данный узел) программе управления, выполняющейся на виртуальной машине 1104, где она используется для общего оценивания, будет ли удовлетворен запрос на воспроизведение фрагмента контента. После определения, что указанный узел 1112 доступен из узла индивидуальных особенностей 1110 устройства 1102, программа управления, выполняющаяся на виртуальной машине 1104, определяет, выполняется ли указанное ограничение по дате (блок 1212 на фиг. 12). Если ограничение по дате выполнено (т.е. на выходе "да" из блока 1212), то программа управления возвращает результат, указывающий, что указанные условия выполнены (блок 1214 на фиг. 12); в противном случае,программа управления возвращает результат, указывающий, что указанные условия не выполнены (блок 1216 на фиг. 12). Пример программы управления, например вышеописанной, показан ниже.- 16012918 Дополнительный пример программы управления включен в приложение Е. 3. Потребление контента и приложения упаковки. Ниже приведено более подробное описание иллюстративных вариантов осуществления приложения, которое потребляет DRM-защищенный контент (например, медиа-проигрывателя, текстового редактора, почтового клиента и т.д., например приложения 303 а, 303 с и 303d на фиг. 3), и приложения упаковки, например, приложения 303b, которое упаковывает контент, адресованный потребляющим приложениям. 3.1. Архитектура приложения, потребляющего контент. Приложение, потребляющее контент, обычно нацелено на доступ к защищенному контенту или может составлять часть приложения общего назначения, которое также осуществляет другие функции,например, упаковки контента. В различных вариантах осуществления, приложение, потребляющее контент, может осуществлять некоторые или все из следующих функций: обеспечивать интерфейс, посредством которого пользователь может запрашивать доступ к защищенным объектам контент и принимать информацию о контенте или информацию ошибки; управлять взаимодействием с файловой системой; распознавать формат защищенных объектов контент; запрашивать механизм DRM для оценивания лицензии на фрагменты контента, для определения,можно ли дать разрешение на доступ к контенту; проверять цифровые подписи и выполнять другие криптографические функции общего назначения,в осуществлении которых нуждается механизм DRM; запрашивать механизм DRM для обеспечения ключей, необходимых для дешифрования защищенного контента; и/или дешифровать защищенный контент и взаимодействовать со службами медиа-представления для представления контента. В одном варианте осуществления, механизм клиента DRM оценивает лицензии, связанные с контентом, подтверждает или отклоняет разрешение использовать контент и передает ключи дешифрования приложению, потребляющему контент. Механизм клиента DRM также может выдавать одно или несколько обязательств и/или обратных вызовов приложению, потребляющему контент, требующих от приложения осуществлять определенные действия вследствие получения доступа к контенту. На фиг. 13 показаны элементы, составляющие клиентское приложение 1300, потребляющее контент, в одном варианте осуществления. Согласно фиг. 13 приложение хоста 1302 является логическим центральным пунктом клиента. Он отвечает за перенос шаблона взаимодействия между другими модулями, а также взаимодействие с пользователем через пользовательский интерфейс 1304. Приложение хоста 1302 предоставляет набор услуг механизму DRM 1306 через интерфейс 1308 услуг хоста. Интерфейс 1308 услуг хоста позволяет механизму DRM 1306 получать доступ к данным, администрируемым приложением хоста 1302, а также определенным библиотечным функциям, реализованным приложением хоста 1302. В одном варианте осуществления, интерфейс 1308 услуг хоста является единственным внешним интерфейсом для механизма DRM 1306. В одном варианте осуществления, механизм DRM 1306 не взаимодействует напрямую с мультимедийным контентом, администрируемым приложением хоста 1302. Приложение хоста 1302 логически взаимодействует с услугами контента 1310 для осуществления доступа к мультимедийному контенту, и передает механизму DRM 1306 только фрагменты данных, которые должен обрабатывать механизм. Другие взаимодействия с контентом осуществляются механизмом медиа-представления 1312. Например,в одном варианте осуществления услуги контента 1310 отвечают за получение контента от медиасерверов и за сохранение и администрирование контента в постоянном хранилище клиента, тогда как механизм медиа-представления 1312 является подсистемой, отвечающей за доступ к мультимедийному контенту и его представление (например, на видео- и/или аудио-выходе). В одном варианте осуществления, механизм медиа-представления 1312 принимает некоторую информацию от механизма DRM 1306(например, ключи дешифрования контента), но, в одном варианте осуществления, механизм DRM 1306 взаимодействует с механизмом медиа-представления 1312 не напрямую, но через приложение хоста 1302. Некоторая информация, необходимая механизму DRM 1306, может быть доступна совместно с мультимедийным контентом, и ее можно получать и иметь возможность манипулировать ею посредством услуг контента 1310, однако может возникнуть необходимость получать часть этой информации посредством других услуг, например, услуги персонализации или услуги принадлежности (не показаны). Согласно варианту осуществления, показанному на фиг. 13, криптографические операции (например, шифрование, проверка подписи, и т.д.) осуществляются блоком криптографических услуг 1314. В одном варианте осуществления, механизм DRM 1306 не взаимодействует напрямую с блоком криптографических услуг 1314, но взаимодействует косвенно, через хост 1302 (с использованием интерфейса 1308 услуг хоста), который передает его запросы. Криптографическими услугами 1314 также может пользоваться, например, механизм медиа-представления 1312 для осуществления дешифрования контента.- 17012918 Очевидно, что фиг. 13 носит иллюстративный характер, и что в других вариантах осуществления различные компоненты, показанные на фиг. 13, могут быть иначе организованы, объединены, разделены,исключены, и/или могут быть добавлены новые компоненты. Например, без ограничения, логическое разделение функций между механизмом DRM и приложением хоста на фиг. 13 просто иллюстрирует один возможный вариант осуществления, и возможны различные практические реализации. Например, механизм DRM может быть полностью или частично объединен с приложением хоста. Таким образом, очевидно, что можно использовать любое пригодное разделение функций между приложением хоста и механизмом DRM. 3.2. Архитектура упаковщика. Ниже приведен пример функций, которые может осуществлять механизм упаковки для приложения хоста, которое упаковывает электронный контент. На практике, приложение упаковки может конкретно предназначаться для упаковки, или составлять часть приложения общего назначения, действующего на пользовательской системе, которое также осуществляет доступ к защищенному контенту (упакованному локально или в другом месте, например, в сети). В различных вариантах осуществления, упаковывающее приложение хоста может осуществлять некоторые или все из следующих функций: обеспечивать пользовательский интерфейс, посредством которого можно задавать информацию контента и лицензии; шифровать контент; создавать объекты DRM, составляющие лицензию; и/или создавать объект контент, который содержит или ссылается на контент и содержит или ссылается на лицензию. На фиг. 14 показаны элементы, которые составляют приложение упаковки 1400 в одном варианте осуществления. Механизм упаковки DRM 1416 отвечает за упаковку лицензий, например, описанных здесь (например, лицензий, содержащих объекты DRM, например, объекты управления, контроллеры,протекторы и т.п.). В некоторых вариантах осуществления, механизм упаковки DRM 1416 может также связывать метаданные с лицензией для объяснения, в понятной человеку форме, что делает лицензия. В одном варианте осуществления, приложение хоста 1402 обеспечивает пользовательский интерфейс 1404 и отвечает за получение информации, например, ссылок на контент и действие(я), которое(ые) пользователь (обычно владелец или поставщик контента) хочет осуществить (например, к кому привязать контент, какие условия пользования контентом включить в лицензию, и т.д.). Пользовательский интерфейс 1404 также может отображать информацию о процессе упаковки, например, текст выпущенной лицензии, и, в случае сбоя, причину сбоя. В некоторых вариантах осуществления, некоторая информация, необходимая приложению хоста 1402, может потребовать использование других услуг, например,услуг аутентификации или авторизации и/или принадлежности через точку доступа к службе (SAP). Таким образом, в некоторых вариантах осуществления, приложение упаковки 1400 и/или приложение хоста 1402 может нуждаться в реализации некоторых или всех из следующих служб: Услуги медиа-формата 1406. В одном варианте осуществления, этот элемент отвечает за управление операциями медиа-формата, например, перекодирование и упаковку. Он также отвечает за шифрование контента, которое достигается посредством модуля 1408 услуг шифрования контента. Криптографические услуги общего назначения 1410. В одном варианте осуществления, этот элемент отвечает за выдачу/проверку подписей, а также шифрование/дешифрование некоторых данных. Запросы на такие операции может выдавать точка доступа к службе 1414 или механизм упаковки DRM 1416 через интерфейс услуг хоста 1412. Услуги шифрования контента 1408. В одном варианте осуществления, этот модуль логически отделен от криптографических услуг общего назначения 1410, поскольку он не знает о приложении. Он запускается модулем услуг медиа-формата в момент упаковки контента, с набором ключей, ранее выданных механизмом упаковки DRM 1416. 4. Вывод ключа. Ниже описана система вывода ключа, которая естественным образом согласуется с описанными здесь предпочтительными вариантами осуществления механизма DRM и архитектурой системы, и/или которую можно использовать в других контекстах. Некоторые примеры в нижеследующем разделе взяты из иллюстративной реализации предпочтительного варианта осуществления этой системы вывода ключа,известной под названием "Scuba". Дополнительные варианты осуществления описаны в заявке '551. Согласно фиг. 15, в некоторых вариантах осуществления объекты связь 1530 а, 1530b используются для распространения ключей, помимо своей основной цели - установления соотношений между узлами 1500 а, 1500b, 1500c. Как описано выше, объект управления может содержать программу управления, которую можно использовать для принятия решения, следует ли удовлетворить запрос на осуществление действия. Для этого, программа управления может проверять, доступен ли конкретный узел через цепь связей. Описанные здесь методы вывода ключа пользуются наличием этой цепи связей для облегчения распространения ключа, что позволяет сделать ключ доступным механизму DRM, который- 18012918 выполняет программу управления. В одном иллюстративном варианте осуществления, каждый объект узел 1500 а, 1500b, 1500c в данной конфигурации, которая использует необязательную систему распространения ключей, имеет набор ключей, которые используются для шифрования ключей контента и ключей других узлов. Объекты связь 1530 а, 1530b, созданные для использования в той же конфигурации, содержат некоторые криптографические данные в качестве полезной нагрузки, что позволяет выводить информацию ключей, когда цепи связей обрабатываются механизмом DRM. Благодаря узлам и связям, несущим ключи подобным образом, причем цепь связей 1530 а, 1530b идет от узла А 1500 а к узлу С 1500 С, сущность (например, механизм DRM клиентского приложение хоста), которая имеет доступ к секретным ключам совместного пользования узла А 1515 а, 1525 а, также имеет доступ к секретным ключам совместного пользования узла С 1515 с, 1525 с. Возможность доступа к секретным ключам совместного пользования узла С дает сущности доступ к любому ключу контента,зашифрованному этими ключами. 4.1. Узлы, сущности и ключи. 4.1.1. Сущности. В одном варианте осуществления системы DRM, узлы представляют собой объекты данных, не принимающие активного участия в системе. Активные участники, в этом контексте, называются сущностями. Примерами сущностей являются медиа-проигрыватели, устройства, служба подписки, упаковщики контента и т.п. С сущностями обычно связаны узлы. Сущность, которая потребляет контент, использует механизм DRM и управляет, по меньшей мере, одним объектом узел, который составляет ее индивидуальность. В одном варианте осуществления, предполагается, что сущность имеет доступ ко всем данным объектов узел, которым она управляет, в том числе ко всей личной информации этих объектов. 4.1.2. Узлы. Объекты узел, которые участвуют в иллюстративном варианте осуществления системы вывода ключа, содержат ключи как часть своих данных. В одном варианте осуществления, узлы может содержать два общих типа ключей: ключи совместного пользования и ключ конфиденциальности. В нижеследующих разделах перечислены разные типы ключей, которые можно использовать в различных вариантах осуществления. Однако очевидно, что конкретная конфигурация может использовать только подмножество этих ключей. Например, система может быть настроена на работу только с парами ключей,без использования секретных симметричных ключей. В другом случае, система может быть сконфигурирована без предоставления узлам ключей конфиденциальности, если необходимо использовать только ключи совместного пользования. 4.1.2.1. Ключи совместного пользования. Ключи совместного пользования представляют собой пару открытого/секретного ключей и/или симметричных ключей, которые совместно используются узлом N и всеми узлами Рх, для которых существует связь от Рх к N, которая содержит расширения вывода ключа. Открытый ключ совместного пользования: Kpub-share[N] Это открытая часть пары открытого/секретного ключей для шифра открытого ключа. Этот ключ обычно приходит с сертификатом, что позволяет проверять мандат сущностям, которые хотят криптографически связать с ним конфиденциальную информацию. Секретный ключ совместного пользования: Kpriv-share[N] Это секретная часть пары открытого/секретного ключей. Сущность, управляющая узлом, призвана гарантировать, что этот секретный ключ держится в секрете. По этой причине, этот секретный ключ обычно хранится и переносится отдельно от остальной информации узла. Далее этот секретный ключ можно сделать совместно используемым с другими узлами посредством расширений вывода ключа в связях. Симметричный ключ совместного пользования: Ks-share[N] Это ключ, который используется с симметричным шифром. Как и секретный ключ, этот ключ является конфиденциальным, и сущность,управляющая узлом, отвечает за сохранение его в секрете. Далее этот секретный ключ можно сделать совместно используемым с другими узлами посредством расширений вывода ключа в связях. 4.1.2.2. Ключи конфиденциальности. Ключи конфиденциальности это пары ключей и/или симметричные ключи, известные только сущности, управляющей узлом, которой они принадлежат. Разница между этими ключами и вышеописанными ключами совместного пользования в том, что они не делаются совместно используемыми с другими узлами посредством расширений вывода ключа в связях. Открытый ключ конфиденциальности. Kpub-conf[N] Это открытая часть пары открытого/секретного ключей для шифра открытого ключа. Этот ключ обычно приходит с сертификатом, что позволяет проверять мандат сущностям, которые хотят криптографически связать с ним конфиденциальную информацию. Секретный ключ конфиденциальности. Kpriv-conf[N] Это секретная часть пары открытого/секретного ключей. Сущность, управляющая узлом, призвана гарантировать, что этот секретный ключ держится в секрете. По этой причине, этот секретный ключ обычно хранится и переносится отдельно от- 19012918 остальной информации узла. Симметричный ключ конфиденциальности: Ks-conf[N] Это ключ, который используется с симметричным шифром. Как и секретный ключ конфиденциальности, этот ключ хранится в секрете. 4.2. Криптографические элементы. Предпочтительные варианты осуществления описанных здесь систем вывода и распространения ключа можно реализовать с использованием разнообразных криптографических алгоритмов, и они не ограничиваются каким-либо конкретным выбором криптографического алгоритма. Тем не менее, для данной(го) конфигурации или профиля, все участвующие сущности, в общем случае, должны согласовываться с набором поддерживаемых алгоритмов (термин профиль, в целом, относится к спецификации набора фактических технологий, используемых в конкретной реализации (например, RSA для вывода ключа; XML для кодирования объектов; МР 4 для формата файла и т.д.) и/или другому представлению семантического контекста, которое существует, когда объекты заданы в практической конфигурации). В одном варианте осуществления, конфигурации включают в себя поддержку по меньшей мере одного шифра открытого ключа (например, RSA) и одного шифра симметричного ключа (например, AES). При описании криптографических функций будет использоваться следующая система обозначений:Ep(Kpub[N], M) означает "сообщение М, зашифрованное открытым ключом Kpub узла N с использованием шифра открытого ключа";Dp(Kpriv[N], М) означает "сообщение М, дешифрованное секретным ключом Kpriv узла N с использованием шифра открытого ключа";Es(Ks[N], М) означает "сообщение М, зашифрованное симметричным ключом Ks узла N с использованием шифра симметричного ключа";Ds(Ks[N], М) означает "сообщение М, дешифрованное симметричным ключом Ks узла N с использованием шифра симметричного ключа". 4.3. Нацеливание ключей контента. В предпочтительном варианте осуществления используется два типа криптографического нацеливания. Нацеливание ключа контента на ключи совместного пользования конечного узла означает делание этого ключа доступным для всех сущностей, которые совместно используют секретные ключи совместного пользования этого конечного узла. Нацеливание ключа контента на ключи конфиденциальности уза означает делание этого ключа доступным только для сущности, которая управляет этим узлом. Нацеливание ключа контента осуществляется путем шифрования ключа контента СК, переносимого в объектеContentKey, с использованием одного или обоих из следующих методов. Открытое связывание: создание объекта ContentKey, который содержит Ep(Kpub[N], CK). Симметричное связывание: создание объекта ContentKey, который содержит Es(Ks[N], CK). В предпочтительном варианте осуществления по возможности используется симметричное связывание, поскольку для него требуется менее вычислительно-интенсивный алгоритм, и поэтому оно менее обременительно для принимающей сущности. Однако сущность (обычно, упаковщик контента), которая создает объект ContentKey, не всегда имеет доступ к Ks[N]. Если упаковщик не имеет Ks[N], он может использовать открытое связывание, поскольку Kpub[N] не является конфиденциальной информацией, и потому его можно сделать доступным для сущностей, которым нужно произвести открытое связывание.Kpub[N] обычно делается доступным для сущностей, которым нужно нацеливать ключи контента совместно с сертификатом, который сущность может проверять для принятия решения, действительно лиKpub[N] является ключом узла, которому можно доверить манипулировать ключом контента в соответствии с некоторой согласованной политикой (например, что узел соответствует сущности, выполняющей механизм DRM и приложение хоста, которые согласуются с функциональными, операционными политиками и политиками безопасности системы). 4.4. Вывод ключей с использованием связей. Чтобы сущность могла иметь доступ к ключам совместного пользования всех узлов, доступных из своего узла индивидуальности, в одном варианте осуществления, объекты связь содержат необязательную полезную нагрузку расширения ключа. Эта полезная нагрузка расширения ключа позволяет сущностям, которые имеют доступ к открытому/секретному ключам начального узла связи, также иметь доступ к личным/секретным ключам совместного пользования конечного узла связи. Таким образом,сущность может дешифровать любой ключ контента, нацеленный на узел, который доступен из ее узла индивидуальности (если нацеливание произведено с использованием ключей совместного пользования конечного узла). В одном варианте осуществления, когда механизм DRM обрабатывает объекты связь, он обрабатывает полезную нагрузку расширения ключа каждой связи для обновления внутренней цепи ключей, к которой он имеет доступ. В одном варианте осуществления, полезная нагрузка расширения ключа связиL от узла F к узлу Т содержит либо: открытую информацию вывода: Ер(Kpub-share[F], Ks-share[T],Kpriv-share[T]), либо симметричную информацию вывода: Es(Ks-share[F], Ks-share[T],Kpriv-share[T]),где Ks-share[T], Kpriv-share[T] - структура данных, содержащая Ks-share[T] и Kpriv-share[T]. Открытая информация вывода используется для переноса секретных ключей совместного пользо- 20012918 вания узла Т, Ks-share[T] и Kpriv-share[T] на любую сущность, которая имеет доступ к личному ключу совместного пользования узла F, Kpriv-share[F]. Симметричная информация вывода используется для переноса секретных ключей совместного пользования узла Т, Ks-share[T] и Kpriv-share[T], на любую сущность, которая имеет доступ к симметричному ключу совместного пользования узла F, Ks-share [F]. Как и при нацеливании ключей контента на узлы, предпочтительная полезная нагрузка, подлежащая включению в связь, является симметричной информацией вывода. Это возможно, когда создатель связей имеет доступ к Ks-share[F]. Если нет, создатель связей делает шаг назад, включая в себя открытую информацию вывода в качестве полезной нагрузки для связи. Предполагая, что механизм DRM, обрабатывающий связь, уже имеет Ks-share[F] и Kpriv-share[F] в своей внутренней цепи ключей после обработки связи, L[FТ], он также будет иметь Ks-share[T] иKpriv-share[T]. Поскольку, в одном варианте осуществления, связи можно обрабатывать в любом порядке, механизм DRM может не иметь возможности производить вычисления для вывода ключа во время обработки данной связи L. Это может быть следствием того факта, что, в это время, цепь ключей механизма DRM может еще не содержать ключи начального узла этой связи. В этом случае, связь запоминается и обрабатывается снова, когда новая информация становится доступной механизму DRM, например, после обработки новой связи Р. Если конечный узел связи Р совпадает с начальным узлом связи L, и начальный узел связи Р является доступным узлом, то начальный узел связи L также будет доступным, и на этапе вывода ключа личные ключи совместного пользования начального узла связи L добавляются в цепь ключей. 5. Примеры реализации. Ниже приведено несколько примеров, иллюстрирующих, как различные варианты осуществления описанных здесь систем и способов можно применять на практике. Описанные здесь системы и способы могут обеспечивать широкий круг функций управления правами и других функций, откуда следует, что приведенные здесь конкретные примеры не претендуют на то, чтобы быть исчерпывающими, но просто иллюстрируют объем изобретения. 5.1. Пример. Пользователи, ПК и устройства. Предположим, что Вы хотите реализовать систему DRM, которая связывает право на воспроизведение контента с конкретным пользователем, и Вы хотите облегчить для пользователя воспроизведение контента на всех устройствах воспроизведения, которыми он обладает. Предположим, что Вы решили снабдить пользователей программным обеспечением, которое позволяет им добавлять необходимые устройства воспроизведения (например, мобильные проигрыватели). Однако предположим также, что Вы хотите задать некоторую политику, ограничивающую количество устройств общего назначения, на которые пользователь сможет переносить контент, чтобы пользователь не имел возможности действовать как распространитель. На основании этих системных требований, может иметь смысл, например, связывать создаваемые Вами лицензии с пользователями и устанавливать соотношения между пользователями и устройствами,которые они используют. Таким образом, в этом примере, Вы сначала можете решить, какого рода узлы Вам нужны для установления необходимых Вам видов соотношений. Например, Вы можете задать следующие типы узлов: Пользователь (например, лицо, владеющее правами на использование контента); ПК (например, прикладная программа, выполняющийся на персональном компьютере, которая может воспроизводить контент и указывать дополнительные устройства воспроизведения); Устройство (например, портативное устройство для представления контента). Каждый объект узел может включать в себя атрибут type (тип), который указывает, представляет ли объект пользователя, ПК или устройство. Пусть, например, Вы решили ограничить максимальное количество объектов узел ПК, которые могут быть присоединены к любому пользователю в конкретный момент времени, четырьмя (4). Вы решили, что не нужно ограничивать количество устройств, присоединенных к пользователю, пока Вы обеспечиваете ограничение по количеству ПК. На основании этого, можно таким образом настроить программу управления, чтобы она разрешала доступ, если можно установить соотношение между узлом пользователь и узлом, запрашивающим доступ. Тогда этот узел может быть либо ПК, либо устройство. На фиг. 16 показана система, призванная удовлетворять вышеизложенным требованиям. Сервер 1600 присваивает объект узел пользователь 1602 а, 1602b каждому новому пользователю 1604 а,1604b, и регулирует способность пользователей 1604 а, 1604b связывать с собой устройства 1606, 1608 и ПК 1610, 1612 с целью доступа к защищенному контенту. Когда пользователь 1604 а желает связать новое устройство 1606 со своим узлом пользователь 1602 а, сервер 1600 определяет, содержит ли уже устройство 1606 информацию персонализации 1614, что может иметь место, если устройство 1606 было персонализовано во время изготовления. Если устройство не содержит информацию персонализации 1614, сервер 1600 использует эту информацию персонализации 1614 для создания связи 1616 от устройства 1606 к узлу 1602 а пользователя, и передает связь 1616 устройству 1606 пользователя. Когда пользо- 21012918 ватель 1604 а получает защищенный контент 1618 (например, с сервера 1600 или от какого-либо другого поставщика контента), этот контент 1618 нацеливается на узел 1602 а пользователя (например, путем шифрования ключа дешифрования контента одним из секретных ключей совместного пользования, связанных с узлом 1602 а пользователя), и с ним связывается лицензия 1619, указывающая условия, при которых можно осуществлять доступ к контенту. Когда пользователь 1604 а пытается воспроизвести контент 1618 на устройстве 1606, механизм DRM 1620, выполняющийся на устройстве 1606, оценивает лицензию 1619, которая указывает, что контент 1618 можно воспроизводить, пока доступен узел пользователь 1602 а. Механизм DRM 1620 оценивает связь 1616, которая показывает, что узел пользователь 1602 а доступен из устройства 1606, и удовлетворяет запрос пользователя 1604 а на доступ к контенту 1618, например, авторизуя дешифрование ключа дешифрования контента, содержащегося в лицензии 1619. Поскольку ключ дешифрования контента, в этом примере, зашифрован с использованием секретного ключа, связанного с узлом 1602 а пользователя, этот секретный ключ нужно получить, чтобы дешифровать ключ дешифрования контента. Если используются описанные здесь в другом месте необязательные методы вывода ключа, ключ узла пользователь можно получить, просто расшифровав информацию вывода ключа, содержащуюся в связи 1616, с использованием одного из секретных ключей устройства 1606. Дешифрованная информация вывода ключа будет содержать ключ, необходимый для дешифрования ключа дешифрования контента, содержащегося в лицензии 1619 (или информации, из которой его можно вывести или получить). Согласно, опять же, фиг. 16, предположим, что пользователь 1604 а желает связать новый ПК 1610 со своим узлом пользователь 1602 а. Сервер 1600 проверяет, не связано ли уже с узлом пользователь 1602 а максимальное количество ПК, и авторизует связывание ПК 1610 с узлом пользователь 1602 а. Однако для осуществления связывания сервер 1600 должен получить информацию персонализации от ПК 1610 (например, криптографические ключи, уникальный идентификатор и т.д.). Если же прежде не был персонализован PC 1610 (что может иметь место, если пользователь просто загрузил копию программного обеспечения ПК), сервер 1600 осуществляет процесс персонализации (например, создавая объект узел PC с использованием протокола загрузки, описанного здесь в другом месте) или направляет пользователя к поставщику услуг, который может осуществить процесс персонализации. По завершении процесса персонализации, сервер 1600 может создать связь 1624 от ПК 1610 к узлу пользователь 1602 а и передать связь на ПК 1610, который может продолжать пользоваться ею, пока она остается действительной. Позже пользователь может запросить добавление дополнительных ПК, и сервер будет применять политику, которая ограничивает количество объектов узел PC на одного пользователя числом 4 (обычно он также предоставляет пользователям возможность, при необходимости, удалять PCs из своего активного списка). В порядке еще одного примера, предположим, что поставщик услуг решил, что пользователи должны иметь возможность воспроизводить любой контент, которым они обладают, на любом принадлежащем им устройстве. Поставщик услуг также может пожелать позволить программному обеспечению ПК пользователя создавать связи с каждым из его устройств, не требуя от пользователя связаться с сервером 1600. В этом варианте осуществления, когда пользователь желает воспроизвести контент на новом устройстве, программное обеспечение ПК пользователя будет обращаться к конфиденциальной информации персонализации нового устройства и использовать ее для создания новой связи для этого устройства (например, связи от нового устройства к узлу 1602 а пользователя). Если устройство не персонализовано, то программное обеспечение ПК может обратиться к удаленной службе или предписать устройству обратиться к удаленной службе, для осуществления процесса персонализации. Затем программное обеспечение ПК передает связь на новое устройство, и при этом новое устройство получает возможность воспроизводить контент, пока она остается действительной, поскольку, в одном варианте осуществления, если объект связь существует, нет необходимости создавать другую, пока не истечет срок действия объекта связь или он станет недействительным по другой причине. В вышеприведенных примерах, контент нацеливается на пользователя. Для этого, приложение упаковщика выбирает новый ID для контента или использует существующий, создает ключ шифрования и соответствующий объект ContentKey, а также объект протектор для связывания объекта контент и объекта ContentKey. Затем упаковщик создает объект управления с программой управления (например,компилированной в байт-код, который может выполняться на виртуальной машине механизма DRM),что позволяет выполнять действие "воспроизведение", если и только если узел пользователь доступен от узла ПК или устройство, который запрашивает действие. Обычно объекты управление, контроллер, протектор и ContentKeys по мере возможности внедряются в упакованный контент, благодаря чему ПК и устройствам не приходится получать их отдельно. В одном варианте осуществления, когда устройство или ПК хочет воспроизвести контент, оно выполняет процесс, например, описанный выше в связи с фиг. 9. Таким образом, механизм DRM находит объект протектор для content ID контента, затем объект ContentKey, указанный этим протектором, затем объект контроллер, на который ссылается этот объект ContentKey, и, наконец, объект управления,- 22012918 указанный этим контроллером. Механизм DRM выполняет программу управления объекта управления,которая проверяет, доступен ли узел пользователь. Если узел устройство или ПК имеет необходимые объекты связь для проверки наличия пути между своим узлом и узлом пользователь, то условие выполняется, и программа управления позволяет использовать ключ, представленный в объекте ContentKey. Затем механизм медиа-представления устройства или ПК может дешифровать и воспроизвести контент. 5.2. Пример. Временный вход. На фиг. 17 показан другой пример возможного применения описанных здесь систем и способовDRM. Этот пример аналогичен примеру, приведенному в предыдущем разделе, за исключением того, что здесь политика, которая регламентирует создание объектов связь между объектами узел PC и объектами узел пользователь допускает временный вход не более чем на 12 ч, при условии, что пользователь уже не имеет временный вход на другом ПК. Эта особенность позволяет пользователю 1700 перенести свой контент 1702 на ПК друга 1704, зайти на этом ПК 1704 на период времени и воспроизвести контент 1702 на ПК друга 1704. Для этого создается объект связь 1710 с ограниченным периодом действия. В одном варианте осуществления это можно делать следующим образом. Для простоты объяснения, предположим, что потребляющее программное обеспечение 1714 с разрешенным DRM, необходимое для воспроизведения DRM-защищенного контента 1702 уже присутствует на ПК друга 1704. Файл, содержащий контент 1702 и лицензию 1708, переносится на ПК друга 1704. Когда пользователь пытается воспроизвести контент 1702, программное обеспечение 1714 распознает отсутствие действительных объектов связь, связывающих локальный узел ПК с узлом пользователя, который владеет контентом. Программное обеспечение 1714 предлагает пользователю представить мандат 1712 (это может обеспечиваться через имя пользователя/пароль, протокол аутентификации мобильного телефона, смарт-карту или любую систему аутентификации, разрешенную согласно политике системы) и связывается с вычислительной системой базы данных 1706. Вычислительная система базы данных 1706 проверяет атрибуты объекта узел пользователь и объекта узел ПК, для которых запрошена связь,и проверяет, нет ли активного объекта связь для временного входа, который все еще действителен. При выполнении этих условий, служба базы данных 1706 создает объект связь 1710, связывающий объект узел PC друга и узел пользователя, с периодом действия, ограниченным запрошенной длительностью входа (например, менее 12 ч, для согласования с политикой в этом примере). Наличие объекта связь 1710 позволяет ПК друга 1704 воспроизводить контент 1702 пользователя, пока не истечет срок действия связи 1710. 5.3. Пример: управление контентом предприятия. На фиг. 18 показана высокоуровневая архитектура иллюстративной системы 1800 для управления документацией предприятия (например, электронной почтой, документами текстового редактора, слайдами презентации, текстами мгновенного обмена сообщениями и/или т.п.). В примере, показанном на фиг. 18, приложение редактирования документов (например, текстовый редактор) 1802, почтовый клиент 1804 и сервер директорий (например, сервер активной директории) 1806 используют плагин 1808 управления цифровыми правами (DRM), уровень согласования сетевых услуг 1810, службу регистрации 1812 и службу политик 1816 для упрощения обработки документов, сообщений электронной почты, и/или т.п. в соответствии с политиками. В предпочтительном варианте осуществления, плагин DRM 1808, уровень согласования сетевых услуг 1810, служба политик 1816 и служба регистрации 1812 реализованы с использованием механизма DRM и технологии согласования услуг, описанной здесь в другом месте и в заявке '551. Например, в одном варианте осуществления, плагин DRM 1808 может содержать вышеописанный вариант осуществления механизма DRM. Очевидно, что, хотя на фиг. 18 показан вариант осуществления, в котором существующие приложения, например, текстовый редактор 1802 и почтовый клиент 1804 объединены с механизмом DRM посредством плагина, который приложения могут вызывать, в других вариантах осуществления механизм DRM может составлять неотъемлемую часть одного или обоих приложений. Также очевидно, что иллюстративную систему, показанную на фиг. 18, можно реализовать в пределах одного предприятия или можно распространить на несколько предприятий. В иллюстрации, показанной на фиг. 18, сервер директорий 1806 может, например, содержать профили пользователей и определения групп. Например, системный администратор компании может задать группу под названием "Команда особых проектов" путем идентификации членов Команды особых проектов компании. В одном варианте осуществления сервер директорий 1806 может содержать Сервер активной директории, выполняющий веб-услуги, например, описанные в заявке '551 (и реализованные, например,посредством стандартных технологий на основе IIS на платформе Windows), которые выдают узлы,связи и лицензии членам группы Команда особых проектов на основании контента, к которому осуществляется доступ. Если состав членов группы меняется, выдаются новые жетоны. Для отмены прав, сервер директорий 1806 может запустить услугу метаданных безопасности, основанную на технологии, например, описанной в заявке '551 (иногда именуемой здесь технологией "NEMO"). В некоторых вариантах осуществления, может потребоваться, чтобы клиент имел значение времени на данное число или обозна- 23012918 чение времени (на основании того, насколько свежее значение задается по выбору компании (например,1 неделя, 1 день, 1 ч, каждые 5 мин и т.д. для использования лицензий DRM. Например, жетон, предоставляемый услугой метаданных безопасности, может включать в себя доверенное и аутентифицируемое значение времени. В некоторых вариантах осуществления, клиент может идентифицировать ID узлов пользователь, взаимодействуя с услугой метаданных безопасности. Метаданные безопасности можно оценивать непосредственно в контексте объектов управления лицензии для определения, все ли еще пользователь имеет данную принадлежность. Метаданные безопасности также могут возвращать агенты,которые могут определять, действительны ли соотношения, например, членство в Команде особых проектов. Таким образом, в некоторых вариантах осуществления можно усовершенствовать существующую инфраструктуру авторизации и аутентификации компании (например, Сервер активной директории компании), просто добавив несколько четко прописанных веб-услуг. На фиг. 19 показан пример, как систему, например, показанную на фиг. 18, можно использовать для управления доступом к документу или другим его использованием. В этом примере, конкретный служащий (Джон) может часто работать над высокосекретными стратегическими проектами, и может иметь уже установленный плагин DRM 1908 для своих приложений (например, программы текстового редактора 1902, программы электронной почты 1904, программы календаря, программы или пакета программ,которая(ый) объединяет такие программы, и/или т.п.). В какой-то момент при создании документа, Джон обращается к элементу "полномочия" выпадающего меню, которое было добавлено в инструментальную панель его приложения (действие 1913). Открывается диалоговое окно полномочий, которое связывается с Сервером активной директории 1906 его компании для доступа к директории лиц и групп, зарегистрированных в системе. Он выбирает "Команда особых проектов" из списка, и выбирает дать каждому члену команды разрешение просматривать, редактировать и печатать документ. С использованием технологии согласования услуг NEMO, описанной в заявке '551, плагин DRM 1908 связывается с расширением службы политик 1916 с разрешенным NEMO до Активной директории 1906 и запрашивает копию политики для использования с целью защиты файлов Команды особых проектов (действие 1914). Когда Джон сохраняет документ, плагин DRM автоматически шифрует файл 1912, и создает объект лицензия, нацеленный и связанный с группой под названием "Команда особых проектов" 1910. Лицензия 1910 позволяет осуществлять доступ к файлу 1912 (например, просмотр, редактирование, печать и т.д.) со стороны любого устройства, которое может создать действительную цепь связей от своего узла устройство к узлу группа Команды особых проектов. Джон может осуществлять доступ к документу 1912, поскольку его устройство имеет связь с узлом пользователь Джона, а также имеет связь от узла пользователь Джона к узлу группа "Команды особых проектов". Аналогично, если он пересылает этот документ другим людям, они могут осуществлять доступ к нему только, если они также могут создать действительную цепь связей к узлу группа"Команды особых проектов" (например, потребовав, чтобы узел Команда особых проектов был доступен устройству). Джон может сохранить файл (уже защищенный) на своем компьютере, и затем присоединить его к сообщению электронной почты (действие 1920). Например, он может открыть старое сообщение электронной почты своему начальнику (Джорджу), присоединить файл, как он обычно это делает, и отправить сообщение. Согласно фиг. 20, Джордж также имеет плагин DRM 2000, установленный на его компьютере 2014. Когда он входит на свой компьютер 2014, плагин 2000 своевременно проверяет все группы, в которые он добавлен (действие 2006), и загружает новые, обновленные связи для всех тех, срок действия которых истек (действие 2012). Если он добавлен в "Команду особых проектов" после своего последнего входа, его плагин 2000 загружает объект связь 2008, который связывает его узел пользователь с узлом группа "Команды особых проектов". Эта связь 2008 указывает, что узел пользователь Джорджа является членом узла группа "Команды особых проектов". В этом примере, предположим, что объект связь 2008 имеет дату окончания срока действия, после которой он уже недействителен (например, 3 дня). Согласно фиг. 21, когда Джордж пытается открыть документ (действия 2130, 2132), плагин DRM 2108 проверяет внедренную (или присоединенную) лицензию, и узнает, что узел "Команда особых проектов" должен быть доступным. Его плагин 2108 строит (и удостоверяет) цепь связей 2120, 2122 от узла устройство его компьютера к узлу пользователь Джорджа; и от узла пользователь Джорджа к узлу группа "Команды особых проектов" (действие 2134). Поскольку устройство имеет действительную цепь связей 2120, 2122, его плагин 2108 разрешает доступ к файлу. Как описано здесь в другом месте, в некоторых вариантах осуществления связи также могут нести защищенную цепь ключей. Таким образом, в некоторых вариантах осуществления, создавая цепь связей к узлу Команда особых проектов, плагин может удостоверять не только разрешение на доступ к контенту, но также то, что он способен дешифровать цепь ключей, которая позволяет ему дешифровать контент. Если, например, другой сотрудник (Кэрол) случайно получает электронное письмо Джона и пытается открыть документ, ее плагин DRM извлекает лицензию, связанную с файлом, и оценивает условия лицензии. Ее ПК имеет связь к ее узлу пользователь Кэрол; но, поскольку она не является членом ко- 24012918 манды, не существует связи от "Кэрол" к узлу группа "Команды особых проектов". Поскольку "Команда особых проектов" недоступна, Кэрол не разрешено обращаться к файлу. Если Кэрол со временем добавляется с группу "Команда особых проектов", в следующий раз, когда ее плагин DRM будет обновлять ее отношения принадлежности, он обнаружит эту новую группу и загрузит объект связь, который связывает ее узел пользователь с узлом Команда особых проектов. Теперь ее плагин имеет все необходимые связи для построения цепи от ее узла устройство к ее узлу пользователь и далее к узлу Команда особых проектов. Теперь узел Команда особых проектов"доступен", и она может открывать любые документы и почтовые отправления, адресованные Команде особых проектов, даже созданные до того, как она стала членом команды. Предположим, что месяц спустя Джордж переводится на новую роль и удаляется из группы Команда особых проектов в Активной директории. В следующий раз, когда Джордж осуществляет вход,его плагин не принимает новый, обновленный объект связь, связывающий узел пользователь Джорджа с "Командой особых проектов". Когда, спустя несколько недель, он пытается открыть файл Джона, его плагин пытается построить цепь связей к Команде особых проектов. Его ПК все еще имеет связь к узлу пользователь Джорджа (ПУ Джорджа все еще принадлежит ему); но связь от "Джорджа" к"Команде особых проектов" уже недействительна. Поскольку "Команда особых проектов" недоступна,ему не разрешено обращаться к файлу. Предположим, что компания имеет политику, которая требует регистрировать в журнале доступ ко всей конфиденциальной информации. В одном таком варианте осуществления, политика для Команды особых проектов требует, чтобы все лицензии, созданные для этой группы, также требовали сбора информации о пользовании и передачи ее, например, в центральное хранилище. Таким образом, в этом примере, при оценивании (например, выполнении) программы управления в лицензии, плагин выполняет требование регистрировать доступ в журнале и делает это. Например, важные действия можно регистрировать в локальной защищенной базе данных состояний, например, описанной здесь, и, после восстановления связности сети, соответствующий контент можно сообщать через вышеописанные услуги. На фиг. 22 показана другая иллюстративная система 2200 для управления электронным контентом на предприятии. В примере, показанном на фиг. 22, сервер LDAP 2206 используется для управления профилями пользователей, определениями групп и назначениями ролей и содержит определение группы под названием "Команда особых проектов" и определение роли "Поверенный". Предположим, что Джон является поверенным и желает послать электронное письмо с вложением другим членам Команды особых проектов. Когда Джон устанавливает плагин DRM 2208 для своих приложений, он также устанавливает элементы в инструментальную панель своего почтового клиента. В некоторый момент при составлении сообщения электронной почты, Джон обращается к элементу "Установить полномочия" выпадающего меню, добавленного в его инструментальную панель. Плагин DRM 2208 связывается со службой политик 2216 и отображает список корпоративных политик обмена сообщениями, из которого можно выбирать. Джон выбирает "Special Project DRM Template", и плагин DRM 2208 использует протокол NEMO для запроса и удостоверения аутентичности, целостности и конфиденциальности объекта политика, который он принимает. Политика описывает, как следует создавать лицензии, которые используют этот шаблон, в том числе, как их следует нацеливать и связывать. Когда Джон кликает по элементу "Отправить", плагин DRM 2208 шифрует сообщение и вложение и генерирует соответствующую(ие) лицензию(и). Лицензия требует, чтобы, для доступа к электронной почте или вложению, узел группа Команды особых проектов или узел группа "Поверенные" должен быть доступным. Лицензии связываются с зашифрованной полезной нагрузкой сообщения и зашифрованным вложением. Затем сообщение передается в список получателей с использованием стандартных функций электронной почты. Поскольку правила лицензии и шифрование не зависят от адресации электронной почты,тот факт, что неправильный получатель электронной почты может быть ошибочно включен, не подвергает опасности содержимое электронного письма или вложения. Поскольку такой непреднамеренный получатель не имеет действительного объекта связь, связывающего его узел пользователь с Командой особых проектов, ему не разрешается обращаться к контенту, если и когда он пытается сделать это. Кроме того, поскольку его устройство не имеет необходимой цепи связей (и ключей, которые они содержат), его устройство даже не имеет возможности дешифровать контент. Однако, если непреднамеренный получатель, в свою очередь, пересылает то же самое, неизмененное электронное письмо с использованием стандартных функций электронной почты члену Команды особых проектов, этот член будет иметь объект связь, который связывает его узел пользователь с узлом группа "Команды особых проектов", и будет способен обращаться к содержимому электронного письма. Предположим, что другой поверенный (Билл) в компании также получил объект связь, который связывает его с узлом группа "Команды особых проектов". Билл также может просматривать файл. Если он пересылает сообщение помощнику юриста (Тренту), который не является поверенным и не связан с Командой особых проектов, Трент не будет иметь объекта связь, который связывает его с узлом- 25012918 группа "Команды особых проектов", и он не получит доступ к документу. Если Трент впоследствии добавляется в группу Команда особых проектов в директории LDAP 2206, он получает необходимые объекты связь и возможность доступа к ранее переправленному сообщению электронной почты. Если, как рассмотрено выше, компания имеет политику, указывающую, что требование отчетности должно быть включено во все лицензии, то, в одном варианте осуществления, всякий раз при выполнении программы управления в одной из этих лицензий (например, когда кто-то пытается обратиться к файлу), может инициироваться событие отчетности. Этап отчетности может дополнительно включать в себя указатель, предоставлен доступ или же отклонен - это вопрос выбора реализации. При использовании такого указателя, может поддерживаться журнал количества попыток доступа к конкретному документу и состояния или иной информации каждой из них (например, успех, неудача и т.д.). В порядке еще одного примера, предположим, что один из членов (Стивен) Команды особых проектов переходит в другую компанию для работы над особым проектом. До его перехода в другую компанию, почтовый клиент Стивена загружает локальную копию всех писем в его ящике входящих сообщений. Защищенный отчет, присоединенный к одному из этих писем, также включает в себя внедренную(или присоединенную) лицензию. Этот объект лицензия включает в себя как правила доступа к контенту, так и зашифрованный ключ контента. Только "отсутствующая связь", необходимая для доступа к контенту, является необходимым объектом связь для достижения узла группа "Команды особых проектов". Поскольку в этом примере политика компании разрешает объектам связь оставаться действительными в течение 3 дней, объект связь, который связывает узел пользователь Стивена с узлом Команда особых проектов, будет оставаться действительным, пока он переходит и отключается. Если он попытается обратиться к файлу в автономном режиме, узел группа Команды особых проектов все еще будет доступен, и ему будет разрешено обратиться к файлу. Если же Stephen останется в автономном режиме в течение более трех дней, объект связь, связывающий его с Командой особых проектов, утратит силу. Узел группа Команды особых проектов станет недоступным, и Стивену не будет разрешено обращаться к файлу. Если Стивен, в конце концов, окажется в месте, где он сможет связаться с системой компании (например, через VPN), его плагин DRM запросит обновленные копии объектов связь для каждой из групп, которым он принадлежит. Поскольку он все еще является членом группы "Команда особых проектов", он получит новый объект связь от своего узла пользователь к узлу группа Команды особых проектов. Эта связь заменит 'старую' связь, которая утратила силу и более недействительна. Поскольку узел "Команда особых проектов" теперь доступен с использованием этой новой, обновленной связи, Стивен опять получает возможность обращаться к защищенному отчету. Новый объект связь будет действителен в течение 3 дней, после чего также утратит силу. В порядке еще одного примера, предположим, что член Команды особых проектов (Салли) желает связаться с другим членом команды посредством службы мгновенного обмена сообщениями, сохранить копию сообщений и передать ее еще одному члену команды (например, в виде вложения электронной почты, дискеты, защитной заглушки и т.п.). В этом примере, клиент службы мгновенного обмена сообщениями (и, возможно, любых других продуктов для обмена сообщениями или связи, которыми компания снабжает своих сотрудников) привязывается к плагину DRM, which, как и в предыдущих примерах,обращается к политике "Special Project DRM Template", которая определяет, как нужно нацеливать и привязывать лицензии. Когда Салли пытается сохранить свои переговоры в службе мгновенного обмена сообщениями (например, выбирая "Сохранить как"), плагин выбирает ключ шифрования (например,произвольно) и упаковывает (шифрует) текст переговоров. Согласно политике компании, плагин DRM генерирует объект лицензия, который нацеливается и привязывается к узлу группа Команды особых проектов. Файл, содержащий защищенный дубликат IM, связывается с лицензией на доступ к содержимому дубликата. Как и в предыдущих примерах, лицензия содержит как правила, которые регламентируют доступ к контенту, так и зашифрованную копию ключа контента. Салли может перенести этот связанный файл в сообщение электронной почты, на защитную заглушку USB, дискету и т.д. с использованием стандартных процедур 'перетаскивания', и отправить его кому-то еще. При условии, что устройство получателя может создавать действительные связи к узлу группа особых проектов, доступ к контенту разрешен и возможен. Предположим, что Салли передает файл Джону, который также является членом Команды особых проектов. Если Джон имеет недавно обновленный объект связь, который идентифицирует его как члена Команды особых проектов, он сможет обращаться к файлу. Согласно политике компании этот объект связь содержит дату окончания срока действия, согласно которой срок его действия истекает через три дня. Поэтому, даже если Джон остается отключенным, он все же будет иметь доступ, пока эта связь остается действительной. Если некоторое время спустя Джон уходит из Команды особых проектов на другую работу и находит в своей сумке защитную заглушку USB от Салли и пытается открыть файл с использованием своего- 26012918 настольного компьютера, объект связь, связывающий его узел пользователь с Командой особых проектов утратит силу. Поскольку он больше не является членом команды, плагин DRM на его устройстве уже не может найти новые, обновленные связи. Поскольку узел группа "Команды особых проектов" уже недостижима с его устройства, доступ не разрешается. Полагая, что его портативный компьютер не подключался к сети с тех пор, как он сменил работу,он также пытается открыть файл с этого устройства. Поскольку максимальное предоставленное время прошло, эта связь больше не действительна. В некоторых вариантах осуществления, каждый раз, когда он пытается обратиться к файлу, может генерироваться отчет, который ставится в очередь на отправку в центральное хранилище. Центральное хранилище принимает многочисленные отчеты о безуспешных попытках доступа к файлу и сигнализирует менеджеру по электронной почте. Менеджер напоминает Джону, что ему больше не разрешено обращаться к конфиденциальному материалу, и просит уничтожить все файлы (несмотря на то, что система указывает, что доступ не может быть предоставлен). В порядке еще одного примера, предположим, что государственное агентство или внешний аудитор желает провести расследование или инспекцию, как Команда особых проектов обращается с конфиденциальной информацией. Чтобы помочь расследованию, компания желает продемонстрировать контрольные записи, касающиеся доступа важной информации в связи с Особым проектом. С этой целью компания сначала сканирует все архивы незашифрованных сообщений на предмет любых сообщений, связанных с Особым проектом. К их облегчению, они обнаруживают, что, в соответствии с политикой компании, никто из сотрудников не посылал сообщений, касающихся Особого проекта, без надлежащей DRM-защиты (например, за пределы системы). Затем компания использует записи доступа DRM для создания контрольного журнала, где подробно указано, кто и когда имел доступ к защищенной информации. Согласно процедуре, принятой в компании, при создании группы Команда особых проектов, в нее по умолчанию вводится начальник правового отдела (ССО). Объект связь для начальника правового отдела создается и сохраняется на архивном сервере, что позволяет ему, при необходимости, просматривать содержимое всех сообщений в будущем. В этом примере политика, определенная для Команды особых проектов, указывающая, что все лицензии, создаваемые командой, должны включать в себя обязательный отчет обо всех попытках доступа к файлу, включающий в себя дату и время, UserNode, и был ли предоставлен доступ. Эти отчеты сохраняются в журнале доступа в центральном хранилище. ССО проверяет журналы доступа для всех случаев доступа, связанных с Командой особых проектов, до того дня, когда возникло подозрение в утечке информации или нарушении правил. ССО также производит поиск в архивах электронной почты, IM и сетевого резервирования на предмет всех переданных сообщений и системных файлов на этот день и до него. Поскольку к каждому файлу присоединена лицензия (с ключом контента), и ССО имеет необходимые объекты связь, удовлетворяющие требованиям лицензии, ему разрешен доступ к содержимому всех сообщений, к которым был совершен доступ до указанного времени. Журналы доступа и содержимое незашифрованных сообщений поступают в полное распоряжение агентства/аудитора в порядке расследования. В некоторых вариантах осуществления политика для Команды особых проектов также может включать в себя необходимость задавать дату окончания срока действия всех лицензий, относящихся к Особому проекту. Например, если компания лишь по закону обязана хранить записи такого рода в течение 1 года, она может указать в политике, что лицензии утрачивают силу через год после даты выпуска. В этом случае, компания может хранить записи ровно столько времени, сколько предписывает закон. После этого даже ССО не имеет к ним доступ. В рассмотренном выше материале иногда упоминалось "нацеливание" и "привязка". В предпочтительных вариантах осуществления, нацеливание и привязка представляют два разных, но тесно связанных между собою процесса. В предпочтительных вариантах осуществления, "привязка" это, в основном,криптографический процесс, относящийся к защите ключа, который используется для шифрования контента. Когда лицензия 'привязана' к узлу (например, узлу "Команда особых проектов"), это может означать, например, что ключ контента зашифрован открытым ключом, связанным с этим узлом. Таким образом, только устройства, имеющие доступ к секретному ключу узла, будут иметь необходимый ключ для дешифрования контента (и, в предпочтительных вариантах осуществления, единственным путем к получению доступа к секретному ключу узла является дешифровка цепи связей к этому узлу); однако, просто наличие правильного секретного ключа указывает только, что устройство имеет возможность дешифровать контент, но ему еще нужно получить на это разрешение. В предпочтительных вариантах осуществления, разрешено ли устройству обращаться к контенту,определяет программу управления в лицензии, и, в частности, как она "нацелена"."Нацеливание" означает добавление требования в программу управления для указания, что конкретный узел (или узлы) "доступны" для осуществления пользования контентом. В вышеприведенных примерах, программа управления обычно указывает, что конкретный узел "Команда особых проектов"- 27012918 доступен потребляющему устройству. В ряде случаев может быть желательно, чтобы лицензии были нацелены на более чем один узел,например, команда по разработке нового продукта в компании ("Компания"), которая работает со многими поставщиками, поставляющими компоненты для нового совершенно секретного продукта. Предположим, что на ранних стадиях проекта, поставщик А и поставщик В (конкуренты) имеют связи к "SecretProjectX". Поставщик А желает поделиться своими идеями со всеми членами SecretProjectX, но не хочет,чтобы, по неосторожности, они стали известны поставщику В. Поставщик А может нацеливать свои лицензии так, что: ("SecretProjectX доступен") и ("Поставщик А доступен" или "Компания доступна"). Если Компания непреднамеренно предает эту информацию гласности во всм Secret Project X (в том числе, и для поставщика В), поставщик В не получит разрешения взглянуть на нее, что ограничивает всякую опасность неразглашения для Компании и ограничивает возможность поставщика А потерять свои коммерческие секреты. 5.4. Пример. Записи системы здравоохранения. На фиг. 23 показано применение описанных здесь систем и способов для управления записями системы здравоохранения. Предположим, что медицинские записи имеют разные уровни конфиденциальности, и что желательно предоставлять разные права доступа разным сущностям в системе (например, пациентам, врачам, страховым компаниям и т.п.). Например, может быть желательно разрешать просматривать некоторые записи только пациенту, разрешать просматривать некоторые записи только врачу пациента, разрешать просматривать некоторые записи пациенту, но только в редакции врача пациента, разрешать просматривать некоторые записи всем врачам, разрешать просматривать некоторые записи всем страховым компаниям, разрешать просматривать некоторые записи только страховой компании пациента, и/или т.п. Согласно фиг. 23, эту экосистему здравоохранения 2300 можно смоделировать с использованием объектов DRM наподобие узлов и связей, например, описанных здесь в другом месте. Например, узлы можно присваивать пациенту 2302, врачам 2304 пациента, страховой компании 2306 пациента, устройствам (2308, 2310) пациента, конкретному одному из врачей 2312 пациента, вычислительным устройствам 2314, 2316 врача, группе всех врачей 2318, группе врачей определенной специализации 2320, медицинскому учреждению 2322, страховой компании 2324, вычислительным устройствам, используемым страховой компанией 2326, группе всех страховых компаний 2328, и т.п. Предположим, что врач пациента использует свой ПК для создания медицинской записи, касающейся пациента. Например, медицинская запись может содержать шаблон документа содержащий поля для примечаний, диагнозов, рецептов, инструкций для пациента и/или т.п. Шаблон также может позволять врачу выбирать политики безопасности для управления документом и/или отдельным его полем. Например, приложение врача может предоставлять возможность выбора из набора стандартных политик безопасности, и, получив выбор врача, может автоматически генерировать лицензию на основании этих выборов и связывать защищенный (например, зашифрованный) контент медицинской записи. В целях этого примера, предположим, что лицензия предоставляет доступ для просмотра пациенту,всем поставщикам услуг здравоохранения, которые лечат пациента, и всем страховым компаниям, которые обеспечивают покрытие для пациента. Кроме того, предположим, в целях иллюстрации, что лицензия предоставляет права редактирования только кардиологу в медицинском учреждении х. Приложение упаковки принимает ввод, указывающий политику врача (который может просто содержать кликанье мышкой по стандартному шаблону) и генерирует лицензию, которая включает в себя программу управления, например, приведенную ниже:- 28012918 Медицинскую запись и связанную с ней лицензию можно затем сохранить в центральной базе данных медицинских записей, базе данных, которой управляет конкретное медицинское учреждение, и/или т.п. Если пациент Y впоследствии посещает другого поставщика услуг здравоохранения и авторизует этого поставщика услуг здравоохранения как одного из его доверенных поставщиков услуг здравоохранения (например, подписывая форму авторизации), этот поставщик услуг здравоохранения получает связь к approved узлу доверенный поставщик услуг здравоохранения пациента у, которую поставщик услуг здравоохранения будет хранить на своей компьютерной системе. Если этому поставщику услуг здравоохранения понадобится обратиться к медицинской записи, созданной врачом х, он сможет получить доступ для просмотра этой медицинской записи, поскольку узел доверенный поставщик услуг здравоохранения пациента у будет доступен от компьютерной системы нового поставщика услуг здравоохранения. Если же, недоверенный поставщик услуг здравоохранения захочет получить копию (зашифрованной) медицинской записи, он не сможет обратиться к ней ввиду отсутствия необходимых узлов (т.е. узла пациента у, узла для всех доверенных поставщиков услуг здравоохранения пациента у и узла для всех доверенных страховых компаний пациента у), которые были бы доступны от его вычислительной системы. Заметим, однако, что показанная выше иллюстративная программа управления включает в себя доминирующую особенность, которую можно вызывать, например, в экстренных случаях, если, например,поставщик услуг здравоохранения нуждается в доступе к защищенной медицинской записи, но не может выполнить условия программы управления (например, потому, что поставщик услуг здравоохранения,пытающийся сделать экстренный доступ к медицинской записи, ранее не был зарегистрирован как поставщик услуг здравоохранения пациента Y). Однако заметим также, что вызов исключения экстренного доступа приводит к автоматической записи информации, касающейся вызова и/или иных обстоятельств,и, в этом примере, также приводит к отправке извещения (например, предпочтительному поставщику услуг здравоохранения пациента, т.е. сущности, в явном виде авторизованной пациентом, и/или самому пациенту). Связывание таких обязательств с экстренным исключением может препятствовать злоупотреблению исключением, поскольку будет существовать запись о злоупотреблении. Очевидно, что эта иллюстративная программа представлена для облегчения объяснения определенных вариантов осуществления описанных здесь систем и способов. Например, включает ли в себя система поддержку экстренных исключений, обычно зависит от требований и желаний архитектора системы. Таким образом, например, некоторые варианты осуществления могут не поддерживать экстренные исключения, другие могут поддерживать экстренные исключения, но ограничивать класс сущностей, которые могут вызывать такие исключения, классом "все врачи" (например, за счет требования, чтобы флагEmergencyException был задан равным "истина" И узел все врачи был доступен), и другие все же могут поддерживать экстренные исключения, но не связывать с ними принудительные обязательства (поскольку неспособность выполнить обязательство, в предпочтительном варианте осуществления, сделает контент недоступным), опираясь вместо этого на нетехнические, правовые или институциональные средства применения (например, путем оказания доверия поставщикам услуг здравоохранения, не злоупотребляющим возможностью вызывать исключение, и/или опираясь на промышленную сертификацию и правовую систему для предотвращения злоупотреблений). Еще одно изменение, которое можно внести в вышеприведенные примеры, состоит в том, что можно потребовать более сильное доказательство того, что к медицинской записи обратился действительно врач, или врач с конкретным именем, а не кто-то другой, сидящий за компьютером, который врач использует для доступа к записям (и, таким образом, компьютером, потенциально содержащим связи, необходимые для удовлетворения анализа доступности). Такую усиленную форму аутентификации можно осуществлять любым подходящим способом. Например, ее можно полностью или частично осуществлять на уровне приложения или системы, защищая компьютер врача и/или программное обеспечение,используемое для доступа к медицинским записям, с использованием паролей, защитных заглушек, механизмов биометрической идентификации и/или т.п. Альтернативно или дополнительно, программы управления, связанные с определенными медицинскими записями сами могут включать в себя обязательство или условие, требующее такой усиленной идентификации, например, проверку наличия защитной заглушки, требование, чтобы хост получил пароль, и/или т.п. 5.5. Пример. Подписки. На фиг. 24 показано, как представленные здесь системы и способы можно использовать в контексте службы электронной подписки. Пусть, например, пользователь (Алиса) желает получить подписку на джазовую музыку от поставщика услуг интернета (XYZ ISP). Поставщик услуг интернета может предлагать разнообразные варианты подписки, включающие в себя пробную подписку, не требующую оплаты,но которую можно использовать только для воспроизведения контента подписки пять раз до истечения срока (например, проиграть одну песню пять раз, проиграть пять разных песен по одному разу, и т.п.). Пробная подписка также может предусматривать обеспечение контента в слегка ухудшенной форме (например, с пониженным качеством звучания или разрешением). Алиса использует свой персональный компьютер для доступа к интернет-сайту поставщика услуг и выбирает пробную подписку. Тогда поставщик услуг создает объект связь 2400 и агент 2401 и передает их на персональный компьютер 2406- 29012918 Алисы. Агент 2401 способен инициализировать состояние защищенной базы данных состояний Алисы,которая будет использоваться для отслеживания, сколько раз Алиса использовала пробный контент. Связь 2400 идет от узла учетной записи ISP Алисы (AflncaXYZISP) 2402 к узлу подписки 2404 и включает в себя программу управления, которая, когда Алиса запрашивает воспроизведение фрагмента контента, проверяет текущее значение переменной состояния, заданной агентом 2401, чтобы определить,разрешены ли дополнительные воспроизведения. Когда Алиса загружает фрагмент контента на свой ПК и пытается воспроизвести его, механизмDRM на ее ПК оценивает лицензию, связанную с контентом, которая указывает, что узел подписки 2404 должен быть доступным для воспроизведения контента. Алиса ранее зарегистрировала свой ПК у своегоISP, и при этом получила связь 2405 от своего узла ПК 2406 к своему узлу учетной записи 2402. Таким образом, механизм DRM обладает объектами связь 2405, 2400, соединяющими узел ПК 2406 с узлом подписки 2404; однако, прежде чем удовлетворить запрос Алисы на воспроизведение контента, механизм DRM сначала определяет, действительны ли связи, выполняя любые программы управления, содержащиеся в связях. При выполнении программы управления в связи 2400, механизм DRM проверяет элемент базы данных состояний для определения, осуществлено ли воспроизведение 5 раз, и, если нет,удовлетворяет запрос на воспроизведение контента, но также выдает обязательство на приложение хоста. Обязательство требует, чтобы хост ухудшил контент до представления. Приложение хоста определяет,что оно способно выполнить это обязательство, и переходит к представлению контента. Для обеспечения Алисы предварительным просмотром контента до учета этого контента в отношении ее пятикратного пробного воспроизведения, программа управления должна также включать в себя обратный вызов, который проверяет, например, через 20 с после удовлетворения запроса на воспроизведение фрагмент контента, продолжается ли воспроизведение контента. Если контент все еще воспроизводится, счетчик воспроизведения уменьшается, а в противном случае - нет. Таким образом, Алиса может выбирать любые из элементов контента, предлагаемых службой подписки, и воспроизводить любые пять из них до истечения срока пробной подписки. По истечении срока пробной подписки Алисы, она решает приобрести полную, месячную подписку, которая позволяет ей воспроизводить столько элементов контента, сколько она желает, за месячную плату. Алиса использует свой ПК для заказа подписки и получает связь 2410 от своего узла учетной записи 2402 к узлу подписки 2404. Связь включает в себя программу управления, указывающую, что связь действительна только в течение одного месяца (например, программа управления проверяет элемент базы данных состояний, чтобы определить, истек ли месяц с момента выдачи связи). Эта связь 2410 передается на ПК Алисы совместно с программой-агентом, которая способна инициализировать соответствующий элемент базы данных состояний механизма DRM ПК, указывающий дату выдачи связи. Когда Алиса загружает фрагмент контента из службы подписки и пытается воспроизвести его, ее механизмDRM ПК определяет, что существует путь к узлу подписки, состоящий из связей 2405, 2410. МеханизмDRM выполняет любые программы управления, содержащиеся в связях 2405, 2410 для определения,действительны ли связи. Если с момента выдачи связи 2410 прошло меньше месяца, программа управления в связи 2410 возвращает результат, указывающий, что связь 2410 все еще действительна, и запрос Алисы на воспроизведение фрагмента контента удовлетворяется. Если Алиса пытается воспроизвести фрагмент контента, который она ранее получила в течение своего пробного периода, механизм DRM на ее ПК осуществляет такой же анализ и удовлетворяет ее запрос. Поскольку лицензия, связанная с фрагментом контента, полученная в течение пробного периода, указывает, что если переменна TrialState в защищенной базе данных не задана, то единственное условие состоит в том, что узел подписки должен быть доступным, Алиса может снова обратиться к этому контенту, поскольку узел подписки снова доступен от ПК Алисы, на этот раз через связь 2410, а не связь 2400, которая уже недействительна. Таким образом, Алисе не нужно получать вторую копию элемента контента для замены копии, которую она получила в течение бесплатного пробного предложения. Аналогично, если Алиса получает фрагмент контента подписки от своего друга Боба, который также подписался на ту же услугу, Алиса, в этом примере, тоже сможет воспроизводить этот контент, поскольку лицензия контента просто требует, чтобы узел подписки был доступен, не обязательно через ПК или учетную запись Боба. Очевидно, что вышеприведенные примеры призваны просто иллюстрировать некоторые функции,которые могут быть обеспечены описанными здесь системами и способами, и не призваны указывать,что подписки должны быть реализованы именно вышеописанным образом. Например, в других вариантах осуществления, лицензия, связанная с фрагментом контента подписки можно связывать с узлом пользователя, а не с узлом подписки, что препятствует двум подписчикам, например, Бобу и Алисе, совместно использовать контент, что возможно в вышеописанном примере. Очевидно, что возможны многие другие вариации вышеприведенных примеров. В нижеприведенной таблице представлен некоторый иллюстративный псевдокод для агента, связи и программ управления лицензии в вышеописанном примере: