BRPI0622235A2

BRPI0622235A2 - sistema e processo de transaÇço

Info

Publication number: BRPI0622235A2
Application number: BRPI0622235-8A
Authority: BR
Inventors: David Ramsdale; Robert Dennett; Gino Dompietro
Original assignee: Coca Cola Co; Transurban Ltd
Priority date: 2006-12-19
Filing date: 2006-12-19
Publication date: 2012-01-03
Also published as: EP2095310A4; AU2006352095A1; WO2008074051A1; US20100312618A1; AU2006352095B2; JP2010514014A; MX2009006571A; CN101617330A; EP2095310A1

Abstract

SISTEMA E PROCESSO DE TRANSAÇçO. Um sistema de transação incluindo: um sistema de entrada para ler o primeiro dado de identificação de um primeiro dispositivo e segundo dado de identificação de um segundo dispositivo e um sistema de base de dados para acessar dados da conta de pagamento de uma conta de transação com base nos primeiro e segundo dados de identificação e solicitar dados de autorização para uma transação de pagamento usando os dados da conta de pagamento. O sistema de entrada executa um processo de autorização em resposta aos dados de autorização que estão sendo recebidos. O sistema de base de dados armazena um registro de autorização com um tempo de autorização em resposta aos dados de autorização que estão sendo recebidos. Um sistema de pagamento pode ser usado para ler o segundo dado de identificação do segundo dispositivo e gerar dados de pagamento que representam uma quantia de pagamento. O sistema de base de dados determina, então, autorização para uma transação de pagamento com base no segundo dado de identificação e no registro de autorização e, em resposta, submete os dados de pagamento e os dados da conta de pagamento a um sistema de processamento de pagamento para executar a transação de pagamento.

Description

"SISTEMA E PROCESSO DE TRANSAÇÃO"

Campo

A presente invenção refere-se a um sistema de transação e aos processos executados pelo sistema. O sistema é para uso na autorização de uma transação sem uso de moeda.

Fundamentos

Muitos sistemas diferentes de transação sem uso de moeda têm sido desenvolvidos ou propostos com apenas um número limitado sendo executado e usado com sucesso. Os sistemas normalmente precisam satisfazer numerosos critérios concorrentes para as várias partes associadas a transações monetárias. Os critérios, exigências e definições técnicas precisam ser solucionados para permitir que o sistema seja conveniente e fácil de usar pelos consumidores- e, também, satisfazer questões de segurança e privacidade dos consumidores, comerciantes, emitentes de conta, e adquirentes da transação.

Por exemplo, foi proposto um sistema de transação sem uso de moeda que usa um dispositivo de identificação de radiofreqüência (RFID) portado por um consumidor, ou montado no veículo de um consumidor. O RFID é lido pelo sistema para prover dados de identificação usados para identificar uma conta de pagamento previamente estabelecida. O RFID é associado diretamente à conta de pagamento a partir da qual o pagamento é feito diretamente para bens ou serviços. Uma vez verificadas a conta de pagamento e a RFID associada, o pagamento pode ser feito no momento da compra pelo consumidor provendo dados de identificação adicionais associados à RFID, como a entrada de um PIN, ou escaneamento de um código de barras provido pelo consumidor. Entretanto, o sistema não determina se a conta de pagamento tem fundos suficientes até que um pagamento seja solicitado e a verificação prévia é apenas executada com base nos primeiros dados de identificação mantidos pela RFID. O sistema também precisa incluir infra-estrutura para manusear pagamentos de conta e prover facilidades para assegurar que todos os fundos suficientes estejam disponíveis, tal como, possibilitando que fundos sejam adicionados a uma conta de pagamento de débito. A facilidade de utilização para o consumidor também é comprometida se o consumidor precisar lembrar um segundo dado de identificação, como um PIN. Todavia, sem a correlação de duas formas de dados de identificação, a segurança do sistema é comprometida.

Conseqüentemente, é desejado prover uma solução técnica para solucionar o acima, ou prover pelo menos uma alternativa utilizável.

Sumário

De acordo com a presente invenção é provido um sistema de transação, incluindo:

um sistema de entrada para ler o primeiro dado de identificação a partir de um primeiro dispositivo e um segundo dado de identificação a partir de um segundo dispositivo; e

um sistema de base de dados para acessar os dados da conta de pagamento de uma conta de transação com base nos mencionados primeiro e segundo dados de identificação e solicitar dados de autorização para uma transação de pagamento usando os mencionados dados da conta de pagamento;

o mencionado sistema de entrada executando um processo de autorização em resposta aos mencionados dados de autorização recebidos.

