Переносимые системы и способы для приложений одноранговой компоновки услуг
Номер патента: 8614
Опубликовано: 29.06.2007
Авторы: Брэдли Уилльям Б., Боккон-Гибо Жилль, Маер Дэвид П.
Формула / Реферат
1. Система компоновки услуг, предоставляемых одноранговыми сетевыми узлами, с достаточной возможностью взаимодействия, чтобы давать возможность обмена информацией, имеющей стоимостное выражение, через участие в распределенных приложениях, при этом система содержит:
a) первого поставщика услуг, имеющего первый уровень адаптации услуг, который предоставляет интерфейс первой услуги, что дает возможность одноранговым сетевым узлам осуществлять доступ к первой услуге, предлагаемой первым поставщиком услуг, через первую обнаруживаемую привязку;
b) первого потребителя услуг, имеющего первую точку доступа к услугам, которая осуществляет доступ к интерфейсу первой услуги, предоставленному первым поставщиком услуг, обнаруживает первую привязку и вызывает первую услугу, используя эту привязку; и
c) первый блок подборки последовательности операций, который компонует этапы, необходимые, чтобы давать возможность первому поставщику услуг выполнять первую услугу для первого потребителя услуг.
2. Система по п.1, в которой первая услуга обеспечивает ограниченный доступ к зашифрованному мультимедийному содержимому, расположенному на удаленном, основанном на интернет-технологиях сервере, и первый блок подборки последовательности операций включает в себя первую управляющую программу, которая проверяет, авторизован ли первый потребитель услуг для осуществления доступа к содержимому, и, если авторизован, определяет местоположение содержимого и предоставляет его первому потребителю услуг через первый уровень адаптации услуг.
3. Система по п.1, в которой интерфейс первой услуги задан на языке описания Web-услуг (WSDL).
4. Система компоновки услуг, представляемых одноранговыми сетевыми узлами, содержащая:
a) первого поставщика услуг, имеющего первый уровень адаптации услуг, который предоставляет интерфейс первой услуги, что дает возможность одноранговым сетевым узлам осуществлять доступ к первой услуге, предлагаемой первым поставщиком услуг, через первую обнаруживаемую привязку;
b) первого потребителя услуг, имеющего первую точку доступа к услугам, которая осуществляет доступ к интерфейсу первой услуги, предоставленному первым поставщиком услуг, находит первую привязку и вызывает первую услугу, используя эту привязку;
c) первый блок подборки последовательности операций, который компонует этапы, необходимые, чтобы давать возможность первому поставщику услуг выполнять первую услугу для первого потребителя услуг; и
d) второго поставщика услуг, имеющего второй уровень адаптации услуг, который предоставляет интерфейс второй услуги, что дает возможность одноранговым сетевым узлам осуществлять доступ ко второй услуге, предлагаемой вторым поставщиком услуг, через вторую обнаруживаемую привязку, причем вторая услуга обеспечивает доступ к системному реестру, имеющему элемент каталога с информацией для определения местоположения и доступа к первой услуге, при этом первая точка доступа к услугам осуществляет доступ к элементу каталога и использует упомянутую информацию, чтобы определять местоположение и вызывать первую услугу.
5. Система по п.4, в которой системный реестр услуг является системным реестром стандарта UDDI.
6. Система, содержащая:
a) первого поставщика услуг, имеющего первый уровень адаптации услуг, который предоставляет интерфейс первой услуги, что дает возможность одноранговым сетевым узлам осуществлять доступ к первой услуге, предлагаемой первым поставщиком услуг, через первую обнаруживаемую привязку;
b) первого потребителя услуг, имеющего первую точку доступа к услугам, которая осуществляет доступ к интерфейсу первой услуги, предоставленному первым поставщиком услуг, обнаруживает первую привязку и вызывает первую услугу, используя эту привязку;
c) первый блок подборки последовательности операций, который компонует этапы, необходимые, чтобы давать возможность первому поставщику услуг выполнять первую услугу для первого потребителя услуг;
d) сертификат управления доверительностью для сертифицирования первой услуги на доступ только со стороны авторизованных потребителей услуг;
e) управляющую программу для обеспечения ограниченного доступа к первой услуге с использованием сертификата управления доверительностью, при этом первая точка доступа использует сертификат управления доверительностью для проверки правомочности первого потребителя услуг на авторизованный доступ к первой услуге.
7. Система по п.6, в которой сертификат управления доверительностью является сертификатом стандарта Х.509.
8. Система по п.6, в которой сертификат управления доверительностью является сертификатом протокола безопасных соединений (SSL).
9. Способ компоновки услуг, предоставляемых одноранговыми сетевыми узлами, с достаточной возможностью взаимодействия, чтобы давать возможность обмена информацией, имеющей стоимостное выражение, через участие в распределенных приложениях, при этом способ заключается в том, что:
a) предоставляют, с первого уровня адаптации услуг, соответствующего первому поставщику услуг, интерфейс первой услуги, который дает возможность одноранговым сетевым узлам осуществлять доступ к первой услуге, предлагаемой первым поставщиком услуг, через первую обнаруживаемую привязку;
b) осуществляют, из первой точки доступа к услугам, соответствующей потребителю услуг, доступ к интерфейсу первой услуги, предоставленному первым поставщиком услуг, обнаруживают первую привязку и вызывают первую услугу, используя эту привязку; и
c) компонуют, с использованием первого блока подборки последовательности операций, этапы, необходимые, чтобы давать возможность первому поставщику услуг выполнять первую услугу для первого потребителя услуг.
10. Способ по п.9, в котором первая услуга обеспечивает ограниченный доступ к зашифрованному мультимедийному содержимому, расположенному на удаленном сервере, основанном на интернет-технологиях, и первый блок подборки последовательности операций включает в себя первую управляющую программу, которая проверяет, авторизован ли первый потребитель услуг для доступа к содержимому, и, если авторизован, определяет местоположение содержимого и предоставляет его первому потребителю услуг через первый уровень адаптации услуг.
11. Способ по п.9, в котором интерфейс первой услуги задают на языке описания Web-услуг (WSDL).
12. Способ компоновки услуг, заключающийся в том, что:
a) предоставляют, с первого уровня адаптации услуг, соответствующего первому поставщику услуг, интерфейс первой услуги, который дает возможность одноранговым сетевым узлам осуществлять доступ к первой услуге, предлагаемой первым поставщиком услуг, через первую обнаруживаемую привязку;
b) осуществляют, из первой точки доступа к услугам, соответствующей потребителю услуг, доступ к интерфейсу первой услуги, предоставленному первым поставщиком услуг, обнаруживают первую привязку и вызывают первую услугу, используя эту привязку;
c) компонуют, с использованием первого блока подборки последовательности операций, этапы, необходимые, чтобы давать возможность первому поставщику услуг выполнять первую услугу для первого потребителя услуг; и
d) предоставляют, со второго уровня адаптации, соответствующего второму поставщику услуг, интерфейс второй услуги, который дает возможность одноранговым сетевым узлам осуществлять доступ ко второй услуге, предлагаемой вторым поставщиком услуг, через вторую обнаруживаемую привязку, причем вторая услуга обеспечивает доступ к системному реестру услуг, содержащему элемент каталога с информацией для определения местоположения и доступа к первой услуге, при этом первая точка доступа к услугам осуществляет доступ к элементу каталога и использует упомянутую информацию, чтобы определять местоположение и вызывать первую услугу.
13. Способ по п.12, в котором системный реестр услуг является системным реестром стандарта UDDI.
14. Способ, заключающийся в том, что:
a) предоставляют, с первого уровня адаптации услуг, соответствующего первому поставщику услуг, интерфейс первой услуги, который дает возможность одноранговым сетевым узлам осуществлять достуя к первой услуге, предлагаемой первым поставщиком услуг, через первую обнаруживаемую привязку;
b) осуществляют, из первой точки доступа к услугам, соответствующей потребителю услуг, доступ к интерфейсу первой услуги, предоставленному первым поставщиком услуг, обнаруживают первую привязку и вызывают первую услугу, используя эту привязку;
c) компонуют, с использованием первого блока подборки последовательности операций, этапы, необходимые, чтобы давать возможность первому поставщику услуг выполнять первую услугу для первого потребителя услуг;
d) сертифицируют первую услугу, используя сертификат управления доверительностью, на доступ со стороны только авторизованных потребителей услуг; и
e) исполняют управляющую программу, чтобы обеспечивать ограниченный доступ к первой услуге с использованием сертификата управления доверительностью, причем первая точка доступа использует сертификат управления доверительностью, чтобы проверять правомочность первого потребителя услуг на авторизованный доступ к первой услуге.
15. Способ по п.14, в котором сертификатом управления доверительностью является сертификат протокола Х.509.
16. Способ по п.14, в котором сертификатом управления доверительностью является сертификат протокола SSL.
17. Способ компоновки услуг, заключающийся в том, что:
а) осуществляют, из первой точки доступа к услугам, соответствующей потребителю услуг, доступ к интерфейсу первой услуги, предоставленному первым поставщиком услуг, причем интерфейс первой услуги выполнен с возможностью предоставления одноранговым сетевым узлам возможности осуществлять доступ к первой услуге, предлагаемой первым поставщиком услуг, через первую обнаруживаемую привязку;
b) обнаруживают первую обнаруживаемую привязку; и
c) вызывают первую услугу, используя эту привязку, причем необходимые для выполнения первой услуги этапы компонуют с использованием первого блока подборки последовательности операций.
18. Способ по п.17, в котором первая услуга обеспечивает ограниченный доступ к зашифрованному мультимедийному содержимому, расположенному на удаленном сервере, основанном на интернет-технологиях, и первый блок подборки последовательности операций включает в себя первую управляющую программу, которая проверяет, авторизован ли первый потребитель услуг на доступ к содержимому, и, если авторизован, определяет местоположение содержимого и предоставляет его первому потребителю услуг через первый уровень адаптации услуг.
19. Способ, заключающийся в том, что:
a) предоставляют, с первого уровня адаптации услуг, соответствующего первому поставщику услуг, интерфейс первой услуги, который дает возможность одноранговым сетевым узлам осуществлять доступ к первой услуге, предлагаемой первым поставщиком услуг, через первую обнаруживаемую привязку;
b) принимают запрос первой услуги из первой точки доступа к услугам, соответствующей первому потребителю услуг; и
c) компонуют, с использованием первого блока подборки последовательности операций, этапы, необходимые, чтобы давать возможность первому поставщику услуг выполнять первую услугу для первого потребителя услуг.
20. Способ, заключающийся в том, что:
а) предоставляют, с первого уровня адаптации услуг, соответствующего первому поставщику услуг, интерфейс первой услуги, который дает возможность одноранговым сетевым узлам осуществлять доступ к первой услуге, предлагаемой первым поставщиком услуг, через первую обнаруживаемую привязку;
b) принимают запрос первой услуги из первой точки доступа к услугам, соответствующей первому потребителю услуг;
c) сертифицируют, используя сертификат управления доверительностью, первую услугу на доступ только со стороны авторизованных потребителей услуг;
d) исполняют управляющую программу, чтобы обеспечивать ограниченный доступ к первой услуге с использованием сертификата управления доверительностью; и
e) компонуют, с использованием первого блока подборки последовательности операций, этапы, необходимые, чтобы дать возможность первому поставщику услуг выполнять первую услугу для первого потребителя услуг.
Текст
008614 Родственные заявки По данной заявке испрашивается приоритет на основе принадлежащей тому же заявителю предварительной заявки на патент США с порядковым номером 60/476357, озаглавленной "Systems andMethods for Peer-to-Peer Service Orchestration" (системы и способы для компоновки услуг одноранговых узлов сети), поданной William Bradley и David Maher 5 июня 2003 г., и 60/504524, озаглавленной "DigitalRights Management Engine Systems and Methods" (способы и системы процессоров цифрового управления правами), поданной Gilles Boccon-Gibod 15 сентября 2003 г., обе из которых тем самым являются полностью включенными путем ссылки; эти две предварительные заявки на патент США составляют часть рассматриваемого в данный момент описания/спецификации и являются прилагаемыми к нему в виде Приложения А и Приложения В, соответственно. Полномочие авторского права Часть раскрытия этого патентного документа содержит материал, который является предметом охраны авторского права. Обладатель авторского права не имеет возражения на факсимильное воспроизведение кем-либо патентного документа или описания изобретения к патенту, по мере его появления в патентном фонде или регистрациях патентов Патентного ведомства США, но во всем остальном сохраняет за собой абсолютно все права, охраняемые авторским правом. Предшествующий уровень техники Сети, такие как Internet, стали преобладающей средой для доставки цифрового содержимого и услуг, связанных с мультимедиа. Появление стандартных протоколов Web-услуг обещает ускорять эту тенденцию, давая возможность компаниям предоставлять услуги, которые могут быть перенесены на многие программные платформы и могут поддерживать совместные действия между бизнес-услугами и потребителями посредством стандартизованных механизмов. Все же существуют значительные препятствия для задачи реализации переносимого и защищенного окружения для услуг, связанных с мультимедиа. Например, множественные, перекрывающиеся фактически и формально стандарты могут, в действительности, мешать прямой переносимости, вынуждая при различных реализациях выбирать между более или менее стандартными, но в других отношениях несовместимыми, альтернативными техническими подходами для решения тех же задач базовой переносимости или взаимосвязи. В некоторых случаях эти несовместимости имеются вследствие проблем, которые являются результатом попытки объединить различные поколения технологий, тогда как в других случаях проблемы обусловлены ассортиментом товаров на рынке, выполненными различными сторонами, действующими в то же самое время, но в различных местах действия и с различными требованиями. Таким образом, несмотря на стандартизацию, обычно трудно определить местоположение, соединить и взаимодействовать с устройствами, которые обеспечивают необходимые услуги. И имеются часто вопросы несовместимости между различным моделями доверия и защиты. При появлении стандартов Web-услуг, таких как WSDL (язык описания Интернет-услуг), которые начинают решать некоторые из этих вопросов для ориентирующихся на Интернет систем, такие подходы являются неполными. Они будут не в состоянии решать эти вопросы через многие ярусы, связывающие персональные и локальные сети; домашние шлюзы, шлюзы предприятия и шлюзы отдела; и глобальные сети. Они также не направлены в достаточной мере на необходимость переносимости, основанной на динамической компоновке и простых, и сложных услуг, используя множество привязок интерфейсов услуг (например, стандарт CORBA (общая архитектура брокера запросов к объектам), WS-I (организация, созданная для обеспечения совместимости Web-услуг), Java RMI (протокол удаленного вызова),DCOM (объектная модель распределенных компонентов), вызов функций С, .Net и т.д.), таким образом ограничивая способность объединять многие существующие приложения. Появление широко развернутых и принятых приложений одноранговой связи (Р 2 Р) и сетей дополнительно составляет сложные задачи создания переносимых, связанных с мультимедиа услуг, частично благодаря факту, что не имеется какого-либо унифицированного мнения относительно того, как представлять и приводить в исполнение права использования на цифровое содержимое. Краткое описание сущности изобретения Варианты осуществления систем и способов, описанные в документе, могут использоваться, чтобы решить некоторые или все из вышеупомянутых проблем. В одном варианте осуществления предусмотрена инфраструктура услуг, которая дает возможность многим видам заинтересованных сторон в медиапространстве потребителя или предприятия (например, потребителям, поставщикам содержимого (контента), изготовителям устройств, поставщикам услуг) обнаруживать друг друга, устанавливать доверительные отношения и осуществлять обмен информацией, имеющей стоимостное выражение (в дальнейшем упоминаемой как ценность), развитыми и динамическими способами через предоставленные интерфейсы услуг. Варианты осуществления этой инфраструктуры, которая будет обозначена для общности"Сетевая среда для компоновки медиа-услуг" (NEMO), могут обеспечивать платформу для обеспечения переносимой, защищенной связанной с мультимедиа электронной коммерции в окружении из неоднородных потребительских устройств, форматов мультимедиа, протоколов связи и механизмов защиты. Распределенное управление политикой интерфейсов услуг может использоваться, чтобы помочь в обеспечении доверительности и защиты, таким образом содействуя коммерческому обмену ценностью.-1 008614 Тогда как стандарты Web-услуг начинают решать вопросы возможности взаимодействия для ориентирующихся на Интернет услуг, варианты осуществления NEMO могут использоваться, чтобы решать вопросы возможности взаимодействия через многие сетевые ярусы, связывающие персональные и локальные сети; домашние шлюзы, шлюзы предприятия и шлюзы отдела; и глобальные сети. Например,NEMO может обеспечивать возможность взаимодействия в одной взаимосвязанной системе, использующей сотовые телефоны, игровые платформы, персональные цифровые ассистенты (PDA), персональные компьютеры (ПК, PC), основанные на Web-услуги предоставления содержимого, услуги обнаружения, услуги уведомления и услуги обновления. Варианты осуществления NEMO дополнительно могут быть использованы, чтобы обеспечить динамическую одноранговую компоновку и простых, и сложных услуг, используя множество привязок локальных и удаленных интерфейсов (например, WS-I [1], Java,RMI, DCOM, С, .Net и т.д.), таким образом давая возможность интеграции существующих приложений. В окружении для мультимедиа системы и интерфейсы, требуемые или пользующиеся вниманием основного множества заинтересованных сторон (например, издателей содержимого, распространителей,служб розничной торговли, поставщиков бытовых устройств и потребителей), часто очень различаются. Таким образом, желательно объединить возможности, обеспеченные этими объектными сущностями, в объединенные услуги, которые могут быстро развиваться в оптимальные конфигурации, удовлетворяющие потребностям участвующих объектных сущностей. Например, разнообразные протоколы обнаружения услуг и регистрации, такие как Bluetooth, UpnP(среди прочих) могут сосуществовать в пределах одной и той же службы, давая возможность каждому узлу сети использовать услугу(и) обнаружения, наиболее подходящую устройству, которое содержит этот узел сети. Другая служба может поддерживать уведомления на основе IP-протокола, а также уведомления беспроводной службы коротких сообщений (SMS) или различные форматы мультимедиа(МР 4, WMF и т.д.). Варианты осуществления NEMO удовлетворяют этим целям, используя одноранговую компоновку услуг (Р 2 Р). Тогда как преимущества структур Р 2 Р были очевидны для таких задач, как распространение музыки и видео, технология Р 2 Р может использоваться значительно более широко. Наибольшая активность в области Web-услуг была сосредоточена на межмашинном взаимодействии с относительно статической конфигурацией сети и взаимодействиях клиент-сервер. NEMO также способна обрабатывать ситуации, в которых человек переносит части своей персональной сети (PAN),перемещается в близкое соседство с LAN или другой PAN и хочет повторно настроить доступ к услугам немедленно, а также соединиться со многими дополнительными услугами на одноранговой основе. Возможности также существуют в области мультимедийных и различных других услуг для предприятия, и особенно во взаимодействиях между двумя или несколькими предприятиями. Тогда как предприятия являются наиболее часто организованными иерархически и их информационные системы часто отражают такую организацию, люди из различных предприятий будут часто взаимодействовать более эффективно через одноранговые интерфейсы. Например, принимающее лицо/служба в компании А может решать задачи или получать полезную информацию более непосредственно, разговаривая с осуществляющим отправку лицом в компании В. Пересечение иерархий или ненужные интерфейсы, в целом,не являются полезными. Компании по доставке (такие, как FedEx и UPS), понимают это и допускают прозрачность в отношении своих процессов, разрешая непосредственный мониторинг событий со стороны заказчиков. Компании и муниципалитеты организуют свои услуги через порталы предприятия, допуская первичные формы самообслуживания. Однако существующие одноранговые инфраструктуры не позволяют одному предприятию предоставлять его различные интерфейсы услуг своим заказчикам и поставщикам таким образом, чтобы позволять этим объектным сущностям взаимодействовать на уровнях естественного однорангового взаимодействия, давая возможность этим объектным сущностям компоновать услуги предприятия способами,которые в наибольшей степени подходят для них. Это повлечет за собой, например, некоторую форму управления доверительностью этими одноранговыми интерфейсами. Предпочтительные варианты осуществления настоящего изобретения могут использоваться не только, чтобы разрешать, но и содействовать такому одноранговому предоставлению интерфейсов услуг. В контексте конкретных вариантов применения, таких как цифровое управление правами (DRM),варианты осуществления NEMO могут использоваться, чтобы обеспечивать ориентированную на услуги архитектуру, предназначенную, чтобы устранить недостатки и ограничения замкнутых, однородных систем DRM. Предпочтительные варианты осуществления могут использоваться, чтобы обеспечить переносимую, защищенную связанную с мультимедиа коммерцию и операции для разнородных потребительских устройств, форматов мультимедиа и механизмов защиты. В отличие от многих обычных систем DRM, которые требуют относительно замысловатых и усложненных процессоров клиентской стороны для обработки защищенного содержимого, предпочтительные варианты осуществления настоящего изобретения дают возможность средствам DRM клиентской стороны быть относительно простыми, усиливая набор политик управления более развитыми системами управления политиками, действующими на уровне услуг. Предпочтительные варианты осуществления-2 008614 настоящего изобретения также могут обеспечивать повышенную гибкость в выборе форматов мультимедиа и криптографических протоколов и могут содействовать переносимости между системами DRM. Простое, открытое и приспосабливаемое средство DRM клиентской стороны может использоваться,чтобы создавать мощные приложения, поддерживающие DRM. В одном варианте осуществления средство DRM предназначено для удобной интеграции в среду Web-услуг и фактически в любую хост-среду или архитектуру программного обеспечения. Компоновка услуг используется, чтобы преодолеть препятствия переносимости. Например, если имеется запрос содержимого, различные услуги (например, обнаружение, поиск, сопоставление, обновление, обмен правами и уведомление) могут быть скоординированы, чтобы выполнить этот запрос. Предпочтительные варианты осуществления возможности компоновки предоставляют пользователю возможность просматривать все домашние и основывающиеся на Интернет кэш-буферы содержимого из любого устройства, в любой точке, в динамической, многоярусной сети. Эта способность может быть расширена, чтобы содействовать совместному использованию потоков и перечней воспроизведения,упрощая поиск импровизированных передач широкого и узкого вещания и соединение с ними, с использованием многих различных устройств, при этом обеспечивая соблюдение прав. Предпочтительные варианты осуществления NEMO обеспечивают систему сквозного переносимого распространения мультимедиа, которая не основывается на единственном наборе стандартов для формата мультимедиа, управления правами и протоколов исполнения. В цепочке образования потребительской ценности, которая включает в себя создателей содержимого,распространителей, розничных продавцов, поставщиков услуг, изготовителей устройств и потребителей,имеется обычно ряд локализованных потребностей в каждом сегменте. Это является особенно справедливым в случае управления правами, когда создатели содержимого могут выражать права на использование, которые применяются различным образом в различных контекстах к различным элементам цепочки образования ценности для нисходящего потока. Шлюз потребителя обычно имеет гораздо более узкий набор ответственностей, и устройство конечного пользователя может содержать еще более простой набор ответственностей, а именно только воспроизведение содержимого. С наличием в достаточной мере автоматизированной системы для динамически самонастраивающихся услуг распространения создатели содержимого могут производить и пакетировать содержимое, выражать права и уверенно полагаться на ценность, добавленную другими поставщиками услуг, чтобы быстро поставлять содержимое заинтересованным потребителям, независимо от того, где они находятся или какое устройство они используют. Предпочтительные варианты осуществления NEMO осуществляют эту задачу, обеспечивая для множества поставщиков услуг средство для того, чтобы совершенствовать и вводить новые услуги, которые приносят пользу и потребителям, и поставщикам услуг, без необходимости ожидать единого набора сквозных стандартов или зависеть от него. Управление политиками может ограничить пространство, на котором пираты могут воздействовать на эти законные услуги. NEMO дает возможность сети действовать, чтобы поощрять развитие весьма развитого набора законных услуг, обеспечивая большую ценность, чем могут обеспечивать пираты. Некоторые способы "передового опыта", общие для многих из вариантов осуществления NEMO,обсуждаемые ниже, включают нижеследующее: разделение сложных ориентированных на устройство и ориентированных на услугу политик; составление усложненных услуг на основании более простых услуг; динамические конфигурирование и объявление услуг; динамическое обнаружение и вызов различных услуг в неоднородной среде; использование шлюзовых услуг из простых устройств. Также представлены новые средство и архитектура DRM, которые могут использоваться вместе со средой NEMO. Эта система DRM может использоваться, чтобы достичь некоторых или всех нижеследующих целей. Простота. В одном варианте осуществления предусмотрено средство DRM, которое использует упрощенную основывающуюся на стеке виртуальную машину (VM), чтобы исполнять управляющие программы (например, программы, которые приводят в исполнение политики управления). Например, VM может состоять только из нескольких страниц кода. Модульность. В одном варианте осуществления средство DRM предназначено, чтобы функционировать в виде отдельного модуля, интегрированного в большее, поддерживающее DRM приложение. Многие из функций, которые были однажды выполнены посредством единых ядер DRM (такие, как услуги шифрования), могут быть запрошены из хост-среды, которая может поставлять эти услуги на другие модули программного кода. Это дает возможность проектировщикам включать в состав стандартные или составляющие собственность технологии с относительной легкостью. Гибкость. Вследствие своего модульного построения, предпочтительные варианты осуществления средстваDRM могут использоваться в широком разнообразии программных сред, от встроенных устройств до-3 008614 персональных компьютеров общего назначения. Открытость. Варианты осуществления средства DRM являются подходящими для использования в качестве опорного программного обеспечения, так чтобы модули программного кода и интерфейсы прикладного программирования (API) могли быть осуществлены пользователями на фактически любом языке программирования и в системах, которыми они полностью управляют. В одном варианте осуществления система не вынуждает пользователей принимать конкретные форматы содержимого или ограничивать кодирование содержимого. Семантическая независимость. В одном варианте осуществления средство DRM основано на простой, основанной на графах модели, которая превращает запросы авторизации в запросы о структуре графа. Вершины в графе представляют объектные сущности в системе, а направленные ребра представляют отношения между этими объектными сущностями. Однако средству DRM не требуется осведомленность о том, что представляют эти вершины и ребра в каком-либо конкретном приложении. Прозрачная интеграция с Web-услугами. Клиентское средство DRM может использовать Web-услуги несколькими способами. Например,вершины и ребра в графе могут быть динамически находимыми посредством услуг. Содержимое и лицензии на содержимое также могут быть находимыми и поставляемыми на средство DRM посредством усложненных Web-услуг. Хотя один вариант осуществления средства DRM может быть сконфигурирован так, чтобы усиливать Web-услуги во многих местах, его архитектура независима от Web-услуг и может использоваться в качестве автономного ядра DRM клиентской стороны. Упрощенное управление ключами. В одном варианте осуществления топология графа может быть многократно используемой, чтобы упростить получение ключей защиты содержимого, не требуя криптографической повторной настройки. Способ получения ключей является необязательной, но мощной функциональной возможностью средства DRM - система может также, или в качестве альтернативы, быть способной к объединению с другими системами управления ключами. Разделение управления, шифрования и содержимого. В одном варианте осуществления элементы управления, которые управляют содержимым, являются логически отличными от криптографической информации, используемой для осуществления управления. Подобным образом элементы управления и криптографическая информация являются логически отличными от содержимого и форматов содержимого. Каждый из этих элементов может быть доставлен отдельно или в объединенном пакете, таким образом допуская высокую степень гибкости в создании системы доставки содержимого. Варианты осуществления инфраструктуры NEMO, ее применений и ее составляющих частей описаны в настоящем документе. Следует понимать, что сама инфраструктура является новой, как и многие из ее компонентов и приложений. Также должно быть оценено, что настоящие изобретения могут быть осуществлены многими способами, в том числе как процессы, приборы, системы, устройства, способы,машиночитаемые носители или их комбинация. Эти и другие признаки и преимущества будут представлены более подробно в нижеследующем подробном описании и сопроводительных чертежах, на которых в качестве примера проиллюстрированы принципы изобретательской части работы. Перечень фигур чертежей Варианты осуществления изобретательской части работы будут легко поняты посредством обращения к нижеследующему подробному описанию вместе с сопроводительными чертежами, на которых одинаковые числовые ссылочные позиции обозначают идентичные структурные элементы и на которых изображено следующее. Фиг. 1 - иллюстрация примерного варианта осуществления инфраструктуры системы. Фиг. 2 а - иллюстрация концептуальной сети из узлов системы. Фиг. 2b - иллюстрация узлов системы в Р 2 Р-сети. Фиг. 2 с - иллюстрация узлов системы, действующих через Internet. Фиг. 2b - иллюстрация шлюзового узла системы. Фиг. 2 е - иллюстрация посреднического узла системы (прокси). Фиг. 2f - иллюстрация узла-адаптера устройства системы. Фиг. 3 - иллюстрация концептуальной сети из устройств DRM. Фиг. 4 - иллюстрация концептуального графа авторизации узла DRM. Фиг. 5 а - иллюстрация концептуального представления архитектуры узла системы. Фиг. 5b - иллюстрация множества привязок интерфейсов услуг, поддерживаемых уровнем адаптации услуг узла системы. Фиг. 6 а - иллюстрация базового взаимодействия между предоставляющим услугу узлом системы и потребляющим услугу узлом системы. Фиг. 6b - другой пример взаимодействия между предоставляющим услугу узлом системы и потребляющим услугу узлом системы.-4 008614 Фиг. 7 а - иллюстрация точки доступа к услугам, включенной во взаимодействие клиентской стороны на основе WSDL. Фиг. 7b - иллюстрация точки доступа к услугам, включенной во внутреннее взаимодействие клиентской стороны. Фиг. 7 с - иллюстрация точки доступа к услугам, включенной в схему двухточечного ("точка-точка") взаимодействия стороны обслуживания. Фиг. 7d - иллюстрация точки доступа к услугам, включенной в схему многоточечного ("точкамноготочка") взаимодействия стороны обслуживания. Фиг. 7 е - иллюстрация точки доступа к услугам, включенной в схему взаимодействия "точкапромежуточный узел" стороны обслуживания. Фиг. 8 - иллюстрация варианта осуществления архитектуры уровня адаптации услуг. Фиг. 9 а - иллюстрация схемы взаимодействия для блока подборки последовательности операций,основывающегося на внешних поставщиках услуг. Фиг. 9b - иллюстрация схемы взаимодействия блока подборки последовательности операций,включенного в прямой многостадийный обмен информацией с клиентским узлом. Фиг. 9 с - иллюстрация схемы базового внутриузлового взаимодействия для блока подборки последовательности операций. Фиг. 9d - иллюстрация относительно сложной схемы взаимодействия для блока подборки последовательности операций. Фиг. 10 - иллюстрация интеграции системы для средства DRM. Фиг. 11 - иллюстрация варианта осуществления архитектуры средства DRM. Фиг. 12 а - иллюстрация средства DRM и связанных с ним элементов в пределах системного узла клиентской стороны. Фиг. 12b - иллюстрация средства DRM и связанных с ним элементов в пределах системного узла стороны обслуживания. Фиг. 13 - иллюстрация варианта осуществления DRM-объектов для защиты содержимого и управления. Фиг. 14 - иллюстрация варианта осуществления DRM-объектов для узла и связи. Фиг. 15 - иллюстрация варианта осуществления элементов криптографических ключей DRM. Фиг. 16 - иллюстрация схемы базового взаимодействия между клиентским и предоставляющим услугу узлами системы. Фиг. 17 а - иллюстрация набора узлов обработки уведомлений, обнаруживающих узел, который поддерживает услугу обработчика уведомлений. Фиг. 17b - иллюстрация процесса доставки уведомления. Фиг. 18 а - иллюстрация управляемого клиентом сценария обнаружения услуги, в котором запрашивающий узел осуществляет запрос обнаружения услуги на намеченный предоставляющий услугу узел. Фиг. 18b - иллюстрация сценария обнаружения услуги регистрации однорангового узла, в котором запрашивающий узел пытается зарегистрировать свое описание на предоставляющем услугу узле. Фиг. 18 с - иллюстрация основанного на событии сценария обнаружения услуги, в котором заинтересованный узел принимает уведомление об изменении в доступности услуги (например, существовании услуги в пределах предоставляющего услугу узла). Фиг. 19 а - иллюстрация процесса установления доверительного отношения с использованием привязки услуги к неявно доверяемому каналу. Фиг. 19b - иллюстрация процесса установления доверительного отношения на основании модели"запрос/ответ". Фиг. 19 с - иллюстрация процесса установления доверительного отношения на основании явного обмена мандатами безопасности. Фиг. 20 - иллюстрация управляемого политикой доступа к услуге. Фиг. 21 - иллюстрация примерного графа узла DRM со связями принадлежности и ключей доступа. Фиг. 22 - иллюстрация варианта осуществления формата модуля кода VM для DRM. Фиг. 23 - иллюстрация иерархии профилей функций системы. Фиг. 24 - иллюстрация сценария DRM-приложения для устройства воспроизведения музыки. Подробное описание Ниже представлено подробное описание изобретательской части работы. Тогда как это описание представлено вместе с несколькими вариантами осуществления, следует понимать, что изобретательская часть работы не ограничена каким-либо вариантом осуществления, а вместо этого охватывает многочисленные альтернативы, модификации и эквиваленты. Например, тогда как некоторые варианты осуществления описаны в контексте ориентированных на потребителя содержимого и приложений, специалисты в области техники признают, что раскрытые системы и способы являются легко приспосабливаемыми для более широкого применения. Например, без ограничения эти варианты осуществления могут быть легко приспособлены и применены к контексту содержимого и приложений для предприятия. Кроме того, тогда как многочисленные конкретные подробности сформулированы в нижеследующем описании, чтобы-5 008614 обеспечить полное понимание изобретательской части работы, некоторые варианты осуществления могут быть реализованы без отдельных или всех из этих подробностей. Кроме того, с целью ясности, некоторый технический материал, который известен в области техники, не был описан подробно, чтобы избежать излишнего затенения изобретательской части работы. 1. Концепции. 1.1. Web-услуги. Архитектура Web-услуг (WSA) является конкретным частным случаем ориентированной на услуги архитектуры (SOA). Собственно SOA является видом распределенной системы, состоящей из слабосвязанных, совместно действующих программных агентов. Агенты в SOA могут предоставлять услугу, запрашивать (потреблять) услугу или осуществлять и то, и другое. Услугу можно рассматривать как строго определенный, автономный набор операций, управляемых агентом, действующим в роли поставщика услуг. Операции вызываются через сеть в некотором, адресуемом в сети местоположении, называемом оконечной точкой, с использованием стандартных протоколов и форматов данных. Под автономностью подразумевается, что услуга не зависит непосредственно от состояния или контекста другой услуги или включающего приложения. Примеры широко известных технологий, которые поддерживают концепции SOA, включают в себяCORBA, DCOM и J2EE (технология разработки корпоративных приложений на языке Java). WSA привлекательна, поскольку она не привязана к конкретной платформе, языкам программирования, стеку протоколов уровня приложения или соглашению по форматам данных. WSA использует стандартные форматы, основанные на XML (расширяемом языке разметки), для описания услуг и обмена сообщениями, который поддерживает слабое связывание и взаимодействия между поставщиками и потребителями и поддерживает многие стандартные протоколы Интернет (особенно HTTP), что способствует развертыванию и участию в потенциально глобально распределенной системе. Новой тенденцией является рассмотрение SOA в контексте шины оперативно подключаемых ("подключи и работай") услуг. Подход такой шины услуг предусматривает компоновку услуг посредством усиливания стандартов описания, передачи сообщений и транспортных стандартов. Инфраструктура также может включать в себя стандарты для обнаружения, преобразования, защиты, а также, возможно,другого. Через внутренние качества повсеместных стандартов, включенных в WSA, она является гибкой,расширяемой и масштабируемой и, следовательно, обеспечивает подходящую основу для создания модели шины компонованных услуг. В этой модели основную единицу работы (услугу) называют Webуслугой. Имеется широкий ряд определений Web-услуги. Нижеследующее определение проистекает из рабочего проекта архитектуры Web-услуг Консорциума World-Wide Web (W3C), (8 августа, 2003 г. - см.Web-услуга является системой программного обеспечения, предназначенной для поддержки переносимого межмашинного взаимодействия по сети. Она имеет в составе интерфейс в машинно-обрабатываемом формате (конкретно WSDL). Другие системы взаимодействуют с Web-услугой способом, предписанным в соответствии с ее описанием, используя сообщения SOAP, обычно передаваемые с использованием HTTP с преобразованием в последовательную форму согласно XML вместе с другими связанными с Web стандартами. Тогда как определение W3C обеспечивает полезную отправную точку, следует понимать, что термин "Web-услуги" используется при этом в более широком смысле, без ограничения, например, использованием конкретных стандартов, форматов и протоколов (например, WSDL, SOAP, XML, HTTP и т.д.). Конкретная Web-услуга может быть описана в виде абстрактного интерфейса для логически связного набора операций, который обеспечивает основу для (возможно кратковременных) отношений между поставщиком услуг и запрашивающим услугу. Конечно, фактические Web-услуги имеют конкретные реализации. Конкретную реализацию поставщика иногда обозначают как служба (в отличие от Web-услуги). Программное обеспечение, которое фактически осуществляет функциональные возможности поставщика услуг, является агентом-поставщиком и для запрашивающего услугу - агентом-запрашивающим. Лицо или организацию, которая владеет агентом, обозначают как объектная сущность "поставщик" или объектная сущность "запрашивающий",как соответствует. Когда используется отдельно, запрашивающий или поставщик может относиться в зависимости от контекста или к соответствующей объектной сущности, или к агенту.Web-услуга существует, чтобы достичь цель, а как она достигается, задается согласно механике и семантике конкретного обмена сообщениями Web-услуги. Механика относится к точным машинообрабатываемым техническим описаниям, которые позволяют, чтобы происходил обмен сообщениями по сети. Хотя механика является точно определенной, семантика может не быть таковой. Семантика относится к явному или неявному "контракту", в какой бы форме он ни существовал, управляющему и пониманием, и совокупными ожидаемыми результатами между объектными сущностями запрашивающего и поставщика для Web-услуги.Web-услуги обычно моделируются в терминах взаимодействий для трех ролей: (i) поставщика услуг; (ii) запрашивающего услугу; и (iii) реестра услуг. В этой модели поставщик услуг "публикует" ин-6 008614 формацию, описывающую его Web-услугу для реестра услуг. Запрашивающий услугу "находит" эту информацию посредством некоторого механизма обнаружения и затем использует эту информацию, чтобы"привязаться" к поставщику услуг для использования услуги. Привязка просто означает, что запрашивающий вызовет операции, предоставляемые поставщиком, используя соглашения форматирования сообщения, отображения данных и транспортного протокола, заданные поставщиком в опубликованном описании услуг. Основанный на XML язык, используемый для описания этой информации, называется языком описания Web-услуг (WSDL). Поставщик услуг предлагает доступ к некоторому набору операций для конкретного назначения,описанного согласно описанию услуги на WSDL; это описание услуги является публикуемым в реестре каким-либо средством из ряда средств с тем, чтобы услуга могла быть обнаружена. Реестр может быть открытым или частным внутри конкретного домена. Реестр услуг является программным обеспечением, которое отвечает на запросы обнаружения услуги, возвращая предварительно опубликованное описание услуги. Запрашивающий услугу является программным обеспечением, которое вызывает различные операции, предлагаемые поставщиком, в соответствии с информацией привязки, заданной на языке WSDL, полученной из реестра. Реестр услуг может существовать только концептуально или может существовать фактически, в виде реально существующего программного обеспечения, обеспечивающего базу данных описаний услуг,используемую, чтобы выполнять запрос, определять местоположение и осуществлять привязку к конкретной услуге. Но независимо от того, проводит ли запрашивающий фактически активный поиск услуги или является описание услуги предоставляемым статически или динамически, в любом случае, реестр является логически отдельным аспектом модели Web-услуг. Интересно обратить внимание, что в реализации реального окружения реестр услуг может быть частью платформы запрашивающего услугу, платформы поставщика услуг или может постоянно находиться на другом местоположении, полностью идентифицированном некоторым известным адресом или адресом, поставляемым некоторым другим средством. Описание услуги на WSDL поддерживает слабое связывание, обычно центральная тема скрыта заSOA. Тогда как в конечном счете запрашивающий услугу будет понимать семантику интерфейса услуги,который он использует с целью достижения некоторого желательного результата, описание услуги изолирует интерфейс услуги от информации конкретной привязки услуги и поддерживает в высокой степени динамическую модель Web-услуг. Ориентированная на услугу архитектура может быть построена поверх многих возможных уровней технологии. Как в настоящее время осуществлено на практике, Web-услуги обычно объединяют или включают в себя аспекты нижеследующих технологий.HTTP - стандартный протокол прикладного уровня для передач большинства Web-услуг. Хотя Webуслуги могут быть развернуты поверх различных сетевых протоколов (например, SMTP (простой протокол электронной почты), FTP (протокол передачи файлов) и т.д.), HTTP является наиболее повсеместным, дружественным относительно брандмауэра (средства межсетевой защиты) транспортным протоколом, находящимся в использовании. Для некоторых приложений, особенно в пределах внутриучрежденческих сетей, могут иметь смысл другие сетевые протоколы в зависимости от требований; однако, HTTP является частью почти любой платформы Web-услуг, созданной на сегодняшний день.XML - стандарт для форматирования и доступа к содержимому (и информации о содержимом) для структурированной информации. XML является основанным на тексте стандартом для обмена информацией между агентами Web-услуг. Обратите внимание, что использование XML не означает, что полезные нагрузки сообщений для Web-услуг могут не содержать каких-либо двоичных данных; но это означает,что эти данные будут форматированы в соответствии с соглашениями XML. Большинство архитектурWeb-услуг не обязательно предписывают, чтобы сообщения и данные были преобразованы (для записи или чтения) в поток символов, - они могут, где это имеет смысл, подобным образом быть преобразованными к двоичному потоку, но если используется XML, эти потоки будут представлять XML-документы. То есть выше уровня механизма транспорта передача сообщений Web-услуг будет обычно проводиться с использованием XML-документов. Двумя технологиями подмножества XML, которые особенно важны для многих Web-услуг, являются XML Namespaces (пространства имен) и XML Schema (схема). Пространства XML-имен используются, чтобы разрешать конфликты именования и объявлять конкретное смысловое содержание для элементов, содержащихся вместе с XML-документами. XML-схема используется, чтобы задавать и ограничивать различные информационные элементы, содержащиеся внутри XML-документа. Хотя является возможным (и необязательным) осуществлять эти цели другими средствами, использование XML является, вероятно, наиболее общей методикой, используемой в настоящее время. Описания формата XMLдокумента для самих документов Web-услуг задаются с использованием XML-схемы, и большинство операций Web-услуг реального окружения и сами сообщения будут далее определены, включая XMLсхему.SOAP - основанный на XML стандарт для инкапсуляции команд и информации в специальным образом форматированный пакет для передачи другим получателям и обработки ими. SOAP (простой протокол доступа к объектам) является стандартным механизмом пакетирования сообщений Web-услуг для-7 008614 передачи между агентами. Своего рода неправильное употребление термина, наследуемое смысловое содержание соответствует его средству вызова распределенных объектов, и в этом отношении он, действительно, "более прост", чем другие альтернативы; но последней тенденцией является рассмотрениеSOAP в качестве основанного на XML протокола проводной связи для целей, которые превысили исходное смысловое содержание акронима.SOAP определяет относительно облегченное соглашение для структурирования сообщений и предоставления информации о содержимом. Каждый документ SOAP содержит конверт, который разделен на заголовок и основную часть (тело). Будучи структурно сходными, заголовок тем не менее обычно используется для метаинформации или команд для принимающей стороны, связанных с обработкой содержимого, содержащегося в основной части.SOAP также определяет средство идентификации характеристик и обработку, необходимую, чтобы реализовать соответствующие характеристикам обязательства. Шаблон обмена сообщениями (МЕР) является характеристикой, которая задает шаблон того, как осуществляется обмен сообщениями между узлами. Обычно МЕР основывается на механизме "запрос-ответ", который устанавливает одиночную, завершенную транзакцию сообщения между запрашивающим и отвечающим узлом (см.WSDL, услуга относится к набору сообщений, обмениваемых между запрашивающими услугу и ее поставщиками. Сообщения описаны в абстрактной форме, которая может быть отображена на конкретные протоколы. Обмен сообщениями, который вызывает некоторые функциональные возможности, называется операцией. Конкретный набор операций определяет интерфейс. Интерфейс привязан к конкретному формату сообщений и протоколу посредством именованной привязки. Привязка (отображение интерфейса на конкретный протокол) соотнесена с URI (унифицированный идентификатор ресурса), соответствующим протоколу, имея в результате оконечную точку. Совокупность одной или нескольких соответствующих оконечных точек (отображение интерфейса на конкретные протоколы его конкретным URI) содержит услугу. Эти определения отображаются на конкретные элементы WSDL:message (сообщение) - абстрактное определение типов посылаемых данных;operation (операция) - абстрактное описание действия на основании комбинации входных, выходных сообщений и сообщений об ошибках;portType (тип порта) - абстрактный набор операций интерфейс;binding (привязка) - описание конкретного протокола и формата данных для интерфейса (portType);port (порт) - комбинация привязки и фактического сетевого адреса - оконечная точка;service (услуга) - совокупность связанных портов (оконечные точки).WSDL задает общий механизм привязки и затем задает конкретные расширения привязки дляSOAP, команд GET/POST (получить/отправить) HTTP и MIME (многоцелевые расширения почтовой службы в Интернет). Таким образом, привязка не обязательно означает связывание с транспортным протоколом непосредственно, а к конкретному формату передачи. Наиболее общей привязкой для Webуслуг является SOAP, хотя фактические обмены сообщениями SOAP обычно происходят по HTTP на порте 80 (через http://URI). Однако интерфейс может быть непосредственно связан с HTTP; в качестве альтернативы, например, привязка в SOAP может использовать протокол SMTP (через mailto://URI). Реализация может даже задавать свой собственный формат передач и использовать специализированное расширение привязки.WSDL содействует удобству сопровождения и возможности повторного использования, обеспечивая поддержку для элемента import (импорт). Используя импорт, WSDL-документ может быть разделен на отдельные части способами, которые имеют смысл для организации. Для связующей среды Webуслуг, требующей некоторой степени разделения между определением интерфейса и определением реализации, является разумным нижеследующее разделение на три документа: документ схемы (.xsd) - корневым узлом является schema, и пространством имен является"http://www.w3.org/2001/XMLSchema"; описание интерфейса услуги, содержащее то, что считают повторно используемой порциейmessage,portType,binding; определение реализации услуги, содержащее конкретную оконечную точку услугиWSDL-интерфейсы не являются в точности сходными с интерфейсами Java (или IDL (язык описания интерфейса), или некоторого другого языка программирования). Например, объявление интерфейсаJava задает набор методов, которые должны совпадать, по меньшей мере, с подмножеством методов класса, притязающего на реализацию этого интерфейса. Более одного класса могут реализовывать интерфейс, и каждая реализация может быть отличной от других; но сигнатуры метода (имя метода и ка-8 008614 кие-либо типы входных или выходных данных) обычно должны быть идентичными. Это предписано языком и принудительно обеспечивается во время компиляции, исполнения или и того, и другого. Интерфейс WSDL является отличающимся, и он более сходен с действительно абстрактным классом, который в одиночку не является вполне пригодным. Различные WSDL-интерфейсы, или типы portType, для отдельной Web-услуги логически связаны в том смысле, что набор имен операций должен быть идентичным, как если бы portType, в действительности, осуществил конкретный контракт, определенный где-либо еще, но такой элемент фактически не существует, и отсутствует механизм для принудительного обеспечения симметрии portType. Каждый portType обычно именуется так, чтобы идентифицировать тип привязки, который он поддерживает, даже при том, что portType в одиночку не создает привязку. Операции portType для соответствующих portType именуются одинаково, но входные данные, выходные данные и сообщения об ошибках (если имеются) отображаются на конкретные сообщения, которые содержат именованные части, также необходимые для поддержки конкретной привязки. Это поднимает вопрос, что сами сообщения не являются полностью абстрактными. Web-услуга может и часто требует определять сходные, но отличные сообщения для различных требуемых привязок. Как будет проиллюстрировано ниже, посредством усиливания появляющихся Web-услуг и связанных с ними стандартов может быть разработана архитектура системы, которая способствует созданию сетевых, переносимых связанных с мультимедиа услуг, которые используют множество различных протоколов и интерфейсов по всему широкому диапазону аппаратных и программных платформ и операционных сред. 1.2. Роли. Предпочтительные варианты осуществления настоящего изобретения стремятся давать возможность, содействовать и/или активно поддерживать одноранговую среду, в которой одноранговые узлы могут самопроизвольно предлагать множество функциональных возможностей посредством предоставления услуг. Один вариант осуществления структуры ломает представление об одноранговых узлах как об имеющих постоянный набор возможностей и, вместо этого, поощряет модель, в которой одноранговый узел в любой момент времени является участником одной или нескольких ролей. Роль может быть определена согласно набору услуг, которые заданный узел предоставляет, в комбинации с конкретной моделью поведения. В любой заданный момент поддерживающий NEMO узел может выступать во многих ролях на основании следующих различных факторов: его фактическое пространство реализации, обеспечивающее функциональные возможности для поддержки заданного набора услуг, административная конфигурация, информация, объявляющая услугу(и), которую узел способен предоставлять, и политика загрузки и времени исполнения для интерфейсов услуг. Явный набор ролей может быть определен на основании разнообразных различных типов услуг. Со временем, по мере того, как определены общие шаблоны участия, и по мере того, как введены новые услуги, может быть определена более формальная схема классификации ролей. Предварительный набор ролей, которые могут быть формализованы со временем, может включать в себя нижеследующее.Client (клиент) - относительно простая роль, в которой никакие услуги не предоставляются, и одноранговый узел просто использует услуги других одноранговых узлов.Authorizer (уполномоченный) - эта роль обозначает одноранговый узел, действующий в качестве точки принятия решения по политике (PDP), определяющий, имеет ли запрашивающий администратор доступ к указанному ресурсу, с помощью заданного набора предусловий и постусловий.Gateway (шлюз) - в некоторых ситуациях узел может не быть способным напрямую обнаруживать или взаимодействовать с другими поставщиками услуг по причинам, включающим в себя несовместимость транспортного протокола, неспособность согласовать доверительный контекст или недостаток вычислительной мощности для создания и обработки необходимых сообщений, соотнесенных с данной услугой. Шлюз является одноранговым узлом, действующим в качестве моста к другому одноранговому узлу, чтобы позволять одноранговому узлу взаимодействовать с поставщиком услуг. С точки зрения идентификации и установления авторизованного и доверительного контекста для операции, запрашивающий одноранговый узел может фактически делегировать одноранговому шлюзовому узлу свои идентификационные данные и позволить этому одноранговому узлу договариваться об условиях и принимать решения от своего имени. В качестве альтернативы, одноранговый шлюзовой узел может действовать в качестве простой точки ретрансляции, осуществляя пересылку или маршрутизацию запросов и ответов.Orchestrator (компоновщик) - в ситуациях, в которых взаимодействие с набором поставщиков услуг включает в себя нетривиальную координацию услуг (возможно включающую в себя транзакции, распределенное управление состоянием и т.д.), участие может быть вне возможностей однорангового узла. Компоновщик является конкретизацией роли шлюза. Одноранговый узел может запросить компоновщик действовать от своего имени, выступая посредником, чтобы обеспечивать одну или несколько услуг. Компонующий одноранговый узел может использовать некоторые дополнительные компоненты NEMO,такие как соответственно настроенный блок подборки последовательности операций, для того, чтобы удовлетворять требования компоновки. При заданной цели "обеспечение мгновенного вознаграждения, удовлетворяя запрос на любые мультимедийные данные, в любом формате, из любого источника, в любом месте, в любое время, на лю-9 008614 бом устройстве, подчиняясь любому соответствующему набору правил использования" нижеследующая неформальная модель, используя варианты осуществления среды NEMO, иллюстрирует, как эту цель можно достичь. Из верхнего уровня модели станет очевидным (без перечисления каждого аспекта того,как NEMO активирует все услуги мультимедиа, которые только можно предположить), каким образомNEMO дает возможность собирать низкоуровневые услуги из различных ярусов в модели в более развитые сквозные услуги мультимедиа. В одном варианте осуществления этой модели имеются четыре яруса обслуживающих компонентов: 1) услуги создания, сборки, пакетирования содержимого (составления) пакетов, 2) основанные наWeb услуги объединения и распределения содержимого, 3) услуги домашнего шлюза и 4) устройства бытовой электроники. Каждый из этих четырех ярусов обычно имеет различные требования к защите, управлению правами, обнаружению услуг, компоновке услуг, сложности пользовательского интерфейса и другим атрибутам услуг. Первые два яруса очень грубо соответствуют моделям, которые рассматривают "традиционные" Web-услуги, тогда как остальные два яруса более соответствуют тому, что можно называть персональной логической сетевой моделью, с некоторыми услугами домашнего шлюза, являющегося связующим звеном между двумя видами моделей. Однако услуги для устройств бытовой электроники (СЕ) могут иногда появляться в любом из ярусов. Одна трудность заключается в желании конкретизировать части инфраструктуры для эффективности осуществления, являющегося при этом достаточно общим, чтобы охватить сквозное решение. Например, каталог UDDI и подход обнаружения могут хорошо работать для относительно статических и централизованных Web-услуг, но для более динамического кратковременного слияния персональных сетей модели обнаружения, такие как обеспечиваемые в протоколах UPnP и Rendezvous, могут быть более подходящими. Таким образом, в некоторых вариантах осуществления многие стандарты поиска вмещены в пределы инфраструктуры. Подобным образом, когда управление правами применяется к распространению мультимедиа через подъярусы оптовой торговли, агрегатора (организация сбора информации о товарах, услугах и розничной торговле) и розничного распространения, могут существовать многие различные виды сложных прав и обязательств, которые должны быть выражены и отслежены, означая необходимость в весьма выразительном и сложном языке прав, усложненных управлении содержимым и расчетах услуги и глобальной модели доверительности. Однако управление правами и содержимым для ярусов домашнего шлюза и устройства СЕ могут влечь за собой другую модель доверительности, которая подчеркивает права законного использования, которые являются относительно прямыми с точки зрения потребителя. Одноранговые устройства в персональной логической сети могут пожелать взаимодействовать, используя относительно простую модель доверительности этой сети, и с возможностью взаимодействовать с одноранговыми узлами через глобальную сеть с использованием глобальной модели доверительности, возможно посредством услуг шлюза-посредника. На стороне потребителя сложность проистекает вследствие автоматизированного управления доступностью содержимого через устройства, некоторые из которых являются мобильными и периодически пересекают многие сети. Таким образом, эффективный подход к управлению правами, предоставляя возможность сквозного распространения, также может быть неоднородным, поддерживающим множество услуг управления правами, включая услуги, которые интерпретируют выражения распространения прав и, в контексте, преобразуют их к правам использования отдельного потребителя в транзакции, которую компонуют вместе с торговой сделкой или возможно с другим событием, в котором подписное право осуществлено. 1.3. Логическая модель. В одном варианте осуществления инфраструктура системы состоит из набора логически соединенных узлов, которые взаимодействуют способом одноранговой (Р 2 Р) связи. Одноранговые вычисления часто определяются как совместное использование ресурсов (таких, как накопители на жестких дисках и циклы процессов обработки) между компьютерами и другими интеллектуальными устройствами. См.http://www.intel.com/cure/peer.htm. При этом Р 2 Р можно рассматривать как модель взаимодействия, позволяющую сетевым узлам симметрично использовать и предоставлять услуги всех видов. Обмен сообщениями и подборка последовательности операций способом Р 2 Р позволяют создавать развитые услуги на основании неоднородного набора более примитивных услуг. Это дает возможность рассмотрения возможностей Р 2 Р-вычислений, когда общедоступными ресурсами являются услуги многих различных типов, даже использующие различные привязки услуг. Различные варианты осуществления могут обеспечивать инфраструктуру мультимедийных услуг,дающую возможность заинтересованным сторонам (например, потребителям, поставщикам содержимого, изготовителям устройств и поставщикам услуг) развитыми и динамическими способами находить друг друга, взаимодействовать, осуществлять обмен ценностью и совместно действовать. Эти различные типы услуг находятся в диапазоне от базовых (обнаружение, уведомление, поиск и совместное использование файлов) до более сложных высокоуровневых услуг (таких, как защищенное хранение, лицензирование, согласование, авторизация, транзакция платежа и обновление) и комбинаций каких-либо из них или всех из них.- 10008614 Услуги могут быть распространены на одноранговые взаимодействующие узлы, каждый из которых обеспечивает маршрутизацию и компоновку, используя буфер подкачки сообщений и блок подборки последовательности операций (описанный более подробно ниже), разработанный для этой инфраструктуры. Узлы взаимодействуют посредством осуществления запросов вызова услуг и приема ответов на запросы. Формат и полезная нагрузка сообщений запросов и ответов являются предпочтительно определенными на стандартном, основанном на XML-схеме языке описания Web-услуг (например, WSDL), который осуществляет расширяемый набор типов данных, допуская возможность описания и составления услуг и соответствующих им привязок интерфейсов. Многие из типов объектов в WSDL являются полиморфными и могут быть расширены для поддержки новых функциональных возможностей. Инфраструктура системы поддерживает создание разнообразных схем взаимодействия, в пределах от прямого взаимодействия с единственным поставщиком услуг до сложного объединения организованного набора услуг от многих поставщиков услуг. В одном варианте осуществления инфраструктура поддерживает базовые механизмы для использования существующих стандартов организации услуг (WSCI (интерфейс организации Интернет-услуг), BPEL (язык описания исполнения бизнес-процессов) и т.д.), а также позволяет поставщикам услуг использовать их собственные соглашения. Синтаксис сообщений, соотнесенных с вызовом услуги, предпочтительно описан относительно гибким и портируемым образом, в виде базовых типов данных, используемых в пределах инфраструктуры системы. В одном варианте осуществления это выполнено с использованием WSDL для обеспечения относительно простых способов осуществления ссылок на семантические описания, соотнесенные с описываемыми услугами. Интерфейс услуги может иметь одну или несколько привязок услуги. В таком варианте осуществления узел может вызывать интерфейс другого узла, пока привязка интерфейса этого узла может быть выражена на, например, WSDL и пока запрашивающий узел может поддерживать соглашения и протоколы, соотнесенные с привязкой. Например, если узел поддерживает интерфейс Web-услуг, может потребоваться, чтобы запрашивающий узел поддерживал SOAP, HTTP, WS-Security (безопасность Webуслуг) и т.д. Любой интерфейс услуги может быть управляемым (например, управляемые права) стандартизованным образом, непосредственно обеспечивающим аспекты управления правами. Взаимодействия между узлами могут рассматриваться в качестве управляемых операций. Фактически любой тип устройства (физического или виртуального) может рассматриваться как потенциально поддерживающий NEMO и способный осуществлять ключевые аспекты инфраструктурыNEMO. Типы устройств включают в себя, например, оборудование бытовой электроники, сетевые услуги и программных клиентов. В предпочтительном варианте осуществления поддерживающее NEMO устройство (узел) обычно включает в себя некоторые или все из нижеследующих логических модулей (обсуждаемых более подробно ниже). Интерфейс прикладного программирования (API) внутренних услуг (Native Services API) - набор из одной или нескольких услуг, которые устройство реализует. Отсутствует требование, чтобы узел NEMO предоставлял в среде NEMO какую-либо услугу прямо или косвенно. Реализация внутренних услуг (Native Service Implementation) - соответствующий набор реализацийAPI внутренних услуг. Уровень адаптации услуг (Service Adaptation Layer) - логический уровень, через который осуществляется доступ к предоставленному поднабору внутренних услуг объектной сущности с использованием одной или нескольких обнаруживаемых привязок, описанных, например, на WSDL. Библиотека поддержки инфраструктуры (Framework Support Library) - компоненты, которые обеспечивают поддержку функциональных возможностей для работы с инфраструктурой NEMO, включая поддержку для вызова интерфейсов услуг, обработки сообщения, компоновки услуг и т.д. 1.4. Терминология. В одном варианте осуществления базовый профиль WSDL определяет наименьший "базовый" набор типов данных и сообщений для поддержки схем взаимодействия и инфраструктурных функциональных возможностей. Пользователи могут либо непосредственно, специальным образом, или посредством некоторой формы процесса стандартизации задавать другие профили, созданные поверх этой базы, добавляя новые данные и типы услуг и расширяя имеющиеся. В одном варианте осуществления этот базовый профиль включает в себя определения для некоторых или всех из нижеследующих основных базовых типов данных. Узел (Node) - представление участника в системной среде. Узел может действовать во многих ролях, включая таковые для потребителя услуг и/или поставщика услуг. Узлы могут быть реализованы в разнообразных формах, включая устройства бытовой электроники, программные агенты, такие как программы воспроизведения мультимедиа, или виртуальные поставщики услуг, такие как машины поиска содержимого, поставщики лицензий DRM или хранители содержимого. Устройство (Device) - заключает в себе представление виртуального или физического устройства. Пользователь (User) - заключает в себе представление пользователя клиента.- 11008614 Запрос (Request) - заключает в себе запрос на услугу на набор намеченных узлов. Ввод запроса (Request Input) - заключает в себе входные данные для запроса. Ответ (Response) - заключает в себе ответ, соотнесенный с запросом. Результат запроса (Request Result) - заключает в себе результаты внутри ответа, соотнесенного с некоторым запросом. Услуга (Service) - заключает в себе представление набора строго определенных функциональных возможностей, раскрытых или предлагаемых узлом поставщика. Это может быть, например, функциональной возможностью низкого уровня, предлагаемой в пределах устройства, такого как сотовый телефон (например, услуга распознавания речи), или многоаспектной функциональной возможностью, предлагаемой по глобальной сети (например, заказ товаров). Услуги могут охватывать широкое множество приложений, включая связанные с DRM услуги, такие как персонализация клиента и приобретение лицензий. Поставщик услуг (Service Provider) - объектная сущность (например, узел или устройство), которая предоставляет некоторый набор услуг. Возможные поставщики услуг включают в себя устройства бытовой электроники, такие как сотовые телефоны, персональные цифровые ассистенты (PDA), портативные устройства воспроизведения мультимедиа и домашние шлюзы, а также сетевые операторы (такие как центральная станция кабельного телевидения), поставщики услуг сотовой связи, розничные торговцы,использующие Web, и поставщики лицензий на содержимое. Интерфейс услуги (Service Interface) - строго определенный способ взаимодействия с одной или несколькими услугами. Привязка услуги (Service Binding) - заключает в себе конкретный способ обмена информацией с услугой, включая соглашения и протоколы, используемые для вызова интерфейса услуги. Они могут быть представлены рядом строго определенных способов, таких как стандартный протокол XML организацииWS-I, протокол RPC (удаленного вызова процедур) на основании WSDL-определения или вызов функции из динамически подключаемой библиотеки (DLL). Точка доступа к услугам (SAP -Service Access Point) - заключает в себе функциональные возможности, необходимые для предоставления возможности узлу осуществлять запрос вызова услуги на намеченный набор предоставляющих услугу узлов и принимать набор ответов. Блок подборки последовательности операций (WFC - Workflow Collator) - механизм компоновки услуг, который обеспечивает общий интерфейс, позволяющий узлу управлять и обрабатывать совокупности запросов и ответов, связанные с вызовами услуг. Этот интерфейс обеспечивает основные компоновочные блоки, чтобы компоновать услуги через управление сообщениями, соотнесенными с услугами. В контексте конкретного приложения, например цифрового управления правами (DRM), типичный профиль может включать в себя различные связанные с DRM услуги (описанные ниже) для нижеследующего набора объектов для защиты содержимого и управления, которые представляют объектные сущности в системе, защищают содержимое, соотносят правила использования с содержимым и определяют, может ли быть предоставлен доступ, если запрошена: Ссылка на содержимое (Content Reference) - заключает в себе представление ссылки или указателя на элемент содержимого. Такая ссылка обычно будет выгодным образом использовать другие стандартизованные способы описания формата содержимого, местоположения и т.д. Ссылка на DRM (DRM Reference) - заключает в себе представление ссылки или указателя на описание формата цифрового управления правами. Связь (Link) - связи между объектными сущностями (например, узлами). Содержимое (Content) - представляет мультимедийное или другое содержимое. Ключ содержимого (Content Key) - представляет ключи шифрования, используемые, чтобы шифровать содержимое. Управление (Control) - представляет правила использования или другие правила, которые управляют взаимодействием с содержимым. Контроллер (Controller) - представляет взаимосвязи между объектами "управление" и "ключ содержимого". Составитель проектов (Projector)представляет взаимосвязи между объектами "ключ содержимого" и "содержимое". В одном варианте осуществления базовый профиль включает определения для некоторых или всех из нижеследующих базовых услуг. Авторизация (Authorization) - запрос или ответ на авторизацию некоторого участника на доступ к услуге. Руководство (Governance) - процесс осуществления авторитетного или доминирующего влияния над некоторым элементом (например, музыкальным файлом, документом или операцией объекта "услуга"), такого как возможность загружать и устанавливать обновление программного обеспечения. Объект"руководство" обычно взаимодействует с "услугами", обеспечивающими функциональные возможности,такие как доверительное управление, управление политикой и защита содержимого. Маршрутизация сообщения (Message Routing) - "запрос" или "ответ", чтобы обеспечить функцио- 12008614 нальную возможность маршрутизации сообщений, включая возможность для предоставляющего услугу узла пересылать сообщение или осуществлять накапливание и сборку сообщений. Регистрация узла (Node Registration) - запрос или ответ на выполнение операций регистрации для"узла", таким образом позволяя "узлу" быть обнаруживаемым через промежуточный узел. Обнаружение узла (опрос) (Node Discovery (Query - запрос или ответ, относящийся к обнаружению узлов. Уведомление (Notification) - запрос или ответ, чтобы посылать или доставлять на заданный набор узлов намеченные сообщения уведомления. Обмен мандатом защиты (Security Credential Exchange) - запрос или ответ, относящийся к предоставлению возможности узлам обмениваться связанной с защитой информацией, такой как пары ключей,сертификаты или подобной. Обнаружение услуги (опрос) (Service Discovery (Query -запрос или ответ, относящийся к обнаружению услуг, предоставляемых некоторым набором из одного или нескольких узлов. Компоновка услуг (Service Orchestration) - сборка и координация услуг в управляемые, грубоукрупненные услуги, повторно используемые компоненты или полные приложения, которые строго придерживаются правил, указанных поставщиком услуг. Примеры включают в себя правила, основанные на идентификационных данных поставщика, типе услуги, способе, которым осуществляют доступ к услугам, порядке, в котором составляют услуги, и т.д. Доверительное управление (Trust Management) - обеспечивает общий набор соглашений и протоколов для создания авторизованных и доверительных контекстов для взаимодействий между узлами. В некоторых вариантах осуществления доверительное управление NEMO может усиливать и/или расширять существующие технические условия и механизмы защиты, включая WS-Security и WS-Policy в доменWeb-услуг. Обновление (Upgrade) - представляет запрос или ответ, относящийся к приему обновления функциональных возможностей. В одном варианте осуществления эта услуга является чисто абстрактной,причем другие профили обеспечивают конкретные представления. 1.5. Иллюстративное взаимодействие между узлами. Как будет обсуждено более подробно ниже, базовое логическое взаимодействие между двумя системными узлами, запрашивающим услугу и поставщиком услуг, обычно включает в себя нижеследующую последовательность событий. С точки зрения запрашивающего услугу узла, запрашивающий услугу узел осуществляет запрос обнаружения услуги, чтобы определить местоположение каких-либо поддерживающих NEMO узлов, которые могут обеспечивать необходимую услугу, используя заданные привязки услуг. Узел может выбрать кэширование информации об обнаруженных услугах. Интерфейс/механизм для обнаружения услуг между узлами может быть лишь другой услугой, которую узел NEMO выбирает для реализации. Как только возможные предоставляющие услугу узлы обнаружены, запрашивающий узел может выбрать диспетчеризацию запроса на один или несколько предоставляющих услугу узлов на основании конкретной привязки услуги. В одном варианте осуществления два узла, которые желают обмениваться информацией между собой безопасно, будут устанавливать доверительные отношения с целью обмена WSDL-сообщениями. Например, они могут согласовать набор совместимых мандатов доверительности (например, сертификаты по протоколу Х.500, ключи устройства и т.д.), которые могут использоваться в определении идентификационных данных, верификации авторизации, установлении защищенного канала и т.д. В некоторых случаях согласование этих мандатов может быть неявным свойством привязки интерфейса услуги (например, WS-Security, если используется протокол XML WS-I, или запрос SSL между двумя хорошо известными узлами). В других случаях согласование мандатов доверительности может быть явно отдельным этапом. В одном варианте осуществления именно данному узлу предстоит определить, какие мандаты являются достаточными для взаимодействия с другим узлом, и принимать решение, что он может доверять данному узлу. Запрашивающий узел создает подходящее WSDL-сообщение(я) запроса, которое соответствует запрошенной услуге. Как только сообщения созданы, их посылают на намеченный предоставляющий услугу узел(ы). Стиль обмена информацией для запроса может быть, например, стилем синхронного или асинхронногоRPC или ориентированным на сообщение, основанным на привязке услуги. Диспетчеризация запросов услуг и прием ответов могут быть осуществлены непосредственно устройством или через услугу-посредник NEMO. Услуга-посредник (описанная ниже) обеспечивает абстракцию и интерфейс для посылки сообщений другим участникам и может скрывать некоторые вопросы привязки услуги, такие как совместимые форматы сообщений, механизмы транспортировки, вопросы маршрутизации сообщений и т.д. После диспетчеризации запроса запрашивающий узел будет обычно принимать один или несколько ответов. В зависимости от конкретных особенностей привязки интерфейса услуги и предпочтений запрашивающего узла ответ(ы) может быть возвращен различными способами, включая, например, ответ в стиле RPC или сообщение уведомления. Ответ по маршруту на намеченный узел(ы) может проходить- 13008614 через другие промежуточные узлы, которые могут предоставлять ряд подходящих услуг, включая, например, функции маршрутизации, доверительного согласования, подборки и корреляции и т.д. Запрашивающий узел проверяет ответ(ы), чтобы гарантировать, что он соблюдает договорную доверительную семантику между ним и предоставляющим услугу узлом. Затем применяется надлежащая обработка на основании типа полезной нагрузки и содержимого сообщения. С точки зрения предоставляющего услугу узла, последовательность событий обычно будет включать в себя нижеследующее. Определение того, поддерживается ли запрошенная услуга. В одном варианте осуществления инфраструктура NEMO не предписывает стиль или степень детализации того, как интерфейс услуги отображается в виде точки входа на услугу. В самом простом случае интерфейс услуги может отображаться однозначно на заданную услугу, и действие по привязке к ней и ее вызова может составлять поддержку для услуги. Однако в некоторых вариантах осуществления одиночный интерфейс услуги может обрабатывать многие типы запросов; и заданный тип услуги может содержать дополнительные атрибуты, которые должны быть рассмотрены прежде, чем может быть сделано определение того, что узел поддерживает конкретно требуемую функциональную возможность. В некоторых случаях для поставщика услуг может быть необходимым определить, доверяет ли он запрашивающему узлу, и согласовать набор совместимых мандатов доверительности. В одном варианте осуществления независимо от того, определяет ли поставщик услуг доверие, некоторая политика, связанная с интерфейсом услуги, будет все же применяться. Поставщик услуг определяет и посылает запрос(ы) авторизации на этот узел(ы), ответственный за авторизацию доступа к интерфейсу, чтобы определить, имеет ли доступ запрашивающий узел. Во многих ситуациях узел авторизации и предоставляющий услугу узел будут одной и той же объектной сущностью, и диспетчеризация и обработка запроса авторизации будут локальными операциями, вызываемыми через упрощенную привязку интерфейса услуги, такую как точка входа функции на языке С. Приняв ответ на запрос авторизации, если запрашивающий узел является авторизованным, поставщик услуг будет выполнять запрос. Если не является, может быть сформировано подходящее сообщение ответа. Сообщение ответа возвращают на основании привязки интерфейса услуги и предпочтений запрашивающего узла. По маршруту на запрашивающий узел сообщение может проходить через другие промежуточные узлы, которые могут предоставлять услуги необходимые или "добавленной ценности". Например, промежуточный узел может обеспечивать маршрутизацию, доверительное согласование или доставку на узел обработки уведомлений, который может доставить сообщение способом, приемлемым для запрашивающего узла. Примером услуги "добавленной ценности" является купонная услуга, которая присоединяет купоны к сообщению, если она знает об интересах запрашивающего узла. 2. Архитектура системы. Рассматривается примерное осуществление системной инфраструктуры NEMO, проиллюстрированной на фиг. 1, реализующей приложение DRM. Как отмечено выше, узлы NEMO могут взаимодействовать, осуществляя запросы вызова услуг и прием ответов на запросы. Инфрастуктура NEMO поддерживает создание разнообразных и развитых схем обмена информацией, находящихся в пределах от простого двухточечного взаимодействия с единственным поставщиком услуг до сложного объединения скомпонованного в целое набора услуг от многих поставщиков услуг. В контексте фиг. 1, узлы NEMO взаимодействуют между собой, чтобы обеспечивать множество услуг, которые в совокупности осуществляют систему лицензирования музыкальных произведений. Музыкальное произведение, хранимое в защищенном хранилище 110 музыкальных произведений потребителя, может быть извлечено Web-торговцем 120 музыкальными произведениями и предоставлено конечным пользователям в их домах через их домашний шлюз 130 развлекательных услуг. Музыкальное произведение из защищенного хранилища 110 музыкальных произведений потребителя может включать в себя правила, которые управляют условиями, при которых такое музыкальное произведение можно предоставлять Web-торговцу 120 музыкальными произведениями и впоследствии другим для дальнейшего использования и распределения. Домашний шлюз 130 развлекательных услуг является средством передачи, посредством которого такое музыкальное произведение (а также видео и другое содержимое) можно запускать, например, на домашнем ПК пользователя (например, посредством устройства 140 воспроизведения видео на базе персонального компьютера) или на пользовательском портативном устройстве воспроизведения (например, портативное устройство 150 воспроизведения музыкальных произведений). Пользователь может путешествовать, например, вместе с портативным устройством 150 воспроизведения музыкальных произведений и получать через беспроводное соединение с Интернет (например, со службой 160 лицензий на цифровые права) лицензию на покупку дополнительных песен, или повторное воспроизведение имеющихся песен дополнительное количество раз, или даже на добавление новых свойств портативному устройству 150 воспроизведения музыкальных произведений через службу 170 обновления программного обеспечения.- 14008614 Узлы NEMO могут взаимодействовать между собой и с другими устройствами разнообразными различными способами. Хост NEMO, как проиллюстрировано на фиг. 2 а, является некоторым видом компьютера или устройства, содержащего по меньшей мере один узел NEMO. Хост может постоянно находиться в пределах персональной сети 210 или на удаленном местоположении 220, доступном через Интернет. Хост может, например, быть сервером 230, настольным ПК 240, портативной ЭВМ 250 или персональным цифровым ассистентом 260. Узел NEMO является программным агентом, который может поставлять услуги на другие узлы (такие, как хост 235, обеспечивающий Web-услуги третьих сторон), а также вызывать услуги других узлов в пределах управляемой на основе NEMO инфраструктуры. Некоторые узлы 270 присоединены к другому хосту через специализированный коммуникационный канал, такой как Bluetooth. Эти хосты 240 и 250 оснащены возможностью сетевого соединения и достаточной вычислительной мощностью, чтобы представлять виртуальный узел для других участвующих узлов NEMO. Как иллюстрировано на фиг. 2b, узел NEMO может быть полным одноранговым узлом в пределах локальной или персональной сети 210. Узлы совместно используют симметричную возможность раскрытия и вызова услуг; однако, каждый узел обычно не предлагает одинаковые наборы услуг. Узлы могут извещать и/или являться конкретно запрашиваемыми об услугах, которые они выполняют. Если присутствует соединение с Интернет, как показано на фиг. 2 с, то локальные узлы NEMO (например, в пределах персональной сети 210) также могут осуществлять доступ к услугам удаленных узлов 220. В зависимости от конфигурации и политики локальной сети является также возможным для локальных и удаленных узлов (например, хосты 280 системы NEMO с поддержкой Интернет) взаимодействовать как одноранговые узлы NEMO. Как проиллюстрировано на фиг. 2d, не все узлы NEMO могут быть на хостах, способных обмениваться информацией с другими хостами, либо локальными, либо удаленными. Хост 280 NEMO может обеспечивать шлюзовую услугу, посредством которой один узел может вызывать услуги другого, например присоединенного узла 285 или узлов в персональной сети 210. Как проиллюстрировано на фиг. 2 е, узел 295 на присоединенном устройстве может осуществлять доступ к услугам других узлов через шлюз, как обсуждено выше. К нему также могут осуществлять доступ другие узлы через услугу-посредник на другом хосте 290. Услуга-посредник образует виртуальный узел, исполняющийся на хосте NEMO. Эти узлы-посредники могут быть полными одноранговыми узлами NEMO. Как иллюстрировано на фиг. 2f, хост NEMO может обеспечивать специализированную поддержку для присоединенных устройств посредством адаптеров узла NEMO. Частный коммуникационный канал 296 используется между адаптером 297 хоста NEMO/устройства и присоединенным узлом 298 с использованием любого подходящего протокола. Присоединенный узел 298 не видит другие одноранговые узлы NEMO и не является видимым для них. Следующим рассматривается примерная функциональность цифрового управления (DRM) правами,которая может быть обеспечена поддерживающими NEMO устройствами в некоторых вариантах осуществления или которая может использоваться вне контекста NEMO. Как предварительно описано, одна из первичных целей предпочтительного варианта осуществления системной среды NEMO состоит в том,чтобы поддерживать разработку защищенных, переносимых взаимосвязей между относящимися к мультимедиа услугами, охватывающими и коммерческие, и ориентированные на потребителя ярусы сети. В дополнение к связности услуг, возможность взаимодействия между относящимися к мультимедиа услугами будет обычно требовать скоординированного управления правами на использование в применении к содержимому, доступному посредством этих услуг. Услуги NEMO и примерное средство DRM, описанные в документе, могут использоваться в комбинации, чтобы достичь возможности взаимодействия,которая позволяет устройствам на основании инфраструктуры NEMO предоставлять потребителям восприятие плавного впечатления от воспроизведения и использования, даже несмотря на неоднородную инфраструктуру DRM и формата мультимедиа. В контексте приложения DRM, как проиллюстрировано на фиг. 3, сеть из поддерживающих NEMODRM-устройств может включать в себя поставщик/сервер 310 содержимого, который составляет пакеты содержимого для других DRM-устройств, а также бытовое устройство 330 воспроизведения на базе ПК и бытовое устройство 320 на базе ПК для составления пакетов/воспроизведения, которое может не только воспроизводить защищенное содержимое, но также может составлять пакеты содержимого для доставки на портативное устройство 340. В каждом DRM-устройстве средство DRM выполняет конкретные функции DRM (например, соблюдение условий лицензии, доставка ключей на хост-приложение и т.д.) и основывается на хостприложении для тех услуг, которые могут быть наиболее эффективно обеспечены хостом, таких как шифрование, расшифровывание и управление файлами. Как будет обсуждено более подробно ниже, в одном варианте осуществления средство DRM включает в себя виртуальную машину (VM), предназначенную для определения того, являются ли допустимыми некоторые действия над защищенным содержимым. Эта управляющая VM может быть реализована в виде простого, на основе стека процессора с минимальным набором команд. В одном варианте осу- 15008614 ществления она способна выполнять логические и арифметические вычисления, а также запрашивать информацию состояния из хост-среды, чтобы проверять параметры, такие как системное время, состояние счетчика и т.д. В одном варианте осуществления средство DRM использует алгоритм на основе графа, чтобы проверять взаимосвязи между объектными сущностями в цепочке ценностей DRM. На фиг. 4 проиллюстрировано концептуальное осуществление такого графа. Граф содержит совокупность узлов или вершин,соединенных связями. Каждая объектная сущность в системе может быть представлена объектом "вершина". Только объектные сущности, на которые должны осуществляться ссылки посредством объектов"связь" или которые являются получателями криптографически заданной информации, должны иметь соответствующие объекты "вершина". В одном варианте осуществления вершина обычно представляет пользователя, устройство или группу. Объекты "вершина" также имеют соотнесенные с ними атрибуты,которые представляют некоторые свойства объектной сущности, соотнесенной с вершиной. Например, на фиг. 4 показаны два пользователя (Хаn и Knox), два устройства (Маc и портативное устройство) и несколько объектов, представляющих группы (члены семейства Carey, члены общедоступной библиотеки, абоненты конкретной музыкальной услуги, соответствующие требованиям Ассоциации индустрии звукозаписи США (RIAA) устройства, а также устройства, изготовленные конкретной компанией). Каждый из них имеет объект "вершина", соотнесенный с ним. Семантика связей может изменяться способом, специфическим для конкретного приложения. Например, направленное ребро от вершины Маc к вершине Knox может означать, что Knox является владельцем Маc. Ребро от Knox до общедоступной библиотеки может указывать, что Knox является членом общедоступной библиотеки. В одном варианте осуществления средство DRM не налагает или интерпретирует эту семантику - он просто устанавливает существование или несуществование путей в графе. Этот граф из вершин может считаться графом "авторизации" в том, что существование пути или отношения (прямого или косвенного) между двумя вершинами можно интерпретировать как разрешение для одной вершины на доступ к другой вершине. Например, поскольку Knox является связанным с семейством Carey и семейство Carey является связанным с музыкальной службой, имеется путь между Knox и музыкальной службой. Вершину "музыкальная служба" считают достижимой из другой вершины, если имеется путь из этой вершины к "музыкальной службе". Это дает возможность записать управление, которое предоставляет разрешение на доступ к защищенному содержимому, на основании условия, что музыкальная служба будет достижимой из портативного устройства, в котором исполняется приложение, запрашивающее доступ (например, хостприложение клиента DRM). Например, владелец содержимого может создать управляющую программу, подлежащую интерпретации управляющей VM, которая позволяет воспроизведение конкретного фрагмента музыкального произведения, если потребительское устройство принадлежит члену общедоступной библиотеки и соответствует требованиям RIAA. Когда управляющая VM, исполняющаяся на устройстве, вычисляет эту управляющую программу, средство DRM определяет, существуют ли "связи" между портативным устройством и общедоступной библиотекой и между портативным устройством и устройством, соответствующим требованиям RIAA. Ребра и вершины графа могут быть статическими и встроенными в устройства или могут быть динамическими и находимыми через услуги, взаимодействующие с хост-приложением. Не накладывая семантики на вершины и связи, средство DRM может обеспечить значительную гибкость. Система может быть приспособлена для многих моделей использования, от традиционных систем политик на основе делегирования полномочий до авторизованных доменов и персональных сетей. В одном варианте осуществления клиент DRM также может повторно использовать граф авторизации для образования ключа защиты содержимого. Системные проектировщики могут выбирать, чтобы позволить существованию связи также обозначать совместное использование некоторой криптографической информации. В таких случаях граф авторизации можно использовать, чтобы получать ключи содержимого без явной криптографической перенастройки потребительских устройств. 3. Архитектура узла. 3.1. Краткий обзор. Любой тип устройства (физического или виртуального), включая оборудование бытовой электроники, сетевые службы или программных клиентов, может быть потенциально поддерживающим NEMO,что означает, что функциональные возможности устройства могут быть расширены таким образом, чтобы допускать участие в системе NEMO. В одном варианте осуществления поддерживающее NEMO устройство (узел) является концептуально составленным из некоторых стандартных модулей, как проиллюстрировано на фиг. 5 а.API 510 внутренних услуг представляет логический набор из одной или нескольких услуг, которые реализует устройство. Не имеется требования, чтобы узел NEMO предоставлял какую-либо услугу прямо или косвенно. Реализация 520 внутренних услуг представляет соответствующий набор из реализаций дляAPI внутренних услуг. Точка 530 доступа к услугам обеспечивает поддержку для вызова предоставляемых интерфейсов услуг. Она заключает в себе функциональные возможности, необходимые, чтобы предоставлять возмож- 16008614 ность узлу NEMO осуществлять запрос вызова услуги на намеченный набор предоставляющих услугу узлов NEMO и принимать набор ответов. Поддерживающие NEMO узлы могут использовать разнообразные протоколы обнаружения, разрешения имен и транспортные протоколы, что неизбежно влечет создание гибкого и расширяемого коммуникационного API. Точка доступа к услугам может быть осуществлена различными способами, приспособленными к конкретной среде исполнения и стилю инфраструктуры приложений. Одной обычной обобщенной моделью для ее интерфейса будет интерфейс, способный принимать XML-сообщения в некоторой форме и возвращать XML-сообщения. Другие модели в большей степени внутренних интерфейсов также могут быть поддержаны. Уровень 540 адаптации услуг NEMO представляет необязательный уровень, через который к раскрытому поднабору внутренних услуг объекта осуществляют доступ, используя одну или несколько обнаруживаемых привязок. Это обеспечивает уровень абстракции выше API внутренних услуг, давая возможность поставщику услуг более легко поддерживать многие типы привязок интерфейсов услуг. В ситуациях, в которых уровень адаптации услуг не присутствует, все же может быть возможным взаимодействие с услугой непосредственно через точку 530 доступа к услугам, если она поддерживает необходимые коммуникационные протоколы. Уровень 540 адаптации услуг обеспечивает обычный способ для поставщиков услуг предоставлять услуги, обрабатывать запросы и ответы и компоновать услуги в среде NEMO. Он является логической точкой, в которой услуги опубликованы, и обеспечивает основу, на которой должны быть реализованы другие конкретные привязки интерфейсов услуг. В дополнение к обеспечению обычного пути предоставления внутренних услуг поставщика услуг для других поддерживающих NEMO узлов, уровень 540 адаптации услуг также обеспечивает естественное место, на котором создают уровни компонентов для поддержки дополнительных привязок 560 интерфейсов услуг, как иллюстрировано на фиг. 5b. Поддерживая дополнительные привязки интерфейсов услуг, поставщик услуг повышает вероятность того, что совместимая привязка будет иметь возможность быть согласованной и используемой либо через точку доступа к услугам, либо через некоторый другой внутренний API. Возвращаясь к фиг. 5 а, блок 550 подборки последовательности операций обеспечивает поддержку управления сообщениями услуг и компоновкой услуг. Он обеспечивает обычный интерфейс, дающий возможность узлу управлять и обрабатывать совокупности сообщений ответов и запросов. Этот интерфейс, в свою очередь, обеспечивает базовые компоновочные блоки, чтобы компоновать услуги через управление сообщениями, соотнесенными с этими услугами. Этот интерфейс обычно реализуется узлом,который поддерживает функциональные возможности маршрутизации сообщений, а также промежуточное формирование очередей сообщений и подборку сообщений. В некоторых вариантах осуществления инфраструктура NEMO включает в себя совокупность дополнительных необязательных услуг поддержки, которые содействуют участию объектной сущности в сети. Такие услуги могут быть разбиты на категории согласно различным типам функциональных возможностей, а также типам объектных сущностей, требующих такие услуги (например, услуги, поддерживающие приложения клиента, в отличие от таковых, требуемых поставщикам услуг). Типичные поддерживающие услуги включают в себя нижеследующее. Процедуры форматирования и манипулирования WSDL - обеспечивают функциональные возможности для создания и манипулировании основанных на WSDL сообщений услуг. Кэш услуг - обеспечивает обычный интерфейс, дающий возможность узлу управлять совокупностью отображений между обнаруженными узлами и услугами, которые они поддерживают. Интерфейс процессора уведомлений - обеспечивает обычный интерфейс поставщика услуг, предназначенный для расширения узла NEMO, который поддерживает обработку уведомлений для некоторого строго определенного средства обработки уведомлений. Разнородные функциональные возможности поддержки - включают в себя процедуры для формирования идентификаторов (ID) сообщений, отметок времени и т.д. 3.2. Базовое взаимодействие узла. Перед исследованием отдельных архитектурных элементов узлов NEMO более подробно является полезным понять способ, которым такиеузлы взаимодействуют и обмениваются информацией между собой. Поддержаны разнообразные стили обмена информацией, в пределах от синхронного и асинхронного обмена информацией в стиле RPC до односторонних вызовов интерфейса и обратных вызовов клиента. Стиль доставки асинхронного RPC - эта модель является особенно пригодной, если ожидают, что выполнение запроса потребует увеличенной продолжительности времени, и клиент не захочет ждать. Клиент подает запрос с ожиданием, что он будет обработан асинхронно произвольными предоставляющими услугу узлами. В этом случае предоставляющая услугу оконечная точка может отвечать, указывая,что она не поддерживает эту модель, или, если обеспечивающий услугу узел поддерживает эту модель,она возвратит ответ, который будет нести жетон, который может быть подан на заданный обеспечивающий услугу узел в последующих запросах, чтобы определить, имеет ли он ответ на запрос клиента. В одном варианте осуществления любая предоставляющая услугу оконечная точка, которая под- 17008614 держивает эту модель, обязана кэшировать на основании внутренней политики ответы на ожидающие запросы клиента. Если клиент пытается изъять жетон, связанный с таким запросом, и ответа нет в наличии или ответ был отброшен предоставляющим услугу узлом, то возвращают ответ о соответствующей ошибке. В этом варианте осуществления клиенту предстоит определить, когда он будет осуществлять такие последующие запросы в попытке изъять жетон для ответов. Стиль доставки синхронного RPC - клиент подает запрос и затем ожидает один или несколько ответов, которые должны быть возвращены. Предоставляющая услугу поддерживающая NEMO оконечная точка может отвечать, указывая, что она не поддерживает эту модель. Стиль доставки на основе сообщений - клиент подает запрос, указывающий, что он желает принимать любые ответы посредством уведомления о сообщении, соотнесенного с одним или несколькими его интерфейсами услуг обработки уведомлений. Предоставляющая услугу поддерживающая NEMO оконечная точка может отвечать, указывая, что она не поддерживает эту модель. С точки зрения приложения клиента, ни одна из вышеупомянутых схем взаимодействия не требует архитектуры, которая должна блокировать и ожидать ответы или должна явно голосовать. Возможно использовать организацию потоков или другие специфические для конкретной платформы механизмы,чтобы моделировать семантику как блокирования, так и неблокирования вместе с вышеупомянутыми механизмами стиля доставки. Также ни один из вышеупомянутых стилей не предназначен, чтобы непосредственно решить вопросы, связанные с задержками для заданного коммуникационного канала - только с возможной задержкой, связанной с фактическим выполнением запроса. На механизмы решения проблем, ассоциированных с задержкой коммуникационного канала, должно быть обращено внимание в конкретной реализации компонента, такого как точка доступа к услугам, или непосредственно в пределах осуществления клиента. 3.3. Точка доступа к услугам. Как отмечено выше, точка доступа к услугам (SAP) может использоваться в качестве обычного, повторно используемого API для вызова услуг. Это может заключать в себе согласование и использование транспортного канала. Например, некоторые транспортные каналы могут требовать установки сеансаSSL поверх протокола TCP/IP (протокол управления передачей/межсетевой протокол), тогда как некоторые каналы могут только поддерживать относительно ненадежную связь по протоколу UDP/IP (протокол дейтаграмм пользователя/межсетевой протокол), а некоторые другие могут не быть основанными на IPпротоколе вообще.SAP может заключать в себе обнаружение начального набора узлов NEMO для маршрутизации сообщения. Например, абонентская приставка кабельного телевидения может иметь выделенное соединение с сетью и предписывать, чтобы все сообщения проходили через конкретный маршрут и промежуточный узел. Портативное устройство воспроизведения мультимедиа в домашней сети может использовать обнаружение UPnP, чтобы найти множество узлов, которые являются непосредственно доступными. Клиенты могут не быть способными или могут не выбрать общение непосредственно с другими узламиNEMO посредством обмена XML-сообщениями. В этом случае может использоваться версия SAP, которая предоставляет и использует любой внутренний интерфейс, который поддерживается. В предпочтительном варианте осуществления пример SAP поддерживает нижеследующие две общие модели обмена информацией (хотя могут быть поддержаны комбинации этих двух, а также другие):(i) основанную на сообщениях (как обсуждено выше) - в которой SAP формирует XML-сообщения запроса и непосредственно осуществляет обмен сообщениями NEMO с поставщиком услуг через некоторую привязку интерфейса; или (ii) внутреннюю - в которой SAP может взаимодействовать с поставщиком услуг через некоторый внутренний коммуникационный протокол. SAP может внутренне преобразовывать в XML-сообщения/из XML-сообщений, определенных где-либо в пределах инфраструктуры. Примерное взаимодействие между двумя одноранговыми узлами NEMO проиллюстрировано на фиг. 6 а. Узел 610 клиента взаимодействует с предоставляющим услугу узлом 660, используя точку 620 доступа к услугам (SAP) инфраструктуры NEMO. В этом примере протоколы и стандарты Web-услуг используются и для предоставления услуг, и для транспорта. Предоставляющий услугу узел 660 использует свой уровень 670 Web-услуг (используя, например, WSDL и передачу сообщений на основе SOAP),чтобы предоставлять его услуги клиентам, таким как узел 610. Уровень 630 Web-услуг узла 610 клиента создает и интерпретирует сообщения SOAP с помощью уровня 640 отображения (который отображает сообщения SOAP на интерфейс 620 SAP и от него) и уровня 650 обработки управления доверительностью (который может, например, усиливать WS-Security, используя мандаты, переданные в пределах заголовков SOAP). Другой пример взаимодействия между узлами NEMO проиллюстрирован на фиг. 6b. Предоставляющий услугу узел 682 взаимодействует с узлом 684 клиента, используя SAP 686. В этом примере предоставляющий услугу узел 682 включает в себя отличающийся от клиента 684, но переносимый уровень управления доверительностью. В частности, предоставляющий услугу узел 682 включает в себя и средство 688 проверки доверительности, и средство 690 авторизации. В этом примере средство 688 проверки доверительности может быть, в целом, ответственным за выполнение шифрования и дешифрования сообщений SOAP, проверки цифровых сертификатов и выполнение других базовых криптографических- 18008614 операций, тогда как средство 690 авторизации может быть ответственным за принятие решений политики более высокого уровня. В примере, показанном на фиг. 6b, узел 684 клиента включает в себя средство 692 проверки доверительности, а не средство авторизации. Таким образом, в этом примере узел 684 клиента может быть способным выполнять базовые криптографические операции и реализовывать относительно простые политики (например, политики, относящиеся к уровню установления подлинности сообщения, конфиденциальности или подобного), но может основываться на предоставляющем услугу узле 682, чтобы оценивать и реализовывать политики более высокого порядка, руководящие использованием клиентом и взаимодействием клиента с услугами и/или содержимым, поставляемым предоставляющим услугу узлом 682. Должно быть оценено, что фиг. 6b представлена с целью иллюстрации, а не ограничения, и что в других вариантах осуществления узел 684 клиента может также включать в себя средство авторизации, как может быть в случае, если клиент нуждается в соблюдении набора обязательств, связанных с заданной политикой. Таким образом, может быть видно, что различные одноранговые узлыNEMO могут содержать различные части среды управления доверительностью в зависимости от своих требований. На фиг. 6b также проиллюстрировано, что коммуникационная линия между узлами может быть независимой от транспорта. Даже в контексте модели обработки SOAP могут использоваться любое подходящее шифрование данных и/или правила обработки. Например, модель защиты, используемаяXML, может быть заменена другой моделью защиты, которая поддерживает другую схему шифрования. Точка доступа к услугам может быть реализована в различных формах, таких как в пределах границ клиента (в форме совместно используемой библиотеки) или вне границ клиента (в форме агента, исполняющегося в другом процессе). Точная форма осуществления точки доступа к услугам может быть приспособлена к потребностям конкретного типа платформы или клиента. С точки зрения клиента, использование точки доступа к услугам может быть необязательным, хотя, в целом, она обеспечивает существенную пользу, как проиллюстрировано ниже. Точка доступа к услугам может быть реализована в виде статического компонента, поддерживающего только установленный набор привязок услуг протокола, или может быть способной поддерживать новые привязки динамически. Взаимодействия, задействующие точки доступа к услугам, могут быть охарактеризованы по меньшей мере с двух точек зрения - клиентской стороны, которую использует запрашивающий участник, и стороны обслуживания, которая взаимодействует с другими поддерживающими NEMO оконечными точками (узлами). В одном варианте осуществления клиентской стороны, который проиллюстрирован на фиг. 7 а, точка 710 доступа к услугам непосредственно обменивается XML-сообщениями с клиентом 720. Клиент 720 непосредственно формирует сообщения 740 запроса и подает их на точку 710 доступа к услугам, которая формирует и посылает одно или несколько сообщений 750 ответа на клиент 720, где их накапливают,анализируют и обрабатывают. Клиент 720 может также подавать (при создании запросов) явный набор(ы) привязок 730 услуг, чтобы использовать в определении целевого объекта доставки запроса. Эти привязки услуг, возможно, были получены различными способами. Например, клиент 720 может выполнять операции обнаружения услуг и затем выбирать, какие привязки услуг применимы, или он может использовать информацию, полученную из предыдущих ответов. В другом варианте осуществления клиентской стороны, проиллюстрированном на фиг. 7b, точка 760 доступа к услугам непосредственно поддерживает внутренний протокол 770 клиента 780. Точка 760 доступа к услугам будет внутренне преобразовывать сообщения между XML и этим внутренним протоколом 770, таким образом давая возможность клиенту 780 участвовать в пределах системы NEMO. Чтобы задействовать такую поддержку, внутренний протокол 770 (или комбинация внутреннего протокола 770 и среды исполнения) должен обеспечивать любую необходимую информацию в некоторой форме для точки 760 доступа к услугам, который формирует подходящий запрос и, в случае необходимости,определяет подходящую целевую привязку услуги. На стороне обслуживания могут быть поддержаны многие схемы взаимодействия между клиентской точкой доступа к услугам и предоставляющими услугу поддерживающими NEMO оконечными точками. Как и в случае клиентской стороны, шаблоны взаимодействия могут быть приспосабливаемыми и могут изменяться на основании разнообразных критериев, включая вид запроса, лежащую в основе коммуникационную сеть и вид прикладных и/или транспортных протоколов, ассоциированных с какимилибо целевыми привязками услуг. Относительно простой тип схемы взаимодействия стороны обслуживания проиллюстрирован на фиг. 7 с, в котором точка 711 доступа к услугам взаимодействует непосредственно с требуемым предоставляющим услугу узлом 712 способом "точка-точка". Возвращаясь к фиг. 7d, точка 721 доступа к услугам может инициировать взаимодействие непосредственно с (и может принимать ответы непосредственно от) многими потенциальными поставщиками 725 услуг. Этот тип схемы взаимодействия может быть осуществлен посредством ретрансляции множества привязок услуг от клиента для использования точкой 721 доступа к услугам; или точка 721 доступа к услугам может использовать сеть широковещательной или многоадресной передачи для ретрансляции сообщений. На основании предпочтений, заданных в запросе, точка 721 доступа к услугам может вы- 19008614 брать накопление и подборку ответов либо просто возврат первого приемлемого ответа. На фиг. 7 е точка 731 доступа к услугам непосредственно не обменивается информацией с какимилибо целевыми предоставляющими услугу оконечными точками 735. Вместо этого, запросы направляются через промежуточный узел 733, который передает запрос, принимает какие-либо ответы и передает их обратно на точку 731 доступа к услугам. Такая схема взаимодействия может быть желательна, если точка 731 доступа к услугам не способна или не желает поддерживать непосредственно какую-либо из привязок услуги, которые соотнесены с предоставляющими услугу оконечными точками 735, но может устанавливать отношения с промежуточным узлом 733, который желает действовать в качестве шлюза. В качестве альтернативы, клиент может не быть способен обнаруживать или иным образом определять привязки услуг для любых подходящих предоставляющих услугу узлов, но может пожелать позволить промежуточному узлу 733 попытаться найти каких-либо подходящих поставщиков услуг. Наконец, точка 731 доступа к услугам может пожелать воспользоваться преимуществом промежуточного узла 733, поскольку он поддерживает более надежные функциональные возможности накопления и подбора, которые, в свою очередь, дают возможность более гибких схем обмена информацией между точкой 731 доступа к услугам и поставщиками услуг, такими как узлы 735 оконечных точек. В дополнение к вышеупомянутым основным схемам взаимодействия для стороны обслуживания,комбинации таких схем или новые схемы могут быть реализованы в пределах точки доступа к услугам. Хотя точка доступа к услугам предназначена для обеспечения обычного интерфейса, ее реализация будет обычно строго привязываться к характеристикам моделей обмена информацией и ассоциированных протоколов, используемых заданными поддерживающими NEMO оконечными точками. На практике точка доступа к услугам может использоваться, чтобы заключать в себе логику обработки для маршалинга (упаковки в формат передачи по сети) и демаршалинга (распаковки в формат получателя) для относящихся к вводу/выводу (I/O) данных, такую как преобразование формы объектов к подходящим представлениям, таким как XML-представление (с форматом, выраженным в WSDL), или такое, которое создает в надлежащем формате конверты кодированных в XML объектов. В предпочтительном варианте осуществления SAP также заключает в себе логику для обмена информацией через один или несколько поддержанных прикладных, сеансовых и/или транспортных протоколов, таких как вызов услуг по протоколу HTTP, использующему конверты SOAP. Наконец, в некоторых вариантах осуществления SAP может заключать в себе логику обеспечения целостности и конфиденциальности сообщения, такую как поддержка установления сеансов SSL/TLS и/или подписание/верификация данных согласно стандартам, таким как XML-Signature (цифровая подпись XML) и XML-Encryption (шифрование XML) . Когда конкретный адрес интерфейса услуги является неизвестным или неуказанным (например, при вызове услуги через многие узлы на основании некоторых критериев поиска), SAP может заключать в себе логику установления начального соединения с заданным по умолчанию/начальным набором узлов NEMO, где услуги могут быть находимыми или разрешаемыми. Нижеследующее является примером неограничительного варианта осуществления описания высокоуровневого API, экспортируемого одним из вариантов осуществления SAP:ServiceAccessPointCreate(Environment[])ServiceAccessPoint - это одноэлементный интерфейс,который возвращает инициализированный экземпляр SAP. SAP может быть инициализирован на основании дополнительного необязательного набор параметров среды.ServiceAccessPointInvokeService(Serviсе Request Message, Boolean)Service Response Message API синхронного вызова услуги поддерживается в тех случаях, когда клиент (используя WSDL) составляет XML-сообщение запроса услуги и в ответ принимает XML-сообщение. API также принимает флажок Boolean, указывающий, должен ли клиент ожидать ответ. Обычно значение флажка будет "истина",кроме случая сообщений без соотнесенного ответа или сообщений, на которые ответы будут доставлены обратно асинхронно через другой канал (например, через уведомление). Результирующее сообщение также может передавать некоторое результирующее состояние ошибки.ServiceAccessPointApplyIntegrityProtection(Boolean, Desc[])Boolean) - этот API дает возможность вызывающему задавать, должна ли применяться защита целостности и к каким элементам в сообщении она должна применяться.ServiceAccessPointApplyConfidentiality(Boolean, Desc[])Boolean - этот API позволяет вызывающему задавать, должна ли применяться конфиденциальность и каким элементам в сообщении она должна применяться.ServiceAccessPointSetKeyCallbacks(SigningKeyCallback, SignatureVerificationKeyCallback, EncryptionKeyCallback, DecryptionKeyCallback)Boolean - как обозначено в предыдущих API, когда сообщение посылается или принимается, оно может содержать объекты, которые требуют защиты целостности или конфиденциальности. Этот API позволяет клиенту устанавливать любые необходимые перехватывающие процедуры между собой и API, чтобы давать возможность API получать ключи, соотнесенные с конкретным типом операции управления доверительностью. В одном варианте осуществления интерфейс основан на процедурах обратного вызова, поддерживающих защиту целостности через осуществление цифровой подписи и проверки, и конфиденциальность через шифрование и дешифрование. В одном ва- 20008614 рианте осуществления каждый из обратных вызовов имеет формуKeyCallback(KeyDesc)Key[] причем KeyDesc является необязательным объектом, описывающим требуемый ключ(и) и возвращаемый перечень подходящих ключей. Цифровые подписи проверяются на действительность как часть приема ответных сообщений услуг при использовании API InvokeService. Если элемент сообщения неудачно завершает проверку, из InvokeService может быть возвращено XML-сообщение, указывающее это состояния и элементы, которые неудачно завершили проверку. 3.4. Уровень адаптации услуг. Как отмечено выше, уровень адаптации услуг обеспечивает обычный способ для поставщиков услуг предоставлять свои услуги, обрабатывать запросы и формировать ответы для услуг, а также компоновать услуги в инфраструктуре NEMO. Он также обеспечивает основу, на которой могут быть осуществлены другие конкретные привязки интерфейсов услуг. В одном варианте осуществления используетсяWSDL, чтобы описывать интерфейс услуги в пределах системы. Такое описание услуги может, в дополнение к определению того, как привязать услугу к конкретному интерфейсу, также включать в себя перечень из одного или нескольких поставщиков услуг авторизации, которые будут ответственными за авторизацию доступа к услуге, указатель на семантическое описание назначения и использования услуги и описание необходимой компоновки для сложных услуг,являющихся результатом целостного скомпонованного исполнения одной или нескольких других услуг. В дополнение к использованию в качестве логической точки, в которой раскрывают услуги, уровень адаптации услуг также предпочтительно заключает в себе конкретные представления типов данныхNEMO и объектов, заданных в профилях услуг NEMO для платформ, которые поддерживаются заданным участником. Он также содержит механизм для отображения относящихся к услугам сообщений на подходящую реализацию внутренних услуг. В одном варианте осуществления инфраструктура NEMO не предписывает, как реализован уровень адаптации услуг для заданной платформы или участника. В ситуациях, в которых обеспечивающий услугу узел не требует преобразования его внутренних протоколов услуг, то есть предоставление его услуг только для клиентских узлов, которые могут обмениваться информацией через этот внутренний протокол, тогда этот обеспечивающий услугу узел не нуждается в том, чтобы содержать уровень адаптации услуг. В противном случае, его уровень адаптации услуг будет обычно содержать нижеследующие элементы, как проиллюстрировано на фиг. 8. Точки входа (Entry Points) - уровень, заключающий в себе точки 810 входа интерфейсов услуг и соотнесенных WSDL-привязок. Через эти точки доступа другие узлы вызывают услуги, передают данные параметров и накапливают результаты. Логика обработки сообщений (Message Processing Logic) - уровень 820, который соответствует логике обработки сообщений, обычно содержащий блок 825 подкачки сообщений, который управляет обработкой сообщений, некоторый тип поддержки 826 привязки XML-данных и поддержку 827 низкоуровневого анализатора XML и представления данных. Внутренние услуги (Native Services) - уровень, представляющий доступные внутренние услуги (на который отображаются соответствующие сообщения услуг), включающий в себя API 830 внутренних услуг и соответствующую реализацию 840. 3.5. Блок подборки последовательности операций. В предпочтительном варианте осуществления блок подборки (WFC) последовательности операций помогает выполнять наиболее нетривиальные запросы услуг NEMO, координируя поток событий для запроса, управляя какими-либо ассоциированными данными, включая переходные и промежуточные результаты, и осуществляя правила, ассоциированные с выполнением. Примеры этого вида функциональных возможностей можно видеть в форме координаторов транзакций в пределах от простых средств мониторинга (мониторов) транзакций в реляционных базах данных до более обобщенных мониторов, как видно в средствах MTS/COM+ корпорации Microsoft. В одном варианте осуществления блок подборки последовательности операций является программируемым средством, посредством которого узлы NEMO компонуют обработку и выполнение вызовов услуг. WFC может быть приспособлен к характеристикам и требованиям конкретного узла NEMO и может быть разработан таким образом, чтобы поддерживать множество функциональных возможностей в пределах от традиционных очередей сообщений до более усложненных координаторов распределенных транзакций. Относительно простой WFC может обеспечивать интерфейс для хранения и поиска произвольных относящихся к услугам сообщений. Основываясь на этом, является возможным поддерживать широкое множество функциональных возможностей, включая (i) накопление запросов услуг для более эффективной обработки; (ii) простое объединение ответов на запросы услуг в сложный ответ; (iii) ручную компоновку множества запросов услуг и ответов услуг для того, чтобы создавать сложную услугу; и(iv) автоматизированную компоновку множества запросов услуг и ответов на запросы услуг для того,чтобы создавать сложную услугу. Схема базового взаимодействия услуг начинается с запроса услуги, поступающего на некоторый- 21008614 узел NEMO через уровень адаптации услуг, принадлежащий узлу. Сообщение передают в блок подкачкиWSDL-сообщений, который первоначально будет управлять и, в свою очередь, быть управляемым посредством WFC, чтобы выполнить запрос и возвратить ответ. Даже в более сложных сценариях выполнение запроса услуги может потребовать многих сообщений и ответов и координированного участия многих узлов. Правила для обработки запросов могут быть выражены на используемом системой языке описания услуг или используя другие стандарты описания компоновки услуг, такие как BPEL. Когда сообщение подается на WFC, WFC определяет надлежащие правила для обработки этого запроса. В зависимости от реализации WFC, логика описания услуг может быть представлена в форме заданного конечного автомата для набора услуг, которые узел предоставляет, или она может быть представлена способами, которые поддерживают обработку для более свободного формата выражения логики обработки услуг. В предпочтительном варианте осуществления архитектура WFC является модульной и расширяемой, поддерживающей сменные модули. В дополнение к интерпретации состава услуг и правил oбработки, WFC может нуждаться в определении того, использовать ли сообщения NEMO в контексте инициирования жизненного цикла обработки выполнения услуги или в качестве входных данных в цепочке продолжающейся транзакции. В одном варианте осуществления сообщения NEMO включают в себя идентификаторы (ID) и метаданные, которые используются, чтобы осуществлять эти виды определений. Сообщения NEMO также могут быть расширены, чтобы включать в себя дополнительную информацию,которая может быть специфической для конкретной транзакции услуги, содействующей обработке сообщений. Как обсуждено более подробно ниже, услуги уведомлений являются непосредственно поддерживаемыми различными вариантами осуществления системы NEMO. Уведомление представляет сообщение, намеченное на заинтересованные поддерживающие NEMO узлы, принимаемое на намеченном интерфейсе услуги для обработки. Уведомления могут нести различный набор типов полезной нагрузки для передачи информации и критерии, используемые для определения того, является ли узел, заинтересованный в уведомлении, расширенным, включая критерии на основе идентификационных данных, а также на основе событий. В одном варианте осуществления, проиллюстрированном на фиг. 9 а, предоставляющий услугу узел 910 NEMO обеспечивает услугу, которая требует процесс компоновки посредством его блока 914 подборки последовательности операций (например, накопление и обработку результатов от двух других поставщиков услуг), чтобы выполнить запрос этой услуги от узла 940 клиента. Когда на узле 940 клиента поддерживающее NEMO приложение 942 инициирует запрос, чтобы вызвать услугу, предоставляемую поставщиком 910 услуг, блок 914 подборки последовательности операций, в свою очередь, формирует сообщения, чтобы инициировать его собственные запросы (от имени приложения 942), соответственно, поставщику 922 услуг, обозначенному "Y", на узле 920 и поставщику 932 услуг, обозначенному "Z", на узле 930. Блок 914 подборки последовательности операций затем осуществляет подбор и обрабатывает результаты от этих двух других предоставляющих услугу узлов, чтобы выполнять исходный запрос от узла 940 клиента. В качестве альтернативы запрошенная услуга может не требовать услуг многих предоставляющих услугу узлов; но, вместо этого, может требовать многих циклов или стадий обмена информацией между предоставляющим услугу узлом и запрашивающим узлом клиента. Как проиллюстрировано на фиг. 9b,если на узле 940 клиента поддерживающее NEMO приложение 942 инициирует запрос, чтобы вызвать услугу, предоставляемую поставщиком 910 услуг, блок 914 подборки последовательности операций, в свою очередь, участвует во множественных стадиях обмена 950 информацией с узлом 940 клиента, чтобы выполнить исходный запрос. Например, блок 914 подборки последовательности операций может формировать и посылать сообщения узлу 940 клиента (через точку 944 доступа), принимать и обрабатывать ответы и затем формировать дополнительные сообщения (и принимать дополнительные ответы) в течение последующих стадий обмена информацией, в конечном счете, выполняя исходный запрос от узла 940 клиента. В этом сценарии блок 914 подборки последовательности операций используется поставщиком 910 услуг, чтобы отслеживать (возможно, на основании идентификатора специфического для конкретной услуги сеанса или идентификатора транзакции как части запроса услуги), на какой стадии операции с клиентом он находится, для корректной обработки. Как отмечено выше, конечный автомат или подобный механизм или методика могут использоваться, чтобы обрабатывать эти множественные стадии взаимодействия 950. На фиг. 9 с проиллюстрирован один вариант осуществления относительно базового взаимодействия,в пределах обеспечивающего услугу узла 960, между блоком 914 подборки последовательности операций и блоком 965 подкачки сообщения (в пределах уровня адаптации услуг узла не показан). Как отмечено выше, блок 914 подборки последовательности операций обрабатывает один или несколько запросов 962 услуг и формирует ответы 964, используя механизм 966 хранения и извлечения, чтобы поддерживать состояние этого процесса компоновки. В этом простом примере блок 914 подборки последовательности операций способен обрабатывать многие запросы услуг и ответы на запросы услуг, которые могут быть- 22008614 реализованы с помощью довольно простого конечного автомата. Для более сложной обработки, однако, на фиг. 9d проиллюстрирована архитектура узла, которая может быть и управляющей, и управляемой в ходе выполнения компоновки услуг. Такие функциональные возможности включают в себя накопление множества запросов услуг, объединение ответов в сложный ответ и либо ручную, или автоматизированную компоновку множества запросов услуг и ответов,чтобы создавать сложную услугу. Множество сценариев может быть поддержано архитектурой, окружающей блок 914 подборки последовательности операций на фиг. 9d. Например, при наличии NEMO узла, объединив его функциональные возможности с таковыми внешнего координатора 970, который понимает семантику процесса компоновки (например, машина языка бизнес-процессов, приводимая в действие согласно высокоуровневому описанию бизнес-процессов, ассоциированных с услугами), или семантику использования ресурсов (например, машина инфраструктуры описания ресурсов (RDF), которая может быть приведена в действие согласно значению семантики ресурсов во взаимосвязях между собой), возможно создать более мощные услуги поверх более простых. Специализированные внешние процессоры BPL 972 и/или RDF 973 могут выгодным образом использовать блок 975 подкачки внешних сообщений, чтобы исполнять обработку описаний посредством процесса 966 ручной компоновки, то есть процесса, включающего вмешательство человека. В дополнение к тому, чтобы полагаться на управляемый вручную процесс, который основывается на внешнем координаторе, действующем вместе с блоком подкачки сообщений узла NEMO, также является возможным создать архитектуру, в которой модули могут быть объединены непосредственно вместе с блоком 914 подборки последовательности операций, чтобы поддерживать автоматизированную форму координации услуг и компоновки 968. Например, для обычных типов схем компоновки услуг, таких как представлены в BPEL и EBXML (язык XML для электронного бизнеса) и взаимодействуют в виде привязок Web-услуг, соотнесенных с интерфейсом услуг, блок 914 подборки последовательности операций может приводиться в действие напрямую в соответствии с описанием и совокупностью сообщений 967 запросов и ответов, которые поступают во времени. В этом сценарии сложное сообщение ответа помещают в блок 965 подкачки сообщений, только если конечный автомат, ассоциированный с заданным сменным модулем процессора компоновки (например, BPEL 982 или EBXML 983), определил, что оно является подходящим. Нижеследующее является вариантом осуществления описания для относительно высокоуровневого API,экспортируемого вариантом осуществления блока подборки последовательности операций среды NEMO.WorkflowCollatorCreate(Environment[])WorkflowCollator - это одноэлементный интерфейс, который возвращает инициализированный экземпляр WFC. WFC может быть инициализирован на основании необязательного набора параметров окружения.WorkflowCollatorStore(Key[], XML Message)Boolean - этот API позволяет вызывающему сохранить сообщение услуги внутри WFC с помощью набора заданных ключей.WorkflowCollatorRetrieveByKey(Key[], XML Message)XML Message[] - этот API позволяет вызывающему извлекать набор сообщений с помощью набора указанных ключей. Возвращаемые сообщения более не содержатся внутри WFC.WorkflowCollatorPeekByKey(KeyD, XML Message)XML Message[] - этот API позволяет вызывающему извлекать набор сообщений с помощью набора заданных ключей. Возвращаемые сообщения по-прежнему содержатся в пределах WFC.WorkflowCollatorClearBoolean - этот API позволяет вызывающему стирать любые сообщения,хранимые в WFC. В качестве альтернативы относительно строгому стандарту BPEL для компоновки, другой вариант осуществления может допускать в большей степени предназначенное для конкретного случая описание компоновки, основанное на XML, например, для более динамического приложения, такого как распределенный поиск. Рассматривается нижеследующее описание, которое может быть интерпретировано предназначенным для подборки последовательности операций блоком NEMO (и может, возможно, даже заменять полную услугу, имея достаточно развитый язык):WSDL Описатель компоновки NEMO Поток управления - например, ИСПОЛНИТЬ услугу А; если результат = Да, тогда услуга В; иначе услуга С Совместно используемое состояние/контекст - например, состояние устройства Транзакции - например, Состояние, Откат и т.д. Доверительность/авторизация - обратите внимание, что доверительность не является обязательно транзитивной 3.6. Примерная архитектура, средства DRM. В контексте различных вариантов осуществления архитектуры узла NEMO, описанных выше, на фиг. 10 проиллюстрирована интеграция модульного осуществления средства 1000 DRM в поддерживающем NEMO устройстве потребления содержимого, таким образом содействуя его интеграции во мно- 23008614 гие различные устройства и программные среды. Хост-приложение 1002 обычно принимает запрос на доступ к конкретной части содержимого через свой пользовательский интерфейс 1004. Хост-приложение 1002 затем посылает запрос, наряду с подходящими объектами средства DRM (предпочтительно непрозрачными для хост-приложения), на средство 1000 DRM. Средство 1000 DRM может выполнять запросы дополнительной информации и криптографических услуг на модуль 1008 хост-услуг с помощью строго определенных интерфейсов. Например, средство 1000 DRM может спрашивать модуль 1008 хост-услуги, является ли доверительной конкретная связь, или может просить, чтобы некоторые объекты были расшифрованы. Некоторая из необходимой информации может быть удаленной, в каковом случае хост-услуги 1008 могут запрашивать информацию из сетевых услуг через точку 1014 доступа к услугам. Как только средство 1000 DRM определило, что конкретная операция является разрешенной, оно указывает это и возвращает все требуемые криптографические ключи на модуль хост-услуг 1008, который под руководством хост-приложения 1002 основывается на содержимом услуг 1016 для получения требуемого содержимого и управления его использованием. Хост-услуги 1008 затем могут инициировать процесс воспроизведения 1010 мультимедиа (например, воспроизводя содержимое через динамики, показывая содержимое на экране и т.д.), скоординированный с услугами 1012 шифрования, как необходимо. Архитектура системы, проиллюстрированная на фиг. 10, является относительно простым примером того, как средство DRM может использоваться в приложениях, но это является лишь одной из многих возможностей. Например, в других вариантах осуществления средство DRM может быть интегрировано в приложения создания пакетов под руководством относительно усложненных систем управления политикой. Оба приложения средства DRM, а именно и клиентское (использование содержимого), и серверное (пакетирование содержимого), включая описания различных типов относящихся к DRM объектов, на которых основываются такие приложения, будут обсуждены ниже, после описания одного варианта осуществления внутренней архитектуры собственно средства DRM. Средство 1100 DRM, проиллюстрированное на фиг. 11, основывается на управляющей виртуальной машине VM 1110 для внутреннего функционирования DRM (например, исполнения управляющих программ, которые управляют доступом к содержимому) в пределах широкого диапазона хост-платформ, с использованием хост-среды 1120 (описанной выше и более подробно ниже), чтобы взаимодействовать с хост-приложением 1130 узла и, в конечном счете, с другими узлами в пределах, например, NEMO или другой системы. В одном варианте осуществления управляющая VM 1110 является виртуальной машиной, используемой вариантом осуществления средства 1100 DRM, чтобы исполнять управляющие программы, которые управляют доступом к содержимому. Нижеследующее является описанием интеграции управляющей VM 1110 в архитектуру средства 1100 DRM, а также некоторых базовых элементов управляющейVM, включая подробности о ее системе команд, модели памяти, модулях программного кода и взаимодействия с хост-средой 1120 посредством системных вызовов 1106. В одном варианте осуществления управляющая VM 1110 является относительно упрощенной виртуальной машиной, которая предназначена, чтобы быть удобной для реализации с использованием различных языков программирования. Она основана на ориентированной на стек системе команд, которая предназначена, чтобы быть упрощенной по сути, без особой заботы о быстродействии или плотности программного кода. Однако будет оценено, что если в данном приложении рассматриваются вопросы быстродействия и/или плотности кода, то могут использоваться традиционные методики (например, сжатие данных),чтобы повысить качество функционирования. Управляющая VM 1100 является подходящей в качестве целевой для языков программирования низкого или высокого уровней и поддерживает языки программирования, такие как ассемблер, С иFORTH. Компиляторы для других языков, таких как Java, или специализированных языков также могут быть реализованы относительно легко. Управляющая VM 1110 спроектирована так, чтобы содержаться внутри средства 1100 DRM, включая хост-среду 1120, в противоположность тому, чтобы исполняться непосредственно на процессоре или в кремниевой микросхеме. Управляющая VM 1110 исполняет программы посредством исполнения команд,хранимых в модулях 1102 программного кода. Некоторые из этих команд могут осуществлять вызовы к реализованным вне самой программы функциям, выполняя один или несколько системных вызовов 1106,которые реализует либо непосредственно управляющая VM 1110, либо они делегированы хост-среде 1120. Модель исполнения. Управляющая VM 1110 исполняет команды, хранимые в модулях 1102 программного кода в виде потока байт-кода, загружаемого в память 1104. Управляющая VM 1110 поддерживает виртуальный реестр, называемый счетчиком команд (СК, PC), который увеличивается по мере того, как команды исполняются. VM исполняет каждую команду последовательно, пока не встретится команда OPSTOP (останов), не встретится команда OPRET (возврат) с пустым стеком вызова или не произойдет исключительная ситуация. Переходы указываются либо в виде относительного перехода (указывается в виде смещения в байтах от текущего значения PC), или в виде абсолютного адреса.- 24008614 Модель памяти. В одном варианте осуществления управляющая VM 1110 имеет относительно простую модель памяти. Память 1104 VM разделена на сегмент данных (DS) и сегмент кода (CS). Сегмент данных является отдельным линейным непрерывным пространством адресов памяти, начинающимся с адреса 0. Сегмент данных является обычно массивом байтов, размещенных в пределах динамически распределяемой памяти (кучи) хост-приложения 1130 или хост-среды 1120. Для заданной реализации VM размер пространства памяти предпочтительно установлен на максимальное значение, и попытки осуществить доступ к памяти вне того пространства будут причиной ошибок и завершат исполнение программы. Сегмент данных является потенциально совместно используемым между несколькими модулями 1102 программного кода,одновременно загруженными посредством VM. К памяти в сегменте данных можно осуществлять доступ посредством команд доступа к памяти, которые могут быть либо 32-разрядными, либо 8-разрядными доступами. 32-разрядные доступы к памяти осуществляют, используя порядок "старшего" байта (формат хранения и передачи двоичных данных). Не делается каких-либо предположений в отношении выравнивания между памятью, видимой VM, и памятью, управляемой хостом (виртуальной или физической памятью центрального процессора (ЦП, CPU) хоста). В одном варианте осуществления сегмент кода является линейным непрерывным пространством памяти, начинающимся на адресе 0. Сегмент кода является обычно совокупностью байтов, выделенных в пределах динамически распределяемой памяти хост-приложения 1130 или хост-среды 1120. Управляющая VM 1110 может загружать несколько модулей программного кода, и все модули кода могут совместно использовать один и тот же сегмент данных (данные каждого модуля предпочтительно загружаются по другому адресу), но каждый имеет свой собственный сегмент кода (например, предпочтительно не является возможным для команды перехода из одного модуля 1102 кода вызвать переход непосредственно на код в другом модуле 1102 кода). Стек данных. В предпочтительном варианте осуществления VM содержит понятие стека данных, который представляет собой 32-разрядные ячейки данных, хранимые в сегменте данных. VM поддерживает виртуальный реестр, называемый указателем (SP) стека. После установки в исходное состояние SP указывает на конец сегмента данных, и стек изменяется по нисходящей (когда данные помещаются в стек данных,регистрам SP дают отрицательное приращение). 32-разрядные значения в стеке интерпретируют или как 32-разрядно адресованные, или 32-разрядные, со знаком, целыми числами, в зависимости от команды,осуществляющей ссылку на данные стека. Стек вызова. В одном варианте осуществления управляющая VM 1110 управляет стеком вызова для создания вложенных вызовов процедур. Значения, помещенные в этот стек, не могут быть считаны или записаны непосредственно командами доступа к памяти, но являются используемыми VM косвенно при исполнении команды OPJSR и OPRET. Для заданного профиля VM размер этого стека адреса возврата предпочтительно установлен на максимальное значение, что обеспечит, что не сможет быть превышено некоторое количество вложенных вызовов. Набор команд. В одном варианте осуществления управляющая VM 1110 использует относительно простой набор команд. Даже при ограниченном количестве команд, однако, тем не менее, возможно выразить простые программы. Система команд является основанной на стеке: кроме команды OPPUSH, ни одна из команд не имеет непосредственных операндов. Операнды считываются из стека данных, и результаты помещаются в стек данных. VM является 32-разрядной VM: все команды в этом иллюстративном варианте осуществления оперируют 32-разрядными операндами стека, представляющими либо адреса памяти, либо целые числа со знаком. Представление целых чисел со знаком осуществляется с использованием дополнительного кода в двоичной системе. Иллюстративный набор команд, используемый в одном варианте осуществления, показан ниже.- 26008614 Формат модуля. В одном варианте осуществления модули 1102 программного кода сохраняют в формате, основанном на "атомах" (элементарных единицах), который является, по существу, эквивалентным атомной структуре, используемой в формате файлов стандарта MPEG-4 (стандарт сжатия изображения и звука). Атом состоит из 32 разрядов, сохраняемых в виде 4 октетов (полубайтов) в порядке "старшего" байта, за которыми следует 4-октетный тип (обычно октеты, которые соответствуют ASCII-значениям букв алфавита), за которыми следует полезная нагрузка атома (размером 8 октетов). 3.7. Клиент-серверная архитектура DRM: использование и пакетирование содержимого. Как отмечено выше, потребляющие DRM-приложения стороны клиента (например, устройства воспроизведения мультимедиа) потребляют DRM-содержимое (например, запускают песню, отображают кинофильм и т.д.). DRM-приложения пакетирования стороны обслуживания (обычно постоянно находящиеся на сервере) упаковывают содержимое (например, соотносят содержимое с подходящим использованием и правами распространения, криптографическими ключами и т.д.), намеченное для DRMклиентов. На фиг. 12 а проиллюстрирован один вариант осуществления основных архитектурных элементовDRM-клиента. Хост-приложение 1200 осуществляет взаимодействие с пользователем устройства (например, владельцем устройства воспроизведения музыки) через пользовательский интерфейс 1210. Пользователь может, например, запрашивать доступ к защищенному содержимому и принимать метаданные наряду с содержимым (например, текст, отображающий на экране имя артиста и заглавие песни, наряду с аудио непосредственно для песни). Хост-приложение 1200, в дополнение к взаимодействию с пользовательским интерфейсом 1210,также выполняет различные функции, необходимые для осуществления запроса пользователя, который может включать в себя управление взаимодействием с другими модулями DRM-клиента, которым он делегирует некоторые функциональные возможности. Например, хост-приложение 1200 может управлять взаимодействием с файловой системой, чтобы извлекать требуемое содержимое. Хост-приложение также предпочтительно распознает формат объекта защищенного содержимого и выдает запрос на средство 1220 DRM, чтобы оценить объекты DRM, которые составляют лицензию (например, посредством исполнения подходящей управляющей программы), чтобы определить, должно ли быть предоставлено разрешение на осуществление доступа к защищенному содержимому. Если разрешение предоставлено, хост-приложение 1200 может также нуждаться в проверке требуемых подписей и делегировании полномочий криптографическим услугам 1230 и каким-либо другим криптографическим функциям общего назначения, требуемым средством 1220 DRM. Средство 1220DRM отвечает за оценивание объектов DRM, подтверждая или отвергая разрешение, и предоставление ключей хост-приложению 1200 для расшифровывания содержимого. Хост-услуги 1240 предоставляют средству 1220 DRM доступ к данным, управляемым (а также к некоторым библиотечным функциям, осуществляемым) хост-приложением 1200. Хост-приложение 1200 взаимодействует с услугами 1250 содержимого для доступа к защищенному содержимому, передавая на средство 1220 DRM только эту часть содержимого, требующего обработки. Услуги 1250 содержимого получают содержимое от внешних серверов мультимедиа и хранят содержимое и управляют содержимым, основываясь на механизмах постоянного хранения, используемых клиентом. Как только в отношении содержимого становится возможным доступ, хост-приложение 1200 взаимодействует со средством 1260 воспроизведения мультимедиа (например, доставляя ключи), чтобы расшифровать и воспроизвести содержимое через средства вывода аудио-видеоданных (AV) клиента. Некоторая информация, необходимая средству 1220 DRM, может быть доступной из состава содержимого и может быть получена и управляема посредством услуг 1250 содержимого, тогда как другая информация может потребовать получения через внешние услуги DRM инфраструктуры NEMO или некоторого другого источника. В предпочтительном варианте осуществления все из криптографических операций (шифрование,проверка цифровой подписи и т.д.) обрабатывают посредством криптографических услуг 1230, которые взаимодействуют косвенно со средством 1220 DRM через хост-услуги 1240, которые пересылают запросы. Криптографические услуги 1230 также могут использоваться средством 1260 воспроизведения мультимедиа, чтобы выполнять расшифровывание содержимого. Обращаясь к стороне обслуживания, на фиг. 12b проиллюстрирован вариант осуществления основных архитектурных элементов примерного узла пакетирования DRM стороны обслуживания. Хост-приложение 1200 взаимодействует с пакетировщиком содержимого (например, владельцем или дистрибутором музыкального содержимого) через пользовательский интерфейс 1210. Пакетировщик может, например, поставлять содержимое и информацию лицензирования на хост-приложение 1200 с тем, чтобы содержимое могло быть защищено (например, зашифровано и соотнесено с ограниченными правами доступа) и распространено различным конечным пользователям и на промежуточные предоставляющие содержимое узлы. Хост-приложение 1200, в дополнение к взаимодействию с пользовательским интерфейсом 1210,также может выполнять различные функции, необходимые для осуществления запроса пакетировщика,- 27008614 включая, например, управление взаимодействием с другими модулями создания пакетов DRM, которым оно делегирует некоторые функциональные возможности. Например, оно может управлять взаимодействием с общими криптографическими услугами 1235, чтобы зашифровать содержимое. Оно может также создавать объект содержимого, который содержит или ссылается на содержимое и содержит или ссылается на лицензию (например, после того, как средство 1225 пакетирования DRM создает объекты DRM,которые составляют лицензию). Метаданные могут быть соотнесены с лицензией, которая удобочитаемым способом поясняет, о чем эта лицензия (например, для просмотра потенциальными клиентскими пользователями). Как отмечено выше, хост-приложение 1200 взаимодействует с пользователем через пользовательский интерфейс 1210. Оно является ответственным за получение информации, такой как ссылки на содержимое и действие(я), которое хочет выполнить пакетировщик (например, к кому должна быть выполнена привязка содержимого). Оно может также отображать информацию о процессе пакетирования, такую как текст выданной лицензии, и если происходит неудача, то причину этой неудачи. Некоторая информация, требуемая хост-приложением 1200, может потребовать использования услуг 1270 NEMO (например, чтобы усилить услуги, такие как аутентификация или авторизация, а также принадлежность). В одном варианте осуществления хост-приложение 1200 делегирует услугам 1255 форматирования мультимедиа ответственность за управление всеми операциями форматирования мультимедиа, такими как транскодирование и пакетирование. Общие криптографические услуги 1235 являются ответственными за выдачу и проверку подписей, а также шифрование и расшифровывание некоторых данных. Запрос таких операций может быть выдан внешне или из средства 1225 пакетирования DRM через хост-услуги 1240. В одном варианте осуществления криптографические услуги 1237 для содержимого логически отделены от общих криптографических услуг 1235, поскольку они не осведомлены о хост-приложении 1200. Они управляются услугами 1255 форматирования мультимедиа во время пакетирования содержимого вместе с набором ключей, предварительно выданных средством 1225 пакетирования DRM (все из которых являются координируемыми хост-приложением 1200). 3.8. Объекты DRM для руководства и защиты. В иллюстративном сценарии поставщик содержимого использует хост-приложение, которое основывается на средстве пакетирования DRM, чтобы создать набор объектов, которые защищают содержимое и управляют его использованием, включая передачу информации, необходимой для получения ключей шифрования содержимого. Термин "лицензия" используется, чтобы охватить этот набор объектов. В предпочтительном варианте осуществления содержимое и его лицензия являются логически раздельными, но связанными вместе посредством внутренних ссылок, использующих идентификаторы объектов. Содержимое и лицензия обычно хранятся вместе, но могут храниться отдельно, если необходимо или желательно. Лицензия может применяться более чем к одному элементу содержимого, и более одной лицензии может применяться к любому отдельному элементу содержимого. На фиг. 13 проиллюстрирован вариант осуществления такой лицензии, включая отношения между набором объектов, обсуждаемых ниже. Обратите внимание, что объект 1320 "управление" и объект 1330"контроллер" являются оба подписанными объектами в этом варианте осуществления, так что средствоDRM клиента может проверить, что управляющая информация поступает из доверительного источника,прежде предоставления хост-приложению разрешения на доступ к защищенному содержимому. В этом варианте осуществления все эти объекты, за исключением объекта 1300 "содержимое", создает средствоDRM клиента. Объект "содержимое" - объект 1300 "содержимое", представляет зашифрованное содержимое 1304,используя уникальный идентификатор (ID) 1302, чтобы содействовать привязке между содержимым и соотнесенным с ним ключом. Объект 1300 "содержимое" является "внешним" объектом. Формат и хранение зашифрованного содержимого 1304 (например, файла кинофильма в формате МР 4, музыкального фрагмента в формате МР 3 и т.д.) определяются хост-приложением (или делегировано услуге) отчасти на основании типа содержимого. Формат содержимого также обеспечивает поддержку для соотнесения идентификатора ID 1302 с зашифрованным содержимым 1304. Хост-приложение пакетировщика шифрует содержимое способом, зависимым от формата, и управляет объектом 1300 "содержимое", используя любую имеющуюся в наличии криптосистему (например, используя симметричный шифр, такой как согласно усовершенствованному стандарту шифрования (AES. Объект "ключ содержимого" - объект 1310 "ключ содержимого" представляет зашифрованные ключевые данные 1314 (включающие уникальный ключ(и) шифрования, необязательно хранимый внутренне в пределах объекта), и также имеет соответствующий уникальный ID 1312. Предпочтительно эти ключевые данные, если содержатся внутри объекта 1310 "ключ содержимого", являются сами зашифрованными с тем, чтобы они могли быть идентифицированными только теми, кто уполномочен расшифровывать содержимое. Объект 1310 "ключ содержимого" также задает, какая криптосистема использовалась, чтобы зашифровать эти ключевые данные. Эта криптосистема, вариант осуществления который обсужден более подробно ниже, названа "система распространения ключей". Объект "управление" - объект 1320 "управление" включает в себя и защищает управляющую про- 28008614 грамму (например, управляющий байт-код 1324), которая представляет правила, управляющие использованием ключей, используемых для шифрования и расшифровывания содержимого. Он также включает в себя ID 1322 с тем, чтобы он мог быть связан с соответствующим объектом "ключ содержимого". Как отмечено выше, объект 1320 "управление" является подписанным с тем, чтобы средство DRM клиента могло проверять действительность привязки между объектами "ключ содержимого" 1310 и "управление" 1320, а также привязку между ID 1312 объекта "ключ содержимого" и зашифрованными ключевыми данными 1314. Действительность управляющего байт-кода 1324 может быть, в необязательном порядке,выведена посредством проверки защищенного хеш-значения (результата хеширования) (например, хешзначения 1338 управления, если имеется), содержащегося в объекте 1330 "контроллер". Объект "контроллер" - объект 1330 "контроллер" представляет привязку между ключами и правилами, руководящими их управлением, используя, соответственно, идентификаторы ID 1312 и 1322, чтобы связать объекты "ключ содержимого" 1310 и "управление" 1320. Объект 1330 "контроллер" руководит использованием защищенного содержимого посредством управления применением правил к этому содержимому, то есть посредством определения того, какой объект "управление" руководит использованием какого объекта 1310 "ключ содержимого". Объект 1330 "контроллер" также содержит хеш-значение 1336 для каждого из объектов 1310 "ключ содержимого", на который он ссылается, чтобы предотвращать фальсификацию привязки между каждым объектом 1310 "ключ содержимого" и соответствующими ему зашифрованными ключевыми данными 1314. Как отмечено выше, объекты 1330 "контроллер" предпочтительно являются подписанными (например, приложением-пакетировщиком, которое имеет сертификат, позволяющий ему подписывать объекты "контроллер", используя цифровые подписи с открытым ключом или симметричным ключом, как обсуждено ниже), чтобы давать возможность проверки действительности привязки между объектами "ключ содержимого" 1310 и "управление" 1320, а также привязки между ID 1312 "ключ содержимого" и зашифрованными ключевыми данными 1314. Как также отмечено выше, объект 1330 "контроллер" также, в необязательном порядке, содержит хеш-значение 1338 для управления, которое дает возможность выводить действительность объекта 1320 "управление" без необходимости отдельно проверять его подпись. Подпись симметричным ключом - в предпочтительном варианте осуществления подпись симметричным ключом является наиболее обычным типом подписи для объектов 1330 "контроллер". В одном варианте осуществления этот тип подписи реализуется посредством вычисления кода аутентификации сообщения (КАС) объекта 1330 "контроллер", снабженного тем же ключом, что и ключ, представленный объектом 1310 "ключ содержимого". Подпись открытым ключом - в предпочтительном варианте осуществления этот тип подписи используется, когда подлинность подписывающего для объекта 1330 "контроллер" требует быть утвержденной однозначно. Этот тип подписи реализуется с помощью алгоритма подписи открытым ключом,подписывая с помощью личного ключа принципала, который утверждает действительность этого объекта. При использовании этого типа подписи информация о привязке объекта "ключ содержимого", которую передают в объекте 1330 "контроллер", предпочтительно содержит хеш-значение 1336 для ключа,содержащегося в объекте 1310 "ключ содержимого", объединенное с "отпечатком" (идентификационной меткой) подписывающего личного ключа (обычно хеш-значение личного ключа). Это связывание обеспечивает, что подписывающий данный объект имеет знания о ключе, используемом для защиты содержимого. Объект "блок защиты" (Protector) - объект 1340 "блок защиты" обеспечивает защищенный доступ к содержимому посредством управления использованием ключей, используемых для шифрования и дешифрования этого содержимого. Объект "блок защиты" 1340 связывает объект 1300 "содержимое" с объектом 1310 "ключ содержимого", чтобы соотнести защищенное содержимое с соответствующим ему ключом(ами). Чтобы выполнять это связывание, он включает в себя ссылки 1342 и 1344, соответственно, на идентификаторы ID 1302 и 1312 объектов 1300 "содержимое" и 1310 "ключ содержимого". В одном варианте осуществления объект 1340 "блок защиты" содержит информацию не только о том, какой ключ использовался для шифрования одного или нескольких элементов содержимого, но также и о том, какой алгоритм шифрования был использован. В одном варианте осуществления, если ссылка 1342 на содержимое ссылается более чем на один объект 1300 "содержимое", ссылка 1344 на "ключ содержимого" может, тем не менее, ссылаться только на один объект 1310 "ключ содержимого", обозначая, что все из этих элементов содержимого были зашифрованы с использованием того же алгоритма шифрования и того же ключа. 3.9. Объекты "узел DRM" и "связь". Тогда как на фиг. 13 проиллюстрированы объекты защиты содержимого и руководства, созданные средствами DRM, чтобы управлять доступом к защищенному содержимому, на фиг. 14 проиллюстрированы объекты DRM, которые представляют объектные сущности в системе (например, пользователи,устройства или группы), а также отношения между этими объектными сущностями. Тогда как на фиг. 4, обсужденной выше, проиллюстрирован концептуальный вариант осуществления узла или графа авторизации, изображающего эти объектные сущности и их отношения, на фиг. 14 проиллюстрированы два типа объектов, которые реализуют вариант осуществления этого концептуаль- 29008614 ного графа: объекты (1400 а и 1400b) вершина (или "узел"), которые представляют объектные сущности и их атрибуты, и объекты (1420) "связь", которые представляют отношения между объектами "узел". В одном варианте осуществления средство DRM, исполняя управляющие программы, активирует одну или несколько моделей использования, включающих в себя эти объекты, например, зашифровывая песню и соотнося ее с лицензией, которая ограничивает ее распределение для конкретных лиц. Все же средство DRM в этом варианте осуществления не задает, неявно или явно, семантику, приданную этим объектам (например, каким индивидуумам песня может быть распространена). В одном варианте осуществления этот семантический контекст, называемый профилем DRM, задают непосредственно в рамках атрибутов объектов "узел". Профиль DRM может включать в себя описания этих объектных сущностей и различные роли и идентификационные данные, которые они представляют, обычно выражаемые с использованием атрибутов узла (1401 а и 1401b). Как обсуждено выше, связь 1420 между двумя узлами 1400 а и 1400b может представлять различные типы семантических отношений. Например, если бы один узел был "пользователем", а другой был "устройством", то связь 1420 могла бы представлять "собственность". Если бы другой узел был "группой пользователей" вместо "устройства",то связь 1420 могла бы представлять "принадлежность". Связь 1420 может быть однонаправленной в одном сценарии и двунаправленной в другом (например, представляющими две связи между теми же самыми двумя узлами). Объекты 1400 а и 1400b "узел" также обычно имеют пары асимметричных ключей защиты конфиденциальности объекта (например, личный ключ 1405 а и открытый ключ 1406 а узла 1400 а и личный ключ 1405b и открытый ключ 1406b узла 1400b) чтобы ограничить конфиденциальную информацию до авторизованных частей узла. Конфиденциальная информация, намеченная на узел, будет зашифрована с помощью открытого ключа защиты конфиденциальности, используемого для этого узла. В необязательном порядке, пара асимметричных ключей защиты содержимого (например, личный ключ 1403 а и открытый ключ 1403b узла 1400 а и личный ключ 1403b и открытый ключ 1403b узла 1400b) может использоваться вместе с объектами "связь", если система использует систему образования "ключа содержимого" для распостранения "ключа содержимого", как обсуждено более подробно ниже. Непосредственно элементы содержимого могут быть защищены с помощью симметричных ключей защиты содержимого,таких как симметричный ключ 1402 а узла 1400 а и ключ 1402b узла 1400b. Как отмечено выше, в одном варианте осуществления объекты "связь" (например, связь 1420) представляют отношения между узлами. Семантика этих отношений может быть хранимой в атрибутах узла(например, 1401 а узла 1400 а и 1401b узла 1400b), на которые осуществлены ссылки изнутри объектов"связь" (например, ссылка 1422 узла на узел 1400 а и ссылка 1424 узла на узел 1400b). Объекты "связь" могут также в необязательном порядке содержать криптографические данные (например, информация 1426 получения ключей), которые дают возможность использовать объект "связь" для получения "ключа содержимого", как обсуждено ниже. В одном варианте осуществления сам объект "связь" является подписанным объектом, представленным направленным ребром в графе, таком как на фиг. 4 выше. Когда имеется такое направленное ребро от одного узла (например, узла X) к другому (например, узлу Y), этот "путь" из узла X к узлу Y указывает, что узел Y является "достижимым" из узла X. Существование пути может использоваться другими объектами DRM, например, в качестве условия выполнения конкретной функции. Объект"управление" может осуществлять проверку, чтобы определять, является ли целевой узел достижимым,прежде чем он позволит, чтобы было выполнено некоторое действие над соотнесенным с ним объектом содержимого. Например, если узел D представляет устройство, которое желает исполнить действие "воспроизведение" над объектом содержимого, "управление", которое руководит этим объектом содержимого, может проверять, является ли некоторый узел U, представляющий некоторого пользователя, достижимым из узла D (например, является ли этот пользователь "владельцем" этого устройства), и позволять действию"воспроизведение" быть выполняемым, только если это условие удовлетворено. Чтобы определить, является ли узел U достижимым, средство DRM может исполнять управляющую программу, чтобы определить, имеется ли набор объектов "связь", которые могут установить путь (например, прямое или косвенное отношение) между узлом D и узлом U. Как отмечено выше, в одном варианте осуществления средство DRM является не осведомленным о семантике отношений; оно просто определяет существование пути, давая возможность хост-приложению, например, интерпретировать этот путь в качестве условной авторизации, разрешая доступ к защищенному содержимому. В одном варианте осуществления средство DRM проверяет объекты "связь" прежде разрешения им быть используемыми для определения существования путей в графе узлов системы. Действительность объекта "связь" в любой заданный момент времени может зависеть от конкретных признаков системы сертификатов (обсуждаемой ниже), используемой для подписания объектов "связь". Например, они могут иметь ограниченные "жизненные циклы" либо быть отменяемыми или повторно проверяемыми время от времени на основании различных условий. Также в одном варианте осуществления политики, которые руководят тем, какие объектные сущности могут подписывать объекты "связь", какие объекты "связь" могут быть созданы, и жизненным цик- 30
МПК / Метки
МПК: G06F 15/16, H04L 9/00, G06Q 40/00
Метки: переносимые, системы, одноранговой, приложений, способы, компоновки, услуг
Код ссылки
<a href="https://eas.patents.su/30-8614-perenosimye-sistemy-i-sposoby-dlya-prilozhenijj-odnorangovojj-komponovki-uslug.html" rel="bookmark" title="База патентов Евразийского Союза">Переносимые системы и способы для приложений одноранговой компоновки услуг</a>
Система, способы и устройства, предназначенные для интеграции распределенных приложений
Номер патента: 6307
Опубликовано: 27.10.2005
Авторы: Токовенко Сергей Витальевич, Игошин Юрий Сергеевич, Трекин Николай Евгеньевич, Сивенцев Алексей Анатольевич, Крайнов Евгений Викторович
МПК: H04L 12/58
Метки: система, устройства, интеграции, предназначенные, способы, приложений, распределенных
Формула / Реферат:
1. Информационный коммутатор, представляющий собой устройство, предназначенное для коммутации сообщений, пересылаемых между приложениями в сети, включающий в себя сетевые средства для осуществления обмена данными в сети, запоминающее устройство для хранения конфигурационных данных информационного коммутатора и буферизации сообщений, при этом конфигурационные данные информационного коммутатора включают в себя структуру данных, каждая запись...
Способ предоставления транспортных и телекоммуникационных услуг, автоматизированная система для предоставления транспортных и телекоммуникационных услуг и транспортная карта с магнитной полосой, предназначенная для предоставления телекоммуникационных услуг
Номер патента: 3306
Опубликовано: 24.04.2003
Авторы: Айбазов Олег Умарович, Михалченко Юрий Абрамович, Припачкин Юрий Игоревич, Казовский Наум Иосифович, Суконкин Александр Владимирович, Киселев Александр Евгеньевич
МПК: H04M 17/02, G06K 19/08
Метки: полосой, услуг, транспортная, карта, система, предназначенная, предоставления, транспортных, магнитной, автоматизированная, телекоммуникационных, способ
Формула / Реферат:
1. Транспортная карта с магнитной полосой, предназначенной для записи индивидуального кода, дающего возможность доступа к транспортным услугам транспортной системы, отличающаяся тем, что на карту нанесена совокупность символов, составляющая идентификационный код, закрытая непрозрачным защитным покрытием, выполненным с возможностью механического удаления, а нанесенный на карту идентификационный код предназначен для обеспечения возможности доступа...
Самосоздающаяся сетевая система, снабженная распределенным искусственным интеллектом для высокоскоростного предоставления мультимедийных услуг большого объема для осуществления телевосприятия, телеметрии, телекинеза, телеприсутствия, телеуправления, удаленного обмена информацией и предоставления услуг обработки данных
Номер патента: 2955
Опубликовано: 26.12.2002
Авторы: Арну Луи Огюст, Макгрегор Эндрю Драммонд
МПК: H04L 12/28, G06F 15/173
Метки: объема, большого, обработки, мультимедийных, информацией, телеметрии, предоставления, телеуправления, распределенным, обмена, телекинеза, услуг, снабженная, удаленного, искусственным, система, самосоздающаяся, телеприсутствия, интеллектом, данных, телевосприятия, высокоскоростного, осуществления, сетевая
Формула / Реферат:
1. Самосоздающаяся объединенная в сеть система, включающая множество компонентов-элементов, в которой все компоненты-элементы не ограничены для обмена информацией по любым постоянным иерархическим каналам и служат связующим звеном локальных и нелокальных действий посредством взаимодействия с окружающей средой, в которой действия происходят интерпретационным способом через интерактивные эвристические последовательности, которые использует...
Способы и системы для осуществления операций с платежными картами
Номер патента: 7806
Опубликовано: 27.02.2007
Авторы: Бэрри Герурд Дж., Даффи Джон
МПК: G07F 7/02, G06Q 30/00
Метки: способы, системы, осуществления, картами, платежными, операций
Формула / Реферат:
1. Способ выполнения операции с платежными картами на сумму первой операции в первой валюте между первым торговцем и первым держателем платежной карты, причем способ содержит следующие этапы: a) создают запись первой операции с платежной картой между первым торговцем и вторым держателем карты на сумму первой операции, b) создают запись второй операции с платежной картой между вторым торговцем и первым держателем карты, причем запись второй...
Способ стимулирования продажи товаров и услуг
Номер патента: 8019
Опубликовано: 27.02.2007
Авторы: Ханджян Гайк, Карапетян Саргис, Авагян Рубен
МПК: G06Q 90/00
Метки: услуг, товаров, стимулирования, способ, продажи
Формула / Реферат:
1. Способ стимулирования продажи товаров и услуг путем создания базы данных в сайте сети Интернет с информацией о льготе на их приобретение и организации по крайней мере одной игры, включающий регистрацию участника игры на этом сайте с присвоением ему персонального идентификационного кода (PIN-кода) и выдачей персональной страницы, регистрацию набранных по результатам игры очков на персональной странице участника игры и предоставление ему...
Предыдущий патент: Многофазная электрическая машина
Следующий патент: Способ взрывания множества слоев или уровней горной породы
Случайный патент: Антидоты для сельскохозяйственных культур