BRPI0807305A2

BRPI0807305A2 - Processo de condução de transações entre um módulo de poagamento e um módulo de segurança

Info

Publication number: BRPI0807305A2
Application number: BRPI0807305-8A
Authority: BR
Inventors: Henri Kudelski
Original assignee: Nagravision Sa
Priority date: 2007-02-27
Filing date: 2008-02-26
Publication date: 2014-05-20
Also published as: EP2126814A1; WO2008104527A1; CA2679055A1; CN101622636B; US20100293098A1; CN101622636A; CA2679055C; EP1965342A1; US8874488B2

Description

PROCESSO DE CONDUÇÃO DE TRANSAÇÕES ENTRE UM MÓDULO DE PAGAMENTO E UM MÓDULO DE SEGURANÇA CAMPO DA TÉCNICA

5

A presente invenção refere-se à proteção de transações entre dois módulos de um usuário, em que um dos módulos é um módulo de pagamento, tal como um cartão pré-pago, e o outro módulo é um módulo de segurança que assume o controle de acesso a dados de acesso condicional. Mste processo pode sér particularmente aplicado ao campo de TV paga. para 10 adquirir eventos ou arquivos tais como filmes, competições esportivas, arquivos de música, aplicativos de software ou outros arquivos similares.

ESTADO DA TÉCNICA

Em aplicativos nos quais um usuário deseja ter acesso a dados de acesso condicional, dois princípios são essencialmente implementados para autorizar esse acesso. Segundo um deles, o direito de acesso é fornecido na forma de assinatura. Neste caso, o(a) usuário(a) geralmente paga um montante que dá a ele(a) o direito de acesso a uma série completa de eventos, em que o preço pago é independente dos eventos realmente acessados.

20

Segundo um outro princípio, o(a) usuário(a) deve adquirir o direito de cada evento a que ele(a) deseja ter acesso. Este é particularmente o caso nos campos de TV paga, vídeo por solicitação ou quando os eventos são solicitados na forma de compras impulsivas. Nessa situação, o(a) usuário(a) geralmente paga um valor que depende do seu consumo de eventos.

25

Os valores a serem pagos podem ser, por exemplo, debitados da conta de um usuário registrado ou subtraídos de um crédito armazenado em um módulo de segurança do usuário. Isso significa que é necessário que o usuário seja registrado antes de ter direito a utilizar este serviço.

30

Em algumas aplicações, não é desejável forçar o usuário, por exemplo, a fornecer detalhes de conta bancária. Pode ser preferível oferecer aos usuários módulos de pagamento na forma de um cartão pré-pago que fornece aos mencionados usuários o direito de acesso a certos conteúdos cujo “valor” corresponde à maior parte do preço de compra do cartão pré-pago. Notadamente, isso permite boa administração do crédito consumido pelo usuário. A dificuldade desses tipos de sistemas é a transferência de créditos ou direitos do módulo de pagamento para um módulo de segurança adaptado de forma segura.

5 Em sistemas conhecidos, tais como no campo de telefonia celular, é possível cobrar um crédito por meio de um cartão pré-pago. Neste tipo de aplicação, uma mensagem tal como SMS (sistema de mensagens curtas) é enviada para um centro de administração, em que essa mensagem contém um número de identificação exclusivo. Por definição, quando a mensagem for enviada para o centro de administração por meio de um telefone, esse centro 10 pode identificar a fonte, pois ele reconhece o número de telefone de onde veio essa mensagem. O centro de administração verifica a autenticidade da mensagem e, caso essa mensagem seja autêntica, envia de volta um código de liberação. Este código de liberação causa o carregamento do telefone com o crédito. O número exclusivo é eliminado em seguida, de tal forma que o envio do mesmo número novamente não creditará o valor por 15 uma segunda vez.

Este tipo de processo não é operativo em todas as aplicações. Particularmente no campo de TV paga, quando um usuário deseja obter um valor correspondente a um evento específico, o processo descrito acima não pode administrar essa solicitação. De fato, quando um crédito 20 é atribuído a uma certa unidade de usuário, é importante garantir que um débito correspondente tenha sido carregado em um módulo de pagamento. Além disso, é necessário que o módulo debitado seja correlacionado ao módulo creditado.

Nos cartões utilizados em telefonia, o valor, na verdade, não é debitado no cartão pré-pago. Na realidade, o cartão serve apenas de apoio para o número a ser enviado para o centro de administração, mas não inclui nenhuma possibilidade de administração de contas.

Este tipo de sistema não pode ser utilizado para a administração de créditos no campo de TV paga pois, em sistemas adaptados à telefonia, a autorização é fornecida ou recusada.

30

