Патент на изобретение №2348967

(54) ДОВЕРИТЕЛЬНОЕ УДАЛЕНИЕ ЛИЦЕНЗИИ В СИСТЕМЕ ЗАЩИТЫ СОДЕРЖИМОГО И Т.П.

(57) Реферат:

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

Перекрестные ссылки на родственные заявки

Данная заявка испрашивает приоритет заявки США №10/831280, поданной 23 апреля 2004 г., раскрытие которой включено в настоящее описание посредством ссылки во всей полноте.

Область техники

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

Предшествующий уровень техники

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

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

Однако после осуществления распространения такой владелец содержимого лишь в малой степени контролирует цифровое содержимое 12, если вообще способен его контролировать. Система защиты от копирования 10 позволяет контролировать представление или воспроизведение произвольных форм цифрового содержимого 12, причем владелец содержимого такого цифрового содержимого может гибко регулировать такой контроль. Обычно содержимое 12 распространяется среди пользователей в виде комплекта 13 посредством любого подходящего канала распространения. Распространяемый комплект 13 цифрового содержимого может включать в себя цифровое содержимое 12, зашифрованное с помощью симметричного ключа шифрования/дешифрования (КД) (т.е. (КД(СОДЕРЖИМОЕ))), а также другую информацию, идентифицирующую содержимое, описывающую как получить лицензию для такого содержимого, и т.д.

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

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

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

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

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

После того как блок 20 оценки определит, что правила удовлетворены, цифровое содержимое 12 можно воспроизводить. В частности, для воспроизведения содержимого 12 ключ дешифрования (КД) получают из заранее определенного источника, например, вышеупомянутой лицензии 16 и применяют к (КД(СОДЕРЖИМОЕ)) из комплекта 13 содержимого, чтобы получить фактическое содержимое 12, после чего фактическое содержимое 12 реально воспроизводится.

Доверенный компонент 18 может иногда требоваться для поддержания информации состояния, релевантной представлению конкретного содержимого 12 и/или использованию конкретной лицензии 16. Например, в отдельных случаях конкретная лицензия 16 имеет требование отсчета воспроизведения, и, соответственно, доверенный компонент 18 должен напоминать, сколько раз лицензия 16 использовалась для представления соответствующего содержимого 12, или сколько еще раз лицензию 16 можно использовать для представления соответствующего содержимого 12. Соответственно, доверенный компонент 18 также может включать в себя, по меньшей мере, одно постоянное защищенное хранилище 22, в котором такая информация состояния постоянно поддерживается в защищенном режиме. Таким образом, доверенный компонент 18 сохраняет такую информацию состояния в таком защищенном хранилище 22 на постоянной основе, что позволяет поддерживать такую информацию состояния даже между сеансами использования на вычислительном устройстве 14. Такое защищенное хранилище 22 обычно находится в вычислительном устройстве 14 доверенного компонента 18, хотя такое защищенное хранилище 22 может альтернативно находиться в другом месте.

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

Следует понимать, что время от времени пользователь, вычислительное устройство 14, доверенный компонент 18 или другой объект (ниже «клиент») может пожелать удалить лицензию 16 из использования в связи с ним. Например, в некоторых случаях клиенту желательно больше не воспроизводить соответствующее содержимое 12 или желательно перевести лицензию 16 на другого клиента. Хотя клиент может сам удалить лицензию 16, в некоторых случаях лицензия 16 хранится, например, в защищенном хранилище 22, и потому недоступна, за исключением контролируемых обстоятельств, или в некоторых случаях внешний объект желает убедиться, что лицензия 16 действительно удалена. В одном возможном сценарии, когда клиент приобрел лицензию 16 у службы за деньги и желает «вернуть» лицензию 16 для возврата денег, следует ожидать, что служба потребует некоторую гарантию, что возвращенная лицензия 16 действительно удалена с клиента. В другом возможном сценарии, когда клиент приобрел лицензию 16 у службы для первого вычислительного устройства 14 и желает перевести лицензию 16 на второе вычислительное устройство 14, аналогично можно ожидать, что служба потребует некоторую гарантию, что переведенная лицензия 16 действительно удалена с первого вычислительного устройства 14.

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

Сущность изобретения

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

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

Краткое описание чертежей

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

На чертежах показано следующее:

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

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

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

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

