BRPI0616713B1 - método e sistema para administração de direito digital - Google Patents

Abstract

método e sistema para administração de direito digital. um método e sistema para administração de direito digital, no qual acesso a uma parte de conteúdo é concedido de acordo com uma licença possuída por um detentor de licença a um cliente que é um membro de um domínio. isto requer verificar com êxito que uma relação de participação existe entre o cliente e o domínio como refletido em uma primeira variável de estado, e que uma relação de associação existe entre o detentor de licença e o domínio como refletido em uma segunda variável de estado. ambas as relações são revocadas executando um protocolo em linha entre as partes na relação depois do que ambos removem a variável de estado correspondente. o controlador de domínio propaga a administração de estado relativa ao domínio que é propagada ao cliente de forma que o cliente possa atualizar sua administração de estado.

Description

(54) Título: MÉTODO E SISTEMA PARA ADMINISTRAÇÃO DE DIREITO DIGITAL (51) Int.CI.: G06F 21/00 (30) Prioridade Unionista: 30/09/2005 EP 05109043.9 (73) Titular(es): KONINKLIJKE PHILIPS N. V.

(72) Inventor(es): WOUTER BAKS; FRANCISCUS L. A. J. KAMPERMAN; PETRUS J. LENOIR; LUKASZ SZOSTEK (85) Data do Início da Fase Nacional: 27/03/2008

Ί - - - - “MÉTODO Ε SISTEMA PARA ADMINISTRAÇÃO DE DIREITO

DIGITAL”

INTRODUÇÃO

Nos últimos anos, o número de sistemas de proteção de conteúdo disponível tem crescido rapidamente. Alguns destes sistemas só protegem o conteúdo contra cópia não autorizada, enquanto outros restringem a habilidade do usuário para acessar o conteúdo. Estes sistemas são freqüentemente referidos como sistemas de Administração de Direito digital (DRM).

Consumidores querem desfrutar conteúdo sem desagrado e com tão poucas limitações quanto possível. Eles querem conectar em rede seus dispositivos para habilitar todos os tipos de aplicativos diferentes e acessar facilmente qualquer tipo de conteúdo. Eles também querem ser capaz de compartilhar/transferir conteúdo em seu ambiente doméstico sem limitações.

Domínios Autorizados

O conceito de Domínios Autorizados (ADs) tenta achar uma solução para ambos servir os interesses dos detentores de conteúdo (que querem proteção da sua propriedade intelectual) e os consumidores de conteúdo (que querem uso irrestrito do conteúdo). O princípio básico é ter um ambiente de rede controlada no qual conteúdo pode ser usado relativamente livremente contanto que não cruze a fronteira do domínio autorizado. Tipicamente, domínios autorizados são centrados ao redor do ambiente doméstico, também referido como redes domésticas.

Certamente, outros contextos também são possíveis. Um usuário podería por exemplo levar um dispositivo portátil para áudio e/ou vídeo com uma quantidade limitada de conteúdo com ele em uma viagem, e usá-lo no seu quarto de hotel para acessar ou carregar conteúdo adicional armazenado no seu sistema de áudio e/ou vídeo pessoal em casa. Embora o dispositivo portátil esteja fora da rede doméstica, faz parte do domínio autorizado do usuário. Deste modo, um Domínio Autorizado (AD) é um sistema que permite acesso a conteúdo por dispositivos no domínio, mas não por quaisquer outros.

Domínios autorizados precisam tratar assuntos tal como identificação de domínio autorizado, verificação de entrada de dispositivo, verificação .de, saída de dispositivo, verificação de entrada de direitos, verificação de saída de direitos, verificação de entrada de conteúdo, verificação de saída de conteúdo, como também administração de domínio. Para uma introdução mais extensa ao uso de um Domínio Autorizado, etc., veja S.A.F.A. van den Heuvel, W. Jonker, F.L.A.J. Kamperman, P.J. Lenoir, Secure Content Management in Authorised Domains, Philips Research, Holanda, publicação de conferência IBC 2002, páginas 467 - 474, mantida em 12-16 de setembro de 2002 ou Paul Koster, Frank Kamperman, Peter Lenoir e Koen Vrielink, Identity based DRM: Personal Entertainment Domain, Conferência sobre Comunicações e Segurança de Multimídia (CMS) 2005, LNCS 3677, pp. 42-54, Salzburg, Áustria, 19-21 de setembro de 2005. Algumas formas de domínio autorizado

Várias propostas existem que implementam o conceito de domínios autorizados a alguma extensão. Nos denominados ADs baseados em dispositivos, o domínio é formado por um conjunto específico de dispositivos de hardware ou aplicativos de software (referido coletivamente como clientes doravante) e conteúdo. _Um gerente de domínio ou controlador, que pode ser um ou mais dos clientes, um cartão inteligente ou outro dispositivo, controles que clientes podem unir o domínio. Só o conjunto específico de clientes no domínio (os membros) é permitido fazer uso do conteúdo desse domínio, por exemplo abrir, copiar, executar ou exportá-lo. Exemplos de tais ADs baseados em dispositivo são dados no Pedido de Patente Internacional WO 03/098931 (registro de agente PHNL020455), Pedido de Patente Internacional WO

2005/088896 (registro de agente PHNL040288) e Pedido de Patente

Internacional WO 04/027588 (registro de agente PHNL030283) pelo mesmo requerente, tudo do qual está incorporado por este meio por referência.

Um tipo de AD baseado em dispositivo permite a um conjunto de clientes saltado a um domínio acessar conteúdo saltado àquele domínio. Esta ligação dupla assegura que todos os membros possam acessar o - conteúdo. Esta estrutura é freqüentemente estabelecida implementando as ligações por uma chave secreta compartilhada. Esta chave é escolhida pelo gerente de domínio e distribuída a todos os membros. Quando conteúdo é ligado ao domínio, a licença é ligada criptograficamente ao domínio por meio de criptografia com a chave compartilhada. Altemativamente, o conteúdo pode ser ligado diretamente a um cliente, e os clientes permanecem ligados ao

AD.

Outro tipo de AD é o denominado AD baseado em pessoa, onde o domínio é baseado em pessoas em vez de dispositivos. Um exemplo de um tal sistema é descrito no Pedido de Patente Internacional WO 04/038568 (registro de agente PHNL021063) pelo mesmo requerente, incorporado aqui por referência, em que conteúdo é acoplado a pessoas, que então são agrupadas em um domínio.

Um denominado sistema de DRM baseado em Domínio Autorizado Híbrido liga conteúdo a um grupo que pode conter dispositivos e pessoas. Este grupo é tipicamente limitado a uma residência, tal que:

1. conteúdo pode ser assistido em quaisquer dos membros que pertencem à residência (por exemplo TV na sala de estar, TV no dormitório, PC);

2. conteúdo pode ser assistido por quaisquer dos usuários que pertencem à residência depois que eles se autenticaram em qualquer cliente (tal como uma televisão em um quarto de hotel). Tal autenticação envolve normalmente um dispositivo de autenticação de usuário tal como um cartão

inteligente.

Exemplos de sistemas de AD híbridos podem ser achados no Pedido de Patente Internacional WO 2005/010879 (registro de agente PHNL030926) e no Pedido de Patente Internacional WO 2005/093544 (registro de agente PHNL040315), ambos incorporados aqui por referência.

Em geral, um AD inclui um grupo de Clientes. Um Cliente em geral c uma entidade funcional que pode adquirir e analisar Licenças e Ligações para o propósito de adquirir acesso a um caso de Conteúdo baseado nos direitos expressos nessas Licenças e Ligações. Tipicamente, um Cliente é concretizado como um ou mais aplicativos de software e/ou componentes de hardware. Por exemplo, um Cliente pode ser provido como um aplicativo de software em um dispositivo tal como um telefone móvel ou reprodutor de música portátil. Um Cliente normalmente inclui um processador para executar as operações necessárias e é equipado com uma memória para armazenar conteúdo e/ou instruções a serem executadas pelo processador. Clientes que são incluídos no AD são referidos como Clientes de Membro ou apenas abreviado Membros.

Conteúdo é feito disponível aos Clientes de Membro por um ou mais Detentores de Licença (LO). Um detentor de Licença em geral é uma entidade que é representativa de um Usuário em um ambiente de Domínio. Um Usuário é um indivíduo que interage com o sistema. Um Usuário pode ser concedido com direitos para um caso de Conteúdo. Tal concessão de licença pode -ser representada no .sistema provendo uma Licença que liga (um caso específico de) Conteúdo ao Detentor de Licença. Um detentor de Licença pode ser implementado provendo informação em uma estrutura de dados, registro em um banco de dados ou objeto de software. A relação com o Usuário não é explicitamente definida no sistema, mas pode por exemplo ser realizada pelo Usuário tendo um Dispositivo contendo essa informação.

Uma Licença contém permissões e restrições que são específicas para o item de conteúdo envolvido. Note que pode haver muitas, por exemplo 15.000 Licenças em uma configuração de Domínio e que emitilas e comunicá-las para Clientes pode tomar uma quantidade significante de recursos.

Um Cliente que pretende acessar uma parte de Conteúdo deve ser autorizada para fazer assim. Para determinar se um Cliente está licenciado, deve ser provado que:

O direito para acessar uma parte de Conteúdo é possuído” por um detentor de Licença; e

Esse Detentor de Licença está associado com um Domínio; e

O Cliente é um membro desse Domínio.

Em outras palavras, os Detentores de Licença deveríam ser intitulados para acessar esse Conteúdo e deveríam estar associados com o Domínio. A habilidade para acessar Conteúdo por um Cliente implica que a cadeia de autorização inteira

Cliente —» Domínio -> Detentor de Licença —> Conteúdo está no lugar e que toda relação é válida. Mudanças feitas em uma configuração estabelecida de relações pode requerer relações serem invalidadas para preservar consistência. Em um sistema dividido, todas as entidades na cadeia podem ser desdobradas em hospedeiros diferentes que não precisam estar conectados um ao outro a toda hora.

Figura 1 ilustra esquematicamente uma tal cadeia de autorização de Cliente para Conteúdo, onde toda relação pode ter uma multiplicidade maior que 1 em cada direção, como indicado pelo símbolo As relações entre as entidades Cliente, Domínio, Detentor de Licença e Conteúdo em uma configuração de Domínio podem ser expressas e qualificadas por uma prova, às vezes também referida como certificado (digital). As seguintes provas podem ser usadas:

O direito que um detentor de Licença específico tem sobre uma parte de Conteúdo é expresso em uma Licença referenciando o detentor de Licença como também a parte de Conteúdo envolvido. Uma Licença é tipicamente realizada como um objeto assinado digitalmente incluindo a informação pertinente em um formato legível por máquina. Tal Licença também inclui as permissões específicas e regras de restrição expressas em código de controle executável, armazenado em um denominado objeto de Controle na Licença, a ser avaliado no momento que acesso ao Conteúdo é desejado (Note que permissões e restrições também poderiam ser representadas por linguagem de direito formal como por exemplo XrML). Uma permissão, em um modelo de concessão positivo como nós usamos aqui, é um direito individual, por exemplo Executar ou Copiar, que pode ser limitado por uma ou mais restrições, por exemplo, só 10 vezes ou não antes das 20:00 horas ou só em um sábado. Uma restrição usada em combinação com uma permissão provê uma condição que limita o uso de uma permissão. Toda permissão pode ter restrições diferentes. Note que cada Licença tem seu próprio conjunto de permissões e restrições para essas permissões (em um Controle). O provedor de serviço de conteúdo original define as permissões, possivelmente estendida com várias restrições, em uma Licença. O usuário do sistema, um consumidor, poderia desejar adicionar restrições de limitação adicionais à Licença para uso em seu Domínio. O provedor de serviço de conteúdo original não fixa parentais por exemplo restrições de controle, mas o detentor de Licença que libera seu Conteúdo adquirido a um Domínio poderia querer fazer assim. Como um exemplo, um detentor de Licença define para vários itens de conteúdo que eles não deveriam ser acessíveis antes das 22:00 horas, ou que os itens de conteúdo não são acessíveis sem alguma autenticação própria do usuário operando um Cliente. Isto conduz a áreas diferentes de controle: uma para o provedor de serviço e uma para o detentor de Licença (usuário) com características r

ligeiramente diferentes. E improvável que as colocações de provedor de /Ο serviço mudarão; a Licença será revocada completamente quando precisado, resultando em um requisito para revogação de Licenças. Um detentor de Licença (usuário) por outro lado poderia querer mudar sas restrições previamente definidas, resultando em uma requisito para ser capaz de propagar mudanças da Licença no sistema.

A relação de associação entre um detentor de Licença e um

Domínio é expressa em uma Ligação dirigida - chamada LinkLO - do Domínio para o detentor de Licença. Tal Ligação pode conter regras de restrição expressas em código de Controle executável, armazenado em um denominado objeto de Controle na Ligação, qualificando a validade da Ligação, que deve ser avaliada no momento que a Ligação é para ser usada. Tal Ligação é preferivelmente criada usando um objeto assinado digitalmente, em que o Domínio e o detentor de Licença são identificados.

A relação de participação entre um Cliente e um Domínio é expressa em uma Ligação dirigida - chamada LinkC - do Cliente para o Domínio. Tal Ligação pode conter regras de restrição expressas em código de Controle executável, armazenado em um denominado objeto de Controle na Ligação, qualificando a validade da Ligação, que deve ser avaliada no momento que a Ligação é para ser usada. Tal Ligação é preferivelmente criada usando um objeto assinado digitalmente, em que o Cliente e o Domínio são identificados.

