BRPI0616713A2 - 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

"MÉTODO E SISTEMA PARA ADMINISTRAÇÃO DE DIREITO

DIGITAL"

INTRODUÇÃO

Nos últimos anos, o número de sistemas de proteção deconteúdo disponível tem crescido rapidamente. Alguns destes sistemas sóprotegem o conteúdo contra cópia não autorizada, enquanto outros restringema habilidade do usuário para acessar o conteúdo. Estes sistemas sãofreqü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 redeseus dispositivos para habilitar todos os tipos de aplicativos diferentes eacessar facilmente qualquer tipo de conteúdo. Eles também querem ser capazde compartilhar/transferir conteúdo em seu ambiente doméstico semlimitações.

Domínios Autorizados

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

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

Domínios autorizados precisam tratar assuntos tal comoidentificaçã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, PJ. Lenoir,"Secure Content Management in Authorised Domains", Philips Research,Holanda, publicação de conferência IBC 2002, páginas 467 - 474, mantida em12-16 de setembro de 2002 ou Paul Koster, Frank Kamperman, Peter Lenoir eKoen 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 dedomínios autorizados a alguma extensão. Nos denominados ADs baseados emdispositivos, o domínio é formado por um conjunto específico de dispositivosde hardware ou aplicativos de software (referido coletivamente como clientesdoravante) e conteúdo. Um gerente de domínio ou controlador, que pode serum ou mais dos clientes, um cartão inteligente ou outro dispositivo, controlesque clientes podem unir o domínio. Só o conjunto específico de clientes nodomínio (os membros) é permitido fazer uso do conteúdo desse domínio, porexemplo abrir, copiar, executar ou exportá-lo. Exemplos de tais ADs baseadosem dispositivo são dados no Pedido de Patente Internacional WO 03/098931(registro de agente PHNL020455), Pedido de Patente Internacional WO2005/088896 (registro de agente PHNL040288) e Pedido de PatenteInternacional WO 04/027588 (registro de agente PHNL030283) pelo mesmorequerente, tudo do qual está incorporado por este meio por referência.

Um tipo de AD baseado em dispositivo permite a um conjuntode clientes saltado a um domínio acessar conteúdo saltado àquele domínio.Esta ligação dupla assegura que todos os membros possam acessar oconteúdo. Esta estrutura é freqüentemente estabelecida implementando asligações por uma chave secreta compartilhada. Esta chave é escolhida pelogerente 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 meiode criptografia com a chave compartilhada. Alternativamente, o conteúdopode ser ligado diretamente a um cliente, e os clientes permanecem ligados aoAD.

Outro tipo de AD é o denominado AD baseado em pessoa,onde o domínio é baseado em pessoas em vez de dispositivos. Um exemplode um tal sistema é descrito no Pedido de Patente Internacional WO04/038568 (registro de agente PHNL021063) pelo mesmo requerente,incorporado aqui por referência, em que conteúdo é acoplado a pessoas, queentã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 epessoas. Este grupo é tipicamente limitado a uma residência, tal que:

1. conteúdo pode ser assistido em quaisquer dos membros quepertencem à 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 quepertencem à residência depois que eles se autenticaram em qualquer cliente(tal como uma televisão em um quarto de hotel). Tal autenticação envolvenormalmente um dispositivo de autenticação de usuário tal como um cartãointeligente.

Exemplos de sistemas de AD híbridos podem ser achados noPedido de Patente Internacional WO 2005/010879 (registro de agentePHNL030926) 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 emgeral é uma entidade funcional que pode adquirir e analisar Licenças eLigações para o propósito de adquirir acesso a um caso de Conteúdo baseadonos direitos expressos nessas Licenças e Ligações. Tipicamente, um Cliente éconcretizado como um ou mais aplicativos de software e/ou componentes dehardware. Por exemplo, um Cliente pode ser provido como um aplicativo desoftware em um dispositivo tal como um telefone móvel ou reprodutor demúsica portátil. Um Cliente normalmente inclui um processador para executaras operações necessárias e é equipado com uma memória para armazenarconteúdo e/ou instruções a serem executadas pelo processador. Clientes quesão incluídos no AD são referidos como Clientes de Membro ou apenasabreviado Membros.

Conteúdo é feito disponível aos Clientes de Membro por umou mais Detentores de Licença (LO). Um detentor de Licença em geral é umaentidade 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 serconcedido com direitos para um caso de Conteúdo. Tal concessão de licençapode ser representada no sistema provendo uma Licença que liga (um casoespecífico de) Conteúdo ao Detentor de Licença. Um detentor de Licençapode ser implementado provendo informação em uma estrutura de dados,registro em um banco de dados ou objeto de software. A relação com oUsuário não é explicitamente definida no sistema, mas pode por exemplo serrealizada pelo Usuário tendo um Dispositivo contendo essa informação.

Uma Licença contém permissões e restrições que sãoespecí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 emiti-las e comunicá-las para Clientes pode tomar uma quantidade significante derecursos.

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" porum 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 deveriam serintitulados para acessar esse Conteúdo e deveriam estar associados com oDomínio. A habilidade para acessar Conteúdo por um Cliente implica que acadeia 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 emuma configuração estabelecida de relações pode requerer relações sereminvalidadas para preservar consistência. Em um sistema dividido, todas asentidades na cadeia podem ser desdobradas em hospedeiros diferentes quenão precisam estar conectados um ao outro a toda hora.