Подробное описание изобретения

Компьютерная среда

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

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

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

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

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

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

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

Доверительное удаление лицензии

Согласно настоящему изобретению осуществляется удаление цифровой лицензии 16 на вычислительном устройстве или клиенте 14, имеющем систему 10 защиты содержимого, и оповещение службы удаления 24 (фиг.3) об удалении также осуществляется доверительным образом. Таким образом, благодаря такому оповещению, служба 24 может, например, кредитовать приобретателя лицензии 16 на «возврат» или может позволить приобретателю или другому получателю лицензии 16 «переводить» права собственности, возложенные в удаленной лицензии 16, на другую лицензию 16 на другом клиенте 14. Затем, согласно настоящему изобретению поставщик/лицензиар цифрового содержимого 12 может предоставлять пользователю возможность «возвращать» ненужное содержимое, гарантируя, что соответствующая лицензия 16 больше не будет доступна пользователю, а также может предоставлять пользователю возможность «переносить» содержимое 12 с первого клиента 14 на второй клиент 14, гарантируя, что соответствующая лицензия 16, присоединенная к первому клиенту 14, больше не будет доступна данному пользователю. Конечно, в последнем случае, поставщик/лицензиар также выдает соответствующую лицензию 16, присоединенную ко второму клиенту 14. Заметим, что в любом случае, поставщик/лицензиар обеспечен доверительным способом гарантирования того, что каждая лицензия 16, удаленная с клиента 14, действительно будет удалена или иным образом сделана недоступной клиенту 14.

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

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

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

Управление правами – это вид DRM, который организационно базируется на том, что содержимое 12 можно защитить так, чтобы оно было доступно только в организации или его подразделении. Пример системы управления правами изложен в патентных заявках США №10/185527, 10/185278, и 10/185511, поданных 28 июня 2002 г. и включенных в настоящее описание посредством ссылки во всей полноте.

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

В одном варианте осуществления настоящего изобретения каждая служба 24, которую можно использовать для удаления лицензии 16, располагает открытым ключом (ОК-С) и соответствующим секретным ключом (СК-С), и каждая лицензия 16 на клиенте 14 может быть удалена только в связи с конкретной службой 24 путем включения открытого ключа (ОК-С) такой службы, как представлено более подробно ниже. Таким образом, лицензия 16, которая не включает в себя (ОК-С) конкретной службы 24, не может быть удалена в связи с такой конкретной службой 24. Таким образом, примером части удаляемой лицензии является:

{значение}

{значение}

{значение}

Заметим, что часть лицензии 16, идентифицированная тегом ‘KID’, – это ИД содержимого, идентифицирующий соответствующее содержимое 12, что часть лицензии 16, идентифицированная тегом ‘LID’, – это ИД лицензии, идентифицирующий саму лицензию 16, и что часть лицензии 16, идентифицированная тегом ‘PU-RS’, – это открытый ключ службы 24 удаления (ОК-С).

В общем случае, клиент 14, желающий удалить одну или несколько лицензий 16, связанных с конкретной службой 24, выдает запрос 26 в службу 24 с идентификацией одной или нескольких лицензий 16, и принимает ответ 28 от службы 24 с идентификацией одной или нескольких лицензий 16. На основании запроса 26 служба 24 извещается о лицензиях 16, подлежащих удалению, и на основании ответа 28 клиенту 14 доверяется фактическое удаление лицензий 16. Таким образом, очевидно, что, хотя клиент 14 может удалить свои лицензии 16 без каких-либо запросов 26 и ответов 28, такой запрос 26 призван информировать службу 24 о действиях клиента, которые он намеревается предпринять, а ответ 28 призван гарантировать, что служба 24 может контролировать и определять действия на клиенте 14, которые он фактически предпринимает, на основании извещения в запросе 26. С помощью запроса 26 и ответа 28 служба 24 удостоверяется в том, что клиент 14 действительно выполняет удаление.

Существенно, что в запросе 26 и ответе 28 идентификация одной или нескольких лицензий 16, подлежащих удалению, может иметь любую конкретно задаваемую и распознаваемую форму, без выхода за рамки сущности и объема настоящего изобретения. Например, в некоторых случаях, каждая лицензия 16 идентифицируется в запросе 26 и/или ответе 28 согласно его LID (ИДЛ). В более общем случае, однако, почти любые критерии, которые могут быть связаны с лицензией 16, можно использовать для ее идентификации в запросе 26 и/или ответе 28, включая его KID (ИДК), службу выдачи, время и/или дату и/или диапазон ее выдачи, тип лицензии, права, предоставляемые лицензией 16, пользователя, которому была выдана лицензия 16, и т.д.

