PT1686507E - Sistema de interface para cartão de chip - Google Patents

Description

Descrição

Sistema de interface para cartão de chip

Descrição

Terminologia

Cartão de chip: dispositivo com as dimensões de um cartão de crédito que contém um chip integrado e, opcionalmente, uma faixa magnética, na qual são guardados os dados.

Cartão de chip sem contacto (CSC) : cartão de chip que contém uma antena de rádio frequência (RF) integrada, através da qual se obtém comunicação externa.

Terminal de cartão de chip: peça de equipamento electrónico que contém uma interface electrónica adequada para comunicar com um cartão de chip.

Terminal CSC: terminal de cartão de chip sem contacto que contém, especificamente, uma interface RF que facilita a comunicação com um CSC.

Campo do invento 0 presente invento refere-se a cartões de chip e, era particular, a um sistema de interface para cartões de chip configurado para interagir com uma pluralidade de tipos ou aplicações de cartões de chip, de modo a determinar se um cartão de chip apresentado está autorizado a aceder ou a utilizar aplicações permitidas, utilizando tecnologia de cartão de chip. Preferencialmente, o invento refere-se a um sistema de interface para cartão de chip que proporciona acesso controlado a um ambiente com base num cartão de chip apresentado correctamente. 0 invento refere-se, mais particularmente, a um sistema de interface utilizado num ambiente de transportes em que é proporcionada uma arquitectura ou um mecanismo de bilhetes de transporte implementados através da utilização cartões de chip sem contacto. 0 invento refere-se, mais particularmente, a um sistema de controlo de acesso que incorpora um módulo de cartão de chip que apresenta uma interface comum ao nivel de negócio para sistemas computorizados de hierarquia superior, facilitando a comunicação com uma larga gama de cartões de chip adoptando normas diferentes. No contexto do presente invento, o termo "módulo" refere-se a um aparelho com uma combinação de hardware / software que inclui ainda um ou mais componentes de hardware e software configurados para obter o resultado desejado.

Antecedentes do invento

Os cartões de chip são bem conhecidos na técnica. 0 cartão de chip típico tem dimensões semelhantes a um cartão de crédito, e pode ser facilmente colocado numa carteira. Um cartão de chip sem contacto (CSC) difere do cartão de crédito de "contacto" tradicional por incluir um processador 2 e uma memória integrados, e por incluir, também, um transmissor rádio de modo a permitir comunicação por rádio frequência (RF) entre o cartão de chip e um terminal de cartão de chip. A existência um processador permite maior funcionalidade e maior segurança no cartão do que as tradicionalmente disponíveis, por exemplo, num cartão de crédito do tipo com faixa magnética.

Com o desenvolvimento de cartões de chip, foram desenvolvidas muitas aplicações proporcionais à funcionalidade disponível do cartão de chip. Os exemplos incluem cartões de acesso de segurança, cartões de identificação pessoal e, recentemente, a utilização de tais cartões na área dos transportes, onde estão a ser utilizados para substituir o bilhete cartão tradicional com faixa magnética.

As vantagens da utilização do cartão de chip, e particularmente do CSC, como um bilhete incluem o facto do cartão de chip poder processar uma transacção e actualizar os dados guardados no CSC mais rapidamente que do qualquer cartão tradicional (na ordem dos cerca de 300 milisegundos) e, como tal, a sua utilização melhora a conveniência e velocidade de acesso ao transporte, reduzindo os vários segundos que demoraria, de outro modo, a inserir um bilhete numa máquina de validação. Para além disso, visto que é possível identificar o utilizador, é também possível cancelar o cartão no caso de roubo ou perda. As vantagens adicionais incluem a facilidade de "recarregar" o bilhete com um valor. Tais vantagens levam a que, progressivamente, mais agências de transportes no mundo se virem para cartões de chip para utilização como bilhetes.