Atributos podem ser adicionados a Licenças como também a Ligações para suportar avaliação de validade e para propósitos de transporte de informação.

Cada Cliente que é um membro de um Domínio pode acessar (uma cópia) o Conteúdo e as provas incluindo a configuração de Domínio a um certo momento em tempo, por exemplo carregando tal Conteúdo e provas como precisado, embora alguns destes dados também possam ser radiodifundidos ou distribuídos caso contrário.

Quando um Cliente pretende acessar uma parte de Conteúdo, ele avaliará a Licença para esse Conteúdo, verificando permissões e restrições definidas nessa Licença. Para este fim, o Cliente é provido com um módulo de avaliação de licença que pode ser realizado como um componente de chip e/ou software seguro, por exemplo em um cartão inteligente.

Em toda Licença há a restrição que, usando as Ligações úiícretil^s dispQni\eis para o Cliente, um caminho válido (cadeia de Ligações) do Cliente avaliador para o detentor de Licença deve estar presente. Durante esta caminho-avaliação, qualquer restrição, sendo uma condição limitando a validade da Ligação, presente nas Ligações compondo o caminho também deve ser avaliada. Como resultado, uma parte de Conteúdo só pode ser acessado quando um caminho de provas é achado entre o Cliente avaliador e a parte de Conteúdo enquanto todas as condições em toda prova são cumpridas. Se este caminho for achado, o módulo de avaliação de licença habilitará um módulo de acesso de conteúdo acessar o Conteúdo da maneira pedida. Subseqüentemente, o Conteúdo pode ser representado, copiado e/ou distribuído de acordo com as Regras de Uso.

Este sistema funciona bem para conceder direitos a Clientes baseado na configuração de Domínio. Mudar ou excluir completamente direitos concedidos prévios para Clientes em uma configuração estabelecida de relações requer relações e suas provas associadas para serem invalidados para preservar consistência no sistema. As entidades na cadeia podem ser desdobradas em dispositivos diferentes que não precisam ser conectados um ao outro a toda hora. Um Cliente não conectado não pode ser simplesmente dito que um prova não é mais válida. Outro problema com uma prova é que até mesmo quando foi apagada em um Cliente, outra cópia da prova podería (re)-aparecer nesse Cliente de outro hospedeiro no sistema ou de um sistema de reserva. Isto dá uma abertura para usuários maliciosos ganharem acesso a Conteúdo em um Cliente ao qual eles não estão intitulados.

’ -----Dado o fato que revogação de provas no sistema apagando todos os casos (cópias) das provas a ser revocadas não é possível, outros modos de revogação são precisados para ser capaz de reduzir direitos que um

Cliente tem para Conteúdo.

SUMÁRIO DA INVENÇÃO

Em resumo, em um sistema tal como descrito acima, acesso a uma parte de conteúdo é concedido de acordo com uma licença possuída por um detentor de licença a um cliente que é um membro de um domínio. Isto requer verificar com êxito que uma relação de participação existe entre o cliente e o domínio como refletido em uma primeira variável de estado mantida ambos pelo cliente e por um controlador do domínio, e que uma relação de associação existe entre o detentor de licença e o domínio como refletido em uma segunda variável de estado mantida ambos pelo controlador do domínio e por um controlador de detentor de licença associado com o detentor de licença.

Estas duas etapas de verificação provam participação do cliente ao domínio, e associação do detentor de licença, e conseqüentemente também as suas licenças com o domínio. Como resultado, o acesso ao conteúdo pode ser concedido. A relação entre duas partes é preferivelmente expressa em uma prova na qual as duas partes são identificadas. A existência de uma tal prova, tipicamente assinada digitalmente por uma parte confiada, então é usada na verificação da relação.

Desabilitar a_ possibilidade para acessar, em um tal Domínio, uma parte específica de Conteúdo pode ser arranjado com uma restrição na Licença ou comunicando a validade da Licença a um Cliente. Desabilitar a possibilidade para acessar, em um tal Domínio, qualquer de conteúdo de um detentor de Licença específico pode ser arranjado com uma restrição no Domínio —> Ligação de detentor de Licença (LinkLO) ou comunicando a validade da Ligação para o Cliente. Para desabilitar um único Cliente de acessar qualquer Conteúdo de Domínio, uma operação semelhante para o Dispositivo —> Ligação de Domínio (LinkC) pode ser executada.

É benéfico para o sistema quando é possível transportar provas a um Cliente provendo informação nova sobre a configuração de Domínio que pode ser usada imediatamente para acesso de Conteúdo sem a necessidade por protocolos em linha entre partes. Uma aplicação é, quando um novo detentor deLicença é associado com o Domínio, expresso em um LinkLO, e ele libera Conteúdo ao Domínio, expresso em Licenças, transporte desta prova junto com o Conteúdo a um Cliente nao conectado usando alguns meios habilita o Cliente acessar o Conteúdo sem precisar se conectar a outra parte.

Outra aplicação até mesmo mais desejável é quando um detentor de Licença associado existente adquire Conteúdo e o libera ao Domínio; a Licença pode ser transportada junto com o Conteúdo a um Cliente não conectado usando alguns meios habilitando o Cliente a acessar o Conteúdo sem precisar conectar à outra parte.

Uma restrição geralmente usada para provas em uma tal situação é a definição de um período de validade; depois do período de validade, a prova é desabilitada por si mesma. No caso de períodos de validade em Ligações, um Cliente que não entrou em contato com os emissores de Ligação no sistema, para renovar suas Ligações não poderão mais eventualmente acessar Conteúdo. Um período de validade em uma Licença resultará em tempo, quando não re-emitido, em um término da possibilidade para acessar uma parte específica de Conteúdo em um Cliente.

Desvantagens associadas com períodos de validade em provas são:

1. Provas devem ser atualizadas em uma base regular para reconfirmar validade requerendo emissores em linha, gerar tráfego de rede e requerendo geração e assinatura de provas atualizadas;

ιι

2. Nem toda prova em um Cliente interromperá em um Cliente ao mesmo tempo dando uma experiência de usuário indesejada especialmente quando Licenças interrompem em momentos diferentes;

3. Para preservar consistência em um sistema, tempos de espera devem ser introduzidos para algumas operações para assegurar que o período de validade de provas emitidas decorreu;

.4. Clientes não serão capazes de acessar Conteúdo quando não conectados por muito tempo (> período de validade) enquanto nada mudou na configuração de Domínio.

Um dos problemas com o anterior é como revocar seguramente ou desabilitar uma Ligação e conseqüentemente uma relação. Apagar uma prova revoca a relação, mas se uma prova puder ser copiada e distribuída, então uma pessoa com intenção maliciosa pode simplesmente copiar a prova antecipadamente e restaurá-la depois que foi apagada. Armazenar e administrar provas em memória segura é uma opção, mas memória segura é cara, especialmente ao lidar com um grande número de provas.

E um objetivo da invenção prover um meio mais eficiente de revocar a relação de participação e a relação de associação.

Isto é alcançado por um método incluindo:

revocar a relação de participação executando um protocolo em linha entre o controlador do domínio e o cliente depois do que ambos removem a primeira variáveL de estado; e revocar a relação de associação executando um protocolo em linha entre o controlador de detentor de licença e o controlador do domínio depois do que o controlador do domínio remove a segunda variável de estado e depois do que a administração de estado relativa ao domínio é propagada ao cliente de forma que a segunda variável de estado seja removida pelo cliente.

Em geral, a invenção resolve este problema tendo as partes ι&

identificadas na ligação para manter estado considerando suas relações, de forma que elas possam simplesmente remover a variável de estado para revocar a ligação. O cliente é por exemplo um dispositivo configurado para acessar e reproduzir conteúdo, e precisa ser um membro de um domínio para ser capaz de acessar conteúdo de domínio. O domínio é administrado por um controlador de domínio, que tipicamente é um dispositivo central em uma rede doméstica

- (embora muitas outras configurações sejam certamente também possíveis).

O detentor de licença é representante de entidade do usuário cujo conteúdo está disponível a dispositivos em 'seu' domínio. Isto requer uma relação de associação entre o detentor de licença e o domínio. O lado do detentor de licença da associação é cuidado por um dispositivo de controlador, que poderia ser realizado por exemplo como um cartão inteligente possuído pelo usuário ou como um servidor provido por terceiros por exemplo através da Internet.

O controlador do domínio e o cliente mantém variáveis de estado respectivas relativas à participação do cliente no domínio. A presença de uma variável de estado válida é requerida para verificar com êxito que a relação de participação existe. Quando ambas as entidades apagam estas variáveis de estado (depois de concordar em fazer assim em um protocolo em linha), a relação não pode mais ser verificada.

O mesmo permanece verdadeiro para a relação de associação, embora aqui o controlador de domínio também precise propagar a administração de estado relativa ao domínio para o cliente, de forma que o cliente possa atualizar sua administração de estado e remover a variável de estado refletindo a relação de associação.

Em uma concretização, a verificação da relação de associação e a relação de participação inclui avaliar um período de validade da relação em questão como expresso pela informação de estado e verificar com êxito a associação em questão só se o período de validade não expirou. E vantajoso ' ' ’ - - ter vencimento de validade baseado em tempo. Expressando isto usando a informação de estado, o período de validade pode ser verificado facilmente.

Em uma concretização adicional, o controlador de domínio e o cliente mantêm uma terceira variável de estado para guardar o estado da licença. Isto vantajosamente usa o mecanismo da invenção também para as licenças e não só para a participação e relações de associação. Esta concretização permite ainvalidaçãode licenças removendo a terceira variável de estado. Isto previne a restauração de licenças expiradas ou caso contrário invalidadas restabelecendo uma cópia desde que a variável de estado não pode ser manipulada deste modo. Agora também não há nenhuma necessidade para restringir a cópia de licenças, desde que elas só serão aceitas por uma parte que tem uma terceira variável de estado válida.

Preferivelmente nesta concretização, o controlador do detentor de licença cria a terceira variável de estado e propaga a terceira variável de estado para o controlador de domínio, que propaga a terceira variável de estado para o cliente. Isto vantajosamente requer só o controlador de detentor de licença ser habilitado a criar a terceira variável de estado, como os outros podem simplesmente recebê-la (diretamente ou indiretamente) deste controlador. Como o controlador do detentor de licença é implementado preferivelmente como um módulo seguro, por exemplo um cartão inteligente, de qualquer maneira, nenhuma medida especial precisa ser tomada para proteger a criação das variáveis de estado.

A invenção pode achar aplicação em áreas tais como sistemas de Domínio Autorizado para dispositivos de IT e CE, sistemas de proteção de conteúdo em ambientes com dispositivos possivelmente desconectados e sistemas de comunidade com compartilhamento de recurso para dispositivos de consumidor.

DESCRIÇÃO DETALHADA DE CONCRETIZAÇÕES PREFERIDAS

Figura 2 ilustra esquematicamente um sistema exemplar 100

- ' ' ’ ’ ’ ’ incluindo dispositivos 101-105 e pessoas 130, 131 formando um domínio autorizado (AD). O sistema 100, que visa representar uma rede doméstica digital típica, inclui vários dispositivos, por exemplo um receptor de radio, um sintonizador/decodificador, um reprodutor de CD, um par de alto-falantes, uma televisão, um VCR, um gravador digital, um telefone móvel, um gravador de fita magnética, um computador pessoal, um assistente digital pessoal, uma unidade de exibição portátil, e assim por diante. Estes dispositivos estão interconectados através de rede 110 para permitir a um dispositivo, por exemplo a televisão, controlar outro, por exemplo, o VCR. Um dispositivo, tal como por exemplo o sintonizador/decodificador ou um “caixa de topo de aparelho” (STB), é normalmente o dispositivo central, provendo controle central através dos outros.

Conteúdo, que tipicamente inclui coisas como música, canções, filmes, programas de TV, imagens, jogos, livros e similares, mas que também pode incluir serviços interativos, é recebido por um portal residencial ou “caixa de topo de aparelho” 101. Conteúdo também poderia entrar na casa por outras fontes, tais como meios de armazenamento como discos ou usando dispositivos portáteis. A fonte poderia ser uma conexão a uma rede de cabo de banda larga, uma conexão de Internet, uma ligação inferior de satélite e assim por diante. O conteúdo pode então ser transferido através da rede 110 a um recebedor pra representação. Um recebedor pode ser, por exemplo, o tela de televisão 102, a dispositivo de exibição portátil 103, o telefone móvel 104 e/ou o dispositivo de reprodução de áudio 105,

O modo exato no qual um item de conteúdo é representado depende do tipo de dispositivo e do tipo de conteúdo. Por exemplo, em um receptor de rádio, representação inclui gerar sinais de áudio e os alimentar a alto-falantes. Para um receptor de televisão, representação geralrnente inclui gerar sinais de áudio e vídeo e alimentando esses a uma tela de exibição e alto-falantes. Para outros tipos de conteúdo, uma em ação apropriada semelhante deve ser tomada. Representação também pode incluir operações tal como decifrar ou 'desembaralhar' um sinal recebido, sincronizar sinais de áudio e vídeo e assim por diante.

A “caixa de topo de aparelho” 101, ou qualquer outro 5 dispositivo no sistema 100, pode incluir um meio de armazenamento SI tai como um disco rígido apropriadamente grande, permitindo a gravação e reprodução. 43usí£rÍQr de conteúdo recebido. O meio de armazenamento SI poderia ser um Gravador Digital Pessoal (PDR) de algum tipo, por exemplo um gravador de DVD+RW, ao qual a “caixa de topo de aparelho” 101 está conectada. Conteúdo também pode entrar no sistema 100 armazenado em um portador 120 tal como um Disco Compacto (CD) ou Disco Versátil Digital (DVD).

