PT780801E - Método e dispositivos para a utilização e compensação de meios de pagamento electrónicos num sistema aberto e inter-operável para a cobrança automática de taxas. - Google Patents

Description

ΕΡ Ο 780 801 /ΡΤ

DESCRIÇÃO "Método e dispositivos para a utilização e compensação de meios de pagamento electrónicos num sistema aberto e inter-operável para a cobrança automática de taxas" O invento refere-se a um método e a dispositivos para a utilização e compensação de meios de pagamento electrónicos num sistema aberto e inter-operável para a cobrança automática de taxas. Em especial o invento refere-se a tais métodos e dispositivos, nos quais a utilização de meios de pagamento electrónicos se efectua sem contacto através de um dispositivo autónomo por parte do utilizador. Métodos de pagamento por via bancária têm uma importância cada vez maior nas operações comerciais, também e, em particular, para o consumidor final. Especialmente a introdução iminente de porta-moedas electrónicos e a sua influência prevista nos hábitos de pagamento do consumidor final bem como o constante aumento do número de possuidores de cartões de crédito e débito são também uma prova disto como também o aumento rápido de terminais para estes cartões no sector do comércio a retalho e de prestação de serviços.

De acordo com isto cresce o interesse para e a necessidade para possibilidades de pagamento por via bancária também no âmbito da cobrança de taxas para a entrada e utilização de instalações, tais como edifícios, estradas, pontes, de sistemas de transporte e meios de deslocação etc. Já no âmbito nacional e, em particular, no âmbito internacional o desenvolvimento está sujeito à condição real de correspondentes instalações de pagamento por via bancária, para que as pessoas em questão como pagadores das taxas estejam guarnecidas para uma pluralidade de diferentes sistemas de pagamento com diversas técnicas. Um sistema aceitável de cobranças de taxas deve poder cooperar com o maior número possível destes sistemas de pagamento, sendo portanto aberto e inter-operável. O invento refere-se a estes sistemas abertos e inter-operáveis para a realização automática de transacções de pagamentos, em particular, de cobranças de taxas. Em especial 2 ΕΡ Ο 780 801 /ΡΤ ο invento refere-se a um método para a realização automática de transacções de pagamento por via bancária, de preferência sem contacto, em particular, para a cobrança de taxas e semelhantes, entre um fornecedor ou prestador de serviços e um utilizador destes serviços respectivamente destas prestações, e o qual paga com um meio de pagamento por via bancária, em particular, electrónico. Um exemplo é a cobrança automática de taxas, devidas à utilização de estradas, silos de estacionamento e outros serviços de valor acrescentado relacionados com estes, por parte de viaturas. A nível político está a ser discutida a introdução de uma cobrança automática de taxas referente ao trajecto em auto-estradas. Esta deverá ser efectuada por via bancária sob salvaguarda da protecção de dados e da segurança do tráfego. No exemplo desta cobrança automática de taxas serão representadas a seguir as condições prévias e as exigências ao método de acordo com o invento. O sistema de pagamento por cobrança automática de taxas deve basear-se de preferência em cartões de microprocessador universais, utilizáveis de vários modos e internacionalmente normalizados ou também em Smartcards, os quais também são designados por ICC (integrated Circuit Cards) ou simplesmente por cartão inteligente (Chipcard). Um ICC pode ser provido de diferentes aplicações como por exemplo títulos de transporte, dados de identificação (passaporte), porta-moedas electrónico, funções de pagamentos (cartões de débito e crédito) etc. O sistema de pagamento a ser elaborado para a cobrança automática de taxas e outros fins de utilização como este, pode ser um sistema de pagamento universal ou especificamente para transportes com as variantes de um pagamento posterior ou antecipado. O sistema de pagamento pode ser utilizável de forma regional (por exemplo cartões de cliente) como também supra-regional (por exemplo porta-moedas nacional ou internacional, cartão de crédito).

Geralmente o ICC é uma unidade de um sistema geral complexo, o qual compreende o produtor do IC (somente a pastilha) e do ICC, emissores de cartões e aplicações, 3 ΕΡ Ο 780 801 /ΡΤ fornecedores de serviços, empresas de compensação (clearing) e processamento, agentes de carregamento (Load Agents) e mais outros componentes/instituições. A principal exigência que deverá ser cumprida pelo sistema e pelas interfaces definidas para este fim é a liberdade de opção do utilizador para as aplicações a serem carregadas nos cartões inteligentes e o meio de pagamento a ser aplicado para o pagamento de serviços e prestações (neste caso: serviços de cobrança automática de taxas).

Para salvaguardar a protecção de dados, para a protecção contra tentativas de manipulação dos créditos e débitos e para comprovar a recusa do serviço e a falta de pagamento são necessários apurados requisitos de segurança de índole técnica, legal e organizadora para todos os componentes/instituições participantes neste sistema.

Na prática o sistema deve permitir uma realização segura, no entanto rápida, de cada processo de pagamento. Métodos e dispositivos conhecidos para os sistemas "point-of-point-sale", por exemplo para o pagamento com um cartão de pagamento, nos quais o cartão é introduzido num leitor, sendo ali lido e após de concluída a transacção dever novamente ser retirado, já são excluídos devido ao seu desperdício de tempo. Com maior razão é de prescindir das consultas de controlo em linha habituais, sem que possam resultar problemas de segurança.

Os requisitos essenciais impostos ao sistema, neste caso o sistema de cobrança automática de taxas, são a seguir descritos em dois grupos, isto é, aqueles que resultam dos aspectos da protecção de dados e aqueles que resultam de outros aspectos funcionais.

Requisitos principais resultantes da protecção de dados A protecção de dados assume uma importância essencial no desenvolvimento e na implementação de um sistema para a cobrança automática de taxas. 4 ΕΡ Ο 780 801 /ΡΤ

No seguinte serão explicados em pormenor os requisitos principais da protecção de dados, relacionados com o sistema de pagamento e o conceito de segurança. 1. O anonimato

Sob o anonimato entende-se que os dados relacionados com a pessoa são memorizados somente no utilizador. Também o pagamento anónimo e a liquidação devem neste caso ser devidamente considerados. A comparação dos dados pessoais com arquivos centrais deve ser impedida. Em caso de coacções só quando a suspeita for fundamentada os dados pessoais podem ser revelados. 2. Sigilo

Sigilo significa que os dados relacionados com a pessoa devem ser protegidos contra tomada de conhecimento não autorizada. O acesso aos dados pessoais só deve ser realizado por entidades autorizadas (com o auxilio do respectivo código). O sistema também deve estar protegido contra o acesso de terceiros piratas ("Hacker"). 3. Integridade A integridade tem como conteúdo que o utilizador não possa ser debitado indevidamente e que os assinantes do sistema podem confiar que todos os dados são geridos sem erros e processados, memorizados e transmitidos de forma correcta e regular. Também a detecção e o impedimento de tentativas de manipulação devem estar integrados na protecção da integridade. 4. Transparência A reprodutibilidade e a capacidade de controlo do método para o responsável e para o utilizador são o critério decisivo para a aceitação do sistema. Compreende-se neste âmbito, em particular, a indicação e a prova de débitos, alterações, defeitos funcionais e contas esgotadas bem como percepção de medidas coercivas. Além disso o utilizador deve, 5 ΕΡ Ο 780 801 /ΡΤ estar informado sobre as informações que estão com ele memorizadas de forma descentralizada. 5. Resistência à retirada

Sob resistência à retirada da protecção de dados deve entender-se que o sistema contém um fundamento da protecção de dados, o qual não permite nenhuma possibilidade incontrolada de alteração por parte da entidade prestadora de serviços ou de terceiros.

Outros requisitos principais: 1. inter-operacionalidade O sistema implantado deve ser inter-operável. A inter-operacionalidade descreve neste caso a capacidade de um sistema de cobrança automática de taxas poder actuar de forma efectiva em conjunto com outros sistemas na proximidade da cobrança de pagamentos de utilização para o utilizador e a entidade prestadora de serviços. A inter-operacionalidade refere-se, no exemplo da cobrança automática de taxas a prestações de serviço da utilização de estradas e a serviços de valor acrescentado sobre sistemas de pagamento (diferentes emitentes), a técnicas de transmissão (micro-ondas, infravermelhos, rádio celular, etc.) e à aplicação pan-europeia. O sistema geral deve estar concebido para qualquer número de fornecedores de cobrança automática de taxas e emitentes de meios de pagamento, e em que deve ser possivel uma coordenação organizadora de diferentes funções do sistema. 2. Rentabilidade dos custos

Além disso o sistema deve ser de custos reduzidos, isto é a utilização de infra-estruturas existentes, interfaces externas iguais dos componentes do sistema para todos os sistemas de pagamento. 3.

Fiabilidade 6 ΕΡ Ο 780 801 /ΡΤ Ο sistema deve corresponder aos requisitos gerais de um sistema, neste caso um sistema de cobrança automática de taxas, quanto à sua fiabilidade de funcionamento (funções defeituosas não devem ser debitadas ao utilizador). 4. Serviços de valor acrescentado A integração de serviços de valor acrescentado (transportes públicos urbanos, gestão do tráfego etc.) conforme a opção do utilizador deve ser prevista ou através da aceitação do sistema de pagamento ou através de aplicações especiais. 5. Circulação de tráfego segura e sem interferências É evidente que o sistema de cobrança automática de taxas também deve obedecer aos requisitos técnicos do tráfego, isto é, deve ser garantida uma cobrança fiável de taxas em todas as situações do tráfego e sob quaisquer condições do meio ambiente.

Destes requisitos resultam directamente requisitos especiais aos componentes do sistema de cobrança automática de taxas como segue:

Requisitos contra uso indevido 1. Protecção contra manipulação

Manipulações deliberadas (sabotagem, fraude) e involuntárias (defeitos funcionais) devem ser detectadas e evitadas tanto quanto possivel. Para a protecção de manipulações involuntárias podem ser adoptadas diversas medidas técnicas, tais como: a) Utilização de equipamento autorizado e certificado, b) Simplicidade e robustez do equipamento e dos sistemas, 7 ΕΡ Ο 780 801 /ΡΤ c) Protecção dos dados por meio de codificação com caracteristicas de detecção de erros e sua reparação, d) Controlo das instalações centrais e nas estradas contra falhas e defeitos, e) Fornecimento de um centro de assistência e venda com elevada capacidade.

Uma protecção contra manipulações deliberadas pode, em contrapartida, com as mencionadas medidas ser atingida somente de forma insatisfatória. Para este efeito devem em vez disso ser aplicados códigos criptográficos, os guais devem ser utilizados dentro da comunicação entre os assinantes do sistema. 2. A cobrança e Enforcement devem guanto à organização ser separados entre si. 3. A separação de tarefas entre a aplicação, a realização do pagamento, a gestão da conta e a realização da comunicação deve ser fixada de forma sistemática, de preferência também de forma legal.

Requisitos ao sistema de pagamento 1. Abertura do sistema de pagamento O sistema de pagamento deve estar aberto em relação ao meio de pagamento a ser utilizado, isto é além de meios de pagamento específicos para transportes também deve ser possivel a aplicação de meios de pagamento universais por via bancária. 2. Sistema de pagamento

Como método base está à disposição o pagamento antecipado com um cartão de crédito anónimo, alternativamente o pagamento posterior. A possibilidade de opção deve ser do utilizador, não devendo nenhum dos métodos ser prejudicado (taxas de emolumentos, preços dos terminais, etc.). 8 ΕΡ Ο 780 801 /ΡΤ 3. Liberdade de opção do utilizador O utilizador decide quanto ao modo de pagamento (pagamento antecipado, ou pagamento posterior, universal ou especifico para transportes), isto é, ele deve ter conhecimento quais os sistemas de pagamento autorizados. 4. Equipamento diferente do utilizador

Habitualmente o utilizador estará provido de um dispositivo de pagamento (OBE; On-Board Equipment), o qual leva com a sua viatura, podendo ser equipado de forma técnica e funcional diferente. Assim por exemplo a aplicação para o processamento, memorização e transmissão de dados de cobrança automática de taxas (OBU, On-Board-Unit respectivamente transponder) pode em principio estar separada do meio de pagamento (por exemplo cartão inteligente), ou o meio de pagamento pode estar memorizado numa memória do dispositivo de pagamento por exemplo como um número fixo de débito ou como um contador de unidade de valor. 5. Garantia de pagamento

Pagamento posterior: O emitente do meio de pagamento posterior deve proporcionar ao prestador de serviços uma garantia de pagamento fiável; pagamento antecipado: A garantia de pagamento efectua-se através do sistema, isto é, as condições técnicas bem como os decursos organizativos devem assegurar o pagamento da importância pedida. 6. Recibo O utilizador deve receber um comprovativo controlável sobre o pagamento efectuado (recibo final) respectivamente o seu consentimento de pagamento (recibo provisório), cuja obrigação de conservação terá de ser restrita. 7. Segurança contra abusos A segurança contra abusos dentro do sistema de pagamento deve estar assegurado. Deve ter-se em conta que: 9 ΕΡ Ο 780 801 /ΡΤ a) Ο sistema reconheça meios de pagamento não autorizados, b) Sejam admitidos somente meios de pagamento autorizados e carregamentos autorizados, c) O sistema permitir a possibilidade de bloquear cartões individuais e/ou grupos de cartões, d) O sistema esteja seguro contra débitos não autorizados, e e) O sistema esteja protegido contra simulações de pagamento, por exemplo por meio de nova introdução de pagamento já utilizados e contra a leitura de dados confidenciais por pessoas não autorizadas. 8. Segurança de verificação A segurança de verificação deve ser garantida para todos os modos de pagamento. Isto significa que todos os créditos são reproduzíveis e a evidência do local, da data e de intervenientes dos processos de pagamento seja salvaguardada. 9. Transacção A transacção entre os parceiros participantes deve efectuar-se com rapidez. Isto significa uma contabilização próxima do tempo real no meio de pagamento (por exemplo um cartão inteligente) no pagamento prévio e uma data do valor a curto prazo em todos os sistemas a favor da câmara de compensação. 10. Liberdade de efeito retroactivo O anonimato não deve afectar de forma negativa a fiabilidade, a segurança de verificação e a garantia de pagamento. 11. Facilidade de utilização 10 ΕΡ Ο 780 801 /ΡΤ Ο sistema deve ser de acesso fácil, isto é os cartões inteligentes devem ser reutilizáveis e as contas devem ser claras.

Requisitos à arquitectura de segurança 1. Capacidade de separação do âmbito de segurança

Em principio resulta uma arquitectura de segurança caracterizada por dois domínios de segurança separáveis: A transacção de cobrança automática de taxas e o sistema de segurança. A função de pagamento, tendo em consideração os meios de pagamento antecipados e posteriores universais e específicos para transportes, devem estes ser separáveis, quanto à técnica de segurança, da aplicação da cobrança automática de taxas. Devido à arquitectura pretende-se atingir que tanto o prestador de serviços possa emitir e aceitar e determinar deste modo o seu próprio meio de pagamento, como também é permitida a aplicação de meios de pagamento universais de emitentes independentes com estruturas de segurança superiores. 2. Arquitectura de segurança da transacção de cobrança automática de taxas. As interfaces de comunicação devem estar protegidas tecnicamente e quanto à organização bem como adaptadas ao sistema de pagamento utilizado. Também faz parte que todos os componentes do sistema estejam integrados num método institucionalizado para autorização, verificação e controlo do sistema. Para a câmara de compensação deve ser verificável se os dados de pagamento provêm de um meio de pagamento autêntico e autorizado. Os protocolos necessários e a gestão das chaves para códigos devem ser normalizados. 3. Arquitectura de segurança dos sistemas de pagamento O emitente administra os valores monetários sob responsabilidade pessoal. As chaves para a segurança da transacção de pagamento encontram-se no emitente respectivamente nas instâncias por ele autorizadas e no meio de pagamento. O sistema de cobrança automática de taxas deve ter condições para encaminhar, de forma transparente, os dados de pagamento inclusive os certificados necessários. 11 ΕΡ Ο 780 801 /ΡΤ 4. Implementação de um organismo de autorização

Implementação de um organismo de autorização competente que é para a salvaguarda da integridade do sistema, a Inter-operacionalidade, a garantia de pagamento e uma colaboração segura. isto condiciona uma institucionalização da autorização, verificação e controlo do sistema pelas unidades de funções participantes, dos componentes aplicados e dos meios de pagamento aplicados; a autorização pode referir-se à aplicação local, nacional ou internacional. Esta tarefa também pode ser assumida por organismos de Clearing nacionais/Internacionais, os quais realizam tanto um Clearing nacional e internacional (evidentemente devem ser possíveis os acordos bilaterais para o intercâmbio de outros dados (Apportionment) ou transacções de pagamento reguladas bilateralmente). 5. Fiabilidade A fiabilidade do sistema deve ser elevada, isto é, todos os componentes centrais devem ser insensível a falhas. Para atingir a fiabilidade exigida também devem ser utilizados métodos criptográficos.

Requisitos ao Enforcement 1. Falhas do sistema a) Utilizadores que pagaram correctamente, não devem ser considerados pagadores falsificadores ou pagadores em falta, b) Utilizadores que pretendiam pagar não devem ser considerados pagadores falsificadores ou pagadores em falta. 2. Acesso do Enforcement O "enforcement" deverá ter somente uma possibilidade de acesso à última transacção. Neste caso por exemplo em que numa transacção a trabalhar com um dispositivo de pagamento por parte do utilizador e um dispositivo de cobrança por 12 ΕΡ Ο 780 801 /ΡΤ parte do fornecedor, são verificados os seguintes factores: Existência de um dispositivo de pagamento (OBE), existência de um dispositivo de cobrança funcional (Road Side Equipment, RSE), Data, local, montante/tarifa do último pagamento, validade do meio de pagamento, classificação da tarifa em relação à classificação do veiculo, eventualmente da utilização efectiva, percurso no momento do pagamento, tempo de percurso quando da passagem, situação do trânsito quando da cobrança, atribuição a grupos. Verificações análogas efectuam-se num método no qual se procede sem dispositivo de cobrança (portagens virtuais) e as funções essenciais do dispositivo de cobrança se encontram integradas num dispositivo de pagamento autónomo. 3. Conteúdo do titulo de transporte O titulo de transporte deverá apresentar o seguinte conteúdo minimo:

Identificação do último posto de pagamento, data e indicação da hora e segundos, importância paga e moeda, número de contagem dos títulos de transporte, características de classificação, certificado do prestador de serviços. 4. Obrigação de conservação A obrigação de conservação dos títulos de transporte deverá restringir-se até à próxima saída.

Requisitos aos meios de pagamento, em particular, sob forma de unidades OBU (On Board Unit) 1. Possibilidades de visualização O dispositivo de pagamento deverá apresentar as seguintes possibilidades de visualização: a) Montante da taxa b) Crédito c) Débito efectuado/não efectuado 13 ΕΡ Ο 780 801 /ΡΤ d) Possibilidade de verificação das funções pelo utilizador (indicação de falha) 2. Visualização respectivamente impressão da apresentação da transacção O dispositivo de pagamento deverá estar em condição, conforme a forma de realização, de visualizar respectivamente imprimir somente para o utilizador a memória das transacções (títulos de transporte, processos de débito e tentativas de débito). 3. Protecção contra manipulações

Para a protecção contra manipulações devem ser tomadas providências de segurança de caracteristicas lógicas, técnicas e físicas para o dispositivo de pagamento. A realização do sistema de acordo com o invento efectua-se sob a validade das normas gerais já existentes, os quais determinam o limite do intercâmbio de dados nestas transacções. São de mencionar, em particular, os seguintes, na maioria não públicos, Working Items (WI) da organização europeia de normalização CEN no Technical Committee 278: WI 1.1.1 Integration of payment systems WI 1.1.2 Interface specification for clearing between operators WI 1.2.1 WI 1.2.3 WI 9.2.1 WI 9.2.2 WI 9.2.3

AFC requirements for DSRC

AFC inteface definition for DSRC DSRC layer 7 DSRC médium and layer 1 DSCR layer 2

Isto ainda é acrescido pelo documento base (requisitos aos sistemas automáticos de cobrança de taxas) do GK 717 ak 1 14 ΕΡ Ο 780 801 /ΡΤ como comité alemão reflectido ao CEN TC 2 78 WG 1 o qual também fixou o modelo alemão de transacção para a interface de ar.

Estas normas definem os componentes do sistema somente de forma restrita ou não, em particular, os conteúdos dos dados e sua utilização.

No estado da técnica foram publicadas diversas propostas para métodos para a transacção de processos de pagamento por via bancária.

No pedido de patente internacional WO 95/10147 da Amtech Corporation é conhecido um sistema para a cobrança de taxas em tempo real para as portagens em auto-estradas e semelhantes. Nesta publicação encontra-se em primeiro lugar uma quase completa despersonalização do processo de pagamento, em que qualquer conclusão referente ao movimento da viatura pretende ser impossível. O sistema opera com dispositivos de pagamento por parte do utilizador, os quais aqui são designados por "in-vehicle units"e que colaboram com dispositivos de cobrança na forma de "roadside collection stations". O pagamento efectua-se em princípio através da transmissão de cheques electrónicos memorizados em OBE (On-Board-Equipment) em "envelopes" selados criptograficamente com os correspondentes "abridores". ("cryptographically sealed envelopes with openers", baseado na tecnologia Chaums de "blind signatures" com codificação assimétrica). O processo de pagamento decorre em três fases e utiliza estruturas especiais de dados para a codificação da importância em dinheiro e determinados dados de autenticação, sendo os dados assim estruturados utilizáveis somente para a comunicação na portagem. Se o cartão inteligente já não apresenta a importância necessária para o pagamento, este deve ser recarregado num computador bancário ou semelhante, o que contudo quanto aos dados se efectua completamente separado dos especialmente estruturados utilizados para o processo de pagamento. Para o caso do utilizador em vez de primeiro recarregar novamente o cartão inteligente num caixa, passar sem pagamento o dispositivo de cobrança, deverá ser possibilitado um pagamento posterior quando dados especiais de identificação da viatura ou do condutor memorizados no 15 ΕΡ Ο 780 801 /ΡΤ dispositivo de pagamento sejam tornados acessíveis ao fornecedor por meio de uma activação especial.