Figura 1 ilustra esquematicamente uma tal cadeia deautorização de Cliente para Conteúdo, onde toda relação pode ter umamultiplicidade 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 eConteúdo em uma configuração de Domínio podem ser expressas equalificadas 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 sobreuma parte de Conteúdo é expresso em uma Licença referenciando o detentorde Licença como também a parte de Conteúdo envolvido. Uma Licença étipicamente realizada como um objeto assinado digitalmente incluindo ainformação pertinente em um formato legível por máquina. Tal Licençatambém inclui as permissões específicas e regras de restrição expressas emcódigo de controle executável, armazenado em um denominado objeto deControle na Licença, a ser avaliado no momento que acesso ao Conteúdo édesejado (Note que permissões e restrições também poderiam serrepresentadas 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 serlimitado por uma ou mais restrições, por exemplo, "só 10 vezes" ou "nãoantes das 20:00 horas" ou "só em um sábado". Uma restrição usada emcombinação com uma permissão provê uma condição que limita o uso de umapermissão. Toda permissão pode ter restrições diferentes. Note que cadaLicença tem seu próprio conjunto de permissões e restrições para essaspermissões (em um Controle). O provedor de serviço de conteúdo originaldefine as permissões, possivelmente estendida com várias restrições, em umaLicença. O usuário do sistema, um consumidor, poderia desejar adicionarrestrições de limitação adicionais à Licença para uso em "seu" Domínio. Oprovedor de serviço de conteúdo original não fixa parentais por exemplorestrições de controle, mas o detentor de Licença que libera seu Conteúdoadquirido a um Domínio poderia querer fazer assim. Como um exemplo, umdetentor de Licença define para vários itens de conteúdo que eles nãodeveriam ser acessíveis antes das 22:00 horas, ou que os itens de conteúdonão são acessíveis sem alguma autenticação própria do usuário operando umCliente. Isto conduz a áreas diferentes de controle: uma para o provedor deserviço e uma para o detentor de Licença (usuário) com característicasligeiramente diferentes. E improvável que as colocações de provedor deserviço mudarão; a Licença será revocada completamente quando precisado,resultando em um requisito para revogação de Licenças. Um detentor deLicença (usuário) por outro lado poderia querer mudar sas restriçõespreviamente definidas, resultando em uma requisito para ser capaz depropagar mudanças da Licença no sistema.

A relação de associação entre um detentor de Licença e umDomínio é expressa em uma Ligação dirigida - chamada LinkLO - doDomínio para o detentor de Licença. Tal Ligação pode conter regras derestrição expressas em código de Controle executável, armazenado em umdenominado objeto de Controle na Ligação, qualificando a validade daLigaçã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 oDomínio. Tal Ligação pode conter regras de restrição expressas em código deControle executável, armazenado em um denominado objeto de Controle naLigação, qualificando a validade da Ligação, que deve ser avaliada nomomento que a Ligação é para ser usada. Tal Ligação é preferivelmentecriada usando um objeto assinado digitalmente, em que o Cliente e o Domíniosão identificados.

Atributos podem ser adicionados a Licenças como também aLigações para suportar avaliação de validade e para propósitos de transportede 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 aum certo momento em tempo, por exemplo carregando tal Conteúdo e provascomo precisado, embora alguns destes dados também possam serradiodifundidos 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çõesdefinidas nessa Licença. Para este fim, o Cliente é provido com um módulode avaliação de licença que pode ser realizado como um componente de chipe/ou software seguro, por exemplo em um cartão inteligente.

Em toda Licença há a restrição que, usando as Ligaçõesdiferentes disponíveis para o Cliente, um caminho válido (cadeia de Ligações)do Cliente avaliador para o detentor de Licença deve estar presente. Duranteesta caminho-avaliação, qualquer restrição, sendo uma condição limitando avalidade da Ligação, presente nas Ligações compondo o caminho tambémdeve ser avaliada. Como resultado, uma parte de Conteúdo só pode seracessado quando um caminho de provas é achado entre o Cliente avaliador e aparte 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á ummódulo de acesso de conteúdo acessar o Conteúdo da maneira pedida.Subseqüentemente, o Conteúdo pode ser representado, copiado e/oudistribuído de acordo com as Regras de Uso.

Este sistema funciona bem para conceder direitos a Clientesbaseado na configuração de Domínio. Mudar ou excluir completamentedireitos concedidos prévios para Clientes em uma configuração estabelecidade relações requer relações e suas provas associadas para serem invalidadospara preservar consistência no sistema. As entidades na cadeia podem serdesdobradas em dispositivos diferentes que não precisam ser conectados umao 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 é queaté mesmo quando foi apagada em um Cliente, outra cópia da prova poderia(re)-aparecer nesse Cliente de outro hospedeiro no sistema ou de um sistemade reserva. Isto dá uma abertura para usuários maliciosos ganharem acesso aConteúdo em um Cliente ao qual eles não estão intitulados.Dado o fato que revogação de provas no sistema apagandotodos os casos (cópias) das provas a ser revocadas não é possível, outrosmodos de revogação são precisados para ser capaz de reduzir direitos que umCliente tem para Conteúdo.

SUMÁRIO DA INVENÇÃO

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

Estas duas etapas de verificação provam participação docliente ao domínio, e associação do detentor de licença, e conseqüentementetambém as suas licenças com o domínio. Como resultado, o acesso aoconteúdo pode ser concedido. A relação entre duas partes é preferivelmenteexpressa em uma prova na qual as duas partes são identificadas. A existênciade 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 naLicença ou comunicando a validade da Licença a um Cliente. Desabilitar apossibilidade para acessar, em um tal Domínio, qualquer de conteúdo de umdetentor de Licença específico pode ser arranjado com uma restrição noDomínio —» Ligação de detentor de Licença (LinkLO) ou comunicando avalidade da Ligação para o Cliente. Para desabilitar um único Cliente deacessar qualquer Conteúdo de Domínio, uma operação semelhante para oDispositivo —» Ligação de Domínio (LinkC) pode ser executada.

É benéfico para o sistema quando é possível transportar provasa um Cliente provendo informação nova sobre a configuração de Domínioque pode ser usada imediatamente para acesso de Conteúdo sem anecessidade por protocolos em linha entre partes. Uma aplicação é, quandoum novo detentor de Licença é associado com o Domínio, expresso em umLinkLO, e ele libera Conteúdo ao Domínio, expresso em Licenças, transportedesta prova junto com o Conteúdo a um Cliente não conectado usando algunsmeios habilita o Cliente acessar o Conteúdo sem precisar se conectar a outraparte.

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

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

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

1. Provas devem ser atualizadas em uma base regular parareconfirmar validade requerendo emissores em linha, gerar tráfego de rede erequerendo geração e assinatura de provas atualizadas;2. Nem toda prova em um Cliente interromperá em um Clienteao mesmo tempo dando uma experiência de usuário indesejada especialmentequando Licenças interrompem em momentos diferentes;

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

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

Um dos problemas com o anterior é como revocarseguramente 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 edistribuída, então uma pessoa com intenção maliciosa pode simplesmentecopiar a prova antecipadamente e restaurá-la depois que foi apagada.

Armazenar e administrar provas em memória segura é uma opção, masmemória segura é cara, especialmente ao lidar com um grande número deprovas.

É um objetivo da invenção prover um meio mais eficiente derevocar 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 emlinha entre o controlador do domínio e o cliente depois do que ambosremovem a primeira variável de estado; e

revocar a relação de associação executando um protocolo emlinha entre o controlador de detentor de licença e o controlador do domíniodepois do que o controlador do domínio remove a segunda variável de estadoe depois do que a administração de estado relativa ao domínio é propagada aocliente de forma que a segunda variável de estado seja removida pelo cliente.

Em geral, a invenção resolve este problema tendo as partesidentificadas na ligação para manter estado considerando suas relações, de formaque elas possam simplesmente remover a variável de estado para revocar aligação. O cliente é por exemplo um dispositivo configurado para acessar ereproduzir conteúdo, e precisa ser um membro de um domínio para ser capaz deacessar conteúdo de domínio. O domínio é administrado por um controlador dedomí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áriocujo conteúdo está disponível a dispositivos em 'seu' domínio. Isto requer umarelação de associação entre o detentor de licença e o domínio. O lado dodetentor de licença da associação é cuidado por um dispositivo decontrolador, que poderia ser realizado por exemplo como um cartãointeligente possuído pelo usuário ou como um servidor provido por terceirospor exemplo através da Internet.

O controlador do domínio e o cliente mantém variáveis deestado respectivas relativas à participação do cliente no domínio. A presençade uma variável de estado válida é requerida para verificar com êxito que arelação de participação existe. Quando ambas as entidades apagam estasvariáveis de estado (depois de concordar em fazer assim em um protocolo emlinha), 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 aadministração de estado relativa ao domínio para o cliente, de forma que ocliente possa atualizar sua administração de estado e remover a variável deestado refletindo a relação de associação.

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

Em uma concretização adicional, o controlador de domínio e ocliente mantêm uma terceira variável de estado para guardar o estado dalicença. Isto vantajosamente usa o mecanismo da invenção também para aslicenças e não só para a participação e relações de associação. Estaconcretização permite a invalidação de licenças removendo a terceira variávelde estado. Isto previne a restauração de licenças expiradas ou caso contrárioinvalidadas restabelecendo uma cópia desde que a variável de estado nãopode ser manipulada deste modo. Agora também não há nenhumanecessidade para restringir a cópia de licenças, desde que elas só serão aceitaspor uma parte que tem uma terceira variável de estado válida.

Preferivelmente nesta concretização, o controlador do detentorde licença cria a terceira variável de estado e propaga a terceira variável deestado para o controlador de domínio, que propaga a terceira variável deestado para o cliente. Isto vantajosamente requer só o controlador de detentorde licença ser habilitado a criar a terceira variável de estado, como os outrospodem simplesmente receoe-ia ^aireramenie ou indiretamente) aesiecontrolador. Como o controlador do detentor de licença é implementadopreferivelmente como um módulo seguro, por exemplo um cartão inteligente,de qualquer maneira, nenhuma medida especial precisa ser tomada paraproteger a criação das variáveis de estado.

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