Na estrutura de um módulo de pagamento capaz de administrar créditos, no momento da atribuição de um crédito a um módulo de segurança, é importante garantir que um débito correspondente tenha sido carregado no módulo de pagamento, de forma a evitar fraudes. De forma similar, é importante que o módulo debitado seja correlacionado com o módulo creditado, para evitar a atribuição de um crédito a uma pessoa não autorizada.

É necessário, portanto, relacionar os dois cartões de uma forma segura e somente creditar o módulo de segurança caso o cartão pré-pago já tenha sido debitado.

5

Os processos do presente não garantem uma segurança ideal durante esses tipos de transações.

O PedMo de Patente n0 WO 01/52124 descreve um método de pagamento eletrônico utilizado em um sistema de TV paga. Neste sistema, é conduzida uma transação localmente, em que o resultado dessa transação é armazenado em uma memória decodifícadora antes da transmissão para o provedor de acesso comercial.

Neste sistema, um centro de administração inicia uma transação enviando uma mensagem 15 de autorização EMM, que é específica para cada decodificador. Como resultado, muitas mensagens são enviadas desnecessariamente. Além disso, um usuário que deseje iniciar uma transação é incapaz de fazê-lo, devendo aguardar o recebimento de uma mensagem. Adicionalmente, a transação não é realizada em tempo real. Uma primeira etapa da transação é realizada em um dado momento, iniciada pelo provedor de serviços ou um 20 centro de administração. Os dados são armazenados na unidade do usuário durante essa etapa. A segunda etapa da transação é realizada localmente na unidade do usuário. O propósito deste processo é evitar a condução de uma série de transações ao mesmo tempo, o que poderia sobrecarregar o centro de administração.

DESCRIÇÃO DA INVENÇÃO

A presente invenção destina-se a evitar as desvantagens de processos do estado da técnica por meio do desenvolvimento de um processo no qual é possível administrar de forma segura e eficiente a atribuição de um crédito a um módulo de segurança e do débito de um valor correspondente em um módulo de pagamento.

Segundo este processo, um usuário que possui um módulo de segurança pode solicitar em seguida um crédito ou direitos associados a um evento específico. No caso de um crédito, o processo permite garantir que um valor somente seja atribuído a um módulo de segurança caso um valor correspondente tenha sido debitado de um módulo de pagamento. No caso de um direito, esse direito geralmente é associado a um valor. O processo de acordo com a presente invenção permite garantir que o direito não seja atribuído ao módulo de segurança caso um valor correspondente não tenha sido debitado anteriormente do módulo de pagamento.

No processo conforme a presente invenção, é estabelecida uma comunicação entre um módulo de segurança conectado a uma unidade de usuário e um módulo de pagamento adquirido pelo mesmo usuário. A comunicação pode ser uma comunicação em duas vias 10 entre o módulo de segurança e o módulo de pagamento ou uma comunicação de uma via, do módulo de pagamento para o módulo de segurança, dependendo da realização selecionada. Pelo menos uma das comunicações é realizada por meio de trânsito por um centro de administração, enquanto a outra comunicação, no caso de um intercâmbio de duas vias, é realizada localmente, ou seja, na unidade do usuário, ou pelo intermediário do centro de 15 administração. A comunicação pode utilizar, entre outros, o protocolo de comunicação APDU (Unidade de Dados de Protocolo de Aplicativo).

A comunicação entre os módulos permite, por um lado, enviar uma solicitação relativa à transação solicitada e, por outro lado, receber um código relativo a essa transação, desde que as condições de recebimento desse código sejam atendidas.

O objeto da presente invenção é atingido por meio de um processo de condução de transações entre um módulo de pagamento e um módulo de segurança conectados a uma unidade de usuário, em que o processo é caracterizado pelo fato de que compreende as etapas a seguir:

• introdução de vim identificador que representa a transação a ser conduzida por meio de um dispositivo de entrada;

· geração pela unidade de usuário de uma mensagem de controle que contém pelo

menos um código representativo da mencionada transação e um identificador do módulo de segurança que exige a transação;

• envio da mencionada mensagem de controle para o mencionado módulo de pagamento;

10

15

verificação no mencionado módulo de pagamento se ele está autorizado a conduzir a transação desejada;

caso o módulo de pagamento esteja autorizado a conduzir essa transação, execução da transação, armazenagem do resultado da transação no mencionado módulo de pagamento e geração pelo módulo de pagamento de um recibo relativo à transação desejada e ao módulo de segurança relacionado;

envio do mencionado recibo para um centro de administração;

envio de um código de liberação para o módulo de segurança pelo centro de administração; e

registro da transação no mencionado módulo de segurança.

O objeto da presente invenção também é atingido por meio de um processo de condução de transações entre um módulo de pagamento e um módulo de segurança conectados a uma unidade de usuário, em que o processo é caracterizado pelo fato de que compreende as etapas a seguir:

25

• introdução de um identificador que representa a transação a ser conduzida por meio de um dispositivo de entrada;

• geração pela unidade de usuário de uma mensagem de controle que contém pelo menos um código representativo da mencionada transação e um identificador do módulo de segurança que exige a transação;

· envio da mencionada mensagem de controle para um centro de administração;

• envio da mencionada mensagem de controle para o módulo de pagamento;

• verificação no mencionado módulo de pagamento se ele está autorizado a conduzir a transação desejada; • caso o módulo de pagamento esteja autorizado a conduzir essa transação, execução da transação e transmissão de um código de liberação relativo à transação desejada para o módulo de segurança correspondente; e

• registro da transação no mencionado módulo de segurança.

• envio da mencionada mensagem de controle para um centro de administração;

• envio da mencionada mensagem de controle para o módulo de pagamento;

• verificação no mencionado módulo de pagamento se ele está autorizado a conduzir a transação desejada;

• caso o módulo de pagamento esteja autorizado a conduzir essa transação, execução da transação e transmissão de um recibo relativo à transação desejada para o centro de administração;

• elaboração de um código de liberação e envio do código de liberação pelo centro de administração para o módulo de segurança; e • registro da transação no mencionado módulo de segurança. O objeto da presente invenção é adicionalmente atingido por meio de um processo de condução de transações entre um módulo de pagamento e um módulo de segurança conectados a uma unidade de usuário, em que o processo é caracterizado pelo fato de que compreende as etapas a seguir:

• introdução de um identificador que representa a transação a ser conduzida e um identificador do módulo de segurança que exige a transação por meio de um dispositivo de entrada;

• geração de uma mensagem de controle que contém pelo menos um código representativo da mencionada transação pelo módulo de pagamento;

• caso o módulo de pagamento esteja autorizado a conduzir a mencionada transação, execução da transação, armazenagem do resultado da transação no mencionado módulo de pagamento e geração de um recibo pelo módulo de pagamento relativo à transação desejada e ao módulo de segurança relacionado;

• envio do mencionado recibo para um centro de administração;

• elaboração de um código de liberação;

• envio do mencionado código de liberação para o módulo de segurança; e

• registro da transação no mencionado módulo de segurança.

BREVE DESCRIÇÃO DAS FIGURAS

A presente invenção e as suas vantagens serão mais bem compreendidas com referência às figuras anexas e à descrição detalhada de realizações específicas, nas quais: as Figuras 1 a 4 representam esquematicamente os componentes utilizados para a execução de diferentes variantes do processo conforme a presente invenção;

- a Figura 5 representa, de forma detalhada, o processo de transferência representado esquematicamente pela Figura 1; e

a Figura 6 representa, de forma detalhada, o processo de transferência representado esquematicamente pela Figura 2.

10

MODOS DE CONDUÇÃO DA INVENÇÃO

Na presente invenção, considera-se que o usuário possui um módulo de segurança SC e um módulo de pagamento PP. O módulo de segurança pode permitir ao usuário, por exemplo, 15 ter acesso a certos eventos. O módulo de pagamento destina-se, por exemplo, a acesso a eventos aos quais o módulo de segurança não dá acesso. O módulo de pagamento pode conter, por exemplo, uma quantidade que o usuário pode utilizar livremente para acesso a qualquer evento até o limite do valor armazenado. O módulo pode também conter brindes ou direitos para um evento ou uma série de eventos específicos ou por um dado período.

20

Em princípio, o módulo de pagamento não se destina a operar isoladamente, mas necessita da presença do módulo de segurança para funcionar. Além disso, prevê-se que o módulo de pagamento é inicializado e não opera sem esta inicialização. Esta etapa de inicialização opera da seguinte forma:

25

Segundo uma primeira realização da presente invenção, o(a) usuário(a) possui um módulo de segurança SC que lhe fornece direito de acesso a certos eventos. Ele(a) também possui um módulo de pagamento que possui as funções indicadas acima. Nesta realização, o módulo de pagamento é ativado quando introduzido em um leitor da unidade multimídia. 30 Para conduzir esta etapa de ativação, um centro de administração envia regularmente mensagens de administração EMM.

O centro de administração envia uma mensagem de autorização EMM que fornece a instrução de criação de uma chave de liberação. Esta chave de liberação é formada a partir de pelo menos um número aleatório e um valor monetário, um brinde e/ou um direito. 0 conjunto é criptografado por uma chave de grupo Kg que pode ser comum para todas as unidades multimídia relacionadas ou a uma parte delas.