Em tais áreas de bilhetes proporciona-se ao utilizador um bilhete de cartão de chip e, à entrada para o 3 sistema de transportes, por exemplo um sistema de Metro ou de autocarro, o cartão é lido por um terminal de cartão de chip, contendo muitos dos elementos descritos de seguida: um exemplo deste arranjo está ilustrado na figura 1. Neste arranjo o utilizador apresenta o seu CSC (100) no autocarro, por exemplo. O cartão transmite a informação relativa ao cartão através de uma antena RF (105) que está acoplada, através de ligação por cabo, como por exemplo uma ligação RS232, a um dispositivo de Aceitação de Cartão [Card Acceptance Device (CAD)] (110). O CAD (110) inclui um tradutor RF (110a) e um módulo de driver de cartão (110b). A informação lida pelo CAD é então transferida para um terminal CSC (115), onde o processamento da informação recebida do CSC é efectuado. 0 modelo tradicional de terminal de CSC para interacção CSC obriga o terminal CSC a ligar-se directamente a um CAD genérico ISO - 14443. Exige-se, assim, que o terminal CSC comunique com CSC ao nivel do "driver": o terminal de cartão de chip interage com o cartão utilizando comandos de baixo nível específicos da tecnologia de cartão de chip escolhida, e exige-se assim que este compreenda e gira o ficheiro detalhado e as estruturas de dados guardadas no cartão. Este processo exige que o terminal CSC gira todos os periféricos de hardware do terminal (por exemplo ecrã, teclado, LED's, vibrador, cancela de três braços ou cancela de flap, mecanismo de moedas, mecanismo de notas) tal como a interacção CSC, que inclui: determinar que tipo de cartão foi apresentado, executar a validação da capacidade de utilização do CSC, processar os dados do CSC, actualízar o CSC e reportar a transacção a um computador de hierarquia superior, geralmente a intervalos periódicos, tais como quando o autocarro regressa à estação. Para além disto, cada fabricante que fornece equipamento a um sistema de transportes asseguraria, idealmente, que os seus terminais 4 de CSC processam os vários tipos de CSC do mesmo modo que os terminais CSC de todos os outros fabricantes que fornecem equipamento ao sistema, de modo a que a experiência do utilizador seja semelhante ao longo de todo o sistema. No entanto, isto raramente é conseguido.

Adicionalmente, em locais onde os sistemas de transporte actuam próximos uns dos outros (por exemplo perto de fronteiras do pais ou de distritos), ou noutras situações nas quais existe uma vontade política ou comercial para se conseguir "interoperabilidade" sabe-se que a empresa que proporciona o transporte específico, i. e., quem proporciona o transporte com a licença para operar nessa zona geográfica, desenvolve um sistema que utiliza a norma desenvolvida por um fabricante, e uma segunda empresa que proporciona transporte desenvolve um sistema utilizando uma segunda norma que foi proporcionada pelo fabricante escolhido para essa implementação. Na maioria dos casos, a norma desenvolvida por um fornecedor não está de acordo com a desenvolvida pelo segundo fornecedor e, como tal, não é um exercício simples proporcionar uma solução para bilhetes que permita a utilização de múltiplas soluções de transporte, ou proporcionar uma solução que atravesse fronteiras geográficas. Os desenvolvimentos para se resolver este problema levaram à publicação de normas genéricas de linguagem de comunicação de transportes (por exemplo a IOPTA). No entanto, porque não existe uma organização de normas a nivel mundial que detenha a jurisdição em todos os países do mundo, existe agora uma proliferação destas normas pela Europa, Ásia e América. Para além disto, porque os comités que elaboram estas normas são dirigidos, geralmente, por representantes dos fabricantes de terminais, e devido à multiplicidade de tipos de cartões disponíveis, as normas têm tendência a focar-se na interface de baixo nível do 5 terminal CSC para o cartão, e não proporcionam qualquer meio de interface de nível da execução. 0 documento WO 00 / 77717 descreve um dispositivo de comunicação de cartão de chip com protocolos múltiplos de acordo com a técnica antecedente.

As vantagens em proporcionar um sistema de transporte integrado foram reconhecidas em vários países. Por exemplo, noutro esforço de normalização no Reino Unido, os executivos dos transportes públicos, os operadores de autocarros e os franchisados da rede de comboios do Reino Unido juntaram-se, em 1998, para formar a Integrated Transport Smartcard Organisation (ITSO), que tinha como principal objectívo o desenvolvimento de uma iniciativa de transportes multi-modais baseados em cartões de chip. Os esforços da ITSO em proporcionar uma solução para o problema de interoperabilidade incluíram a publicação de outra norma e o desenvolvimento de um Security Access Module (SAM) específico da ITSO. O SAM da ITSO tinha como objectivo proporcionar um mecanismo comum, através do qual (i) a autenticidade e integridade dos CSC concordantes com a ITSO poderiam ser validadas, e (ii) a comunicação das transacções do CSC para os computadores de hierarquia superior poderia ser conseguida com integridade. No entanto, a ITSO foi apenas outra na multiplicidade de normas publicadas, e a SAM da ITSO não proporcionou, nesta altura, uma solução de interoperável entre múltiplos tipos de cartões de chip.

Assim, existe ainda a necessidade de proporcionar uma arquitectura integrada que utilize os benefícios dos cartões de chip sem contacto que (i) podem ser utilizados, com interoperabilidade, numa variedade de diferentes tipos de CSC e / ou sistemas de transporte, (ii) proporcionam uma experiência comum de utilização, mesmo na presença de 6 terminais de CSC de fabricantes diferentes, e (iii) elevam a interface até ao CSC a partir do nível do cartão até um nível de execução.

Resumo do invento

Estes e outros problemas são abordados por um sistema de interface de cartão de chip de acordo com o presente invento, que proporciona (i) uma plataforma auto-suficiente (SSP - Self-Sufficient Platform), (ii) a superposição de um motor de execução no SSP , e (iii) a associação de uma infra-estrutura de execução externa através da qual um módulo universal de cartão de chip (USM - Universal Smartcard Module), (em particular as suas regras de execução) está configurado, e com o qual o USM comunica.

Numa representação preferida, na qual o sistema de interface é colocado num ambiente de transportes, o SSP proporciona o ambiente, através do qual o USM pode (i) estabelecer uma interface inter-operável com uma variedade de tipos de CSC de um ou mais sistemas de transporte, (ii) comunicar localmente (por exemplo num único autocarro ou comboio, ou dentro de uma estação ferroviária) e globalmente (por exemplo, com computadores de hierarquia superior em diferentes locais), (iii) determinar a sua posição, globalmente (por exemplo em termos de coordenadas de navegação, actuando num ambiente de um autocarro ou de outro veículo que viaje ao longo de uma rota regular de transporte de passageiros) e (iv) obter segurança da informação que vai ser comunicada fora do domínio do USM individual. 0 motor de execução proporciona o ambiente no qual a funcionalidade de execução comum a operações de transporte 7 (por exemplo criar o cartão, personalizar o cartão, criar a aplicação, criar o produto, validar o produto, cartão de hot-list, finalizar o produto, utilizar o produto, eliminar o produto) podem ser executadas de um modo comum, independentemente do tipo de CSC apresentado, e independentemente do fabricante a cujo terminal o CSC é apresentado. A infra-estrutura externa de execução proporciona os meios através dos quais todas as regras de execução, a serem executadas quando um CSC é apresentado a um terminal CSC, são desenvolvidas e testadas. Para além disto, a infra-estrutura de execução é baseada numa tecnologia que permite que as regras de execução computorizadas desenvolvidas na infra-estrutura externa sejam descarregadas, sem mudança, para o ambiente operacional do USM. Isto é uma mudança relativamente à aproximação habitual, na qual as regras de execução desenvolvidas na infra-estrutura externa exigem "portabilidade" para os ambientes operacionais individuais dos vários tipos de terminal CSC.

Finalmente, o invento {i. e. o USM e a sua infra-estrutura externa de execução) permite o desenvolvimento e teste de regras de processamento ao nível da execução, para utilização com tipos múltiplos de CSC, de um modo inter-operável, em terminais CSC fornecidos por múltiplos fabricantes, e a existência do código final para a execução destas regras antes mesmo da selecção dos fabricantes que vão fornecer o equipamento ao sistema e, seguramente, antes do fornecimento de quaisquer terminais CSC ao ambiente operacional.

Para permitir estas e outras vantagens, o presente invento proporciona um sistema de interface de acordo com a reivindicação 1. São apresentadas representações vantajosas 8 nas reivindicações anexas. 0 invento proporciona também um método no qual os cartões de chip sem contacto de diferentes tipos ou tendo várias aplicações aí guardadas pode ser questionado de modo a seleccionar a interface correcta para o cartão de chip específico numa altura específica. Tal metodologia é proporcionada na reivindicação 16, com as representações vantajosas apresentadas nas reivindicações desta dependentes .

Breve descrição dos desenhos 0 presente invento será agora descrito com referência a alguns desenhos anexos, nos quais: A figura 1 ilustra uma arquitectura conhecida para utilização em sistemas de transporte; A figura 2 ilustra uma arquitectura de acordo com uma primeira representação do presente invento. A figura 3 ilustra uma modificação da arquitectura da figura 2 de acordo com uma representação adicional do invento. A figura 4 ilustra uma modificação adicional da arquitectura da figura 2 de acordo com uma representação adicional do invento. A figura 5 ilustra uma arquitectura alternativa de acordo com uma representação adicional do presente invento.

Descrição detalhada dos desenhos 9 A técnica anterior foi descrita com referência à figura 1. 0 presente invento será agora descrito com referência às figuras 2 a 4. Estas figuras ilustram uma representação preferida de um sistema de interface de acordo com o presente invento, no qual o sistema é implementado no contexto de uma arquitectura de transporte. Tal representação será tomada como exemplo do tipo de controlo de interface que pode se pode conseguir utilizando o presente invento, e não se pretende que limite o invento de qualquer forma, excepto se for considerado necessário à luz das reivindicações anexas.

Como será evidente a partir de uma análise da figura 2, que ilustra uma arquitectura de transporte de acordo com o presente invento, com componentes semelhantes aos da figura 1 identificados com os mesmos números de referência, o presente invento utiliza um cartão de chip sem contacto 100 que comunica através de uma Antena RF 105 com componentes de hardware que acedem a aplicações guardadas no cartão de chip. De acordo com o presente invento, esta interface entre o cartão de chip e os componentes de hardware é efectuada através de um Universal Smartcard Module USM 200. O USM é acoplado à antena RF para permitir a comunicação com o cartão de chip, e é ligado através de um cabo de dados ao terminal CSC tradicional. O USM pode estar localizado fisicamente dentro ou no exterior do alojamento do terminal CSC. O USM 200 da figura 2 inclui um conjunto de módulos de interface de cartões específicos 200A, um módulo de motor de integridade de cartão 200B, um módulo genérico de interface lógica de cartão 200C, e um módulo de serviços de segurança 200D. O número dos módulos de interface de cartão 200A incorporados dentro de um USM específico vai depender da aplicação a ser executada para esse USM, porque as áreas geográficas específicas irão exigir a capacidade de 10 interacção com tipos de CSC diferentes de outras execuções. Deverá ser tomado em consideração que, de acordo com o presente invento, o número dos módulos da interface para cartão 200A pode ser actualizado mais tarde do que o número inicial incorporado no USM 200. De um modo semelhante, onde um cartão de chip for apresentado com múltiplas aplicações ai guardadas, os módulos de interface estão configurados para seleccionar a aplicação correcta para a interacção actual. A determinação do módulo especifico de interface do cartão adequado para processar um cartão apresentado, baseía-se tipicamente na hierarquia de: 1)Fabricante; 2}Tipo de cartão,-3)Aplicação;

