BR112013009278B1

BR112013009278B1 - Terminal de usuário e método para impor uma política de uso de aplicativo gerado por servidor

Info

Publication number: BR112013009278B1
Application number: BR112013009278-5A
Authority: BR
Inventors: Jean-Pierre Ciudad; Augustin J Farrugia; David M'Raihi; Bertrand Mollinier Toublet; Gianpaolo Fasoli; Nicholas T Sullivan
Original assignee: Apple Inc
Priority date: 2010-10-19
Filing date: 2011-10-10
Publication date: 2020-11-24
Also published as: US20190114399A1; EP2630606B1; BR112013009278A2; CN103180859A; US20120095877A1; EP2630606A2; KR20130084671A; MX2013004434A; KR101492757B1; JP5624681B2; JP2013546060A; CN103180859B; US11475106B2; WO2012054252A3; WO2012054252A2; AU2011318417A1; AU2011318417B2

Abstract

DISPOSITIVO ELETRÔNICO E MÉTODO DE APLICAÇÃO DE UMA POLÍTICA DE USO DE APLICATIVO GERADA POR COMPUTADOR. A presente invenção refere-se a sistemas, métodos e meios legíveis por computador não transitórios para aplicar políticas de uso de aplicativo. Como parte de uma transação de compra de aplicativo, o distribuidor de aplicativo cria um recibo (1002) de prova de compra exclusivo. Esse recibo pode ser juntado ao aplicativo e enviado para o comprador. Cada máquina pode manter um arquivo de autorização (1004) que lista os usuários autorizados a usar aplicativos naquela máquina. Um sistema configurado para pôr em prática o método confirma que um usuário está autorizado a usar um aplicativo em uma máquina com base em um recibo (1002) de prova de compra e no arquivo de autorização (1004) forem ambos válidos, o sistema verifica se o identificador de cota do usuário no recibo está contido no arquivo de autorização. Em caso afirmativo, o usuário pode ser considerado autorizado a usar o aplicativo na máquina.

Description

TERMINAL DE USUÁRIO E MÉTODO PARA IMPOR UMA POLÍTICA DE USO DE APLICATIVO GERADO POR SERVIDOR

REFERÊNCIA REMISSIVA A PEDIDOS RELACIONADOS

[001] Esse aplicativo reivindica como prioridade o pedido de patente US Número de Série 12/907.915, intitulado “APPLICATION USAGE POLICY ENFORCEMENT”, depositado em 19 de outubro de 2010, que é incorporado aqui como referência em sua totalidade.

ANTECEDENTES 1. Campo Técnico

[002] A presente invenção refere-se à aplicação de políticas de uso de aplicativo e, mais especificamente, a evitar a execução não autorizada da execução de um aplicativo em um computador.

2. Introdução

[003] Uma característica importante de um software de computador é que um único item de software pode ser instalado em vários computadores sem que haja necessidade de alterar o software. Isso é vantajoso para quem desenvolve o software porque se pode desenvolver o software uma vez e então distribuir o mesmo para muitos usuários diferentes sem qualquer trabalho adicional. Também é vantajoso para o usuário porque ele ou ela pode mover seu software de uma máquina para outra, por exemplo, quando o usuário compra um novo computador. A portabilidade do software também torna possível para um usuário comprar uma só cópia do software e instalá-lo simultaneamente em vários computadores, o que em algumas situações pode não ser desejável. Por exemplo, um software pode ser muito caro para produzir e ter um mercado alvo muito pequeno. Nesse caso, uma cópia não autorizada pode impedir o desenvolvedor de recuperar seus gastos.

[004] Para evitar cópia não autorizada, desenvolvedores de software frequentemente empregam um processo de instalação que requer uma chave de produto exclusiva para cada instalação do software. Esse procedimento evita cópia não autorizada, mas também torna difícil para um usuário migrar de uma máquina para outra. Além disso, essa solução não é prática quando um desenvolvedor de software tem uma política que permite a um usuário instalar o software em um número específico de máquinas.

SUMÁRIO

[005] Características e vantagens adicionais da descrição serão mostradas na descrição a seguir, e em parte serão óbvias a partir da descrição, ou podem ser aprendidas pela prática dos princípios aqui descritos. As características e vantagens da descrição podem ser compreendidas e obtidas por meio dos instrumentos e combinações particularmente apontadas nas concretizações anexas. Essas e outras características da descrição se tornarão mais aparentes como um todo a partir da descrição e concretizações anexas a seguir, ou podem ser aprendidas pela prática dos princípios mostrados aqui.

[006] São descritos aqui sistemas, métodos, e meios de armazenamento legíveis por computador não transitórios para a aplicação de políticas de uso de aplicativo.

[007] Em uma modalidade de servidor de aplicativo, um sistema configurado para praticar o método é configurado para receber uma solicitação de compra. Em resposta à solicitação, o sistema pode criar um recibo de prova de compra para aquela compra. O recibo pode incluir vários itens de informação sobre a transação de compra, tais como o identificador da conta do usuário, o identificador de aplicativo, o número da versão do aplicativo, a data da compra, e classificações para controle parental para o aplicativo. O sistema pode assinar o recibo, juntá-lo ao aplicativo, e enviar o conjunto para o dispositivo do cliente que está fazendo a solicitação.

[008] Em uma modalidade de dispositivo para cliente, quando um usuário quer utilizar um aplicativo em uma máquina, o sistema pode confirmar que a utilização esteja em conformidade com as políticas de utilização. Quando um usuário compra um aplicativo, um recibo de prova de compra do aplicativo é incluído no aplicativo. Para operar o aplicativo adquirido em um determinado dispositivo de cliente, o identificador de conta associado ao aplicativo adquirido tem de ser autorizado no dispositivo do cliente. Cada dispositivo do cliente pode manter um arquivo de autorização que pode especificar um identificador de cliente para aquela máquina de cliente e todos os identificadores de usuário autorizados a utilizar aplicativos no dispositivo desse cliente. Quando um usuário tenta utilizar um aplicativo, o sistema pode confirmar se o recibo de prova de compra e o arquivo de autorização são válidos. Além disso, o sistema pode confirmar que o usuário especificado no recibo de prova de compra está no arquivo da autorização. Em algumas modalidades, se o usuário não estiver no arquivo de autorização, o sistema pode fazer uma requisição para autorizar o usuário.

[009] Como exemplo de um mecanismo de aplicação, o sistema pode incluir um contador de desautorização para tentar impedir que um usuário burle a política de uso do aplicativo. Um campo de contagem de desautorização pode ser incluído no recibo de prova de compra do aplicativo e no arquivo de autorização. Uma contagem de desautorização também pode ser mantida pelo sistema. Quando um usuário efetua uma solicitação de compra de um aplicativo, o sistema pode montar um recibo de prova de compra para aquela compra que inclui a contagem de desautorização corrente para o usuário. Quando um usuário tenta utilizar um aplicativo, o sistema pode confirmar que o recibo de prova de compra e o arquivo de autorização são válidos. Além disso, o sistema pode confirmar que o usuário especificado no recibo de prova de compra está no arquivo de autorização. Finalmente, o sistema pode confirmar se a contagem de desautorização no recibo está abaixo ou é igual à contagem de desautorização no arquivo de autorização. Esse mecanismo de aplicação pode proporcionar uma maneira simples para um usuário transferir o aplicativo por um número programado de vezes, de acordo com os termos da política de uso de aplicativo.

BREVE DESCRIÇÃO DOS DESENHOS

[0010] A fim de descrever a maneira pela qual a vantagem acima descrita e outras vantagens e características da descrição podem ser obtidas, uma descrição mais específica dos princípios brevemente descritos acima será proporcionada com referência a modalidades específicas dos mesmos que estão ilustrados nos desenhos anexos. Entendendo-se que esses desenhos ilustram apenas modalidades exemplificativas da descrição e não são, portanto, considerados como limitativos de seu escopo, os princípios aqui são descritos e explicados com especificidade e detalhes adicionais através do uso dos desenhos anexos, nos quais:

[0011] A figura 1 ilustra uma configuração de sistema exemplificativa para distribuição e utilização do aplicativo;

[0012] A figura 2 ilustra uma compra de aplicativo exemplificativa;

[0013] A figura 3 ilustra um recibo de compra de aplicativo exemplificativa;

[0014] A figura 4 ilustra uma modalidade de método exemplificativa para compra do aplicativo;

[0015] A figura 5 ilustra um arquivo de autorização exemplificativo;

[0016] A figura 6 ilustra uma solicitação de autorização exemplificativa;

[0017] A figura 7 ilustra uma situação exemplificativa para autorização de compra;

[0018] A figura 8 ilustra um método exemplificativo para autorização de iniciação de aplicativo;

[0019] A figura 9 ilustra uma modalidade de método exemplificativa para confirmação de aplicativo;

[0020] A figura 10 ilustra um recibo de compra e um arquivo de autorização exemplificativos com contadores de desautorização;

[0021] A figura 11 ilustra uma modalidade de método exemplificativa para verificação de aplicativo utilizando contadores de desautorização;

[0022] A figura 12 ilustra uma situação de utilização de contador de desautorização exemplificativa; e

[0023] A figura 13 ilustra uma modalidade de sistema exemplificativa.

DESCRIÇÃO DETALHADA

[0024] Várias modalidades da descrição são discutidas em detalhe abaixo. Embora implementações específicas sejam discutidas, deve ser entendido que isto é feito apenas com propósito ilustrativo. Uma pessoa habilitada na técnica relevante vai reconhecer que outros componentes e configurações podem ser usados sem que haja um afastamento do espírito e escopo da invenção. A presente descrição aborda a necessidade na técnica de métodos aperfeiçoados de selecionar conteúdo visado apresentado a um usuário com base em características descritivas da interação do usuário e/ou da interação do usuário com um ou mais itens de conteúdo visado.

[0025] O sistema e método descritos aqui são particularmente úteis para aplicação de políticas de uso de aplicativo em um computador. Uma configuração exemplificativa de sistema 100 para distribuição e utilização de aplicativo é ilustrada na figura 1, em que dispositivos eletrônicos 102, 104 se comunicam por uma rede 110 com um distribuidor 112 de aplicativo eletrônico. O sistema pode ser configurado para uso em uma ampla rede de área, tal como aquela ilustrada na figura 1. Entretanto, os presentes princípios são aplicáveis em uma ampla variedade de configurações de rede que facilitam a intercomunicação de dispositivos eletrônicos. Por exemplo, cada um dos componentes de sistema 100 na figura 1 pode ser implementado de uma maneira localizada ou distribuída em uma rede.

[0026] No sistema 100, os terminais 102 e 104 de usuário interagem com o distribuidor 112 de aplicativo, por comunicação direta e/ou indireta, para obter programas de computador, também conhecidos como aplicativos. Qualquer número ou tipo de terminais de usuário pode interagir com o distribuidor 112 de aplicativo. Por exemplo, um terminal 102 de usuário pode ser um computador de mesa; um laptop; um dispositivo de comunicação que cabe na mão, por exemplo, um telefone celular, um smartphone, um tablet, ou qualquer outro tipo de dispositivo utilizando múltiplas ou não persistentes sessões de rede; etc. O terminal 102 de usuário efetua uma solicitação, tal como uma solicitação de compra, para o distribuidor 112 de aplicativo. O distribuidor 112 de aplicativo responde ou enviando o conteúdo solicitado para o terminal 102 de usuário que fez a solicitação ou negando a solicitação. Uma solicitação pode ser negada, por exemplo, devido a uma falha por parte do terminal 102 de usuário em fornecer um método adequado de pagamento.

[0027] Para facilitar a aplicação das políticas de uso do aplicativo, o distribuidor de aplicativo pode proporcionar ao terminal do usuário solicitante um recibo de prova de compra do aplicativo juntamente com o aplicativo comprado. A figura 2 ilustra uma compra de aplicativo 200 exemplificativa. Na compra de aplicativo 200 exemplificativa, o terminal 102 de usuário efetua uma solicitação de compra para o distribuidor 112 de aplicativo. Como parte da solicitação de compra, o terminal 102 de usuário pode proporcionar informação de conta para o usuário solicitante. Em algumas configurações, a informação de conta pode ser um nome de usuário e uma senha. Em outras configurações, a autorização de conta pode ocorrer como uma interação separada com o distribuidor 112 de aplicativo e, assim, a informação de conta pode ser um identificador de conta exclusivo, tal como DSid. Após receber a solicitação de compra, o distribuidor 112 de aplicativo pode criar um conjunto de aplicativo 206 composto pelo aplicativo 208 e pelo recibo 210 de prova de compra do aplicativo. O distribuidor 112 de aplicativo pode então enviar o conjunto 206 de aplicativo para o terminal 102 de usuário. Como será discutido em maior detalhe abaixo, o recibo de prova de compra do aplicativo pode ser usado posteriormente para ajudar a aplicar uma política de uso para o aplicativo.

[0028] Uma transação de compra inclui qualquer tipo de transação para que um recebedor obtenha um aplicativo e não tenha necessariamente de requerer uma troca em dinheiro ou outro valor. A transação de compra pode incluir um terceiro dando o aplicativo como um presente para o recebedor, ou o recebedor pode resgatar um cupom, código promocional, ou instrumento similar em troca pelo aplicativo. Em alguns casos, uma solicitação de compra pode ser feita para um aplicativo gratuito. Independentemente da necessidade de uma troca monetária ser requerida para se obter o aplicativo, o distribuidor do aplicativo pode fornecer um recibo de prova de compra do aplicativo com o aplicativo.

[0029] Um recibo de prova de compra do aplicativo pode incluir uma variedade de informações, como ilustrado no recibo 300 de prova de compra exemplificativo na figura 3. O recibo de prova de compra do aplicativo pode incluir mais ou menos informações em relação ao que é mostrado na figura 3. O corpo 302 do recibo de prova de compra pode incluir várias informações sobre conta associadas ao usuário que comprou o aplicativo. O usuário pode ser um indivíduo, um grupo de indivíduos, ou uma organização. A informação sobre a conta pode incluir a identidade do usuário, como, por exemplo, um nome de usuário. A informação sobre a conta pode incluir também um identificador de conta exclusivo para o usuário, tal como o DSid. Em algumas configurações, ao invés de incluir a DSid de texto plano, o corpo 302 do recibo de prova de compra pode incluir uma representação exclusiva do DSid. Por exemplo, a representação exclusiva pode ser uma representação de uma via de DSid, por exemplo f(DSid). Em alguns casos, a representação exclusiva pode ser usada para aumentar a s segurança do recibo e/ou a privacidade do usuário. O corpo 302 do recibo de prova de compra pode incluir também vários itens de informação sobre o aplicativo comprado. Por exemplo, o corpo 302 do recibo de prova de compra pode incluir a identidade, o número da versão, e a classificação de controle parental do aplicativo comprado. Em alguns casos, informação adicional sobre o aplicativo pode ser incluída no recibo, tal como uma assinatura do aplicativo. Além disso, o corpo 302 do recibo de prova de compra pode incluir a data da compra.

[0030] Em algumas configurações, um corpo 302 do recibo de prova de compra pode incluir informação adicional e/ou alternativa. Além disso, a organização da informação dentro do 300 recibo de prova de compra pode variar com a configuração do sistema. Em uma variação, um servidor retém uma cópia completa ou parcial do recibo 300 de prova de compra do aplicativo.