Este sistema assegura em regra, com efeito, que o recurso à prestação de serviço pelo utilizador não possa retroceder a este, o que representa somente um requisito, e de forma nenhuma o mais importante, de um sistema deste género. A abertura do sistema para meios de pagamento, que deverá proporcionar uma identificação do meio de pagamento em relação ao pagamento da prestação de serviço, praticamente conectada a jusante e independente, é um outro requisito extremamente importante, que o sistema fechado como o descrito na WO 95/10147, em princípio necessariamente não poderá cumprir. É conhecido a partir de EP-Al 0 401 192 um sistema de cobrança automática de taxas com a utilização de um porta-moedas electrónico para as portagens de estradas. Também neste caso é descrito um dispositivo de pagamento por parte da viatura, o qual actua em conjunto com um dispositivo de cobrança do prestador de serviços. Como meios de pagamento são mencionadas unidades de valores pré-pagas, cartões de crédito e também cobrança por nota de débito. O processo de pagamento propriamente dito engloba uma comunicação em dois passos sem entrega de recibo e com protecção criptográfica somente para a transmissão de dados. Embora isto não seja descrito em pormenor, aparentemente os dados da transacção cruzados entre o dispositivo de cobrança e o dispositivo de pagamento, estão estruturados especialmente para a transacção na interface entre os dois dispositivos. Uma estrutura de dados que pudesse proporcionar uma continuação do processamento dos dados fácil e sem problemas no circuito total inclusive o emitente, câmara de compensação e semelhantes, não é nem exigida nem descrita nesta publicação prévia. Este tipo de transacção do pagamento não forma de modo algum os costumes usuais de um processo de pagamento em vários passos por meio da informação da operação da prestação de serviço (a), declaração do intuito de compra e de pagamento (b), fixação do preço (c), concretização do pagamento (d) e fornecimento de uma prova de pagamento (e). 16 ΕΡ Ο 780 801 /ΡΤ É também conhecido a partir de EP-A2 0 577 328 (AT&T) um sistema automático de pagamento, em particular, uma portagem electrónica, do tipo já acima mencionado. Este estado da técnica descreve uma comunicação de cinco passos entre o dispositivo de pagamento e o dispositivo de cobrança, em que com um número aleatório periodicamente alterado é aplicado um sistema especial de codificação sob utilização de uma chave individual do cartão inteligente. Não está prevista qualquer declaração sobre a estruturação dos dados da transacção quanto ao seu processamento posterior no adquirente respectivamente no emitente ou semelhante. É conhecido a partir de EP-A2 0 616 302 um sistema electrónico de cobrança para taxas de trânsito, em que se utiliza um dispositivo de pagamento, em particular, com cartões inteligentes de pagamento prévio. Com efeito empregam-se nesta publicação também termos utilizados tais como os que teriam importância num sistema aberto com um qualquer meio de pagamento electrónico, contudo não é explicado como isto se poderia realizar. Também não é referida a estrutura de dados essencialmente concordantes em todos os passos de processamento do circuito de pagamento.

Publicações gerais semelhantes por um lado referente às transacções automáticas de processos de pagamento por via bancária, por outro referente às tecnologias especiais para estes fins, encontram-se em US 5,450,087; US 4,303,904; EP-A2 0 152 198; GB-A 2 278 704; WO 91/18354; WO 93/09621 e EP-A1 0 609 453. A D5 descreve um método e um dispositivo para o verificação de taxas de utilização para vias de trânsito e/ou áreas de circulação, em que com o auxilio de um dispositivo que se encontra na viatura são calculados na base de dados da posição e dados de tarifa as taxas de utilização que são transmitidas através de um sistema de transmissão de dados a um posto central. Neste caso estas taxas de utilização são somadas no dispositivo na viatura até atingirem um montante determinado. Em seguida o dispositivo na viatura estabelece através de uma rede móvel uma ligação a um posto central. Os 17 ΕΡ Ο 780 801 /ΡΤ correspondentes dados de taxas e dados que identificam o porta-moedas devedor, são transmitidos ao posto central. Além disso o registo no dispositivo na viatura é reduzido pela importância debitada. Por outras palavras, a respectiva taxa é em primeiro lugar localmente descontada (interno) num cartão inteligente de uma conta intermediária e então em conjunto com outros dados são transmitidos ao posto central e descontados de uma conta do utilizador.

Todas estas publicações têm em comum que as mesmas não abordam condições prévias essenciais para um sistema aberto e inter-operacional tanto quanto possível pouco dispendioso e que contudo possa operar de forma segura, ou até as excluem com suas medidas concretas. Nenhuma destas objecções descreve um método do género de acordo com o invento no qual, não obstante de uma salvaguarda normalizada de segurança e anonimato, a transacção do processo de pagamento entre o utilizador e o prestador de serviços esteja assim concebido para que as estruturas de dados utilizadas possam ser aplicadas sem dispendiosos processos de transformação ou outros passos de processamento para outros processos de transacção entre fornecedor e adquirente, entre adquirente e emitente por um lado, bem como entre o utilizador e a agência de vendas respectivamente esta e o emitente, como a seguir ainda será explicado em pormenor. O objectivo essencial do invento consiste em preencher também estas lacunas remanescentes na normalização, em particular, na geração, função e utilização uniformizada de dados relevantes para o pagamento, por um lado pela actuação em conjunto com o suporte físico utilizada de acordo com o invento, por outro lado no contexto do sistema de acordo com o invento.

Um outro objectivo essencial do invento é a apresentação de um método e dispositivos do género inicialmente mencionado, que permitam um pagamento automatizado por via bancária, fiável e seguro sob manutenção da protecção de dados, no mais curto prazo possível.

Também é objectivo do invento proporcionar uma cobrança automática de taxas sem prejudicar consideravelmente o fluxo de trânsito e a velocidade da viatura. 18 ΕΡ Ο 780 801 /ΡΤ

Os métodos e dispositivos para a obtenção deste objectivo devem ser concebidos e interagir de tal forma que possam ser utilizados tanto meios de pagamento especiais como também universais, pagamentos prévios e posteriores para o pagamento num sistema de pagamento automático respectivamente cobrança de taxas, enquanto que para a compensação devem ser mantidas tanto quanto possível as vias de pagamento actualmente já praticadas entre fornecedores de serviços e instituições bancárias.

Estes objectivos são atingidos de acordo com o invento através das características das reivindicações independentes.

Formas de concretização favoráveis resultam das respectivas reivindicações dependentes. O sistema do modelo pelo qual se orienta o desenvolvimento dos métodos de acordo com o invento, especialmente do sistema de pagamento automático de taxas a seguir descrito, tem como base o esboço normalizado do CEN TC 278 "Interface Specification for Clearing between Operators". Este modelo representado no diagrama 1 distingue as seguintes cinco componentes: utilizador que por meio da aplicação de um meio de pagamento utiliza uma prestação de serviços, fornecedor de serviços que apresenta uma prestação de serviços ao utilizador, câmara de compensação, que recebe dados de transacções de diferentes fornecedores de serviços e os transmite aos respectivos emitentes de meios de pagamento, emitente que explora um sistema de pagamento, e "collection agent", o qual realiza para um emitente a venda ou o carregamento de meios de pagamento (agência de vendas, loja). 19 ΕΡ Ο 780 801 /ΡΤ 19 ΕΡ Ο 780 801 /ΡΤ

Collcction Câmara de Agent compensação

Utilizador

Diagrama 1: Modelo sistema CEN TC 278 A câmara de compensação no seguinte também é designada por adquirente.

No modelo de sistema representado as setas do circulo interior correspondem ao fluxo dos dados relevantes para o pagamento, as setas do circulo exterior correspondem às relações monetárias e objectivas (compra ou prestação de serviços). A separação funcional decisiva para a concepção do sistema de cobrança automática de taxas entre as aplicações do sistema de pagamento e da cobrança automática de taxas já está preparada neste modelo pela distinção fundamental entre o emitente (do meio de pagamento) e o fornecedor de serviços.

Num outro modelo diferenciado, o qual forma o fundamento propriamente dito para o desenvolvimento do conceito, deve ser considerado que: a utilização de um meio de pagamento num contexto como o ambiente da cobrança automática de taxas só é possível "sem contacto" (sem toque), visto que o intercâmbio de dados relevante para o pagamento se efectua através de uma transmissão via rádio no âmbito de microondas ou de infravermelhos (DSRC -Dedicated Short Range Communication) ou via rádio celular (por exemplo GSM - Global System for Mobile Telecommunication), 20 ΕΡ Ο 780 801 /ΡΤ a separação de dados de movimento dos dados de pagamento exigida por razões de protecção de dados e a restrição de dados pretendida por motivos de custos, os quais são introduzidos na transacção de pagamento, que geralmente por uma correspondente agregação de dados de transacção só são possíveis num posto de concentração do fornecedor de serviços, e os interesses de todos os participantes no sistema também devem ser protegidos por meio de medidas de organização e legais. O invento permite isto com o método reivindicado, de acordo com a reivindicação 1 anexa.

No método definido na reivindicação 1 o modelo acima mencionado é complementado com os componentes meio de pagamento (Payment Means), pelo qual o processo de pagamento pode ser realizado pelo utilizador, dispositivo de pagamento na forma de On-Board-Equipment (OBE), o qual por um lado aceita a opção de pagamento de um utilizador (pagamento por meio de porta-moedas ou pela conta bancária, conforme o meio de pagamento introduzido), por outro lado realiza o pagamento efectivo das cobranças automáticas de taxas por ordem do utilizador e requisição explicita ou implícita do fornecedor de serviços através do transponder (OBU, On-Board-Unit), organismo pagador na forma de um Road-Side-Equipment (RSE) físico, que representa o organismo pagador da cobrança automática de taxas de um fornecedor de serviços (Service Provider) e que cobra ou taxas de viaturas em passagem ou emite títulos de entrada, na forma de um Road-Side-Equipment virtual que, num dispositivo de identificação por parte do 21 ΕΡ Ο 780 801 /ΡΤ utilizador, permite a iniciação autónoma do pagamento e sua realização pelo utilizador; o concentrador de um fornecedor de serviços, que separa os dados de movimentos dos dados de pagamento das transacções de cobranças automáticas de taxas, transmitindo débitos cumulados aos adquirentes, o posto de controlo de cobrança automática de taxas (Enforcement), que pode motivar um dispositivo de pagamento (OBE) a comprovar o último pagamento efectuado, e a instância de autorização (Certification Authority), a qual assegura que sejam aplicados somente aqueles componentes de sistema, que observem todas as obrigações necessárias, como por exemplo a protecção de dados, a segurança IT, a possibilidade de revisão e a justiça dos acordos (relações contratuais). O modelo de sistema é exemplificado em pormenor no diagrama 2.

Num sistema de cobrança automática de taxas inter-operável, supranacional e (referente aos meios de pagamento) aberto, a segurança de todos os participantes do sistema só pode ser salvaguardada por uma combinação de medidas técnicas, de organização e legal, cujo cumprimento seja controlado por uma instância de autorização, o que leva a uma institucionalização do sistema total.

Sem a actuação em conjunto da técnica, da organização, da justiça e da institucionalização, não é concretizada uma configuração do sistema que ofereça a todos os participantes no sistema no âmbito das condições de base uma ampla autonomia de decisão. 22 ΕΡ Ο 780 801 /ΡΤ

Diagrama 2: modelo de sistema do conceito

Num processo de cobrança automática de taxas respectivamente num sistema de cobrança automática de taxas, é em principio exigido que nenhum dado relacionado directamente à pessoa e ao veiculo seja processado e memorizado. A totalidade do processo de cobrança corrente é configurada de tal modo que não resultem vestígios de dados que possam ser seguidos. Em princípio o método da cobrança automática de taxas subdivide-se em três áreas separadas, em que respectivamente deve ser considerada esta exigência: 1) Averiguação da taxa pelos passos do aviso da proposta do fornecedor de serviços (a), da declaração da intenção de compra e de pagamento (b), da fixação do preço (c) 2) O processo de pagamento 3) A entrega do recibo. A averiguação da taxa pode efectuar-se neste caso em diálogo entre o dispositivo de pagamento, no caso do exemplo 23 ΕΡ Ο 780 801 /ΡΤ ο transponder transportável respectivamente OBU (On-Board Unit) com o cartão de pagamento, e o dispositivo de cobrança, no caso do exemplo, o interrogador fixo no local respectivamente RSE (Road-Side-Equipment). Conforme a reivindicação 2 a averiguação da taxa efectua-se no dispositivo de pagamento do utilizador, sem influência externa (isto é de forma autónoma), baseado na análise de uma tabela memorizada ou do resultado de um correspondente algoritmo. Não é necessária a transmissão de dados individuais das pessoas e do veiculo bem como a memorização dos dados.

De forma favorável o utilizador pode no processo de pagamento decidir, que meio de pagamento (autorizado) vai utilizar. A seguir os componentes individuais do sistema

Meio de pagamento,

On-Board-Equipment,

Road-Side-Equipment,

Concentrador,

Adquirente,

Emitente,

Collection Agent

Posto de controlo da cobrança automática de taxas (Enforcement) e

Instância de autorização (institucionalização) é descrita em pormenor quanto às suas funções e opções de realização.

Meio de pagamento O termo "meio de pagamento" designa o modo como um utilizador, isto é o cliente no sistema de cobrança automática de taxas (por via bancária) paga a prestação de serviços de um prestador de serviços, e abrange todas as funções e os dados necessários para o processo de pagamento e sua protecção. Em principio devem para a cobrança automática de taxas RSE autorizados quaisquer meios de pagamento respectivamente opções de pagamento, em que o utilizador em principio deve ter a liberdade de escolha (isto é o mesmo 24 ΕΡ Ο 780 801 /ΡΤ montante da taxa para todos os meios de pagamento autorizados): pré-pagamento (Prepayment) pela utilização de um porta-moedas electrónico ou pagamento posterior (Postpayment) indicando uma conta de crédito ou débito, utilização de um meio de pagamento universal (isto é independente dos serviço prestado) ou especifico para transportes (por exemplo cobrança automática de taxas), utilização de um meio de pagamento com aceitação ou regional (por exemplo um meio de pagamento válido na região de um operador de auto-estrada) ou supra-regional (por exemplo um porta-moedas nacional) ou internacional (isto é supra-nacional prescrito pela instância de autorização como meio de pagamento a RSE aceite por todos os fornecedores de serviço da cobrança automática de taxas). A separação fundamental entre as aplicações do meio de pagamento e a cobrança automática de taxas e a possibilidade de utilização de um meio de pagamento universal na cobrança automática de taxas exigem que como suporte para o meio de pagamento seja utilizado um media tecnicamente perfeito, com aceitação geral e, em particular, seguro. Portanto no conceito parte-se do principio de que o meio de pagamento representa na generalidade uma aplicação num cartão inteligente normalizado multi-funcional. Estes cartões inteligentes universalmente utilizáveis em poucos anos estarão divulgados como suportes de porta-moedas electrónicos substituindo o valor monetário e devem portanto em principio também serem autorizados para o pagamento na cobrança automática de taxas.

Devido a esta tendência é na configuração técnica do dispositivo de pagamento, isto é do On-Board Equipment (OBE) como por exemplo no diagrama 2, apresentada a possibilidade de o cartão inteligente não poder RSE somente o suporte do 25 ΕΡ Ο 780 801 /ΡΤ meio de pagamento, mas também poder conter a aplicação da cobrança automática de taxas (vide o parágrafo seguinte).

Por outro lado por esta tendência não deverá RSE excluido que na forma de realização mais simples um meio de pagamento especifico para transportes seja uma parte integral (funcional) do On-Board-Equipment. Por exemplo deverá RSE possivel adquirir a titulo de empréstimo na passagem de uma fronteira um OBE em cuja memória (por exemplo uma pastilha EEPROM) esteja carregado um determinado saldo disponível pago antecipadamente.

Em principio deve estar assegurado que na utilização de um meio de pagamento num sistema de cobrança automática de taxas (tal como no pagamento de qualquer outro serviço também) os acordos legais, estipulados entre os emitentes dos pagamentos, dos adquirentes e dos fornecedores de serviços, não sejam iludidos pela técnica. Em particular, devem RSE cumpridos os requisitos relevantes quanto à segurança, nos quais se baseia a garantia de pagamento para com o fornecedor de serviços, o que deve RSE assegurado pela institucionalização. Por isso os diferentes interesses de emitentes e fornecedores de serviços devem em princípio RSE salvaguardados por meio de domínios de segurança separados.

Em consequência no conceito parte-se do princípio, que tanto a aplicação do meio de pagamento como também a aplicação da cobrança automática de taxas poderem em princípio possuir os seus processos de segurança próprios, separados entre si, os quais são designados na normalização (por exemplo para porta-moedas electrónicos) por Security Application Module (SAM).

Um SAM deve RSE sempre utilizado, quando para a protecção de transacções deverem existir funções de segurança em particular, sensíveis, e é composto por um componente de suporte lógico e um de suporte físico. O componente de suporte lógico é composto por uma lógica de supervisão da operação para a aplicação a RSE protegida e contém algoritmos de codificação, chaves secretas criptográficas e outros dados e parâmetros relevantes quanto à segurança, enquanto que o 26 ΕΡ Ο 780 801 /ΡΤ componente do suporte físico serve para a própria protecção das funções de segurança.

De acordo com o invento ambos os SAM podem RSE idênticos. Isto permite que no caso de uma simples forma de realização do OBE ou no caso de um fornecedor de serviços de cobrança automática de taxas emitir o seu próprio meio de pagamento, ambas as aplicações formem um domínio de segurança comum, podendo portanto utilizar os mesmos mecanismos de segurança e as mesmas chaves.

De acordo com o invento está de preferência previsto que um cartão inteligente seja o suporte do meio de pagamento, contudo não da aplicação de cobrança automática de taxas, possua um SAM próprio, através do qual a legitimidade da utilização do meio de pagamento num sistema de cobrança automática de taxas possa RSE controlado respectivamente garantido.

Além disso tem preferência que por motivos de aceitação e inter-operacionalidade sejam utilizados somente cartões inteligentes, cujas propriedades físicas e eléctricas estejam determinadas na norma ISO 7816, parte 1-3 respectivamente no CEN-Pránorm prENV 1855. O modelo de dados lógico interno da pastilha está predeterminado em 7816-5 por uma estrutura em árvore, a qual no mais alto nível possui um ficheiro principal (Master file, MF) no qual se encontram instalados ficheiros individuais (Elementary File, EF) ou subdirectorias (Dedicated File DF). Esse tipo de estruturação de dados é de preferência prevista também para as aplicações e dados instalados na OBU, em particular, no caso da opção de realização OBE I "solução compacta", que é descrita mais abaixo. O MF é instalado pelo produtor do cartão e personalizado pelo emitente do cartão, isto é, inscrito com os EF directamente subordinados ou - no caso de já existirem -alterados. O ficheiro principal do cartão contém informações gerais referentes ao cartão e suas propriedades (dados para a produção da pastilha, do módulo e do cartão, parâmetros técnicos característicos, data da activação e data do vencimento, identificação do país etc.), referentes ao 27 ΕΡ Ο 780 801 /ΡΤ detentor do cartão (nome, preferência da língua, protecção PIN, etc.) e referentes aos mecanismos de segurança e dados independentes da aplicação.

Cada subdirectoria no próximo nível corresponde a uma aplicação e é instalada conforme a opção do detentor do cartão e sob responsabilidade do emitente do cartão, respectivamente é personalizada e eventualmente actualizada sob a responsabilidade do emitente da aplicação. Uma subdirectoria pode RSE composta por mais outras subdirectorias ou ficheiros individuais.

Com esta estruturação lógica de dados torna-se possível favorecer também tecnicamente a separação funcional entre os diferentes intervenientes na produção do módulo, da preparação do cartão e da emissão do cartão e da aplicação bem como a independência legal entre diferentes emitentes de aplicações, de modo que por exemplo interacções recíprocas não pretendidas entre diferentes aplicações e seus mecanismos de segurança possam RSE seguramente impedidas. Neste contexto tem especial importância a norma ISO 10202, o qual determina a arquitectura de segurança dos cartões de crédito e débito.

On-Board-Equipment (OBE)

Um elemento essencial do invento é a execução de actos de utilização de meios de pagamento pelo dispositivo de pagamento em vez de RSE pelo utilizador, de modo que os actos são automatizados. Para os sistemas de cobrança automática de taxas e sistemas comparáveis, os quais operam com o método de acordo com o invento, o dispositivo de pagamento é realizado de preferência na forma do já mencionado On-Board-Equipment (OBE). O dispositivo de pagamento adopta respectivamente a um modo diferente a realização do processo de pagamento e correspondentemente o OBE é equipado de forma diferente. O dispositivo de pagamento pode por exemplo adoptar no essencial somente as etapas processuais reservadas ao utilizador, enquanto que as etapas processuais típicas para o fornecedor são realizadas pelo dispositivo de cobrança.