DESCRIÇÃO DETALHADA DE CONCRETIZAÇÕES PREFERIDAS

Figura 2 ilustra esquematicamente um sistema exemplar 100incluindo dispositivos 101-105 e pessoas 130, 131 formando um domínioautorizado (AD). O sistema 100, que visa representar uma rede domésticadigital típica, inclui vários dispositivos, por exemplo um receptor de radio, umsintonizador/decodificador, um reprodutor de CD, um par de alto-falantes,uma televisão, um VCR, um gravador digital, um telefone móvel, umgravador de fita magnética, um computador pessoal, um assistente digitalpessoal, uma unidade de exibição portátil, e assim por diante. Estesdispositivos estão interconectados através de rede 110 para permitir a umdispositivo, 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 quetambém pode incluir serviços interativos, é recebido por um portal residencialou "caixa de topo de aparelho" 101. Conteúdo também poderia entrar na casapor outras fontes, tais como meios de armazenamento como discos ou usandodispositivos portáteis. Ά fonte poderia ser uma conexão a uma rede de cabo debanda larga, uma conexão de Internet, uma ligação inferior de satélite e assimpor diante. O conteúdo pode então ser transferido através da rede 110 a umrecebedor pra representação. Um recebedor pode ser, por exemplo, o tela detelevisão 102, a dispositivo de exibição portátil 103, o telefone móvel 104e/ou o dispositivo de reprodução de áudio 105.

O modo exato no qual um item de conteúdo é representadodepende do tipo de dispositivo e do tipo de conteúdo. Por exemplo, em umreceptor de rádio, representação inclui gerar sinais de áudio e os alimentar aalto-falantes. Para um receptor de televisão, representação geralmente incluigerar sinais de áudio e vídeo e alimentando esses a uma tela de exibição ealto-falantes. Para outros tipos de conteúdo, uma em ação apropriadasemelhante deve ser tomada. Representação também pode incluir operaçõestal 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 outrodispositivo no sistema 100, pode incluir um meio de armazenamento Sl talcomo um disco rígido apropriadamente grande, permitindo a gravação ereprodução posterior de conteúdo recebido. O meio de armazenamento Slpoderia ser um Gravador Digital Pessoal (PDR) de algum tipo, por exemploum 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 umportador 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óvelsão conectados por modo sem fios à rede 110 usando um ponto de acesso semfios 111, por exemplo usando Bluetooth ou IEEE 802.11 b/g. Os outrosdispositivos são conectados usando uma conexão por fios convencional. Parapermitir aos dispositivos 101-105 interagirem, vários padrões deinteroperabilidade estão disponíveis, que permitem a dispositivos diferentestrocarem mensagens e informação e controlar um ao outro. Um padrão bemconhecido é '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 dispositivos101-105. Opcionalmente, vários itens de conteúdo (não mostrado) tambémpodem ser ligados ao Domínio Autorizado. Esta ligação de usuários e/ou deconteúdo pode ser feita da maneira exposta no Pedido de PatenteInternacional WO 04/038568 (registro de agente PHNL021063), da maneiraexposta no Pedido de Patente Internacional WO 2005/010879 (registro deagente PHNL030926), ou da maneira descrita no Pedido de PatenteInternacional número de série LB2005/050910 (registro de agentePHNL040315).

É freqüentemente importante assegurar que os dispositivos101-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 umsistema de Administração de Direito digital (DRM) é necessário. Um modode proteger conteúdo na forma de dados digitais é assegurar que conteúdo sóserá transferido entre dispositivos 101-105 se:

o dispositivo receptor foi autenticado como sendo umdispositivo complacente; e

o usuário do conteúdo tem o direito para transferir (mover e/oucopiar) esse conteúdo para outro dispositivo.

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

Autenticação de membro de AD

Sistemas de proteção de conteúdo, especialmente aquelesestabelecidos como alguma forma de Domínio Autorizado, normalmenteenvolvem comunicação protegida entre membros baseado em algum segredo,só conhecido a dispositivos que foram testados e certificados para terimplementações seguras. Conhecimento do segredo é testado usando umprotocolo de autenticação. Geralmente estes protocolos empregamcriptografia de chave pública, que usam um par de duas chaves diferentes. Osegredo a ser testado é então a chave secreta (às vezes chamada chaveprivada) do par, enquanto a chave pública pode ser usada para verificar osresultados do teste.

Para assegurar a perfeição da chave pública e verificar se o parde chaves é um par legítimo de um dispositivo certificado, a chave pública éacompanhada por um certificado, que é assinado digitalmente por umaAutoridade de Certificação (CA), a organização que administra a distribuiçãode pares de chaves públicas/privadas para todos os dispositivos. Todo mundoconhece a chave pública da CA e pode usá-la para verificar a assinatura daCA 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 chavessecretas. Estas chaves e o fluxo de controle usando estas chaves deveriam serprotegidos, para conhecimento destas chaves ou manipulação do fluxo decontrole permitiria a invasores lograr os sistemas de proteção de conteúdo.

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

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

O cliente, por exemplo quaisquer dos dispositivos 102-105, e ocontrolador de 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 departicipação do cliente ao Domínio. Semelhantemente, o controlador dedomínio e um controlador de detentor de licença associado com o detentor delicença ambos mantêm uma segunda variável de estado que reflete a relaçãode associação entre o detentor de licença e o domínio. O controlador dedetentor de licença é por exemplo um cartão inteligente possuído pelo usuáriorepresentado pelo Detentor de Licença.

Em algumas concretizações, o controlador de domínio e ocliente 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 terceiravariável de estado e a propaga para o controlador de domínio que propaga aterceira variável de estado para o cliente.

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

Um controlador de detentor de licença administra e servemúltiplos Detentores de Licença (zero, um ou mais). Um detentor de Licençaporém só pode ser administrado por um único controlador de detentor delicença. Este controlador é responsável por emitir provas relativas a relaçõesde associação entre o Domínio e Detentores de Licença e por distribuir estasligações e variáveis de estado relacionadas para controladores de Domínio. Ocontrolador pode estar localizado em uma plataforma embutida como tambémaberta. Um controlador de detentor de licença pode ser concedido comautorização para associar e desassociar Detentores de Licença com/deDomínios, adquirir Licenças, importar conteúdo no AD, compartilharConteú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 poruma política de domínio.

Nota que as várias entidades, tal como Cliente, controlador deDomínio e controlador de detentor de licença podem ser implementadas comomódulos de hardware e/ou software em um único dispositivo. A "caixa detopo de aparelho" 101 foi descrita acima por exemplo como um controladorde Domínio, mas certamente também pode operar como um Cliente quandoprecisa acessar certo conteúdo.

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

Em outra concretização, o controlador de Domínio e ocontrolador 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 doisdispositivos separados. Os outros dispositivos 102-105 na casa operam comoClientes. Neste Conteúdo de cenário, uma vez adquirido, está sob o controledo usuário, certamente dentro dos limites fixados pela Licença e qualquerrestrição imposta pelas ligações no AD.