Após o recebimento da chave de liberação, ela é decifrada por meio da chave de grupo e o número aleatório é extraído. A unidade multimídia verifica se esse número aleatório já foi ou não utilizado. Caso tenha sido utilizada, a chave de liberação é rejeitada. Caso contrário, o valor, o brinde e/ou o direito é extraído em vista da sua utilização segundo o processo conforme a presente invenção.

10

Segundo uma variante, a ativação do cartão pré-pago é realizada conforme segue: o usuário telefona para o centro de administração e fornece dados de identificação. Estes dados são verificados no centro de administração. Caso eles correspondam a um cartão real, o centro de administração prepara uma mensagem de administração EMM, que geralmente é 15 específica para o módulo de pagamento. Esta mensagem de administração contém uma chave de liberação, como na realização anterior. Em princípio, essa chave é criptografada com a chave específica para o módulo de pagamento correspondente, ao contrário da realização anterior, em que é geralmente criptografada com uma chave global.

Os dados de identificação podem ser compreendidos, por exemplo, por um número relativo a um evento, um número de identificação do módulo de pagamento, bem como um código de verificação.

As Figuras 1 a 6 ilustram esquematicamente o processo de transferência conforme a presente invenção, bem como os elementos de condução deste processo de transferência entre um módulo de pagamento PP e um módulo de segurança SC, em que esses dois módulos são conectados a uma unidade de usuário, tal como um decodificador STB.

Como é bem conhecido dos técnicos no assunto, o módulo de segurança SC pode ser 30 essencialmente realizado conforme quatro formas distintas. Uma destas formas é uma placa de microprocessador, um cartão inteligente ou, de forma mais geral, um módulo eletrônico (que assume a forma de chave, crachá etc.). Este tipo de módulo geralmente é removível e conectável ao decodificador. A forma com contatos elétricos é a mais amplamente utilizada, mas não se exclui uma conexão sem contato, tal como do tipo ISO 14443. Uma segunda forma conhecida é a de uma caixa de circuito integrado, colocada geralmente de forma definitiva e irremovível no decodificador. Uma alternativa é composta de um circuito montado sobre uma base ou conector tal como um conector de módulo SIM.

Em uma terceira forma, o módulo de segurança é integrado em uma caixa de circuito integrado que também contém uma outra função, tal como em um módulo de decodificação do decodificador ou no microprocessador do decodificador.

Em uma quarta realização, o módulo de segurança não é realizado na fõrma dê hardware, mas a sua função é implementada somente na forma de software. Considerando que, nos quatro casos, a função é idêntica, embora o nível de segurança seja diferente, podemos falar de um módulo de segurança independentemente da forma em que a sua função é conduzida ou da forma que esse módulo pode assumir.

Nas realizações ilustradas, o módulo de segurança SC é representado na forma de um cartão do tipo cartão inteligente. A unidade do usuário é representada como possuindo dois leitores estruturados para receber o módulo de segurança SC e o módulo de pagamento PP simultaneamente. Estes dois leitores permitem uma comunicação direta entre o módulo de pagamento e o módulo de segurança. Desta forma, os dados transferidos entre esses dois 20 módulos são transferidos sem armazenagem na unidade do usuário.

Caso o módulo de segurança encontre-se em uma forma diferente de um cartão, tal como um circuito integrado, naturalmente é possível utilizar uma unidade de usuário que possua apenas um leitor de cartões, que é então utilizado pelo módulo de pagamento PP.

25

Caso o módulo de segurança encontre-se na forma de um cartão, também é possível utilizar uma unidade multimídia que possui apenas um leitor. Neste caso, os dados a serem transmitidos de um módulo para o outro são armazenados em primeiro lugar na unidade de usuário, em que o módulo que iniciou a comunicação é removido em seguida do leitor para 30 deixar lugar para o outro módulo. Isso retira os dados solicitados da memória da unidade de usuário.

A Figura 1 representa os elementos que permitem a realização de duas realizações do processo conforme a presente invenção. Na primeira realização descrita, presume-se que o usuário deseje adquirir um crédito e que esses créditos podem ser adquiridos em grupos de dez unidades cada. O processo conforme a presente invenção opera da seguinte forma. O(a) usuário(a) indica qual crédito ele(a) deseja adquirir por meio de um dispositivo de entrada tal como um controle remoto, um teclado alfanumérico ou qualquer dispositivo apropriado.

Esta solicitação de crédito é transmitida para o decodificador STB. O decodificador STB gera um número aleatório compreendido entre dois valores que agem como limites, em que esses limites definem a quantidade de crédito necessária. Um número aleatório compreendido, por exemplo, entre Oel corresponde a uma solicitação de crédito de dez unidades, um número aleatório compreendido entre 1 e 2 corresponde a um crédito de vinte 10 unidades e assim por diante, até um crédito máximo autorizado de, por exemplo, cem unidades por transação.