Preferivelmente, o mencionado sistema de base de dados armazena um registro de autorização, com o tempo de autorização, em resposta aos mencionados dados de autorização que estão sendo recebidos.

Preferivelmente o sistema inclui adicionalmente um sistema de pagamento para ler o mencionado segundo dado de identificação do mencionado segundo dispositivo e gerar dados de pagamento representando uma quantia de pagamento; o mencionado sistema de base de dados determinando autorização para uma transação de pagamento com base no mencionado dado de identificação e mencionado registro de autorização e, em resposta, submetendo os mencionados dados de pagamento e os mencionados dados da conta de pagamento a um sistema de processamento de pagamento para executar a mencionada transação de pagamento.

A presente invenção também provê um processo de transação incluindo:

ler o primeiro dado de identificação de um primeiro dispositivo e o segundo dado de identificação de um segundo dispositivo, acessar uma conta de transação com base nos mencionados primeiro e no segundo dados de identificação;

solicitar dados de autorização para uma transação de pagamento usando dados da conta de pagamento da mencionada conta de transação;

armazenar um registro de autorização com um tempo de autorização em resposta aos mencionados dados de autorização que estão sendo recebidos.

Preferivelmente o processo inclui adicionalmente validar os mencionados primeiro e segundo dispositivos usando os mencionados primeiro e segundo dados de identificação.

Vantajosamente, o processo da transação pode incluir adicionalmente:

ler o mencionado segundo dado de identificação do mencionado segundo dispositivo e gerar dados de pagamento representando uma quantia de pagamento;

determinar autorização para uma transação de pagamento com base no mencionado segundo dado de identificação e o mencionado registro de autorização, e

submeter os mencionados dados de pagamento e mencionados dados da conta de pagamento a um sistema de processamento de pagamento para executar a mencionada transação de pagamento.

A presente invenção também provê um processo de transação incluindo:

ler e validar uma primeira RFED;

ler e validar uma segunda RFED;

acessar os dados da conta de pagamento associados com a mencionada primeira RFID e a mencionada segunda RFID; e

submeter uma transação de autorização com os mencionados dados da conta de pagamento a um sistema de processamento de pagamento para obter dado de autorização representando aprovação para uso subseqüente da mencionada segunda RFID, dentro de um período de tempo predeterminado, para autorizar um pagamento.

Descrição resumida dos desenhos

Modos de realização preferidos da presente invenção são descritos a seguir, apenas como exemplo, com referência aos desenhos de acompanhamento, onde:

A Figura 1 é um diagrama de bloco de um modo de realização preferido de um sistema de transação;

A Figura 2 é um diagrama esquemático de um sistema de entrada do sistema de transação;

A Figura 3 é um diagrama de bloco do servidor central e componentes locais do sistema de transação;

A Figura 4 é um fluxograma de um processo de estabelecimento de conta de transação executado pela rede e servidores de base de dados do sistema de transação;

A Figura 5 é um fluxograma de um processo de entrada executado por um controlador de entrada do sistema de transação; e

A Figura 6 é um processo de pagamento executado por um controlador de pagamento do sistema de transação. Descrição de modos de realização preferidos

Um sistema de transação, como mostrado nas Figuras 1 e 3, é usado para facilitar transações sem uso de moeda executando processos de dupla autorização usando dados de identificação de dois dispositivos de identificação de radiofreqüência (RFIDs). O sistema de transação inclui um sistema local 102 e um sistema de escritório central, ou de suporte 104, capaz de se comunicar com numerosos sistemas locais 102 usando uma rede de dados 130 de banda larga (por exemplo usando os protocolos da Internet sobre uma rede DSL). O sistema local 102 está localizado em um local que ofereça produtos, por exemplo, bens ou serviços, para compra por consumidores. Por exemplo, o local pode ser um supermercado, shoppingcenter, estacionamento de carro, restaurante, etc.

O sistema central 104 inclui um servidor de rede 120, servidor de base de dados 110, e um servidor de mensagem. 130. O servidor de mensagem 130, como mostrado na Figura 3, inclui um subsistema 302 de email, um subsistema de SMS 304 e um gerador de relatório 306.