В одном варианте осуществления настоящего изобретения такая идентификация лицензий 16 достигается включением в запрос 26 и/или ответ 28 блока идентификации лицензии (LIB, БИЛ), который идентифицирует лицензии 16, подлежащие удалению. Такая идентификация в БИЛ может включать в себя особую идентификацию каждой лицензии 16 и/или критерии, по которым нужно задавать тип лицензии 16. В любом случае идентификация в БИЛ используется для отыскания совпадающих лицензий 16, которые подлежат удалению из клиента 14. Обычно БИЛ базируется на атрибутах и другой информации, имеющейся в каждой лицензии 16 и/или вне каждой лицензии 16, и имеет форму, распознаваемую получателем. Такой БИЛ должен быть подписан секретным ключом издателя для предотвращения подделки и может быть зашифрован во избежание нежелательного просмотра какой-либо заинтересованной третьей стороной.

Со ссылкой на фиг.4 раскрыт способ, согласно которому клиент 14 удаляет на себе одну или несколько лицензий 16, связанных с конкретной службой 24. Можно видеть, что процесс начинается с того, что клиент 14 выбирает на себе одну или несколько лицензий 16, подлежащих удалению (этап 401), а также выбирает конкретную службу 24 (этап 403). Такой выбор можно осуществлять любым подходящим способом, не выходя за рамки сущности и объема настоящего изобретения, и выбор лицензий 16, в частности, может базироваться на идентификации отдельных лицензий 16 и/или критериев, по которым идентифицируется тип лицензии 16. Заметим, что в связи с выбором одной конкретной лицензии 16, подлежащей удалению, на этапе 401, выбор службы на этапе 403 осуществляется в связи с (ОК-С), указанным в выбранной лицензии 16.

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

Выбрав лицензии 16 и выбрав службу 24, клиент 14 формирует запрос 26 (этап 405), включая в него

БИЛ вызова, идентифицирующий отдельные лицензии 16, подлежащие удалению, и/или критерии, по которым тип лицензии 16 подлежит выбору для удаления;

– идентификацию клиента 14;

– открытый ключ клиента 14 (OK-К), обычно в виде содержащего его цифрового сертификата; и

– ИД транзакции (ИДТ), идентифицирующий вызов 26.

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

Затем клиент 14 посылает запрос 26 в службу 24 (этап 407). Получив запрос, служба 24 осуществляет дешифрование, которое может потребоваться, а также проверяет цифровую подпись БИЛ запроса и/или самого запроса 26 на основании открытого ключа клиента 14 (ОК-К), включенного в запрос 26 (этап 409). Очевидно, что если какая-либо цифровая подпись не проходит проверку, то запрос 26 не следует принимать во внимание. В этом случае, служба 24 может отказаться отвечать, может отвечать запретом и пр.

Если каждая цифровая подпись в вызове 26 прошла проверку, то служба 24 сохраняет информацию, содержащуюся в запросе 26, включая БИЛ вызова, идентификацию клиента 14, ИДТ и открытый ключ устройства в базе данных 30, совместно с любой другой надлежащей информацией, относящейся к транзакции (этап 411). Можно видеть, что служба 24 или любая другая служба 32 может извлекать такие сохраненные элементы из базы 30 данных по любым причинам, которые считаются необходимыми. Например, в связи с «возвратом» лицензии 16 для возврата денег, другая служба 32 является предоставителем кредита, и предоставитель 32 кредита будет выдавать кредит в связи с лицензией 16 на клиенте 14, только если предоставитель 32 кредита сможет подтвердить из базы 30 данных, что лицензия 16 на клиенте 14 удалена. Аналогично, в связи с «переводом» лицензии 16, возможно, что другая служба 32 является предоставителем лицензии, и что предоставитель 32 лицензии будет выдавать лицензию 16 второму клиенту 14, только если предоставитель 32 лицензии сможет подтвердить из базы 30 данных, что лицензия 16 на первом клиенте 14 удалена.