Este número aleatório é transmitido para o módulo de segurança SC. E formada uma mensagem de controle a partir de um código que representa a transação, nomeadamente 15 neste exemplo, a partir de um código correspondente ao valor e de um identificador do módulo de segurança que solicita essa transação. Esta mensagem de controle é transmitida para o módulo de pagamento PP. Esta transmissão pode ser realizada em forma decodificada ou criptografada. Antes de validar-se a transação, verifica-se se o módulo de pagamento está autorizado a conduzir essa transação. Com este propósito, ao solicitar-se um crédito, 20 geralmente verifica-se se o saldo no módulo de pagamento é maior ou igual ao valor solicitado. Neste caso, o crédito solicitado é debitado do módulo de pagamento PP e o novo valor é armazenado no módulo de pagamento. Ao conduzir-se essa operação, é formada uma mensagem de recibo, em que essa mensagem contém pelo menos um valor que permite a determinação do montante de crédito solicitado e o identificador do módulo de pagamento 25 PP. O módulo de pagamento transfere essa mensagem de recibo para um centro de administração CG de forma criptografada, por meio de uma chave específica para esse módulo de pagamento. Esta mensagem é decifrada pelo centro de administração CG. Esta última determina em seguida, conforme o identificador do módulo de pagamento, qual módulo de segurança SC é associado a ele. Isso também permite a determinação da chave ou 30 do par de chaves a ser utilizado para criptografar a mensagem no centro de administração e para permitir a sua decifração no nível de módulo de segurança. Segundo uma alternativa, o recibo pode conter um identificador do módulo de segurança que solicitou a transação. O centro de administração gera em seguida um código de liberação criptografado com essa chave. Este código de liberação criptografado é enviado para o decodificador de STB relacionado e transmitido em seguida para o módulo de segurança SC, onde é decifrado. O código de liberação pode conter apenas uma informação de autorização para o crédito solicitado ou pode também incluir o valor do crédito ou um identificador do módulo de segurança correspondente.

5

A Figura 1 também exibe uma segunda realização do processo conforme a presente invenção, em que esta segunda realização também é explicada em detalhes com referência à Figura 5. Nesta realização, supõe-se que o usuário deseje obter o direito de visualizar um evento específico tal como um filme. Hste evento é ligado a um identificador, indicado como 10 Dl. Particularmente, o identificador pode ser disponível, por exemplo, em um guia de programação eletrônico EPG ou em um suporte de papel.

Em primeiro lugar, o(a) usuário(a) digita o identificador IDl do evento que ele(a) deseja adquirir ou o seleciona a partir de um guia de programação eletrônico (EPG). Com este 15 propósito, ele(a) utiliza, por exemplo, um teclado alfanumérico ou um controle remoto que funciona com uma unidade de usuário. Pode-se utilizar qualquer outro dispositivo de entrada similar. Ele(a) garante que o módulo de segurança SC esteja bem conectado á unidade de usuário. Fica claro que, dependendo do tipo de módulo de segurança, este não pode ser removido da unidade de usuário. Ele é, portanto, conectado permanentemente.

20

A unidade de usuário gera em seguida uma solicitação RQ na forma de uma mensagem de controle, tal como quando o usuário pressiona uma tecla de confirmação de comando, em que essa mensagem contém pelo menos o valor MONTANTE correspondente àquele evento ou um derivado daquele valor. Esta mensagem pode também conter opcionalmente o 25 identificador IDl do evento solicitado. Segundo uma realização preferida, a mensagem de controle também contém um identificador IDsc do módulo de segurança SC que emitiu a solicitação ou um número de identificação.

A mensagem de controle é criptografada por meio de uma chave Kl conhecida do módulo 30 de segurança. Esta mensagem criptografada é transmitida para o módulo de pagamento PP. Este módulo de pagamento também possui a chave Kl ou, no caso de um par de chaves assimétricas, a chave correspondente, também indicada como Kl para fins de simplificação. Também é possível adicionar um código de verificação, de forma a evitar problemas devido a eventuais erros de transmissão. A mensagem de controle é decifrada em seguida pelo módulo de pagamento PP por meio da chave correspondente. O valor MONTANTE é extraído da mensagem decifrada. O módulo de pagamento PP verifica que o valor contido na mensagem é menor ou igual ao saldo armazenado no módulo de pagamento. Em caso contrário, o valor não é debitado e uma mensagem de erro é enviada de volta para o centro de administração.

Por outro lado, caso o saldo seja suficiente, o valor MONTANTE é debitado do saldo, possivelmente após outras verificações, tais como as verificações relativas a controle parental ou a outros direitos relativos ao evento ou ao módulo de segurança. O novo saldo é armazenado no módulo de pagamento PP.