O dispositivo de exibição portátil 103 e o telefone 104 móvel são conectados por modo sem fios à rede 110 usando um ponto de acesso sem fios 111, por exemplo usando Bluetooth ou IEEE 802.1 lb/g. Os outros dispositivos são conectados usando uma conexão por fios convencional. Para permitir aos dispositivos 101-105 interagirem, vários padrões de interoperabilidade estão disponíveis, que permitem a dispositivos diferentes trocarem mensagens e informação e controlar um ao outro. Um padrão bem conhecido é 'Universal Plug and Play' (http://www.upnp.org).

Em um cenário exemplar, pelo menos um dos usuários 130,

131 é ligado ao Domínio Autorizado além de um ou mais dos dispositivos 101-105. Opcionalmente, vários itens de conteúdo (não mostrado) também podem ser ligados ao Domínio Autorizado. Esta ligação de usuários e/ou de conteúdo pode ser feita da maneira exposta no Pedido de Patente Internacional WO 04/038568 (registro de agente PHNL021063), da maneira exposta no Pedido de Patente Internacional WO 2005/010879 (registro de agente PHNL030926), ou da maneira descrita no Pedido de Patente Internacional número de série IB2005/050910 (registro de agente ’· , X16

PHNL040315).

É freqüentemente importante assegurar que os dispositivos 101-105 na rede doméstica não façam cópias não autorizadas do conteúdo. Para fazer isto, uma estrutura de segurança, tipicamente referida como um sistema de Administração de Direito digital (DRM) é necessário. Um modo de proteger conteúdo na forma de dados digitais é assegurar que conteúdo só sem transferido entre dispositivos 101 -105 se:

o dispositivo receptor foi autenticado como sendo um dispositivo complacente; e o usuário do conteúdo tem o direito para transferir (mover e/ou copiar) esse conteúdo para outro dispositivo.

Se transferência de conteúdo for permitida, isto tipicamente será executado de um modo codificado para assegurar que o conteúdo não possa ser capturado ilegalmente em um formato útil do canal de transporte, tal como um barramento entre uma unidade de CD-ROM e um computador pessoal (hospedeiro).

Autenticação de membro de AD

Sistemas de proteção de conteúdo, especialmente aqueles estabelecidos como alguma forma de Domínio Autorizado, normalmente envolvem comunicação protegida entre membros baseado em algum segredo, só conhecido a dispositivos que foram testados e certificados para ter implementações seguras. Conhecimento do segredo é testado usando um protocole de autenticação. . Geralmente estes _ protocolos empregam criptografia de chave pública, que usam um par de duas chaves diferentes. O segredo a ser testado é então a chave secreta (às vezes chamada chave privada) do par, enquanto a chave pública pode ser usada para verificar os resultados do teste.

Para assegurar a perfeição da chave pública e verificar se o par de chaves é um par legítimo de um dispositivo certificado, a chave pública é acompanhada por um certificado, que é assinado digitalmente por uma Autoridade de Certificação (CA), a organização que administra a distribuição de pares de chaves públicas/privadas para todos os dispositivos. Todo mundo conhece a chave pública da CA e pode usá-la para verificar a assinatura da CA no certificado. Em uma implementação simples, a chave pública da CA é codificada fisicamente na implementação do dispositivo.

- ---- _ - Para habilitar o anterior, cada cliente contém várias chaves secretas. Estas chaves e o fluxo de controle usando estas chaves deveríam ser protegidos, para conhecimento destas chaves ou manipulação do fluxo de controle permitiría a invasores lograr os sistemas de proteção de conteúdo.

O fluxo de controle determina se acesso a uma parte de conteúdo deveria ser concedido a um Cliente de Membro. O resultado do fluxo de controle é uma decisão se Conteúdo pode ser acessado ou não. Certamente, tal acesso devería ser de acordo com a Licença aplicável ao Conteúdo, qual Licença é possuída pelo Detentor de Licença. Informação para essa decisão consiste na presença das relações entre as entidades de sistema.

Avaliar o fluxo de controle então envolve verificar que uma relação de participação existe entre o cliente e o domínio e que uma relação de associação existe entre o detentor de licença e o domínio. Esta verificação envolve a avaliação de provas chamadas Ligações como também a verificação de variáveis de estado que refletem a validade destas provas.

O cliente, por exemplo quaisquer dos dispositivos 102-105, e o controlador ée domínio, por exemplo, a_“caixa de topo de aparelho” 101, ambos mantêm uma primeira variável de estado que reflete a relação de participação do cliente ao Domínio. Semelhantemente, o controlador de domínio e um controlador de detentor de licença associado com o detentor de licença ambos mantêm uma segunda variável de estado que reflete a relação de associação entre o detentor de licença e o domínio. O controlador de detentor de licença é por exemplo um cartão inteligente possuído pelo usuário representado pelo Detentor de Licença.

Em algumas concretizações, o controlador de domínio e o cliente mantêm uma terceira variável de estado que vigia o estado da licença. Em tais concretizações, o controlador de detentor de licença cria esta terceira variável de estado e a propaga para o controlador de domínio que propaga a terceira variável de estado para o cliente.

_ _ __ __Um controlador de Domínio administra e serve múltiplos

Domínios (zero, um ou mais). Um Domínio porém só pode ser administrado por um único controlador de Domínio. Este controlador é responsável por emitir provas relativas a relações de participação de Clientes aos Domínios que administra. O controlador pode estar localizado em uma plataforma embutida como também aberta. A autorização para criar, remover e controlar a composição de um Domínio pode estar sujeita a certas regras ou restrições impostas por uma política de domínio.

Um controlador de detentor de licença administra e serve múltiplos Detentores de Licença (zero, um ou mais). Um detentor de Licença porém só pode ser administrado por um único controlador de detentor de licença. Este controlador é responsável por emitir provas relativas a relações de associação entre o Domínio e Detentores de Licença e por distribuir estas ligações e variáveis de estado relacionadas para controladores de Domínio. O controlador pode estar localizado em uma plataforma embutida como também aberta. Um controlador de detentor de licença pode ser concedido com autorização para, associar e desassociar Detentores de Licença com/de Domínios, adquirir Licenças, importar conteúdo no AD, compartilhar Conteúdo adquirido ou importado com um Domínio ou um Cliente individual. Esta autorização pode estar sujeita a certas regras ou restrições impostas por uma política de domínio.

Nota que as várias entidades, tal como Cliente, controlador de Domínio e controlador de detentor de licença podem ser implementadas como ’

módulos de hardware e/ou software em um único dispositivo. A caixa de topo de aparelho” 101 foi descrita acima por exemplo como um controlador de Domínio, mas certamente também pode operar como um Cliente quando precisa acessar certo conteúdo.

Exatamente onde cada entidade é implementada depende do modelo empresarial desejado que este sistema técnico é para suportar, como também considerações de segurança.constrangimentos técnicos relativos aos dispositivos disponíveis, e assim por diante. Em uma concretização direta, os Clientes são realizados em dispositivos de usuário final tais como telefones móveis ou reprodutores de música portáteis, e o controlador de Domínio e controlador de detentor de licença são desdobrados em um servidor central disponível pela Internet. Isto provê o operador deste servidor com o controle mais completo sobre Domínios e entrega de conteúdo.

Em outra concretização, o controlador de Domínio e o controlador de detentor de licença são ambos realizados em um dispositivo (central) na casa, por exemplo a “caixa de topo de aparelho” 101. Opcionalmente, os dois controladores podem ser realizados como dois dispositivos separados. Os outros dispositivos 102-105 na casa operam como Clientes. Neste Conteúdo de cenário, uma vez adquirido, está sob o controle do usuário, certamente dentro dos limites fixados pela Licença e qualquer restrição imposta pelas ligações no AD.

Em ainda outra concretização, o controlador de detentor de licença é provido em um primeiro servidor da .Internet e o controlador de Domínio é realizado em um dispositivo (central) na casa. O contrário também é possível. O controlador de detentor de licença pode ser realizado em um cartão inteligente, embora dependendo da funcionalidade requerida isto não seja sempre prático. Um cartão inteligente também pode ser usado para autorizar ou identificar um Usuário de forma que o detentor de Licença apropriado seja usado.

'

Os mecanismos nos quais a invenção se confia serão elaborados na seção 1 como eles serão aplicados em combinações diferentes. Qual combinação de mecanismos usar depende da estimação que um projetista de sistema faz para equilibrar complexidade, recursos computacionais, capacidade de armazenamento (seguro) e requisitos de disponibilidade para o sistema.

_ _ _As_ concretizações descritas na seção 2 não são exaustivas; outras combinações dos mecanismos apresentados também serão benéficas.

1. MECANISMOS USADOS NESTA INVENÇÃO

1.1 Estado Individual para Relação

Por entidades na cadeia de autorização uma administração segura de estado de relações é mantida. Valores de estado são trocados entre partes (entidades) em protocolos em linha seguros. Esta administração determina se a relação existe ou não e opcionalmente a definição de relação é estendida com um número de versão para suportar detecção de mudança. As provas (Licenças e Ligações) também expressam as mesmas relações. A informação de estado administrada seguramente pode ser usada agora para determinar a existência de uma relação e com essa a validade de qualquer prova para a mesma relação. Quando este mecanismo é usado para guardar a validade de uma prova, o código de controle na prova será estendido com uma verificação se a relação, as reivindicações de prova a representar, é administrada como existindo e válida na administração de estado da entidade avaliadora ^tipicamente um Cliente). Qualquer _ outra_ condição, como um período de validade, fixado em uma prova ainda será avaliado. Todas as condições incluindo a verificação de estado devem ser cumpridas antes que a prova seja aceita como válida. Eliminar a relação nas administrações de estado das entidades diferentes pode agora revocar uma relação no sistema.

A forma mais simples de estado é só a administração das próprias relações da entidade com vizinhos na cadeia. Ambas as partes .ζ, +21 ' ’ (entidades) juntas podem decidir em um protocolo em linha para romper sua relação, que é refletida imediatamente em ambas suas administrações invalidando toda prova para aquela relação para ambas as partes envolvidas. Outras partes (entidades) na cadeia serão informadas depois desta mudança de estado e ainda considerará a prova como válida. Períodos de validade podem ser indicados na informação de estado para forçar proliferação de informação de eslado atualizada. O mecanismo de estado pode ser usado para revogação. Criação de uma nova relação envolverá geração de um prova como também criação de uma variável de estado que deve ser comunicada usando protocolos em linha seguros. Um prova pode ser transportada de qualquer modo adequado.

O caso mais trivial para o mecanismo de estado individual é a relação de participação de um Cliente com um Domínio, onde o Cliente faz parte no protocolo de revogação e também é o avaliador da prova. Quando o Cliente e o Domínio concordam em um protocolo em linha para romper sua relação, isto é refletido na administração de estado do Cliente. O Cliente desqualificará imediatamente qualquer prova para a relação e nenhum Conteúdo relacionado a Domínio é mais acessível no Cliente. No caso mais geral, onde o avaliador (Cliente) não participa no protocolo quando uma relação é rompida, há o problema de latência de comunicar a mudança de estado ao avaliador.

1.2 Períodos de validade para Ligação

Q código de controle na Ligação, verificará que o período de validade das Ligações não está expirado. Quando expirado, a Ligação é considerada inválida. Partes usando Ligações, à parte de um mecanismo de estado adicional opcional, para determinar se uma relação na cadeia existe serão urgidas para contatar outras partes na cadeia para receber uma renovação da Ligação com um período de validade estendido e opcionalmente receber atualizações de informação de estado.

1.3 Proliferação de Ligações de Domínio anexadas a Licenças a Clientes não conectados

Quando a validade de uma Ligação em um Domínio não é guardada cuidadosa por estado individual para a relação, a Ligação (prova) por si só pode prover prova de validade. Tais Ligações, cada uma descrevendo uma parte da configuração de Domínio, pode ser anexadas a Licenças quando elas são emitidas. É benéfico para o sistema quando esta informação potencialmente nova sobre a configuração de Domínio chega a um Cliente e pode ser usada imediatamente para acesso de Conteúdo sem a necessidade por protocolos em linha entre partes. Este mecanismo pode ser usado para anexar o LinkLO para um detentor de Licença às Licenças emitidas por aquele Detentor de Licença.

Quando o Cliente já tem a Ligação ou uma versão mais nova da Ligação, a informação não é usada. Em um pacote, um Cliente pode receber a Licença para uma parte de Conteúdo e a Ligação do Detentor de Licença emissor com o Domínio. Este pacote de Licença pode acompanhar o próprio Conteúdo em alguns meios habilitando o Cliente acessar o Conteúdo sem precisar conectar qualquer outra parte no sistema. Quando nenhuma das Ligações na configuração de domínio é guardada por estado individual para a relação, todas as Ligações podem ser anexadas a uma Licença provendo o conjunto inteiro de provas precisadas para acessar o Conteúdo relacionado.

Este mecanismo não operará quando mecanismo 1.1 - Estado individual para Relação é usado paraa Ligação,., mas pode trabalhar junto com os mecanismos 1.4 - Número de Configuração para Relações por Estado e 1.5 - Número de Configuração para Relações por Ligações.

1.4 Número de Configuração para Relações por Estado

No mecanismo de estado 1.1 - Estado Individual para Relação, um valor de estado representa uma única relação. Um número de Configuração representa uma coleção explícita de relações que são tratadas