O servidor de base de dados 110 inclui um servidor de computador, como aquele produzido por Lenovo Group Ltd, ou Apple Computer Inc., executando software de computador de servidor de base de dados, como MySQL, em um sistema operacional, como Windows Server ou Linux. O servidor de base de dados 110 mantém dados da conta de transação, descrita abaixo, para usuários do sistema em uma base de dados central 112. O servidor de base de dados 110 também inclui um controlador de comunicações 310 para manusear a recepção, transmissão, e processamento dos dados de controle entre outros componentes do sistema de transação. O controlador de comunicações 310 inclui um módulo de comunicações e componentes de interfaces de comunicações padrão, como um modem DSL. O módulo pode ser escrito em código de programa de computador, como C++ ou Java, ou implementado por circuitos de hardware dedicados, por exemplo, ASICs e FPGAs. O servidor de base de dados 110 é capaz de se comunicar com um sistema de processamento de pagamento (PPS) 140 e um sistema de pedágio 142. O PPS 140 pode ser mantido por uma ou mais instituições financeiras e inclui sistemas de transferência eletrônica de fundos para executar transações de cartão de crédito ou débito. Por exemplo, o PPS 140 pode incluir um transferidor eletrônico de fundos existente no ponto de venda da rede (EFTPOS). O sistema de pedágio 142 inclui um servidor de base de dados para manter dados da conta de pedágio para usuários do sistema de pedágio 142, que pode ser um sistema de pedágio de tráfego, como aquele produzido por Kapsch TrafficCam Ab of Sweden. O servidor de base de dados de pedágio 142 é capaz de acessar os dados da conta de pedágio de um usuário, que inclua dados associados com uma primeira RFID 230 usada pelo sistema de transação, como descrito abaixo.

O servidor de rede 120 inclui um computador de servidor, como aquele produzido por Lenovo Group Ltd., ou Apple Computer Inc., executando código de servidor de rede, como Apache, e Java Server Pages (JSP) e Java Servlets em um sistema operacional, como Windows Server ou Linux. O servidor de rede 120 suporta um site da web 320, como descrito abaixo, e possibilita o estabelecimento e manutenção remotos de contas de transação mantidas pelo servidor de base de dados 110. O site da web do servidor de rede 120 pode ser acessado via Internet 125 por um computador cliente 132 de um usuário (por exemplo, consumidor), ou um computador cliente 134 de um administrador.

O subsistema de email 302 inclui um servidor de SMTP para enviar mensagens de email para sistemas de clientes 132 e 134 com base nas mensagens de instrução recebidas do servidor de base de dados 110 ou gerador de relatório 306. O gerador de relatório 306 é capaz de gerar relatórios como solicitado ou em uma base regular usando dados acessados da base de dados 112. Os relatórios podem, então, ser acoplados às mensagens geradas e enviadas pelo subsistema de email 302. Os relatórios podem ser solicitados por um administrador 134 acessando o site da web 320. Por meio de instruções do servidor de base de dados 110, o subsistema de SMS 304 também pode gerar mensagens de SMS a ser emitidas por um ponto de conexão de SMS 127 para um telefone celular móvel 136 de um usuário.

O servidor de rede 120 e o servidor de mensagem 130 suportam serviços de comunicações, como descrito abaixo, para os sistemas ou dispositivos, 132, 134 e 136 de administradores e usuários do sistema de transação.

Um sistema local 102 inclui um ou mais sistemas de controle de entrada 106, como mostrado nas Figuras 1, 2 e 3, e um ou mais sistemas de pagamento 108, como mostrado na Figura 3. Para um local tendo múltiplas entrada e sistemas de pagamento, os componentes de processamento de dados dos sistemas podem ser combinados.

Um sistema de entrada 106, como mostrado nas Figuras 1, 2 e 3, inclui um sistema de computador local 202, um primeiro leitor de RFID 204 e um controlador de porta de lança 206, ambos conectados ao sistema de computador local 202 por meio de cartões de interface de comunicação de entrada/saída digital 208 para o primeiro leitor 204 e o controlador de porta. 206. O controlador de porta de lança 206 inclui uma tela de cristal líquido 210, um segundo leitor de RFID 212, uma porta de lança para veículo 214 e relês de presença de veículo (VPRs) 216 para detectar a presença de um veículo 220. O veículo 220 inclui um primeiro dispositivo de RFID 230, aqui referido como um "eTag", e um segundo dispositivo de RFID 240, aqui referido como um "iTag".

O eTag 230 transmite o primeiro dado de identificação ao leitor 204, quando dentro do alcance e questionado pelo leitor 204. Os dados de identificação representam um número exclusivo para o eTag. O eTag 230 está associado ao veículo 220 e a uma conta de pedágio mantida para um usuário pelo sistema de pedágio 142. O eTag 230 pode ser usado para identificar o veículo e a conta para o sistema de pedágio quando o veículo for conduzido em uma estrada de pedágio, tal como a rede CityLink of Transurban Limited. Por exemplo, o eTag 230 pode ser um dispositivo de link de microonda PREMID produzido por Kapsch TrafficCom Ab. O eTag 230 seria montado normalmente dentro e permaneceria associado ao veículo 220.