Em ainda outra concretização, o controlador de detentor delicença é provido em um primeiro servidor da Internet e o controlador deDomí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 umcartão inteligente, embora dependendo da funcionalidade requerida isto nãoseja sempre prático. Um cartão inteligente também pode ser usado paraautorizar ou identificar um Usuário de forma que o detentor de Licençaapropriado seja usado.Os mecanismos nos quais a invenção se confia serãoelaborados na seção 1 como eles serão aplicados em combinações diferentes.Qual combinação de mecanismos usar depende da estimação que umprojetista de sistema faz para equilibrar complexidade, recursoscomputacionais, capacidade de armazenamento (seguro) e requisitos dedisponibilidade 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çãosegura de estado de relações é mantida. Valores de estado são trocados entrepartes (entidades) em protocolos em linha seguros. Esta administraçãodetermina 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. Asprovas (Licenças e Ligações) também expressam as mesmas relações. Ainformação de estado administrada seguramente pode ser usada agora paradeterminar a existência de uma relação e com essa a validade de qualquerprova para a mesma relação. Quando este mecanismo é usado para guardar avalidade de uma prova, o código de controle na prova será estendido com umaverificação se a relação, as reivindicações de prova a representar, éadministrada como existindo e válida na administração de estado da entidadeavaliadora (tipicamente um Cliente). Qualquer outra condição, como umperíodo de validade, fixado em uma prova ainda será avaliado. Todas ascondições incluindo a verificação de estado devem ser cumpridas antes que aprova seja aceita como válida. Eliminar a relação nas administrações deestado das entidades diferentes pode agora revocar uma relação no sistema.

A forma mais simples de estado é só a administração daspróprias relações da entidade com vizinhos na cadeia. Ambas as partes(entidades) juntas podem decidir em um protocolo em linha para romper suarelação, que é refletida imediatamente em ambas suas administraçõesinvalidando toda prova para aquela relação para ambas as partes envolvidas.

Outras partes (entidades) na cadeia serão informadas depois desta mudança deestado e ainda considerará a prova como válida. Períodos de validade podemser indicados na informação de estado para forçar proliferação de informaçãode estado 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émcriação de uma variável de estado que deve ser comunicada usandoprotocolos em linha seguros. Um prova pode ser transportada de qualquermodo adequado.

O caso mais trivial para o mecanismo de estado individual é arelação de participação de um Cliente com um Domínio, onde o Cliente fazparte no protocolo de revogação e também é o avaliador da prova. Quando oCliente e o Domínio concordam em um protocolo em linha para romper suarelação, isto é refletido na administração de estado do Cliente. O Clientedesqualificará imediatamente qualquer prova para a relação e nenhumConteúdo relacionado a Domínio é mais acessível no Cliente. No caso maisgeral, onde o avaliador (Cliente) não participa no protocolo quando umarelação é rompida, há o problema de latência de comunicar a mudança deestado ao avaliador.

1.2 Períodos de validade para Ligação

O código de controle na Ligação verificará que o período devalidade das Ligações não está expirado. Quando expirado, a Ligação éconsiderada inválida. Partes usando Ligações, à parte de um mecanismo deestado adicional opcional, para determinar se uma relação na cadeia existeserão urgidas para contatar outras partes na cadeia para receber umarenovação da Ligação com um período de validade estendido e opcionalmentereceber atualizações de informação de estado.1.3 Proliferação de Ligações de Domínio anexadas aLicenç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 umadescrevendo uma parte da configuração de Domínio, pode ser anexadas aLicenças quando elas são emitidas. E benéfico para o sistema quando estainformação potencialmente nova sobre a configuração de Domínio chega aum Cliente e pode ser usada imediatamente para acesso de Conteúdo sem anecessidade por protocolos em linha entre partes. Este mecanismo pode serusado para anexar o LinkLO para um detentor de Licença às Licençasemitidas por aquele Detentor de Licença.

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

Este mecanismo não operará quando mecanismo 1.1- "EstadoIndividual para Relação" é usado para a Ligação, mas pode trabalhar juntocom os mecanismos 1.4 - "Número de Configuração para Relações porEstado" 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 paraRelação", um valor de estado representa uma única relação. Um número deConfiguração representa uma coleção explícita de relações que são tratadasigualmente com respeito à revogação. Só quando uma relação é removida dacoleção, o número de Configuração é incrementado indicando que nem todasas relações previamente parte da coleção ainda são válidas. Adicionar umarelação nova à coleção não incrementará o número porque nós só estamosinteressados em revogação. As provas das relações envolvidas são atribuídascom o valor atual do número de Configuração no momento que eles sãoemitidos e em seu código de controle uma condição é adicionada declarandoque o valor do número de Configuração da prova é igual a ou maior do que ovalor do número de Configuração na administração de estado da entidadeavaliadora (tipicamente Cliente). Quando esta condição não é cumprida, arelação é considerada inválida.

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

Este mecanismo pode ser usado em cascata para os níveisdiferentes de relações na cadeia de autorização, opcionalmente emcombinação com o mecanismo 1.5 - "Número de Configuração para Relaçõespor 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 paraadicionar e remover relações a e da coleção implícita é igual como descritopara 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 nacadeia para a entidade de Cliente e no modo que provas das relaçõesenvolvidas são testadas para validade. As provas das relações envolvidas sãoatribuídas com o valor atual do número de Configuração no momento que elessão emitidos, mas a condição para verificação de validade não é adicionada aseu Controle. O valor atual do número de Configuração é adicionado comoum atributo à Ligação que está próxima em linha da cadeia de autorização nadireçã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 deConfiguração é adicionado ao código de controle da Ligação. Esta Ligaçãoalcançará os Clientes a tempo, forçada pelo período de validade fixado para aLigação. Durante avaliação em um Cliente do caminho para o detentor deLicença, uma Licença é visada, a Ligação será avaliada e o valor de númerode Configuração na Ligação será comparado com o na prova da relaçãoenvolvida (tipicamente a Licença). O número da prova deve ser igual a oumaior do que o valor do número na Ligação. Note que este mecanismo nãosofre da inaptidão para introduzir relações nos Clientes por provas sem ocliente estar conectado, porque há nenhuma operação de estado envolvida.

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

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

Algumas relações, tipicamente as entre Conteúdo e Detentorde Licença não só precisam ser revocadas completamente, mas precisam seradaptadas. Este é o caso, por exemplo quando para uma Licença existente asrestrições definidas por usuário devem ser mudadas. Para suportar controle deversã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 essencialacontece na relação.O valor atual do número de versão deve ser comunicado aClientes para verificar a condição de versão. Atribuir o estado para a relaçãocom 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 protocolosseguros em linha como já descrito para os outros mecanismos de estado.

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

Um pré-requisito para este mecanismo é o uso do mecanismo1.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 porEstado". As diferenças estão na proliferação do número de versão atual nacadeia para a entidade de Cliente e no modo que provas das relaçõesenvolvidas são testadas para validade.

A prova da relação envolvida é atribuída com o valor atual donúmero de versão no momento que é emitido, mas a condição para verificaçãode validade não é adicionada a seu Controle. O valor atual do número de versãoe 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 para oCliente. Note que esta Ligação conterá potencialmente uma lista inteira derelação - combinações de número de versão - uma para cada relação um nívelmais 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á osClientes 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, umaLicença é visada, a Ligação será avaliada e o valor de número de versão paraa relação sob avaliação na Ligação será comparado com o na prova da relaçãoenvolvida (tipicamente a Licença). Note que este mecanismo não sofre dainaptidão para introduzir relações nos Clientes por provas sem o cliente estarconectado, porque não há nenhuma operação de estado envolvida.

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