[0031] Em algumas configurações, o recibo 300 de prova de compra pode estar em texto plano, o que tornaria o mesmo legível para qualquer usuário que possa entender a disposição do arquivo. Para evitar e/ou detectar modificação não autorizada do recibo 300 de prova de compra, o recibo 300 de prova de compra pode inclui uma assinatura 304 de recibo. A assinatura 304 de recibo pode ser qualquer assinatura digital que possa ser usada para detectar modificação não autorizada do recibo de prova de compra. Por exemplo, o distribuidor 112 do aplicativo pode usar uma função hash criptográfica para gerar uma assinatura digital do corpo 302 do recibo de prova de compra. Em algumas configurações, o distribuidor 112 de aplicativo pode usar um sistema de chave pública para gerar a assinatura digital. Nesse caso, o distribuidor 112 de aplicativo usa sua chave particular para gerar a assinatura 304 do recibo. Um terminal de usuário, o distribuidor de aplicativo, e/ou qualquer outro dispositivo com acesso à chave publica do distribuidor de aplicativo pode então confirmar o recibo 300. Alternativamente, o distribuidor 112 de aplicativo pode usar um sistema de chave para gerar a assinatura 304 do recibo. Nesse caso, a menos que o distribuidor 112 do aplicativo compartilhe sua chave particular, apenas o distribuidor do aplicativo pode verificar o recibo 300.

[0032] A figura 4 é um fluxograma ilustrando etapas em um método exemplificativo 400 para uma compra de aplicativo que inclui um recibo de prova de compra. Tendo em vista a clareza, esse método é discutido em termos de um sistema exemplificativo tal como aquele que é mostrado na figura 1. Embora etapas específicas sejam mostradas na figura 4, em outras modalidades, um método pode ter mais ou menos etapas que as mostradas. As etapas do método e outras figuras podem ser implementadas na ordem ou combinação mostrada, ou em qualquer outra ordem ou combinação.

[0033] Em vários pontos, o distribuidor 112 do aplicativo recebe uma solicitação de um usuário para compra de um aplicativo (402). A solicitação de compra pode vir de qualquer terminal de usuário com acesso ao distribuidor 112 de aplicativo. Como descrito acima, a requisição de compra pode incluir informação sobre contas para o usuário que está fazendo a solicitação que pode ser usada para facilitar a transação, como, por exemplo, o identificador de conta do usuário.

[0034] Em resposta à solicitação de compra, o distribuidor 112 de aplicativo monta um recibo de prova de compra de aplicativo (404), tal como o recibo 300 na figura 3. O recibo de prova de compra de aplicativo pode ser exclusivo para a transação. Por exemplo, mesmo que o usuário tenha comprado anteriormente o aplicativo, o recibo de prova de compra associado a essa solicitação de compra será diferente. Entretanto, em algumas configurações, o recibo de prova de compra pode ser exclusivo para o par usuário, aplicativo, ao invés da transação. Após montar o recibo de prova de compra do aplicativo, o distribuidor 112 de aplicativo cria um conjunto de aplicativo, com base no recibo de prova de compra de aplicativo e no aplicativo (406), e envia o conjunto de aplicativo para o usuário que está fazendo a solicitação (408).

[0035] Após comprar um aplicativo, pode ser possível usar esse aplicativo em múltiplos terminais de usuário. Para evitar que um usuário abuse dessa capacidade, um desenvolvedor de aplicativo pode instituir uma política de uso que limita o número de terminais de usuário nos quais o aplicativo pode ser usado em qualquer momento. Por exemplo, suponha-se que um aplicativo custe dez dólares. Um usuário poderia comprar o aplicativo e então vender uma cópia do aplicativo para nove amigos por um dólar. Cada um dos dez usuários poderia então obter uma cópia do aplicativo de dez dólares por um dólar. Em alguns casos, um desenvolvedor de aplicativo pode estar de acordo com essa situação; entretanto, em outros casos, essa atividade poderia impedir que o desenvolvedor recuperasse seus gastos com o desenvolvimento. Para restringir tal atividade, pode ser estabelecida uma política para limitar o número de cópias a, por exemplo, cinco máquinas. Uma maneira de assegurar que um usuário opere um aplicativo apenas em um número específico de máquinas é fazer com que o usuário autorize cada máquina na qual ele ou ela quer usar o aplicativo.

[0036] Um arquivo de autorização, que pode se encontrar na máquina do usuário, pode ser usado para facilitar a autorização do usuário. A figura 5 ilustra um arquivo de autorização 500 exemplificativo.
O arquivo de autorização 500 pode incluir um corpo 502 de arquivo de autorização. O corpo 502 de arquivo de autorização pode incluir um identificador de máquina exclusivo para a máquina associada ao arquivo de autenticação 500. O identificador de máquina exclusivo pode ser um identificador que pode ser ligado a um terminal de usuário. Por exemplo, os vários componentes de hardware em um computador podem estar associados a um identificador exclusivo, tal como um número de série. Um ou mais desses números de série pode(m) ser usado(s) para criar um identificador de máquina exclusivo.

[0037] O corpo 502 de arquivo de autorização pode conter também um ou mais identificadores de conta exclusivos, por exemplo, DSid. Os identificadores de conta contidos no arquivo de autorização 500 indicam os usuários que estão autorizados a usar aplicativos comprados na máquina. Em algumas configurações, ao invés de incluir o DSid de texto plano, o corpo 502 de arquivo de autorização pode incluir uma representação exclusiva do DSid. Por exemplo, a representação exclusiva pode ser uma representação de DSid, por exemplo f(DSid). Em alguns casos, a representação exclusiva pode ser usada para aumentar a segurança do recibo e/ou da privacidade de usuário.

[0038] Em algumas configurações, um corpo 502 de arquivo de autorização pode incluir informação adicional e/ou alternativa. Além disso, a organização da informação dentro do arquivo 500 de autorização pode variar com a configuração do sistema.

[0039] Em algumas configurações, o arquivo de autorização 500 pode estar em texto plano, que o tornaria legível para qualquer usuário que possa entender a disposição do arquivo. Para evitar e/ou detectar modificação não autorizada do arquivo de autorização 500, o arquivo de autorização 500 pode incluir uma assinatura 504 do arquivo de autorização. A assinatura 504 do arquivo de autorização poderia ser qualquer assinatura digital que possa ser usada para detectar modificação não autorizada do arquivo de autorização. Por exemplo, o distribuidor 112 do aplicativo pode usar uma função hash criptográfica para gerar uma assinatura digital do corpo 502 do arquivo de autorização. Em algumas configurações, o distribuidor 112 do aplicativo pode usar um sistema de chave pública para gerar a assinatura digital. Nesse caso, o distribuidor 112 de aplicativo usa sua chave particular para gerar a assinatura 504 do arquivo de autorização. Um terminal de usuário, o distribuidor de aplicativo, e/ou qualquer outro dispositivo com acesso à chave publica do distribuidor de aplicativo pode então confirmar o arquivo de autorização 500. Alternativamente, o distribuidor 112 de aplicativo pode usar um sistema de chave particular para gerar a assinatura 504 do arquivo de autorização. Nesse caso, a menos que o distribuidor 112 do aplicativo compartilhe sua chave particular, apenas o distribuidor do aplicativo pode confirmar o arquivo de autorização 500.

[0040] Uma solicitação de autorização pode ser feita para o distribuidor de aplicativo ou para qualquer outro dispositivo responsável pela autorização para os usuários no sistema. O arquivo de autorização pode ser usado para manter-se informado sobre quais autorizados estão autorizados a operar aplicativos em um determinado terminal de usuário, enquanto o servidor pode manter registros quanto à autorização para manter-se informado sobre quantas máquinas e/ou exatamente para quais máquinas cada usuário está autorizado. Os registros de autorização no servidor podem ser usados para assegurar que um usuário não está autorizado em mais máquinas do que aquelas permitidas pela política de uso.