Utilizando uma tal sequência de interrogação de hierarquia é possível determinar rapidamente e de um modo preciso a linguagem correcta de interface que deve ser utilizada para comunicação subsequente com o cartão de chip.

Após receber uma notificação da antena 105 de que um CSC está a tentar iniciar uma comunicação com o mecanismo de transporte, o USM é configurado para questionar o CSC de modo a determinar quais dos módulos específicos de interface de cartão devem ser utilizados para comunicação subsequente. Esta interrogação é feita através de várias questões. Primeiro, a resposta utilizando o comando "Questão" da norma ISO 14443 emite uma identificação de fabricante de acordo com a ISO. Uma análise adicional da resposta facilita a 11 selecção do tipo de cartão especifico do fabricante. Logo que o tipo de cartão for conhecido, a sua capacidade para suportar aplicações simultâneas múltiplas é conhecida de um modo implícito (a partir de informação programada e guardada no USM), tal como a estrutura dos Identificadores da Aplicação, Para cartões de aplicação única, o Módulo Específico de Interface de Cartão é seleccionado imediatamente. Para cartões com múltiplas aplicações, logo que o Identificador de Aplicação seja recuperado, o Módulo de Interface Específico do Cartão pode ser seleccionado. Se não existir módulo associado com o identificador recuperado, então o cartão é rejeitado como "não suportado". Isto pode ser introduzido separadamente como parte de uma estrutura de relatório, de modo a proporcionar, mais tarde, uma análise sobre a necessidade introdução posterior de módulos de interface de cartões adicionais. 0 módulo de interface lógico genérico de cartão 200C apresenta uma vista ao nível de execução de um cartão lógico genérico, que é independente, quer da tecnologia do cartão escolhida, quer da estrutura detalhada dos ficheiros e dos dados guardados em qualquer um dos tipos de cartão suportados. 0 componente do Motor de Integridade de Cartão 200B do USM é responsável por gerir os vários dados, ficheiros, etiquetas e índices que estão associados com a estrutura das aplicações, ficheiros e campos de dados que estão distribuídos ao longo de cada um dos tipos de cartão suportados. 0 Motor de Integridade de Cartão assegura que apenas os conjuntos consistentes de dados são alocados a um cartão durante uma "transacção" do cartão de chip. 0 componente dos Serviços de Segurança 200D do USM é incorporado preferencialmente num hardware à prova de fraude 12 do Módulo de Acesso de Segurança (SAM - Security Acess Module) e executa todas as funções criptográficas necessárias para interagir com os tipos de cartão suportados, ao nível de tecnologia e da execução, {i) assegurando que os dados válidos são "selados" criptograficamente antes de serem escritos no cartão, e (ii) validando selagens criptográficas existentes de modo a apresentar, no terminal CSC, os dados de negócio que foram validados criptograficamente para integridade e autenticidade. Através das suas capacidades de resistência a fraude, o SAM também proporciona a localização para guardar de um modo seguro as chaves digitais secretas que são exigidas para executar os algoritmos criptográficos. Será tomado em consideração que o hardware do módulo de acesso de segurança (SAM) permite a gestão criptográfica simultânea e o armazenamento seguro de chaves para a interacção com cartões de chip que obedeçam a normas diferentes, incluindo IOPTA, ITSO e RIS-300, e semelhantes.