De acordo com a reivindicação 1 o dispositivo de pagamento adopta adicionalmente também as funções essenciais 28 ΕΡ Ο 780 801 /ΡΤ do dispositivo de cobrança, em particular, a fornecimento de dados, os quais representam a taxa a RSE paga etc. bem como a execução e o registo do pagamento e a elaboração e apresentação do recibo. O controlo do pagamento efectivo desejável em ambos os casos por parte do fornecedor é em principio igual, pode no entanto RSE tecnicamente caracterizado de forma diferente. Assim por exemplo o controlo dos dados memorizados no dispositivo de pagamento referente aos comprovativos de pagamento só é possível por meio de provas feitas ao acaso ou de caso para caso ou no caso da reivindicação 1 também periodicamente, por exemplo após um número configurável de processos de pagamento automaticamente por meio da geração de uma interface de comunicação adequada com um posto de controlo da cobrança automática de taxas (virtual). Em todo o caso para evitar um dispêndio desproporcionado na realização do invento é na maioria dos casos preferível não ligar de forma fixa a função de controlo com o dispositivo de cobrança (um assim denominado controlo separado ao contrário do controlo integrado). Estes controlos são também geralmente efectuados localmente e temporalmente conectados após o decurso da realização do pagamento de acordo com o invento. A seguir o invento é em primeiro lugar explicado em pormenor por um exemplo de concretização de um OBE, em que o dispositivo de pagamento e o dispositivo de cobrança formam uma interface de comunicação, resultando obviamente para o perito que consideráveis partes desta descrição também se aplicam para a realização de acordo com a reivindicação 1.

Visto que para a cobrança automática de taxas, entre o meio de suporte do meio de pagamento e da cobrança de taxas do fornecedor de serviços RSE para o processo de pagamento excluído um intercâmbio de dados com contactos, a comunicação, entre os dois componentes de sistema, é realizada através de uma transmissão via rádio, a qual por parte do utilizador é realizada através do On-Board-Equipment (OBE) na viatura (interface de ar).

Além das severas restrições de tempo no caso de uma comunicação a curta distância através da interface de ar à 29 ΕΡ Ο 780 801 /ΡΤ velocidade máxima, são ο requisito de protecção de dados da separação de dados de movimentação e pagamentos e o requisito de rendibilidade da restrição da quantidade de dado relevantes para o pagamento os motivos mais importantes para que quando da aplicação de um meio de pagamento universal, isto é nos domínios da segurança separada, dever rse distinguido entre o saldo disponível certificado, o qual é gerado no On-Board-Equipment, e os valores individuais a serem descontados do mesmo.

Isto significa, em particular, que para o processo de pagamento geralmente não é possível uma comunicação directa entre o meio de pagamento e o posto de cobrança de taxas, mas sim são transmitidos a confirmação de pagamento de um taxa de cobrança automática em conjunto com o saldo disponível certificado ou uma informação certificada da conta ao posto de cobrança da taxa. Antes do encaminhamento do débito individual (isto é cada uma das taxas cobradas automaticamente) pelo fornecedor de serviços ao adquirente, efectua-se uma agregação das informações relevantes ao pagamento referente aos dados certificados pelo meio de pagamento.

Nos casos em que é possível uma comunicação directa entre o meio de pagamento e o posto de cobrança da taxa (por exemplo por meio de uma comunicação extremidade a extremidade entre o cartão inteligente e o Road-Side-Equipment) ou um fornecedor de serviços emitir o seu próprio meio de pagamento, é possível eventualmente prescindir de uma certificação adicional da importância descontada durante um pagamento de cobrança automática de taxas.

Conceptualmente o On-Board-Equipment é composto pelas seguintes unidades funcionais a serem logicamente separadas:

Sistema de comunicação: esta parte técnica do OBE realiza a parte referente à transmissão do protocolo de comunicação para a interface de ar (por exemplo DSRC ou GSM) e eventualmente - dependente da forma técnica de realização, ver adiante - o protocolo do cartão inteligente (por exemplo T=1 conforme ISO 30 ΕΡ Ο 780 801 /ΡΤ 7816-3) e é competente para o accionamento dos dispositivos de comando, mostrador, luzes de controlo etc.; utilização de cobrança automática de taxas: esta unidade funcional lógica é activada na base de acções, as quais são incentivadas pelo utilizador, pelos sistemas de cobrança de taxas de um fornecedor de serviços, dos componentes de localização para organismos pagadores virtuais ou postos de controlo de cobrança automática de taxas, realiza o processamento e a memorização de dados referentes à cobrança automática de taxas e a parte da comunicação referente à aplicação com outros componentes de sistemas e gera uma ou várias memórias de títulos; uma parte integrante desta unidade funcional pode RSE o SAM da cobrança automática de taxas, o qual com mecanismos criptográficos garante, em particular, a autenticidade e a regularidade de uma cobrança de taxa, do processo de pagamento e do comprovativo de pagamento; e

Meio de pagamento: a unidade funcional lógica do meio de pagamento está separada da aplicação de cobrança automática de taxas, tornando-se activa por incentivo da aplicação de cobrança automática de taxas ou de uma instância de carregamento entrando em interacção com estas; o meio de pagamento possui geralmente um SAM próprio, o qual assegura as transacções relevantes do pagamento com o mundo exterior (por exemplo posto de aceitação de cartões ou instancia de carregamento, neste caso: aplicação de cobrança automática de taxa).

Os componentes técnicos do OBE tais como teclado, mostrador, contactos etc. não serão explicadas neste contexto, visto serem irrelevantes para a concepção 31 ΕΡ Ο 780 801 /ΡΤ funcional. Estes componentes são em princípio conhecidos no estado da técnica. 31 ΕΡ Ο 780 801 /ΡΤ »<}

Diagrama 3: Estruturação lógica de um On-Board-Equipment A estruturação lógica do OBE é exemplificada no diagrama 3.

De acordo com o invento por meio desta concepção tornam- se possíveis várias opções de realização. - Opção I: "Solução compacta"

Na forma de realização mais simples o OBE é composto por uma única unidade técnica, a qual integra todas as unidades funcionais lógicas (neste caso OBE e OBU coincidem e formam o dispositivo de pagamento). Esta forma pode por exemplo RSE utilizada quando da passagem pela fronteira adquirir a título de empréstimo um OBE, carregado na memória interna com um determinado saldo disponível pago antecipadamente, o qual pode RSE sucessivamente consumido e recarregado em carregadores especiais. Isto corresponde às características de um meio de pagamento de pré-pagamento, específico para transportes e nacional.

Esta variante também é adequada, quando por exemplo potenciais clientes acordam condições especiais com fornecedores de serviços, efectuando-se o pagamento 32 ΕΡ Ο 780 801 /ΡΤ através de uma conta central. Isto corresponde às características de um meio de pagamento de pós-pagamento, específico para transportes e regional ou supra-regional.

Nesta forma de realização pode com especial vantagem RSE previsto que o modelo lógico de dados e aplicação do OBU seja estruturado como no caso de um cartão inteligente, visto que todas as unidades funcionais lógicas por motivos de custos estão de forma conveniente reunidas numa única pastilha. Uma pastilha devido às suas características técnicas e lógicas pode além disso sob certas condições prévias RSE aplicado como suporte físico, de modo que ambos os SAM de aplicação podem funcionalmente RSE reunidos, visto que afinal só deve RSE assegurada a comunicação através da interface de ar.

Opção II: "Solução transponder"

Nesta forma de realização o sistema de comunicação está tecnicamente separado do meio de pagamento e da aplicação de cobrança automática de taxas as quais estão reunidas em conjunto num cartão inteligente normalizado. No caso do meio de pagamento específico para transportes também nesta variante é possível unir de modo funcional o SAM de cobrança automática de taxas e o SAM do meio de pagamento. É por outro lado pensável que os emitentes da aplicação da cobrança automática de taxas e do meio de pagamento sejam instituições juridicamente independentes ou que o meio de pagamento tenha carácter universal, de modo que a relação legal entre o fornecedor de serviços de cobrança automática de taxas e o emitente do meio de pagamento também deverá RSE protegida tecnicamente em relação à segurança (isto é de modo criptográfico). Neste caso ambas as aplicações podem em princípio possuir o seu próprio SAM para a separação do domínio da segurança, em que a interacção dos SAM deverá RSE controlada através de um correspondente "Keymanagement".

Opção III: "Solução normalizada" 33 ΕΡ Ο 780 801 /ΡΤ

Uma outra alternativa consiste no facto do conjunto do sistema de comunicação e da aplicação da cobrança automática de taxas estar alojado na On-Board-Unit enquanto que o meio de pagamento completamente separado das mesmas está integrado num cartão inteligente normalizado. Com isto é no conceito também favorecido o pagamento com porta-moedas electrónicos universais, os quais no futuro serão amplamente divulgados em substituição de pagamento numerário. De igual modo pode RSE utilizado qualquer outro meio de pagamento universalmente autorizado na base de cartões inteligentes no conceito do pagamento de cobrança automática de taxas.

Opção IV: "Solução 2 cartões inteligentes" A forma de realização mais dispendiosa, a qual contudo também oferece a maior flexibilidade, permite cartões inteligentes separados para as aplicações de meios de pagamento e aplicação de cobrança automática de taxas, o que sem a independência legal dos respectivos emitentes não é muito conveniente. Por isso nesse caso parte-se em principio da existência de um SAM de meio de pagamento e separado deste um SAM de aplicação da cobrança automática de taxas, visto que, independentemente das caracteristicas do meio de pagamento, dever RSE sempre salvaguardada e também tecnicamente fundamentada a relação legal entre os emitentes. Neste caso a OBU reduz-se funcionalmente ao sistema de comunicação, o qual por exemplo está montado numa viatura e equipado com dois leitores de cartões inteligentes.

Em principio está previsto que respectivamente as ultimas transacções de cobrança automática de taxas (o número total é independente da forma de realização do OBE) permaneçam continuamente registadas na memória, sendo proporcionado ao utilizador controlar os últimos pagamentos. Além do controlo dos títulos através do mostrador está previsto para cada opção um método de imprimir adicionalmente os recibos. 34 ΕΡ Ο 780 801 /ΡΤ

Na opção I isto pode por exemplo RSE facilitado quando a OBU for retirada da viatura e num dispositivo de leitura (da instância de carregamento ou da agência de venda) serem imprimidas as memórias de transacção. No caso das opções II, III e IV, o registo de transacção pode em vez disso estar num cartão inteligente e correspondentemente RSE imprimido num dispositivo de leitura de cartões inteligentes externo.

Além disso o OBE dispõe de mais outras indicações ópticas e acústicas, com as quais podem RSE sinalizadas determinadas situações operacionais e transaccionais (montante da taxa, pagamento efectuado ou não efectuado, queda da tensão, Enforcement etc.).

Road-Side-Equipment

Por Road-Side-Equipmento (RSE) é neste conceito designado em geral aquele terminal de um fornecedor de serviços de cobrança automática de taxas, o qual para a cobrança automática de taxas num posto de pagamento ou para a emissão de títulos numa entrada de veículos entra em comunicação com um On-Board-Equipment de um cliente. A forma típica de realização para a cobrança das taxas de utilização de estradas baseia-se em estações de cobrança instaladas na estrada e que através de microondas ou infravermelhos entram em intercâmbio de dados com o veículo em passagem. Por meio deste conceito são contudo também favorecidos aqueles sistemas de cobrança automática de taxas que não servem para a cobrança das taxas de utilização de estradas, mas por exemplo de taxas em estacionamentos cobertos.

Além disso existem sistemas de cobrança automática de taxas baseados em GNSS (Global Navigation Satellite System, por exemplo GPS), os quais, ou (no sentido do exemplo de concretização de acordo com a reivindicação 1) funcionam de forma autónoma (isto é o pagamento de taxas somente por meio de um processamento interno de dados do dispositivo de pagamento, em particular, sem comunicação externa) ou numa comunicação via rádio por exemplo através de GSM, entram em 35 ΕΡ Ο 780 801 /ΡΤ comunicação com um posto de cobrança externo. Nestes casos o incentivo para o pagamento de taxas efectua-se quando for atingida uma determinada posição geográfica, detectada por um módulo de localização no interior da viatura (por exemplo por meio da recepção de sinais GPS e alinhamento com um mapa digital) de modo que frequentemente também é mencionado um posto de pagamento virtual ou um Road-Side-Equipment virtual.

As unidades funcionais mais importantes do RSE são: o módulo de comando da cobrança automática de taxas, o qual, tanto periodicamente como também orientado à ocorrência, estabelece a comunicação referente à utilização através da interface de ar, executa a verificação automática da taxa e a sua cobrança ou a emissão de títulos para as viaturas registadas e processa os dados relevantes para o pagamento; parte integrante desta unidade funcional pode RSE um SAM, o qual com mecanismos criptográficos controla de forma fiável a integridade e autenticidade dos dados, das ocorrências e dos parceiros de comunicação. O sistema de comunicação, o qual por um lado compreende o dispositivo de emissão e recepção para a parte técnica da transmissão do protocolo de comunicação na interface de ar e por outro lado estabelece o encaminhamento ou a transmissão de ficheiros de transacção para a introdução nas operações de pagamento, e eventualmente uma memória para as transacções, onde os dados relevantes para o pagamento das transacções de cobrança automática de taxas são reunidos, memorizados temporariamente e eventualmente pré-concentrados.

Geralmente o RSE está ligado através de uma linha de comunicação com um computador central do fornecedor de serviços (por exemplo concentrador) através do qual periodicamente, por exemplo diariamente, são transmitidos os dados locais relevantes do pagamento reunidos num 36 ΕΡ Ο 780 801 /ΡΤ correspondente protocolo. Em sistemas especiais (por exemplo caixa automática de auto-silos) também é possível que a memória de transacção seja realizada como cartão inteligente ou disquete, cujo conteúdo pode RSE introduzido na operação de pagamento pelo intercâmbio do meio de memorização, ou que a memória de transacções seja esvaziada por uma comunicação via rádio.

Diagrama 4: Estruturação lógica de um Road-Side-Equipment A concepção lógica do RSE é explicada no diagrama 4.

No caso de um meio de pagamento específico de transportes e pago antecipadamente, pode no módulo de comando da cobrança automática de taxas efectuar-se uma pré-agregação dos dados relevantes do pagamento de modo que somente a soma das taxas é transmitida ao computador central.

Os mecanismos de segurança do SAM são de preferência utilizados pelo módulo de comando da cobrança automática de taxas, tanto para proteger as operações automáticas de pagamento através da interface de ar contra manipulações não autorizadas como também salvaguardar contra alterações não autorizadas ou duplicação os dados relevantes do pagamento, os quais para a agregação são transmitidos ao concentrador do fornecedor de serviços.

Concentrador 37 ΕΡ Ο 780 801 /ΡΤ

Neste sistema modelo ο concentrador representa a cabeça de rede do fornecedor de serviços para com o posto de compensação. A sua função consiste em receber respectivamente consultar em todos os RSE do fornecedor de serviços os dados de transacção relevantes para o pagamento, extrair destes os dados individuais e agrega-los tanto quanto possível quanto ao meio de pagamento. Conforme a relação contratual entre o fornecedor de serviços, emitentes de meios de pagamento e adquirentes, os dados referentes ao sistema de pagamento são separados e processados de tal forma que os mesmos possam RSE transmitidos ao ou aos adquirentes.

Visto que no concentrador se reúne uma pluralidade de dados individuais, dos quais se poderia fazer mau uso para o desvio de informações de movimentos e comportamentos, são estes dados e as suas possibilidades de processamento sujeitos a uma rigorosa delimitação, a qual de acordo com os regulamentos de protecção de dados deve RSE garantida e controlada. Em particular, os dados de transacções, os quais por exigências de técnicas de revisão permanecem memorizados durante um longo período, devem RSE eficazmente protegidos contra consultas, utilização e alteração não autorizadas.

No caso da utilização de um meio de pagamento de pós-pagamento no sistema de cobrança automática de taxas, o utilizador pode requerer uma descodificação individual dos dados de transacção que lhe são facturados pelo seu banco (emitente). Por motivos de protecção de dados isto somente é possível quando o utilizador autorizar explicitamente o instituto que gera a sua conta, para recolher estes dados dos fornecedores de serviços da cobrança automática de taxas. Neste caso o emitente pode por exemplo reunir estes dados numa factura mensal com provas das taxas individuais, enviando-a ao utilizador.

Adquirente

No sistema modelo da cobrança automática de taxas o adquirente é aquela instituição, a qual compra de todos os fornecedores de serviços todas os débitos referentes aos sistemas de pagamento por ele processados, efectuando o pagamento (nota de crédito). Os débitos são controlados 38 ΕΡ Ο 780 801 /ΡΤ quanto à sua autenticidade e integridade, sendo, em particular, a autenticidade do meio de pagamento verificada na base dos dados de certificação, os quais são fornecidos juntamente com os débitos. Após a respectiva reclassificação os dados de débito são remetidos ao respectivo emitente, para que se possa efectuar a compensação de pagamento (nota de débito). A função do adquirente pode RSE realizada por exemplo por um instituto de crédito, uma sociedade emissora de cartões ou um fornecedor de serviços de processamentos. O modelo permite a integração de um ou vários adquirentes, é por exemplo pensável que um adquirente processe um ou vários meios de pagamento ou desempenhe a função de uma cabeça de rede nacional ou internacional para um ou vários meios de pagamento especificamente para o transporte. No caso de identidade jurídica de um emitente de um meio de pagamento e um fornecedor de serviços, a função do adquirente também pode RSE realizada pelo próprio fornecedor de serviços.

Emitente O termo emitente no modelo sistema de cobrança automática de taxas é como conceito genérico entendido para o fornecedor ou emissor de um meio de pagamento ou um instituto de crédito gerador de contas. Conforme a característica do meio de pagamento pode desempenhar a função de emitente um instituto de crédito, uma sociedade emissora de cartões, uma associação de transportes públicos urbanos, uma empresa operadora de auto-estradas etc.

Neste contexto uma das funções do emitente é a elaboração e distribuição de listas de bloqueio para estes meios de pagamento, os quais por exemplo devido a furto, anomalias ou outras violações da segurança já não podem RSE aceites. As informações necessárias para o efeito podem por exemplo RSE requeridas dos adquirentes, visto que estes podem detectar violações da segurança independentes do serviço no comportamento do pagamento (como função Outsourcing, a responsabilidade é no entanto do emitente). 39 ΕΡ Ο 780 801 /ΡΤ

No conceito está previsto que estas informações de bloqueio possam RSE transmitidas até aos dispositivos RSE e a partir destes também opcionalmente e por selecção serem transferidos à OBU. Para meios de pagamento pagos antecipadamente o emitente do sistema de pagamento pode além disso controlar saldos actuais memorizados referentes aos meios de pagamento que se encontram em circulação (por exemplo porta-moedas electrónico), para poder detectar eventuais ataques contra a segurança.

Agente fiduciário (Collection Agent)

Este componente modelo tem importância quando por exemplo num sistema de cobrança automática de taxas forem aplicados meios de pagamento pagos antecipadamente. Neste caso pode tratar-se de uma correspondente agência de vendas para cartões inteligentes ou On-Board-Units autorizada pelo emitente ou uma instância de carregamento para porta-moedas electrónicos (Caixa automática para dinheiro electrónico).

Posto de controlo de cobrança automática de taxas (Enforcement) O posto de controlo de cobrança automática de taxas é um componente do sistema em princípio separado da cobrança de taxas. Este tem a função de controlar a existência e a autenticidade da respectiva última prova de pagamento necessária, controlar se neste caso a aplicação da tarifa foi regular, eventualmente e só no caso de não ter sido feito o pagamento ou este tenha sido errado, reunir os dados como garantia de prova e um pagamento posterior da taxa, e proceder a uma cobrança tanto quanto possível automatizada das taxas não pagas e eventuais taxas suplementares. 40 ΕΡ Ο 780 801 /ΡΤ Ο posto de controlo da cobrança automática de taxas pode ou RSE estacionário para o controlo de utentes da estrada em circulação ou móvel para o controlo de utentes em circulação ou estacionários, comunicando através da interface de ar com as On-Board-Units.

Tecnicamente o controlo da cobrança automática de taxas também pode estar acoplado com um RSE, para que a medida conservatória de prova para não pagadores ou pagamentos errados possa RSE levada a fazer directamente a seguir. Isto também é designado por Enforcement integrado. Ao contrário disto, como já acima explicado, o Enforcement destacado é realizado por meio de um controlo tecnicamente separado da cobrança de taxas, temporalmente ligado a jusante e geralmente por amostras aleatórias.

Instância de autorização (Institucionalização)

Uma condição indispensável para a participação de todos os componentes do sistema num sistema de cobrança automática de taxas consiste no facto de que os requisitos de arquitectura relevantes para a segurança quando da realização dos componentes do sistema de pagamento da cobrança automática de taxas sejam convertidos completa e correctamente em medidas técnicas, de organização e legais e que estas medidas também sejam cumpridas na operação.

Requisitos relevantes de segurança resultam do facto de terem de RSE assegurados a segurança conta manipulação e revisão, o cumprimento dos regulamento da protecção de dados e o fluxo regular de todos os pagamentos, visto que nos diferentes componentes do sistema total uma pluralidade de dados referentes a clientes, pagamentos e serviços são gerados, apresentados, encaminhados, explorados e memorizados, sendo portanto expostos a uma pluralidade de riscos. A instância de autorização deve cumprir as seguintes funções:

para todos os componentes do sistema e pessoas civis a participação no sistema total deve RSE 41 ΕΡ Ο 780 801 /ΡΤ regulamentada por um processo de autorização, o qual evite de forma eficaz a utilização de sistemas não autorizados (cartões inteligentes, aplicações, terminais, fornecedores de serviços, etc.), isto é também com obrigações técnicas nos decursos automáticos, isto implica um processo de aceitação para todos os componentes do sistema, sempre onde surjam processos de pagamento e se efectuam os correspondentes fluxos de dados, a legitimidade, a autenticidade e eventualmente o sigilo devem RSE garantidos. Em particular, devem RSE tomadas medidas as quais impeçam um carregamento não autorizado de meios de pagamento ou um débito de importâncias e a simulação ou reintrodução de pagamentos já efectuados bem como possibilitem o bloqueio de assinantes individuais ou grupos de assinantes (cartões inteligentes, aplicações, meios de pagamento, aparelhos), a evidência de processos de pagamento deve estar assegurada, e todas as transacções e débitos devem RSE reproduzíveis seguros para a revisão. Neste caso devem RSE considerados os especiais requisitos legais de protecção de dados para a cobrança, memorização, processamento e transmissão de dados relativos a pessoas ou possíveis de relacionar com as mesmas (estreita afectação), a impressão técnica do sistema e os decursos técnicos e de organização devem RSE configurados de tal modo que na generalidade possam RSE garantidos todos os pagamentos entre assinantes do sistema. Isto deve RSE regulamentado pelos respectivos acordos contratuais (por exemplo entre fornecedor de serviços, adquirentes e emitentes).

Para a autorização operacional devem, à semelhança dos regulamentos para o sistema de caixas automáticas (caixas Multibanco) ou o sistema electronic-cash do regime de crédito alemão, RSE elaborados contratos para quaisquer participantes, os quais proponham uma prestação de serviço a 42 ΕΡ Ο 780 801 /ΡΤ nível local, nacional ou europeu. Nos mesmos, em particular, para o licenciamento de componentes do sistema, devem RSE exigidos os controlos obrigatórios respectivamente os pareceres para a segurança IT de cartões inteligentes, aplicações, On-Board-Equipment, RSE, conceitos de redes, postos de compensação etc.

Os critérios destes controlos devem entre outros RSE a liberdade de manipulação de aplicações relevantes quanto à cobrança automática de taxas e pagamentos nos mais diferentes postos de aplicação no sistema total bem como a independência e a liberdade de efeitos retroactivos de diferentes aplicações quando da utilização de cartões inteligentes multi-funcionais. Deve RSE verificado se em todas as situações regulares e irregulares de aplicação são salvaguardados os interesses para todos os participantes no sistema em qualquer fase de processamento seja isto no respectivo momento efectivo ou, pelo menos, retrospectivo, e a garantia de pagamento para todas as cobranças regulares de taxas seja salvaguardada.

Duas tarefas subordinadas às funções de autorização podem no âmbito da administração RSE consideradas como chaves criptográficas:

No caso de emitentes independentes de meios de pagamento e fornecedores de serviços, a autorização de um sistema de pagamento para o sistema de cobrança automática de taxas deve RSE estabelecido através do "Keymanagement", o qual é necessário para a activação dos SAM. Para este efeito é conveniente pretender um método de segurança harmonizado com arquitectura de chaves compatível para todos os emitentes e fornecedores de serviços, o que de forma ideal pode RSE coordenado no âmbito dos procedimentos de autorização.

Na utilização de métodos de codificação assimétricos para a autenticação de sócios e para gerir assinaturas digitais é necessária uma instância de certificação, a qual atribui a cada um dos sócios autorizados uma chave de tal modo que a legalidade 43 ΕΡ Ο 780 801 /ΡΤ da atribuição de qualquer outro participante no sistema possa RSE verificada.

No caso de uma expansão internacional respectivamente de uma abertura do sistema de cobrança automática de taxas, a instância de autorização e o sistema de administração das chaves deve RSE implementado de forma hierárquica, a fim de integrar as respectivas tarefas e competências nacionais num processo de autorização internacional e uma administração uniforme de chaves. Deste modo, na base de requisitos de segurança harmonizados e de critérios de admissão, os participantes no sistema de cobrança automática de taxas a nivel nacional podem RSE admitidos para a aplicação internacional.

Referente ao processo de pagamento quando da utilização de serviços através da interface de ar e na preparação deste processo no On-Board-Equipment deve RSE distinguido se se trata de um meio de pagamento tipo bolsa (pré-pagamento) ou um meio de pagamento com base na conta (pagamento posterior). O ponto de referência para a fixação numa forma de concretização, particularmente preferida, de acordo com o invento é neste caso que, devido aos domínios de segurança separados - não tendo em conta uma eventual identificação de organização dos componentes do sistema (por exemplo coincidência do emitente e fornecedor de serviços) normalmente só o emitente do meio de pagamento possua as chaves para a certificação de processos de pagamento e disponibilize estas - excepto quando da aplicação de processos de criptográficos assimétricos - somente ao adquirente para um controlo de autenticidade para requisitos apresentados por fornecedores de serviços.

Pagamento com porta-moedas electrónico:

Na utilização de porta-moedas universais dados comprimidos só podem RSE introduzidos em operações de pagamento não quando cada uma das taxas da cobrança automática for certificada pelo meio de pagamento, mas sim se antecipadamente, isto é antes da primeira cobrança de taxa, for certificado um determinado saldo disponível e for 44 ΕΡ Ο 780 801 /ΡΤ fornecido à aplicação da cobrança automática de taxas no OBE para o pagamento por conta das taxas individuais seguinte.

Portanto no conceito de uma forma de concretização, em particular, preferida de acordo com o invento está previsto que no caso de um pagamento com um porta-moedas universal, como é apresentado pelo regime de crédito alemão, antes do inicio da viagem seja descontado um saldo disponível do porta-moedas e na forma certificada transferido à aplicação da cobrança automática de taxas no On-Board-Equipment independentemente se este se encontrar no mesmo cartão inteligente, num outro cartão inteligente ou na On-Board-Unit. O saldo disponível pode RSE escolhido ou pelo utilizador ou pode por exemplo RSE fixado por um determinado parâmetro do sistema do emitente, ou o mesmo pode resultar do total do saldo disponível no porta-moedas.

Este saldo disponível, o qual normalmente ultrapassa nitidamente a cobrança automática das taxas e que deve RSE gerido de forma segura na aplicação do OBE na cobrança automática de taxas, serve como valor de referência para a reunião das pertencentes taxas individuais no fornecedor de serviços antes da iniciação dos créditos na operação de pagamento e não deve portanto RSE ultrapassado pela soma das taxas individuais. Do saldo disponível são, na aplicação do OBE na cobrança automática de taxas, descontadas as taxas individuais durante tanto tempo até que o saldo esteja consumido, tornando necessário um novo processo de débito. Um saldo restante no fim da viagem ou pode permanecer na aplicação da cobrança automática de taxas ou RSE reconduzido como ordem de anulação parcial. No âmbito da autorização da cobrança automática de taxas do meio de pagamento "porta-moedas universal" é portanto necessário que sejam cumpridos os decursos de segurança por parte dos equipamentos e do suporte lógico e os emitentes assumirem uma obrigação com os fornecedores de serviços de que todas as somas de débitos assim formadas também sejam liquidadas.

Quando o porta-moedas e a aplicação da cobrança automática de taxas possuírem domínios de segurança idênticos, o que no caso normal só é possível para um porta-moedas específico de transportes, pode-se prescindir da 45 ΕΡ Ο 780 801 /ΡΤ certificação de um saldo disponível quando o meio de pagamento for aceite somente pelo fornecedor emitente de serviços, visto que neste caso a operação de pagamento é efectuada pelo próprio fornecedor de serviços ou um prestador de serviços por ele autorizado.

Neste último caso mencionado ou no caso de sistemas baseados em GNSS ou de um modo geral, quando o período de tempo requerido para o processo de pagamento ou a capacidade de rendimento técnica das pastilhas e as técnicas de transmissão o permitam, também pode RSE estabelecida uma comunicação directa entre o meio de pagamento e o dispositivo de cobrança, de modo que é possível prescindir de uma fornecimento prévia de um saldo disponível. Neste caso em cada pagamento de taxa é descontada somente a taxa efectiva pagável, de modo que não se realiza um retorno de saldos eventualmente não consumidos.

Pagamento por conta:

No caso do pagamento por conta é somente necessário transmitir a informação certificada da conta à aplicação da cobrança automática de taxas. Estes dados, no caso de não apresentarem erros, podem RSE utilizados durante tanto tempo e apresentados nas operações de pagamento, até o utilizador fizer uma outra opção de um meio de pagamento. Esta variante de pagamento corresponde a um processo de nota de débito, para o qual o cliente concede uma autorização de débito para a sua conta.

Também neste caso, tal como acima descrito para o pagamento com porta-moedas electrónico, pode prescindir-se tanto da certificação da informação da conta com também a operação de pagamento pode RSE realizada na comunicação directa entre o meio de pagamento e o dispositivo de cobrança.

Em ambas as variantes de pagamento é, antes da transferência do saldo disponível certificado ou da informação certificada da conta, controlado se o sistema de pagamento é aceite na generalidade pela aplicação da cobrança automática de taxas - o que tem como condição prévia um 46 ΕΡ Ο 780 801 /ΡΤ correspondente acordo contratual entre os fornecedores de serviço e os emitentes do meio de pagamento - e, em particular, se o meio de pagamento concreto está válido (controlo da data de validade e sinal de bloqueio) . No caso de domínios de segurança separados o controlo da aceitação e da validade bem como o débito ou a autorização de nota de débito é assegurado por um correspondente Keymanagement.

Numa forma de concretização do invento, particularmente preferida, o dispositivo de pagamento é configurado como On-Board-Equipment (OBE) para uma viatura, em particular, para um automóvel, compreendendo uma On-Board-Unit (OBU), a qual é comandada com um cartão microprocessador (ICC) do utilizador. O ICC é introduzido na OBU como meio de pagamento pago antecipadamente; A OBU retira da pastilha do ICC as informações, as quais o OBE necessita para a realização automática do processo de pagamento com o dispositivo de cobrança. A comunicação entre um ICC e uma OBU normalmente necessita mais tempo do que a comunicação entre a OBU e o dispositivo de cobrança, tipicamente de um dispositivo RSE. Tem portanto particular preferência, antes que se realize um processo de pagamento entre o dispositivo de pagamento e o dispositivo de cobrança, e até ainda antes que entre ambos se tenha estabelecido uma interface de comunicação, que seja carregado para a OBU um determinado saldo disponível sob forma de dados da aplicação do porta-moedas do ICC. Normalmente isto é provocado sempre quando o utilizador (e detentor do cartão) insere o seu ICC na OBU. Além disso um carregamento deste género normalmente está previsto quando o saldo disponível na OBU, devido a pagamentos já efectuados, tenha ultrapassado um determinado valor limite, pressuposto evidentemente que o ICC tenha sido inserido na OBU e apresentar ainda um suficiente saldo disponível.

Na comunicação entre o ICC e a OBU efectua-se por cada mensagem da OBU para o ICC (comando) uma mensagem do ICC para a OBU (resposta). A seguinte sequência de comandos descreve um processo de comunicação após a inserção do ICC no dispositivo de leitura de uma OBU: 47 ΕΡ Ο 780 801 /ΡΤ ATR Pelo comando Answer to Reset com a respectiva resposta são fornecidas informações técnicas quanto ao ICC e da disponibilidade de aplicações. SLA O comando Select Application selecciona a aplicação de porta-moedas do ICC através da OBU. A resposta contém as informações correspondentes à aplicação do porta-moedas. RIDL Por meio do comando Read ID/Limit pode RSE consultada a actual quantia monetária memorizada na aplicação do porta-moedas do ICC, para verificar se o ICC ainda dispõe de um saldo disponível suficiente. Numa forma de concretização do invento de particular preferência, a OBU ou o utilizador podem decidir que importância deverá efectivamente RSE carreqada do ICC para a OBU. Numa outra forma de concretização preferida, quando o débito for efectuado de forma autónoma (isto é sem comunicação externa) ou em comunicação directa com o dispositivo de cobrança, a informação pode RSE utilizada para em princípio verificar a possibilidade de utilização do meio de pagamento.

GC Antes que da aplicação do porta-moedas possa RSE retirada uma determinada importância devem RSE fornecidos, independentemente uns dos outros, dois números aleatórios, por um lado pelo ICC e por outro lado pela OBU ou pelo dispositivo de cobrança (RSE), os quais comprovam mutuamente a autorização do ICC e da OBU respectivamente do RSE para a transferência da importância monetária. Pelo comando e a resposta Get Challenqe o número aleatório gerido pelo ICC é enviado aos adjacentes. UA Pelo comando Update Amount é deduzida uma determinada quantia de dinheiro electrónico do ICC. Este comando e a sua resposta estão protegidos por um código secreto, o qual utiliza os dois números aleatórios, para evitar uma dedução não autorizada ou uma dedução repetida. Adicionalmente a

importância retirada pode RSE certificada pelo ICC 48 ΕΡ Ο 780 801 /ΡΤ com um segundo código, não conhecido pelo fornecedor de serviços, contudo do conhecimento do adquirente.

Numa forma de concretização, particularmente preferida, podem, depois de estar fornecido um saldo disponível certificado na OBU, RSE realizados eventualmente vários processos de pagamento entre a OBU e um ou vários dispositivos de cobrança, sem que o ICC esteja envolvido. Se já não forem necessárias nenhumas transacções e o ICC irá RSE retirado do dispositivo de leitura da OBU, um eventual saldo disponível ainda existente deve RSE novamente reconduzido para a aplicação de porta-moedas do ICC. Isto também deve realizar-se quando mais outro comando UA deverá RSE transmitido, para fornecer um novo saldo disponível; também neste caso uma importância restante do anterior saldo disponível deve em primeiro lugar RSE novamente carregada para o ICC, antes que um novo saldo disponível seja transferido para a OBU. PR Com comando Partial Reversal uma importância restante pode RSE reconduzida novamente da OBU para o ICC. Este comando também está protegido contra utilização abusiva por meio de um código de autenticação, o qual é gerido por meio de um código secreto e dois números aleatórios, os quais só são geridos directamente antes deste comando.

Em particular são para as sequências de comando e resposta na comunicação entre o ICC e a OBU utilizadas as seguintes mensagens, em que "Input" significa aqueles dados, os quais são transferidos pela mensagem de comando para o ICC, enquanto que "Output" significa aqueles dados, os quais são emitidos do ICC por meio de uma mensagem de resposta: ATR Nenhum Input

Output: card_data SLA Input: Nome da aplicação de porta-moedas; 49 ΕΡ Ο 780 801 /ΡΤ nenhum Output RIDL nenhum Output;

Output: id_prevu, contendo ICC/PREVU_ID, 8 (ou mais) Byte inteiro; importância, 2 (ou mais) Byte inteiro; GC nenhum Input;

Output: 4 ou 8 Byte número aleatório hexadecimal; UA Input: o respectivo comando compreende os objectos tipo, ID, TA_Counter, amount, random e macl.

Tipo é 1 Byte inteiro; ID é 4 Byte inteiro; TA_Counter é 2 Byte inteiro e amount é 2 (ou mais) Byte inteiros.

Random e macl são 4 ou 8 Byte números hexadecimais.

Output: a respectiva resposta compreende os objectos status, ICC/PREVU_ID, ICC_TA_counter, amount, mac2 e mac3.

Status é um 2 Byte número hexadecimal; ICC/PREVU_ID é 8 (ou mais) Byte inteiro. ICC_TA_counter e Amount são 2 (ou mais) Byte inteiros; mac2 e mac3 são 4 ou 8 Byte números hexadecimais. PR Input: o comando contém os objectos ID, TA_counter, amount1, macl, amount2, random e mac2. ID é 4 Byte inteiro. 50 ΕΡ Ο 780 801 /ΡΤ TA_counter, amountl e amount2 são 2 (ou mais) Byte inteiros; macl, random e mac2 são 4 ou 8 Byte números hexadecimais. A respectiva resposta (Output) compreende os objectos status e mac3. Status é 2 Byte número hexadecimal, mac3 um 8 Byte número hexadecimal.

Numa outra forma de concretização preferida do invento, quando por exemplo o fornecedor de serviços emitir ou seu próprio sistema de pagamento ou se existem exigências de tempo menos duras para o processo de pagamento, é possível que se estabeleça em relação à segurança criptográfica um comunicação directa entre o meio de pagamento, por exemplo na forma de um cartão microprocessador, e o dispositivo de cobrança. Nesta forma de concretização está excluída a necessidade de uma memorização dos dados e uma codificação no transponder, uma vez que este é utilizado essencialmente só para a conversão de protocolos de transmissão. Neste caso os acima descritos comandos UA e PR devem RSE substituídos por exemplo por SD (Secure Decrease: débito assegurado de uma taxa de cobrança automática da memória de saldos da aplicação de porta-moedas) e RF (Register Fee: confirmação definitiva da quitação positiva do pagamento e geração de um registo cronológico). SD Input: o comando compreende os objectos ID, tarifa, amount, random, macl. ID é 4 (ou mais) Byte inteiro; tarifa é 1 Byte inteiro; amount é 2 (ou mais) byte inteiro; random e macl são 4 ou 8 Byte números hexadecimais.

Output: a respectiva resposta compreende os objectos status e mac2.

Status é 2 Byte número hexadecimal; 51 ΕΡ Ο 780 801 /ΡΤ mac2 é 4 ou 8 Byte número hexadecimal. RF Input: o comando compreende os objectos, classe de veículo, número do recibo, amount, result, encMsg. classe de veículo é 1 Byte inteiro; número do recibo é 3 Byte número hexadecimal; amount é 2 (ou mais) Byte inteiro; result é 2 Byte número hexadecimal; encMsg é 8 ou 16 número hexadecimal, que contém um mac3 codificado, 4 ou 8 Byte hexadecimal.

Output: a respectiva resposta compreende os objectos status e mac4.

Status é 2 Byte hexadecimal; mac4 é 4 ou 8 Byte hexadecimal.

Interface de ar:

Para o apuramento e a cobrança automática de taxas é de distinguir se se trata de um sistema de cobrança automática de taxas aberto ou fechado.

No sistema aberto cada RSE permite o pagamento de taxas.

No sistema fechado o utente da estrada recebe primeiro um título de entrada, que deve RSE apresentado ao sair da zona e que forma a base para a facturação da taxa (por exemplo num auto-silo).

A cobrança de taxa através da interface de ar efectua-se no sistema aberto e na saída do sistema fechado nos seguintes cinco passos em princípio já acima descritos, para que os processos para o apuramento da taxa, para o pagamento e para a entrega do recibo em princípio possam RSE separados. A 52 ΕΡ Ο 780 801 /ΡΤ entrada para um sistema fechado efectua-se de acordo com os primeiros três dos seguintes passos. Para os conteúdos de protocolo em pormenor deve distinguir-se neste caso por parte do fornecedor de serviços entre um dispositivo de cobrança do tipo "RSE de pagamento" (sistema aberto e saída do sistema fechado), no qual é realizado um imediato pagamento da taxa e do tipo "RSE de entrada" (entrada num sistema fechado), o qual emite somente títulos de entrada. Por parte do cliente o pagamento efectua-se através de uma interface de comunicação, a qual é composta pela parte de transmissão do dispositivo de pagamento (parte integrante do On-Board-Equipment, OBE). T: Tender (correspondente: informação da proposta de prestação de serviço)

Quando da aproximação de um veículo o dispositivo de pagamento é em primeiro lugar abastecido pelo Road-Side-Equipment com a informação para os sistemas de pagamento (List of Acceptable Payments) aceites pelo fornecedor de serviços de cobrança automática de taxas e eventualmente com indicações para a funcionalidade, ao nível do posto de cobrança de taxas e ao fornecedor de serviços. A "List of Acceptable Payments" contém para cada sistema de pagamento regional ou supra-regional (isto é não aceites obrigatoriamente) um registo (Issuer Identification Number ou Registered Application Priver Identifier) de preferência estruturado conforme ISO 7816-5, se isto for aceite pelo fornecedor de serviços de cobrança automática de taxas.

Adicionalmente poderá RSE necessário que num RSE de pagamento sejam executadas mais outras consultas de status tipo booleano (List of Boolean Chalenges), por exemplo para interrogar a existência de um título de entrada ou de um sinal de bloqueio. No caso de um RSE de entrada é em vez disso emitido um número aleatório (RSE Random Challenge), para assegurar no seguinte que os títulos de entrada sejam somente 53 ΕΡ Ο 780 801 /ΡΤ distribuídos aos dispositivos de pagamento autênticos. R: Registration (correspondente: Declaração da intenção de compra e intenção de pagamento)

Através da recepção de uma mensagem T de um RSE de pagamento o dispositivo de pagamento é solicitado a transmitir ao RSE dados guanto ao tipo de veículo e condições especiais de pagamento (por exemplo tarifas para deficientes, assinatura de potenciais clientes, veículos automóveis para o transporte de altos dignitários etc.; Vehicle and Driver Dependent Class Table), quanto à situação de validade (Expire Date, mínimo do fim da validade da aplicação de cobrança automática de taxas e do meio de pagamento utilizado), pretensão de pagamento (Issuer Identifier e Reguested Currency), quanto às consultas status booleano (List of Boolean Responses) e - no sistema fechado - quanto à eventual existência de um título de entrada codificado do correspondente nível de serviço. Devido à codificação do título de entrada é evitada uma cópia sistemática do título de entrada por meio da interceptação no ponto da interface de ar. O título contém dados sobre a hora e o local da entrada e eventualmente outros dados anónimos de plausibilidade (por exemplo tipo de viatura, número do título), para que possa RSE verificada a legalidade da sua utilização.