Служба 24, помимо сохранения информации на этапе 411, также формирует ответ 28, соответствующий запросу 26 (этап 413). В частности, сформированный ответ 28 включает в себя:

– БИЛ ответа, идентифицирующий отдельные лицензии 16, подлежащие удалению и/или критерии, по которым тип лицензии 16 нужно выбирать для удаления;

– возможно, идентификацию клиента 14;

– открытый ключ службы 24 (OK-С), обычно в виде включающего его цифрового сертификата;

– ИДТ из запроса 26.

Опять же, БИЛ ответа в ответе 28 может подписываться секретным ключом службы 24 (СК-С), соответствующим (ОК-С) во избежание подделки, и можно шифровать во избежание нежелательного просмотра какой-либо заинтересованной третьей стороной.

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

Заметим также, что БИЛ ответа в ответе 28 может быть идентичен или почти идентичен БИЛ запроса в соответствующем запросе 26 или может быть изменен материальным и/или существенным образом. Такое изменение, осуществляемое службой, может представлять собой любое изменение без выхода за рамки сущности и объема настоящего изобретения. Например, изменение может базироваться на фильтрации БИЛ запроса службой 24, изменение может быть предназначено для определения лицензий 16, подлежащих удалению, как указано в БИЛ ответа более определенным образом; может быть так, что служба 24 выдает каждый БИЛ ответа согласно заранее заданному общему формату и т.п. В любом случае, если БИЛ ответа изменен по сравнению с БИЛ вызова, служба 24 может выбирать вариант сохранить БИЛ ответа в базе 30 данных с БИЛ запроса и другой информацией из запроса 26.

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

После этого служба 24 посылает ответ 28 клиенту 14 (этап 415), и, получив его, клиент 14 осуществляет дешифрование, которое может потребоваться, и также проверяет цифровую подпись БИЛ ответа и/или самого ответа 28 на основании открытого ключа службы 24 (ОК-С), который включен в ответ 28 (этап 417). Как и раньше, если проверка какой-либо подписи не прошла, то ответ 28 не принимается во внимание. В этом случае клиент 14 может повторно послать запрос 26, повторно сформировать запрос 26 и послать его и т.п. Кроме того, клиент 14 подтверждает, что ИДТ ответа 28 совпадает с ИДТ вызова 26.

При условии, что каждая подпись ответа 28 проверена, и что ИДТ совпадают, клиент 14 извлекает БИЛ ответа из ответа 28 и использует его для идентификации одной или нескольких лицензий 16, подлежащих удалению (этап 419). Такую идентификацию можно осуществлять любым подходящим способом, не выходя за рамки сущности и объема настоящего изобретения, и, очевидно, на основании данных в БИЛ ответа, который идентифицирует отдельные лицензии 16, подлежащие удалению, и/или критерии, по которым тип лицензии 16 подлежит выбору для удаления. Затем клиент 14 фактически удаляет каждую идентифицированную лицензию 16, но только если идентифицированная лицензия 16 имеет тот же (ОК-С), что и ответ 28 (этап 421). Таким образом, лицензию 16 можно удалить только на основании ответа 28 от службы 24, имеющей (ОК-С), если лицензия 16 и ответ 28 включают в себя один и тот же (ОК-С).

Когда все идентифицированные и удаляемые лицензии 16 фактически удалены, клиент 14 формирует квитирование (АСК) 34 для отправки в службу 24 (этап 423). В частности, формированное квитирование АСК 34 включает в себя:

– возможно, идентификацию клиента 14;

– возможно, открытый ключ 24 клиента 14 (OK-К), обычно в виде цифрового сертификата, включающего в себя это ключ; и

– ИДТ из запроса 26 и ответа 28.

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

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

При условии, что цифровая подпись АСК 34 проверена и ИДТ совпадают, служба 24 отмечает в базе 30 данных, что соответствующий ответ 28 квитирован (на этапе 429), и транзакция завершается. На основании такого квитирования можно, например, распознать, что клиент 14, идентифицированный в базе 30 данных согласно ИДТ АСК 34, имеет обновленную подписку. Заметим, что, по завершении транзакции, с точки зрения службы 24 будет разумно удалить из базы 30 данных существенную информацию, касающуюся клиента 14, например, его (ОК-К).

Заключение

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

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

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

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

Формула изобретения

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