-. · k_>’ igualmente com respeito à revogação. Só quando uma relação é removida da coleção, o número de Configuração é incrementado indicando que nem todas as relações previamente parte da coleção ainda são válidas. Adicionar uma relação nova à coleção não incrementará o número porque nós só estamos interessados em revogação. As provas das relações envolvidas são atribuídas com o valor atual do número de Configuração no momento que eles são emitidos e em seu código de controle uma condição é adicionada declarando que o valor do número de Configuração da prova é igual a ou maior do que o valor do número de Configuração na administração de estado da entidade avaliadora (tipicamente Cliente). Quando esta condição não é cumprida, a relação é considerada inválida.

Este mecanismo não requer atualizações de estado no sistema ao adicionar uma relação nova; comunicação de provas só bastará para introduzir relações efetivamente novas. Uma desvantagem deste mecanismo é que quando só uma relação é para ser revocada, todas as outras relações na coleção devem ser re-confirmadas por uma renovação de suas provas com o novo número de Configuração incrementado como atributo. Proliferação de informação de estado mudada é semelhante como com o mecanismo de estado para relações individuais.

Este mecanismo pode ser usado em cascata para os níveis diferentes de relações na cadeia de autorização, opcionalmente em combinação com o mecanismo 1.5 - Número de Configuração para Relações por Ligações. _ _ . _

1.5 Número de Configuração para Relações por Ligações

A definição do número de Configuração e regras para adicionar e remover relações a e da coleção implícita é igual como descrito para mecanismo 1.4 - Número de Configuração para Relações por Estado.

As diferenças estão na proliferação do número de Configuração atual na cadeia para a entidade de Cliente e no modo que provas das relações envolvidas sào testadas para validade. As provas das relações envolvidas são atribuídas com o valor atual do número de Configuração no momento que eles são emitidos, mas a condição para verificação de validade não é adicionada a seu Controle. O valor atual do número de Configuração é adicionado como um atributo à Ligação que está próxima em linha da cadeia de autorização na direção para o Cliente.

A condição para verificar o número de Configuração atribuído à prova das relações envolvidas contra o valor atual do número de Configuração é adicionado ao código de controle da Ligação. Esta Ligação alcançará os Clientes a tempo, forçada pelo período de validade fixado para a Ligação. Durante avaliação em um Cliente do caminho para o detentor de Licença, uma Licença é visada, a Ligação será avaliada e o valor de número de Configuração na Ligação será comparado com o na prova da relação envolvida (tipicamente a Licença). O número da prova deve ser igual a ou maior do que o valor do número na Ligação. Note que este mecanismo não sofre da inaptidão para introduzir relações nos Clientes por provas sem o cliente estar conectado, porque há nenhuma operação de estado envolvida.

Este mecanismo pode ser usado em cascata para os níveis diferentes de relações na cadeia de autorização, opcionalmente em combinação com o mecanismo 1.4 - Número de Configuração para Relações por Estado.

1.6 Número de Versão para Relação por Estado

Algumas relações_T tipicamente as entre Conteúdo e Detentor de Licença não só precisam ser revocadas completamente, mas precisam ser adaptadas. Este é o caso, por exemplo quando para uma Licença existente as restrições definidas por usuário devem ser mudadas. Para suportar controle de versão (revogação de versões prévias), um número de versão é introduzido. Este número de versão sendo incrementado quando uma mudança essencial acontece na relação.

O valor atual do número de versão deve ser comunicado a

Clientes para verificar a condição de versão. Atribuir o estado para a relação com o valor atual do número de versão faz isto e esta combinação será transportada ao Cliente avaliador pela cadeia de entidades usando protocolos seguros em linha como já descrito para os outros mecanismos de estado.

A prova da relação envolvida é atribuída com o valor atual do número de versão no momento que é emitido e em seu código de controle uma condição é adicionada declarando que o valor do número de versão da prova é igual a ou maior do que o valor do número de versão da relação na administração de estado da entidade avaliadora (tipicamente Cliente).

Um pré-requisito para este mecanismo é o uso do mecanismo

1.1 - Estado Individual para Relação para a relação controlada por versão.

1.7 Número de Versão para Relação por Ligações

A definição do número de versão e regras para mudar relações é igual a descrita para mecanismo 1.6- Número de Versão para Relação por Estado. As diferenças estão na proliferação do número de versão atual na cadeia para a entidade de Cliente e no modo que provas das relações envolvidas são testadas para validade.

A prova da relação envolvida é atribuída com o valor atual do número de versão no momento que é emitido, mas a condição para verificação de validade não é adicionada a seu Controle. O valor atual do número de versão e a identificação da relação envolvida são adicionados como um atributo à Ligação que está próxima em linha da cadeia de autorização na direção p_ara o Cliente. Note que esta Ligação conterá potencialmente uma lista inteira de relação - combinações de número de versão - uma para cada relação um nível mais alto acima na cadeia de autorização.

A condição para verificar o número de versão atribuído à prova das relações envolvidas contra o valor atual do número de versão é adicionado ao código de controle da Ligação. Esta Ligação alcançará os

Clientes a tempo, forçada pelo período de validade fixado para a Ligação.

Durante avaliação em um Cliente do caminho ao Detentor de Licença, uma

Licença é visada, a Ligação será avaliada e o valor de número de versão para a relação sob avaliação na Ligação será comparado com o na prova da relação envolvida (tipicamente a Licença). Note que este mecanismo não sofre da inaptidão para introduzir relações nos Clientes por provas sem o cliente estar conectado, porque não há nenhuma operação de estado envolvida.

1.8 Ligação de Licença Paralela para separação de áreas de controle

No conceito básico, um caminho válido para o detentor de

Licença deve ser provado e as permissões e restrições na Licença, visadas ao Detentor de Licença, devem ser cumpridas. Restrição definida por usuário adicional deve, neste conceito, ser adicionada ao Controle na Licença. Usando ligação de Licença paralela, estas restrições definidas por usuário são separadas do conjunto de restrições no Controle da Licença. A Licença visando um detentor de Licença é ligada explicitamente com uma nova” ligação LinkLic do Detentor de Licença para a Licença quando a Licença é adquirida. Note que o LinkLic não precisa lidar com a multiplicidade da relação de Conteúdo - Licença, como uma Licença deve.

A verificação na Licença agora se tomará que um caminho válido (cadeia de Ligações) do Cliente avaliador para a Licença deve estar presente. Quando por razões de segurança o detentor de Licença específico estando presente no caminho para a Licença deve ser verificado^ também a verificação original para um caminho válido do Cliente avaliador para o detentor de Licença pode ser adicionada. As restrições definidas por usuário são adicionadas agora ao código de controle no LinkLic em vez do Controle da Licença. Como resultado, o Controle de uma Licença não precisa ser mudado quando um usuário quer adicionar ou mudar restrições definidas por usuário separando as áreas de controle e resolvendo os assuntos de segurança que surgem quando todas as restrições são combinadas em um único Controle.

Relação de Revogação do Conteúdo - Detentor de Licença pode ser feita com um ou uma combinação dos mecanismos de revogação disponíveis. Note que há agora 2 provas (Licença e LinkLic) para a relação única. Ambas destas provas paralelas devem estar disponíveis e válidas para poder acessar Conteúdo em um Cliente. Quando uma das provas é desabilitada, a relação é revocada. Controle de versão, tipicamente requerido para restrições definidas por usuário, podem agora ser aplicadas seletivamente ao LinkLic contendo as restrições definidas por usuário.

1.9 Ligação de Licença Serial para separação de áreas de controle

No conceito básico, um caminho válido para o detentor de Licença deve ser provado e as permissões e restrições na Licença, visadas ao Detentor de Licença, devem ser cumpridas. Restrição definida por usuário adicional deve, neste conceito, ser adicionada ao Controle na Licença. Usando ligação de Licença serial, estas restrições definidas por são separadas do conjunto de restrições no Controle da Licença. A Licença já não visa mais um detentor de Licença; apenas referencia os itens de conteúdo e contém as permissões e restrições como fixadas pelo provedor de serviço de conteúdo original. A Licença não representa mais a relação completa entre o Conteúdo e o detentor de Licença. A relação com o detentor de Licença é estabelecida e representada por uma ligação nova LinkLic do Detentor de Licença para a Licença quando ao Detentor de Licença é concedido acesso ao Conteúdo. Note que o LinkLic não precisa lidar com a multiplicidade da relação de Conteúdo Licença; isto ainda é feito pela Licença. A verificação na Licença se tomará agora que um caminho válido (cadeia de Ligações) do Cliente avaliador para a Licença deve estar presente. As restrições definidas por usuário são adicionadas agora ao código de controle no LinkLic em vez do Controle da Licença. Como resultado, o Controle de uma Licença não precisa ser mudado quando um

AM usuário quer adicionar ou mudar as restrições definidas por usuário separando as áreas de controle e resolvendo os assuntos de segurança que surgem quando todas as restrições são combinadas em um único Controle.

Relação de Revogação do Conteúdo - Detentor de Licença pode ser feita com um ou uma combinação dos mecanismos de revogação disponíveis atuando na prova de LinkLic.

Note que há agora 2 provas (Licença e LinkLic) requeridas para a única relação, onde a Licença opera a parte de conteúdo da relação e o LinkLic opera a parte de detentor de Licença da relação. Ambas destas provas seriais devem estar disponíveis e válidas para poder acessar Conteúdo em um Cliente. Quando uma das provas está desabilitada, a relação é revocada. Controle de versão, tipicamente requerido para restrições definidas por usuário, podem agora ser aplicadas seletivamente ao LinkLic contendo as restrições definidas por usuário.

Em soluções prévias, Conteúdo foi visado a um detentor de Licença em uma Licença, para ser mais específico no código de controle da Licença com a verificação que o detentor de Licença deve ser alcançável por um caminho de Ligações. Em uma solução com este mecanismo, o acoplamento de detentor de Licença é feito no LinkLic. Conceder Direitos de acesso a um detentor de Licença específico não está embutido na Licença. Quando os direitos são para serem movidos para outro detentor de Licença, então o Controle na Licença não precisa ser mudado; o novo detentor de Licença pode reusá-la. Qmovo detentor _de Licença tem que estabelecer_uma nova referência de LinkLic ele mesmo em cooperação com o antigo detentor de Licença que tem que revocar a relação existente (LinkLic).

1.10 Redefinição de licença para separação de áreas de controle

Com os mecanismos 1.8 - Ligação de Licença Paralela para separação de áreas de controle e 1.9 - Ligação de Licença Serial para separação de áreas de controle, métodos são descritos para separar áreas de controle usando os elementos existentes Licença e Ligação. Uma alternativa para esta abordagem é a definição de um novo elemento que combina o comportamento descrito da Licença e LinkLic. Desde que a Licença e LinkLic sempre aparecem em combinação, este novo elemento pode ser uma substituição para a combinação de outros dois. Esta alternativa também pode ser apresentada como um redefinição do elemento de Licença suportando dois Controles intemamente com duas áreas diferentes de controle; uma para conter as permissões e restrições como fixadas pelo provedor de serviço de conteúdo original e uma para as restrições que podem ser adicionadas por um usuário. Neste caso, a verificação original que um caminho válido de Ligações para o detentor de Licença deve existir, será usada. Esta alternativa abrange ambos os mecanismos porque o padrão paralelo como também o serial pode ser substituído por um único novo elemento.

2. CONCRETIZAÇÕES PREFERIDAS

As concretizações apresentadas usam os pontos de partida seguintes:

Não ter nenhum período de validade em Licenças individuais;

Uso de Ligações é requerido;

Prova pode ser provida para Clientes de qualquer fonte, mas tipicamente Licenças serão providas por um detentor de Licença e as ligações de Domínio LinkC e LinkLO são providas pelo Domínio;

Estado de validade de provas é transportado em protocolos em linha entre partes estritamente de acordo com a cadeia de autorização.

Usar períodos de validade nas Ligações, onde o período de validade para LinkLO é assumido ser, mas não necessariamente é, maior do que o para LinkC.

Note que os mecanismos também podem ser usados em outras configurações de Domínio diferentes da apresentada aqui; tipicamente em todas as configurações com mais de 2 entidades distribuídas com uma cadeia de dependências.

Os mecanismos também podem ser usados em concretizações que não usam as escolhas acima mencionadas. Por exemplo:

Soluções com um período de validade definido para Licenças que são liberadas ao Domínio são bastante fáceis de definir dados os mecanismos providos, mas sofrem muito das desvantagens discutidas acima sob o Resumo da invenção. Porém, em situações onde o número de Licenças é baixo ou onde recursos não tão limitantes, períodos de validade aplicados para Licenças podem ser benéficos;

Quando relações são guardadas por estado individual, Ligações podem ser eliminadas completamente ou pelo menos reduzidas em funcionalidade movendo alguns ou todos os atributos de Ligações, como usado nas soluções apresentadas, nas administrações de estado das entidades;

Quando o detentor de Licença em vez do Domínio emite o LinkLO, algumas das soluções onde informação é adicionada a um LinkLO devem ser adaptadas ligeiramente para habilitar o fluxo de informação à entidade que emite a ligação.

As concretizações apresentadas são ilustradas nas figuras usando as convenções de notação seguintes:

As entidades na cadeia de autorização são indicadas por um círculo e podem ser atribuídas com múltiplas variáveis de estado aninhadas (ids, números de configuração, períodos de validade) indicadas por ovais. Estes atributos são administrados seguramente pelas entidades;

As linhas sólidas entre as entidades na cadeia de autorização representam as relações entre elas; as outras linhas sólidas indicam associações de atributo;