Com a mensagem R ainda são transmitidos dados para o processo de codificação (por exemplo número de código de grupo), os quais no entanto ainda não permitem nenhuma identificação OBE. O protocolo completo para o pagamento de taxas é de acordo com o invento, particularmente preferido, visto que em primeiro lugar deve RSE efectuada a identificação RSE. Além disso para a autenticação RSE é transferido um número 54 ΕΡ Ο 780 801 /ΡΤ aleatório (ΟΒΕ Random Challenge). Na mensagem R é ainda transmitido também a data e hora do último pagamento, desde que o pagamento tenha sido feito no mesmo posto de pagamento (Beacon ID) .

No caso de um RSE de entrada o dispositivo de pagamento envia na mensagem R dados quanto à pretensão de pagamento, um número aleatório próprio (OBE Random Challenge), o qual é utilizado para a autenticação RSE que se segue, número de código de grupo bem como um autenticador para estes dados. PD/TT:Price Definition (correspondente: fixação do preço) respectivamente Ticket Transfer (correspondente: emissão de um titulo de entrada).

Se no actual RSE deverá ser feito um pagamento de taxas, o RSE pode, após verificação da validade da aplicação da cobrança automática de taxas respectivamente da aplicação do meio de pagamento (Expire Date) na base dos dados recebidos pelo dispositivo de pagamento em dependência do tipo de viatura, das condições especiais de pagamento, da data e hora do pagamento e de um eventual título de entrada, averiguar a actual importância da taxa (Fee), em que o valor da taxa deve ser independente do meio de pagamento, visto que o utilizador tem em principio uma livre opção da lista dos meios de pagamento aceites.

Em alternativa a isto (num sistema fechado) pode em vez da averiguação da taxa ser emitido um título de entrada, o qual pelos motivos acima mencionados é codificado pelo RSE, de modo que só poderá ser descodificado por um RSE do mesmo fornecedor de serviços. Com a transmissão do título podem 55 ΕΡ Ο 780 801 /ΡΤ adicionalmente também ser fixados determinados valores booleanos, como por exemplo instalar uma marcação num dispositivo de pagamento, de que a entrada num sistema fechado se tenha realizado. Registos não booleanos, por exemplo do tipo numérico, não devem por motivos de protecção de dados, poder ser efectuados num dispositivo de pagamento por um dispositivo de cobrança, para excluir sistemáticas marcações e seguimentos de assinantes. A taxa exigida pela cobrança automática ou o titulo de entrada codificado é, em conjunto com a identificação RSE, a data e a hora da cobrança da taxa, uma informação do status (Error Code), a tarifa aplicada e - no caso de um pagamento de taxa a seguir - mais outro número aleatório para a autenticação do OBE (RSE Random Challenge), enviada ao dispositivo de pagamento.

Para que o dispositivo de cobrança e o dispositivo de pagamento possam ser autenticados, a mensagem PD respectivamente TT ou - no caso de um RSE de pagamento -está equipada com um autenticador (Signature ou Message Authentication Code) ou - no caso de um RSE de entrada - parcialmente codificada, sendo em ambos os casos utilizado um "Sessionkey", o qual depende do número de uma chave de grupo e de números aleatórios. P: Payment (correspondente: execução do pagamento)

Depois da recepção de uma transferência do titulo (sistema fechado) é em primeiro lugar descodificada a mensagem e controlado o OBE Random Response, de modo que o RSE e com isto também o titulo de entrada codificado em caso positivo sejam considerados como 56 ΕΡ Ο 780 801 /ΡΤ autênticos. No caso de um RSE de entrada o processo está então concluído.

Após a recepção de uma definição de preço é em primeiro lugar verificado o autenticador e com isto o dispositivo de cobrança é autenticado pelo dispositivo de pagamento. Os dados de uma mensagem PD são memorizados como comprovativo da intenção de pagamento (Preliminary Receipt) até ao próximo pagamento, para que a tentativa de pagamento no caso de um processo de pagamento eventualmente fracassado possa ser justificada junto de um posto de controlo de cobrança automática de taxas.

Para a execução do processo de pagamento, a taxe de cobrança automática (Fee) e os dados relevantes para o pagamento (Issuer Identifier e Payment Object) são transmitidos ao RSE, sendo esta mensagem também provida de um campo de autenticação. Os conteúdos possíveis do objecto de pagamento dependem exclusivamente de acordos bilaterais entre o emitente e o fornecedor de serviços e são explicados mais abaixo. CR: Confirmation and Receipt (correspondente: fornecimento de um titulo de pagamento)

Após a recepção do Payment e da verificação do autenticador no RSE - se no Payment Object esteja contida a exacta identificação do meio de pagamento - pode ser realizada uma verificação de bloqueio para o meio de pagamento aplicado. Caso for verificado um sinal de bloqueio, pode por um lado numa informação status (Error Code) o dispositivo de pagamento ser informado para bloquear o meio de pagamento e por outro lado as informações obtidas no habitual decurso da 57 ΕΡ Ο 780 801 /ΡΤ transacção podem ser introduzidas directamente no Enforcement. A anotação de bloqueio pode permanecer na aplicação do OBE de cobrança automática de taxas, para rejeitar já no dispositivo de pagamento uma nova tentativa de pagamento com o meio de pagamento bloqueado. O meio de pagamento pode adicionalmente, por exemplo no caso de um cartão inteligente, ser provocado para um auto-bloqueio.

Em caso contrário é ao dispositivo de pagamento passado recibo pelo pagamento efectuado e transferido ao dispositivo de pagamento um recibo Enforcement provido de um autenticador bem como eventualmente valores booleanos (por exemplo para a reposição da marcação de um titulo de entrada). Esta mensagem está para a protecção contra ataques de interceptação parcialmente codificada com o acima mencionado Sessionkey. O recibo contém todos os dados importantes para o controlo da cobrança automática de taxas (Enforcement), tais como RSE-ID, data e hora, número do recibo, indicações do tipo de viatura, taxa de cobrança automática etc. O autenticador do recibo de Enforcement é gerado com um código desconhecido do dispositivo de pagamento.

Após a recepção e verificação da mensagem CR o recibo é arquivado na memória de transacções no OBE de modo que respectivamente o ultimo recibo de um nivel de serviço com o seu autenticador também pode ser utilizado como comprovativo de pagamento perante um posto de controlo de cobrança automática de taxas. 58 ΕΡ Ο 780 801 /ΡΤ

Payment Object Ο objecto contido na mensagem P é geralmente composto pelas quatro seguintes partes de informação, as quais no entanto poderão não estar ocupadas do mesmo modo para todos os tipos de pagamento. TR Transaction Related Data, por exemplo, saldo disponível ou montante da taxa, data ou contador de sequências de prestações de serviços: PAY Payment System Related Data, por exemplo indicativo do responsável pelo pagamento, conta para nota de débito ou conta de compensação; ID Identity Related Data, por exemplo meio de pagamento ID; SEC Security Related Data, por exemplo parâmetros de codificação e autenticador.

Os conteúdos possíveis do Payment Object são indicados a seguir para três exemplos de pagamento. • Cartão de valor declarado de pagamento antecipado, específico para transportes, anónimo: 9TR Taxa Eventualmente contador de débitos ou Saldo Pay Eventualmente conta de compensação ID Número de cartão de valor declarado (grupos) SEC - 59 ΕΡ Ο 780 801 /ΡΤ

Observações: Ο campo de dados TR pode conter além da própria taxa de cobrança automática por exemplo um contador de débitos ou o saldo existente no cartão de valor declarado, para facilitar a distinção dos processos individuais e eventuais controlos de segurança. É pensável que cartões de valor declarado em dependência da emissão e/ou data de caducidade sejam compensados em contas diferentes. Isto pode ser explicito através da indicação de uma conta no campo de dados PAY, a qual no âmbito do débito é verificada no cartão de valor declarado ou implícito através do número do cartão de valor declarado (grupos).

Parâmetros de segurança adicionais não são necessários no caso de um meio de pagamento especifico de transporte, anónimo, de modo que para este fim também não é necessária nenhuma identificação de cartão individual. • Porta-moedas universal de institutos financeiros: TR Saldo disponível, Contador de sequências Terminal-ID Pay Conta de compensação do porta-moedas ID Número do porta-moedas SEC Message Authentication Code (MAC)

Observações:

Visto que a comunicação com o cartão inteligente do porta-moedas devido aos aperfeiçoados procedimentos de segurança ser muito complexa quanto ao tempo, o 60 ΕΡ Ο 780 801 /ΡΤ porta-moedas universal pode, como meio de pagamento num campo periférico da cobrança automática de taxas, eventualmente ser utilizado somente por meio de um débito antecipado de um saldo disponível. Quanto ao significado do saldo disponível no campo de dados TR chama-se a atenção para a Observação anterior referente ao tipo de pagamento "pagamento com porta-moedas".

Os outros dados previstos no campo de dados TR são incluídos pelo porta-moedas universal na formação MAC, a qual salvaguarda de modo criptográf ico o processo de débito do porta-moedas, e não necessitando portanto de serem transferidos para aquele ponto da operação de pagamento (isto é ao adquirente competente), que verifica o MAC. • Processo de nota de débito: TR Contador de sequências e/ou data, hora Pay Código indicativo do banco (NIB) e número da conta bancária ID Eventualmente número do cartão inteligente SEC Message Authentication Code ou assinatura electrónica

Observações: O pagamento efectua-se posteriormente através de débito de uma conta de débito ou crédito, indicada no campo de dados PAY. Através do campo de dados TR é neste caso comandado se cada um dos débitos de taxas na cobrança automática de taxas é autorizado pelo utilizador ou se a autorização de débito é concedida em determinados períodos de tempo (por exemplo uma vez no início da viagem ou diariamente). A concessão da autorização de débito deve ser à prova de falsificação e verificável e exige portanto a geração de uma Message Authentication Code ou de 61 ΕΡ Ο 780 801 /ΡΤ uma assinatura electrónica, podendo o respectivo código ser atribuído ou através da identificação da conta ou do cartão inteligente como suporte de meio pagamento.

Numa outra forma de concretização de acordo com o invento a averiguação da taxa, nomeadamente conforme um exemplo de concretização da reivindicação 1 do invento, pode ser realizada sem (isto é de forma autónoma) ou por meio de comunicação do dispositivo de pagamento por parte do utilizador e um outro emissor/receptor por exemplo via rádio celular (por exemplo GSM - Global System for Mobile Telecommunications), sendo o emissor/receptor, como assim denominada caixa virtual, atribuída a um ou vários locais fixos de cobrança de taxas. Em ambas as variantes a actuação de um pagamento de taxas realiza-se através de um GNSS (Global Navigation Satellite System, por exemplo GPS - Global Positioning System). Todo o processo pode neste caso também ser realizado pelos cinco passos análogos acima descritos.

Num sistema deste género o receptor GPS fornece ao dispositivo de pagamento constantemente dados referentes à posição geográfica da viatura. Estes são comparados com um mapa digital, onde estão assinaladas caixas virtuais. Estes dados de mapas estão memorizados no dispositivo de pagamento. Se for verificada uma concordância, isto é, a viatura se encontrar numa estrada sujeita a taxas, a taxa de utilização da estrada apurada através de uma tabela de tarifas ou um algoritmo de tarifas é registada no dispositivo de pagamento. Conforme o sistema de pagamento aplicado e o equipamento técnico e do apetrechamento da viatura, esta taxa pode por exemplo ser debitada directamente no cartão inteligente sem qualquer outra comunicação externa (sistema autónomo). Em alternativa, após um determinado número destas operações de pagamento ou quando for atingida uma determinada posição geográfica ou quando for passada uma "baliza de detecção", é realizada uma comunicação através de GSM ou DSCR para a transmissão dos dados de débito entretanto reunidos. Para sistemas próprios para GSM a actualização de tabelas de tarifas bem como o recarregamento de um meio de pagamento pré-pago pode ser realizado através do telemóvel. 62 ΕΡ Ο 780 801 /ΡΤ

Tanto no caso da cobrança de taxas baseada em micro-ondas bem como também no caso de uma cobrança de taxas através de outras técnicas de transmissão, os cinco passos da cobrança de taxas podem ser realizados por meio de uma comunicação tipo comando (Master-Slave em vez de Peer-to-Peer) entre o dispositivo de cobrança e o dispositivo de pagamento. No respectivo passo o dispositivo de cobrança emite neste caso um ou vários comandos ao dispositivo de pagamento, os quais são processados por este e respondendo com os dados solicitados para a transmissão do passo seguinte. Assim podem ser considerados facilmente requisitos especiais ou adicionais no sistema total.

Preparação dos dados relevantes para o pagamento

Os dados de transacção reunidos no dispositivo de cobrança são periodicamente preparados para a transmissão ao concentrador do fornecedor de serviços. Isto sucede na forma de um ficheiro de transacção protegido de modo criptográfico com número de versão, carimbo da data e identificação RSE, para que no concentrador possa ser verificada a autenticidade e a unicidade da apresentação.

Como processo de transmissão há em principio duas possibilidades: transmissão em tempo real de acordo com um protocolo de comunicação, por exemplo na base da "especificação da interface para o Clearing entre os participantes" do sistema de cobrança automática de taxas (esquema normalizado do CEN/TC 278), ou intercâmbio de suportes de dados por exemplo utilizando uma disquete ou um cartão inteligente de memória para estes dispositivos de cobrança, os quais não estão ligados à rede de comunicações.

No concentrador os ficheiros de transacções recebidos ou chamados, são então controlados se estes não foram manipulados durante a transmissão, se estes foram gerados pelo remetente (RSE) correcto e se os mesmos - em caso de erro - não tenham já sido enviados. 63 ΕΡ Ο 780 801 /ΡΤ

Para meios de pagamento universais, isto é não específicos para transporte, efectua-se, numa forma de concretização do invento, particularmente preferida, no espaço de tempo do débito (por exemplo em todos os dias úteis) uma classificação de todas as transacções individuais referentes às identidades dos meios de pagamento, de modo que todos os pagamentos de taxas efectuados, os quais ou no caso de um meio de pagamento pré-pago referente ao mesmo saldo disponível certificado ou no caso de um meio de pagamento pago posteriormente referente à mesma identificação de conta certificada, possam ser somados e serem processados como crédito global.

Os dados relevantes para o pagamento, os quais então são encaminhados ao respectivo adquirente, contêm - a não ser que o cliente pretenda isto expressamente para a elaboração de um comprovativo de taxas individuais - nenhum dado sobre o número, o montante e local do termo de pagamento das taxas individuais somadas. Estes dados são preparados para a transmissão a um adquirente na forma de um ficheiro de crédito protegido de modo criptográfico, com número de versão, carimbo da data e identificação do apresentador (fornecedor de serviços), para que o adquirente possa controlar a autenticidade e unicidade da apresentação.

Para meios de pagamento anónimos, específicos para transportes ou fornecedores de serviços, pode efectuar-se no RSE já uma classificação prévia e uma agregação de modo que somente as somas das taxas devem ser transmitidas ao computador central do operado de serviços. A estrutura de dados para a interface entre o RSE e o receptor de dados, normalmente um computador central do fornecedor de serviços de acordo com o invento, é escolhido de tal modo que esta também pode ser aplicada para o processamento no adquirente e no emitente. A estrutura para as unidades de dados do protocolo (Protocol data units, PDU) é representada no diagrama a 64 ΕΡ Ο 780 801 /ΡΤ seguir, podendo em princípio também serem integrados outros PDUs, como por exemplo conforme ISO 8583, EDIFACT.

Descrição dos elementos de dados:

Message_Header: Todas as mensagens de dados deveriam pertencer a uma das seis diferentes classes de mensagens (message classes). A respectiva Message_Class adequada para os Transaction_Files e para Fee_Claim-Files são Advice e Advice Response.

Message_Class: Todas as mensagens de dados deverão pertencer a uma de seis diferentes classes de mensagens (message classes). a respectiva Message_Class adequada para os Transactions_Files e para os Fee_Claims_Files são Advice e Advice Response.

Message_Type: Sinaliza a escolha de um determinado tipo de mensagem. No sistema de acordo com o invento trata-se no Message_Type do tipo de mensagem Transaction.

Sender_lD, Receiver_lD: Dentro do sistema a identidade do emissor e do receptor deve ser fixada inequivocamente. De 65 ΕΡ Ο 780 801 /ΡΤ acordo com ο invento trata-se de um número 4 Byte.

Message_ID: O identificador de mensagens,

Message_Identifier identifica em conjunto com o Sender_lD e o Receiver_ID uma determinada mensagem existente e é determinado pelo próprio remetente da mensagem com um número 4 Byte. A resposta do destinatário da mensagem deve conter a mesma indicação de

Message_Identifier.

Message_Body: Message_Body é uma sequência de

Data_Objects de diferentes tipos como é definido mais abaixo. Os Data_Objects contêm os "Automatic Fee Collection" (AFC) válidos e os dados de transacção relacionados com a operação de transacção. Em geral o Data-Object refere-se a uma operação de transacção, recebida pela OBU.

Os elementos de dados das Message_Header, Message_Class e Message_Type são todas números 1 Byte. A transmissão de objectos de pagamento do RSE para o computador central do fornecedor de serviços efectua-se por meio de por assim denominados Transaction_Files. Um Transaction_File compreende um Header_Record e os efectivos Transaction_Records positivos ou negativos e define portanto diferentes tipos de Data_Objects. O Transaction_File é transmitido como uma mensagem da classe Advice, a qual no seu Message_Body contém um único Data_Object do tipo 1, ao qual se segue uma sequência de Data_Objects do tipo 2, 3, ou 4.

Um tipo de objecto adicional está reservado para o tipo de mensagem Advice Response, com a qual é confirmada a recepção de um Transaction_File.

Parte-se do principio de que uma chamada da transmissão de um Transaction-File se efectua através do computador central num baixo nivel de protocolo, por exemplo dentro de 66 ΕΡ Ο 780 801 /ΡΤ um File_Transfer_Protocol, de modo que para este efeito não estão previstas mensagens especiais. Neste sentido a transmissão de Transaction_Files é sempre iniciada por um computador RSE. O Data_Object do tipo 1 compreende a Header Information para o Transaction_File, emitida pelo computador RSE, nomeadamente de um computador central. A estrutura dos Data_Objects do tipo 1 é mostrada no diagrama 6

Este Object_Type é composto pelos seguintes elementos de dados: TA_Number: Este elemento de dados contém a quantidade de Transaction-Records no Transaction_File e determina portanto a quantidade de Data-Objects dos tipos 2, 3 e 4 na mensagem.

Fee_Sum: O elemento de dados Fee_Sum contém a soma de todas as taxas, as quais estão contidas no respectivo elemento de dados Data_Objects (tipo 2 ou 3) do Transaction_Records. MAC: Este elemento de dados contém um código de autenticação da mensagem (Message Authentication Code).

Os elementos de dados TA_Number e Fee_Sum são ambos números 4 Byte. MAC é um número hexadecimal 8 Byte. O Data_Object do tipo 2 contém um Transaction-Record de pré-pagamento positivo do Transaction_File, que deve ser 67 ΕΡ Ο 780 801 /ΡΤ enviado do computador RSE para o computador central. Positivo significa que a transacção entre a RSE e a OBU foi concluída regularmente, isto é o pagamento foi efectuado. A estrutura do Data_Object do tipo 2 é mostrada no diagrama 7.

Diagrama 7

Este tipo de Data-Object é composto pelos seguintes elementos de dados: TA_ID: Este elemento de dados serve para a numeração contínua dos Transaction_Records do Transaction_File. O elemento de dados TA_ID é um número 4 Byte.

Issuer_ID: Este número 4 Byte identifica o emitente do meio de pagamento, o qual foi utilizado para o pagamento da taxa e transmitido com a mensagem de pagamento. PO: Este elemento de dados (Payment_Object) contém dados individuais relevantes do pagamento para o sistema de pré-pagamento pago antecipadamente. Este é por exemplo uma informação 20 Byte, a qual assinala o carregamento prévio de um saldo disponível do cartão inteligente para a OBU. Este contém de preferência os seguintes quatro elementos: ICC/PREVU ID: Identificação da aplicação do porta-moedas no cartão inteligente, do qual 68 ΕΡ Ο 780 801 /ΡΤ ο saldo disponível foi carregado para a OBU (número 4 Byte) . ICC_TA_Counter: Contador de transacções, determinado pelo cartão inteligente (número 2 Byte).

Amount: O saldo disponível carregado do cartão inteligente para a OBU (número 2 Byte). MAC: Código de autenticação da mensagem produzido pelo cartão inteligente, o qual certifica a autenticidade da quantia carregada (número hexadecimal 8 Byte).

Fee: Este elemento de dados contém a taxa exigida para a viatura que passou o posto de pagamento, e a qual foi deduzida do saldo disponível na OBU. O elemento de dados da Fee é um número 2 Byte. MAC: Este elemento de dados com 8 Byte de comprimento contém um código de autenticação da mensagem. O Data-Object do tipo 3 contém um registo de transacção de pós-pagamento (Post Payment Transaction Record), do ficheiro de transacção, a ser enviado do computador RSE para o computador central. Positivo significa que a transacção entre o RSE e a OBU pode ser concluída como estava previsto, isto é, efectuou-se o pagamento. O diagrama 8 mostra a estrutura do Data_Object do tipo 3. 69 ΕΡ Ο 780 801 /ΡΤ