O segundo tag de RFED 240 é um transponder passivo de curto alcance. O transponder transmite, usando uma alta freqüência, o segundo dado de identificação ao leitor de iTag 212, quando colocado próximo ao leitor 212. O segundo dado de identificação é único para o iTag 240 e está associado com uma conta de transação para o uso do iTag 240. O iTag 240 pode ter o tamanho de uma moeda pequena, ou disco, e pode ser convenientemente distribuído e acoplado a uma carteira, telefone celular ou chaveiro. O leitor de iTag 212 é um dispositivo capaz de ler dados de identificação exclusivos de RFIDs compatíveis com MIFARE operando dentro da faixa de HF (13,56MHz), como aqueles produzidos por HID Corporation, Texas Instruments e Phillips.

O sistema de transação está disponível para ser utilizado por titulares correntes de eTags 230 e contas de pedágio. Para usar o sistema, um usuário precisa coletar um iTag 240 distribuído de graça em um ponto de distribuição de distribuição, como uma loja de varejo e, a seguir, acessar o sistema central 104 para estabelecer uma conta de transação associada com o iTag. O site da web 320, do servidor de rede 120, pode ser acessado por um sistema cliente de usuário 132 e usado para executar um processo de estabelecimento de conta de transação, como mostrado na Figura 4. O site 320, primeiro envia uma página de login (etapa 402) solicitando entrada pelo cliente 132 do número da conta para a conta de pedágio e um número de identificação pessoal associado (PIN). O número da conta de pedágio e o PIN submetidos são passados para o servidor de base de dados 110 para recuperar dados da conta de pedágio para a conta de pedágio (identificada pelo número) do sistema de pedágio 142. Baseado nos dados retornados, o site da web 320 determina se o número e o PIN entrados representam uma associação e combinação válidas da conta de pedágio (etapa 404). Para uma combinação inválida, o site 320 envia novamente a página de login (etapa 402). Para uma combinação válida, o dado da conta de pedágio acessada retornado é usado para enviar uma exibição dos detalhes da conta de pedágio para verificação pelo usuário (406). Os dados da conta de pedágio representam os números do eTags associados com a conta, os números do registro do veículo e veículos associados com os eTags, e dados pessoais, como o nome e endereço do proprietário da conta. Junto com os detalhes retornados da conta de pedágio, é provido um link HTTP para acessar os termos e condições associados com o uso do sistema de transação e manutenção de uma conta de transação. Um link HTTP também é provido para aceitar os termos e condições, e o processo somente prossegue uma vez ativado o link de aceitação para retornar a resposta associada ao servidor de rede 120 (etapa 408). Ao receber a resposta de aceitação, o servidor de rede 120 registra a aceitação com sua cópia dos dados da conta de pedágio e retorna uma página dinâmica com campos para a entrada de dados para a nova conta de transação. Os dados incluem:

(i) Um campo para um número de identificação do iTag 240 que está impresso no material distribuído com o iTag, ou impresso no próprio iTag. A base de dados 112 mantida pelo servidor de base de dados 110 inclui tabelas que associam os números de iTags impressos em cada iTag distribuído com os dados de identificação transmitidos por aquele iTag. Os dados de identificação representam um número de identificação exclusivo para o transponder que pode ser diferente ou o mesmo daquele impresso no iTag.

(ii) Uma combinação de nome de usuário e senha exclusiva para a conta de transação. (iii) Dados pessoais representando nome, endereço e detalhes de contato para o usuário da conta de transação. Isto inclui um endereço de email e um número de telefone móvel que podem ser usados, subseqüentemente, pelo servidor de mensagem 130.

(iv) Dados da conta de pagamento. Isto inclui campos que representam e definem uma conta de pagamento que pode ser usada pelo PPS para completar um pagamento por bens ou serviços. Para contas de cartão de crédito, isto inclui um campo para o nome do possuidor do cartão, número do cartão, tipo de cartão e data de expiração do cartão.

Uma vez os dados acima submetidos ao servidor de rede 120 com sucesso, os dados da conta de pedágio e os dados submetidos são enviados ao servidor de base de dados 110 com uma solicitação para criar e estabelecer uma conta de transação (410). Os dados da conta de transação são armazenados em tabelas com campos para os dados da conta de pedágio, os dados submetidos e os respectivos dados de identificação exclusivos para o iTag identificado e um ou mais eTags associados com a conta de pedágio. Um email de ativação da conta de transação é, então, enviado ao endereço de email submetido pelo usuário usando o subsistema de email 302(412). O email de ativação é enviado com um URL exclusivo codificado com um identificador para a nova conta de transação. O email pede que o receptor selecione o URL a fim de ativar a conta de transação. O servidor de rede 320 recebe uma solicitação de HTTP com o URL codificado (414), e este evento é passado ao servidor de base de dados 110, de modo a colocar um campo na base de dados 112 para ativar a conta de transação (416). Isto assegura que a conta de transação seja estabelecida em associação com um endereço de email válido para o usuário. O processo de estabelecimento termina (418) se os termos e condições não forem aceitos, os dados solicitados não forem recebidos, ou o URL codificado não for retornado.