Será tomado em consideração que cada um dos motores de integridade de cartão 200B, os serviços de segurança 200D, e o módulo de interface de cartão lógico genérico estão configurados para comunicar em linguagens CSC específicas independentes, sendo os comandos e comunicações traduzidos posteriormente pelo módulo de interface de cartão 200A para interacção com o CSC. Assim, o nível de funcionalidade que pode ser proporcionado pelo USM é maior do que o disponível tradicionalmente no ponto de interacção com o CSC. 0 USM permite uma programação genérica de funcionalidade que só é traduzida para linguagens de interacção específicas de CSC na altura da interacção. 0 USM 200 é ainda programável para apresentar dados a um terminal CSC 205, de acordo com qualquer norma industrial pretendida (por exemplo CEN EN-1545: IOPTA). A interface 13 entre o USM e o terminal CSC é implementada tipicamente utilizando uma ligação em série que suporta protocolos de comunicação Standard na indústria, incluindo o RS-232 e o USB-2. Será entendido que todas as aplicações CSC utilizam um terminal CSC com o nível de funcionalidade de hardware suportado ou proporcionado pelo terminal CSC, dependendo da aplicação especifica. Por exemplo numa zona de bilhetes, um terminal CSC inclui, tipicamente, um ecrã, de modo a permitir uma apresentação de comandos a um utilizador, um controlo de barreira que será activado com a apresentação de um CSC autorizado, e um ou mais LED's que serão activados de modo a indicar que o utilizador pode prosseguir ou deve aguardar. Noutras aplicações, um terminal CSC pode não ser utilizado para controlar barreiras, e, como tal, o controlo de barreiras não é suportado.