Diagrama 8

Este tipo de Data_Object é composto pelos seguintes elementos de dados: TA_ID: Este elemento de dados tem o mesmo significado como no diagrama 7. lssuer_lD: Este elemento de dados tem o mesmo significado como no diagrama 7. PO: O Payment_Object contém dados para o sistema de pagamento pago posteriormente. O elemento de dados do PO é por exemplo uma informação 18 Byte, a qual se refere por exemplo ao Post-Payment Account memorizado na OBU. É composto de preferência por três elementos. OBU/Account ID: Identification do Post

Payment Account (número 8 Byte). PP_Sel_Counter: Este contador é aumentado sempre quando o condutor da viatura decide um pós-pagamento, quando este executar um correspondente função de selecção da OBU. Este valor é portanto geralmente constante para todas as transacções OBU/RSE durante uma viagem. MAC: O código de autenticação da mensagem gerado pela OBU, o qual confirma a autenticidade da identificação da conta.

Fee: Este elemento de dados contém a taxa exigida a uma viatura ao passar pelo posto 70 ΕΡ Ο 780 801 /ΡΤ de pagamento. Ο elemento de dados é um número 2 Byte. MAC: Este elemento de dados de 8 Byte de comprimento contém um código de autenticação de mensagem. O Data_Object do tipo 4 contém informações sobre transacções negativas. Uma transacção é considerada negativa, quando de uma viatura ao passar o posto de pagamento não se efectua o pagamento. Neste caso poderia ser provocado um Enforcement. Este Data-Object tem a estrutura indicada no diagrama 9.

Este tipo de um Data_Object é composto pelos seguintes elementos de dados: TA_ID: Este elemento de dados tem o mesmo significado como o dos diagramas anteriores.

Error_ID: O elemento Error_lD contém informações específicas referentes ao tipo de erro que tenha surgido e portanto relativo à causa para um eventual Enforcement. É um número 2 Byte.

Error_Data: Este elemento de dados de comprimento variável contém informações específicas relativas ao erro que efectivamente surgiu. 71 ΕΡ Ο 780 801 /ΡΤ MAC: Este elemento de dados 8 Byte de comprimento contém um código de autenticação da mensagem. O Data_Object do tipo 5 contém informações, as quais são transferidas nas mensagens da classe Advice Response do computador central de volta para o RSE. Este mostra ou uma transmissão e um controlo bem sucedidos do ficheiro transmitido, ou dá informações especiais no caso de um erro. Uma mensagem da classe Advance Response pode conter um ou vários Data_Objects deste tipo. A estrutura de um Data-Object do tipo 5 é mostrada no diagrama 10.

Diagrama 10

Este tipo de data-Object é composto pelos seguintes elementos de dados:

Response_Code: Este elemento de dados contém um número 2 Byte, que indica a exactidão ou a inexactidão da transmissão. No caso de um erro o Response_Code define o tipo de erro.

Reference: Este elemento de dados contém um número 4 Byte e pode referir-se ou a um elemento de dados do PDU, ou a um Data_Object, ou a um elemento do Data_Object no Message_Body onde foi encontrado o erro. MAC:

Este elemento de dados com 8 Byte de comprimento contém um código de autenticação da mensagem. 72 ΕΡ Ο 780 801 /ΡΤ

Uma mensagem da classe Advice do tipo acima definido contém exactamente um Transaction_File. Diferentes Transaction-Files devem ser transmitidos por meio de diferentes mensagens. Quando existir uma delimitação quanto ao comprimento de uma mensagem, o Transaction_File deve ser fechado logo que tenha ocorrido um determinado número de Transaction-Records.

Na forma de concretização exemplificada está para a protecção da transmissão previsto um Transaction_File, para a autenticação dos Data_Objects e para a autenticação do Payment_Object a utilização de códigos de autenticação de mensagens (MAC) os quais são produzidos por meio de um algoritmo de codificação simétrico, como por exemplo o DEA (Data Encryption Algorithm) ou do IDEA (Inter national Data Encryption Algorithm). Um algoritmo de codificação simétrico distingue-se pelo facto de que tanto o emissor como também o receptor para a transmissão confidencial e/ou de integridade protegida deverão dispor do mesmo segredo (chave) criptográfico.

Em determinados casos pode no entanto ser necessário utilizar em vez disso um algoritmo de codificação assimétrico, quando por exemplo forem aplicadas assinaturas digitais, ou quando o Keymanagement pode por este meio ser simplificado. Na utilização de algoritmos de codificação assimétricos ambos os parceiros de comunicação dispõem de diferentes partes da chave, contudo estando em rigoroso contexto matemático entre si, das quais só uma deverá permanecer secreta (a chave que gera a assinatura) podendo a outra ser pública (a chave de controlo da assinatura) . Neste caso contudo a chave pública de um participante deve estar assinada (certificada) por uma instância independente, como acima já foi explicado em relação à instância de certificação. Estes certificados de chaves podem então ser arquivados num indice público (por exemplo X.500 Directory). Não obstante à descrição da aplicação da técnica MAC, as concretizações, em particular, quanto às estruturas exemplificadas dos dados, devem ser entendidas de tal modo que o respectivo campo MAC funciona como curinga para quaisquer estruturas de segurança inclusive informações 73 ΕΡ Ο 780 801 /ΡΤ adicionais relacionadas com a segurança, tais como o identificador do algoritmo, o tipo e número de chave, modo de aplicação para o algoritmo de codificação e outros mais. Esta observação aplica-se também para todas as estruturas de dados que ainda serão descritas mais abaixo.

Concentrador <-> adquirente <-> emitente

Os dados relevantes para o pagamento processados na forma de um ficheiro de crédito (Fee Claim File) são aceites pelos respectivos adquirentes em linha conforme o mesmo protocolo de comunicação, o qual também está previsto para a transmissão em tempo real entre RSE e concentrador de um fornecedor de serviços, visto que nesta interface se encontram diferentes domínios de segurança, a transmissão destes dados está protegida por chaves próprias, que unicamente para este efeito devem ser determinadas entre o fornecedor de serviços e o adquirente.

Se os controlos de autenticidade e unicidade respectivamente a novidade dos dados de crédito apresentados forem realizados com um resultado positivo, é com base nos acordos contratuais entre o fornecedor de serviços e o adquirente que entra em vigor a garantia de pagamento. Os controlos incluem também a autenticação dos meios de pagamento aplicados, quando para uma operação de pagamento forem verificados os saldos disponíveis certificados respectivamente as informações sobre a conta. Devido à separação dos domínios de segurança entre meio de pagamento e aplicação da cobrança automática de taxas, os certificados não podem ser verificados imediatamente pela aplicação da OBU respectivamente RSE de cobrança automática da taxa quando da operação de pagamento mas sim somente após a apresentação do ficheiro de crédito ao adquirente, o qual na sua função de fornecedor de serviços perante o emitente dispões das respectivas chaves.

Quanto à sua estrutura, as mensagens e os dados na interface entre o fornecedor de serviços e o local de pagamento são semelhantes àquelas que anteriormente já foram descritas para a interface entre o RSE e o fornecedor de serviços respectivamente o CC. 74 ΕΡ Ο 780 801 /ΡΤ

Por exemplo diariamente ο fornecedor de serviços manda ao adquirente uma mensagem da classe Advice a qual contém um assim denominado Fee_Claim_File. Este ficheiro é composto por um Header_Record, o qual é determinado por um Data-Object do tipo 6 e os Fee_Claims efectivos, isto é os processos de taxas representados por Data-Objects do tipo 7 ou 8. A transmissão correcta ou incorrecta é confirmada pelo adquirente por meio de uma mensagem da classe Advice Response, e esta mensagem contém um ou vários Data_Objects do tipo 5 acima definidos.

Os Data_Objects dos tipos 6, 7 e 8 são definidos pelas seguintes estruturas e conteúdos: O Data_Object do tipo 6 contém a informação inicial (Header Information) para o Fee Claim File, enviada pelo fornecedor de serviços respectivamente do seu computador central ao adquirente. O diagrama 11 mostra a estrutura do

Data_Objects do tipo 6.

Diagrama 11

Este tipo de Data_Object é composto pelos seguintes elementos de dados: FC_Number: Este elemento de dados contém a quantidade dos Fee_Claim_Records relacionados com o pré- e pós-pagamento no Fee Claim File e determina portanto a quantidade de Data_Objects do tipo 7 e 8 na mensagem.

Fee_Total_Sum: O elemento de dados Fee_Total_Sum contém a soma de todas as quantias de 75 ΕΡ Ο 780 801 /ΡΤ taxas que estão contidas no respectivo elemento de dados da Fee Claim Record Data Objects do tipo 7 ou 8. SP_Account: O número da conta (Account Number) do fornecedor de serviços para a nota de crédito da quantia do Fee_Total_Sum. MAC: Este elemento de dados contém o código de autenticação da mensagem (Message Authentication Code).

Os elementos de dados FC_Number e Fee_Total_Sum são ambos números 4 Byte. O elemento de dados SP_Account é um número 10 Byte MAC é um número 8 Byte hexadecimal. O Data_Object do tipo 7 contém um Fee_Claim_Record do Fee Claim File relacionado com o pré-pagamento, que é enviado do fornecedor de serviços para o adquirente. A estrutura do Data_Object do tipo 7 é mostrada no diagrama 12.

Diagrama 12

Este tipo de Data_Object é composto pelos seguintes elementos de dados: FC_ID: Este elemento de dados conta continuamente os Fee_Claim:Records do Fee Claim File. O elemento de dados FC_ID é um número de 4 Byte. PO: Este elemento de dados é por exemplo uma informação de 20 Byte, 76 ΕΡ Ο 780 801 /ΡΤ correspondente à definição no diagrama 7, referente ao Data_Object do tipo 2.

Fee_Total: Este elemento de dados contém a quantia total de todas as taxas individuais as quais foram deduzidas referentes ao mesmo Payment Object do saldo disponível numa OBU. O Fee_Total Data Element é um número de 2 Byte. MAC: Este Elemento de dados de 8 Byte de comprimento contém um código de autenticação da mensagem (Message Authentication Code). O Data_Object do tipo 8 contém um Fee_Claim_Record do Fee Claim File relacionado com o pós-pagamento a ser enviado do fornecedor de serviços ao adquirente. A estrutura do Data_Object do tipo 8 é mostrado no diagrama 13.

Este tipo de Data_Object é composto pelos seguintes elementos de dados: FC_ID: Este elemento de dados tem o mesmo significado como o Data_Object do tipo 7, no diagrama 12. PO: Este elemento de dados é por exemplo uma informação de 18 Byte 77 ΕΡ Ο 780 801 /ΡΤ 77 ΕΡ Ο 780 801 /ΡΤ no correspondente à definição Data_Object do tipo 3, diagrama 8.

Fee Total: MAC:

Este elemento de dados contém a soma total de todas as taxas que foram deduzidas numa OBU referente ao mesmo PO. O elemento de dados Fee_Total é um número de 2 Byte.

Este elemento de dados de 8 Byte de comprimento contém um código de autenticação da mensagem (Message Authentication Code).

Todos os processos implicitos com a garantia de pagamento, para produzir notas de crédito para fornecedores de serviços e notas de débito para emitentes, são no trânsito bancário nacional e internacional operações habituais nas operações de pagamento, não necessitando portanto neste contexto de explicações pormenorizadas. É contudo pressuposto que o encaminhamento das informações relevantes para a compensação de pagamentos para notas de crédito e débito se efectua de acordo com o método de intercâmbio de suportes de dados habitual no sector de serviços de crédito alemão (DTA-Verfahren).

Além do intercâmbio de dados relevante para o sistema de pagamentos entre adquirentes e emitentes, no caso da aplicação de meios de pagamento pré-pagos poderá ser necessário fornecer dados referentes a processos de carregamento e descarregamento para o controlo da segurança do sistema (relativo ao sistema de pagamento). De forma análoga para a organização destas tarefas para o porta-moedas universal de institutos financeiros está previsto de acordo com o invento que este controlo seja realizado pelo emitente.

Para este efeito o emitente mantém para cada correspondente meio de pagamento um saldo simulado, o qual resulta da compensação de quantias carregadas em relação a quantias pagas. As quantias carregadas devem então pelas agências ou pelos terminais de carregamento ser participadas ao emitente na forma de assim denominados avisos de 78 ΕΡ Ο 780 801 /ΡΤ carregamento. As quantias de pagamento a serem compensadas são apuradas no processamento dos Fee Claim Files acima descrito e encaminhadas para o emitente. O saldo simulado é exactamente atribuído ao um meio de pagamento concreto, contudo não revela nenhuma relação a pessoas, visto que os meios de pagamento ID não são relacionados às pessoas. Geralmente o saldo simulado é sempre positivo, e excepções temporais só são possíveis quando os avisos de carregamento forem processados com atraso em relação à transacção de pagamento. Saldos simulados negativos duradouros deixam prever um ataque considerado grave a todo o sistema de pagamento pago antecipadamente.

De acordo com o invento os avisos de carregamento são enviados num Load_File ao emitente. Este ficheiro é composto por um Header_Record, que determina um Data_Object do tipo 9, e os Load_Records propriamente ditos, isto é as quantias individuais de carregamento e descarregamento, representadas por Data_Objects do tipo 10 e 11. O Data_Object do tipo 9 é quanto à estrutura idêntico ao Data_Object do tipo 6 e contém a Header Information para o Load_File.

Este tipo de Data_Object é composto pelos seguintes elementos de dados: LR_Number: Este elemento de dados contém uma quantidade de Load_Records do Load_File e fixa portanto a quantidade de Data_Objects do tipo 10 e 11.

Load_Sum: Este elemento de dados corresponde à soma de todas as quantias carregadas e 79 ΕΡ Ο 780 801 /ΡΤ descarregadas, contidas nos Load_Records seguintes referentes aos respectivos meios de pagamento. PP_Account: Uma pluralidade de meios de pagamento pré-pagos (por exemplo porta-moedas electrónicos) é em geral atribuída a uma única conta comum, na qual são debitadas as quantias de pagamento realizadas com os respectivos meios de pagamento, a serem apresentadas por fornecedores de serviços ao adquirente para a nota de crédito. MAC: Este elemento de dados contém um código de autenticação da mensagem (Message Authentication Code).

Os elementos de dados LR_Number e Load_Sum são números 4 Byte. O elemento de dados PP_Account é um número 10 Byte. O MAC é um número hexadecimal 8 Byte. O Data_object do tipo 10 contém um Load_Record do Load_File sobre um processo de carregamento (por exemplo para o carregamento de um porta-moedas electrónico), que é transmitido ao emitente.

Diagrama 15

Este tipo de Data_Object é composto pelos seguintes elementos de dados: 80 ΕΡ Ο 780 801 /ΡΤ LR_ID: Este elemento de dados faz a contagem contínua dos Load_Records do Load_File e é um número 4 Byte.

Payment_Object: Este elemento de dados é por exemplo uma informação 20 Byte, que indica o saldo disponível de um meio de pagamento pré-pago. Quanto ao seu conteúdo pode ser composto pelos mesmos quatro elementos, definidos para o processo de pagamento através da interface de ar respectivamente a introdução na operação de pagamento para o Data_Object do tipo 2. MAC: Este elemento de dados contém um código de autenticação da mensagem (Message Authentication Code).

Operações de descarregamento, isto é o descarregamento de meios de pagamento pré-pagos, são informadas pelos Data_Objects do tipo 11, estruturalmente idênticos aos Data_Objects do tipo 10.

Emitente <-> instância de carregamento/agência de venda ^meio de pagamento / On-Board-Equipment

As interfaces que são fixadas neste contexto referem-se primariamente à comercialização de meios de pagamento e On-Board-Units, o carregamento e descarregamento de meios de pagamento pré-pagos e as inerentes relações com os clientes, não sendo portanto aqui elucidadas em pormenor. É no entanto de referir que, quando da utilização de cartões inteligentes multifuncionais como meios de suporte para o meio de pagamento e/ou aplicações de cobranças automáticas de taxas, devem ser reproduzidas as dependências técnicas já referidas entre os diferentes emitentes de cartões e aplicações e as inerentes medidas técnicas de segurança também quanto às relações legais/de organização. 81 ΕΡ Ο 780 801 /ΡΤ

As estruturas das mensagens e objectos de dados transmitidas nesta interface correspondem essencialmente ao já anteriormente descrito.

On-Board-Equipment <-> Posto de controlo da cobrança automática de taxas A verificação da existência de uma prova de pagamento num On-Board-Equipment por um posto de controlo da cobrança automática de taxas móvel ou estacionário, numa forma de concretização especialmente preferida do invento efectua-se em grande parte de forma análoga à operação de pagamento propriamente dita com os passos de protocolo já definidos: T Tender

Em primeiro lugar um dispositivo de pagamento (OBE) é abastecido com dados quanto à funcionalidade do posto de controlo da cobrança automática de taxas e para o fornecedor de serviços (Beacon Service Table) associado. Também aqui, semelhante ao caso de um RSE de pagamento, são possíveis consultas da situação (List of Boolean Challenges). R Registration

Antes do OBE apresentar a sua prova de pagamento, deve por motivos da protecção de dados ser verificada a autenticidade do posto de controlo da cobrança automática de taxas. Para este efeito é gerado um número aleatório (OBE

Random Challenge), e em conjunto com o número da chave de grupo bem como uma indicação sobre o sistema de pagamento utilizado para o último pagamento (do respectivo nível de serviço), enviado ao posto de controlo da cobrança automática de taxas. Neste caso podem igualmente ser transmitidas respostas (List of Boolen Responses) para as consultas booleanas.

RQ

Receipt Request 82 ΕΡ Ο 780 801 /ΡΤ

Para que ο posto de controlo da cobrança automática de taxas possa ser autenticado pelo OBE, são enviadas ao OBE a identificação RSE, a data e a hora de controlo. Esta mensagem está provida de um autenticador, o qual, como já foi descrito, depende de uma "Sessionkey". Neste caso para uma autenticação posterior do OBE é enviado em conjunto mais outro número aleatório (RSE Random Challenge) . RP Receipt Presentation

Após a recepção da mensagem RQ é em primeiro lugar autenticado pelo OBE o posto de controlo da cobrança automática de taxas, quando for verificado o autenticador. A seguir numa mensagem autenticada é, ou (no caso de um sistema fechado) apresentado o último título de entrada codificado recebido do respectivo nível de serviço ou (num sistema aberto) comprovado o último pagamento efectuado (recibo Enforcement, sem codificação) respectivamente, no caso de um pagamento falhado, a última tentativa de pagamento (Preliminary Ticket). RC Receipt Confirmation

Após a recepção e o controlo do Receipt

Presentation o posto de controlo da cobrança automática de taxas sinaliza ao OBE numa mensagem codificada o resultado do seu controlo. No caso de um controlo negativo os dados verificados podem pelo posto de controlo da cobrança automática de taxas ser então directamente processados respectivamente encaminhados como medida conservatória da prova e um pagamento posterior da taxa. Opcionalmente com a mensagem (codificada) podem ser transmitidas marcações booleanas.

Em princípio também o posto de controlo da cobrança automática de taxas poderia além disso 83 ΕΡ Ο 780 801 /ΡΤ estar em condição de, na base dos dados de identificação, realizar um controlo de bloqueio para o meio de pagamento utilizado. Caso nesta ocasião seja detectada uma observação de bloqueio para o meio de pagamento utilizado, poderia por um lado ser comunicado ao OBE um apelo para o bloqueio do meio de pagamento e por outro lado a identificação do meio de pagamento utilizado ser processada e encaminhada para a actualização de listas de bloqueio.

Um comprovativo de pagamento na base dos decursos de segurança no protocolo de transmissão só são possíveis quando no OBE no momento do comprovativo esteja activo o SAM de aplicação da cobrança automática de taxas. No caso das opções de realização II e IV do OBE o comprovativo de pagamento pode fracassar quando no momento do controlo o cartão inteligente com a aplicação da cobrança automática de taxas não esteja inserido no OBE.

Outras características e vantagens do invento resultam da descrição a seguir de um sistema e do método a ser realizado com este, bem como dos desenhos aos quais se fará referência, os quais mostram: na FIG. 1 um diagrama em bloco de um sistema de acordo com o invento composto por um interrogador e um transponder; na FIG. 2 uma vista lateral generalizada de um modo de disposição típico de um sistema conforme a FIG. 1; na FIG. 3 um diagrama em bloco de uma disposição de transponder e consulta para ser utilizado num sistema de acordo com as FIGS. 1 e 2; na FIG. 4 um diagrama em bloco pormenorizado do transponder conforme a FIG. 3 para representar os componentes do transponder e de um cartão inteligente (Smartcard), que possa comunicar com o transponder; e 84 ΕΡ Ο 780 801 /ΡΤ na FIG. 5 um diagrama de tempos para a representação do método a ser concretizado com a disposição de transponder/cartão inteligente.

Nas diferentes figuras os mesmos componentes estão indicados com os mesmos números de referência e símbolos. A FIG. 1 mostra um diagrama em bloco de um sistema 10 para a cobrança automática de taxas no exemplo de uma cobrança de taxa para a utilização de estradas, em que o interrogador 12 comunica com um transponder 14 portátil por meio da emissão de um sinal de consulta, uma consulta de transacção e uma confirmação de transacção 15a ao transponder 14, o qual reenvia um sinal de resposta e uma resposta de transacção 15b ao interrogador 12. Num sistema de cobrança automática de taxas 10 típico, o interrogador 12 pode encaminhar partes relevantes desta informação a um computador central (Host) 16 para geração e processamento de informações de compensação referentes ao transponder 14 e ao cartão inteligente 66 associado (vide FIG. 4).