[0041] A figura 6 ilustra uma situação 600 de autorização para usuário exemplificativa. Para autorizar um usuário em uma máquina, o servidor 606 recebe o arquivo de autorização 602 e o identificador de conta 604 exclusivo do cliente. O servidor 606 então verifica os registros de autorização 608 para confirmar que o usuário já não está autorizado para seu número máximo permitido de máquinas de acordo com a política de uso. Nesse exemplo, o usuário DSid8 está autorizado para apenas uma máquina, o que é menos que o limite, de modo que o servidor 606 pode autorizar o usuário. Para autorizar o usuário, o servidor 606 atualiza os lançamentos nos registros de autorização para o usuário incluir o identificador de máquina no arquivo de autorização 602, isto é, M1. Isso produz os registros de autorização 610. O servidor também atualiza o arquivo de autorização ao acrescentar o número da conta do usuário, isto é, f(DSid8), e renunciando ao arquivo. O servidor 606 então devolve o arquivo de autorização atualizado 612 para a máquina do usuário. Em algumas configurações, o servidor 606 pode manter outras informações nos registros de autorização. Outros métodos de autorização também são possíveis utilizando-se todas essas etapas ou parte delas.

[0042] Em algumas configurações, a política de uso pode ser estática através de todos os usuários e todos os aplicativos, ou a política de uso pode ser específica para usuário e/ou específica para aplicativo. Por exemplo, uma política de uso pode ser designada de modo que qualquer usuário possa ser autorizado a usar qualquer dos aplicativos que eles compraram em até cinco máquinas em qualquer momento. Entretanto, o sistema também pode ser configurado de modo que uma política de uso possa ser especificada para um aplicativo individual. Por exemplo, um aplicativo poderia permitir aos usuários utilizar o aplicativo em 10 máquinas, enquanto outro aplicativo podería permitir apenas que o usuário usasse o aplicativo em 4 máquinas. Para suportar um esquema de política de uso variável o servidor 606 pode precisar armazenar informações adicionais nos registros de autorização.

[0043] Em algumas configurações, a autorização do usuário pode ocorrer no momento em que o usuário compra o aplicativo. A figura 7 ilustra uma situação 700 exemplificativa para autorização no momento da compra. No método 700, o terminal 102 do usuário efetua uma solicitação de compra para o distribuidor 112 de aplicativo. Além das informações sobre a conta, tais como DSid, a solicitação de compra pode incluir um arquivo de autorização 706 que se encontra no terminal 102 de usuário. O distribuidor 112 de aplicativo pode criar o conjunto 708 de aplicativo utilizando o método 400 na figura 4 e pode executar o método de autorização 600 na figura 6 para atualizar os registros de autorização e produzir o arquivo de autorização 710. O distribuidor 112 de aplicativo pode enviar o conjunto de autorização 710. O distribuidor 112 de aplicativo pode enviar então o conjunto de aplicativo e o arquivo de autorização 710 atualizado para o terminal 102 do usuário que está efetuando a solicitação. Em algumas configurações, o distribuidor 112 de aplicativo age como um intermediário da solicitação de autorização e simplesmente passa a solicitação de autorização para outro dispositivo ou servidor que irá devolver o arquivo de autorização para o distribuidor 112 de aplicativo. Em alguns casos, o usuário é autorizado no terminal 102 do usuário antes de efetuar a solicitação de compra. Nesse caso, o distribuidor 112 de aplicativo pode ou devolver o arquivo de autorização inalterado ou não devolver o arquivo. Em algumas configurações, o terminal de usuário pode determinar que o usuário está autorizado para a máquina sem efetuar uma solicitação de autorização para o servidor.

[0044] Em alguns casos, a autorização no momento da compra pode ser desnecessária porque o usuário não tem intenção de usar o aplicativo na máquina pela qual ele ou ela comprou o aplicativo. Por exemplo, um usuário pode ter uma conexão lenta com a internet em casa, mas uma conexão muito rápida no trabalho. Em alguns casos, as velocidades de conexão com a internet podem não importar, mas para aplicativos grandes uma conexão de rede lenta pode impedir um usuário de comprar um determinado aplicativo. Para uma experiência de compra melhor por parte do usuário, o usuário pode decidir comprar o aplicativo no trabalho e então transferir o aplicativo para o computador caseiro do usuário. Por exemplo, o usuário pode transferir o aplicativo para um disco, por exemplo, um CD-ROM, DVD, drive USB, etc., e então transferir o aplicativo para o computador doméstico, ou o usuário pode estabelecer uma conexão direta de alta velocidade entre o computador do trabalho do usuário e o computador doméstico, por exemplo, através de uma conexão Ethernet. Além disso, para permitir ao usuário copiar o aplicativo para mais de uma máquina, a autorização pode ocorrer quando o usuário tenta usar o aplicativo.

[0045] A figura 8 ilustra uma situação exemplificativa 800 para autorização na iniciação de aplicativo. Nessa situação, o usuário efetua uma solicitação de compra pelo terminal 102 de usuário. A solicitação de compra é enviada para o distribuidor 112 de aplicativo onde o conjunto de aplicativo 806 é preparado utilizando-se o método 400 na figura 4. O conjunto de aplicativo 806 é enviado para o terminal 102 de usuário. Em algum momento, o conjunto de aplicativo 806 é copiado para o terminal 104 de usuário onde o usuário tenta usar o aplicativo. Quando da iniciação do aplicativo, o terminal de usuário envia uma solicitação de autorização para o servidor 606. Em algumas configurações, o servidor 606 e o distribuidor 112 de aplicativo podem ser os mesmos. Entretanto, em outros casos, o servidor 606 e o distribuidor 112 de aplicativo podem ser diferentes. Como parte da solicitação de autorização, o servidor 606 recebe o arquivo de autorização 812 e o identificador 814 da conta do usuário. O servidor 606 executa o método de autorização 600 na figura 6 e devolve o arquivo de autorização atualizado 816 para o terminal 104 do usuário. Agora que o usuário está autorizado na máquina, o usuário pode usar o aplicativo. Em algumas configurações, um usuário pode já estar autorizado a usar aplicativos na máquina. Nesse caso, não são requeridas atualizações para para o arquivo de autorização. Além disso, em alguns casos, o terminal do usuário determina que o usuário está autorizado sem efetuar uma solicitação de autorização para o servidor.

[0046] A situação 600 de autorização para o usuário na figura 6 evita apenas que um usuário seja autorizado a operar aplicativos em um número superior a um número especificado de máquinas. Ao incorporar o recibo de prova de compra de aplicativo criado no momento da compra, a confirmação do aplicativo pode aplicar uma política de uso de aplicativo que limita o uso de um aplicativo particular a um número específico de máquinas ou instâncias em qualquer dado momento. Por exemplo, o aplicativo pode ser a cinco instâncias separadas em cinco máquinas virtuais hóspedes diferentes que se encontram todas em uma só maquina hospedeira física. Quando um usuário compra um aplicativo, um recibo de prova de compra do aplicativo é incluído no aplicativo. Para se utilizar um aplicativo comprado em uma determinada máquina, o identificador de conta no recibo de prova de compra precisa estar autorizado na máquina. Como descrito acima, cada máquina pode manter um só arquivo de autorização que pode especificar o identificador de máquina para a máquina e todos os identificadores de conta de usuários autorizados a operar aplicativos na máquina. Se o identificador de conta no recibo de prova de compra estiver no arquivo de autorização, o aplicativo pode ser usado na máquina. Entretanto, se o usuário associado ao aplicativo não estiver autorizado na máquina, o usuário pode ser autorizado utilizando-se um método de autorização tal como o método 600 na figura 6. Tanto o recibo de prova de compra quanto o arquivo de autorização podem ser confirmados para se evitar modificação não autorizada do recibo de prova de compra e/ou do arquivo de autorização e assegurar que o recibo pertence ao aplicativo e o arquivo de autorização pertence à máquina.

[0047] O método 900 de confirmação de aplicativo exemplificativo na figura 9 pode ser usado para aplicar uma política de uso de aplicativo que é dirigida a uma limitação do usuário que está efetuando a compra a um número específico de máquinas. O método de confirmação 900 pode usar o recibo 300 de prova de compra do aplicativo na figura 3 e o arquivo de autorização 500 na figura 5. Para fins de clareza, o método 900 é discutido em termos de um sistema exemplificativo 100 como mostrado na figura 1. Embora etapas específicas sejam mostradas na figura 8, em outras modalidades um método pode ter mais ou menos etapas que as ilustradas.