As linhas pontilhadas indicam a representação de prova das relações;

Multiplicidade para atributos é indicada com um enquanto a multiplicidade para as relações não é indicada nas figuras;

Provas representando uma relação são indicadas por um retângulo e podem ser atribuídas com múltiplas variáveis (estado) (ids, números de configuração, períodos de validade) indicadas por ovais. Estes atributos são acoplados seguramente à prova.

Uma Licença podeser atribuída com ligações (acoplando LinkC(s) e LinkLO(s) a uma Licença). Estes atributos de ligação são informadores e não precisam ser acoplados seguramente às provas.

Estas ligações acopladas (cópias) levam a mesma informação (atributos) como as ligações emitidas representando as relações correspondentes. Os atributos porém são mostrados agora nas figuras.

Provas (cópias) que são/devem estar presentes, mas não devem necessariamente ser administradas seguramente, nos hospedeiros das entidades não são indicadas nas figuras.

O Clientld, Domainld, LicenseOwnerld e Licenseld são usados como variáveis de estado para referenciar sua entidade correspondente, mas nas figuras para elas não são mostradas como um atributo dessas entidades.

2.1 Nenhuma execução antes de períodos de validade

Esta concretização é ilustrada em Figura 3. Os mecanismos aplicados são:

Mecanismo	Usado para
1.3 - Proliferação de Ligações de Domínio anexadas a licenças para Clientes não conectados	Comunicar todos os LinkLOs e LinkCs na configuração de Domínio para Clientes
1.5 - Número de configuração para relações por ligações	Guardar estado de LinkC, LinkLO e todas as Licenças de um detentor de Licença (duas vezes em cascata)

Um detentor de Licença tem um licenseConfigNr que é incrementado quando quaisquer das Licenças visadas àquele Detentor de Licença é mudada ou é removida indicando uma mudança para uma das Licenças.

Este licenseConfigNr deve ser comunicado em um protocolo ao Domínio que administra seguramente o licenseConfigNr mais recente para cada detentor de Licença associado. O Domínio administra um domainConfigNr que é incrementado quando quaisquer das relações na configuração de Domínio muda. Estas mudanças são: um incremento do licenseConfigNr de quaisquer dos detentores de Licença associados com o Domínio, uma mudança ou remoção de quaisquer das associações de detentores de Licença com o Domínio, e uma mudança ou remoção de quaisquer das associações de Clientes com o Domínio.

O valor atual do domainConfigNr está associado com o LinkC e o LinkLO pelo Domínio e a Licenças recentemente liberadas a um Domínio pelo Detentor de Licença, por exemplo registrando este valor no objeto assinado representando o LinkC e LinkLO.

O domainConfigNr deve primeiro ser comunicado em um protocolo ao Detentor de Licença que administra seguramente o domainConfigNr mais recente para cada Domínio associado para poder emitir uma nova Licença com um domainConfigNr atualizado.

Depois de um incremento do licenseConfigNr no Detentor de ....Licença, o detentor de Licença precisa esperar por comunicação com o Domínio para receber o domainConfigNr mais recente, junto com as Ligações mais recentes do Domínio, antes que novas Licenças possam ser emitidas.

Todos os LinkLOs e todos os LinkCs, como conhecido pelo Detentor de Licença, são anexados a uma Licença quando liberados a um Domínio. O Detentor de Licença recebe estas ligações em um protocolo com o Domínio.

As ligações de um Domínio podem agora alcançar um Cliente por comunicação direta entre o Domínio e o Cliente ou por uma Licença adquirida pelo Cliente. Um Cliente que administra por Domínio é o membro de uma variável de estado para o domainConfigNr mais recente conhecido pelo Cliente. Este domainConfigNr indica validade para Ligações e Licenças. Quando uma destas provas leva um domainConfigNr como atributo que tem um valor mais baixo do que o administrado com seguramente pelo Cliente, a prova é considerada como inválida e deve ser renovada quando possível. Esta verificação é executada por código no Controle das Ligações durante avaliação de caminho, requerendo que os valores do domainConfigNr na Licença sob avaliação e o domainConfigNr na Ligação sob avaliação não devem ser mais baixos do que o administrado pelo Cliente.

O Cliente adaptará seu domainConfigNr, só o incrementando quando um valor mais alto é encontrado em uma Ligação enviada pelo

Domínio ou em uma Licença. Todas as relações podem ser revocadas no sistema pelo mecanismo de domainConfigNr, mas não há nenhuma execução para Clientes contatarem um Domínio ou interpretarem uma nova Licença. O único incentivo para um Cliente aceitar esta informação de revogação quando deseja acessar Conteúdo para qual uma Licença é emitida depois da revogação aconteceu no sistema.

Um detentor de Licença atribui uma Licença com o domainConfigNr conhecido na administração do Detentor de Licença. Não há porém nenhum incentivo para um detentor de Licença contatar um Domínio para receber nova informação de configuração de Domínio, exceto para o caso onde o licenseConfigNr foi aumentado e comunicação é requerida antes que Licenças sejam permitidas serem liberadas. Como resultado, a informação de configuração de Domínio anexada à nova Licença liberada (LinkLOs, LinkCs e o domainConfigNr) pode retardar atrás da situação atual na configuração de Domínio como conhecido pelo Domínio. Isto pode ser logrado requerendo comunicação do Detentor de Licença com um Domínio toda vez antes que uma Licença é liberada a um Domínio para assegurar ter a informação de configuração de Domínio mais recente.

Esta solução não implementa a revogação imediata de provas em um Cliente, mas a tempo, quando Conteúdo de Domínio chega, um

Cliente concordará.

Características de solução:

Aspecto/Ação
Novas ligações a Cliente com Domínio fora de linha e/ou Detentor de Licença	Todas as ligações anexadas à Licença proliferada para Cliente sem Domínio em linha ou Detentor de Licença precisado. Nunca conexão entre Cliente e Domínio requerido.
Não conectando Detentor de Licença	Relação de associação será retida para sempre (depois de Domínio decidido para terminá-la) ponto de vista de detentor de Licença. Em ponto de vista de Clientes, a associação deveria terminar encontrando uma Licença liberada por outro detentor de Licença associado com o Domínio com um domainConfigNr mais alto. Não há nenhum término garantido para acesso de Conteúdo em Clientes.
Não conectando Cliente	Relação de participação será retida (depois de Domínio decidido para terminá-la) em ponto de vista de Cliente até que uma Licença seja interpretada com domainConfigNr mais alto. Não há nenhum término garantido para acesso de Conteúdo em Clientes
Desfazer registro de -um Cliente de um Domínio	Imediatamente Cliente não acessará qualquer Conteúdo de Domínio. Todas as Ligações restantes devem ser renovadas.
Desassociar um detentor de Licença de um Domínio	Até que Clientes contatem o Domínio ou eles encontrem uma Licença liberada por outro detentor de Licença associado com o Domínio com um domainConfigNr mais alto, Conteúdo do Detentor de Licença desassociado será acessível. Todas as Ligações restantes devem ser renovadas.

Μ

Remover uma Licença de um detentor de Licença	Até que Detentor de Licença contate o Domínio e subseqüentemente Clientes contatem o Domínio ou eles encontrem uma Licença, liberada pelo Detentor de Licença removedor ou outro detentor de Licença associado com o Domínio que contatava o Domínio depois de remoção, com um domainConfigNr mais alto, Conteúdo da Licença removida será acessível. Todas as Licenças restantes de todos os Detentores de Licença devem ser renovadas.
Mudar uma Licença (restrições definidas por usuário)	íiici ementar licenseConfigNr como sc—uma? Licença fosse removida.
Administração de estado seguro de Tamanho de Cliente	#domains *(DomainId+domainConfigNr)

2.2 Nenhum estado em Cliente

Esta concretização é ilustrada na Figura 4. Os mecanismos aplicados são:

Mecanismo	Usado por
1.2 - Períodos de validade para Ligação	Guardar LinkC e LinkLO e forçar propagação de licenseConfigNr.
1.3 - Proliferação de Ligações de Domínio anexadas a Licenças para Clientes desconectados	Comunicar o LinkLO do Detentor de Licença e todos os LinkCs na configuração de Domínio para Clientes.
1.5 - Número de configuração para relações por Ligações	Guardar estado de todas as Licenças de um detentor de Licença.

Um detentor de Licença tem um licenseConfigNr que é mcrêmêntãdo quando quaisquer das Licenças visadas àquele Detentor de Licença é mudada ou é removida indicando uma mudança para uma das Licenças. Quando um detentor de Licença libera uma Licença para um Domínio, o detentor de Licença atribui a Licença com o valor atual do licenseConfigNr. O valor atual do licenseConfigNr também é atribuído ao

LinkLO. Este licenseConfigNr deveria ser primeiro comunicado em um protocolo ao Domínio que administra seguramente o licenseConfigNr mais recente para cada detentor de Licença associado para ser capaz de emitir um novo LinkLO com um licenseConfigNr atualizado. O Controle no LinkLO, durante avaliação de caminho, executará a verificação do licenseConfígNr atribuído à Licença com o atribuído ao LinkLO.

O LinkLO e todos os LinkCs, como conhecido pelo Detentor de Licença, são anexados a uma Licença quando liberada a um Domínio. O Detentor de Licença recebe estas ligações em um protocolo com o Domínio. Como a distribuição de Ligações anexadas a uma Licença é uma alternativa opcional em cima da distribuição padrão do Domínio para os Clientes, é opcional se depois de um incremento do licenseConfígNr no Detentor de Licença o detentor de Licença precisar esperar por comunicação com o Domínio para receber o LinkLO com o licenseConfígNr atualizado. LinkCs anexados a Licenças liberadas podem retardar atrás da situação atual na configuração de Domínio como conhecido pelo Domínio.

Note que quando o LinkLO não é emitido por um Domínio, mas por um detentor de Licença, o detentor de Licença não precisa comunicar o licenseConfígNr ao Domínio e o Domínio não precisa administrar o licenseConfígNr. Nesse caso, o detentor de Licença emite diretamente o LinkLO com o licenseConfígNr atual.

Clientes e Detentores de Licença são forçados antes dos períodos de validade no LinkLO e LinkC para se comunicarem em uma base regular para reconfirmar sua relação com o Domínio e receber informação de configuração de Domínio atualizada. Estes períodos de validade são indicados na figura como LO-validityperiod e C-validityperiod, respectivamente.

Características de solução:

Aspecto/Ação
Novas Ligações a Cliente com Domínio fora de linha e/ou detentor de Licença	-r .........—t-....-,-.- , LJnico LinkLo e todos os LinkCs anexados à Licença proliferada para Cliente sem Domínio em linha ou Detentor de Licença precisado.
Não conectando Detentor de Licença	Relação rompida e nenhum acesso a Conteúdo depois de expiração de LO-validityperiod atual.

Não conectando Cliente	Relações rompidas e nenhum acesso a Conteúdo depois de expiração de LOvalidityperiod atual por Detentor de Licença ou C-validityperiod.
Desfazer registro de um Cliente de um Domínio	Esperar até expiração de C-validityperiod atual para Conteúdo de Domínio se tomar acessível.
Desassociar um detentor de Licença de um Domínio	Esperar pelo resto do LO-validityperiod atual antes que Clientes não mais acessarão qualquer Conteúdo de Domínio do Detentor de Licença desassociado. Nenhuma renovação de Ligações
	prCCl Scldcl»
Remover uma Licença de um detentor de Licença	Esperar pelo resto do LO-validityperiod atual antes que Clientes não mais acessarão Conteúdo de Licença removida. Todas as Licenças restantes de detentor de Licença devem ser renovadas. Só LinkLO deve ser renovado.
Mudar uma Licença (restrições definidas por usuário)	Incrementar licenseConfigNr como se uma Licença fosse removida.
Administração de estado seguro de Tamanho de Cliente	0

2.3 £stado individual para LinkC

Esta concretização é ilustrada na Figura 5. Os mecanismos aplicados são:

Mecanismo	Usado para
1.1 - Estado Individual para Relação	Guardar estado de LinkC.
1.2 - Períodos de Validade para Ligação	Guardar LinkC e LinkLO, forçar propagação de licenseConfigNr e forçar troca de informação entre Detentor de Licença e Domínio e forçar Domínio entre Cliente e Domínio.
1.3- Proliferação de Ligações de Domínio anexadas a Licenças para Clientes desconectadas	Comunicar o LinkLO para o detentor de Licença para Clientes.
1.5- Número de Configuração para relações por Ligações	Guardar estado de todas as Licenças de um detentor de Licença.

Note que há estado local entre o detentor de Licença e Domínio, mas isto não resulta em um estado individual administrado por um Cliente. A relação de associação pode ser revocada em um protocolo em linha entre o Domínio e o detentor de Licença, onde eles ambos concordam para terminar a associação e cada um remove a variável de estado relacionada de sua administração.

O IicenseConfigNr é usado para guardar o estado de todas as Licenças de um detentor de Licença e o período de validade em LinkLO guarda a validade de LinkLO como descrito com a solução 2.2 - Nenhum Estado em Cliente.

Só LinkLO, como conhecido pelo Detentor de Licença, é anexado a uma Licença quando liberada a um Domínio. O Detentor de Licença recebe esta ligação em um protocolo com o Domínio. Como a distribuição do LinkLO anexado a uma Licença é uma alternativa opcional em cima da distribuição padrão do Domínio para os Clientes, é opcional se depois um incremento do IicenseConfigNr no Detentor de Licença que o detentor de Licença precisa esperar por comunicação com o Domínio para receber o LinkLO com o IicenseConfigNr atualizado.