Como mostrado na FIG. 2 as vias de circulação 28 estão associadas a um ponto de regulação de trânsito, como por exemplo um posto de cobrança de taxas 29. Neste caso cada via de tráfego 28 tem um interrogador 12. Cada interrogador 12 inicia uma comunicação e mantém a mesma através de uma ligação via rádio com os transponder 14, existentes nas viaturas 26, que se deslocam na via de tráfego 28 associada ao interrogador 12. Os interrogadores 12 podem ter parâmetros eléctricos interiores uniformes, como por exemplo interrogadores da posição da via de circulação, interrogadores de parâmetros de comando e interrogadores da frequência de referência. Nesta aplicação a função do interrogador 12 é a de iniciar ou activar um transponder 14, consultá-lo ou incitar o transponder 14 para o fornecimento de informações específicas, e no caso de um intercâmbio de dados admissível, confirmar este facto ao transponder 14. Como se mostra nas FIGS. 1 e 2, o interrogador 12 tem uma antena 18 que de preferência está fixada por cima da via de circulação. A electrónica 20 do interrogador está ligada com a antena 18 através de um cabo adequado, por exemplo um cabo coaxial por rádio 22. 85 ΕΡ Ο 780 801 /ΡΤ Ο interrogador 12 comunica por via radiotelefónica com o transponder 14 por envio de sinais codificados por fases e modulados, seguido de um sinal de ondas de alta-frequência. O transponder 14 pode responder ao interrogador 12 por retransmissão do sinal continuo de ondas de alta-frequência como é descrito por exemplo na de-r 37 74 015. Outros pormenores da comunicação que se segue entre o interrogador 12 e o transponder 14 são descritos mais abaixo. Uma função possivel do computador central 16 consiste em comandar a operação do interrogador 12 e as funções periféricas do posto de cobrança de taxas. Estas funções periféricas podem servir para o comando de cancelas de trânsito e outros equipamentos para o controlo da via de tráfego tais como câmaras e semáforos. Outras funções periféricas poderiam ser as comunicações entre interrogadores 12 e com um centro de processamento de dados mais afastado, não representado (por exemplo de um adquirente), o qual processa informações de transacções. A ligação 24 entre o interrogador 12 e o computador central 16 pode efectuar-se através da Ethernet, Tokenring, RS 232 RS 422 ou de outro modo. A FIG. 2 mostra uma disposição típica de um sistema 10. Nesta FIG. uma viatura 26 circula numa via de tráfego 28 e aproxima-se deste modo à antena 18. O transponder 14 está instalado ou sobre ou dentro da viatura 26. De preferência o transponder 14 está fixado no pára-brisas da viatura. Em determinadas utilizações, tais como em viaturas excepcionalmente grandes, podem ser adequados outros locais de afixação, tais como o pára-choques de um camião de carga, para reduzir a variação da altura de fixação do transponder 14. Como se mostra na FIG., a viatura 26 que sustenta o transponder 14 aproxima-se do interrogador 12 do posto de cobrança de taxas 29. Outros detalhes referentes à comunicação entre o transponder 14 e o interrogador 12 são abordados a seguir em pormenor. Também os componentes do interrogador 12 e do transponder 14 serão descritos com maior exactidão. A FIG. 3 mostra um diagrama em bloco dos principais componentes do sistema 10. Em primeiro lugar será descrito o transponder 14 com referência à FIG. 4 e no contexto com as FIGS. 2 e 3. O sistema 10 compreende de preferência antenas 86 ΕΡ Ο 780 801 /ΡΤ direccionais 18, sendo cada antena 18 orientada a uma via de tráfego 28 a ela associada. Uma ou várias viaturas 26 podem circular em cada via de tráfego 28, apresentando cada viatura 26 um ou vários transponderes 14. Cada transponder 14 compreende de preferência: uma antena 30, um ASIC 32 analógico ou analógico/digital, um ASIC digital 34 e um reflector de modulação 41. A antena 30 e o reflector de modulação 41 podem formar uma única antena integrada 31. De preferência o ASIC 32 e o ASIC 34 estão integrados num único ASIC.

Ainda com referência à FIG. 3 é reconhecível que a antena 30 do transponder para a recepção de transmissões de alta-frequência é operado pelo interrogador 12. O ASIC 32 analógico converte um sinal encaminhado pela antena 30 do transponder numa tensão, a qual, ao ser ultrapassado um valor limiar activa o transponder 14. De preferência o ASIC 32 analógico capta uma modulação de alta-frequência, a qual está colocada sobre um sinal da antena 30 do transponder, e também só activará o transponder 14 quando existir esta frequência de modulação especial. Deste modo o transponder 14 é relativamente imune contra o facto de ser activado por transmissões de alta-frequência parasitas, que não provém do interrogador 12, mas sim só será activado quando pelo interrogador 12 for transmitida uma frequência especial. O valor limiar da tensão pode ser regulado.

Como ainda mostra a FIG. 3, o ASIC 32 analógico e o ASIC 34 digital processam de forma típica o sinal de interrogação recebido de um transmissor 52 e formam os necessários dados de resposta. A seguir o ASIC 34 digital transfere um fluxo de dados de resposta formatado ao reflector de modulação 41. O ASIC 34 pode ser um sistema digital simples que utiliza um formato fixo, ou um sistema de processamento digital mais dispendioso, o qual pode apresentar uma multiplicidade de opções. Para o ASIC 34 são pensáveis muitas funções, por exemplo a memorização de dados, o historial da transacção, protocolos de intercâmbio de dados e sinais de alarme da capacidade da bateria. O reflector de modulação 41 é modulado por meio da alteração do seu comprimento de onda visível - de preferência ente 1/4 e 1/2 do comprimento da frequência portadora λ. Quando o comprimento de onda visível do 87 ΕΡ Ο 780 801 /ΡΤ reflector de modulação 41 perfazer 1/2 λ, a antena 30 reflecte uma grande parte da energia portadora incidente. Quando o reflector de modulação 41 apresentar um comprimento de onda visível de 1/4 λ, este reflecte somente pouco da energia portadora incidente. Como é do conhecimento geral pode ser realizada uma comutação da antena entre 1/2 λ e 1/4 λ por meio de conexão ou desconexão de dois cabos de derivação 1/4 λ. Na forma de concretização descrita a alteração da secção transversal de reflexão situa-se de preferência no âmbito dos 45 cm2 e dos 100 cm2. Por meio da variação da secção transversal de reflexão conforme o formato específico são enviados dados do transponder 14 ao interrogador 12. Para a energia operacional necessária para o efeito pode existir uma bateria no transponder 14. Em alternativa o transponder 14 também pode receber a sua energia operacional directamente do sinal de alta-frequência, como é revelado por exemplo na DE-R 37 88 348. Os transponder 14 podem de forma típica ser realizados num modelo do tamanho de um cartão de crédito e podem portanto ser facilmente levados com o portador.

Depois de descritos os componentes do transponder 14, faz-se agora referência a uma forma de concretização preferida do interrogador 12 na FIG. 3. O interrogador 12 está instalado num local específico, onde se pretende um intercâmbio de dados, por exemplo um local de pagamento de taxas. O sistema 10 pode geralmente conter um oscilador de referências 50, o qual na sua saída 51 gere uma onda portadora de referência para a coordenação entre os interrogadores 12. Cada interrogador 12 tem uma antena direccional 18 e um emissor 52, o qual emite um sinal de activação com uma intensidade de campo suficiente e uma distância pré-seleccionada, para alcançar ou activar um transponder 14, o qual é sustentado numa viatura 26 numa via de circulação 28 atribuída ao interrogador 12.

A FIG. 4 mostra um diagrama em bloco de uma forma de concretização preferida de um transponder 14 em estado de comunicação com um cartão inteligente 66 através de uma interface 68. O cartão inteligente 66 é inserido na unidade de contacto 70 do cartão inteligente, de modo que possa ser estabelecida uma comunicação através da interface 68. O 88 ΕΡ Ο 780 801 /ΡΤ transponder 14 compreende uma interface de utilizador 72, a qual por seu lado apresenta um mostrador de cristais líquidos 74 e um teclado 76. O mostrador de cristais líquidos 74 é de preferência utilizado para representar ao utilizador no transponder 14 o valor monetário memorizado ou a última taxa deduzida. Depois de um micro-controlador 78 do transponder 14 ter verificado que o cartão inteliqente 66 é compatível com o transponder 14, o micro-controlador 78 opcionalmente pode iniciar um "processo de autorização, no qual o utilizador introduz o seu número de identificação pessoal (PIN) através do teclado 76. Para assegurar que o cartão inteligente 66 possa ser utilizado com o transponder 14, podem contudo ser utilizados outros "processos de autorização". Por meio da introdução do PIN, o qual foi transferido pelo micro-controlador 78 do transponder 14 para o cartão inteligente 66 e por este comparado com um valor de identificação memorizado, é assegurado que valores monetários ou outros dados só sejam entregues pelo cartão inteligente 66 quando autorizados. De preferência a verificação e a "autorização" anteriormente mencionadas são realizadas através da interface 68, a qual de preferência é uma interface serial.

Numa forma de concretização especial do invento o cartão inteligente 66 pode transmitir dados, que representam um valor monetário, o qual de preferência é várias vezes maior do que aquele valor de taxa tipicamente a ser entregue pelo transponder 14. Neste processo os dados são gerados para o valor monetário da transacção, para o fornecedor de serviços, para a identificação do cartão inteligente e para outras informações.

Inicialmente é portanto gerada uma informação pelo cartão inteligente e arquivada no transponder 14. A informação actual gerada pelo cartão inteligente 66 é denominada certificado do cartão inteligente. Este certificado do cartão inteligente compreende normalmente: 1) uma área de dados não codificados, que representam o local, a hora, o número do cartão inteligente ou outras informações necessárias para o administrador do sistema para assegurar ter sido realizado um processo válido; 2) uma área codificada, que compreende informações relevantes para a segurança e outros. Se o micro-controlador 78 tiver condições 89 ΕΡ Ο 780 801 /ΡΤ para ler com êxito esta área codificada, o certificado é memorizado no transponder 14 sob administração do micro-controlador 78. Este certificado do cartão inteligente pode ser arquivado no RAM 80 ou no EEPROM 82. A vantagem de uma memorização no EEPROM consiste nas caracteristicas permanentes, não voláteis de um EEPROM.

Por motivos de segurança e protecção de dados existe um dispositivo de codificação/descodificação 84, o qual comunica com o micro-controlador 78. Este dispositivo de codificação/descodificação 84 vai codificar e descodificar respectivamente autenticar dados transmitidos de e para o cartão inteligente 66. Deste modo é impedido às pessoas que por meio de intervenções não permitidas no transponder 14 possam contornar a utilização do cartão inteligente 66 e deste modo aumentar valores monetários memorizados no transponder 14. Do mesmo modo também não é possivel retransmitir do transponder 14 para o cartão inteligente 66 um valor monetário posteriormente aumentado.

De preferência o transponder recebe a sua energia de baterias, mas também a pode obter da viatura ou de outras fontes. Adicionalmente o transponder 14 pode estar integrado numa viatura ou num outro sistema. O cartão inteligente 66 pode ser levado pelo utilizador até a um aparelho semelhante a uma caixa automática, no qual pode ser introduzido dinheiro e unidades de valores que representam este valor monetário ou ser transferido um outro valor monetário ao cartão inteligente 66. Em alternativa pode ser levantado dinheiro de uma conta ou deduzido de uma conta de crédito, e podem ser carregados dados que representam este valor monetário ou um outro valor monetário para o cartão inteligente 66. Depois destes dados, transferidos de um dispositivo de carregamento externo para o cartão inteligente, terem sido introduzidos, o utilizador pode levar consigo o cartão inteligente 66 como porta-moedas electrónico e utilizá-lo em conjunto com o seu transponder 14 ou talvez em outras possibilidades de aplicação. A vantagem desta utilização de um cartão inteligente consiste no facto de que ao utilizador é conferido um certo 90 ΕΡ Ο 780 801 /ΡΤ grau de confidencialidade respectivamente esfera privada. Nos sistemas em que são utilizados aparelhos externos tais como caixas automáticas, pode por exemplo ser introduzido um valor em dinheiro directamente nestas máquinas, não sendo necessária a identificação do utilizador.

Numa típica transacção de pagamento após a entrada para a zona de cobrança de taxas de um sistema aberto de cobrança automática de taxas ou na saída de um sistema fechado (por exemplo um auto-silo), o interrogador 12 vai consultar o transponder 14. Isto inicia-se com um aviso de aproximação ou uma mensagem de alerta para avisar o transponder 14 de que este se encontra na zona de cobrança de taxas. O sinal de aproximação já pode conter informações do tipo, do serviço e da localização do ponto de cobrança de taxas (Beacon Service Table). Após a recepção do sinal de aproximação pelo transponder 14 e a sua activação, o transponder 14 revela através da emissão de um sinal de disponibilidade ao interrogador 12 a disponibilidade para efectuar uma transacção. Este sinal de disponibilidade pode por seu lado conter informações para o tipo e o volume de funções do transponder (Vehicle Service Table). O interrogador 12 envia então um sinal de interrogação (T), o qual contém indicações relativas aos contratos e métodos de pagamento (cartões de credito ou debito, porta-moedas, etc.) aceites pelo fornecedor de serviços e eventualmente mais outras informações ao local de cobrança de taxas.

Com um sinal de resposta (R) o transponder 14 informa o interrogador 12 sobre a classe da viatura 26, sobre as condições de pagamento (por exemplo tarifa para deficientes, potencial cliente, veículos automóveis para o transporte de altos dignitários, etc.), sobre o estado da validade do transponder respectivamente o meio de pagamento (expiry date), sobre o tipo de meio de pagamento a ser utilizado bem como um eventual título de entrada. Além disso o sinal de resposta contém dados para o processo de codificação (por exemplo número de código de grupo) bem como um número aleatório gerado pelo transponder 14 ou pelo cartão inteligente 66, para a autenticação do interrogador 12. 91 ΕΡ Ο 780 801 /ΡΤ

Adicionalmente podem no sinal de resposta ser transmitidas informações quanto ao momento do último pagamento, por exemplo se este foi efectuado no mesmo ponto de cobrança de taxas. O interrogador 12 vai processar esta informação e reencaminhar uma consulta de transacção (PD) para a solicitação da taxa. O transponder 14 encontrará então um momento adequado para realizar deduções da totalidade de unidades de valores presentemente existentes conservadas na memória 80, 82 do transponder. Em alternativa também pode estar previsto um sistema, no qual o montante da taxa depende da distância percorrida. Neste caso é somente à entrada nesta zona sujeita a taxas necessário que no ponto de entrada seja no transponder 14 memorizado um código de localização respectivamente um titulo de entrada. Neste tipo de procedimento, quando da aproximação à zona da taxa, o transponder 14 vai no sinal de resposta (R) indicar ao interrogador 12 o seu ponto de entrada. O interrogador 12 vai então calcular a taxa dai resultante e comunicar ao transponder 14 na consulta de transacção (PD). Neste momento o montante da taxa é deduzido da quantia memorizada no transponder 14, como já foi acima descrito.

Em dependência do momento actual e na base dos dados contidos no sinal de resposta (R) referentes à classe da viatura, e condições especiais de pagamento e titulo de entrada (ou ponto de entrada, duração de permanência etc.) é no interrogador 12 calculada a taxa a ser paga. A seguir o interrogador 12 envia ao transponder 14 uma consulta de transacção (PD), a qual contém a taxa a ser paga bem como a data e a hora do ponto de transacção, um status ou código de erros, um número aleatório gerado pelo interrogador 12 para a autenticação do transponder 14, bem como uma informação para a tarifa em que se baseia a determinação do preço. A consulta de transacção contém também um código de autenticação da mensagem (Message Authentication Code - MAC), o qual representa um código de segurança codificado utilizando um processo de codificação como por exemplo o Data Encryption Standards (DES). 92 ΕΡ Ο 780 801 /ΡΤ

Após a verificação do MAC contido na consulta de transacção (PD), isto é a autenticação do interrogador 12 pelo transponder 14, o saldo disponível conservado nas memórias 80 respectivamente 82 do transponder é reduzido pela taxa exigida e o resultado do processamento (status) em conjunto com o certificado do cartão inteligente é transmitido numa resposta de transacção (P) ao interrogador 12. A resposta de transacção (P) contém como certificado do transponder também um código de autenticação da mensagem (Message Authentication Code - MAC) o qual é gerado pelo transponder 14. Este é controlado pelo interrogador 12 após a recepção da resposta de transacção (P), de modo que no caso positivo o transponder 14 é considerado autentico.

Para finalizar a transacção o interrogador 12 envia a seguir ao transponder 14 uma confirmação da transacção (CR) parcialmente codificada, a qual contém, pelo menos, uma confirmação do pagamento efectuado (status), informações quanto ao local de pagamento e hora, um número de recibo e um autenticador (por exemplo MAC). Depois de efectuada a descodificação da confirmação da transacção (CR), os dados do recibo são arquivados nas memórias 80, respectivamente 82 do transponder, de tal modo que possam ser efectuadas informações úteis adicionais bem como também um comprovativo de pagamento por exemplo para com um ponto de controlo. A transmissão do certificado do cartão inteligente pelo transponder 14 ao interrogador 12 permite às instituições administrativas estabelecer um assim denominado "balanço simulado" ou efectuar uma contagem contínua, com que frequência um cartão inteligente 66 emitido foi debitado e que a quantia de dinheiro existente no cartão inteligente 66 emitido também esteja de acordo com a quantia de dinheiro efectivamente carregada neste cartão inteligente 66. Isto não afecta de modo nenhum a esfera privada do utilizador, visto que geralmente o nome do utilizador não pode ser relacionado com um cartão inteligente 66 emitido. Cada transacção tem um número de transacção atribuído, de modo que na elaboração da contabilidade de todas as transacções, as transacções que faltam, possam ser facilmente identificadas. 93 ΕΡ Ο 780 801 /ΡΤ

Devido à transmissão do sinal de aproximação, do sinal de fornecimento, do sinal de resposta, da consulta de transacção, da resposta de transacção e da confirmação da transacção bem como pela actualização das informações directamente entre as memórias 80, 82 do transponder e do interrogador 12 em vez de directamente entre o cartão inteligente 66 e o interrogador 12, os problemas de tempo referentes à transmissão de dados são ultrapassados numa janela de comunicação na qual o transponder se mantém dentro do lóbulo do interrogador. Devido ao extenso processo de segurança, aos protocolos e ao constante intercâmbio entre o interrogador 12 e o transponder 14, os receios quanto à segurança com as conhecidas aplicações de "dinheiro cartão" estão em grande parte ultrapassados. A velocidade da transacção está, nesta forma de concretização, extraordinariamente melhorada em comparação com os sistemas nos quais o cartão inteligente 66 comunica directamente com os interrogadores 12 através de um modulador e desmodulador do transponder. Isto deve-se ao facto de que a maioria dos cartões inteligentes 66 têm interfaces normalizadas série lentas. É importante que o tempo de transmissão de dados entre o interrogador 12 e o transponder 14 seja independente do tempo de acesso para averiguação e memorização de dados do e para o cartão inteligente 66. Devido à memorização temporária de dados nas memórias 80, 82 do transponder 14, a comunicação mais lenta entre o transponder 14 e o cartão inteligente 66 pode ocorrer depois da comunicação com o posto de cobrança da taxa estar finalizada.

Numa forma especial de concretização a totalidade da quantia de dinheiro memorizada no cartão inteligente 66 pode ser transmitida para o transponder 14. Antes de retirar o cartão inteligente 66 a quantia restante pode novamente ser retransmitida para o cartão inteligente 66. Neste processo torna-se evidente a importância da codificação dos dados memorizados no transponder 14. É um requisito importante que não seja permitido a nenhuma pessoa manipular dados memorizados no transponder 14 ou por meio de retransmissão do dinheiro do transponder 14 para o cartão inteligente 66 gerar uma quantia de dinheiro aumentada. O papel do dispositivo de 94 ΕΡ Ο 780 801 /ΡΤ codificação 84 consiste em codificar estes dados e integrá-los em sequências de processamento e de decurso seguro e contra manipulação.

De preferência é possível concretizar uma completa transacção de dados dentro de 10 milissegundos (ms). Durante este tempo o transponder 14 vai responder ao sinal de consulta do interrogador 12. Simultaneamente é neste caso determinada a taxa e transmitida ao transponder 14. Também são gerados certificados e a importância correcta o saldo disponível deduzida dentro do transponder 14. Enquanto que o invento permite uma concretização destas transacções dentro de 10 milissegundos, estas com os conhecidos cartões inteligentes/dispositivos de transponder só podem tipicamente ser realizados em 300 a 500 milissegundos. Depois da transacção estar concluída, o transponder 14 pode actualizar os dados no cartão inteligente 66, quando a velocidade de comunicação já não for decisiva, isto é quando o transponder 14 já não se encontra dentro da zona de detecção do interrogador 12. O cartão inteligente 66 pode ser utilizado por diferentes utilizadores como também para diferentes aplicações. Deste modo é com esta aplicação superado o problema da memorização actual e directa de quantias em dinheiro no transponder 14, o que teria a desvantagem de uma mobilidade limitada, visto que o transponder 14 normalmente está instalado numa única viatura não podendo ser aproveitado para outras possibilidades de aplicação. Na presente forma de concretização um utilizador pode aplicar o seu cartão inteligente 66 com um transponder 14 para o pagamento de taxas, mas pode também aplicá-lo para distribuidores automáticos, telefones públicos ou outras possibilidades de outra aplicações.