[0048] O método 900 de verificação de aplicativo pode ser usado a cada vez que um usuário inicia um aplicativo e pode ser executado localmente pela máquina na qual o aplicativo se encontra. Entretanto, o sistema também pode ser configurado de modo que essa confirmação do aplicativo seja executada menos frequentemente, por exemplo, na primeira iniciação do aplicativo. Além disso, a confirmação do aplicativo pode ser executada efetuando-se uma solicitação de confirmação a um servidor ou ela pode ser uma combinação de ações locais e remotas.

[0049] Mediante a iniciação do aplicativo, o terminal 102 de usuário recebe uma solicitação de confirmar um aplicativo com base em um recibo 300 de prova de compra e um arquivo de autorização 500 (902). Como parte da confirmação do aplicativo, o terminal 102 de usuário pode confirmar o recibo 300 de prova de compra, primeiramente verificando se a assinatura do recibo é válida (904). Se a assinatura não for válida, então será provável que o recibo tenha sido alterado, então o processo de confirmação é abortado e a confirmação falha. Se a assinatura for válida, o terminal 102 de usuário verifica se o identificador de aplicativo no recibo é o mesmo identificador do aplicativo que está sendo confirmado (906). Se ele não for igual, a verificação falha. Se o identificador de aplicativo for igual, o terminal 102 de usuário verifica se o número da versão do aplicativo no recibo é o mesmo número da versão do aplicativo que está sendo confirmado (908). Se o número da versão não combinar, o método de confirmação falha, em caso contrário a confirmação continua.

[0050] O método de confirmação 900 pode incluir também uma confirmação do arquivo de autorização 500. Para confirmar o arquivo de autorização 500, o terminal 102 de usuário verifica se a assinatura no arquivo é válida (910). Se a assinatura não for válida, então é provável que o arquivo de autorização tenha sido alterado, de modo que o processo de confirmação é abortado e a confirmação falha. Se a assinatura for válida, o terminal 102 do usuário verifica se o identificador de máquina no arquivo de autorização é o mesmo identificador para o terminal 102 do usuário (912). Se não for, a verificação falha. Se o identificador de máquina não combina, a confirmação continua.

[0051] Dependendo da configuração, as etapas 904, 906 e 908 podem ser executadas antes, depois, ou paralelamente às etapas 910 e 912. Além disso, as etapas 904-912. Além disso, as etapas 904-912 não têm de ser executadas, mas pela execução das etapas pode se obter um nível de certeza de que os arquivos estão inalterados e correspondem ao aplicativo e à máquina. Depois confirmar o recibo 300 e o arquivo de autorização 500. O terminal 102 de usuário verifica se o número de conta no recibo, por exemplo, f(DSid) está no arquivo de autorização (914). Se estiver, o usuário que comprou o aplicativo está autorizado na máquina, de modo que o aplicativo pode ser iniciado (916). Se o usuário que comprou o aplicativo já não estiver autorizado, o terminal 102 de usuário pode efetuar uma solicitação de autorização para o distribuidor 112 de aplicativo (918). Se a solicitação de autorização tiver sucesso (920), o aplicativo pode iniciar (916), caso contrário a confirmação falha.

[0052] Em algumas configurações, o método de confirmação 900 pode ocorrer dentro do aplicativo. Nesse caso, a ação tomada mediante a confirmação de uma falha depende do desenvolvedor do aplicativo. Por exemplo, mediante falha na confirmação, o aplicativo poderia ser interrompido. Alternativamente, mediante falha na confirmação, o aplicativo poderia continuar sua execução, mas apenas uma funcionalidade limitada estaria disponível. Além disso, dependendo da configuração, o aplicativo pode não ser capaz de solicitar autorização ao usuário.

[0053] Utilizando-se o método de verificação 900 descrito acima, o usuário associado a um aplicativo comprado pode usar o aplicativo no número de máquinas especificado na política de uso. Por exemplo, se o número máximo de máquinas é cinco, o usuário pode copiar o aplicativo para cinco máquinas diferentes e passar pelo processo de autorização em cada máquina. Se o usuário quiser usar o aplicativo em uma sexta máquina, o usuário tem que desautorizar uma das máquinas já autorizadas. Para fazer isso, o usuário pode enviar uma solicitação de “desautorizar” por uma das máquinas autorizadas. Alternativamente, em algumas configurações, o usuário pode enviar uma solicitação de “desautorizar todas” por qualquer máquina, o que terá o efeito de desautorizar todas as máquinas nas quais o usuário estava autorizado. Após desautorizar uma máquina, o usuário pode voltar para a sexta máquina e autorizá-la. Nesse ponto, se o método de verificação 900 tiver sucesso, o usuário pode usar o aplicativo.

[0054] Em alguns casos, um usuário pode tentar burlar a política de uso de máquina máximo. Uma maneira pela qual um usuário pode tentar fazer isso é descrita a seguir. Suponha-se que o usuário associado ao aplicativo comprado já está autorizado para o número máximo de máquinas, por exemplo, cinco. Para liberar uma autorização, o usuário desautoriza uma máquina. Entretanto, antes de emitir a solicitação de “desautorizar”, o usuário faz uma cópia do arquivo de autorização na máquina. Após a desautorização, o usuário copia o arquivo de desautorização de volta no lugar. Agora a máquina entende que o usuário está autorizado embora o usuário tenha sido desautorizado.

[0055] Para enfrentar essa ação de burla, um campo de contagem de desautorização pode ser adicionado ao recibo de prova de compra do aplicativo e ao arquivo de autorização. Além disso, uma contagem de desautorização também pode ser mantida no servidor. A figura 10 ilustra um recibo 1002 de prova de compra exemplificativo e um arquivo de autorização 1004 com campos de contagem de desautorização. No arquivo de autorização 1004, uma contagem de desautorização separada pode estar associada a cada identificador de contagem autorizado. Cada vez que um usuário desautoriza uma máquina, a contagem de desautorização no servidor associado ao identificador de contagem pode ser incrementada. Quando um usuário compra um novo aplicativo, a contagem de desautorização no registro de desautorização associado ao usuário pode ser incluída no recibo de prova de compra do aplicativo. Além disso, quando um usuário autoriza uma máquina, a contagem de desautorização associada a esse identificador de contagem pode ser incluída no arquivo de autorização.

[0056] A contagem de desautorização também pode ser incorporada ao método de confirmação de aplicativo. Quando um usuário tenta utilizar um aplicativo, o método de confirmação pode executar todas as etapas descritas no método de confirmação 900. Entretanto, o método de confirmação também pode verificar se a contagem de desautorização no recibo é menor ou igual à contagem de desautorização no arquivo de autorização. Se essa verificação falhar, o usuário pode ser impedido de usar o aplicativo nessa máquina.

[0057] A figura 11 ilustra um método 1100 de confirmação de aplicativo exemplificativo que usa os contadores de desautorização. O método 1100 de confirmação pode usar o recibo 1002 de prova de compra de aplicativo e o arquivo de autorização 1004 na figura 10. Para fins de clareza, o método 1100 é discutido em termos de um sistema exemplificativo tal como é mostrado na figura 1. Embora etapas específicas sejam mostradas na figura 10, em outras modalidades, um método pode ter mais ou menos etapas do que as ilustradas.

[0058] O método 1100 de confirmação de aplicativo pode ser usado a cada vez que um usuário inicia um aplicativo e pode ser executado localmente pela máquina na qual o aplicativo se encontra. Entretanto, o sistema também pode ser configurado de maneira que a confirmação do aplicativo seja executada menos frequentemente, como na primeira iniciação do aplicativo. Além disso, a confirmação do aplicativo pode ser executada fazendo-se uma solicitação de confirmação para um servidor ou ela pode ser uma combinação de ações locais e remotas.

