Улучшенная система цифрового управления правами (drm)

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

 

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

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

Авторизованные домены

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

Конечно, возможны и другие контексты. Пользователь может, например, брать с собой в поездку переносное аудио- или видеоустройство для аудио и/или видеоконтента с ограниченным количеством контента и использовать его в своем гостиничном номере, чтобы осуществлять доступ или загружать дополнительный контент, хранящийся на его персональной аудио- и/или видеосистеме дома. Даже при том, что переносное устройство находится вне домашней сети, оно является частью авторизованного домена пользователя. Таким образом, авторизованный домен (AD) является системой, которая позволяет осуществлять доступ к контенту с помощью устройств, находящихся в домене, но не с помощью чего-либо иного.

Для авторизованных доменов необходимо решить такие проблемы, как идентификация авторизованного домена, регистрация входа устройства, регистрация выхода устройства, регистрация прав при входе, регистрация прав при выходе, регистрация контента при входе, регистрация контента при выходе, а также управление доменом. Для более полного ознакомления с использованием авторизованного домена и т.д. см. S.A.F.A. van den Heuvel, W.Jonker, F.L.A.J. Kamperman, P.J. Lenoir, "Secure Content Management in Authorised Domains", Philips Research, The Netherlands, IBC 2002 conference publication, pages 467-474, held at 12-16 September 2002 или Paul Koster, Frank Kamperman, Peter Lenoir and Koen Vrielink, "Identity based DRM: Personal Entertainment Domain", Conference on Communications and Multimedia Security (CMS) 2005, LNCS 3677, pp.42-54, Salzburg, Austria, September 19-21, 2005.

Некоторые формы разрешенных доменов

Существуют различные предложения, в некоторой степени реализующие концепцию авторизованных доменов. В так называемых основывающихся на устройствах доменах AD, домен формируется определенным набором аппаратурных устройств или приложений программного обеспечения (здесь далее упоминаемых вместе как клиенты) и контента. Менеджер или контроллер домена, которым может быть один или более клиентов, смарт-карта или другое устройство, управляет тем, какие клиенты могут присоединяться к домену. Только определенному набору клиентов в домене (членам) разрешается использовать контент данного домена, например, открывать, копировать, запускать или экспортировать его. Примеры таких AD, основывающихся на устройствах, приводятся в международной патентной заявке WO 03/098931 (номер в досье поверенного PHNL020455), международной патентной заявке WO 2005/088896 (номер в досье поверенного PHNL040288) и международной патентной заявке WO 04/027588 (номер в досье поверенного PHNL030283), поданных одним и тем же заявителем, каждая из которых включается сюда путем ссылки.

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

Другим типом AD является так называемый основывающийся на индивидуумах AD, где домен основывается на индивидуумах вместо устройств. Пример такой системы описан в международной патентной заявке WO 04/038568 (номер в досье поверенного PHNL021063) тем же самым заявителем, которая включена сюда ссылкой, в которой контент привязывается к индивидуумам, которые затем группируются в домен.

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

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

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

Примеры гибридных систем AD можно найти в международной патентной заявке WO 2005/010879 (номер в досье поверенного PHNL030926) и в международной патентной заявке WO 2005/093544 (номер в досье поверенного PHNL040315), которые обе включены сюда посредством ссылки.

Вообще говоря, AD содержит группу Клиентов. Клиент обычно является функциональным субъектом, который может приобретать и анализировать Лицензии (License) и привязки (Link) с целью получения доступа к экземпляру Контента (Сontent), основываясь на правах, выраженных в этих Лицензиях и привязках. Обычно Клиент воплощается как одно или более приложений программного обеспечения и/или аппаратурных компонент. Например, Клиент может обеспечиваться как приложение на устройстве типа мобильного телефона или портативного музыкального плеера. Клиент обычно содержит процессор, чтобы выполнять необходимые операции, и оснащен запоминающим устройством, чтобы сохранять Контент и/или команды, которые должны исполняться процессором. Клиенты, содержащиеся в AD, упоминаются как Клиенты-Члены или просто как Члены (Members) для краткости.

Контент делается доступным Клиентам-Членам одним или более Владельцами лицензии (LO). Владелец лицензии (License Owner), вообще говоря, является лицом, являющимся представителем Пользователя в окружении Домена (Domain). Пользователь является индивидуумом, который взаимодействует с системой. Пользователю могут предоставляться права на экземпляр Контента. Такое предоставление лицензии может быть представлено в системе путем предоставления Лицензии, которая привязывает (конкретный экземпляр) Контент к Владельцу лицензии. Владелец лицензии может быть реализован путем предоставления информации в структуре данных, записи в базе данных или программном объекте. Отношения с Пользователем в системе не определяются в явной форме, но могут, например, осуществляться Пользователем, имеющим Устройство, содержащее эту информацию.

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

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

право осуществлять доступ к части Контента "находится в собственности" у Владельца лицензии, и

этот Владелец лицензии ассоциирован с Доменом, и

Клиент является членом этого Домена.

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

Клиент -> Домен ->Владелец лицензии -> Контент

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

На фиг.1 схематично показана такая цепочка разрешений от Клиента до Контента, в которой каждое отношение может иметь множественность больше 1 в каждом направлении, как указано символом "*". Отношение между объектами Клиент, Домен, Владелец лицензии и Контент в конфигурации Домена могут быть выражены и квалифицированы в форме свидетельства, иногда также упоминаемого как (цифровой) сертификат. Могут использоваться следующие свидетельства:

• Право, которое конкретный Владелец лицензии имеет касаемо части Контента, выражается в Лицензии со ссылкой на Владельца лицензии, а также на часть оговариваемого Контента. Лицензия обычно реализуется как объект с цифровой подписью, содержащий соответствующую информацию в машиночитаемом формате. Такая Лицензия также содержит в себе конкретные разрешения и ограничивающие правила, выраженные в исполняемом коде Control (Контроль), хранящемся в так называемом объекте Control в Лицензии, которые должны быть оценены на момент желаемого доступа к Контенту. (Обратите внимание, что разрешения и ограничения могут быть также представлены на формальном языке представления прав, подобном, например, XrML). Разрешение, в положительной модели предоставления, как мы используем ее здесь, является индивидуальным правом, например "Play" (воспроизвести) или "Copy" (копировать), которое может ограничиваться одним или более ограничениями, например "only 10 times" (только 10 раз) или "not before 20:00 pm" (не раньше 20:00 часов" или "only on a Saturday" (только по субботам). Ограничение, используемое в комбинации с разрешением, обеспечивает условие, которое ограничивает использование разрешения. Каждое разрешение может иметь различные ограничения. Заметим, что каждая Лицензия имеет свой собственный набор разрешений и ограничений для этих разрешений (в объекте Control). Первоначальный поставщик услуг контента определяет в Лицензии разрешения, возможно дополненные множеством ограничений. Пользователь системы, потребитель, может пожелать добавить дополнительные ограничения к Лицензии для использования в "своем" Домене. Первоначальный поставщик услуг контента не устанавливает, например, ограничения, соответствующие водительскому контролю, но Владелец лицензии, который выпускает приобретенный им Контент в Домен, может захотеть это сделать. Как пример, Владелец лицензии определяет количество позиций Контента, которые не должны быть доступны раньше 22:00 часов, или позиции Контента, которые не должны быть доступны без некоторой надлежащей аутентификации пользователя, эксплуатирующего Клиент. Это ведет к различным областям контроля: одна - для поставщика услуг и одна - для Владельца лицензии (пользователя) с несколько различными характеристиками. Маловероятно, что параметры настройки поставщика услуг изменятся; Лицензия будет аннулироваться полностью, когда необходимо, приводя в результате к требованию аннулирования Лицензий. Владелец лицензии (пользователь), с другой стороны, может захотеть изменить свои ранее определенные ограничения, приводя в результате к требованию возможности передачи изменений Лицензии в систему.

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

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

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

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

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

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

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

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

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

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

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

Для запрещения возможности доступа в таком Домене конкретная часть Контента может быть организована с ограничением в Лицензии или посредством сообщения о действительности Лицензии Клиенту. Для запрещения возможности доступа в таком Домене любой Контент конкретного Владельца лицензии может быть организован с ограничением в Привязке Домен → Владелец лицензии (LinkLO) или путем сообщения о действительности Привязки Клиенту. Чтобы запретить отдельному Клиенту доступ к любому Контенту Домена, может быть выполнена подобная операция для Привязки Устройство → Домен (LinkC).

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

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

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

Недостатки, связанные с периодами действительности свидетельств.

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

2. Не все свидетельства на Клиенте будут блокироваться по истечении времени на Клиента одновременно, создавая у пользователя нежелательные впечатления, особенно когда Лицензии блокируются по истечении времени в различные моменты;

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

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

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

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

Это достигается способом, содержащим этапы, на которых:

аннулируют отношение членства, исполняя онлайновый протокол между контроллером домена и клиента, после чего они оба удаляют первую переменную состояния, и

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

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

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

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

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

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

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

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

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

ПОДРОБНОЕ ОПИСАНИЕ ПРЕДПОЧТИТЕЛЬНЫХ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ

На фиг.2 схематично показан пример системы 100, содержащей устройства 101-105 и индивидуумов 130, 131, образующих авторизованный домен (AD). Система 100, которая представляет типичную цифровую домашнюю сеть, содержит множество устройств, например радиоприемник, тюнер/декодер, проигрыватель компакт-дисков, пару громкоговорителей, телевизор, видеомагнитофон, цифровое записывающее устройство, мобильный телефон, кассетный магнитофон, персональный компьютер, персональный цифровой секретарь, мобильный дисплейный блок и так далее. Эти устройства соединены между собой через сеть 110, чтобы позволить одному устройству, например телевизору, управлять другим, например видеомагнитофоном. Одно устройство, такое как, например, тюнер/декодер или телевизионная приставка (STB), обычно является центральным устройством, обеспечивающим централизованное управление всеми остальными.

Контент, который обычно содержит такие вещи, как музыка, песни, кинофильмы, программы телевидения, картинки, игры, книги и тому подобное, но может также содержать интерактивные услуги, принимается через местный шлюз или телевизионную приставку телевидения 101. Контент может также поступать в дом через другие источники, такие как носители данных, подобные дискам, или используя мобильные устройства. Источником может быть соединение с широкополосной кабельной сетью, соединением с Интернет, нисходящей линией спутниковой связи и так далее. Контент может затем переноситься по сети 110 к получателю для воспроизведения. Получателем может быть, например, телевизионный дисплей 102, портативный дисплей 103, мобильный телефон 104 и/или воспроизводящее аудиоустройство 105.

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

Телевизионная приставка 101 или любое другое устройство в системе 100 может содержать носитель S1 данных, такой как жесткий диск надлежаще большой емкости, позволяющий запись и последующее проигрывание принятого контента. Носитель S1 данных может быть персональным цифровым записывающим устройством (PDR) некоторого вида, например, записывающим устройством DVD+RW, к которому телевизионная приставка 101 подсоединена. Контент может также вводиться в систему 100 сохраненным на носителе 120 типа компакт-диска (CD) или цифрового универсального диска (DVD).

Портативный дисплей 103 и мобильный телефон 104 подсоединяются беспроводным способом к сети 110, используя точку 111 беспроводного доступа, например, используя Bluetooth или IEEE 802.11b/g. Другие устройства подсоединяются, используя традиционное проводное подключение. Чтобы позволить устройствам 101-105 взаимодействовать, предлагаются несколько стандартов взаимодействия, которые позволяют различным устройствам обмениваться сообщениями и информацией и управлять друг другом. Одним из известных стандартов является Universal Plug and Play (http://www.upnp.org).

В одном примерном сценарии, по меньшей мере, один из пользователей 130, 131 привязан к Разрешенному Домену в дополнение к одному или более устройствам 101-105. В необязательном порядке некоторое количество позиций контента (не показаны) также могут быть привязаны к авторизованному Домену. Эта привязка пользователей и/или контента может делаться способом, раскрытым в международной патентной заявке WO 04/038568 (номер в досье поверенного PHNL021063), способом, раскрытым в международной патентной заявке WO 2005/010879 (номер в досье поверенного PHNL030926), или способом, описанным в международной патентной заявке с серийным номером IB2005/050910 (номер в досье поверенного PHNL040315).

Часто бывает важно гарантировать, что устройства 101-105 в домашней сети не делают неавторизованных копий контента. Чтобы это сделать, необходима цифра структура защиты, обычно упоминаемая как система Цифрового Управления Правами (DRM). Один из способов защиты контента в форме цифровых данных состоит в том, чтобы гарантировать, что контент будет передаваться только между устройствами 101-105, если

• приемное устройство было аутентифицировано как совместимое устройство, и

• пользователь контента имеет право переносить (перемещать и/или копировать) этот контент на другое устройство.

Если перенос контента разрешен, он обычно будет выполняться зашифрованным способом, чтобы гарантировать то, что контент не может быть незаконно перехвачен в удобном формате через транспортный канал, такой как шина между дисководом CD-ROM и персональным компьютером (Хостом).

Аутентификация члена AD

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

Чтобы гарантировать правильность открытого ключа и проверить, является ли пара ключей законной парой сертифицированного устройства, открытый ключ сопровождается сертификатом, который в цифровой форме подписан Органом Сертификации (CA), организацией, которая управляет распространением пар открытых/личных ключей для всех устройств. Любой знает открытый ключ CA и может использовать его для проверки подписи СА на сертификате. В простой реализации открытый ключ СА жестко программируется в реализации устройства.

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

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

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

Клиент, например любое из устройств 102-105, и контроллер домена, например телевизионная приставка 101, вместе поддерживают первую переменную состояния, которая отражает отношение членства клиента в Домене. Точно также контроллер домена и контроллер владельца лицензии, ассоциированный с владельцем лицензии, вместе поддерживают вторую переменную состояния, которая отражает отношение ассоциациативной связи между владельцем лицензии и доменом. Контроллером Владельца лицензии является, например, смарт-карта, принадлежащая пользователю, представляемому Владельцем лицензии.

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

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

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

Заметим, что различные субъекты, такие как Клиент, контроллер Домена и контроллер владельца лицензии, могут быть реализованы как модули аппаратного и/или программного обеспечения в едином устройстве. Телевизионная приставка 101, например, была описана выше как контроллер Домена, но, конечно, она может также работать как Клиент, когда ей требуется осуществить доступ к определенному контенту.

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

В другом варианте осуществления контроллер Домена и контроллер Владельца лицензии оба реализованы в (центральном) устройстве в доме, например в телевизионной приставке 101. В необязательном порядке, эти два контроллера могут быть реализованы как два отдельных устройства. Другие устройства 102-105 в доме работают как Клиенты. В этом сценарии Контент, когда он получен, находится под контролем пользователя, конечно, в пределах ограничений, установленных в соответствии с Лицензией и любыми ограничениями, налагаемыми Привязками в AD.

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

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

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

1. МЕХАНИЗМЫ, ИСПОЛЬЗУЕМЫЕ В НАСТОЯЩЕМ ИЗОБРЕТЕНИИ

1.1. Отдельное состояние для отношения

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

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

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

1.2. Периоды действительности для Привязки

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

1.3. Быстрая передача Привязок Домена, придаваемых к Лицензиям, к неподсоединенным Клиентам

Когда действительность Привязки в Домене не охраняется отдельным состоянием для отношения, Привязка (свидетельство) само по себе может обеспечить доказательство действительности. Такие Привязки, каждая из которых описывает часть конфигурации Домена, могут придаваться к Лицензиям, когда они выдаются. Для системы выгодно, когда эта потенциально новая информация о конфигурации Домена прибывает к Клиенту и может немедленно использоваться для доступа к Контенту без необходимости в онлайновых протоколах между сторонами. Этот механизм может, например, использоваться для придания LinkLO Владельца лицензии Лицензиям, выданным этим Владельцем Лицензии.

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

Этот механизм не будет работать, когда механизм 1.1 "Отдельное состояние для отношения" используется для Привязки, но он может работать вместе с механизмами 1.4 "Номер конфигурации для отношений по состоянию" и 1.5 "Номер Конфигурации для отношений по Привязкам".

1.4. Номер конфигурации для отношений по состоянию

В механизме состояний 1.1 "Отдельное состояние для отношения" значение состояния представляет одно единственное отношение. Номер конфигурации представляет неявную совокупность отношений, которые обрабатываются одинаково в отношении аннулирования. Только, когда отношение удаляется из совокупности, номер Конфигурации увеличивается, указывая, что не все отношения, ранее являвшиеся частью совокупности, все еще остаются действительными. Добавление нового отношения к совокупности не будет увеличивать номер, потому что нас интересует только аннулирование. Свидетельством задействуемых отношений в качестве атрибута придается фактическое значение номера Конфигурации на момент, когда они выпущены, и в их коде Control добавляется условие, указывающее, что значение номера Конфигурации в свидетельстве равно или больше, чем значение номера Конфигурации в администрировании состояний оценивающего субъекта (обычно Клиента). Когда это условие не выполняется, отношение расценивается как недействительное.

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

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

1.5. Номер Конфигурации для отношений по Привязкам

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

Условие для проверки номера конфигурации, приданного в качестве атрибута свидетельству задействуемых отношений, относительно фактического значения номера конфигурации добавляется к коду Control Привязки. Эта Привязка будет достигать Клиентов вовремя, придерживаясь периода действительности, установленного для привязки. Во время оценки на Клиент пути к владельцу лицензии, на которого нацелена Лицензия, Привязка будет оцениваться и значение номера Конфигурации в Привязке будет сравниваться со значением номера конфигурации в свидетельстве задействуемого отношения (обычно Лицензии). Номер в свидетельстве должен быть равен или быть больше, чем значение номера в Привязке. Заметим, что этот механизм не страдает неспособностью вводить отношения на Клиентах посредством свидетельств без подсоединения клиента, потому что не имеется никакой вовлеченной операции с состоянием.

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

1.6. Номер версии для отношения по состоянию

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

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

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

Предпосылкой для этого механизма является использование механизма 1.1 "Отдельное состояние для отношения", механизма для отношения, управляемого версией.

1.7. Номер версии для отношения по Привязкам

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

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

Условие для проверки номера Версии, приданного в качестве атрибута свидетельству задействуемых отношений, относительно фактического значения номера Версии добавляется к коду Control Привязки. Эта привязка будет достигать Клиентов вовремя, придерживаясь периодам действительности, установленного для Привязки. Во время оценки на Клиенте пути к Владельцу лицензии, на которого нацелена Лицензия, привязка будет оцениваться и значение номера Версии оцениваемого отношения в привязке будет сравниваться со значением номера Версии в свидетельстве задействуемого отношения (обычно Лицензии). Заметим, что этот механизм не страдает неспособностью вводить отношения на клиентах посредством свидетельств без подсоединения клиента, потому что не задействуются никакие операции, связанные с состоянием.

1.8. Параллельное связывание лицензий для разделения зон управления

В основной концепции действительный путь к Владельцу лицензии должен быть подтвержден и разрешения и ограничения в лицензии, нацеленной на владельца лицензии, должны выполняться. Дополнительное определяемое пользователем ограничение в этой концепции должно добавляться в код Control в Лицензии. Используя параллельное связывание лицензий, эти определяемые пользователем ограничения отделяются от ограничений, установленных в коде Control в Лицензии. Когда приобретается Лицензия, Лицензия, нацеленная на Владельца лицензии, явно связывается с "новой" привязкой LinkLic от Владельца лицензии к Лицензии. Заметим, что LinkLic не должна иметь дело с множественностью отношений Контент-Лицензия, поскольку это должно относиться к Лицензии.

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

Аннулирование отношения Контент-Владелец лицензии может быть сделано с помощью одного или комбинации доступных механизмов аннулирования. Заметим, что теперь существуют 2 свидетельства (Лицензия и LinkLic) для одного отношения. Оба эти параллельные свидетельства должны быть доступны и действительны, чтобы иметь возможность доступа к контенту на Клиенте. Когда одно из свидетельств блокируется, отношение аннулируется. Управление Версиями, обычно требующееся для определяемых пользователем ограничений, может теперь выборочно применяться к LinkLic, содержащей определяемые пользователем ограничения.

1.9. Последовательное связывание Лицензий для разделения областей управления

В основной концепции действительный путь к Владельцу лицензии должен быть подтвержден, и разрешения и ограничения, содержащиеся в Лицензии, нацеливаемой на владельца лицензии, должны быть выполнены. Дополнительное определяемое пользователем ограничение в этой концепции должно добавляться к коду Control в Лицензии. Используя последовательное связывание Лицензий, эти определяемые пользователем ограничения отделяются от ограничений, установленных в коде Control в Лицензии. Лицензия больше не нацелена на Владельца лицензии; она только ссылается на позицию(-и) Контента и содержит разрешения и ограничения, установленные первоначальным поставщиком услуг контента. Лицензия больше не представляет полное отношение между Контентом и Владельцем лицензии. Отношение с Владельцем лицензии устанавливается и представляется "новым" привязкам связи LinkLic от Владельца лицензии к Лицензии, когда Владельцу лицензии предоставляют доступ к Контенту. Заметим, что для LinkLic нет необходимости иметь дело с множественностью отношения Контент-Лицензия; это все еще делается в соответствии с Лицензией. Проверка в Лицензии теперь станет такой, что должен быть представлен действительный путь (цепочку Привязок) от оценивающего Клиента к Лицензии. Определяемые пользователем ограничения теперь добавляются к коду Control в LinkLic вместо кода Control в Лицензии. В результате, код Control Лицензии не требуется изменять, когда пользователь хочет добавить или изменить определяемые пользователем ограничения, разделяющие области управления и решающие проблемы безопасности, которые возникают, когда все ограничения объединяются в едином коде Control.

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

Заметим, что теперь имеются 2 свидетельства (Лицензия и LinkLic), требующихся для одного отношения, где Лицензия имеет дело с частью "Контент" отношения, а LinkLic имеет дело с частью "Владелец лицензии" отношения. Оба эти последовательные свидетельства должны быть доступны и быть действительны, чтобы иметь возможность доступа к Контенту на Клиенте. Когда одно из свидетельств блокируется, отношение аннулируется. Управление Версиями, обычно требуемое для определяемых пользователем ограничений, может теперь выборочно применяться к LinkLic, содержащему определяемые пользователем ограничения.

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

1.10. Переопределение Лицензии для разделения областей управления

С помощью механизмов 1.8 "Параллельное связывание Лицензий для разделения областей управления" и 1.9 "Последовательное связывание лицензий для разделения областей управления" описываются способы разделения областей управления, используя существующие элементы Лицензия и Привязка. Альтернативой этого подхода является определение нового элемента, который объединяет в себе описанное поведение Лицензии и LinkLic. Поскольку Лицензия и LinkLic всегда появляются в комбинации, этот новый элемент может быть заменой комбинации двух других. Эта альтернатива может также быть представлена как переопределение элемента лицензии, поддерживающего два кода Control внутренне с двумя различными областями управления; одна для содержания в ней разрешений и ограничений, как установлено исходным поставщиком услуг контента, и одна для ограничений, которые могут добавляться пользователем. В этом случае должна использоваться первоначальная проверка, что должен существовать действительный путь из Привязок к Владельцу лицензии. Эта альтернатива охватывает оба механизма, поскольку как параллельная, так и последовательная структура могут быть заменены единым новым элементом.

2. ПРЕДПОЧТИТЕЛЬНЫЕ ВАРИАНТЫ ОСУЩЕСТВЛЕНИЯ

Представленные варианты осуществления используют следующие отправные точки:

по отдельным лицензиям отсутствуют периоды действительности;

требуется использование Привязок;

Клиентам может быть предоставлено свидетельство из любого источника, но обычно лицензии будут предоставляться Владельцем лицензии, а привязки Домена LinkC и LinkLO обеспечиваются Доменом;

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

используя периоды действительности для Привязок, где период действительности для LinkLO принимается большим, но не обязательно, чем период действительности для LinkC.

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

Механизмы могут также использоваться в вариантах осуществления, которые не используют вышеупомянутые варианты. Например:

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

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

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

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

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

Сплошные линии между субъектами в цепочке авторизации представляют отношения между ними; остальные сплошные линии указывают ассоциативные связи между атрибутами;

Пунктиры указывают представление свидетельств отношений;

Множественность для атрибутов обозначается как "*", в то время как множественность для отношений на чертежах не указывается;

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

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

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

Свидетельства (копии), которые представлены/должны быть представлены, но не обязательно должны управляться защищенным образом, на хостах субъектов не указываются на чертежах.

Идентификатор Клиента ClientId, идентификатор Домена DomainId, идентификатор Владельца лицензии LicenseOwnerId и идентификатор Лицензии LicenseId используются в качестве переменных состояния для ссылки на их соответствующий субъект, но на чертежах они не показаны как атрибуты этих субъектов.

2.1. Отсутствие принуждения со стороны периодов действительности

Этот вариант осуществления показан на фиг.3. Применяемые механизмы:

Механизм	Используется для:
1.3 - Быстрая передача Привязок Доменов, придаваемых к Лицензиям, неподсоединенным Клиентам	Передача всех Привязок LinkLO и LinkC в конфигурации Домена Клиентам
1.5 - Номер Конфигурации для отношений по Привязкам	Охрана состояния LinkC, LinkLO и всех Лицензий Владельца лицензии (2 раза в каскаде)

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

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

Текущее значение номера domainConfigNr ассоциировано с LinkC и LinkLO с помощью Домена и с Лицензиями, вновь выданными Домену Владельцем Лицензий, например, посредством записи этого значения в подписанный объект, представляющий LinkC и LinkLO.

Номер DomainConfigNr должен сначала быть сообщен в протоколе Владельцу лицензии, который защищенно управляет самым последним номером domainConfigNr для каждого ассоциированного Домена, чтобы иметь возможность выпустить новую Лицензию с обновленным номером domainConfigNr.

После приращения номера LicenceConfigNr у Владельца лицензии Владелец лицензии, прежде, чем новые Лицензии смогут быть выпущены, должен дождаться связи с Доменом, чтобы принять самый последний номер domainConfigNr вместе с самыми последними Привязками Домена.

Все LinkLO и LinkC, которые известны Владельцу лицензии, придаются к Лицензии, когда она выпускается в Домен. Владелец лицензии принимает эти привязки в протоколе с Доменом.

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

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

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

Это решение не реализует немедленное аннулирование свидетельств на клиенте, но к моменту, когда Контент Домена прибывает, Клиент будет соответствовать новой информации.

Особенности решения:

Аспект/действие
Новые привязки к Клиенту с офлайновым Доменом и/или Владельцем Лицензии	Все Привязки, приданные лицензии, передаваемой Клиенту без необходимости в онлайновом Домене или Владельце Лицензии. Никакое соединение между Клиентом и Доменом не требуется.
Неподсоединенный Владелец лицензии	Отношение ассоциативной связи будет сохраняться навсегда (после того, как Домен решит прекратить его) с точки зрения Владельца лицензии. С точки зрения Клиентов, ассоциативная связь может закончиться при столкновении с лицензией, выданной другим Владельцем Лицензии, ассоциированным с Доменом с более высоким domainConfigNr. Не имеется никакого гарантируемого прекращения доступа к Контенту на Клиентах.
Неподсоединенный Клиент	Отношение членства будет сохраняться (после того, как Домен решит закончить его) с точки зрения Клиента, пока Лицензия не будет предоставлена с более высоким номером domainConfigNr. Не имеется никакого гарантируемого прекращения доступа к Контенту на Клиентах.
Снятие Клиента с регистрации в Домене	Клиент немедленно прекратит доступ к любому Контенту Домена. Все остающиеся Привязки должны быть обновлены.
Отключение Владельца лицензии от Домена	Пока Клиенты не войдут в контакт с Доменом или не столкнутся с Лицензией, выданной другим Владельцем Лицензии, ассоциированным с Доменом с более высоким номером domainConfigNr, Контент деассоциированного Владельца лицензии будет доступен. Все остающиеся Привязки должны быть обновлены.
Удаление Лицензии у Владельца лицензии	Пока Владелец лицензии не войдет в контакт с Доменом и впоследствии Клиенты не войдут в контакт с Доменом или не столкнутся с лицензией, выданной удаляющим владельцем лицензии или другим владельцем лицензии, ассоциированным с Доменом, который контактировал с Доменом после удаления, с более высоким номером domainConfigNr, Контент по удаленной Лицензии будет доступен. Все остающиеся лицензии всех владельцев лицензии должны быть обновлены. Все Привязки должны быть обновлены.
Изменение Лицензии (определяемые пользователем ограничения)	Приращение номера LicenceConfigNr, как если бы Лицензия была удалена.
Размер защищенного администрирования состояний Клиента	#domains* (DomainId + domainConfigNr)

2.2. Отсутствие состояния на Клиенте

Этот вариант осуществления показан на фиг.4. Применяемые механизмы:

Механизм	Используется для
1.2 - Периоды действительности для Привязки	Охраны LinkC и LinkLO и принуждение к передаче LicenceConfigNr.
1.3 - Быстрая передача Привязок Домена, приложенных к Лицензиям, неподсоединенным Клиентам	Передачи LinkLO Владельца лицензии и всех привязок LinkC в конфигурации Домена Клиентам.
1.5 - Номер Конфигурации для отношений по Привязкам	Охраны состояния всех Лицензий Владельца лицензии.

Владелец лицензии имеет номер licenseConfigNr, который увеличивается, когда любая из лицензий, нацеленная на этого владельца лицензии, изменяется или удаляется, указывая изменение одной из Лицензий. Когда владелец лицензии выпускает лицензию в Домен, владелец лицензии придает лицензии в качестве атрибута текущее значение licenseConfigNr. Текущее значение licenseConfigNr также придается в качестве атрибута LinkLO. Этот номер licenseConfigNr должен сначала быть сообщен в протоколе Домену, который надежно управляет самым последним номером licenseConfigNr для каждого ассоциированного Владельца лицензии, чтобы иметь возможность выпустить новую Привязку LinkLO с обновленным licenseConfigNr. Control в LinkLO во время оценки пути будет выполнять проверку номера licenseConfigNr, приданного в качестве атрибута лицензии, относительно номера, приданного в качестве атрибута LinkLO.

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

Заметьте, что когда LinkLO выдана не Доменом, а Владельцем Лицензии, Владелец лицензии не должен сообщать licenseConfigNr Домену и Домен не должен администрировать licenseConfigNr. В этом случае Владелец лицензии выдает LinkLO непосредственно с текущим licenseConfigNr.

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

Особенности решения:

Аспект/действие
Новые привязки к Клиенту с офлайновым Доменом и/или владельцем лицензии	Одна LinkLO и все LinkC, приданные Лицензии, передаются Клиенту без необходимости в онлайновом Домене или Владельце Лицензии.
Неподсоединенный Владелец лицензии	Нарушенное отношение и отсутствие доступа к Контенту после истечения срока действительности текущего LO-validityperiod.
Неподсоединенный Клиент	Нарушенное отношение и отсутствие доступа к Контенту после истечения срока действительности LO-validityperiod для Владельца лицензии или C-validityperiod.
Снятие Клиента с регистрации в Домене	Ожидать до истечения текущего периода C-validityperiod, чтобы Контент Домена стал доступным.
Деассоциирование владельца лицензии от Домена	Ожидать остальной части текущего периода LO-validityperiod до того, как Клиенты больше не смогут осуществлять доступ к любому Контенту Домена деассоциированного Владельца лицензии. Никакое обновление Привязок не требуется.
Удаление Лицензии у Владельца лицензии	Ожидать остальной части текущего периода LO-validityperiod до того, как Клиенты больше не смогут осуществлять доступ к любому Контенту по удаленной Лицензии. Все остающиеся Лицензии Владельца лицензии должны быть обновлены. Только LinkLO должна быть обновлена.
Изменение Лицензии (определяемые пользователем ограничения)	Увеличивает LicenceConfigNr, как если бы Лицензия была удалена.
Размер защищенного администрирования состояний Клиента	0

2.3. Отдельное состояние для LinkC

Этот вариант осуществления показан на фиг.5. Применяемые механизмы:

Механизм	Используется для
1.1 - Отдельное состояние для отношения	Охраны состояния LinkC.
1.2 - Периоды действительности для Привязки	Охраны LinkC и LinkLO, принуждения к передаче liсenseConfigNr и принуждения к обмену информацией между Владельцем Лицензии и Доменом и принуждения к обмену информацией о конфигурации Домена между Клиентом и Доменом.
1.3 - Быстрая передача Привязок Домена, приложенных к Лицензиям, неподсоединенным Клиентам	Передачи LinkLO для владельца лицензии на Клиенты.
1.5 - Номер Конфигурации для отношений по Привязкам	Охраны состояния всех Лицензий Владельца лицензии.

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

Номер licenseConfigNr используется для охраны состояния всех Лицензий Владельца лицензии, а период действительности на LinkLO охраняет действительность LinkLO, как описано в решении 2.2 "Отсутствие состояния на Клиенте".

Только LinkLO, как известно Владельцу лицензии, придается Лицензии, когда она выпускается в Домен. Владелец лицензии принимает эту Привязку в протоколе с Доменом. Поскольку распространение LinkLO, приданного Лицензии, является необязательной альтернативой сверх стандартного распространения от Домена Клиентам, является необязательным, должен ли или нет Владелец лицензии после приращения licenseConfigNr у Владельца лицензии ждать связи с Доменом, чтобы принять LinkLO с обновленным licenseConfigNr.

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

Отношение членства между Клиентом и Доменом определяется механизмом отдельного состояния. Членство может быть установлено, только используя протокол между этими 2 сторонами, и они обе администрируют этот факт в переменной состояния (DomainId для Клиента). LinkC выдается с периодом действительности. LinkC теперь действительна только тогда, когда период действительности не истек и переменная состояния DomainId, связанная с членством LinkC у Клиента, все еще присутствует. Это проверяется в коде Control привязки LinkC, когда оценка LinkC ищет путь к Владельцу лицензии, как это требуется в оцениваемой лицензии. Отношение членства может аннулироваться в онлайновом протоколе между Доменом и Клиентом, где они оба соглашаются прекратить членство и каждый удаляет соответствующую переменную состояния из своего администрирования. Как следствие, LinkC блокируется на Клиенте, потому что там более не существует никакой соответствующей переменной состояния.

LinkLO выдается с периодом действительности. LinkLO теперь действительна только тогда, когда период действительности не истек и переменная состояния DomainId, связанная с членством у Клиента, все еще присутствует. Это проверяется в коде Control привязки LinkLO, когда оценка LinkLO ищет путь к владельцу лицензии. Control в LinkLO во время оценки пути будет выполнять проверку номера licenseConfigNr, приданного Лицензии в качестве атрибута с номером, приданным в качестве атрибута LinkLO.

Заметим, что DomainId Привязок Домена может быть получен из их администрирования неявным указанием, но более устойчивое решение состоит в том, чтобы придать каждой привязке для Домена DomainId в качестве атрибута. Это, однако, не показано на чертеже.

Особенности решения:

Аспект/действие
Новые привязки к Клиенту с офлайновым Доменом и/или Владельцем Лицензии	LinkLO, приложенная к Лицензии, передается Клиенту без необходимости в онлайновом Домене или Владельце Лицензии.
Неподсоединенный Владелец лицензии	Нарушенное отношение и отсутствие доступа к Контенту после истечения срока действительности текущего LO-validityperiod.
Неподсоединенный Клиент	Нарушенные отношения и отсутствие доступа к Контенту после истечения срока действительности текущего LO-validityperiod для Владельца лицензии или C-validityperiod.
Снятие Клиента с регистрации в Домене	Клиент немедленно перестанет осуществлять доступ к любому Контенту Домена
Деассоциирование Владельца лицензии от Домена	Ожидать в течение оставшейся части текущего периода LO-validityperiod до того, как Клиенты больше не смогут осуществлять доступ к любому Контенту Домена деассоциированного Владельца лицензии. Никакое обновление Привязок не требуется.
Удаление Лицензии у Владельца лицензии	Ожидать в течение оставшейся части текущего периода LO-validityperiod до того, как Клиенты больше не смогут осуществлять доступ к любому Контенту по удаленной Лицензии. Все остающиеся Лицензии Владельца лицензии должны быть обновлены. Только LinkLO должна быть обновлена.
Изменение Лицензии (определяемые пользователем ограничения)	Увеличивает LicenceConfigNr, как если бы Лицензия была удалена.
Размер защищенного администрирования состояний Клиента	#domains*DomainId

2.4. Отдельное состояние для LinkC и состояние Домена для LinkLO

Этот вариант осуществления показан на фиг.6. Применяемые механизмы:

Механизм	Используется для
1.1 - отдельное состояние для отношения	Охраны состояния LinkC.
1.2 - Периоды действительности для Привязки	Охраны LinkC и LinkLO, принуждения к передаче liсenseConfigNr, принуждения к обмену информацией между Владельцем Лицензии и Доменом и принуждения к обмену информацией о конфигурации Домена между Клиентом и Доменом.
1.3 - Быстрая передача Привязок Домена, приложенных к Лицензиям, неподсоединенным к Клиентам	Передачи LinkLO для Владельца лицензии на Клиенты.
1.4 - Номер Конфигурации для отношений по состоянию	Охраны состояния LinkLO и LinkC с помощью domainConfigNr
1.5 - Номер Конфигурации для отношений по Привязкам	Охраны состояния всех Лицензий Владельца лицензии.

Заметим, что имеется локальное состояние между Владельцем лицензии и Доменом, но это не приводит к отдельному состоянию, администрируемому Клиентом; только в объединенном состоянии domainConfigNr. Отношение ассоциативной связи может аннулироваться в онлайновом протоколе между Доменом и Владельцем лицензии, где они оба соглашаются прекратить ассоциативную связь и каждый удаляет соответствующую переменную состояния из своего администрирования.

Владелец лицензии имеет номер licenseConfigNr, который увеличивается, когда любая из Лицензий, нацеленных на этого Владельца лицензии, изменяется или удаляется, указывая на изменение одной из Лицензий. Когда владелец лицензии выпускает Лицензию в Домен, Владелец лицензии придает лицензии текущее значение licenseConfigNr в качестве атрибута. Текущее значение licenseConfigNr также придается в качестве атрибута LinkLO. Поскольку мы предполагаем, что Домен должен выпустить привязки LinkLO, этот licenseConfigNr должен сначала быть сообщен в протоколе Домену, который защищенно управляет самым последним licenseConfigNr для каждого ассоциированного Владельца лицензии, чтобы иметь возможность выдать новое LinkLO с обновленным licenseConfigNr. Control в LinkLO во время оценки пути будет выполнять проверку номера licenseConfigNr, приданного в качестве атрибута Лицензии, сравнивая его с номером, приданным в качестве атрибута LinkLO.

LinkLO, как известно Владельцу лицензии, прилагается к Лицензии, когда она выдается Домену. Владелец лицензии принимает эту привязку в протоколе с Доменом. Поскольку распространение LinkLO, приложенного к Лицензии, является необязательной альтернативой сверх стандартного распространения от Домена к Клиентам, Владельцу лицензии необязательно после приращения licenseConfigNr у Владельца ждать связи с Доменом, чтобы принять LinkLO с обновленным licenseConfigNr.

Отношение членства между Клиентом и Доменом определяется механизмом отдельного состояния. Членство может устанавливаться, только используя протокол между этими двумя сторонами, и они обе администрируют этот факт в переменной состояния (DomainId для Клиента). LinkC выдается с периодом действительности. LinkC теперь действительна только тогда, когда период действительности не истек и переменная состояния DomainId, связанная с членством LinkC у Клиента, все еще присутствует. Это проверяется в коде Control привязки LinkC, когда оценка LinkC ищет путь к владельцу лицензии, как требуется в оцениваемой Лицензии.

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

Домен управляет номером domainConfigNr, который увеличивается, когда изменяется любое из отношений в конфигурации Домена. Этими изменениями являются: приращение LicenceConfigNr любого из владельцев лицензии, ассоциированного с Доменом, изменение или удаление любой из ассоциативных связей Владельцев лицензии с Доменом, и изменение или удаление любого из членств Клиентов в Домене. Домен придает текущее значение domainConfigNr в качестве атрибута LinkC и LinkLO.

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

Клиенты управляют переменной состояния domainConfigNr для каждого Домена, членом которого они являются. Эта переменная состояния обновляется в онлайновом протоколе между Клиентом и Доменом.

Привязки у Клиента теперь действительны только тогда, когда их период действительности не истек и переменная состояния DomainTd, связанная с членством LinkC у Клиента, все еще присутствует и их значение domainConfigNr не ниже значения в администрировании состояния Клиента. Это проверяется в коде Control Привязок, когда оценка Привязок ищет путь Владельца лицензии, как требуется в Лицензии при оценке. Control в LinkLO также должен выполнить проверку номера LicenceConfigNr, приданного Лицензии в качестве атрибута, сравнив его с номером, приданным в качестве атрибута LinkLO.

Заметим, что теперь имеется двойное администрирование состояний для LinkC: одно с отдельным состоянием (DomainId у Клиента) и одно через domainConfigNr. Альтернативной конфигурацией может быть LinkC без domainConfigNr в качестве атрибута и отсутствие проверки LinkC со сравнением domainConfigNr в администрировании состояний Клиента. Поведение подобно, но для LinkC нет необходимости выдаваться при каждом изменении domainConfigNr.

Заметим, что идентификатор DomainId привязок Домена может быть получен от администрирования с неявным указанием, но более надежное решение состоит в том, чтобы придать каждой привязке для Домена DomainId в качестве атрибута. Это, однако, не показано на чертеже.

Клиенты и Владельцы лицензии принуждаются периодами действительности на LinkLO и LinkC сообщать на регулярной основе повторное подтверждение их отношений с Доменом и принимать обновленную информацию о конфигурации Домена. Эти периоды действительности указаны на чертеже как LO-validityperiod и C-validityperiod, соответственно.

Особенности решения:

Аспект/действие
Новые привязки к Клиенту с офлайновым Доменом и/или Владельцем лицензии	Привязка LinkLO, приложенная к Лицензии, передается Клиенту без необходимости в онлайновом Домене или Владельце лицензии.
Неподсоединенный Владелец лицензии	Нарушенное отношение и отсутствие доступа к Контенту после истечения срока действительности текущего LO-validityperiod.
Неподсоединенный Клиент	Нарушенные отношения и отсутствие доступа к Контенту после истечения срока действительности текущего LO-validityperiod для Владельца лицензии или C-validityperiod.
Снятие Клиента с регистрации в Домене	Клиент немедленно перестанет осуществлять доступ к любому Контенту Домена. Все остающиеся Привязки должны быть обновлены.
Деассоциирование Владельца лицензии от Домена	Ожидать в течение min.(оставшейся части текущего периода LO-validityperiod, max.(оставшихся частей текущих периодов LO-validityperiod)), прежде чем все Клиенты перестанут осуществлять доступ к любому Контенту деассоциированного владельца лицензии. Все остающиеся Привязки должны быть обновлены (альтернативно, только все привязки LinkLO)
Удаление Лицензии у Владельца лицензии	Ожидать в течение (если Владелец лицензии и Домен подсоединены: min.(оставшейся части текущего периода LO-validityperiod, max.(оставшихся частей текущих периодов LO-validityperiod)), иначе оставшейся части текущего периода LO-validityperiod), прежде чем Клиент перестанет осуществлять доступ к Контенту отключенной Лицензии. Все остающиеся Лицензии у Владельца лицензии должны быть обновлены. Все привязки должны быть обновлены (альтернативно, только все привязки LinkLO).
Изменение Лицензии (определяемые пользователем ограничения)	Увеличивает LicenceConfigNr, как если бы Лицензия была удалена.
Размер администрирования безопасных состояний Клиента	#domains*(DomainId + domainConfigNr)

2.5. Отдельное состояние для LinkC и LinkLO

Этот вариант осуществления показан на фиг.7. Применяемые механизмы:

Механизм	Используется для
1.1 - Отдельное состояние для отношения	Охраны состояния LinkC и LinkLO.
1.2 - Периоды действительности для Привязки	Охраны LinkC и LinkLO, принуждения к передаче liсenseConfigNr, принуждения к обмену информацией между Владельцем лицензии и Доменом и принуждения к обмену информацией о конфигурации Домена между Клиентом и Доменом.
1.4 - Номер Конфигурации для отношений по состоянию	Охраны состояния всех Лицензий Владельца лицензии с помощью licenseConfigNr в состоянии Домена и состоянии Клиента.

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

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

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

Отношение членства между Клиентом и Доменом определяется механизмом отдельного состояния. Членство может быть установлено, только используя протокол между этими двумя сторонами и они обе администрируют этот факт в переменной состояния (DomainId для Клиента и ClientId для Домена).

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

Привязки Домена могут достигать Клиента путем прямой связи между Доменом и Клиентом. Привязки у Клиента теперь действительны только тогда, когда их период действительности не истек и переменная состояния DomainId, связанная с членством, все еще присутствует в администрировании состояний Клиента. Это проверяется в коде Control Привязок, когда оценка Привязок ищет путь к владельцу лицензии, как это требуется в оцениваемой лицензии. Control привязки LinkLO будет выполнять дополнительные проверки на предмет того, что LicenseOwnerId для LinkLO все еще зарегистрирован как ассоциированный в администрировании состояний Клиента и что значение licenseConfigNr оцениваемой лицензии равно или больше значения в администрировании состояний Клиента.

Заметим, что идентификатор DomainId Привязок Доменов может быть получен из их администрирования по неявному указанию, но более надежное решение состоит в том, чтобы придать каждой привязке для Домена DomainId в качестве атрибута. То же самое относится к добавлению явного LicenseOwnerId к LinkLO. Это, однако, не показано на чертеже.

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

Так как отношение ассоциативной связи (LinkLO), по сравнению с решением 2.4 "Отдельное состояние для LinkC и состояние Домена для LinkLO", теперь охраняется с помощью отдельной переменной состояния в Клиенте, он не использует добавление LinkLO к Лицензии, потому что Клиент, который приобретает Лицензию, не может использовать LinkLO самостоятельно, чтобы установить доказательство ассоциативной связи; это может быть сделано только с помощью онлайнового протокола.

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

Особенности решения:

Аспект/действие
Новые привязки к Клиенту с офлайновым Доменом и/или Владельцем Лицензии	Никакого офлайнового создания состояния у Клиента не происходит.
Неподсоединенный Владелец лицензии	Нарушенное отношение и отсутствие доступа к Контенту после истечения срока действительности текущего LO-validityperiod.
Неподсоединенный Клиент	Нарушенные отношения и отсутствие доступа к Контенту после истечения срока действительности текущего LO-validityperiod для Владельца лицензии или C-validityperiod.
Снятие Клиента с регистрации в Домене	Клиент немедленно перестанет осуществлять доступ к любому Контенту Домена.
Деассоциирование Владельца лицензии от Домена	Ожидать в течение min.(оставшейся части текущего периода LO-validityperiod, max.(оставшихся частей текущих периодов LO-validityperiods)), прежде чем все Клиенты перестанут осуществлять доступ к любому Контенту деассоциированного Владельца лицензии. Никакие обновления Привязок не требуются.
Удаление Лицензии у Владельца лицензии	Ожидать в течение (если Владелец лицензии и Домен подсоединены: min.(оставшейся части текущего периода LO-validityperiod, max.(оставшихся частей текущих периодов C-validityperiods)), иначе, оставшейся части текущего периода LO-validityperiod), прежде чем Клиент перестанет осуществлять доступ к Контенту удаленной Лицензии. Все остающиеся Лицензии у Владельца лицензии должны быть обновлены. Никакие обновления Привязок не требуются.
Изменение Лицензии (определяемые пользователем ограничения)	Увеличение licenceConfigNr, как если бы Лицензия была удалена.
Размер защищенного администрирования состояний Клиента	#domains*(DomainId+ #LO*(LicenseOwnerId+ licenseConfigNr))

2.6. Отдельное состояние для LinkC, LinkLO и Лицензии

Этот вариант осуществления показан на фиг.8. Применяемые механизмы:

Механизм	Используется для
1.1 - Отдельное состояние для отношения	Охраны состояния LinkC, LinkLO и Лицензии.
1.2 - Периоды действительности для Привязки	Охраны LinkC и LinkLO, принуждения к обмену информацией между Владельцем Лицензии и Доменом и принуждения к обмену информацией о конфигурации Домена между Клиентом и Доменом.

Это решение отличается от решения 2.5 - "Отдельное состояние для LinkC и LinkLO" в том, что механизм licenseConfigNr не используется для охраны состояния всех Лицензий, нацеленных на владельца лицензии, а каждая из всех Лицензий получает отдельную переменную состояния в администрировании состояний Домена и Клиентов. Теперь каждое свидетельство у Клиента нуждается в соответствующей переменной состояния в администрировании состояний Клиента, которая будет расцениваться как действительная при оценке Лицензии.

Привязки Домена могут достигать Клиента путем прямой связи между Доменом и Привязками, и Привязки Клиента теперь действительны только тогда, когда их период действительности не истек и переменная состояния DomainId, связанная с членством, Клиента все еще присутствует в администрировании состояний. Это проверяется в коде Control Привязок, когда оценка Привязок ищет путь к Владельцу Лицензии, как это требуется в оцениваемой Лицензии. Control привязки LinkLO будет выполнять дополнительные проверки на предмет того, что LicenseOwnerId для LinkLO все еще зарегистрирован как ассоциированный в администрировании состояний Клиента и что LicenseId Лицензии при оценке все еще зарегистрирован в администрировании состояний Клиента. Заметим, что эта последняя проверка LicenseId может быть также распределена в коде Control самой Лицензии. В последнем случае следствием этого является то, что проверка, специфическая для системы по конкретному решению, должна быть добавлена к коду Control, подписанному первоначальным поставщиком контента, или выпущенная Лицензия изменяется и подписывается Владельцем лицензии.

Заметим, что идентификатор LicenseId Лицензии должен быть доступен в Лицензии. Это, однако, не показано на чертеже, как это имеет место с другим идентификатором субъектов.

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

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

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

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

Особенности решения:

Аспект/действие
Новые привязки к Клиенту с офлайновым Доменом и/или Владельцем Лицензии	Никакое офлайновое создание состояния в Клиенте не происходит.
Неподсоединенный Владелец лицензии	Нарушенное отношение и отсутствие доступа к Контенту после истечения срока действительности текущего LO-validityperiod.
Неподсоединенный Клиент	Нарушенные отношения и отсутствие доступа к Контенту после истечения срока действительности текущего LO-validityperiod для Владельца лицензии или C-validityperiod.
Снятие Клиента с регистрации в Домене	Клиент немедленно перестанет осуществлять доступ к любому Контенту Домена.
Деассоциирование Владельца лицензии от Домена	Ожидать в течение min.(оставшейся части текущего периода LO-validityperiod, max.(оставшихся частей текущих периодов LO-validityperiods)), прежде чем все Клиенты перестанут осуществлять доступ к любому Контенту деассоциированного Владельца лицензии. Никакие обновления Привязок не требуются.
Удаление Лицензии у Владельца лицензии	Ожидать в течение (если Владелец лицензии и Домен подсоединены: min.(оставшейся части текущего периода LO-validityperiod, max.(оставшихся частей текущих периодов C-validityperiods)), иначе, оставшейся части текущего периода LO-validityperiod), прежде чем Клиент перестанет осуществлять доступ к Контенту удаленной Лицензии. Никакие обновления Лицензий не требуются. Никакие обновления Привязок не требуются.
Изменение Лицензии (определяемые пользователем ограничения)	Не поддерживается.
Размер защищенного администрирования состояний Клиента	#domains*(DomainId+ #LO*(LicenseOwnerId+ #Lics*LicenseId))

2.7. Отдельное состояние для всех отношений с управлением версиями касаемо Лицензий

Этот вариант осуществления показан на фиг.9. Применяемый механизм:

Механизм	Используется для
1.1 - Отдельное состояние для отношения	Охраны состояния LinkC, LinkLO и Лицензии.
1.2 - Периоды действительности для Привязки	Охраны LinkC и LinkLO, принуждения к обмену информацией между Владельцем лицензии и Доменом и принуждения к обмену информацией о конфигурации Домена между Клиентом и Доменом.
1.6 - Номер Версии для отношения по состоянию	Охраны состояния версий Лицензий.

Это решение отличается от решения 2.6 "Отдельное состояние для LinkC, LinkLO и лицензии" поддержкой версий лицензий в состоянии. Владелец лицензии имеет теперь для каждой лицензии, которая нацелена на него, в своем администрировании состояний номер версии LicControlVersionNr. Лицензии, выпущенной в Домен Владельцем Лицензии, в качестве атрибута придается фактическое значение LicControlVersionNr, и LicControlVersionNr сообщается Домену(-ам) и оттуда - Клиентам, чтобы быть включенным в их администрирование состояний.

Владелец лицензии будет увеличивать свой LicControlVersionNr, когда в Лицензии делается существенное изменение. Предыдущие версии Лицензии, выпущенные в Домен, закончат свое действие как бесполезные (вовремя), потому что они несут более старый номер версии, чем тот, который зарегистрирован в администрировании состояний Клиентов.

Проверка присутствия LicenseId оцениваемой Лицензии в администрировании состояний Клиента в качестве элемента LicenseOwnerId в качестве элемента DomainId расширяется до проверки на предмет того, что значение зарегистрированного номера LicControlVersionNr для LicenseOwnerId не выше, чем значение номера LicControlVersionNr, приданного Лицензии в качестве атрибута.

Опять же, необязательно назначать эту проверку в коде Control привязки LinkLO или в коде Control самой Лицензии.

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

Особенности решения:

Аспект/ действие
Новые привязки к Клиенту с офлайновым Доменом и/или Владельцем Лицензии	Никакое офлайновое создание состояния в Клиенте не происходит.
Неподсоединенный Владелец лицензии	Нарушенное отношение и отсутствие доступа к Контенту после истечения срока действительности текущего LO-validityperiod.
Неподсоединенный Клиент	Нарушенные отношения и отсутствие доступа к Контенту после истечения срока действительности текущего LO-validityperiod для Владельца лицензии или C-validityperiod.
Снятие Клиента с регистрации в Домене	Клиент немедленно перестанет осуществлять доступ к любому Контенту Домена.
Деассоциирование Владельца лицензии от Домена	Ожидать в течение min.(оставшейся части текущего периода LO-validityperiod, max.(оставшихся частей текущих периодов LO-validityperiods)), прежде чем все Клиенты перестанут осуществлять доступ к любому Контенту деассоциированного Владельца лицензии. Никакие обновления Привязок не требуются.
Удаление Лицензии у Владельца лицензии	Ожидать в течение (если Владелец лицензии и Домен подсоединены: min.(оставшейся части текущего периода LO-validityperiod, max.(оставшихся частей текущих периодов C-validityperiods)), иначе оставшейся части текущего периода LO-validityperiod), прежде чем Клиент перестанет осуществлять доступ к Контенту по удаленной Лицензии. Никакие обновления Лицензий не требуются. Никакие обновления Привязок не требуются.
Изменение Лицензии (определяемые пользователем ограничения)	Ожидать в течение (если владелец лицензии и Домен подсоединены: min.(оставшейся части текущего периода LO-validityperiod, max.(оставшихся частей текущих периодов C-validityperiods)), иначе, оставшейся части текущего периода LO-validityperiod), прежде чем Клиент перестанет осуществлять доступ к Контенту по удаленной Лицензии. Измененная Лицензия должна быть обновлена.
Размер защищенного администрирования состояний Клиента	#domains*(DomainId + #LO*(LicenseOwnerId + #Lics*(LicenseId + LicControlVersionNr))

2.8. Параллельное связывание Лицензий

Этот вариант осуществления показан на фиг.10. Применяемые механизмы:

Механизм	Используется для
1.1 - Отдельное состояние для отношения	Охраны состояния LinkC, LinkLO и Лицензии.
1.2 - Периоды действительности для Привязки	Охраны LinkC и LinkLO, принуждения к обмену информацией между Владельцем лицензии и Доменом и принуждения к обмену информацией о конфигурации Домена между Клиентом и Доменом.
1.6 - Номер Версии для отношения по состоянию	Охраны состояния версий LinkLic.
1.8 - Параллельное связывание Лицензий для отделения зон управления	Изоляции определяемых пользователем ограничений в Control для LinkLic.

Это решение демонстрирует использование механизма параллельного связывания лицензий поверх конфигурации, описанной в решении 2.7 "Отдельное состояние для всех отношений с управлением версиями Лицензий". Смотрите описание параллельного механизма как ссылку для этого решения. LinkLic является привязкой от Владельца лицензии к лицензии, которая нацелена на владельца лицензии. LicControlVersionNr используется теперь для управления версиями в состоянии для LinkLic, которое наиболее вероятно будет изменено Control, а не Лицензией, с Control первоначального поставщика контента. Также, когда для Лицензии требуется создание версии, дополнительный номер версии может использоваться как следующий номер и действовать независимо от LicControlVersionNr.

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

2.9. Последовательное связывание Лицензий

Этот вариант осуществления показан на фиг.11. Применяемые механизмы:

Механизм	Используется для
1.1 - Отдельное состояние для отношения	Охраны состояния LinkC, LinkLO и Лицензии.
1.2 - Периоды действительности для Привязки	Охраны LinkC и LinkLO, принуждения к обмену информацией между Владельцем лицензии и Доменом и принуждения к обмену информацией о конфигурации Домена между Клиентом и Доменом.
1.6 - Номер Версии для отношения по состоянию	Охраны состояния версий LinkLic.
1.9 - Последовательное связывание Лицензий для отделения зон управления	Изоляции определяемых пользователем ограничений в Control для LinkLic.

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

Особенности решения:

Решение имеет те же самые особенности, что и решение 2.7 "Отдельное состояние для всех отношений с управлением версиями касаемо Лицензий", с дополнительными преимуществами:

Разделенные области управления, где определяемые пользователем ограничения могут изменяться без изменения Лицензии.

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

ДОПОЛНИТЕЛЬНЫЕ УСОВЕРШЕНСТВОВАНИЯ

Определяемые пользователем ограничения могут быть добавлены в соответствии со способом, раскрытым в международной патентной заявке WO 05/111760 (номер в досье поверенного PHNL040536).

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

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

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

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

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

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

Тщательно выбирая оба максимума, эта вероятность может быть значительно уменьшена.

ЗАКЛЮЧИТЕЛЬНЫЕ ЗАМЕЧАНИЯ

В сказанном выше, выражение "min. (A, B)" должно истолковываться как меньшее из А и B, а выражение "max. (A, B)" должно истолковываться как большее из А и B.

В настоящем документе используются следующие определения:

Термин	Определение
Ассоциативная связь	Результат установления отношения между Владельцем лицензии и Доменом.
Клиент	Функциональный субъект, который может приобретать и анализировать Лицензии и Привязки с целью получения доступа к экземпляру Контента, основываясь на правах, выраженных в этих Лицензиях и Привязках.
Контент	Любые данные, которые предназначены для доступа к ним для потребления людьми под защищенным управлением со стороны согласующейся с Доменом системы.
Объект Control	Представление правил, которые управляют доступом к контенту путем предоставления или отказа в использовании ключа Контента для Контента, которым они управляют. Они могут также использоваться для представления ограничений на действительность объекта Привязка, в который они внедрены. Они могут также использоваться как автономные программные контейнеры, которые действуют от имени другого объекта, такого как агенты или делегаты. Объекты Control содержат метаданные и программы в байт-коде, которые реализуют конкретный протокол взаимодействия.
Устройство	Приложение программного обеспечения и/или компонент аппаратных средств, вмещать Клиент.
Домен	Уникально идентифицированная совокупность Клиентов и Владельцев лицензии.
Конфигурация Домена	Совокупность отношений, составляющих Домен, где отдельные отношения могут быть выражены в свидетельстве.
Контент Домена	Контент, который был выпущен для Домена.
Лицензия	Выражение прав, которые Принципал имеет на конкретный экземпляр Контента.
Владелец лицензии	Представитель Пользователя в окружении Домена, которому могут предоставляться права на экземпляр Контента.
Членство	Результат установления отношения между Клиентом и Доменом.
Клиент-Член	Клиент, который является членом конкретного Домена.
Принципал	Системный субъект, подлинность которого может быть установлена.
Выпуск	Процесс предоставления всех или подмножества прав на экземпляр Контента для использования в пределах Домена.
Нацеливание	Установление отношений между Лицензией и Владельцем лицензии.
Пользователь	Индивидуум, который взаимодействует с системой, Устройствами и Услугами. Совокупность владельцев лицензии представляет Пользователя внутри системы.
Правила использования	Набор прав, которые руководят использованием защищенного Контента. Примечание: Правила использования МОГУТ быть явно выражены в Лицензии или быть определены в другом месте, например, через регулирование или в разрешениях на уровне применений.

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

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

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

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

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

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

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

4. Способ по п.3, в котором третья переменная состояния содержит представление идентификатора для лицензии.

5. Способ по п.3, в котором контроллер владельца лицензии создает третью переменную состояния и передает третью переменную состояния контроллеру домена, который передает третью переменную состояния клиенту.

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

7. Способ по п.1 или 4, в котором отношение членства между клиентом и доменом выражено в свидетельстве, в котором идентифицированы клиент и домен.

8. Способ по п.4 или 5, в котором свидетельство несет в себе идентификацию периода своей действительности.

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