клиент выбирает лицензию, подлежащую удалению,

клиент выбирает службу,

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

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

служба формирует ответ, соответствующий запросу, и включает в него БИЛ ответа, идентифицирующий лицензию, подлежащую удалению, и идентификацию службы, и посылает ответ клиенту,

клиент принимает ответ и использует БИЛ ответа из ответа для идентификации лицензии, подлежащей удалению, и

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

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

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

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

БИЛ запроса, идентифицирующий лицензию, подлежащую удалению, идентификацию клиента и

идентификатор транзакции (ИДТ), идентифицирующий запрос.

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

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

7. Способ по п.6, содержащий этап, на котором служба формирует ответ, включая в него

БИЛ ответа, идентифицирующий лицензию, подлежащую удалению, идентификацию службы и

ИДТ из вызова.

8. Способ по п.7, содержащий этап, на котором служба формирует ответ, включая в него открытый ключ службы (ОК-С) в качестве идентификации службы.

9. Способ по п.7, дополнительно содержащий этап, на котором клиент подтверждает, что ИДТ в ответе совпадает с ИДТ в запросе.

10. Способ по п.6, содержащий этап, на котором служба формирует ответ, дополнительно включая в него цифровую подпись, основанную, по меньшей мере, частично на БИЛ ответа, способ дополнительно содержит этап, на котором клиент проверяет подпись.

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

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

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

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

клиент формирует квитирование (АСК), соответствующее ответу, включая в него ИДТ из ответа, и посылает АСК службе,

служба принимает АСК и отмечает в базе данных, что ответ квитирован.

15. Способ по п.14, дополнительно содержащий этап, на котором служба подтверждает, что ИДТ в АСК совпадает с ИДТ в ответе.

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

выбирает лицензию, подлежащую удалению,

выбирает службу,

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

принимает ответ и использует БИЛ ответа из ответа для идентификации лицензии, подлежащей удалению,

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

17. Способ по п.16, содержащий этап, на котором клиент выбирает службу на основании идентификации службы в лицензии.

18. Способ по п.17, в котором лицензия включает в себя открытый ключ службы (ОК-С) в качестве идентификации службы, при этом способ содержит этап, на котором клиент выбирает службу на основании (ОК-С) в лицензии.

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

БИЛ запроса, идентифицирующий лицензию, подлежащую удалению, идентификацию клиента и

ИДТ, идентифицирующий вызов.

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

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

22. Способ по п.21, в котором служба формирует ответ, дополнительно включая в него ИДТ из запроса, при этом способ дополнительно содержит этап, на котором клиент подтверждает, что ИДТ в ответе совпадает с ИДТ в запросе.

23. Способ по п.21, в котором служба формирует ответ, дополнительно включая в него цифровую подпись, основанную, по меньшей мере, частично на БИЛ ответа, при этом способ дополнительно содержит этап, на котором клиент проверяет цифровую подпись.

24. Способ по п.21, в котором служба формирует ответ, дополнительно включая в него БИЛ ответа в зашифрованном виде, способ дополнительно содержит этап, на котором клиент дешифрует зашифрованный БИЛ ответа.

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

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

принимает запрос и сохраняет, по меньшей мере, часть запроса в базе данных,

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

27. Способ по п.26, в котором клиент формирует запрос, включая в него БИЛ запроса, идентифицирующий лицензию, подлежащую удалению, идентификацию клиента и

ИДТ, идентифицирующий вызов,

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

БИЛ ответа, идентифицирующий лицензию, подлежащую удалению, идентификацию службы и

ИДТ из вызова.

28. Способ по п.27, содержащий этап, на котором служба формирует ответ, включая в него открытый ключ службы (ОК-С) в качестве идентификации службы.

29. Способ по п.26, содержащий этап, на котором служба формирует ответ, дополнительно включая в него цифровую подпись, основанную, по меньшей мере, частично на БИЛ ответа, причем клиент проверяет цифровую подпись.

30. Способ по п.26, содержащий этап, на котором служба формирует ответ, включая в него БИЛ ответа в зашифрованном виде, причем клиент дешифрует зашифрованный БИЛ ответа.

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

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

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

34. Способ по п.33, дополнительно содержащий этап, на котором служба подтверждает, что ИДТ в АСК совпадает с ИДТ в ответе.

РИСУНКИ