No conceito básico, um caminho válido para o detentor deLicença deve ser provado e as permissões e restrições na Licença, visadas aoDetentor de Licença, devem ser cumpridas. Restrição definida por usuárioadicional deve, neste conceito, ser adicionada ao Controle na Licença. Usandoligação de Licença paralela, estas restrições definidas por usuário sãoseparadas do conjunto de restrições no Controle da Licença. A Licençavisando 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 darelação de Conteúdo - Licença, como uma Licença deve.

A verificação na Licença agora se tornará que um caminhoválido (cadeia de Ligações) do Cliente avaliador para a Licença deve estarpresente. Quando por razões de segurança o detentor de Licença específicoestando presente no caminho para a Licença deve ser verificado, também averificação original para um caminho válido do Cliente avaliador para o detentorde Licença pode ser adicionada. As restrições definidas por usuário sãoadicionadas agora ao código de controle no LinkLic em vez do Controle daLicença. Como resultado, o Controle de uma Licença não precisa ser mudadoquando um usuário quer adicionar ou mudar restrições definidas por usuárioseparando as áreas de controle e resolvendo os assuntos de segurança quesurgem quando todas as restrições são combinadas em um único Controle.

Relação de Revogação do Conteúdo - Detentor de Licençapode ser feita com um ou uma combinação dos mecanismos de revogaçãodisponí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 parapoder acessar Conteúdo em um Cliente. Quando uma das provas édesabilitada, a relação é revocada. Controle de versão, tipicamente requeridopara restrições definidas por usuário, podem agora ser aplicadas seletivamenteao LinkLic contendo as restrições definidas por usuário.

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

No conceito básico, um caminho válido para o detentor deLicença deve ser provado e as permissões e restrições na Licença, visadas aoDetentor de Licença, devem ser cumpridas. Restrição definida por usuárioadicional deve, neste conceito, ser adicionada ao Controle na Licença. Usandoligação de Licença serial, estas restrições definidas por são separadas doconjunto de restrições no Controle da Licença. A Licença já não visa mais umdetentor de Licença; apenas referencia os itens de conteúdo e contém aspermissões e restrições como fixadas pelo provedor de serviço de conteúdooriginal. A Licença não representa mais a relação completa entre o Conteúdo e odetentor de Licença. A relação com o detentor de Licença é estabelecida erepresentada por uma ligação "nova" LinkLic do Detentor de Licença para aLicença quando ao Detentor de Licença é concedido acesso ao Conteúdo. Noteque 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 tornaráagora que um caminho válido (cadeia de Ligações) do Cliente avaliador para aLicença deve estar presente. As restrições definidas por usuário são adicionadasagora ao código de controle no LinkLic em vez do Controle da Licença. Comoresultado, o Controle de uma Licença não precisa ser mudado quando umusuá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 quandotodas as restrições são combinadas em um único Controle.

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

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

Em soluções prévias, Conteúdo foi visado a um detentor deLicença em uma Licença, para ser mais específico no código de controle daLicença com a verificação que o detentor de Licença deve ser alcançável porum caminho de Ligações. Em uma solução com este mecanismo, oacoplamento de detentor de Licença é feito no LinkLic. Conceder Direitos deacesso 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 deLicença pode reusá-la. O novo detentor de Licença tem que estabelecer umanova referência de LinkLic ele mesmo em cooperação com o antigo detentorde Licença que tem que revocar a relação existente (LinkLic).

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

Com os mecanismos 1.8 - "Ligação de Licença Paralela paraseparação de áreas de controle" e 1.9 - "Ligação de Licença Serial paraseparação de áreas de controle", métodos são descritos para separar áreas decontrole usando os elementos existentes Licença e Ligação. Uma alternativapara esta abordagem é a definição de um novo elemento que combina ocomportamento descrito da Licença e LinkLic. Desde que a Licença eLinkLic sempre aparecem em combinação, este novo elemento pode ser umasubstituição para a combinação de outros dois. Esta alternativa também podeser apresentada como um redefinição do elemento de Licença suportando doisControles internamente com duas áreas diferentes de controle; uma paraconter as permissões e restrições como fixadas pelo provedor de serviço deconteúdo original e uma para as restrições que podem ser adicionadas por umusuário. Neste caso, a verificação original que um caminho válido deLigações para o detentor de Licença deve existir, será usada. Esta alternativaabrange ambos os mecanismos porque o padrão paralelo como também oserial pode ser substituído por um único novo elemento.

2. CONCRETIZAÇÕES PREFERIDAS

As concretizações apresentadas usam os pontos de partidaseguintes:

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, mastipicamente Licenças serão providas por um detentor de Licença e as ligaçõesde Domínio LinkC e LinkLO são providas pelo Domínio;

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

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

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

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

Soluções com um período de validade definido para Licençasque são liberadas ao Domínio são bastante fáceis de definir dados osmecanismos providos, mas sofrem muito das desvantagens discutidas acimasob 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 aplicadospara 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 emfuncionalidade movendo alguns ou todos os atributos de Ligações, comousado nas soluções apresentadas, nas administrações de estado das entidades;

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

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

As entidades na cadeia de autorização são indicadas por umcí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çãorepresentam as relações entre elas; as outras linhas sólidas indicamassociações de atributo;

As linhas pontilhadas indicam a representação de prova dasrelações;Multiplicidade para atributos é indicada com um '*', enquantoa multiplicidade para as relações não é indicada nas figuras;

Provas representando uma relação são indicadas por umretâ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. Estesatributos são acoplados seguramente à prova.

Uma Licença pode ser atribuída com ligações (acoplandoLinkC(s) e LinkLO(s) a uma Licença). Estes atributos de ligação sãoinformadores 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çõescorrespondentes. Os atributos porém são mostrados agora nas figuras.

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

O Clientld, Domainld, LicenseOwnerId e LicenseId sãousados como variáveis de estado para referenciar sua entidadecorrespondente, mas nas figuras para elas não são mostradas como umatributo dessas entidades.

2.1 Nenhuma execução antes de períodos de validadeEsta concretização é ilustrada em Figura 3. Os mecanismosaplicados são:

Mecanismo Usadopara1.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 Clientes1.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 IicenseConfigNr que éincrementado quando quaisquer das Licenças visadas àquele Detentor deLicença é mudada ou é removida indicando uma mudança para uma dasLicenças.

Este IicenseConfigNr deve ser comunicado em um protocoloao Domínio que administra seguramente o IicenseConfigNr mais recente paracada detentor de Licença associado. O Domínio administra umdomainConfigNr que é incrementado quando quaisquer das relações naconfiguração de Domínio muda. Estas mudanças são: um incremento doIicenseConfigNr de quaisquer dos detentores de Licença associados com oDomínio, uma mudança ou remoção de quaisquer das associações dedetentores de Licença com o Domínio, e uma mudança ou remoção dequaisquer das associações de Clientes com o Domínio.

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

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

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

Todos os LinkLOs e todos os LinkCs, como conhecido peloDetentor de Licença, são anexados a uma Licença quando liberados a umDomínio. O Detentor de Licença recebe estas ligações em um protocolo como Domínio.As ligações de um Domínio podem agora alcançar um Clientepor comunicação direta entre o Domínio e o Cliente ou por uma Licençaadquirida pelo Cliente. Um Cliente que administra por Domínio é o membrode uma variável de estado para o domainConfigNr mais recente conhecidopelo Cliente. Este domainConfigNr indica validade para Ligações e Licenças.Quando uma destas provas leva um domainConfigNr como atributo que temum valor mais baixo do que o administrado com seguramente pelo Cliente, aprova é considerada como inválida e deve ser renovada quando possível. Estaverificação é executada por código no Controle das Ligações duranteavaliação de caminho, requerendo que os valores do domainConfigNr naLicença sob avaliação e o domainConfigNr na Ligação sob avaliação nãodevem ser mais baixos do que o administrado pelo Cliente.