Embora a conta de pedágio esteja associada com a conta de transação, a maneira pela qual as duas são estabelecidas e operadas assegura que sejam efetivamente duas contas diferentes, uma usada para um sistema de pedágio 142, e outra para autorizar uma transação de pagamento para produtos e serviços, como descrito abaixo. A associação provê um fator de autenticação duplo para os processos de autorização da transação. O processo de estabelecimento da conta de transação permite distribuição prévia e grátis dos iTags e, a seguir, a associação subseqüente com uma conta de pedágio. Uma conta de pedágio pode ter uma ou mais contas de transação associadas com ela, bem como, um ou mais eTags associados com ela. Apenas um iTag é associado com cada conta de transação, mas a mesma conta de pagamento (por exemplo, cartão de crédito) pode ser associada a uma ou mais contas de transação.

O sistema de entrada 106 executa um processo de entrada, como mostrado na Figura 5, e o sistema de pagamento 108 executa um processo de pagamento, como mostrado na Figura 6. Ambos submetem campos selecionados dos dados da conta de transação ao PPS 140, para obter autorização, ou aprovação, mas nenhum transfere fundos para o pagamento. O pagamento é executado e manuseado pelo PPS 140 usando uma conta de pagamento. O sistema de transação não mantém o balanço de uma conta de pagamento. Conseqüentemente, além do fator de autenticação duplo do usuário, a autorização da transação é executada, efetivamente, duas vezes pelo sistema de transação.

O processo de entrada, como mostrado na Figura 5, começa, na etapa 502, determinando se um veículo 220, um eTag 230 e um iTag 240, foram detectados. O leitor de iTag 212 lê o dado de identificação do iTag 240 e este é passado e detectado por um controlador de leitor 330 do sistema de computador local 202. Uma vez o iTag detectado, o dado de identificação lido é passado a um controlador de entrada 334 do sistema de entrada 106 com um evento de detecção. O controlador de entrada 334 recebe um evento de detecção similar de um controlador de leitor de eTag 332 que se comunica com o leitor de eTag 204. Quando um veículo se aproxima uma porta de lança de entrada 204, sua presença é detectada por um relê de presença de veículo (VPR) 216 na estrada. Este evento de detecção de VPR é passado ao controlador de entrada 334 do sistema de computador local 202 pelo controlador de porta 206. Uma vez o evento de detecção do veículo, o evento de detecção de iTag e o evento de detecção de eTag recebidos dentro de um tempo predeterminado, um em relação ao outro, o controlador de entrada 334 prossegue para executar as etapas subseqüentes do processo de entrada.

O controlador de entrada 334 e o controlador de leitor 332 incluem módulos escritos em código de programa de computador, como C++, ou Java, ou são implementados usando circuitos de hardware dedicados. Os controladores 332, 334 e o controlador de porta 206 incluem componentes de sistemas de entrada produzidos por Ski Data AG, Amano Cincinnati, Inc., ou

Data Park, Inc.

O controlador de entrada 334 armazena o primeiro dado de identificação lido do eTag e o segundo dado de identificação do iTag (504). O dado de identificação para o eTag é passado ao servidor de base de dados 110 com uma solicitação para determinar se o eTag é válido e se alguma conta da transação está associada ao eTag (506). O servidor de base de dados 110 se comunica com o sistema de pedágio 142 para determinar se o eTag ainda é valido e não está listado em uma lista negra de eTags barrados. Se o eTag é relatado como válido, o servidor de base de dados recupera os dados da conta de transação de quaisquer contas de transação associadas com o eTag 230 e retorna os dados da conta de transação ao controlador de entrada 334 (510). Se o eTag for inválido, uma mensagem de negação (508) é enviada ao LCD 210 para exibição para o usuário do iTag. A mensagem avisa que o iTag não pode ser usado para facilitar o pagamento.