Desde que a relação de participação, comparada com a solução

2.2 - Nenhum Estado em Cliente, é guardada agora por uma variável de estado individual no Cliente, não tem nenhum uso adicionando um LinkC a uma Licença, porque o Cliente que adquire a Licença não pode usar o LinkC por si só para estabelecer participação; isto só pode ser feito com um protocolo em linha.

A relação de participação entre um Cliente e um Domínio é determinada pelo mecanismo de estado individual. Participação só pode ser estabelecida usando um protocolo entre as duas partes e elas ambas administram este fato em uma variável de estado (Domainld para o Cliente). O LinkC é emitido com um período de validade. O LinkC só é válido agora .Μ39 quando ο período de validade não é expirado E a variável de estado Domainld relacionada à participação LinkC no Cliente ainda está presente. Isto é verificado no código do Controle do LinkC quando avaliação do LinkC procurando por um caminho o detentor de Licença como requerido na

Licença sob avaliação. A relação de participação pode ser revocada em um protocolo em linha entre o Domínio e o Cliente, onde eles ambos concordam para terminar a participação e cada um remove a variável de estado relacionada de sua administração. Como uma conseqüência, o LinkC é desabilitado no Cliente porque não há nenhuma variável de estado relacionada mais.

O LinkLO é emitido com um período de validade. O LinkLO agora só é válido quando o período de validade não está expirado E a variável de estado Domainld relacionada à participação no Cliente ainda está presente. Isto é verificado no código do Controle do LinkLO quando avaliação do

LinkLO procurando por um caminho ao Detentor de Licença. O Controle no LinkLO, durante avaliação de caminho, executará a verificação do licenseConfígNr atribuído à Licença com o atribuído ao LinkLO.

Note que o Domainld de Ligações de Domínio poderia ser derivado de sua administração de direção implícita, mas a solução mais robusta é atribuir toda Ligação a um Domínio com o Domainld. Isto porém não é ilustrado na figura.

Características de solução:

Aspecfô/Açãõ
Novas lrgaçõês“a Cliente com Domínio fora de linha e/ou Detentor de Licença	LinkLO anexado â Licença proliferada a Cliente sem Domínio em linha ou Detentor de Licença precisado.
Não conectando Detentor de Licença	Relação rompida e nenhum acesso a Conteúdo depois de expiração de LO-validityperiod atual.
Não conectando Cliente	Relações rompidas e nenhum acesso a Conteúdo depois de expiração de LOvalidityperiod atual por Detentor de Licença ou C-validityperiod.

Desfazer registro de um Cliente de um Domínio	Imediatamente Cliente não acessará qualquer Conteúdo de Domínio.
Desassociar um detentor de Licença de um Domínio	Esperar pelo resto do LO-validityperiod atual antes que Clientes não mais acessarão qualquer Conteúdo do Detentor de Licença desassociado. Nenhuma renovação de Ligações precisada.
Remover uma Licença de um detentor de Licença	esperar pelo resto do LO-validityperiod atual antes que Clientes não mais acessarão Conteúdo de Licença removida. Todas as Licenças restantes de detentor de Licença devem ser reiiovadas. Só LínkLO deve ser renovado.
Mudar uma Licença (restrições definidas por usuário)	Incrementar licenseConfigNr como se uma Licença fosse removida.
Administração de estado seguro de T amanho de Cliente	#domains*DomainId

2.4 Estado Individual para LinkC e Estado de Domínio para LinkLO

Esta concretização é ilustrada na Figura 6. Os mecanismos aplicados são:

Mecanismo	Usado para
1.1- Estado Individual para Relação	Guardar estado de LinkC.
1.2 - Períodos de Validade para Ligação	Guardar LinkC e LinkLO, forçar propagação de licenseConfigNr e forçar troca de informação entre Detentor de Licença e Domínio e forçar troca de informação de configuração de Domínio entre Cliente e Domínio.
1.3- Proliferação de Ligações de Domínio anexadas a Licenças para Clientes desconectados	Comunicar o LinkLO para o detentor de Licença para Clientes.
1.4 - Número de configuração para relações por Estado	Guardar estado de LinkLO e LinkC por domainConfigNr.
1.5- Número de Configuração para relações por Ligações	Guardar estado de todas as Licenças de um detentor de Licença.

Note que há estado local entre o detentor de Licença e Domínio, mas isto não resulta em um estado individual administrado por um Cliente; só no estado de domainConfigNr combinado. A relação de associação pode ser revocada em um protocolo em linha entre o Domínio e o detentor de Licença, onde eles ambos concordam para terminar a associação e cada um remove a variável de estado relacionada de sua administração.

Um detentor de Licença tem um licenseConfigNr que é incrementado quando quaisquer das Licenças visadas àquele Detentor de Licença é mudada ou é removida indicando uma mudança para uma das Licenças. Quando um detentor de Licença libera uma Licença a um Domínio, o detentor de Licença atribui a Licença com o valor atual do licenseConfigNr. O valor atual do licenseConfigNr também é atribuído ao LinkLO. Como nós assumimos o Domínio emitir LinkLOs, este licenseConfigNr deve ser comunicado primeiro em um protocolo ao Domínio que administra seguramente o licenseConfigNr mais recente para cada detentor de Licença associado para ser capaz de emitir um novo LinkLO com um licenseConfigNr atualizado. O Controle no LinkLO, durante avaliação de caminho, executará a verificação do licenseConfigNr atribuído à Licença com o atribuído ao LinkLO.

O LinkLO, como conhecido pelo Detentor de Licença, é anexado a uma Licença quando liberada a um Domínio. O Detentor de Licença recebe esta ligação em um protocolo com o Domínio. Como a cima da distribuição padrão do Domínio para os Clientes, é opcional se depois de um incremento do licenseConfigNr no Detentor de Licença o detentor de Licença precisar esperar por comunicação com o Domínio para receber o LinkLO com o licenseConfigNr atualizado.

A relação de participação entre um Cliente e um Domínio é determinada pelo mecanismo de estado individual. Participação só pode ser estabelecida usando um protocolo entre as duas partes e elas ambas administram este fato em uma variável de estado (Domainld para o Cliente). O LinkC é emitido com um período de validade. O LinkC agora só é válido quando o período de validade não está expirado E a variável de estado Domainld relacionada ao LinkC de participação no Cliente ainda está presente. Isto é verificado no código do Controle do LinkC quando avaliação do LinkC procurando por um caminho o detentor de Licença como requerido na Licença sob avaliação.

A relação de participação pode ser revocada em um protocolo em linha entre o Domínio e o Cliente, onde eles ambos concordam para terminar a participação e cada um remove a variável de estado relacionada de sua administração. Como uma conseqüência, o LinkC é desabilitado no Cliente porque não há nenhuma variável de estado relacionada mais.

O Domínio administra um domainConfigNr que é incrementado quando quaisquer das relações na configuração de Domínio muda. Estas mudanças são: um incremento do licenseConfigNr de quaisquer dos detentores de Licença associados com o Domínio, uma mudança ou remoção de quaisquer das associações de detentores de Licença com o Domínio, e uma mudança ou remoção de quaisquer das associações de Clientes com o Domínio. O Domínio atribui o valor atual do domainConfigNr ao LinkC e ao LinkLO.

As ligações de um Domínio podem alcançar um Cliente por comunicação direta entre _o Domínio e o Cliente e um LinkLO pode alcançar um Cliente por uma Licença adquirida pelo Cliente. Um Cliente que administra por Domínio é o membro de uma variável de estado para o domainConfigNr mais recente conhecido pelo Cliente. Este domainConfigNr indica validade por Ligações. Quando uma das Ligações leva um domainConfigNr como atributo tendo um valor mais baixo do que o administrado seguramente pelo Cliente, a Ligação é considerada como inválida e é renovada quando possível. Esta verificação é executada por código no Controle das Ligações durante avaliação de caminho, requerendo que o valor do domainConfigNr na Ligação sob avaliação não deva ser mais baixo do que o administrado pelo Cliente.

Clientes administram uma variável de estado de domainConfigNr para todo Domínio do qual eles são membro. Esta variável de estado é atualizada em um protocolo em linha entre o Cliente e o Domínio.

Ligações em um Cliente só são agora válidas quando seu período de validade não está expirado E a variável de estado Domainld relacionada ao LinkC de participação no Cliente ainda está presente E seu valor de domainConfigNr não é mais baixo do que o na administração de estado de Cliente. Isto é verificado no código do Controle das Ligações quando avaliação das Ligações procurando por um caminho o detentor de Licença como requerido na Licença sob avaliação. O Controle no LinkLO também executará a verificação do licenseConfigNr atribuído à Licença com o atribuído ao LinkLO.

Note que há agora uma administração de estado dupla para LinkC: um com o estado individual (Domainld em Cliente) e um pelo domainConfigNr. Uma configuração alternativa pode ser um LinkC sem o domainConfigNr como um atributo e não testando o LinkC contra o domainConfigNr na administração de estado do Cliente. O comportamento é semelhante, mas o LinkC não precisa ser emitido com toda mudança do

Note que o Domainld de Ligações de Domínio poderia ser derivado de sua administração de direção implícita, mas a solução mais robusta é atribuir toda Ligação a um Domínio com o Domainld. Isto porém nao é ilustrado na figura.

Clientes e Detentores de Licença são forçados antes dos períodos de validade no LinkLO e LinkC se comunicarem em uma base regular para reconfirmar sua relação com o Domínio e receber informação de configuração de Domínio atualizada. Estes períodos de validade são indicados na figura como LO-validityperiod e C-validityperiod, respectivamente.

Características de solução:

Aspecto/Açao
Novas ligações a Cliente com Domínio fora de linha e/ou Detentor de Licença	LinkLO anexado à Licença proliferada a Cliente sem Domínio em linha ou Detentor de Licença precisado.
Não conectando Detentor	Relação rompida e nenhum acesso a Conteúdo
de Licença	depois de expiração de LO-validityperiod atual.
Não conectando Cliente	Relações rompidas e nenhum acesso a Conteúdo depois de expiração de LOvalidityperiod atual por Detentor de Licença ou C-validityperiod.
Desfazer registro de um Cliente de um Domínio	Imediatamente Cliente não acessará qualquer Conteúdo de Domínio. Todas as ligações restantes devem ser renovadas.
Desassociar um detentor de Licença de um Domínio	Esperar pelo mínimo (resto do LOvalidityperiod atual, Máximo (resto do Cvalidityperiods)) antes que todos os Clientes não mais acessarão qualquer Conteúdo do Detentor de Licença desassociado. Todas as Ligações restantes devem ser renovadas (alternativa só todos os LinkLOs).
Remover uma Licença de um detentor de Licença	Esperar por (se Detentor de Licença e Domínio conectado: mínimo (resto do LO-validityperiod atual, Máximo (resto de C-validityperiods)) senão resto de LO-validityperiod atual) antes que Cliente não mais acessará Conteúdo de Licença removida. Todas as Licenças restantes de detentor de Licença devem ser renovadas. Todas as Ligações devem ser renovadas.
Mudar uma Licença (restrições definidas por usuário)	Incrementar licenseConfigNr como se uma Licença fosse removida.
Administração de estado seguro de Tamanho de Cliente	#domains *(DomainId+domainConfigNr)

2.5 Estado individual para LinkC e LinkLO

Esta concretização é ilustrada na Figura 7. Os mecanismos aplicados são:

Mecanismo	Usado para
1.1 - estado Individual para Relação	Guardar estado de LinkC e LinkLO.
1.2 - Períodos de validade para Ligação	Guardar LinkC e LinkLO, forçar propagação de licenseConfigNr e forçar troca de informação entre Detentor de Licença e Domínio e forçar troca de informação de configuração de Domínio entre Cliente e Domínio.
-4-4- - Número de	Guardar estado de tndas as Licenças de um
Configuração para relações por Estado	detentor de Licença por um licenseConfigNr em estado de Domínio e estado de Cliente.

Um detentor de Licença tem um licenseConfigNr que é incrementado quando quaisquer das Licenças visadas àquele Detentor de Licença é mudada ou é removida indicando uma mudança para uma das Licenças. Quando um detentor de Licença libera uma Licença a um Domínio, o detentor de Licença atribui a Licença com o valor atual do licenseConfigNr.

O valor atual do licenseConfigNr é comunicado em um protocolo ao Domínio que administra seguramente o licenseConfigNr mais recente para cada detentor de Licença associado.

A relação de associação entre um detentor de Licença e um Domínio é determinada pelo mecanismo de estado individual. Uma relação de associação só pode ser estabelecida usando um protocolo entre as duas partes e elas ambas administram este fato em uma variável de estado (Domainld para o detentor de Licença e LicenseOwnerld para o Domínio). A relação de associação pode ser revocada em um protocolo em linha entre o Domínkr e o detentor de Licença onde eles ambos concordam para terminar a associação e cada um remove as variáveis de estado relacionadas de sua administração. A administração de estado de um Domínio é propagada a Clientes quando eles estão ou quando eles ficam em contato entre si.

A relação de participação entre um Cliente e um Domínio é determinada pelo mecanismo de estado individual. Participação só pode ser estabelecida usando um protocolo entre as duas partes e elas ambas administram este fato em uma variável de estado (Domainld para o Cliente e Clientld para o Domínio).

Para cada Domínio que um Cliente é membro dele conterá uma cópia da administração de estado do Domínio com respeito aos Detentores de Licença associados com o Domínio. A relação de participação pode ser revocada em um protocolo em linha entre o Domínio e o Cliente, onde eles concordam para terminar a participação e cada um remove as variáveis de estado relacionadas de sua administração.