Ao conduzir-se esta operação de débito, é gerado um recibo. Este recibo pode apresentar-se na forma de um código de liberação CD criptografado por meio de uma chave K2 que é 15 conhecida do módulo de pagamento PP e do centro de administração CG. O recibo também contém uma informação que permite a identificação do módulo de segurança que emitiu a solicitação ou a mensagem de controle. Esta informação normalmente é o identificador IDsc do mencionado módulo de segurança. O recibo é autenticado de forma a evitar a possibilidade de transmissão de um recibo fraudulento para o módulo de segurança e 20 fornecimento injustificado de um crédito.

O recibo é enviado para o centro de administração CG, onde é decifrado. Desta forma, o centro de administração processa a mensagem de recebimento para determinar qual módulo de segurança SC emitiu a solicitação e obter o código de liberação.

25

Como o centro de administração conhece o emissor da mensagem de controle, ele pode determinar qual chave utilizar para criptografar uma mensagem destinada àquele módulo. Desta forma, ele criptografa o código de liberação com o auxílio de uma chave K3 do módulo de segurança SC correspondente e envia esse código de liberação criptografado para 30 aquele módulo. Este último pode, portanto, decodificá-lo e extrair o código de liberação CD dali. Este último é utilizado em seguida para permitir o acesso ao conteúdo necessário, em que este acesso é possivelmente realizado de diversas formas. Uma forma possível é que o código de liberação seja uma chave que permite o acesso às mensagens de controle ECM ou às mensagens de administração EMM. Nesta realização, o módulo de segurança SC e o módulo de pagamento PP podem compartilhar uma informação secreta comum, que é a chave Kl no caso atual. É perfeitamente possível permitir que diversos ou todos os módulos de pagamento de um certo 5 lote compartilhem a mesma chave Kl. De fato, mesmo se a solicitação codificada for enviada para um módulo de pagamento diferente daquele a que se destina, o fato de que o identificador é integrado à solicitação garante que o código de liberação será transmitido para o módulo de segurança correto.

Também é possível detectar automaticamente o módulo de segurança que emitiu a solicitação, sem que o usuário necessite introduzir o identificador.

O código de liberação somente é enviado após o débito do valor do módulo de pagamento, de forma a evitar o uso da mesma mensagem de recibo várias vezes sem a execução do débito correspondente.

Na descrição acima, indicou-se que o módulo de segurança necessita de um evento específico ou um grupo de eventos, indicados por um identificador IDl contido na mensagem de controle. Também é possível, por exemplo, não solicitar um evento 20 específico, mas sim um valor. Este valor poderá ser utilizado em seguida pelo módulo de segurança para ter acesso a qualquer evento. Neste caso, o módulo de pagamento funciona como uma carteira eletrônica. Esta situação não altera o princípio do processo, pois é suficiente enviar apenas o valor solicitado MONTANTE e não um identificador de evento.

As Figuras 2 e 6 ilustram uma alternativa do processo conforme a presente invenção, por meio do qual o módulo de segurança envia uma solicitação para o centro de administração. No exemplo selecionado, a solicitação não é realizada para um evento específico, mas para um certo valor. Esta solicitação contém, portanto, um valor MONTANTE e uma indicação IDsc que permite a identificação do módulo de segurança que realiza essa solicitação. Em 30 uma variação da presente invenção, a presente solicitação também contém uma chave de sessão SK, cuja utilidade será explicada abaixo. Todos estes elementos podem ser criptografados por meio de uma chave K4 conhecida do centro de administração CG. A mensagem é enviada para o centro de administração desta forma. Ele decifra a mensagem, se necessário, por meio da chave K4 e a criptografa novamente por meio de uma chave K5, conhecida do módulo de pagamento associado ao módulo de segurança que emitiu a solicitação. A mensagem criptografada desta forma é enviada para o módulo de pagamento, que a decifra utilizando a chave K5. Esta decifração permite a 5 obtenção de informações relativas ao evento solicitado e seu custo em particular, o que permite a condução de uma verificação e o débito do montante necessário caso o saldo armazenado no módulo de pagamento seja suficiente. A decifração também permite a recepção da chave de sessão emitida pelo módulo de segurança. Esta chave é utilizada para criptografar o código de liberação CD e enviá-lo para o módulo de segurança. Naturalmente, 10 este último possui a chave de sessão, que permite a decifração do código de liberação e acesso ao conteúdo solicitado.

Em uma alternativa em que a mensagem de controle ou a solicitação é endereçada a um evento específico ou um grupo de eventos, é possível transmitir o valor relativo ao evento 15 desejado na mencionada mensagem. Também é possível não transmitir o valor nesta solicitação, mas permitir que o centro de administração associe o evento ao valor. Isso pode ser particularmente interessante quando o valor para um mesmo evento variar dependendo dos direitos que são específicos do módulo de segurança que emite a mensagem de controle.