Como resumo, (i) as Interfaces Especificas de Cartão do USM contêm as várias tecnologias suportadas pelo cartão e estruturas de dados de acordo com as normas suportadas, (ii) o Motor de Integridade de cartão traça funcionalidades ao nivel da execução para instruções ao nível do cartão, assegurando que os dados escritos em cada cartão são consistentes internamente, (iii) o módulo de Serviços de Segurança estabelece a integridade e a autenticidade da transacção, e (iv) a Interface Lógica Genérica do cartão apresenta uma interface comum ao nivel da execução aos terminais CSC, independentemente de que sistema, tecnologia ou norma estão associados com o cartão apresentado. Será entendido, assim, que a representação da figura 2 introduz uma Plataforma de Cartão Lógico Genérico, que facilita a substituição da Gestão de Dados específica do cartão pelo terminal CSC por uma Interface de Gestão de "cartão lógico" genérico 205C. A arquitectura do presente invento introduz também um módulo de Serviços de Segurança, que proporciona, i 14 genericamente, os serviços criptográficos e armazenamento seguro de chave necessários para interagir com todos os tipos de cartão suportados, de acordo com as normas suportadas. A figura 3 ilustra uma extensão adicional do USM da figura 2, até ao ponto em que a plataforma se torna auto-suficiente como uma base para processamento adicional ao nível da execução (a ser descrito relativamente a figuras posteriores). Nesta representação do invento, o USM 300 inclui os componentes presentes no USM da figura 2, mas inclui, adicionalmente, capacidades de comunicação.

Um exemplo é o acrescento de um módulo de comunicações 300A. O módulo de "comunicações" 300A é multi-modal, incluindo comunicação sem fios "local" {obtida através do fornecimento de um transmissor sem fios 802.11 x WiFi), e comunicação sem fios "global" (obtida através do fornecimento de um transmissor sem fios GSM ou GPRS). Incluindo tais meios de comunicação no USM é possível substituir ..informação reunida num USM individual, quer para igualar USM's em terminais CSC locais (por exemplo entre validações CSC e consolas de condutor de autocarro) e em computadores remotos de hierarquia superior (por exemplo computadores de estações de caminhos de ferro), num ambiente em tempo real. O terminal CSC não exige, assim, qualquer interface para permitir a comunicação com redes ou sistemas externos. Isto é vantajoso quando comparado com a implementação da técnica anterior que podia apenas proporcionar esta informação no regresso do autocarro à estação, ou em estacões de caminhos-de-ferro e pontões de ferrys, através da interface de ligação por cabo proporcionada para permitir uma actualização do computador central. 15

Assim, o USM de acordo com a figura 3 proporciona os meios através dos quais o terminal CSC pode ser ligado a uma rede de computadores e a dispositivos electrónicos que compreendem um sistema de Colecta Automatizada de Tarifas (AFC - Automated Fare Collection} , sem a necessidade de cabo. Isto resolve três conjuntos de problemas: 1. o trabalho envolvido para introduzir ou melhorar a capacidade de comunicações dos terminais CSC para lidar com o volume adicional de dados associados com o processamento CSC e com as suas exigências de segurança, 2. o esforço envolvido em colocar ou redireccionar cabos de rede sempre que os terminais AFC são introduzidos ou deslocados {envolvendo, geralmente, a perfuração do cimento de plataformas de estações de metro operacionais), e, 3. a dificuldade em conseguir comunicação regular com os terminais em veículos (por exemplo autocarros), o que pode, frequentemente, demorar dias entre visitas a estações, onde a solução tradicional para o problema consiste em guardar informação nos terminais CSC dos veículos, e transferi-la quando o veículo regressa às estações, impondo assim uma exigência adicional de capacidade de armazenamento de dados aos terminais CSC, o que se torna um peso em terminais mais antigos com capacidade de hardware limitada. 0 USM proporciona uma comunicação em curso com terminais CSC fixos e móveis, sem qualquer exigência de cablagem ou outra infra-estrutura de rede, e, durante o processo, minimiza as exigências de capacidade de 16 armazenamento de carga dos terminais CSC. Entretanto, o terminal CSC pode continuar a processar bilhetes magnéticos utilizando a sua capacidade de armazenamento e de processamento, e a sua infra-estrutura de comunicações existente, em paralelo com a capacidade de processamento do CSC adicionada pelo USM. A capacidade de "localização" no USM pode também ser proporcionada por uma modificação, tal como a ilustrada na figura 3. Neste exemplo de arquitectura, um módulo de localização com a forma de um módulo receptor GPS 300C pode ser incluído no USM. Um tal USM aumenta os meios para identificar a posição, em coordenadas GPS, do terminal CSC. Estes meios permitem que o terminais CSC em veículos que viajam ao longo de rotas configuráveis, incrementem automaticamente etapas e / ou zonas de mudança, enquanto a viagem decorre. A aproximação tradicional a este problema tem sido obrigar o condutor do equipamento móvel AFC a premir um botão de "incremento de etapa" durante a viagem, ou a adicionar um subsistema externo de GPS. A associação de todos estes meios num módulo único, o USM, proporciona uma plataforma auto-suficiente (i. e. que não exige infra-estrutura de suporte adicional, e assim, que pode ser acoplada a um equipamento AFC existente) com o qual um Motor de Execução pode ser agora construído. Será entendido, assim, que a modificação proporcionada pela arquitectura da figura 3 proporciona a existência da Plataforma Auto-Suficiente, o que dá à plataforma conhecimento da sua localização, juntamente com os meios de comunicação fora do domínio do USM.