As ligações de um Domínio podem alcançar um Cliente por comunicação direta entre o Domínio e o Cliente. Ligações em um Cliente agora só são válidas quando seu período de validade não está expirado E a variável de estado Domainld relacionada à participação na administração de estado de Cliente ainda está presente. Isto é verificado no código do Controle das Ligações quando avaliação das Ligações procurando por um caminho o detentor de Licença como requerido na Licença sob avaliação. O código de controle do LinkLO executará as verificações adicionais que o LicenseOwnerld para o LinkLO ainda está registrado como associado na administração de estado do Cliente e que o valor de licenseConfigNr da Licença sob avaliação é igual a ou maior do que o na administração de estado do Cliente.

Note que o Domainld de Ligações de Domínio poderia ser derivado de sua administração de direção implícita, mas a solução mais se mantém para adicionar um LicenseOwnerld explícito ao LinkLO. Isto porém não é ilustrado na figura.

Os clientes e Detentores de Licença são forçados pelos períodos de validade no LinkLO e LinkC para se comunicarem em uma base regular para reconfirmar sua relação com o Domínio e receber informação de configuração de Domínio atualizada. Estes períodos de validade são indicados na figura como período de LO-validityperiod e C-validityperiod, respectivamente.

Desde que a relação de associação (LinkLO), comparada com a solução 2.4 - Estado Individual para LinkC e Estado de Domínio para

LinkLO, é agora guardada por uma variável de estado individual no Cliente, não tem nenhum uso adicionar um LinkLO a uma Licença, porque o Cliente que adquire a Licença não pode usar o LinkLO por si só para estabelecer prova da associação; isto só pode ser feito com um protocolo em linha.

Note que um desdobramento alternativo para esta solução pode ser a transferência dos atributos de período de validade (e os outros atributos mostrados) das ligações para a administração de estado. Isto significa que a verificação de uma participação ou relação de associação inclui avaliar um período de validade da relação em questão como expresso pela informação de estado e verificar com êxito a associação em questão só se o período de validade não expirou.

Características de solução:

Aspecto/Ação
Novas ligações a Cliente com Domínio fora de linha e/ou Detentor de Licença	Nenhuma criação fora de linha de estado em Cliente.
Não conectando Detentor de Licença	Relação rompida e nenhum acesso a Conteúdo depois de expiração de LO-validityperiod atual.
Não conectando Cliente	Relações rompidas e nenhum acesso a Conteúdo depois de expiração de LOvalidityperiod atual por Detentor de Licença ou C-validityperiod.
Desfazer registro de um Cliente de um Domínio	Imediatamente Cliente não acessará qualquer Conteúdo de Domínio.
Desassociar um detentor de Licença de um Domínio	Esperar pelo mínimo (resto do LOvalidityperiod atual, máximo (resto do Cvalidityperiods)) antes que todos os Clientes não mais acessarão qualquer Conteúdo do Detentor de Licença desassociado. nenhuma renovação de ligações precisada.