O Cliente adaptará seu domainConfigNr, só o incrementandoquando um valor mais alto é encontrado em uma Ligação enviada peloDomínio ou em uma Licença. Todas as relações podem ser revocadas nosistema pelo mecanismo de domainConfigNr, mas não há nenhuma execuçãopara Clientes contatarem um Domínio ou interpretarem uma nova Licença. Oúnico incentivo para um Cliente aceitar esta informação de revogação quandodeseja acessar Conteúdo para qual uma Licença é emitida depois darevogação aconteceu no sistema.

Um detentor de Licença atribui uma Licença com odomainConfigNr 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íniopara receber nova informação de configuração de Domínio, exceto para ocaso onde o IicenseConfigNr foi aumentado e comunicação é requerida antesque Licenças sejam permitidas serem liberadas. Como resultado, ainformação de configuração de Domínio anexada à nova Licença liberada(LinkLOs, LinkCs e o domainConfigNr) pode retardar atrás da situação atualna configuração de Domínio como conhecido pelo Domínio. Isto pode serlogrado requerendo comunicação do Detentor de Licença com um Domíniotoda vez antes que uma Licença é liberada a um Domínio para assegurar ter ainformação de configuração de Domínio mais recente.

Esta solução não implementa a revogação imediata de provasem um Cliente, mas a tempo, quando Conteúdo de Domínio chega, umCliente concordará.

Características de solução:

<table>table see original document page 35</column></row><table><table>table see original document page 36</column></row><table>

2.2 Nenhum estado em Cliente

Esta concretizacao e ilustrada na Figura 4. Os mecanismosaplicados sao:

<table>table see original document page 36</column></row><table>

Um detentor de Licença tem um IicenseConfigNr que éincrementado quando quaisquer das Licenças visadas àquele Detentor deLicença é mudada ou é removida indicando uma mudança para uma dasLicenças. Quando um detentor de Licença libera uma Licença para umDomínio, o detentor de Licença atribui a Licença com o valor atual doIicenseConfigNr. O valor atual do IicenseConfigNr também é atribuído aoLinkLO. Este IicenseConfigNr deveria ser primeiro comunicado em umprotocolo ao Domínio que administra seguramente o IicenseConfigNr maisrecente para cada detentor de Licença associado para ser capaz de emitir umnovo LinkLO com um IicenseConfigNr atualizado. O Controle no LinkLO,durante avaliação de caminho, executará a verificação do IicenseConfigNratribuído à Licença com o atribuído ao LinkLO.

O LinkLO e todos os LinkCs, como conhecido pelo Detentorde Licença, são anexados a uma Licença quando liberada a um Domínio. ODetentor 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 alternativaopcional em cima da distribuição padrão do Domínio para os Clientes, éopcional se depois de um incremento do IicenseConfigNr no Detentor deLicença o detentor de Licença precisar esperar por comunicação com oDomínio para receber o LinkLO com o IicenseConfigNr atualizado. LinkCsanexados a Licenças liberadas podem retardar atrás da situação atual naconfiguraçã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 comunicaro IicenseConfigNr ao Domínio e o Domínio não precisa administrar oIicenseConfigNr. Nesse caso, o detentor de Licença emite diretamente oLinkLO com o IicenseConfigNr atual.

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

Características de solução:

<table>table see original document page 37</column></row><table><table>table see original document page 38</column></row><table>Note que há estado local entre o detentor de Licença eDomínio, mas isto não resulta em um estado individual administrado por umCliente. A relação de associação pode ser revocada em um protocolo em linhaentre o Domínio e o detentor de Licença, onde eles ambos concordam paraterminar a associação e cada um remove a variável de estado relacionada desua administração.

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

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

Desde que a relação de participação, comparada com a solução2.2 - "Nenhum Estado em Cliente", é guardada agora por uma variável deestado individual no Cliente, não tem nenhum uso adicionando um LinkC auma Licença, porque o Cliente que adquire a Licença não pode usar o LinkCpor si só para estabelecer participação; isto só pode ser feito com umprotocolo 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 serestabelecida usando um protocolo entre as duas partes e elas ambasadministram 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 agoraquando o período de validade não é expirado E a variável de estado DomainIdrelacionada à participação LinkC no Cliente ainda está presente. Isto éverificado no código do Controle do LinkC quando avaliação do LinkCprocurando por um caminho o detentor de Licença como requerido naLicença sob avaliação. A relação de participação pode ser revocada em umprotocolo em linha entre o Domínio e o Cliente, onde eles ambos concordampara terminar a participação e cada um remove a variável de estadorelacionada 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 LinkLOagora só é válido quando o período de validade não está expirado E a variávelde estado DomainId relacionada à participação no Cliente ainda está presente.Isto é verificado no código do Controle do LinkLO quando avaliação doLinkLO procurando por um caminho ao Detentor de Licença. O Controle noLinkLO, durante avaliação de caminho, executará a verificação doIicenseConfigNr atribuído à Licença com o atribuído ao LinkLO.

Note que o DomainId de Ligações de Domínio poderia serderivado de sua administração de direção implícita, mas a solução maisrobusta é atribuir toda Ligação a um Domínio com o Domainld. Isto porémnão é ilustrado na figura.

Características de solução:

<table>table see original document page 40</column></row><table><table>table see original document page 41</column></row><table>

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:

<table>table see original document page 41</column></row><table>Note que há estado local entre o detentor de Licença eDomínio, mas isto não resulta em um estado individual administrado por umCliente; só no estado de domainConfigNr combinado. A relação deassociação pode ser revocada em um protocolo em linha entre o Domínio e odetentor de Licença, onde eles ambos concordam para terminar a associação ecada um remove a variável de estado relacionada de sua administração.

Um detentor de Licença tem um IicenseConfigNr que éincrementado quando quaisquer das Licenças visadas àquele Detentor deLicença é mudada ou é removida indicando uma mudança para uma dasLicenç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 IicenseConfigNr.O valor atual do IicenseConfigNr também é atribuído ao LinkLO. Como nósassumimos o Domínio emitir LinkLOs, este IicenseConfigNr deve sercomunicado primeiro em um protocolo ao Domínio que administraseguramente o IicenseConfigNr mais recente para cada detentor de Licençaassociado para ser capaz de emitir um novo LinkLO com um IicenseConfigNratualizado. O Controle no LinkLO, durante avaliação de caminho, executará averificação do IicenseConfigNr atribuído à Licença com o atribuído aoLinkLO.

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

A relação de participação entre um Cliente e um Domínio édeterminada pelo mecanismo de estado individual. Participação só pode serestabelecida usando um protocolo entre as duas partes e elas ambasadministram 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álidoquando o período de validade não está expirado E a variável de estadoDomainld relacionada ao LinkC de participação no Cliente ainda estápresente. Isto é verificado no código do Controle do LinkC quando avaliaçãodo LinkC procurando por um caminho o detentor de Licença como requeridona Licença sob avaliação.

A relação de participação pode ser revocada em um protocoloem linha entre o Domínio e o Cliente, onde eles ambos concordam paraterminar a participação e cada um remove a variável de estado relacionada desua administração. Como uma conseqüência, o LinkC é desabilitado noCliente 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íniomuda. Estas mudanças são: um incremento do IicenseConfigNr de quaisquerdos detentores de Licença associados com o Domínio, uma mudança ouremoção de quaisquer das associações de detentores de Licença com oDomínio, e uma mudança ou remoção de quaisquer das associações deClientes com o Domínio. O Domínio atribui o valor atual do domainConfigNrao LinkC e ao LinkLO.

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