Ao obter dados para as contas de transação associadas, o controlador de entrada 334 usa os dados para determinar se o iTag lido é atualmente válido (etapa 512). Isto envolve determinar se o segundo dado de identificação está associado com uma das contas de transação recuperada para o eTag, e se o iTag, ou a conta de transação identificada, pertencem a uma lista negra. Se o iTag for determinado como inválido, então a mensagem da negação (508) é exibida, se não, o dado da conta de pagamento da conta de transação identificada é usado para submeter uma transação de autorização ao PPS 140. A transação de autorização é uma transação-teste para obter dados de autorização para o pagamento de uma quantia predeterminada, digamos, R$100, usando a conta de pagamento da conta de transação. Se o PPS 140 retorna os dados de autorização significando que a transação foi aprovada e que pode prosseguir, isto valida efetivamente uma conta de pagamento como sendo boa para fazer um pagamento por um período de tempo predeterminado. A autorização bem sucedida é relatada ao controlador de comunicações 310 e transmitida ao controlador de entrada 334 em uma mensagem de sucesso (etapa 516). Se a mensagem de sucesso não for recebida dentro de um tempo predeterminado, ou relatado que a conta de pagamento para a quantia predeterminada não foi aprovada, a mensagem de negação (508) é enviada para exibição sobre o LCD 210. Se a mensagem de sucesso for recebida, o controlador de entrada 334, e o servidor de base de dados 110 armazenam um registro de autorização associado com a conta de transação. O registro de autorização inclui dados que representam a transação de autorização e, em particular, a hora em que uma mensagem de aprovação foi recebida do PPS 140. O registro da hora da autorização é a hora da autorização. Ao armazenar o registro de autorização (etapa 518), o controlador da entrada 334 executa um processo de sucesso (520). O processo de sucesso envolve:

(i) Enviar uma mensagem de sucesso para exibição sobre o LCD 210. Esta mensagem de sucesso avisa ao usuário que o iTag 240 pode ser usado para atender ao pagamento no local, para bens ou serviços, incluindo pagamento do estacionamento no local.

(ii) Enviar uma mensagem aberta ao controlador de porta 206, que faz com que o controlador de porta abra a porta de lança 214 para permitir que o veículo 220 entre em uma área de estacionamento dentro do local.

O usuário é capaz de usar o iTag 240 para atender ao pagamento de quaisquer bens e serviços dentro do local colocando, primeiro, o iTag dentro da proximidade de um leitor de iTag 340 conectado a um sistema de pagamento 108 do local. O sistema de pagamento 108 é um sistema de computador local que constitui um terminal de pagamento e inclui um controlador de leitura 342 para o leitor 340 e um controlador de pagamento 344. O controlador de pagamento 344 inclui um módulo escrito em código de programa de computador, como C++, ou, Java, ou implementado usando circuitos de hardware dedicados e também pode incluir componentes de caixas registradoras existentes, ou terminais de Pontos de Venda. O controlador de leitura 342 e o leitor de iTag 340 são os mesmos que aqueles usados pelo sistema de entrada 106. Logo que o controlador de leitura 342 detecta um iTag e lê o dado de identificação do iTag, um evento da detecção com o dado é passado ao controlador de pagamento 334 (602), como mostrado na Figura 6. Em resposta, o controlador de pagamento 334 se comunica com o servidor de base de dados 110 para obter o registro de autorização armazenado para a conta de transação associada com o iTag (604). O controlador de pagamento 344. processa o registro de autorização obtido para determinar (606) se (i) ele é válido para o local e a localização do leitor 340, e (ii) se o evento de detecção ocorreu dentro de um tempo predeterminado a partir do momento da autorização. Se o processamento determinar que os dados satisfazem aos critérios (i) e (ii), então, uma mensagem é enviada e exibida sobre um LCD 346 do sistema de pagamento 102 solicitando que os dados de pagamento sejam introduzidos. Se não, uma mensagem da negação é enviada e exibida (608).