[ Remover uma Licença de um detentor de Licença	Esperar por (se Detentor de Licença e Domínio conectado: mínimo (resto do LO-validityperiod atual, máximo (resto de C-validityperiods)) senão resto de LO-validityperiod atual) antes que Cliente nao mais acessará Conteúdo de Licença removida. Todas as Licenças restantes de detentor de Licença devem ser renovadas. Nenhuma renovação de ligações precisada.
Mudar uma Licença (restrições definidas por	Incrementar licenseConfigNr como se uma Licença fosse removida.
usuário)
Administração de estado seguro de Tamanho de Cliente	#domains (DomainId+#LO*(LicenseOwnerId + licenseConfigNr))

2.6 Estado Individual para LinkC, LinkLO e Licença

Esta concretização é ilustrada na Figura 8. Os mecanismos aplicados são:

Mecanismo	Usado para
1.1- Estado Individual para relação	Guardar estado de LinkC, LinkLO e Licença.
1.2 - Períodos de validade para Ligação	Guardar LinkC e LinkLO, forçar troca de informação entre Detentor de Licença e Domínio e forçar troca de informação de configuração de Domínio entre Cliente e Domínio.

Esta solução difere da solução 2.5 - Estado Individual para

LinkC e LinkLO pelo fato que um mecanismo de licenseConfigNr não é usado para guardar o estado de todas as Licenças visadas a um detentor de Licença, mas que todas as Licenças adquiram cada uma variável de estado individual na administração de estado do Domínio e Clientes. Agora toda prova no Cliente precisa de uma variável de estado correspondente na administração de estado do Cliente ser considerada válida em uma avaliação de Licença.

As ligações de um Domínio podem alcançar um Cliente por comunicação direta entre o Domínio e o Cliente. Ligações em um Cliente agora só são válidas quando seu período de validade não está expirado E a variável de estado Domainíd relacionada à participação na administração de estado de Cliente ainda está presente. Isto é verificado no código do Controle das Ligações quando avaliação das Ligações procurando por um caminho o detentor de Licença como requerido na Licença sob avaliação. O código de controle do LinkLO executará as verificações adicionais que o LicenseOwnerld para o LinkLO ainda está registrado como associado na administração de estado do Cliente e que o Licenseld da Licença sob avaliação ainda está registrado na administração de estado do Cliente. Note que esta última verificação para Licenseld também pode ser alocada no código de controle da própria Licença. No caso anterior, isto tem como uma conseqüência que uma verificação específica de sistema de solução é para ser adicionada ao Controle assinado pelo provedor de conteúdo original ou Licença liberada são mudados e assinados pelo Detentor de Licença.

Note que o Licenseld de uma Licença deve estar disponível na Licença. Isto não é ilustrado porém na figura, como é o caso com o outro Id das entidades.

Uma alternativa para administrar variáveis de estado (em memória segura) de entidades e as comunicar em uma base individual para outras entidades para atualizar suas estruturas de estado internas é a definição de provas assinadas e com versão contendo estruturas inteiras definindo estado. Estas provas podem ser distribuídas livremente entre entidades, exatamente como as outras provas e só uma única variável de estado para a versão de uma tal prova precisa ser administrada seguramente por entidades,

Como um exemplo nesta solução, um Domínio pode emitir uma prova com uma lista de todo LicenseOwnerld associado com o Domínio junto com todos os Licenselds por LicenseOwnerld de Licenças visadas ao Detentor de Licença correspondente e liberada ao Domínio. Um Cliente administra o número de versão de uma tal lista branca contendo os ids das Licenças que são válidas de acordo com administração de estado seguramente. Α prova, que pode ser grande em tamanho, não precisa ser armazenada seguramente e não precisa ser comunicada ao Cliente por um protocolo seguro em linha.

O comportamento para um tal mecanismo com respeito à administração de estado da variável de versão já está descrito na solução 2.1 Nenhuma execução por períodos de validade para o domainConfigNr. A . técnica é usada lá para um conjunto de Ligações; aqui pode ser usadapara um conjunto de variáveis de estado em qualquer estrutura. A técnica não é descrita como um mecanismo separado para a invenção, mas certamente pode ser aplicada em combinação com a maioria das outras soluções igualmente.

Note que um desdobramento alternativo para esta solução pode ser a transferência dos atributos de período de validade (e os outros atributos mostrados) das ligações para a administração de estado. Isto significa que a verificação de uma participação ou relação de associação, como também a validade de uma Licença, inclui avaliar um período de validade da relação em questão como expresso pela informação de estado e verificar com êxito a associação em questão só se o período de validade não expirou.

Características de solução:

Aspecto/Ação
Novas ligações a Cliente com Domínio fora de linha e/ou Detentor de Licença	Nenhuma criação fora de linha de estado em Cliente.
Não conectando Detentor de Licença	Relação rompida e nenhum acesso a Conteúdo depois de expiração deDO-validityperiod atual.
Não conectando Cliente	Relações rompidas e nenhum acesso a Conteúdo depois de expiração de LOvalidityperiod atual por Detentor de Licença ou C-validityperiod.
Desfazer registro de um Cliente de um Domínio	Imediatamente Cliente não acessará qualquer Conteúdo de Domínio.

--- Α

Desassociar um detentor de Licença de um Domínio	Esperar pelo mínimo (resto do LOvalidityperiod atual, máximo (resto do Cvalidityperiods)) antes que todos os Clientes não mais acessarão qualquer Conteúdo do Detentor de Licença desassociado. Nenhuma renovação de ligações precisada.
Remover uma Licença de um detentor de Licença	Esperar por (se Detentor de Licença e Domínio conectado: mínimo (resto do LO-validityperiod atual, máximo (resto de C-validityperiods)) senão resto de LO-validityperiod atual) antes que Cliente não mais acessará Conteúdo dc Licença removida. Nenhuma renovação de Licenças precisada. Nenhuma renovação de Ligações precisada.
Mudar uma Licença (restrições definidas por usuário)	Não suportada.
Administração de estado seguro de Tamanho de Cliente	#domains (DomainId+#LO*(LicenseOwnerId + #lics *ConfigNr))

2.7 Estado individual para todas as relações com controle de versão em Licenças

Esta concretização é ilustrada na Figura 9. Os mecanismos aplicados são:

Mecanismo	Usado para
1.1- Estado Individual para relação	Guardar estado de LinkC, LinkLO e Licença.
1.2 - Períodos de validade para Ligação	Guardar LinkC e LinkLO, forçar troca de informação entre Detentor de Licença e Domínio e forçar troca de informação de configuração de Domínio entre Cliente e Domínio,.
1.6- Número de versão para Relação por Estado	Guardar estado de versões de uma Licença.

Esta solução difere da solução 2.6 - Estado Individual para

LinkC, LinkLO e Licença no suporte de versões de Licenças em estado. Um detentor de Licença tem agora para toda Licença que é visada a ele em sua administração de estado um LicControlVersionNr. Uma Licença liberada ao Domínio por um detentor de Licença é atribuída com o valor atual do

LicControlVersionNr e o LicControlVersionNr é comunicado aos Domínios e de lá para os Clientes par ser incorporado em suas administrações de estado.

Um detentor de Licença incrementará seu

LicControlVersionNr quando uma mudança essencial é feita a uma Licença.

Versões prévias da Licença liberada a um Domínio terminarão inúteis (em tempo) porque elas levam um número de versão mais antigo do que o registrado na administração de estado dos Clientes.

A verificação para a presença do Licenseld da Licença sob avaliação na administração de estado do Cliente como elemento do

LicenseOwnerld como elemento do Domainld é estendida com a verificação que o valor do LicControlVersionNr registrado para o LicenseOwnerld não é mais alto do que o valor do LicControlVersionNr atribuído à Licença.

Novamente é opcional alocar este verificação no código de controle do LinkLO ou no código de controle da própria Licença.

Note que um desdobramento alternativo para esta solução pode ser a transferência dos atributos de período de validade (e os outros atributos mostrados) das ligações para a administração de estado.

Características de solução:

Aspecto/Ação
Novas ligações a Cliente com Domínio fora de linha e/ou Detentor de Licença	Nenhuma criação fora de linha de estado em Cliente.
Não conectando Detentor de Licença	Relação rompida e nenhum acesso a Conteúdo depois de expiração de LO-validityperiod atual.
Não-conectando Cliente	Relações rompidas e nenhum acesso a Conteúdo depois de expiração de LOvalidityperiod atual por Detentor de Licença ou C-validityperiod.
Desfazer registro de um Cliente de um Domínio	Imediatamente Cliente não acessará qualquer Conteúdo de Domínio.
Desassociar um detentor de Licença de um Domínio	Esperar pelo mínimo (resto do LOvalidityperiod atual, máximo (resto do Cvalidityperiods)) antes que todos os Clientes não mais acessarão qualquer Conteúdo do Detentor de Licença desassociado. Nenhuma renovação de Ligações precisada.

5Ί

Remover uma Licença de um detentor de Licença	Esperar por (se Detentor de Licença e Domínio conectado: mínimo (resto do LO-validityperiod atual, máximo (resto de C-validityperiods)) senão resto de LO-validityperiod atual) antes que Cliente não mais acessará Conteúdo de Licença removida. Nenhuma renovação de Licenças precisada. Nenhuma renovação de Ligações precisada.
Mudar uma Licença (restrições definidas por usuário)	Espera por (se Detentor de Licença e Domínio conectado: mínimo (resto de LO-validityperiod atual, máximo (resto de C-validityperiod atual)) senão resto de LO-validityperiod atual) ante que Cliente não mais usará uma versão prévia da Licença. A licença mudada deve ser renovada.
Administração de estado seguro de Tamanho de Cliente	#domains (DomainId+#LO*(LicenseOwnerId + lics*(License!d+LicControlVersionNr))

2.8 Ligação de Licença Paralela

Esta concretização é ilustrada na Figura 10. Os mecanismos aplicados são:

Mecanismo	Usado para
1.1- Estado Individual para relação	Guardar estado de LinkC, LinkLO e Licença.
1.2 - Períodos de validade para Ligação	Guardar LinkC e LinkLO, forçar troca de informação entre Detentor de Licença e Domínio e forçar troca de informação de configuração de Domínio entre Cliente e Domínio.
1.6- Número de versão para Relação por Estado	Guardar estado de versões de uma LinkLic.
1.8- Ligação de Licença Paralela para separação de áreas, de controle	Isolar restrições definidas por usuário no Controle do LinkLic.

Esta solução demonstra o uso do mecanismo de Ligação de

Licença Paralela em cima da configuração como descrito na solução 2.7 Estado Individual para todas as relações com controle de versão em Licenças. Veja a descrição do mecanismo paralelo como uma referência para esta solução. O LinkLic é uma ligação do Detentor de Licença à Licença que é visada ao Detentor de Licença. Um LicControlVersionNr é agora usado para controle de versão em estado para o LinkLic, qual Controle é mais provável mudar do que a Licença com o Controle do provedor de conteúdo original.

Quando também a determinação de versão de Licença é requerida, uma versão adicional nr pode ser usada próxima a e operando independente do

LicControlVersionNr.

Mesmas características como com a solução 2.7 - Estado Individual para todas as relações com controle de versão em Licenças 501η vantagem adicional de áreas separadas de controle, onde as restrições definidas por usuário podem ser mudadas sem mudar a Licença.

2.9 Ligação de Licença Serial

Esta concretização é ilustrada na Figura 11. Os mecanismos aplicados são:

Mecanismo	Usado para
1.1- Estado Individual para Relação	Guardar estado de LinkC, LinkLO e Licença.
1.2 - Períodos de validade para Ligação	Guardar LinkC e LinkLO, forçar troca de informação entre Detentor de Licença e Domínio e forçar troca de informação de configuração de Domínio entre Cliente e Domínio.
1.6- Número de Versão para Relação por Estado	Guardar estado de versões de uma LinkLic.
1.9- Ligação de Licença Serial para separação de áreas de controle	Isolar restrições definidas por usuário no Controle do LinkLic.

Esta solução demonstra o uso do mecanismo de Ligação de

Licença Serial em cima da configuração como descrita na solução 2.7 Estado Individual para todas as relações com controle de versão em Licenças. Veja a descrição do mecanismo serial como uma referência para esta solução. O LinkLic é uma ligação do Detentor de Licença à Licença que não é visada ao Detentor de Licença. O LinkLic faz o acoplamento de Conteúdo a um detentor de Licença fazendo esta ligação um elemento essencial no processo de aquisição e movimento de Conteúdo. Um

LicControlVersionNr é usado agora para controle de versão em estado para o LinkLic, qual Controle é mais provável mudar do que a Licença com o Controle do provedor de conteúdo original. Quando também a determinação de versão de Licença é requerida, um versão adicional nr pode ser usada próxima a e operando independente do LicControlVersionNr.

Características de solução:

Mesmas características como com a solução 2.7 - Estado

Individual para todas as relações com controle de versão em Licenças com vantagens adicionais:

Áreas separadas de controle onde as restrições definidas por usuário podem ser mudadas sem mudar a Licença;

Nenhum redirecionamento precisado em Controle de Licença assinado pelo provedor de conteúdo original.

MELHORIAS ADICIONAIS

Restrições definidas por usuário podem ser adicionadas de acordo com o método exposto no Pedido de Patente Internacional WO 05/111760 (registro de agente PHNL040536). Em algumas concretizações acima, desassociar um detentor de Licença de um Domínio requer Clientes esperarem por um certo período, normalmente o resto do LO-validityperiod atual, antes que Clientes não mais acessarão qualquer Conteúdo de Domínio do Detentor de Licença desassociado. Este período então atua como um período de graça durante o qual Conteúdo de Domínio desse Domínio ainda é acessível. Depois, que este período de graça, a associação de Domínio ή cancelada.

Um sistema pode implementar um número máximo de associações de Domínio que podem existir simultaneamente (Domínios ativos). Normalmente isto seria feito com um contador que é aumentado quando um Domínio é criado, e diminuído se uma associação de Domínio for cancelada. Se este contador igualar o máximo, e o usuário desassociar um < - detentor de Licença de um dos seus Domínios, a criação de uma nova associação de Domínio não será permitida até o fim do período de graça, porque só àquele momento o contador é diminuído. Isto é inconveniente para usuários, como eles esperam poder criar uma nova associação de Domínio diretamente depois do ato de desassociar um detentor de Licença de um Domínio existente.

Para melhorar sobre o anterior, o sistema deveria implementar um contador separado para o número de domínios no período de graça (contador de Domínio antigo). Diretamente depois que o detentor de Licença é desassociado do Domínio, o contador de Domínio ativo é diminuído por um. Isto permite a criação de uma nova associação de Domínio imediatamente.

Além de diminuir o contador de Domínio ativo, o contador de Domínio antigo é aumentado. Depois da expiração do período de graça, o contador de Domínio antigo é diminuído. Deste modo, Domínios ativos e Domínios em seus períodos de graça são rastreados separadamente.

Se o contador de Domínio ativo alcançou seu máximo, nenhuma nova associação de Domínio pode ser criada. Porque o contador de Domínio ativo é diminuído agora logo que o usuário desassocia um detentor de Licença de um Domínio, a inconveniência supracitada é reduzida.

Um usuário ainda não é capaz de criar uma nova associação de Domínio diretamente depois de desassociar um detentor de Licença. Isto acontecerá se o contador.de Domínio antigo alcançou seu máximo, e também o contador de Domínio ativo alcançou seu máximo. Esta porém é uma situação muito mais extrema: o usuário teria que ter não só o número de máximo de Domínios ativos, mas também o número máximo de Domínios ainda em seus períodos de graça.

Escolhendo cuidadosamente ambos os máximos, esta possibilidade pode ser reduzida significativamente.

NOTAS FINAIS

No anterior, a declaração min(A, B) deveria ser interpretada como o menor de A e B, e a declaração max(A, B) deveria ser interpretada como o maior de A e B.

Neste documento, as definições seguintes são usadas:

Termo	Definição
Associação	O resultado de estabelecer uma relação entre um detentor de Licença e um Domínio.
Cliente	Entidade funcional que pode adquirir e analisar Licenças e Ligações para o propósito de obter acesso a um caso de Conteúdo baseado nos direitos expressos nessas Licenças e Ligações.
Conteúdo	Quaisquer dados que são pretendidos para serem acessados para consumo humano administrado seguramente por um sistema complacente de Domínio.
Objeto de Controle	Uma representação de regras que governam acesso a conteúdo concedendo ou negando o uso da chave de Conteúdo para conteúdo que elas controlam. Elas também podem ser usadas para representar restrições sobre a validade de um objeto de Ligação em que elas estão embutidas. Elas também podem ser usadas como recipientes de programa independentes que são corridos em nome de outra entidade, tal como em agentes ou delegados. Controles contêm metadados e programas de código de byte, que implementam um protocolo de interação específico.
Dispositivo	Um aplicativo de software e/ou componente de hardware capaz de hospedar um Cliente.
Domínio	Uma coleção identificada unicamente de Clientes e Detentores de Licença.
Configuração de Domínio	A constelação das relações constituindo um Domínio onde relações individuais podem ser expressas em uma prova.
Conteúdo de Domínio	Conteúdo que foi liberado para um Domínio.
Licença	Uma expressão dos direitos que um Autor tem para um caso específico de Conteúdo.
Detentor de Licença	Um representante de um Usuário em um ambiente de Domínio que pode ser concedido direitos para um caso de Conteúdo.

Participação	O resultado de estabelecer uma relação entre um Cliente e um Domínio.
Cliente de Membro	Um Cliente que é membro de um domínio específico.
Autor	Uma entidade de sistema cuja identidade pode ser autenticada.
Liberação	0 processo de conceder todo ou um subconjunto de direitos para um caso de Conteúdo, para uso dentro do Domínio.
Objetivo	Estabelecer uma relação entre uma Licença e um detentor de Licença.
Usuário	0 indivíduo que interage com o sistema, os Dispositivos e Serviços. Uma coleção de detentores de Licença representa o Usuário dentro do sistema.
Regras de Uso	Um conjunto de direitos que governam o uso de Conteúdo protegido. Nota: Regras de Uso PODEM ser expressas explicitamente em uma Licença ou serem determinadas em outro lugar, por regulamento ou em permissões de nível de aplicativo.

Deveria ser notado que as concretizações supracitadas ilustram em lugar de limitar a invenção, e que aqueles qualificados na arte serão capazes de projetar muitas concretizações alternativas sem partir da extensão das reivindicações anexas.

Ao longo das figuras, mesmos numerais de referência indicam características semelhantes ou correspondentes. Algumas das características indicadas nos desenhos são implementadas tipicamente em software, e como tal representam entidades de software, tais como módulos ou objetos de software.

Nas reivindicações, qualquer sinal de referência colocado entre parênteses não deverá ser interpretado como limitando a reivindicação. A palavra incluindo não exclui a presença de elementos ou etapas diferentes daquelas listadas em uma reivindicação. A palavra um ou uma precedendo um elemento não exclui a presença de uma pluralidade de tais elementos. A invenção pode ser implementada por meio de hardware incluindo vários elementos distintos, e por meio de um computador

G<

programado adequadamente.

Nas reivindicações de dispositivo ou sistema enumerando vários meios, alguns ou todos destes meios podem ser concretizados por um e o mesmo item de hardware. O mero fato que certas medidas são recitadas em reivindicações dependentes mutuamente diferentes não indica que uma combinação destas medidas não pode ser usada com vantagem.

i

Claims (10)

1. REIVINDICAÇÕES

   1. Método para administração de direito digital, caracterizado pelo fato de no mesmo o acesso a uma parte de conteúdo é concedida de acordo com uma licença possuída por um detentor de licença a um cliente que

   5 é um membro de um domínio, condicional em uma etapa de verificar com êxito:

   que uma relação de participação existe entre o cliente e o domínio como refletido em uma primeira variável de estado mantida ambos pelo cliente e por controlador do domínio, a presença de uma primeira

   10 variável de estado válida é requerida para verificar com êxito que a relação de participação existe; e que uma relação de associação existe entre o detentor de licença e o domínio como refletido em uma segunda variável de estado mantida ambos pelo controlador do domínio e por um controlador de detentor

   15 de licença associado com o detentor de licença, a presença de uma segunda variável de estado válida é requerida para verificar com êxito que a relação de participação existe, o método incluindo:

   revocar a relação de participação executando um protocolo em

   20 linha entre o controlador do domínio e o cliente depois do que ambos removem a primeira variável de estado; e revocar a relação de associação executando um protocolo em linha entre o controlador de detentor de licença e o controlador do domínio depois do que o controlador do domínio remove a segunda variável de estado

   25 e depois do que a administração de estado relativa ao domínio é propagada ao cliente de forma que a segunda variável de estado seja removida pelo cliente.
2. 2. Método de acordo com reivindicação 1, caracterizado pelo fato de que a verificação da relação de associação e da relação de participação compreende avaliar um período de validade da relação em questão como

   Petição 870180058005, de 04/07/2018, pág. 10/15 expressa pela informação de estado e verificar com êxito a associação em questão só se o período de validade não expirou.
3. 3. Método de acordo com reivindicação 1, caracterizado pelo fato de adicionalmente o controlador de domínio e o cliente mantêm uma

   5 terceira variável de estado para guardar o estado da licença.
4. 4. Método de acordo com reivindicação 3, caracterizado pelo fato de que a terceira variável de estado contém uma representação de um identificador para a licença.
5. 5. Método de acordo com reivindicação 3, caracterizado pelo 10 fato de que o controlador do detentor de licença cria a terceira variável de estado e propaga a terceira variável de estado ao controlador de domínio que propaga a terceira variável de estado ao cliente.
6. 6. Método de acordo com reivindicação 1, caracterizado pelo fato de que a relação de associação entre o detentor de licença e o domínio é

   15 expressa em uma prova na qual o detentor de licença e o domínio são identificados.
7. 7. Método de acordo com reivindicação 1 ou 4, caracterizado pelo fato de que a relação de participação entre o cliente e o domínio é expressa em uma prova na qual o cliente e o domínio são identificados.

   20
8. 8. Método de acordo com reivindicação 4 e/ou 5, caracterizado pelo fato de que a prova leva uma identificação de seu período de validade.
9. 9. Método de acordo com a reivindicação 1, caracterizado pelo cliente ter uma administração de estado e em que o controlador de domínio propaga a administração de estado relativa ao domínio para o cliente, de

   25 forma que o cliente possa atualizar sua administração de estado e remover a variável de estado refletindo a relação de associação.
10. 10. Sistema para administração de direito digital, caracterizado pelo fato de ser configurado para conceder acesso a uma parte de conteúdo de acordo com uma licença possuída por um detentor de licença a um cliente que

    Petição 870180058005, de 04/07/2018, pág. 11/15 é um membro de um domínio, condicional ao verificar com êxito:

    que uma relação de participação existe entre o cliente e o domínio como refletido em uma primeira variável de estado e que uma relação de associação existe entre o detentor de licença e o domínio como

    5 refletido em uma segunda variável de estado, a presença de uma primeira variável de estado válida é requerida para verificar com êxito que a relação de participação existe, a presença de uma segunda variável de estado válida é requerida para verificar com êxito que a relação de participação existe;

    o cliente e um controlador do domínio sendo configurados 10 para ambos manter a primeira variável de estado, e sendo configurados para revocar a relação de participação executando um protocolo em linha entre eles depois do que ambos removem a primeira variável de estado;

    o controlador do domínio e um controlador de detentor de licença associado com o detentor de licença sendo configurado para ambos 15 manter a segunda variável de estado, e sendo configurados para revocar a relação de associação executando um protocolo em linha entre eles depois do que ambos removem a segunda variável de estado, o controlador do domínio ademais sendo configurado para propagar a administração de estado relativa ao domínio para o cliente para fazer o cliente remover a segunda variável de

    20 estado.

    Petição 870180058005, de 04/07/2018, pág. 12/15

    L

    1/11