Clientes administram uma variável de estado dedomainConfigNr para todo Domínio do qual eles são membro. Esta variávelde 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 seuperíodo de validade não está expirado E a variável de estado DomainIdrelacionada ao LinkC de participação no Cliente ainda está presente E seuvalor de domainConfigNr não é mais baixo do que o na administração deestado de Cliente. Isto é verificado no código do Controle das Ligaçõesquando avaliação das Ligações procurando por um caminho o detentor deLicença como requerido na Licença sob avaliação. O Controle no LinkLOtambém executará a verificação do IicenseConfigNr atribuído à Licença como atribuído ao LinkLO.

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

Note que o Domainld de Ligações de Domínio poderia serderivado de sua administração de direção implícita, mas a solução maisrobusta é atribuir toda Ligação a um Domínio com o Domainld. Isto porémnão é ilustrado na figura.

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

Características de solução:

<table>table see original document page 45</column></row><table>

2.5 Estado individual para LinkC e LinkLO

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

<table>table see original document page 46</column></row><table>

Um detentor de Licença tem um IicenseConfigNr que éincrementado quando quaisquer das Licenças visadas àquele Detentor deLicença é mudada ou é removida indicando uma mudança para uma dasLicenç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 IicenseConfigNr.

O valor atual do IicenseConfigNr é comunicado em umprotocolo ao Domínio que administra seguramente o IicenseConfigNr maisrecente para cada detentor de Licença associado.