Para certas localizações do leitor de tag 340, o controlador de pagamento 344 é capaz de gerar, ele próprio, os dados de pagamento. Por exemplo, se o leitor de Tag 340 estiver localizado dentro de um controlador de porta de saída e o veículo 220 estiver tentando deixar o local, então, o controlador de pagamento 344 pode determinar, baseado no tempo decorrido, a quantia que precisa ser paga pelo estacionamento e gera dados de pagamento para esta quantia. O tempo decorrido é a diferença entre tempo de autorização e o momento do evento de detecção do iTag no controlador de pagamento 344. Ao receber a aprovação do pagamento o controlador da saída pode enviar uma mensagem aberta para abrir uma porta de saída para o veículo. Em outras circunstâncias, por exemplo, em um ponto de varejo, uma pessoa pode precisar entrar com a quantia e quaisquer outros detalhes necessários, usando um dispositivo de entrada de dados 350, como um teclado do terminal de pagamento. O sistema de pagamento 108 também pode ser incorporado dentro uma caixa registradora, ou de pagamento de um ponto de venda provendo os bens ou serviços. Os dados de pagamento, além de representarem a quantia, também podem representar outra informação, como a descrição dos bens ou serviços. Logo que o controlador de pagamento 344 tenha obtido os dados de pagamento, o controlador de pagamento 344 submete uma solicitação de transação ao PPS 140 (612). A solicitação de transação inclui os dados do pagamento e da conta de transação que são necessários, como os dados que representam a quantia do pagamento e a conta de pagamento da conta de transação. O pedido de transação inclui os dados necessários para o PPS 140 atender a uma transferência de fundos, ou pagamento, para os bens ou serviços associados aos dados de pagamento, usando a conta de pagamento. O sucesso, ou a falha, da transação processada pelo PPS 140 são retornados como dados da aprovação ao servidor de base de dados 110 e, por sua vez, ao controlador de pagamento 344. Uma mensagem de sucesso é enviada ao controlador de pagamento 344 se a transação de pagamento for aprovada pelo PPS 140. Se a mensagem de sucesso não for recebida dentro do tempo predeterminado (614), uma mensagem da negação (608) é enviada para exibição sobre o LCD 346. Se a mensagem de sucesso é recebida, o controlador de pagamento 344 executa um processo de sucesso (616). O processo de sucesso envolve exibir uma mensagem de pagamento bem sucedido sobre o LCD 346 e imprime um recibo para o pagamento usando uma impressora 348. O sistema de pagamento 108 pode apenas imprimir o recibo se solicitado, ou por default.

O sistema de transação permite que os usuários façam um pagamento para bens ou serviços em um local, sem que documentos precisem ser assinados, ou dinheiro manuseado. Nem cartões de crédito precisam ser apresentados. Tudo que é exigido é que um usuário estacione no local com um veículo que possua um eTag válido, e uma vez o iTag autorizado na entrada, ele pode usar o iTag em vários terminais de pagamento para atender ao pagamento. A segurança do sistema de transação, apesar da conveniência de uso, é realçada pelo fator de autenticação duplo de que é provido usando o eTag e o iTag, e o sistema executar um processo de autorização duas vezes para autorizar uma transação de pagamento.

Muitas modificações serão aparentes àqueles peritos na técnica sem fugir do escopo da presente invenção como aqui descrita com referência aos desenhos de acompanhamento.

Claims

1. Sistema de transação, caracterizado pelo fato de incluir: um sistema da entrada para ler o primeiro dado de identificação de um primeiro dispositivo e um segundo dado de identificação de um segundo dispositivo; e um sistema de base de dados para acessar dados da conta de pagamento de uma conta de transação com base nos mencionados primeiro e segundo dados de identificação, e solicitar dados de autorização para uma transação de pagamento usando dados da mencionada conta de pagamento; o mencionado sistema de entrada executando um processo de autorização em resposta aos mencionados dados de autorização que estão sendo recebidos.

2. Sistema de transação de acordo com a reivindicação 1, caracterizado pelo fato do mencionado sistema de base de dados armazenar um registro de autorização com um tempo de autorização, em resposta aos mencionados dados de autorização que estão sendo recebidos.

3. Sistema de transação de acordo com a reivindicação 1, caracterizado pelo fato do mencionado sistema de base de dados validar o mencionado primeiro dispositivo ao receber o mencionado primeiro dado de identificação e acessar contas de transação associadas ao mencionado primeiro dado de identificação.

4. Sistema de transação de acordo com a reivindicação 3, caracterizado pelo fato do mencionado sistema de base de dados validar o mencionado segundo dispositivo ao receber o mencionado segundo dado de identificação e determinar a conta de transação associada ao mencionado segundo dado de identificação.

5. Sistema de transação de acordo com a reivindicação 1, caracterizado pelo fato do mencionado processo de autorização incluir aviso de autorização de uso do mencionado segundo dispositivo para atender a um pagamento.

6. Sistema de transação de acordo com a reivindicação 5, caracterizado pelo fato do processo de autorização incluir gerar uma mensagem para permitir a entrada em um local.

7. Sistema de transação de acordo com a reivindicação 2, caracterizado pelo fato de incluir um sistema de pagamento para ler o mencionado segundo dado de identificação do mencionado segundo dispositivo e gerar dados de pagamento representando uma quantia de pagamento; o mencionado sistema de base de dados determinar uma autorização para uma transação de pagamento baseada no mencionado segundo dado de identificação e mencionado registro de autorização e, em resposta, submeter os mencionados dados de pagamento e mencionados dados da conta de pagamento a um sistema de processamento de pagamento para executar a mencionada transação de pagamento.