[0059] Quando da iniciação do aplicativo, o terminal 102 de usuário recebe uma solicitação de confirmação de um aplicativo com base em um recibo 1002 de prova de compra e um arquivo de autorização 1004 (1102). O terminal 102 de usuário pode então confirmar que o recibo 1002 de prova de compra e o depósito de autorização 1004 são válidos utilizando-se etapas similares às 904-912 na figura 9 (1104 e 1106). Se qualquer das etapas de validação falha, o método de confirmação aborta e a confirmação falha. Dependendo da configuração, a etapa 1104 pode ser executada antes, depois, ou paralelamente à etapa 1106. Além disso, as etapas 1104 e 1106 não têm de ser executadas, mas pela execução das etapas pode se obter um nível de certeza de que os arquivos estão inalterados e correspondem ao aplicativo e à máquina.

[0060] Depois de confirmar o recibo 1002 e o arquivo de autorização 1004, o terminal 102 de usuário verifica se o número de conta no recibo, por exemplo, f(DSid) está no arquivo de autorização (1108). Se estiver, o usuário que comprou o aplicativo está autorizado na máquina, e a confirmação pode prosseguir para se verificar as contagens de desautorização. Se o usuário que comprou o aplicativo já não estiver autorizado, o terminal 102 de usuário pode efetuar uma solicitação de autorização para o distribuidor 112 do aplicativo (1110). Se a solicitação de autorização tiver sucesso (1114), o terminal 102 de usuário pode prosseguir e verificar as contagens de desautorização.

[0061] Na etapa 1112, o terminal 102 de usuário confirma as contagens de desautorização verificando se a contagem de desautorização no recibo é menor ou igual à contagem de desautorização na autorização associada ao identificador de conta. Caso seja, a confirmação teve sucesso e o terminal 102 de usuário pode iniciar o aplicativo (1116). Se a confirmação da contagem de desautorização falhar, é provável que uma ação intensiva de desautorização tenha ocorrido, de modo que o usuário é impedido de usar o aplicativo na máquina.

[0062] Como acontece com o método de confirmação 900, o método de confirmação 1100 pode ser executado dentro do aplicativo. Nesse caso, a ação tomada mediante a confirmação de uma falha depende do desenvolvedor do aplicativo. Por exemplo, mediante a confirmação da falha, o aplicativo poderia parar de funcionar. Alternativamente, mediante confirmação de falha, o aplicativo poderia continuar a funcionar, mas uma funcionalidade apenas limitada poderia estar disponível. Além disso, dependendo da configuração, o aplicativo pode não ser capaz a solicitar autorização para o usuário.

[0063] A figura 12 ilustra uma situação de uso de contador de desautorização exemplificativo. Nessa situação, o usuário com identificador de conta DSidl está naquele momento autorizado em cinco máquinas: M1-M5. O usuário também quer poder usar aplicativos em uma sexta máquina M6, mas a política de uso limita o número de autorizações a cinco. Essa condição de situação inicial é refletida nos arquivos de autorização para as máquinas M5 e M6 e em registros de autorização no servidor (1210). O arquivo de autorização da máquina M5 contém um lançamento para DSicM com contagem associada de desautorização de zero. O arquivo de autorização da máquina M6 está vazio. Os registros de autorização no servidor mostram que DSID1 está autorizado nas máquinas M1-M5 e que o usuário não desautorizou quaisquer máquinas.

[0064] Em uma tentativa de usar aplicativos em uma sexta máquina M6, o usuário faz uma cópia do arquivo de autorização em M5 e então desautoriza a máquina. Essas ações são refletidas no arquivo de autorização na máquina M5 e nos registros de autorização no servidor (1220). O arquivo de autorização da máquina M5 agora está vazio. Além disso, a contagem de desautorização é aumentada para um e M5 foi removido da lista de máquinas autorizadas nos registros de autorização no servidor.

[0065] O usuário autoriza agora a máquina M6. Essa ação resulta em duas mudanças, que estão refletidas nas máquinas M5 e M6 e no servidor (1230). Primeiramente, o arquivo de autorização na máquina M6 é atualizado para incluir DSidl com uma contagem de desautorização de 1. Em segundo lugar, os registros de autorização no servidor são atualizados para incluir a máquina M6 na lista de máquinas autorizadas.

[0066] Após a autorização, o usuário substitui o arquivo de autorização pelo arquivo de autorização antigo e compra um aplicativo. As mudanças estão refletidas nas máquinas M5 e M6 e no servidor (1240). A contagem de desautorização no recibo de prova de compra é 1. Quando o usuário tenta usar o aplicativo na máquina M5, a máquina pode confirmar o aplicativo utilizando o método de confirmação 1100. Como a contagem de desautorização no recibo de prova de compra é maior que a contagem de desautorização no arquivo de autorização, o método de verificação 1100 vai falhar na etapa 1112. O usuário então pode ser impedido de usar o aplicativo na máquina.

[0067] A descrição agora se volta para uma discussão de um dispositivo de computação de propósitos gerais. Todos os componentes mostrados na figura 13 e discutidos a seguir ou parte deles podem ser usados para implementar os vários dispositivos e elementos de infraestrutura discutidos acima. Com referência à figura 13, um sistema exemplificativo 1300 inclui um dispositivo 1300 de computação de finalidades gerais, incluindo uma unidade de processamento (CPU ou processador) 1320 e um barramento de sistema 1310 que acopla vários componentes de sistema incluindo a memória 1330 do sistema, tal como a memória apenas para leitura (ROM) 1340 e a memória de aceso aleatório (RAM) 1350 para o processador 1320. O sistema 1300 pode incluir um cache 1322 de memória de alta velocidade conectado diretamente, em grande proximidade, ou integrado como parte do processador 1320. O sistema 1300 copia dados da memória 1330 e/ou do dispositivo de armazenamento 1360 para o cache 1322 para rápido acesso pelo processador 1320. Dessa maneira, o cache 1322 proporciona uma intensificação no desempenho que evita retardos do processador 1320 enquanto aguarda por dados. Esses e outros módulos podem ser configurados para controlar o processador 1320 e fazê-lo desempenhar várias ações. Outra memória 1330 do sistema pode estar disponível para uso também. A memória 1330 pode incluir múltiplos diferentes de memória com diferentes características de desempenho. Pode ser apreciado que está divulgado aqui pode operar em um dispositivo de computação 1300 com mais de um processador 1320 ou em um grupo ou aglomerado de dispositivos de computação juntos em uma mesma rede para proporcionar maior capacidade de processamento. O processador 1320 pode incluir qualquer processador de propósito geral e um módulo de hardware ou módulo de software, tal como o módulo 1 1362, módulo 2 1364, e módulo 3 1366 armazenados no dispositivo de armazenamento 1360, configurado para controlar o processador 1320 e também um processador com propósito específico onde instruções de software são incorporadas no desenho do processador real. O processador 1320 pode ser essencialmente um sistema de computação completamente autossuficiente, contendo múltiplos núcleos ou processadores, um barramento, um controlador de memória, um cache, etc. Um processador com múltiplos núcleos pode ser simétrico ou assimétrico.

[0068] O barramento de sistema 1310 pode ser qualquer uma dentre diversos tipos de estruturas de barramento incluindo um barramento de memória ou controlador de memória, um barramento periférico, e um barramento local utilizando qualquer uma dentre uma variedade de arquiteturas de barramento. Uma entrada/saída básica (BIOS) armazenada na ROM 1340 ou similar, pode proporcionar a rotina básica que ajuda a transferir informação entre elementos dentro do dispositivo de computação 1300, como, por exemplo, quando ele é ligado. O dispositivo de computação 1300 inclui ainda dispositivos de armazenamento 1360 tais como um drive de disco rígido, um drive de disco magnético, um drive de disco óptico, um drive de fita ou similar. O dispositivo de armazenamento 1360 pode incluir módulos de software 1362, 1364, 1366 para controlar o processador 1320. Outros módulos de hardware ou software são considerados. O dispositivo de armazenamento 1360 está conectado ao barramento de sistema 1310 por uma interface de acionamento. Os drives e os meios de armazenamento legíveis por computador associados proporcionam armazenamento não volátil de instruções legíveis por computador, estruturas de dados, módulos de programa e outros dados para o dispositivo de computação 1300. Em um aspecto, um módulo de hardware que executa uma função particular inclui o componente de software armazenado em um meio legível por computador não transitório em conexão com os componentes de hardware necessários, tais como o processador 1320, barramento 1310, dispositivo de saída 1370, e assim por diante, para executar a função. Os componentes básicos são conhecidos dos especialistas na técnica e variações apropriadas são consideradas dependendo do tipo de dispositivo, tais como se o dispositivo 1300 é um dispositivo de computação pequeno, que cabe na mão, um computador de mesa ou um servidor de computador.