Segundo uma outra alternativa, é possível utilizar uma chave comum no módulo de segurança e no módulo de pagamento em vez da chave de sessão. O uso de uma chave de sessão apresenta, entretanto, a vantagem de que o módulo de segurança e o módulo de pagamento não necessitam compartilhar informações secretas comuns para poder comunicar-se.

25

A chave de sessão é utilizada para apenas uma comunicação e é excluída em seguida. Isso evita riscos relativos ao uso abusivo das chaves.

Na realização da Figura 3, a comunicação do módulo de segurança SC para o módulo de 30 pagamento PP tem lugar de forma similar à descrita com referência às Figuras 2 e 5. A mensagem de controle é enviada para o centro de administração CG e esta solicitação é eventualmente criptografada por meio de uma chave conhecida do mencionado centro de administração. Em princípio, entretanto, a mensagem transmitida para esse centro de administração não contém uma chave de sessão. A mensagem é decifrada pelo centro de administração e novamente criptografada por este último por meio de uma chave que é conhecida do módulo de pagamento PP. Ela é enviada em seguida para o mencionado módulo de pagamento.

O módulo de pagamento criptografa a mensagem recebida, verifica se o saldo é suficiente e, se necessário, debita o montante.

O código de liberação não é transmitido diretamente pelo módulo de pagamento para o módulo de segurança SC. Este código de liberação CD é enviado em primeiro lugar pelo 10 módulo de pagamento PP para o centro de administração CG, em que o mencionado código é criptografado. O código é decifrado em seguida no centro de administração e novamente criptografado antes da transmissão para o módulo de segurança SC. O código é decifrado em seguida para que possa ser utilizado para acesso ao conteúdo solicitado.

Esta realização possui a vantagem de que é possível transmitir dados entre o módulo de segurança e o módulo de pagamento sem a necessidade de compartilhar informações secretas. Todas as comunicações entre o módulo de segurança SC e o módulo de pagamento PP transitam por meio do centro de administração CG.

Na realização ilustrada na Figura 4, o módulo de segurança SC não inicia a comunicação. Esta última é iniciada pelo módulo de pagamento PP. Isso pode ser realizado particularmente, mas não apenas, quando um crédito for transferido do módulo de pagamento para o módulo de segurança.

Nesta realização, um código de liberação CD que contém o crédito MONTANTE para 25 transferência bem como um identificador IDsc do módulo de segurança ao qual esse crédito necessita ser transferido é gerado pelo módulo de pagamento. Este código de liberação é criptografado por uma chave conhecida do centro de administração e a mensagem criptografada é enviada para este centro de administração. Ele a decifra e extrai o identificador IDsc do módulo de segurança correspondente. Em seguida, ele criptografa 30 novamente o código de liberação CD por meio de uma chave específica do módulo de segurança e envia novamente esse código criptografado. O módulo de segurança o decifra e pode utilizar em seguida o código de liberação para creditar o montante solicitado.

Esta realização não é ideal com relação à segurança porque não há nenhuma comunicação entre o módulo de segurança e o módulo de pagamento, mas poderá ser utilizada em aplicações em que a segurança não é primordial.

Nas diferentes realizações descritas, considera-se que existe comunicação direta entre o 5 módulo de segurança e o módulo de pagamento, a unidade multimídia possui dois leitores ou o módulo de segurança é integrado na unidade multimídia. Na prática, caso os módulos de segurança e de pagamento possuam a forma de cartões com chip e a unidade multimídia possua apenas um leitor de cartão, é possível armazenar o conteúdo das mensagens em uma memória de unidade multimídia, colocar o módulo solicitado no leitor e transferir o 10 conteúdo da memória para o módulo que é inserido no leitor naquele momento.

Claims

1. Processo de condução de transações entre um módulo de pagamento e um módulo de segurança conectados a uma unidade de usuário, em que o processo é caracterizado pelo fato de que compreende as etapas a seguir: • introdução de um identificador que representa a transação a ser conduzida por meio de um dispositivo de entrada; · geração pela unidade de usuário de uma mensagem de controle que contém pelo menos um código representativo da mencionada transação e um identificador do módulo de segurança que exige a transação; • envio da mencionada mensagem de controle para o mencionado módulo de pagamento (PP); verificação no mencionado módulo de pagamento se ele está autorizado a conduzir a transação desejada; · caso o módulo de pagamento esteja autorizado a conduzir essa transação, execução da transação, armazenagem do resultado da transação no mencionado módulo de pagamento e geração pelo módulo de pagamento de um recibo relativo à transação desejada e ao módulo de segurança relacionado; · envio do mencionado recibo para um centro de administração; • envio de um código de liberação para o módulo de segurança (SC) pelo centro de administração; e · registro da transação no mencionado módulo de segurança.