Uma extensão adicional ao USM da figura 3 introduz um Motor de Execução USM 400, tal como está ilustrado na figura 4. Um tal USM incorpora software tal como o implementado 17 utilizando uma Máquina Java Virtual (JVM - Java Virtual Machine) 400B, com a qual as regras de execução AFC podem ser executadas em código Java. 0 termo "Regras de Execução AFC" incluem o conjunto de algoritmo e processos de referência que são, (a) executados com os dados recuperados do CSC, e (b) executados para criar a nova informação a ser escrita de volta no CSC durante uma transacção. Tais regras de execução podem ser guardadas numa cache local proporcionada por um módulo de regras de execução específicas de projecto 400A. As regras de execução incluem fases como: 1. o processamento de "validação" (tal como confirmar que o identificador do cartão não está numa hotlist do cartão, confirmando que o Balanço de Compra é diferente de zero) 2. o processo de "selecção" (tal como avaliar o conjunto de produtos mantidos no CSC, e determinar o adequado para utilização na transacção a ser executada) 3. o processo de "cálculo" (tal como determinar, a partir das etapas de embarque e saída, e da classe do passageiro, a tarifa correcta a ser cobrada) 4. o processo de "actualização" (tal como determinar, a partir do Balanço de Compra e da tarifa cobrada, o novo Balanço de Compra a ser escrito de volta no CSC).