[0069] Embora a modalidade exemplificativa descrita aqui empregue o disco rígido 1360, deve ser apreciado por aqueles especializados na técnica que outros tipos de meios legíveis por computador que podem armazenar dados que são acessíveis por um computador, tais como cassetes magnéticos, cartões de memória flash, discos versáteis digitais, cartuchos, memórias de acesso aleatório (RAMs) 1350, memória apenas para leitura (ROM) 1340, um sinal a cabo ou sem fio contendo uma corrente de bit e similar, também podem ser usados no ambiente operacional exemplificativo. Meios de armazenamento legíveis por computador não transitórios excluem expressamente meios como energia, sinais de portador, ondas eletromagnéticas, e sinais per se.

[0070] Para permitir interação do usuário com o dispositivo de computação 1300, um dispositivo de entrada 1390 representa qualquer número de mecanismos de entrada, tais como um microfone para falar, uma tela sensível ao toque para entrada de gesto ou gráfica, teclado, mouse, entrada de movimento, fala e assim por diante. Um dispositivo de saída 1370 também pode ser um ou mais dentre um número de mecanismos de saída conhecidos daqueles especializados na técnica. Em alguns casos, sistemas multimodais permitem a um usuário proporcionar tipos múltiplos de entrada para se comunicar com o dispositivo de computação 1300. A interface de comunicações 1380 geralmente governa e gerencia a entrada do usuário e a saída do sistema. Não há restrição à operação em qualquer arranjo de hardware específico e, portanto, as características básicas aqui podem facilmente ser substituídas por arranjos de hardware ou firmware à medida que elas se desenvolvem.

[0071] Para clareza de exposição, a modalidade do sistema ilustrativo é apresentada como incluindo blocos funcionais individuais incluindo blocos funcionais chamados de “processador” ou processador 1320. As funções que esses blocos representam podem ser proporcionadas através do uso de hardware compartilhado ou dedicado, incluindo, mas não apenas, hardware capaz de executar software e hardware, tal como um processador 1320, que é construído propositadamente para operar como um equivalente de software sendo executado em um processador de propósito geral. Por exemplo, as funções de um ou mais processadores apresentados na figura 13 podem ser proporcionadas por um só computador compartilhado ou por múltiplos processadores (o uso do termo “processador” não deve ser interpretado como se referindo exclusivamente a hardware capaz de executar software). Modalidades ilustrativas podem incluir microprocessador e/ou hardware de processador de sinal digital (DSP), memória apenas para leitura 1340 para armazenar software desempenhando as operações discutidas abaixo, e memória de acesso aleatório (RAM) 1350 para armazenar resultados. Modalidades de hardware de integração em escala muito grande (VLSI), bem como conjunto de circuito VLSI feito por encomenda em combinação com um circuito DSP de propósito geral, também podem ser proporcionados.

[0072] As operações lógicas das várias modalidades são implementadas como: (1) uma sequência de etapas, operações ou procedimentos implementados por computador operando em um circuito programável dentro de um computador de uso geral, (2) uma sequência de etapas, operações ou procedimentos implementados por computador operando em um circuito programável de uso específico; e/ou (3) módulos de máquina ou motores de programa interconectados dentro dos circuitos programáveis. O sistema 1300 mostrado na figura 13 pode praticar todos os métodos enunciados ou parte deles, pode ser uma parte dos sistemas enunciados, e/ou pode operar de acordo com instruções nos meios de armazenamento legíveis por computador não transitórios. Essas operações lógicas podem ser implementadas como módulos configurados para controlar o processador 1320 para que ele desempenhe funções específicas de acordo com a programação do módulo. Por exemplo, a figura 13 ilustra três módulos Mod1, 1362, Mod 2 1364 e Mod 3 1366 que são módulos que controlam o processador 1320 para que ele desempenhe etapas específicas ou uma série de etapas. Esses módulos podem estar armazenados no dispositivo de armazenamento 1360 e carregados na RAM 1350 ou memória 1330 no momento de operar ou podem estar armazenados como seria conhecido na técnica em outros locais de memória legível por computador.

[0073] Modalidades dentro do escopo da presente descrição também podem incluir meios de armazenamento legíveis por computador tangíveis e/ou não transitórios para transportar ou ter instruções executáveis por computador ou estruturas de dados armazenados nos mesmos. Esses meios de armazenamento legíveis por computador não transitórios podem ser qualquer meio disponível que possa ser acessado por um computador com propósito genérico ou especial, incluindo o desenho funcional de qualquer processador com propósito especial, como discutido acima. A título de exemplo, e não de limitação, tais meios legíveis por computador não transitórios podem incluir RAM, ROM, EEPROM, CD-ROM, ou outro armazenamento em disco óptico, armazenamento em disco magnético ou outros dispositivos de armazenamento magnético, ou qualquer outro meio que possa ser usado para transportar ou armazenar meios de código de programa desejados na forma de instruções executáveis por computador, estruturas de dados, ou desenho de chip de processador. Quando a informação é transferida ou proporcionada por uma rede ou outra conexão de comunicação (seja por meio de fios ou cabos, sem utilização de fios, ou uma combinação destes) a um computador, o computador vê adequadamente a conexão como um meio legível por computador. Assim, qualquer conexão é apropriadamente denominada um meio legível por computador. Combinações destes acima também poderiam ser incluídas dentro do escopo do meio legível por computador.

[0074] Instruções executáveis por computador incluem, por exemplo, instruções e dados que levam um computador de propósitos gerais, um computador de propósito especial, ou um dispositivo de processamento com propósito especial a desempenhar uma determinada função ou grupo de funções. Instruções executáveis por computador incluem também módulos de programa que são executados por computadores em ambientes isolados ou de rede. Geralmente, módulos de programa incluem rotinas, programas, componentes, estruturas de dados, objetos, e as funções inerentes ao projeto de processadores com finalidades especiais, etc. que desempenham tarefas particulares ou implementam tipos de dados abstratos particulares. Instruções executáveis por computador, estruturas de dados associadas, e módulos de programa representam exemplos dos meios de código de programa para executar etapas dos métodos descritos aqui. A sequência particular de tais instruções executáveis ou estruturas de dados associada representa exemplo de ações correspondentes para a implementação das funções descritas em tais etapas.

[0075] Os especialistas na técnica irão apreciar que outras modalidades da descrição podem ser praticadas em ambientes de computação em rede com muitos tipos de configurações de sistema de computador, incluindo computadores pessoais, dispositivos que cabem na mão, sistemas multiprocessadores, aparelhos eletrônicos para consumidores com base em microprocessador ou programáveis, computadores pessoais de rede, minicomputadores, computadores de grande porte e similares. Modalidades também podem ser praticadas em ambientes de computação distribuídos onde as tarefas são executadas por dispositivos de processamento locais e remotos que estão conectados (seja por conexões com fios e cabos, conexões sem utilização de fios, ou por uma combinação dos mesmos) através de uma rede de comunicações. Em um ambiente de computação distribuído, módulos de programa podem estar localizados em dispositivos de armazenamento de memória locais e remotos.