8. Sistema de transação de acordo qualquer uma das reivindicações precedentes, caracterizado pelo fato dos mencionados primeiro e segundo dispositivos serem dispositivos de RFID.

9. Sistema de transação de acordo com a reivindicação 8, caracterizado pelo fato do mencionado primeiro dispositivo estar associado com uma conta de pedágio de um sistema de pedágio e localizado em um veículo.

10. Processo de transação, caracterizado pelo fato de incluir: ler o primeiro dado de identificação de um primeiro dispositivo e um segundo dado de identificação de um segundo dispositivo; acessar uma conta de transação com base nos mencionados primeiro e segundo dados de identificação; solicitar dados de autorização para uma transação de pagamento usando dados da conta de pagamento da mencionada conta de transação; e armazenar um registro de autorização com um tempo de autorização em resposta aos mencionados dados de autorização que estão sendo recebidos.

11. Processo de transação de acordo com a reivindicação 10, caracterizado pelo fato de incluir validar os mencionados primeiro e segundo dispositivos usando os mencionados primeiro e segundo dados de identificação.

12. Processo de transação de acordo com a reivindicação 11, caracterizado pelo fato da mencionada validação incluir comparar os mencionados dados de identificação com os dados de uma lista negra para dispositivos inválidos.

13. Processo de transação de acordo com a reivindicação 10, caracterizado pelo fato de incluir acessar contas de transação associadas ao mencionado primeiro dado de identificação e determinar a conta de transação das mencionadas contas de transação que estão associadas com o mencionado segundo dado de identificação.

14. Processo de transação de acordo com a reivindicação 10, caracterizado pelo fato de incluir aviso de autorização de uso do mencionado segundo dispositivo para atender a um pagamento, em resposta ao recebimento dos mencionados dados da autorização.

15. Processo de transação de acordo com a reivindicação 10, caracterizado pelo fato de incluir gerar uma mensagem para permitir que um usuário do segundo dispositivo entre em um local, em resposta ao recebimento dos mencionados dados de autorização.

16. Processo de transação de acordo com a reivindicação 10 ou -11, caracterizado pelo fato de incluir: ler o mencionado segundo dado de identificação do mencionado segundo dispositivo e gerar dados de pagamento, representando uma quantia de pagamento; determinar autorização para uma transação de pagamento com base no mencionado segundo dado de identificação e no mencionado registro de autorização, e submeter os mencionados dados de pagamento e mencionados dados da conta de pagamento a um sistema de processamento de pagamento para executar a mencionada transação de pagamento.

17. Processo de transação de acordo com qualquer uma das reivindicações 10 a 16, caracterizado pelo fato dos mencionados primeiro e segundo dispositivos serem dispositivos de RFID.

18. Processo de transação de acordo com a reivindicação 17, caracterizado pelo fato do mencionado primeiro dispositivo estar associado com a conta de pedágio de um sistema de pedágio e localizado em um veículo.

19. Processo de transação de acordo com a reivindicação 18, caracterizado pelo fato da mencionada validação incluir acessar a mencionada conta de pedágio com base no mencionado primeiro dado de identificação.

20. Processo de transação de acordo com qualquer uma das reivindicações 17 a 19, caracterizado pelo fato do mencionado segundo dispositivo ser um dispositivo de RFID passivo de curto alcance, e o mencionado primeiro dispositivo ser um dispositivo de RFID ativo com um alcance de aproximadamente 1 OOm.

21. Processo de transação, caracterizado pelo fato de incluir: ler e validar uma primeira RFID; ler e validar uma segunda RFID; acessar dados da conta de pagamento associada com a mencionada primeira RFID e a mencionada segunda RFID; e submeter uma transação da autorização com os mencionados dados da conta de pagamento a um sistema de processamento de pagamento para obter dados de autorização representando aprovação para uso subseqüente da mencionada segunda RFID, dentro de um período de tempo predeterminado para autorizar um pagamento.

22. Processo de transação de acordo com a reivindicação 13, caracterizado pelo fato de incluir gerar uma mensagem para permitir a entrada em um local em resposta aos mencionados dados de autorização.

23. Processo de transação de acordo com a reivindicação 13, caracterizado pelo fato de incluir: ler a mencionada segunda RFID em um terminal de pagamento; acessar o mencionado registro de autorização com base no mencionado segundo dado de identificação; determinar se uma transação de pagamento foi autorizada com base no mencionado registro de autorização; e submeter a mencionada transação de pagamento com os dados de pagamento representando uma quantia de pagamento para um sistema de processamento de pagamento.