Estes meios permitem que seja utilizada uma linguagem de programação padrão para a indústria na codificação das regras de execução a serem executadas no terminal CSC, e que seja assim removida a exigência para regras específicas de execução a serem implementadas em ambientes de plataforma 18 com múltiplos dispositivos, com o regime de teste individual superior associado necessitado por transacções potencialmente diferentes feitas durante as actividades de portabilidade. A execução das regras de execução no USM minimizam, novamente, as exigências da capacidade de armazenamento e de processamento dos equipamento AFC existentes serem melhorados para receber cartões de chip. 0 USM pode ser ainda configurado para incluir uma interface sim / não (go/no go) 410. O módulo de interface sim / não 410 proporciona os meios através dos quais o USM e o terminal CSC comunicam os seus "estados" de operação. Por exemplo, o terminal CSC pode estar a processar moedas ou notas, e pode querer assegurar que o USM não começa a processar o CSC até ter sido paga a quantia correcta. Pelo contrário, o USM pode estar a processar e o CSC pode querer garantir que as barreiras dos caminhos-de-ferro não abrem até o CSC ter sido validado e processado com sucesso. A interface sim / não é um componente bidireccional de sinalização digital que permite que o USM e o seu terminal receptor coordenem as suas responsabilidades de processamento respectivas. 0 módulo sim / não é definido por uma especificação de interface do programador da aplicação (API - Application Programmer's Interface).

De acordo com a modificação proporcionada pela representação da figura 5, é incorporado um motor de execução. O motor de execução USM atinge o seu valor máximo como um elemento da Infra-estrutura de Regras de Execução. A infra-estrutura de regras de execução utiliza dois componentes chave: 19 1. um motor de execução USM com capacidade Java, como foi descrito acima relativamente à figura 4, e 2. uma Estação de Gestão USM com base em PC com capacidade java 500. A estação de gestão USM está equipada com uma máquina virtual Java (JVM - Java Virtual Machine) de terceiros imediatamente disponível 500A, tal como a conhecida e construída para hardware de PC e plataformas de sistemas operativos. O USM está equipado com uma JVM de elevado desempenho colocada no hardware do processador da plataforma USM. Ambas as JVM's interagem com módulos de regras de processamento específicas para o projecto, sendo o módulo 5Q0B fornecido na estação de gestão de PC 500 configurado para permitir uma escrita de software de Regras de Execução em Java. De acordo com isto, a estação de gestão USM com base num PC pode ser utilizada num ambiente de escritório para configurar, utilizando um motor de configuração 500C, todas as regras de execução relacionadas com o cartão de chip a serem implementadas no sistema operativo, e para depois testar, utilizando um motor de teste 500D, essas mesmas regras de execução, relacionadas com o cartão de chip, a serem executadas no terminal CSC antes de serem proporcionadas ao USM remoto 300. Logo que as regras necessárias tenham sido testadas no ambiente de teste proporcionado pela estação de gestão de PC 500, é então possível comunicar a versão totalmente testada através de canais de comunicação 500F a um ou mais USM's remotos, onde estas são guardadas e activadas utilizando os seus motores de execução específicos 400A para o projecto específico e JVM7 s 400B, confiando que o código que está a ser testado na estação de gestão USM será descarregado, não modificado, 20 para actuar no USM do terminal CSC. Isto elimina o duplo problema de: 1. ter de traduzir regras de execução para implementações de software especificas, aplicáveis à plataforma de computação de cada terminal CSC diferente, e 2. ter de testar independentemente as implementações de regras de execução em todos os tipos diferentes de terminais no sistema.

Será tomado em consideração que a arquitectura do presente invento proporciona um número de vantagens relativamente à técnica anterior. Proporcionando uma arquitectura que incorpora um USM, é possível proporcionar meios únicos, unificados, através dos quais: 1. os cartões de chip com tecnologias e estruturas de dados internas diferentes e referentes a sistemas de transportes diferentes podem ser processados através de uma interface lógica comum. 2. os cartões de chip de sistemas de transporte diferentes, que actuam em áreas onde a inter-operação dos sistemas sobrepostos é exigida (i, e, nos e à volta dos limites dos distritos) podem ser processados pelos terminais de cartões de chip de ambos os sistemas. 3. a tecnologia de cartão de chip pode ser introduzida por fornecedores de transportes sem que estes tenham de gastar dinheiro em equipamento de processamento de bilhetes. 21 4. as regras de execução relacionadas com cartões de chip podem ser especificadas e testadas num ambiente de escritório, e depois implementadas no equipamento distribuído dos fornecedores de transporte, sem a necessidade, quer de tradução para o ambiente de hardware específico do fabricante do terminal CSC, quer de teste individual pelos fabricantes. 5. a definição, implementação e verificação das regras de execução relacionadas com cartão de chip pode avançar enquanto estão a ainda ser tomadas decisões relativamente ao local e desenho dos computadores e equipamento electrónico que constituirão, em última análise, os componentes do sistema de transporte implementado.

Embora o invento tenha sido descrito com referência a um desenvolvimento numa área de transportes, será tomado em consideração que este é um exemplo do tipo de aplicação de interface que é adequada para a utilização com o presente invento. Proporcionando interfaces múltiplas, cada uma configurada para comunicar com um CSC específico numa linguagem específica a esse CSC, o invento permite a utilização de cartões de chip de múltiplos tipos de fabrico e tendo múltiplas aplicações a serem aplicadas. Por exemplo, um fornecedor de transporte pode não pretender dar direitos exclusivos a um fabricante de CSC para que forneça todos os cartões de chip para utilização com esse fornecedor de transporte. 0 presente invento refere-se a este problema fornecendo interfaces para múltiplos cartões de chip. Para além disto, um utilizador pode ter múltiplas aplicações guardadas no seu cartão de chip personalizado - sendo uma aplicação, por exemplo, um bilhete para o metro·, e outra um 22 bilhete para o teatro. Quando se dirigirem ao teatro, apresentam o seu cartão de chip no sistema de bilhetes situado no metro. Os módulos de interface fornecidos pelo presente invento questionam o cartão, determinam que o cartão tem uma aplicação configurada para bilhete de metro, deduz a tarifa correcta para a viagem de metro e permite que a pessoa prossiga. Ao chegar ao teatro, a pessoa apresenta o mesmo cartão de chip ao sistema de bilhetes do teatro, que utiliza os módulos de interface do presente invento, determina que existe uma aplicação para o bilhete de teatro guardada no cartão, e processa essa aplicação para autorizar o acesso ao teatro. Toda esta multi-funcionalidade é obtida de um modo simples, sem exigir qualquer interacção pelo utilizador - tudo o que é exigido é uma apresentação do cartão de chip e o USM efectua o processamento correcto, independentemente do fabricante do cartão de chip especifico.

Será assim tomado em consideração que é descrito um sistema de interface de cartão de chip. 0 sistema de interface suporta uma pluralidade de diferentes tipos de cartões de chip. Proporcionando uma pluralidade de módulos de interface e seleccionando um adequado de entre os módulos disponíveis para comunicar com o cartão de chip apresentado, o sistema proporciona a interacção com o cartão de chip apresentado de um modo específico ao cartão de chip. Assim, apesar de o invento ter sido descrito relativamente a uma representação preferida de uma aplicação num ambiente de transporte, pretende-se que o invento não esteja de forma nenhuma limitado, excepto no que é exigido pelas reivindicações anexas.

As palavras compreendem/compreendendo, quando utilizadas nesta especificação, são-no para especificar a presença de características, inteiros, passos ou componentes 23 mencionados, mas não exclui a presença ou acrescento de um ou mais caracteristicas, inteiros, passos, componentes ou grupos destes.

Lisboa, 12 de Setembro de 2008 24

Claims (20)

1. Reivindicações 1. Sistema de interface para um cartão de chip se contacto (CSC) para utilização com um equipamento hardware de processamento de CSC, incluindo o equipamento hardware uma antena RF (105) configurada para permitir a comunicação com um ou mais cartões de chip apresentados (100), e um terminal CSC (205) configurado para gerir os componentes de hardware periféricos, incluindo o sistema de interface um módulo universal de cartão de chip (USM) (200), sendo o módulo universal de cartão de chip (200) configurado para ser proporcionado entre a antena RF (105) e o terminal CSC (205), e sendo ainda configurado para comunicar com os cartões de chip sem contacto apresentados (100), incluindo o USM (200) uma pluralidade de módulos de interface (200A) , cada um da pluralidade de módulos de interface associado com o tipo de cartão de chip sem contacto especifico suportado, sendo o USM (200) configurado, após recepção de uma comunicação do CSC (100) através da antena RF (105), para determinar o módulo de interface correcto com o qual deve executar comunicações subsequentes com esse CSC (100) e para utilizar esse módulo de interface para essa comunicação subsequente, caracterizado por cada um da pluralidade de módulos de interface ser diferente de outros da pluralidade de módulos de interface na linguagem utilizada para interagir com o cartão de chip específico.
2. 2. Sistema de acordo com a reivindicação 1, caracterizado por o USM incluir meios para interrogar inicialmente um pedido de comunicação recebido de um CSC para determinar 1 a interface correcta para comunicação subsequente com esse CSC, baseado em factores seleccionados entre: a. fabricante b. tipo de cartão e / ou, c. aplicação
3. 3. Sistema de acordo com qualquer uma das revindicações precedentes, caracterizado por o USM incluir um módulo de interface de cartão lógico genérico configurado para permitir comunicação entre o USM e o terminal CSC numa linguagem independente da tecnologia CSC especifica escolhida.
4. 4. Sistema de acordo com qualquer uma das reivindicações precedentes, caracterizado por o USM incluir ainda um motor de integridade de cartão responsável por gerir vários ficheiros de dados, etiquetas e índices que estão associados com a estrutura das aplicações, ficheiros e campos de dados que estão distribuídos através de cada um dos tipos de cartões suportados.
5. 5. Sistema de acordo com qualquer uma das reivindicações precedentes, caracterizado por o USM incluir ainda um componente de Serviço de Segurança, estando o componente de Serviços de Segurança configurado para executar as funções criptográficas necessárias em comunicações entre o USM e um CSC apresentado. 2
6. 6. Sistema de acordo com a reivindicação 5, caracterizado por o componente de serviços de segurança ser proporcionado num módulo hardware de acesso de segurança (SAM) à prova de fraude.
7. 7. Sistema de acordo com a reivindicação 6, caracterizado por o SAM estar configurado para guardar uma pluralidade de chaves criptográficas, sendo as chaves necessárias para permitir a encriptação de comunicações entre o USM e um CSC apresentado.
8. 8. Sistema de acordo com qualquer uma das reivindicações precedentes, caracterizado por o USM incluir meios de comunicação configurados para permitir a comunicação sem fios entre um USM remoto e um computador central de controlo.
9. 9. Sistema de acordo com a reivindicação 8, caracterizado por o USM incluir um módulo de localização configurado para: a. permitir uma identificação da localização geográfica instantânea do USM e efectuar uma comunicação dessa localização do computador de central controlo, e / ou b. o processamento local, tal como o débito de tarifas com base na distância, que exige o conhecimento da localização. 3
10. 10. Sistema de acordo com qualquer uma das reivindicações precedentes, caracterizado por o USM incluir um módulo de software, tal como uma máquina virtual Java (JVM), estando o módulo de software configurado para permitir uma execução de um conjunto de processos algorítmicos e de referência que são: a. executados com a recuperação de dados do CSC, e b. executados para criar a nova informação a ser escrita de volta para o CSC durante a transacção.
11. 11. Sistema de acordo com a reivindicação 10, caracterizado por o conjunto de processos algorítmicos e de referência ser guardado numa cache local, localizada no USM.
12. 12. Sistema de acordo com as reivindicações 10 ou 11, caracterizado por incluir ainda um servidor de teste, estando o servidor de teste longe de mas em comunicação com o USM e incorporando um módulo separado de software, tal como uma JVM, relativamente ao localizado no USM, estando o servidor de teste configurado para permitir uma configuração de um ou mais processos algorítmicos e de referência e um teste do mesmo antes de uma comunicação destes processos ao USM.
13. 13. Sistema de acordo com qualquer uma das reivindicações precedentes, caracterizado por o USM permitir uma selecção de uma aplicação adequada, de uma pluralidade de aplicações disponíveis guardadas no CSC apresentado, 4 para processamento, comunicação subsequentes entre a aplicação seleccionada e sendo o USM que é conduzido através de um módulo de interface adequado.
14. 14. Sistema de acordo com qualquer uma das reivindicações precedentes, caracterizado por o USM permitir uma selecção de uma aplicação adequada para processamento a partir de uma pluralidade de aplicações disponíveis guardadas no CSC, dependendo do contexto no qual o CSC é apresentado ao USM.
15. 15. Processo para suportar múltiplos tipos diferentes de cartão de chip numa arquitectura de processamento de cartão de chip, incluindo a arquitectura de processamento de cartão de chip uma antena RF configurada para permitir comunicação com um cartão de chip sem contacto (CSC) apresentado e com um terminal CSC configurado para efectuar um processamento de componentes de hardware auxiliares da arquitectura, incluindo o método os seguintes passos: a. proporcionar módulos de interface múltiplos, estando cada um dos módulos associados com um tipo de cartão de chip específico, b. ao receber um pedido de comunicação inicial de um CSC apresentado através de uma antena RF, seleccionar um módulo de interface adequado de entre os múltiplos módulos de interface disponíveis para comunicação subsequente com esse CSC, e 5 por cada um dos múltiplos módulos de interface serem diferentes entre si na linguagem que utilizam para interagir com o cartão de chip especifico.
16. 16. Processo de acordo com a reivindicação 15, caracterizado por o tipo do cartão de chip ser definido por um ou mais dos seguintes: a. fabricante do cartão de chip, b. aplicação do cartão de chip guardado nesse cartão de chip.
17. 17. Processo de acordo com as reivindicações 15 ou 16, caracterizado por compreender ainda o passo de: a. guardar uma pluralidade de regras, determinando cada uma das regras como um cartão de chip especifico deve ser processado, sendo as regras guardadas numa linguagem independente desse tipo de cartão de chip específico.
18. 18. Processo de acordo com a reivindicação 17, caracterizado por incluir ainda o passo de, durante uma comunicação com um cartão de chip específico, traduzir as regras guardadas para uma linguagem adequada a esse tipo de cartão específico, e comunicar, nessa linguagem, essas regras ao cartão de chip específico. 6
19. 19. Processo de acordo com a reivindicação 18, caracterizado por incluir ainda o passo de encriptar qualquer comunicação com o cartão de chip.
20. 20. Programa de computador para gerir uma interface com cartões de chip seleccionados de entre uma pluralidade de cartões de chip, estando o programa adaptado para, quando correr num computador, executar os passos do processo de acordo qualquer uma das reivindicações 15 a 19. Lisboa, 12 de Setembro de 2008 7