2. Processo de condução de transações entre um módulo de pagamento e um módulo de segurança conectados a uma unidade de usuário, em que o processo é caracterizado pelo fato de que compreende as etapas a seguir: • introdução de um identificador que representa a transação a ser conduzida por meio de um dispositivo de entrada; • geração pela unidade de usuário de uma mensagem de controle que contém pelo menos um código representativo da mencionada transação e um identificador do módulo de segurança que exige a transação; • envio da mencionada mensagem de controle para um centro de administração (CG); • envio da mencionada mensagem de controle para o módulo de pagamento (PP); • verificação no mencionado módulo de pagamento se ele está autorizado a conduzir a transação desejada; • caso o módulo de pagamento esteja autorizado a conduzir essa transação, execução da transação e transmissão de um código de liberação (CD) relativo à transação desejada para o módulo de segurança correspondente; e • registro da transação no mencionado módulo de segurança.

3. Processo de condução de transações entre um módulo de pagamento e um módulo de segurança conectados a uma unidade de usuário, em que o processo é caracterizado pelo fato de que compreende as etapas a seguir: • introdução de um identificador que representa a transação a ser conduzida por meio de um dispositivo de entrada; • geração pela unidade de usuário de uma mensagem de controle que contém pelo menos um código representativo da mencionada transação e um identificador do módulo de segurança que exige a transação; • envio da mencionada mensagem de controle para um centro de administração (CG); • envio da mencionada mensagem de controle para o módulo de pagamento (PP); • verificação no mencionado módulo de pagamento se ele está autorizado a conduzir a transação desejada; • caso o módulo de pagamento esteja autorizado a conduzir essa transação, execução da transação e transmissão de um recibo relativo à transação desejada para o centro de administração (CG); • elaboração de um código de liberação e envio do código de liberação pelo centro de administração para o módulo de segurança (SC); e • registro da transação no mencionado módulo de segurança.

4. Processo de condução de transações entre um módulo de pagamento e um módulo de segurança conectados a uma unidade de usuário, em que o processo é caracterizado pelo fato de que compreende as etapas a seguir: • introdução de um identificador que representa a transação a ser conduzida e um identificador do módulo de segurança que exige a transação por meio de um dispositivo de entrada; • geração de uma mensagem de controle que contém pelo menos um código representativo da mencionada transação pelo módulo de pagamento (PP); • verificação no mencionado módulo de pagamento (PP) se ele está autorizado a conduzir a transação desejada; • caso o módulo de pagamento esteja autorizado a conduzir essa transação, execução da transação, armazenagem do resultado da transação no mencionado módulo de pagamento e geração pelo módulo de pagamento (PP) de um recibo relativo à transação desejada e para o módulo de segurança (SC) relacionado; • envio do mencionado recibo para um centro de administração (CG); elaboração de um código de liberação (CD); • envio do mencionado código de liberação (CD) para o módulo de segurança (SC); e • registro da transação no mencionado módulo de segurança.

5. Processo de acordo com a reivindicação 1, caracterizado pelo fato de que a mensagem de controle é armazenada na unidade do usuário antes de ser enviada para o módulo de pagamento (PP).

6. Processo de acordo com a reivindicação 1, caracterizado pelo fato de que a criptografia do recibo é realizada por meio de uma chave que o centro de administração (CG) é capaz de determinar.

7. Processo de acordo com qualquer das reivindicações 1, 3 ou 4, caracterizado pelo fato de que o recibo é enviado criptografado para o centro de administração (CG).

8. Processo de acordo com qualquer das reivindicações 1, 3 ou 4, caracterizado pelo fato de que o código de liberação (CD) é formado a partir do mencionado recibo.

9. Processo de acordo com qualquer das reivindicações 1, 2, 3 ou 4, caracterizado pelo fato de que a transação refere-se a pelo menos um dos elementos selecionados a partir de um direito de acesso a evento, direito de acesso a dados ou crédito.

10. Processo de acordo com a reivindicação 2, caracterizado pelo fato de que a mensagem de controle é enviada criptografada para o centro de administração (CG).

11. Processo de acordo com qualquer das reivindicações 2 ou 3, caracterizado pelo fato de que a mensagem de controle é decifrada pelo centro de administração (CG).

12. Processo de acordo com qualquer das reivindicações 2 ou 3, caracterizado pelo fato de que o código de liberação é armazenado na unidade de usuário.

13. Processo de acordo com a reivindicação 4, caracterizado pelo fato de que o código de liberação (CD) é enviado criptografado para o módulo de segurança (SC).