A relação de associação entre um detentor de Licença e umDomínio é determinada pelo mecanismo de estado individual. Uma relação deassociação só pode ser estabelecida usando um protocolo entre as duas partese elas ambas administram este fato em uma variável de estado (Domainldpara o detentor de Licença e LicenseOwnerId para o Domínio). A relação deassociação pode ser revocada em um protocolo em linha entre o Domínio e odetentor de Licença onde eles ambos concordam para terminar a associação ecada um remove as variáveis de estado relacionadas de sua administração. Aadministração de estado de um Domínio é propagada a Clientes quando elesestã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 serestabelecida usando um protocolo entre as duas partes e elas ambasadministram este fato em uma variável de estado (Domainld para o Cliente eClientId 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 aosDetentores de Licença associados com o Domínio. A relação de participaçãopode 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 asvariáveis de estado relacionadas de sua administração.

As ligações de um Domínio podem alcançar um Cliente porcomunicação direta entre o Domínio e o Cliente. Ligações em um Clienteagora só são válidas quando seu período de validade não está expirado E avariável de estado Domainld relacionada à participação na administração deestado de Cliente ainda está presente. Isto é verificado no código do Controledas Ligações quando avaliação das Ligações procurando por um caminho odetentor de Licença como requerido na Licença sob avaliação. O código decontrole do LinkLO executará as verificações adicionais que oLicenseOwnerId para o LinkLO ainda está registrado como associado naadministração de estado do Cliente e que o valor de IicenseConfigNr daLicença sob avaliação é igual a ou maior do que o na administração de estadodo Cliente.

Note que o Domainld de Ligações de Domínio poderia serderivado de sua administração de direção implícita, mas a solução maisrobusta é atribuir toda Ligação para um Domínio com o Domainld. O mesmose mantém para adicionar um LicenseOwnerId explícito ao LinkLO. Istoporém não é ilustrado na figura.

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

Desde que a relação de associação (LinkLO), comparada coma solução 2.4 - "Estado Individual para LinkC e Estado de Domínio paraLinkLO", é 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 Clienteque adquire a Licença não pode usar o LinkLO por si só para estabelecerprova da associação; isto só pode ser feito com um protocolo em linha.

Note que um desdobramento alternativo para esta soluçãopode ser a transferência dos atributos de período de validade (e os outrosatributos mostrados) das ligações para a administração de estado. Istosignifica que a verificação de uma participação ou relação de associaçãoinclui avaliar um período de validade da relação em questão como expressopela informação de estado e verificar com êxito a associação em questão só seo período de validade não expirou.

Características de solução:

<table>table see original document page 48</column></row><table><table>table see original document page 49</column></row><table>

Esta solução difere da solução 2.5 - "Estado Individual paraLinkC e LinkLO" pelo fato que um mecanismo de IicenseConfigNr não éusado para guardar o estado de todas as Licenças visadas a um detentor deLicença, mas que todas as Licenças adquiram cada uma variável de estadoindividual na administração de estado do Domínio e Clientes. Agora todaprova no Cliente precisa de uma variável de estado correspondente naadministração de estado do Cliente ser considerada válida em uma avaliaçãode Licença.

As ligações de um Domínio podem alcançar um Cliente porcomunicação direta entre o Domínio e o Cliente. Ligações em um Clienteagora só são válidas quando seu período de validade não está expirado E avariável de estado DomainId relacionada à participação na administração deestado de Cliente ainda está presente. Isto é verificado no código do Controledas Ligações quando avaliação das Ligações procurando por um caminho odetentor de Licença como requerido na Licença sob avaliação. O código decontrole do LinkLO executará as verificações adicionais que oLicenseOwnerId para o LinkLO ainda está registrado como associado naadministração de estado do Cliente e que o LicenseId da Licença sobavaliação ainda está registrado na administração de estado do Cliente. Noteque esta última verificação para LicenseId também pode ser alocada nocódigo de controle da própria Licença. No caso anterior, isto tem como umaconseqüência que uma verificação específica de sistema de solução é para seradicionada ao Controle assinado pelo provedor de conteúdo original ouLicença liberada são mudados e assinados pelo Detentor de Licença.

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

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

Como um exemplo nesta solução, um Domínio pode emitiruma prova com uma lista de todo LicenseOwnerId associado com o Domíniojunto com todos os LicenseIds por LicenseOwnerId de Licenças visadas aoDetentor de Licença correspondente e liberada ao Domínio. Um Clienteadministra o número de versão de uma tal lista branca contendo os ids dasLicenças que são válidas de acordo com administração de estadoseguramente. A prova, que pode ser grande em tamanho, não precisa serarmazenada seguramente e não precisa ser comunicada ao Cliente por umprotocolo 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". Atécnica é usada lá para um conjunto de Ligações; aqui pode ser usada para umconjunto de variáveis de estado em qualquer estrutura. A técnica não édescrita como um mecanismo separado para a invenção, mas certamente podeser aplicada em combinação com a maioria das outras soluções igualmente.

Note que um desdobramento alternativo para esta soluçãopode ser a transferência dos atributos de período de validade (e os outrosatributos mostrados) das ligações para a administração de estado. Istosignifica 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 devalidade da relação em questão como expresso pela informação de estado everificar com êxito a associação em questão só se o período de validade nãoexpirou.

Características de solução:

<table>table see original document page 51</column></row><table><table>table see original document page 52</column></row><table>

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:

<table>table see original document page 52</column></row><table>

Esta solução difere da solução 2.6 - "Estado Individual paraLinkC, LinkLO e Licença" no suporte de versões de Licenças em estado. Umdetentor de Licença tem agora para toda Licença que é visada a ele em suaadministração de estado um LicControlVersionNr. Uma Licença liberada aoDomínio por um detentor de Licença é atribuída com o valor atual doLicControlVersionNr e o LicControlVersionNr é comunicado aos Domínios ede lá para os Clientes par ser incorporado em suas administrações de estado.

Um detentor de Licença incrementará seuLicControlVersionNr 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 (emtempo) porque elas levam um número de versão mais antigo do que oregistrado na administração de estado dos Clientes.

A verificação para a presença do LicenseId da Licença sobavaliação na administração de estado do Cliente como elemento doLicenseOwnerId como elemento do DomainId é estendida com a verificaçãoque o valor do LicControlVersionNr registrado para o LicenseOwnerId não émais alto do que o valor do LicControlVersionNr atribuído à Licença.

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

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

Características de solução:

<table>table see original document page 53</column></row><table><table>table see original document page 54</column></row><table>

Esta solução demonstra o uso do mecanismo de Ligação deLicenç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 emLicenças". Veja a descrição do mecanismo paralelo como uma referência paraesta 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 paracontrole de versão em estado para o LinkLic, qual Controle é mais provávelmudar 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, umaversão adicional nr pode ser usada próxima a e operando independente doLicControlVersionNr.

Mesmas características como com a solução 2.7 - "EstadoIndividual para todas as relações com controle de versão em Licenças" comvantagem adicional de áreas separadas de controle, onde as restriçõesdefinidas 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 mecanismosaplicados são:

<table>table see original document page 55</column></row><table>

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 emLicenças". Veja a descrição do mecanismo serial como uma referência paraesta solução. O LinkLic é uma ligação do Detentor de Licença à Licença quenão é visada ao Detentor de Licença. O LinkLic faz o acoplamento deConteúdo a um detentor de Licença fazendo esta ligação um elementoessencial no processo de aquisição e movimento de Conteúdo. UmLicControlVersionNr é usado agora para controle de versão em estado para oLinkLic, qual Controle é mais provável mudar do que a Licença com oControle do provedor de conteúdo original. Quando também a determinaçãode versão de Licença é requerida, um versão adicional nr pode ser usadapróxima a e operando independente do LicControlVersionNr.

Características de solução:

Mesmas características como com a solução 2.7 - "EstadoIndividual para todas as relações com controle de versão em Licenças" comvantagens adicionais:

Areas separadas de controle onde as restrições definidas porusuário podem ser mudadas sem mudar a Licença;

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

MELHORIAS ADICIONAIS

Restrições definidas por usuário podem ser adicionadas deacordo com o método exposto no Pedido de Patente Internacional WO05/111760 (registro de agente PHNL040536). Em algumas concretizaçõesacima, desassociar um detentor de Licença de um Domínio requer Clientesesperarem por um certo período, normalmente o resto do LO-validityperiodatual, antes que Clientes não mais acessarão qualquer Conteúdo de Domíniodo Detentor de Licença desassociado. Este período então atua como umperí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 deassociações de Domínio que podem existir simultaneamente (Domíniosativos). Normalmente isto seria feito com um contador que é aumentadoquando um Domínio é criado, e diminuído se uma associação de Domínio forcancelada. Se este contador igualar o máximo, e o usuário desassociar umdetentor de Licença de um dos seus Domínios, a criação de uma novaassociaçã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 parausuários, como eles esperam poder criar uma nova associação de Domíniodiretamente depois do ato de desassociar um detentor de Licença de umDomínio existente.

Para melhorar sobre o anterior, o sistema deveriaimplementar um contador separado para o número de domínios no períodode graça (contador de Domínio antigo). Diretamente depois que o detentorde 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 deDomínio imediatamente.

Além de diminuir o contador de Domínio ativo, o contador deDomínio antigo é aumentado. Depois da expiração do período de graça, ocontador de Domínio antigo é diminuído. Deste modo, Domínios ativos eDomí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 deDomínio ativo é diminuído agora logo que o usuário desassocia um detentorde Licença de um Domínio, a inconveniência supracitada é reduzida.

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

Escolhendo cuidadosamente ambos os máximos, estapossibilidade pode ser reduzida significativamente.NOTAS FINAIS

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

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

<table>table see original document page 58</column></row><table><table>table see original document page 59</column></row><table>

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

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

Nas reivindicações, qualquer sinal de referência colocado entreparênteses não deverá ser interpretado como limitando a reivindicação. Apalavra "incluindo" não exclui a presença de elementos ou etapas diferentesdaquelas listadas em uma reivindicação. A palavra "um" ou "uma"precedendo um elemento não exclui a presença de uma pluralidade de taiselementos. A invenção pode ser implementada por meio de hardwareincluindo vários elementos distintos, e por meio de um computadorprogramado adequadamente.

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

Claims (9)

1. Método para administração de direito digital, caracterizadopelo fato de no mesmo o acesso a uma parte de conteúdo é concedida deacordo com uma licença possuída por um detentor de licença a um cliente queé 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 odomínio como refletido em uma primeira variável de estado mantida ambospelo cliente e por controlador do domínio; eque uma relação de associação existe entre o detentor delicença e o domínio como refletido em uma segunda variável de estadomantida ambos pelo controlador do domínio e por um controlador de detentorde licença associado com o detentor de licença,o método incluindo:revocar a relação de participação executando um protocolo emlinha entre o controlador do domínio e o cliente depois do que ambosremovem a primeira variável de estado; erevocar a relação de associação executando um protocolo emlinha entre o controlador de detentor de licença e o controlador do domíniodepois do que o controlador do domínio remove a segunda variável de estadoe depois do que a administração de estado relativa ao domínio é propagada aocliente de forma que a segunda variável de estado seja removida pelo cliente.

2. Método de acordo com reivindicação 1, caracterizado pelofato de que a verificação da relação de associação e da relação de participaçãocompreende avaliar um período de validade da relação em questão comoexpressa pela informação de estado e verificar com êxito a associação emquestão só se o período de validade não expirou.

3. Método de acordo com reivindicação 1, caracterizado pelofato de adicionalmente o controlador de domínio e o cliente mantêm umaterceira variável de estado para guardar o estado da licença.

4. Método de acordo com reivindicação 3, caracterizado pelofato de que a terceira variável de estado contém uma representação de umidentificador para a licença.

5. Método de acordo com reivindicação 3, caracterizado pelofato de que o controlador do detentor de licença cria a terceira variável deestado e propaga a terceira variável de estado ao controlador de domínio quepropaga a terceira variável de estado ao cliente.

6. Método de acordo com reivindicação 1, caracterizado pelofato de que a relação de associação entre o detentor de licença e o domínio éexpressa em uma prova na qual o detentor de licença e o domínio sãoidentificados.

7. Método de acordo com reivindicação 1 ou 4, caracterizadopelo 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.

8. Método de acordo com reivindicação 4 e/ou 5, caracterizadopelo fato de que a prova leva uma identificação de seu período de validade.

9. Sistema para administração de direito digital, caracterizadopelo fato de ser configurado para conceder acesso a uma parte de conteúdo deacordo com uma licença possuída por um detentor de licença a um cliente queé um membro de um domínio, condicional ao verificar com êxito:que uma relação de participação existe entre o cliente e odomínio como refletido em uma primeira variável de estado e que umarelação de associação existe entre o detentor de licença e o domínio comorefletido em uma segunda variável de estado;o cliente e um controlador do domínio sendo configuradospara ambos manter a primeira variável de estado, e sendo configurados pararevocar a relação de participação executando um protocolo em linha entre elesdepois do que ambos removem a primeira variável de estado;o controlador do domínio e um controlador de detentor delicença associado com o detentor de licença sendo configurado para ambosmanter a segunda variável de estado, e sendo configurados para revocar arelação de associação executando um protocolo em linha entre eles depois doque ambos removem a segunda variável de estado, o controlador do domínioademais sendo configurado para propagar a administração de estado relativaao domínio para o cliente para fazer o cliente remover a segunda variável deestado.