Esta forma de concretização tem ainda a vantagem de uma melhor protecção de dados e uma maior flexibilidade em comparação com os sistemas "Money-on-Tag", nos quais o dinheiro é memorizado directamente em um "Tag". Nestes sistemas conhecidos pelo estado da técnica, são necessárias agências especiais ou fornecedores de sistemas com aparelhos especiais, para carregar dinheiro no transponder 14. Na 95 ΕΡ Ο 780 801 /ΡΤ presente forma de concretização o transponder 14 é carregado com dinheiro do cartão inteligente 66, o qual por seu lado pode ter recebido dinheiro através de um dispositivo autómato semelhante às caixas automáticas (Multibanco). A FIG. 5 representa um diagrama de tempo para uma forma de concretização deste invento. Neste caso o decurso temporal pode ser subdividido em três fases individuais. A primeira fase "fase A - introduzir" descreve a parte da operação do utilizador, quando o utilizador introduz o cartão inteligente 66 no transponder 14. Este passo é caracterizado na FIG. 5 com o bloco 102. A seguir o utilizador pode opcionalmente introduzir um número secreto pessoal (PIN) no teclado 76, desde que o transponder 14 apresente o respectivo teclado e o meio de pagamento contido no cartão inteligente 66 o permita isto é respectivamente o requerer. Isto é designado com o bloco 104. Após a introdução o PIN é pelo micro-controlador 78 do transponder 14 transferido para o cartão inteligente 66 e comparado por este com um valor de identificação memorizado no mesmo. Em caso positivo a autorização está concluída, e há acesso aos dados relevantes para o pagamento no cartão inteligente 66. Dependente do pretendido respectivamente exigido grau de segurança do meio de pagamento, este processo de autorização também pode ser eliminado ou ser efectuado de outro modo.

No bloco 106 o cartão inteligente 66 gera um certificado de cartão inteligente, compreendendo: 1) uma parte de dados descodificados, os quais contêm o local e a hora de fornecimento, o número do cartão inteligente, as unidades de valor que representam o montante de dinheiro descarregado do cartão inteligente e eventualmente outras informações necessárias para o fornecedor do sistema de pagamento (por exemplo contador de débitos, código de autenticação da mensagem); e 2) uma zona codificada com informações relevantes para a segurança e outras, necessárias para a verificação da autenticidade do processo. Caso o micro-controlador 78 possa interpretar com êxito esta zona, o certificado é memorizado no transponder 14 ou no RAM 80 ou no EEPROM 82 sob o controlo do micro-controlador 78. 96 ΕΡ Ο 780 801 /ΡΤ

Depois disto ter sido concretizado, o transponder 14 está pronto para realizar transacções de cobrança de taxas com o interrogador 12. Isto é mostrado na FIG. 5 como "fase B". Esta fase inicia-se quando o transponder 14 alcança uma zona sujeita a taxas, o que é mostrado no bloco 110. O processo de consulta começa com um sinal de aproximação ou alerta, para avisar o transponder 14 da entrada numa zona sujeita a taxas. O sinal pode conter os acima mencionados pormenores para o posto de cobrança de taxas. O transponder 14 sinaliza num sinal de disponibilidade para com o interrogador 12, de que está preparado para a realização de uma transacção. O interrogador envia um sinal de interrogação (T), o qual contém indicações para os contratos e processos de pagamento aceites pelo fornecedor de serviços. Com o seu sinal de resposta (R) o transponder 14 informa o interrogador 12, como acima descrito, entre outros quanto à classe de viatura, condições especiais de pagamento, o meio de pagamento a ser utilizado, um eventual titulo de entrada existente, o método de codificação e o número aleatório a ser utilizado para a autenticação do interrogador 12.

No bloco 112 o interrogador 12 envia ao transponder 14 uma consulta de transacção (PD), a qual contém a taxa a ser paga bem como a data e a hora do momento da transacção, mais outro número aleatório para a autenticação do transponder 14, bem como uma informação referente à tarifa da taxa. A consulta de transacção também contém um código de autenticação da mensagem (Message Authentication Code - MAC) o qual representa um código de segurança codificado, utilizando um método de codificação como por exemplo o Data Encryption Standards (DES) Após a autenticação do interrogador 12 pelo transponder 14 e a redução do saldo disponível conservado nas memórias 80 respectivamente 82 do transponder, o transponder 14 envia o seu resultado de processamento juntamente com o certificado do cartão inteligente numa resposta de transacção (P) ao interrogador 12. A resposta contém como certificado do transponder também um código de autenticação da mensagem (Message Authentication Code - MAC) o qual é gerido pelo transponder 14 e verificado pelo interrogador 12 para a autenticação do transponder 14 e do processo de pagamento. 97 ΕΡ Ο 780 801 /ΡΤ Ο interrogador 12 vai então processar esta informação e reenviar uma confirmação da transacção (CR) para finalizar a transacção, sendo isto representado no bloco 114. A confirmação da transacção contém as informações acima mencionadas referentes ao pagamento realizado, ao local de pagamento e ao momento, um número de recibo e um autenticador (por exemplo MAC). Após uma descodificação bem sucedida da confirmação da transacção (CR), os dados do recibo são arquivados nas memórias 80 respectivamente 82 do transponder, de tal modo que se possa realizar uma informação útil adicional bem como também um comprovativo de pagamento para com um posto de controlo. Os passos 110 a 114 podem ser repetidos várias vezes, desde que na memória 80 respectivamente 82 a quantidade de unidades de valor não se situar abaixo de um valor minimo. A "fase C" designa a remoção do cartão inteligente a pedido do utilizador, o que é assinalado no bloco 120. Neste momento toda a quantia de dinheiro restante no transponder 14 é de preferência retransmitida através da interface 68 do cartão inteligente 66. A retransmissão de preferência é realizada codificada e integrada num protocolo de autenticação, de modo que, em particular, uma retransmissão só é possível, se anteriormente tenha sido efectuado um débito autêntico e certificado pelo cartão inteligente 66 dentro do transponder 14. O montante de dinheiro existente no cartão inteligente 66 é então actualizado (vide bloco 124). Como se mostra no bloco 126, o cartão inteligente 66 agora pode ser retirado do transponder 14.

No anteriormente mencionado foram descritas algumas formas de concretização preferidas. Contudo é evidente que o âmbito do invento também abrange, em complemento ao que foi descrito, formas de concretização divergentes, como se pode concluir das patentes.

Por exemplo os dispositivos de visualização podem ser tubos de raios catódicos ou outros dispositivos de exploração de linhas, mostradores de cristais líquidos ou mostradores de plasma. O termo "micro-computador" em alguns contextos foi utilizado no sentido de um micro-computador necessitar uma memória, enquanto que o "micro-processador" não necessita 98 ΕΡ Ο 780 801 /ΡΤ desta memória. Apesar disso, na presente descrição estes termos podem ser considerados sinónimos. Os termos "controlador", "circuito do processador" e "circuito de comando", compreendem ASIC (Application Specific Integrated Circuits), componentes de circuitos integrados programáveis com estrutura lógica, como PAL ou PLA, Dekoder, componentes de memória, processadores não baseados em suporte lógico, outros circuitos de conexão, computadores digitais inclusive micro-processadores e micro-computadores de qualquer arquitectura, ou combinações destes. Por dispositivos de memória são designados SRAM (Static Random Access Memory), DRAM (Dynamic Random Access Memory), RAM pseudo-estáticos, circuitos de intercepção, EEPROM (Electronically-Erasable Programmable Read-Only Memory), EPROM (Erasable Programmable Read-Only Memory) registos ou outros dispositivos de memorização conhecidos no estado da técnica. Esta enumeração não pretende ser completa em relação ao invento. A modulação por desvio de frequência (frequency shift keyed modulation, FSK) pode ser considerada como um possivel processo de modulação de dados, mas também a modulação impulso - pausa (pulse-pause modulation), desvio da amplitude (amplitude shift keying, ASK), modulação de quadratura AM (QAM), desvio de fases (phase shift keying, PSK), quadratura do desvio de fase (quadrature phase shift keying, QPSK) ou qualquer outro tipo de modulação. Diferentes processos multiplex, tais como modulação do tempo ou da frequência, também podem ser aplicados para evitar sinais de interferências. Uma modulação também pode ser atingida por modulação por reflexão (back-scatter modulation), por modulação activa de uma frequência portadora ou por outros métodos

Uma implementação pode ser realizada com componentes parciais discretos como também com circuitos completamente integrados de silício, arsenieto de gálio ou outros grupos de materiais electrónicos. Também são consideradas formas de concretização ópticas baseadas em outras tecnologias. Em todo o caso deve ser evidente que as diferentes formas de concretização do invento podem utilizar suporte físico, suporte lógico respectivamente microprogramação. 99 ΕΡ Ο 780 801 /ΡΤ

Embora ο invento tenha sido descrito em relação a uma forma de concretização explicita, não é com isto implícita uma restrição. Para os técnicos desta área da técnica é evidente que com a descrição exemplificada também são abrangidas as mais diferentes modificações e combinações tanto das formas de concretização descritas como também de outras. Estas devem ser incluídas nas reivindicações que se seguem.

Lisboa,

Claims (30)

1. ΕΡ Ο 780 801 /ΡΤ 1/7 REIVINDICAÇÕES 1 - Método para a realização automática de transacções de pagamento por via bancária, em particular, para a cobrança automática de taxas e semelhantes, de preferência, sem contacto entre um fornecedor ou prestador de serviços e um utilizador destes serviços, respectivamente, destas prestações de serviços, que para isso paga com meios de pagamento por via bancária, em particular, meios de pagamento electrónicos, tais como um cartão de crédito, um cartão de débito ou um porta-moedas electrónico, em que este método também é aplicado no âmbito de um sistema de pagamento aberto, o qual, além de meios de pagamento específicos para transportes, permite a aplicação de meios de pagamento universais por via bancária, obtendo o utilizador o meio de pagamento de um emitente, em particular, de um banco ou semelhante e efectuando-se a iniciação do pagamento na forma de uma declaração vinculativa da solvência, enquanto que a recepção do pagamento se efectua na forma da aceitação da declaração e o emitente paga ao prestador de serviços, em particular através de uma câmara de compensação, a taxa ou semelhante, fazendo as respectivas contas com o utilizador, que compreende os seguintes passos: - fornecimento de dados, pela introdução do meio de pagamento num dispositivo de pagamento, os quais contêm, pelo menos, a identificação do meio de pagamento e os quais dispõem de dados individuais relevantes para o pagamento e sua compensação, tais como o montante disponível ou que permitem a identificação da conta, bem como dados que permitem, pelo menos, a identificação do pagamento a ser efectuado; - fornecimento de um dispositivo de reconhecimento por parte do utilizador, que o utilizador leva consigo, o qual, quando da utilização da prestação, respectivamente, do serviço pelo utilizador, emite um correspondente sinal para o dispositivo de pagamento, em particular, na forma de dados, os quais representam a utilização efectuada; ΕΡ Ο 780 801 /ΡΤ 2/7 recepção do sinal emitido pelo dispositivo de reconhecimento e a fixação automática do pagamento a ser efectuado, em particular, uma taxa, com base numa tabela ou através de um algoritmo no dispositivo de pagamento; e - iniciação do pagamento na forma de uma declaração vinculativa no dispositivo de pagamento; - elaboração e apresentação de um recibo correspondente a um pagamento a ser efectuado, no dispositivo de pagamento; em que a iniciação do pagamento e a apresentação do recibo se efectua pela exploração dos dados de compensação correspondentes no dispositivo de pagamento, e em que a estrutura dos dados de compensação é escolhida de tal modo que a mesma é aplicada para o processamento adicional no emitente e eventualmente na câmara de compensação.
2. 2 - Método de acordo com a reivindicação 1, em que o pagamento é uma taxa de utilização, nomeadamente para um meio de transporte, uma estrada, um edifício e, de preferência, em particular, uma taxa para a utilização de uma auto-estrada por uma viatura.
3. 3 - Método de acordo com uma das reivindicações 1 ou 2, caracterizado por o pagamento ser realizado por um pré-pagamento ou um pagamento posterior, por exemplo, por indicação da conta bancária ou semelhante.
4. 4 - Método de acordo com uma das reivindicações 1 a 3, caracterizado por a tabela ou o algoritmo estar presente no dispositivo de pagamento da parte do utilizador, em que o pagamento a ser efectuado é descontado directamente no meio de pagamento ou é memorizado até à próxima transmissão de dados com um posto de cobrança externo.
5. 5 - Método de acordo com a reivindicação 4, caracterizado por ser efectuada uma transferência de dados da transmissão de dados para uma interface de comunicação sem contacto, em particular, via rádio. ΕΡ Ο 780 801 /ΡΤ 3/7
6. 6 - Método de acordo com a reivindicação 4, caracterizado por a iniciação de um pagamento ser efectuada através de um sistema de navegação global por satélite (Global Navigation Satellite System - GNSS).
7. 7 - Método de acordo com a reivindicação 1, caracterizado por o fornecimento de instalações de equipamentos respectivamente funcionais, para a protecção contra um acesso não autorizado às informações, modificação não autorizada de informações, de suporte fisico e suporte lógico, bem como de contextos de sistema, intervenção não autorizada na funcionalidade de sistemas e componentes, intervenções não autorizadas na comprovação da transferência de dados e operações de pagamentos.
8. 8 - Método de acordo com a reivindicação 7, em que são aplicadas as medidas de protecção contra ataques deliberados e ocorrências involuntárias, com base na utilização de mecanismos criptográficos e, em particular, de mecanismos criptográficos para a autenticação de dados, processos e componentes que participem numa comunicação.
9. 9 - Método de acordo com a reivindicação 7 ou 8, caracterizado por para a protecção contra ataques deliberados serem aplicados mecanismos de autenticação na base de números aleatórios, códigos de autenticação de mensagens (Message Authentication Codes), assinaturas digitais e semelhantes.
10. 10 - Método de acordo com uma das reivindicações 7 a 9 compreendendo um dos métodos de segurança normalizados (SAM) diferentes ou idênticos no fornecedor de serviços e no emitente do meio de pagamento.
11. 11 - Método de acordo com a reivindicação 10, em que as transferências de dados são efectuadas parcial ou completamente de forma codificada e, em particular, os dados para a detecção de erros serem codificados por medidas criptográficas.
12. 12 - Método de acordo com uma das reivindicações anteriores, caracterizado por a transferência de dados de compensação ser efectuada via rádio ou semelhantes, através ΕΡ Ο 780 801 /ΡΤ 4/7 de uma linha de comunicações ou por transferência de meios de armazenamento.
13. 13 - Método de acordo com uma das reivindicações anteriores, caracterizado por a transferência de dados de compensação ser efectuada na forma de mensagens, compostas por um elemento de dados Message_Header e um elemento de dados Protocoll_Data_Unit, em que o elemento de dados Messase_Header identifica a versão válida do protocolo e o elemento de dados Protocoll_Data_Unit compreende dados com a classe de mensagem, o tipo de mensagem, a identidade do destinatário da mensagem e a identidade da mensagem, seguindo-se uma sequência de objectos de dados, que contém dados ligados ao pagamento propriamente dito.
14. 14 - Método de acordo com a reivindicação 13, caracterizado por os elementos de dados do Message_Header, Message_Class e Message_Type serem concebidos como números de 1 Byte, enquanto que os objectos de dados do Sender_iD, Receiver_ID e Message_ID serem concebidos com números de 4 Byte.
15. 15 - Método de acordo com uma das reivindicações anteriores, caracterizado por os dados serem transmitidos na forma de objectos de dados (Data Objects), os elementos de dados na forma de números de 4 Byte e os parâmetros de segurança por exemplo como o código de autenticação de mensagem (Message Authentication Code - MAC) ou assinaturas digitais.
16. 16 - Método de acordo com a reivindicação 15, caracterizado por os objectos de dados conterem elementos de dados adicionais com informações de 20 Byte, sendo compostas por números de 8 Byte e números de 2 Byte bem como um número hexadecimal de 8 Byte.
17. 17 - Método de acordo com uma das reivindicações anteriores, caracterizado por os objectos de dados compreenderem elementos de dados adicionais na forma de números de 2 Byte. ΕΡ Ο 780 801 /ΡΤ 5/7
18. 18 - Método de acordo com uma das reivindicações anteriores, caracterizado por os objectos de dados compreenderem elementos de dados na forma de informações de 18 Byte, compostas por um número de 8 Byte, um número de 2 Byte e número hexadecimal de 8 Byte.
19. 19 - Método de acordo com uma das reivindicações anteriores, caracterizado por o fluxo total de dados, vindo do fornecedor, ter eventualmente lugar através do ponto concentrador, do ponto de compensação até ao emitente na forma de mensagens de estrutura homóloga com utilização dos objectos de dados definidos nas reivindicações anteriores.
20. 20 - Método de acordo com uma das reivindicações anteriores, caracterizado por serem transferidos dados para o emitente do meio de pagamento electrónico pelo fornecedor do terminal de carregamento para controlo da segurança do sistema na forma de tais objectos de dados, os quais são estruturalmente homólogos dos objectos de dados, os quais são intercambiados na interface de comunicações entre o dispositivo de pagamento e o dispositivo de cobrança.
21. 21 - Sistema para a realização automática de transacções de pagamento por via bancária, em particular, para a cobrança automática de taxas e semelhantes, de preferência, sem contacto entre um fornecedor ou prestador de serviços e um utilizador destes serviços, respectivamente, desta prestações de serviços, que para isso paga com meios de pagamento por via bancária, em particular, meios de pagamento electrónicos, tais como um cartão de crédito, um cartão de débito ou um porta-moedas electrónico, em que este sistema também é aplicado no âmbito de um sistema de pagamento aberto, o qual, além de meios de pagamento específicos para transportes, permite a utilização de meios de pagamento universais por via bancária, obtendo o utilizador o meio de pagamento de um emitente, em particular, de um banco ou semelhante, efectuando-se a iniciação do pagamento na forma de uma declaração vinculativa de solvência, enquanto que a recepção do pagamento se efectua na forma da aceitação da declaração, e o emitente paga ao fornecedor ou prestador de serviços, em particular através de uma câmara de compensação, a taxa ou ΕΡ Ο 780 801 /ΡΤ 6/7 semelhante, fazendo as respectivas contas com o utilizador, que compreende: - um dispositivo de pagamento que o utilizador traz consigo, para a fornecimento de dados pelo utilizador por meio da introdução do meio de pagamento no dispositivo de pagamento, contendo os dados que permitem, pelo menos, a identificação do meio de pagamento e os dados individuais relevantes para o pagamento e sua compensação tais como o saldo disponível ou a identificação da conta; - fornecimento de um dispositivo de reconhecimento que o utilizador traz consigo, o qual quando da utilização de uma prestação de serviço ou do fornecimento de um serviço pelo utilizador, envia um respectivo sinal, em particular, na forma de dados para o dispositivo de pagamento, os quais representam a utilização efectuada, em que o dispositivo de pagamento está preparado para a recepção dos sinais emitidos pelo dispositivo de reconhecimento e para a determinação automática do pagamento a ser efectuado, em particular, a taxa, com base numa tabela ou ainda num algoritmo; - em que o dispositivo de pagamento está configurado para a iniciação do pagamento na forma da declaração vinculativa; - em que o dispositivo de pagamento está configurado para a elaboração e a apresentação de um recibo de acordo com o pagamento a ser efectuado; e - em que o dispositivo de pagamento está configurado para a iniciação do pagamento e a apresentação do recibo pela exploração de correspondentes dados de conversão, - em que a estrutura dos dados é configurada de tal modo que esta pode ser aplicada ainda para o processamento no emitente e eventualmente na câmara de compensação. ΕΡ Ο 780 801 /ΡΤ 7/7
22. 22 - Sistema de acordo com a reivindicação 21, que compreende um módulo electrónico (20) e uma antena direccional (18).
23. 23 - Sistema de acordo com a reivindicação 22, caracterizado por o módulo electrónico (20) compreender um transmissor (52), uma interface (56) para um computador central e um receptor (54).
24. 24 - Sistema de acordo com uma das reivindicações 21 a 23, que compreende um transponder (14), o qual apresenta uma interface (68) para cartões com circuitos integrados (IC).
25. 25 - Sistema de acordo com a reivindicação 24, caracterizado por o cartão com circuito integrado (IC) ser um cartão inteligente (66).
26. 26 - Sistema de acordo com a reivindicação 25, caracterizado por o cartão inteligente (66) comunicar, através da interface (68) e um micro-controlador (78), com uma memória temporária (80, 82).
27. 27 - Sistema de acordo com uma das reivindicações 24 a 26, caracterizado por o transponder (14) apresentar um dispositivo de codificação/descodificação (84).
28. 28 - Sistema de acordo com uma das reivindicações 24 a 27, caracterizado por o transponder (14) apresentar uma interface (72) com um mostrador de cristais líquidos (74) e um teclado (76).
29. 29 - Sistema de acordo com uma das reivindicações 21 a 28, que compreende uma memória temporária composta por uma RAM (80) e uma EEPROM (82).
30. 30 - Sistema de acordo com uma das reivindicações 26 a 29, que compreende um micro-controlador (78) ligado a um circuito integrado (ASIC) analógico (32), a um circuito integrado (ASIC) digital (34) e a uma antena (30, 31). Lisboa,