[0076] As várias modalidades descritas acima são proporcionadas a título de ilustração apenas e não devem ser interpretadas como limitantes do escopo da descrição. Os especialistas na técnica vão reconhecer imediatamente muitas modificações e alterações que podem ser feitas aos princípios descritos acima sem seguir as modalidades exemplificativas e os aplicativos ilustrados e descritos aqui, e sem que haja um afastamento do espírito e do escopo da descrição.

Claims

Terminal de usuário para impor uma política de uso de aplicativo gerado por servidor, o terminal de usuário compreendendo recurso de processamento dados (1320) configurado para:
enviar, para um servidor (112), uma solicitação de autorização para autorizar um usuário a executar um aplicativo no terminal de usuário;
o terminal de usuário sendo caracterizado pelo fato de que o recurso de processamento dados é ainda configurado para:
receber, a partir do servidor, um primeiro arquivo de autorização (1004), o primeiro arquivo de autorização especificando o usuário e incluindo uma primeira contagem de desautorização associada ao usuário;
receber, a partir do servidor, em resposta a uma solicitação de desautorização (1220), um arquivo de autorização substituto, resultante da desautorização do usuário no terminal de usuário, que não mais especifica o usuário;
receber, a partir do servidor, um recibo de compra do aplicativo (1002) em resposta a uma solicitação de compra para comprar o aplicativo, o recibo de compra de aplicativo (1002) incluindo uma contagem de desautorização associada ao usuário;
comparar (1112) as contagens de desautorização do recibo de compra do aplicativo (1002) do arquivo de autorização; e
negar uso do aplicativo se a contagem de desautorização no recibo de compra do aplicativo (1002) é maior do que a contagem de desautorização no arquivo de autorização.
Terminal de usuário, de acordo com a reivindicação 1, caracterizado pelo fato de que o recurso de processamento dados é ainda configurado para:
receber, através de uma interface de entrada de usuário (1390), a solicitação de desautorização para desautorizar o usuário no terminal de usuário; e
enviar a solicitação de desautorização para o servidor.
Terminal de usuário, de acordo com a reivindicação 1, caracterizado pelo fato de que o recurso de processamento dados é ainda configurado para:
receber, através da interface de entrada de usuário, a solicitação de compra para comprar o aplicativo para o usuário; e
enviar a solicitação de compra para o servidor, em que a solicitação de compra inclui uma identificação do usuário.
Terminal de usuário, de acordo com a reivindicação 1, caracterizado pelo fato de que o recurso de processamento dados é ainda configurado para:
verificar (1104) que o recibo de compra de aplicativo é válido;
verificar (1106) que o arquivo de autorização é válido; e
verificar (1108) que um usuário especificado no recibo de compra do aplicativo está no arquivo de autorização.
Terminal de usuário, de acordo com a reivindicação 4, caracterizado pelo fato de que o recurso de processamento dados é ainda configurado para enviar a solicitação de autorização quando o usuário especificado no recibo de compra do aplicativo não está incluído no arquivo de autorização.
Terminal de usuário, de acordo com a reivindicação 4, caracterizado pelo fato de que o recurso de processamento dados, para confirmar que o recibo de compra do aplicativo é válido, é ainda configurado para:
gerar uma primeira assinatura com base no recibo de compra do aplicativo;
verificar (904) que a primeira assinatura corresponde uma segunda assinatura associada com o recibo de compra do aplicativo;
checar (906) que um identificador de aplicativo no recibo de compra do aplicativo corresponde a um identificador do aplicativo; e
checar (908) que um número de versão de aplicativo no recibo de compra do aplicativo corresponde a um número de versão do aplicativo.
Terminal de usuário, de acordo com a reivindicação 4, caracterizado pelo fato de que o recurso de processamento dados, para confirmar que o primeiro arquivo de autorização é válido, é ainda configurado para:
gerar uma primeira assinatura com base no primeiro arquivo de autorização;
verificar (910) que a primeira assinatura corresponde uma segunda assinatura associada com o arquivo de autorização; e
checar (912) que um identificador de máquina no arquivo de autorização corresponde a um identificador para o terminal de usuário.
Terminal de usuário, de acordo com a reivindicação 4, caracterizado pelo fato de que o recurso de processamento dados é ainda configurado para:
permitir uso do aplicativo quando as etapas de verificação logram;
e
negar pelo menos algum uso do aplicativo quando pelo menos uma das etapas de confirmação falha.
Método para impor uma política de uso de aplicativo gerado por servidor, o método caracterizado pelo fato de que compreende as etapas de, em um terminal de usuário:
enviar, para um servidor, uma solicitação de autorização para autorizar um usuário a executar um aplicativo em uma máquina;
receber, a partir do servidor, um arquivo de autorização (1004), o arquivo de autorização especificando o usuário e incluindo uma primeira contagem de desautorização associada ao usuário;
receber, a partir do servidor, em resposta a uma solicitação de desautorização (1220), um arquivo de autorização substituto, resultante da desautorização do usuário na máquina, que não mais especifica o usuário;
receber, a partir do servidor, um recibo de compra do aplicativo (1002) em resposta a uma solicitação de compra para comprar o aplicativo, o recibo de compra de aplicativo (1002) incluindo uma contagem de desautorização associada ao usuário;
comparar (1112) as contagens de desautorização do recibo de compra do aplicativo (1002) do arquivo de autorização; e
negar uso do aplicativo se a contagem de desautorização no recibo de compra do aplicativo (1002) é maior do que a contagem de desautorização no arquivo de autorização.
Método, de acordo com a reivindicação 9, caracterizado pelo fato de que o recurso de processamento dados é ainda configurado para:
receber, através de uma interface de entrada de usuário (1390), a solicitação de desautorização para desautorizar o usuário no terminal de usuário; e
enviar a solicitação de desautorização para o servidor.
Método, de acordo com a reivindicação 9, caracterizado pelo fato de que o recurso de processamento dados é ainda configurado para:
receber, através da interface de entrada de usuário, a solicitação de compra para comprar o aplicativo para o usuário; e
enviar a solicitação de compra para o servidor, em que a solicitação de compra inclui uma identificação do usuário.
Método, de acordo com a reivindicação 9, caracterizado pelo fato de que o recurso de processamento dados é ainda configurado para:
verificar (1104) que o recibo de compra de aplicativo é válido;
verificar (1106) que o arquivo de autorização é válido; e
verificar (1108) que um usuário especificado no recibo de compra do aplicativo está no arquivo de autorização.
Método, de acordo com a reivindicação 12, caracterizado pelo fato de que o recurso de processamento dados é ainda configurado para enviar a solicitação de autorização quando o usuário especificado no recibo de compra do aplicativo não está incluído no arquivo de autorização.
Método, de acordo com a reivindicação 12, caracterizado pelo fato de que o recurso de processamento dados, para confirmar que o recibo de compra do aplicativo é válido, é ainda configurado para:
gerar uma primeira assinatura com base no recibo de compra do aplicativo;
verificar (904) que a primeira assinatura corresponde uma segunda assinatura associada com o recibo de compra do aplicativo;
checar (906) que um identificador de aplicativo no recibo de compra do aplicativo corresponde a um identificador do aplicativo; e
checar (908) que um número de versão de aplicativo no recibo de compra do aplicativo corresponde a um número de versão do aplicativo.
Método, de acordo com a reivindicação 12, caracterizado pelo fato de que o recurso de processamento dados, para confirmar que o primeiro arquivo de autorização é válido, é ainda configurado para:
gerar uma primeira assinatura com base no primeiro arquivo de autorização;
verificar (910) que a primeira assinatura corresponde uma segunda assinatura associada com o arquivo de autorização; e
checar (912) que um identificador de máquina no arquivo de autorização corresponde a um identificador para o terminal de usuário.
Método, de acordo com a reivindicação 12, caracterizado pelo fato de que o recurso de processamento dados é ainda configurado para:
permitir uso do aplicativo quando as etapas de verificação logram; e
negar pelo menos algum uso do aplicativo quando pelo menos uma das etapas de confirmação falha.