ES2286822T3 - Procedimiento y dispositivos para el uso y la compensacion de medios de pago electronico en un sistema abierto e interoperable para la exaccion automatica de tasas. - Google Patents
Procedimiento y dispositivos para el uso y la compensacion de medios de pago electronico en un sistema abierto e interoperable para la exaccion automatica de tasas. Download PDFInfo
- Publication number
- ES2286822T3 ES2286822T3 ES96118760T ES96118760T ES2286822T3 ES 2286822 T3 ES2286822 T3 ES 2286822T3 ES 96118760 T ES96118760 T ES 96118760T ES 96118760 T ES96118760 T ES 96118760T ES 2286822 T3 ES2286822 T3 ES 2286822T3
- Authority
- ES
- Spain
- Prior art keywords
- payment
- data
- user
- message
- transponder
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/14—Payment architectures specially adapted for billing systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/322—Aspects of commerce using mobile devices [M-devices]
- G06Q20/3226—Use of secure elements separate from M-devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/352—Contactless payments by cards
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/363—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
- G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
- G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
- G07B15/06—Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems
- G07B15/063—Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems using wireless information transmission between the vehicle and a fixed station
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/0866—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means by active credit-cards adapted therefor
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Accounting & Taxation (AREA)
- General Physics & Mathematics (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Economics (AREA)
- Development Economics (AREA)
- Devices For Checking Fares Or Tickets At Control Points (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Coin-Freed Apparatuses For Hiring Articles (AREA)
Abstract
LA INVENCION SE REFIERE A UN PROCEDIMIENTO Y DISPOSITIVO PARA DESARROLLO AUTOMATICO DE PROCESOS DE PAGO SIN DINERO EN EFECTIVO, CON PREFERENCIA LIBRES DE TASA, EN PARTICULAR PARA EL COBRO AUTOMATICO DE DERECHOS DE UTILIZACION Y SIMILAR, ENTRE UN OFRECEDOR DE PRODUCTOS Y SERVICIO Y UN UTILIZADOR DE ESTE PRODUCTO O ESTE SERVICIO, QUE PAGA CON ELLO SEGUN MEDIOS DE PAGO SIN DINERO EN EFECTIVO, EN PARTICULAR ELECTRONICOS, TAL COMO TARJETA DE CREDITO, TARJETA DE DEBITO O UN MONEDERO ELECTRONICO. EL PROCEDIMIENTO PUEDE SER TAMBIEN UTILIZADO EN CONEXION CON UN SISTEMA DE PAGO, DONDE EL UTILIZADOR OBTIENE EL MEDIO DE PAGO A PARTIR DE UN EMITENTE, EN PARTICULAR UN BANCO O SIMILAR Y LA LIBERACION DEL PAGO CONSIGUIENDO LA CORRESPONDIENTE EXPLICACION DE LAS CARACTERISTICAS DEL PAGO, MIENTRAS SE OBTIENE LA RECEPCION DEL PAGO EN FORMA DE RECEPCION DE EXPLICACION, Y EL EMITENTE DEL OFRECEDOR DE LOS PRODUCTOS O SERVICIOS, EN PARTICULAR A TRAVES DE UN LUGAR (ADQUIRIDOR) DE CALCULO, EFECTUA EL PAGO DE LOS DERECHOS DE UTILIZACION O SIMILAR Y CON ELLO DE ACUERDO CON EL UTILIZADOR. LA DETERMINACION ASI COMO LA ENTREGA DEL PAGO, ENTREGA DE RECIBO Y REGISTRO DE PAGO SE CONSIGUEN A TRAVES DE TRANSFERENCIA DE DATOS SEGUN DATOS DE MOVIMIENTO CORRESPONDIENTE Y DATOS DE CALCULO A TRAVES DEL LUGAR DE INTERFAZ DE COMUNICACION ENTRE EL DISPOSITIVO DE PAGO Y EL DISPOSITIVO DE COBRO. LA ESTRUCTURA DE DATOS DE CALCULO SE ELIGE DE TAL MODO, QUE PUEDE SER UTILIZADA TAMBIEN PARA ELABORACION POSTERIOR POR EL EMITENTE Y EVENTUALMENTE POR EL ADQUIRIDOR.
Description
Procedimiento y dispositivos para el uso y la
compensación de medios de pago electrónicos en un sistema abierto e
interoperable para la exacción automática de tasas.
La invención se refiere a procedimientos y
dispositivos para el uso y la compensación de medios de pago
electrónicos en un sistema abierto e interoperable para la exacción
automática de tasas. Más concretamente, la invención se refiere a
aquellos procedimientos y dispositivos en los que el uso del medio
de pago electrónico se efectúa sin contacto mediante un dispositivo
autónomo del lado del usuario.
Los procesos de pago sin efectivo cobran cada
vez mayor importancia en el tráfico comercial, también y sobre todo
para el consumidor final. Esto lo muestran, en particular, la
introducción inminente de monederos electrónicos y la influencia
esperada de éstos en los hábitos de pago del consumidor final, así
como el número de titulares de tarjetas de crédito y débito que
está en continuo aumento, además del rápido aumento de terminales
para las tarjetas de este tipo en el sector del comercio al por
menor y de servicios.
Correspondientemente aumenta el interés y la
necesidad de posibilidades de pago sin efectivo también en el área
de la exacción de tasas para la entrada y el uso de instalaciones,
como edificios, carreteras, puentes, sistemas de transporte y
medios de transporte, etc. Ya a nivel nacional, pero aún mucho más a
nivel internacional, el desarrollo de los dispositivos de pago sin
efectivo correspondientes está sujeto a la condición real de que
las personas que son los potenciales pagadores de tasas están
equipadas para una pluralidad de sistemas de pago diferentes con
técnicas distintas. Un sistema de exacción de tasas aceptable debe
poder cooperar con el mayor número posible de sistemas de pago de
este tipo, es decir, debe estar configurado de forma abierta e
interoperable.
La invención se refiere a sistemas abiertos e
interoperables de este tipo para la tramitación automática de
procesos de pago, en particular, de exacciones de tasas. Más
concretamente, la invención se refiere a procedimientos para la
tramitación automática de procesos de pago sin efectivo,
preferiblemente sin contacto, en particular, para la exacción
automática de tasas y similares, entre un proveedor de prestaciones
o servicios y un usuario de estas prestaciones o de este servicio,
que paga por ellos con un medio de pago sin efectivo, en particular,
electrónico. Un ejemplo es el uso en la exacción automática de
tasas que se exigen para el uso de carreteras, garajes públicos y
otros servicios de valor añadido relacionados con ello por
vehículos.
En el ámbito político se discute la introducción
de una exacción automática de tasas (EAT) en función del tramo
recorrido en autopistas. Ésta debe realizarse sin efectivo,
respetándose la protección de datos y la seguridad del tráfico. Con
el ejemplo de este sistema EAT, a continuación se representarán las
condiciones previas y los requisitos de los procedimientos según la
invención.
El sistema de pago EAT debe basarse
preferiblemente en tarjetas con microprocesador que pueden usarse de
una forma universal, versátil y que están estandarizadas a nivel
internacional o también en tarjetas inteligentes, que se denominan
también ICC (Integrated Circuit Cards) o simplemente tarjeta chip.
Una ICC puede estar provista de diferentes aplicaciones, como por
ejemplo billetes, datos de identificación (pasaporte), monedero
electrónico, función de postpago (tarjetas de débito y de crédito),
etc.
El sistema de pago que ha de ser desarrollado
para EAT y otros fines de aplicación de este tipo puede ser tanto
un sistema de pago universal o también específico según el
transporte con las variantes postpago y prepago. El sistema de pago
puede usarse tanto a nivel regional (por ejemplo, tarjeta de
cliente) como también a nivel suprarregional (por ejemplo, monedero
nacional o internacional, tarjeta de crédito).
Generalmente, la ICC es una unidad de un sistema
global complejo, que comprende fabricantes de IC (el chip puramente
dicho) y de ICC, emisores de tarjetas y aplicaciones, proveedores de
servicios, empresas de compensación y procesamiento, Load Agents y
otros componentes/instituciones.
El requisito principal que deben cumplir el
sistema y las interfaces definidas para ello es la libertad de
elección del usuario de las aplicaciones que han de ser cargadas en
las tarjetas chip y del medio de pago que ha de ser usado para el
pago de prestaciones y servicios (aquí: servicios EAT).
Para garantizar la protección de datos, para la
protección frente a intentos de manipulación durante el proceso de
abono y adeudo y para comprobar la denegación de la prestación y del
pago, son necesarios refinados requisitos de seguridad de tipo
técnico, jurídico y organizativo para todas las instituciones/todos
los componentes que participan en el sistema.
El sistema debe permitir en la práctica una
tramitación segura pero rápida de los distintos procesos de pago.
Quedan excluidos simplemente por el tiempo necesario los
procedimientos y dispositivos conocidos para sistemas de puntos de
venta (point-of-sale), por ejemplo,
para el pago con tarjeta de pago, en los que la tarjeta debe
introducirse en un aparato lector, leerse allí y volver a entregarse
posteriormente una vez realizada la transacción. Menos todavía es
posible realizar consultas de control online de tipo habitual, sin
que deban surgir por ello problemas de seguridad.
Los requisitos esenciales del sistema, aquí el
sistema EAT, se describirán a continuación en dos grupos, es decir,
aquellos que resultan por aspectos de la protección de datos y
aquellos que resultan por otros aspectos funcionales.
\vskip1.000000\baselineskip
La protección de datos desempaña un papel
fundamental en el desarrollo y la implementación de un sistema para
la exacción automática de tasas.
A continuación, se describirán más
detalladamente los requisitos principales de la protección de datos
relacionados con el sistema de pago y el concepto de seguridad.
Por anonimato se ha de entender que los datos
personales sólo se almacenan en el lado del usuario. En este
contexto, también deben tenerse en cuenta correspondientemente el
pago anónimo y la compensación. Debe impedirse un ajuste de los
datos personales con ficheros centrales. En el caso del cumplimiento
(enforcement), los datos personales sólo deben revelarse cuando
existe una sospecha fundada.
Confidencialidad significa que los datos
personales deben protegerse para que no los conozcan personas no
autorizadas. El acceso a datos personales sólo debe tener lugar por
parte de organismos autorizados (con ayuda de una clave
correspondiente). El sistema también debe estar protegido
correspondientemente para que no puedan acceder terceros
("hackers").
La integridad significa que el usuario no debe
ser cargado de forma injusta y que los que participan en el sistema
deben poderse fiar de que los datos se generan, procesan, almacenan
y transmiten sin errores y en la forma debida. También forman parte
de la protección de la integridad la detección y la defensa ante
intentos de manipulación.
El criterio decisivo para la aceptación del
sistema es la comprensibilidad y la controlabilidad del
procedimiento para el organismo con capacidad de decisión y el
usuario. Esto se refiere, en particular, a la indicación o la
comprobación de procesos de adeudo, modificaciones, fallos
funcionales y cuentas agotadas, así como la posibilidad de detectar
medidas de cumplimiento. Además, el usuario debería estar informado
acerca de las informaciones que están almacenadas de forma
descentralizada a su nombre.
Por imposibilidad de revocación de la protección
de datos ha de entenderse que el sistema comprende un anclaje de la
protección de datos que no permite una posibilidad no controlada de
ser cambiada por explotadores o terceros.
\vskip1.000000\baselineskip
El sistema usado debe ser interoperable. La
interoperabilidad describe aquí la capacidad de un sistema
automático de exacción de tasas de actuar en conjunto de una forma
efectiva con otros sistemas en el entorno de la exacción de tasas
de uso para usuarios y explotadores. En el caso del ejemplo de la
EAT, la interoperabilidad se refiere a servicios de uso de
carreteras y de servicios de valor añadido, a sistemas de pago
(distintos emisores), a técnicas de transmisión (microonda,
infrarrojo, radio celular, etc.) y al uso paneuropeo. El sistema
global debe estar concebido para un número a elegir libremente de
explotadores de EAT y emisores de medios de pago, debiendo ser
posible reunir distintas funciones del sistema desde el punto de
vista organizativo.
Además, el sistema debe ser económico, es decir,
uso de infraestructuras existentes, interfaces externas iguales de
los componentes del sistema para todos los sistemas de pago.
El sistema debe cumplir los requisitos generales
de un sistema, aquí un sistema EAT, en cuanto a la fiabilidad en el
servicio (los fallos funcionales no deben ir a cargo del
usuario).
La integración de servicios de valor añadido
(transporte público de cercanías, control de tráfico, etc.) a
elección del usuario debe preverse o mediante la aceptación del
sistema de pago o mediante aplicaciones especiales.
Por supuesto, el sistema EAT también debe
cumplir las exigencias de la técnica de circulación, es decir, una
exacción fiable de tasas debe estar garantizada en todas las
situaciones de tráfico posibles y en todas las condiciones externas
concebibles.
De estos requisitos resultan directamente
requisitos especiales de los componentes del sistema (EAT), que son
los siguientes:
\vskip1.000000\baselineskip
Deben detectarse e impedirse en la mayor medida
posible las manipulaciones conscientes (sabotaje, fraude) e
inconscientes (fallos funcionales). Como protección contra
manipulaciones inconscientes son adecuadas distintas medidas
técnicas, como
- a)
- el uso de aparatos admitidos y certificados,
- b)
- la simplicidad y robustez de los aparatos y sistemas,
- c)
- la protección de datos mediante codificación con propiedades para detectar y solucionar errores,
- d)
- el control de los dispositivos instalados en la carretera y de forma central para impedir fallos y averías,
- e)
- la puesta a disposición de un centro de venta y de servicios potente.
Por lo contrario, las medidas indicadas sólo
permiten una protección insuficiente contra manipulaciones
conscientes. En lugar de ellas deben usarse para ello códigos
criptográficos, que deben usarse para la comunicación entre los que
participan en el sistema.
2. Desde el punto de vista organizativo, deben
separarse la exacción y el cumplimiento.
3. Debe anclarse de forma sistemática,
preferiblemente también de forma legal, la separación de los papeles
de cumplimiento, tramitación de pago, administración de cuentas y
tramitación de la comunicación.
El sistema de pago debe estar abierto respecto
al medio de pago utilizable, es decir, además de medios de pago
específicos según el transporte, también debe ser posible el uso de
medios de pago sin efectivo universales.
Como procedimiento básico está disponible el
prepago con una tarjeta con saldo activo anónima, alternativamente
a ello el postpago. El usuario debe tener la posibilidad de elegir
sin que ninguno de los dos procedimientos presente inconvenientes
(tasas de tramitación, precios de los terminales, etc.).
El usuario decide la forma de pago (prepago o
postpago, universal o específico según el transporte), es decir,
debe saber qué sistemas de pago se admiten.
Habitualmente, el usuario estará provisto de un
dispositivo de pago (OBE, On-Board Equipment), que
lleva consigo en su vehículo y que puede estar equipado de
distintas formas desde el punto de vista técnico y funcional. La
aplicación para el procesamiento, el almacenamiento y la transmisión
de los datos EAT (OBU, On-Board Unit (unidad de a
bordo) o transpondedor (transponder)) puede estar separada, por
ejemplo, en principio del medio de pago (por ejemplo, tarjeta chip)
o el medio de pago puede estar almacenado en una memoria del
dispositivo de pago, por ejemplo, como un número fijo de
compensación o como contador de unidades de valor.
Postpago: El emisor del medio de pago debe
conceder al proveedor de servicios una garantía de pago fiable;
prepago: la garantía de pago se realiza mediante el sistema, es
decir, las condiciones técnicas, así como los desarrollos
organizativos deben garantizar el pago del importe exigido.
El usuario debe recibir un comprobante del pago
realizado que debe poderse verificar con seguridad (recibo final) o
de su voluntad de pago (recibo provisional), debiendo estar limitado
el deber de conservación del mismo.
Debe estar garantizada la seguridad para
prevenir abusos en el sistema de pago. Esto significa entre otras
cosas que:
- a)
- el sistema debe detectar medios de pago no admitidos,
- b)
- sólo se admiten medios de pago autorizados y cargados de forma autorizada,
- c)
- el sistema permite la posibilidad de bloqueo de tarjetas individuales y/o grupos,
- d)
- el sistema impide de forma segura un adeudo no autorizado y
- e)
- el sistema está protegido contra la simulación de pago, por ejemplo, mediante la carga repetida de pagos ya usados, y contra la lectura de datos confidenciales por parte de terceros.
La seguridad de revisión debe estar garantizada
para todas las formas de pago. Esto significa que todas las deudas
activas son comprensibles y que está garantizada la designación
inequívoca de lugar, hora y fecha y de las personas que participan
en los procesos de pago.
La tramitación entre las partes implicadas debe
realizarse de forma rápida. Esto significa, una contabilización
cercana al tiempo real en el medio de pago (por ejemplo, tarjeta
chip) en caso de prepago y una anotación de valor a corto plazo en
todos los sistemas a favor de la caja de compensación.
El anonimato no debe influir negativamente en la
fiabilidad, la seguridad de revisión y la garantía de pago.
El sistema debe ser fácil de manejar, es decir,
las tarjetas chip deben ser reutilizables y las compensaciones deben
ser fáciles de comprender.
\vskip1.000000\baselineskip
En principio resulta una arquitectura de
seguridad que se caracteriza por dos dominios de seguridad
separables: la tramitación (EAT) y el sistema de pago. La función
de pago debe poderse separar desde el punto de vista de la técnica
de seguridad de la aplicación (EAT) teniéndose en cuenta medios de
pago universales y específicos según el transporte pagados
previamente y posteriormente. Gracias a la arquitectura debe
conseguirse, por un lado, que un proveedor de servicios pueda
emitir y aceptar su medio de pago propio, pudiendo determinar con
ello también por su cuenta los procedimientos de seguridad y, por
otro lado, que sea posible el uso de medios de pago universales de
emisores independientes con estructuras de seguridad de orden
superior.
Las interfaces de comunicación deben estar
asegurados desde el punto técnico y organizativo, además de
adaptarse a los sistemas de pago usados. También forma parte de
ello que todos los componentes del sistema están integrados en un
procedimiento institucionalizado para la admisión, la comprobación y
el control del sistema. La caja de compensación debe poder
comprobar si los registros de pago proceden de un medio de pago
auténtico y admitido. Deben estandarizarse los protocolos
necesarios para ello y la administración de claves
correspondientes.
El emisor administra los valores monetarios bajo
su responsabilidad. Las claves para asegurar los procedimientos de
pago están disponibles en el lado del emisor o de las instancias
encargadas por él y en el medio de pago. El sistema (EAT) debe ser
capaz de transmitir de una forma transparente los registros de pago
incluidos los certificados necesarios.
Implementación de un punto de admisión que es
competente para mantener la integridad del sistema, la
interoperabilidad, la garantía de pago y la cooperación segura.
Esto requiere una institucionalización de la admisión, de la
comprobación y del control de sistema de las unidades funcionales
que participan, los componentes usados y los medios de pago
admitidos; la admisión puede referirse a la aplicación local,
nacional o internacional. Esta función también puede ser asumida
por puntos de compensación nacionales/internacionales, que tramitan
tanto la compensación nacional como la internacional (por supuesto,
también deben ser posibles acuerdos bilaterales para el intercambio
de datos (apportionment) o tramitaciones de pago reguladas de forma
bilateral).
El sistema debe ofrecer una fiabilidad elevada,
es decir, todos los componentes centrales deben ser tolerantes a
errores. Para conseguir la fiabilidad requerida, también deben
usarse procedimientos criptográficos.
\vskip1.000000\baselineskip
- a)
- Los usuarios que han pagado correctamente no deben ser tratados como pagadores fraudulentos o no pagadores.
- b)
- Los usuarios que querían pagar correctamente no deben ser tratados como pagadores fraudulentos o no pagadores.
El cumplimiento sólo debería tener una
posibilidad de acceso a la última transacción. Por ejemplo, en un
procedimiento que trabaja con un dispositivo de pago del lado del
usuario y un dispositivo de exacción del lado del proveedor, para
ello se comprueben los siguientes factores: la existencia de un
dispositivo de pago admitido (OBE), la existencia de un dispositivo
de exacción capaz de funcionar (Road Side Equipment, RSE), el
momento, el lugar, el importe/tarifa del último pago, la validez
del medio de pago, la valoración de la tarifa respecto a la
clasificación del vehículo, dado el caso, el uso real, el tramo
recorrido hasta el momento del pago, la duración de la marcha al
realizar el recorrido, la situación de tráfico en el momento de la
exacción, la pertenencia a grupos. En un procedimiento en el que se
procede sin dispositivo de exacción (puntos de pago virtuales), se
realizan comprobaciones análogas trasladándose las funciones
fundamentales del dispositivo de exacción a un dispositivo
automático de pago.
El billete debería presentar el siguiente
contenido mínimo: ID del último punto de pago, la fecha y la
indicación de la hora con precisión de segundo, el importe pagado y
la moneda, el número correlativo del billete, características de
clasificación, certificado del proveedor de servicios.
El deber de conservación del billete debería
estar limitado hasta la siguiente salida.
\vskip1.000000\baselineskip
El dispositivo de pago debería presentar las
siguientes posibilidades de indicación:
- a)
- Importe de la tasa
- b)
- Saldo activo
- c)
- Se ha realizado/no se ha realizado el adeudo
- d)
- Posibilidad de comprobación de las funciones por parte del usuario (indicación de fallos).
Según la forma de realización, el dispositivo de
pago debería ser capaz de indicar o imprimir la memoria de
transacciones (billetes, procesos e intentos de adeudos) sólo para
el usuario.
Para la protección contra manipulaciones deben
tomarse medidas de seguridad de tipo lógico, técnico y físico para
el dispositivo de pago.
La realización del sistema según la invención se
realiza bajo la vigencia de normas generales, ya existentes, que
determinan el marco del intercambio de datos durante las
transacciones de este tipo. Han de indicarse, en particular, los
siguientes Working Items (WI) no públicos de la Organización Europea
de normalización CEN en el Comité Técnico 278:
- WI 1.1.1
- Integración de sistemas de pago
- WI 1.1.2
- Especificación de interface para la compensación entre operadores
- WI 1.2.1
- Requisitos AFC para DSRC
- WI 1.2.3
- Definición de interface AFC para DSRC
- WI 9.2.1
- DSRC capa 7
- WI 9.2.2
- DSRC medio y capa 1
- WI 9.2.3
- DSRC capa 2
También hay que tener en cuenta el llamado
documento base (Requisitos de sistemas de exacción automática de
tasas) del GK 717 AK 1 como comité espejo alemán del CEN TC 278 WG
1, que ha definido también el modelo de transacción alemán para la
interfaz aérea.
Estas normas sólo definen de forma limitada o de
ninguna manera los componentes del sistema, en particular los
contenidos de los datos y su uso.
En el estado de la técnica se han publicado
diversas propuestas para procedimientos para la tramitación
automática de procesos de pago sin efectivo.
Por la solicitud de patente internacional WO
95/10147 de Amtech Corporation se ha dado a conocer un sistema para
el registro de tasas en tiempo real para puntos de peaje de
autopistas y similares. Esta publicación trata sobre todo de una
anonimización lo más completa posible del proceso de pago, en el que
debe impedirse cualquier conclusión respecto al movimiento del
vehículo. El sistema trabaja con dispositivos de pago del lado del
usuario, que se denominan aquí "in-vehicle
units" y que cooperan con dispositivos de exacción en forma de
"roadside collection stations". En principio, el pago se
realiza mediante la entrega de cheques electrónicos almacenados en
tarjetas chip de los OBEs en "sobres" sellado de forma
criptográfica con ``abridores" correspondientes
(cryptographically sealed envelopes with openers", basados en la
tecnología de Chaum de "blind signatures" con cifrado
asimétrico). El proceso de pago se realiza en tres pasos y usa
estructuras de datos especiales para el cifrado del importe y de
determinados datos de autenticación, pudiendo usarse los datos así
estructurados exclusivamente para la comunicación en el punto de
pago. Si la tarjeta chip ya no dispone del importe necesario para
el pago, debe volver a cargarse previamente en un ordenador de banco
o similares, lo cual se realiza por lo visto de forma completamente
separada en cuanto a los datos de los datos estructurados
especialmente usados para el proceso de pago. En caso de que el
usuario pase sin pago por el dispositivo de exacción en lugar de
volver a cargar previamente la tarjeta chip en el punto de pago,
debe ser posible un post-payment permitiéndose al
proveedor el acceso a datos especiales de identidad del vehículo o
del conductor que están almacenados en el dispositivo de pago
mediante una conexión especial.
Aunque este sistema garantiza, por regla
general, que no pueda seguirse el uso de la prestación por parte
del usuario hasta llegar a éste, esto sólo es un requisito de un
sistema de este tipo, y en ningún caso siempre la más importante.
La apertura del sistema para medios de pago que debe permitir
justamente una identificación del medio de pago posterior al pago
del servicio e independiente, es otro requisito sumamente
importante, y un sistema en principio cerrado como el que se
describe en el documento WO 95/10147 forzosamente no puede cumplir
este requisito.
Por el documento EP-A1 0 401 192
se conoce un sistema de exacción automática de tasas para el uso de
un monedero electrónico para tasas de uso de carreteras. También
aquí se describe un dispositivo de pago del lado del vehículo, que
actúa en combinación con un dispositivo de exacción del proveedor de
la prestación. Como medios de pago se mencionan unidades de valor
pagadas previamente, tarjetas de crédito y también cobro por cargo
en cuenta.
El proceso de pago propiamente dicho comprende
una comunicación de dos pasos, sin entrega de recibo y con
protección criptográfica sólo para la transmisión de datos. Aunque
ésta no está detalladamente descrita, los datos de compensación,
que se intercambian entre el dispositivo de exacción y el
dispositivo de pago, parecen estar estructuradas especialmente para
la tramitación en la interfaz entre los dos dispositivos. En este
documento previamente publicado no se exige ni se describe una
estructura de datos que permitiría el procesamiento fácil y sin
problemas de los datos en el circuito global, incluidos el emisor,
la caja de compensación y similares. Este tipo de transacción de
pago tampoco refleja de ninguna manera los hábitos corrientes de un
proceso de pago en varios pasos mediante la indicación de la oferta
de servicio (a), la declaración de la voluntad de compra y pago
(b), la fijación del precio (c), la realización del pago (d) y la
entrega del comprobante de pago (e).
Por el documento EP-A2 0 577 328
(AT&T) se conoce, a su vez, un sistema de pago automático, en
particular una exacción electrónica de peaje del tipo ya
anteriormente mencionado. Este estado de la técnica describe una
comunicación de cinco pasos entre el dispositivo de pago y el
dispositivo de exacción, en la que se aplica un sistema de cifrado
especial con un número aleatorio que se cambia periódicamente
usándose una clave de tarjeta chip individual.
No se ofrece ninguna descripción de la
estructura de datos de los datos de compensación respecto a su
procesamiento posterior por parte del adquirente o emisor y
similares.
Por el documento EP-A2 0 616 302
se conoce un sistema electrónico de exacción para tasas de tráfico,
usándose un dispositivo de pago, en particular con tarjetas chip
pagadas previamente. Si bien se usan en este documento previamente
publicado también conceptos que podrían usarse en un sistema
abierto, en el que pueden usarse medios de pago electrónicos a
elegir libremente, no se describe como debería realizarse esto. No
se habla de la estructura de datos conforme en todos los pasos de
procesamiento del circuito de pago que sería fundamental para
ello.
Se dan a conocer descripciones de un carácter
general similar, por un lado, respecto a procedimientos para la
tramitación automática de procesos de pago sin efectivo, por otro
lado, respecto a tecnologías especiales para estos fines en los
documentos US 5,450,087; us 4,303,904; EP-A2 0 152
198; GB-A 2 278 704; WO 91/18354; WO 93/09621 y
EP-A1 0 609 453.
D5 da a conocer un procedimiento y una
disposición para la determinación de tasas de uso para vías de
tráfico y/o zonas de tráfico, calculándose con ayuda de un
dispositivo que se encuentra en el vehículo las tasas de uso
basándose el cálculo en datos de posición y datos de tarifas y
transmitiéndose las mismas mediante un sistema de transferencia de
datos a una oficina central. Las tasas de uso se suman aquí en el
dispositivo del vehículo hasta que alcancen un importe
predeterminado. A continuación, el dispositivo del vehículo
establece mediante una red de telefonía móvil una comunicación con
la oficina central. Los datos de las tasas correspondientes y los
datos que identifican el monedero deudor que ha de ser cargado se
transmiten a la oficina central. Además, la memoria en el
dispositivo del vehículo se hace retroceder deduciéndose el importe
calculado. Dicho de otro modo, la tasa correspondiente se adeuda en
primer lugar de forma local en una tarjeta chip en una cuenta
intermedia (interna) transfiriéndose a continuación junto con otros
datos a una oficina central y deduciéndose de una cuenta de
usuario.
Todos estos documentos previamente publicados
tienen en común que no hacen referencia a requisitos fundamentales
para un sistema abierto e interoperable que pueda hacerse funcionar
con el menor esfuerzo posible y al mismo tiempo con seguridad o que
lo excluyen incluso por sus medidas concretas. Ninguno de estos
documentos objetados describe un procedimiento del tipo según la
invención, en el que, a pesar de garantizarse normas de seguridad y
anonimato, la tramitación del proceso de pago entre el usuario y el
proveedor de la prestación o del servicio está concebido de tal
forma que las estructuras de datos usadas puedan usarse sin procesos
complicados de transformación u otros pasos de procesamiento
también para otros procesos de tramitación entre el proveedor y el
adquirente, entre el adquirente y el emisor, así como entre el
usuario y la agencia de venta o entre ésta y el emisor, como se
explicará a continuación más detalladamente.
Un objetivo fundamental de la invención es
llenar las lagunas que quedan también en la normalización, en
particular, respecto a la generación, función y el uso unificado de
datos relevantes para el pago, por un lado, en combinación con el
hardware usado según la invención y, por otro lado, en el contexto
del sistema según la invención.
Otro objetivo fundamental de la invención es
indicar procedimientos y dispositivos del tipo indicado al principio
con los que sea posible realizar en un tiempo mínimo un pago sin
efectivo automatizado fiable y seguro, respetándose la protección de
datos.
También es un objetivo de la invención permitir
una exacción automática de tasas sin efectivo sin perjudicar en
gran medida la fluidez del tráfico ni la velocidad de los
vehículos.
Para conseguir estos objetivos, los
procedimientos y dispositivos deben estar configurados de tal forma
e interactuar de tal forma que puedan usarse tanto medios de pago
especiales como universales, pagados previamente y posteriormente,
para el pago en un sistema para el pago o la exacción automáticos de
tasas debiendo mantenerse para la compensación en gran medida las
vías de comunicación de pago ya practicadas hoy día entre
proveedores de servicios y el mundo bancario.
\newpage
Según la invención, estos objetivos se consiguen
mediante las características de las reivindicaciones
independientes.
De las reivindicaciones respectivamente
subordinadas resultan formas de realización ventajosas.
El modelo de sistema al que está orientado el
desarrollo del procedimiento según la invención, en particular del
sistema de pago EAT descrito a continuación, está basado en el
borrador estándar del CEN TC 278 "Especificación de interface
para la compensación entre operadores". Este modelo representado
en el diagrama 1 distingue entre los siguientes cinco
componentes:
- -
- el usuario, que usa un servicio empleando un medio de pago,
- -
- el proveedor, que ofrece un servicio a usuarios,
- -
- la caja de compensación, que recibe datos de transacciones de distintos proveedores de servicios y los transmite a los emisores correspondientes de medios de pago,
- -
- el emisor, que explota un sistema de pago y
- -
- el Collection Agent, que realiza la venta o la carga de medios de pago para un emisor (agencia de venta, instancia de carga).
Diagrama
1
CEN TC 278 Modelo del
sistema
La caja de compensación se denominará en lo
sucesivo también adquirente.
En el modelo del sistema representado, las
flechas del círculo interior corresponden al flujo de los datos
relevantes para el pago, las flechas en el círculo exterior a las
relaciones (de la compraventa o del servicio) monetarias y
materiales.
La separación funcional entre las aplicaciones
del sistema de pago y de la exacción automática de tasas decisiva
para la concepción del sistema de pago EAT ya está preparada en este
modelo mediante la distinción fundamental entre el emisor (del medio
de pago) y el proveedor de servicios.
En un modelo aún más diferenciado, que forma la
base propiamente dicha para el desarrollo del concepto, hay que
tener en cuenta que
- -
- el uso de un medio de pago en un entorno como el entorno EAT sólo es posible "sin contacto", puesto que el intercambio de datos relevantes para el pago se realiza mediante una transmisión por radio en el intervalo de microondas o infrarrojo (DSRC - Dedicated Short Range Communication) o mediante radio celular (por ejemplo, GSM - Global System for Mobile Telecommunication),
- -
- la separación de datos de movimientos y de pago requerida por motivos relacionados con la protección de datos y la limitación de los datos introducidos en los movimientos de pagos, deseada por cuestiones económicas, entre otras, sólo son posibles por una agregación correspondiente de datos de las transacciones en un punto concentrador del proveedor de servicios, y
- -
- los intereses de todos los que participan en el sistema también deben ser protegidos mediante medidas organizativas y jurídicas.
La invención lo permite en el procedimiento
reivindicado según la reivindicación 1 adjunta.
En los procedimientos definidos en la
reivindicación 1, el modelo arriba descrito se complementa con los
componentes
- -
- medio de pago (payment means), con ayuda del cual el usuario realiza el proceso de pago,
- -
- dispositivo de pago en forma de un On-Board Equipment (OBE), que recibe, por un lado, la opción de pago de un usuario (pago por monedero o pago por cuenta, según el medio de pago empleado), y que realiza, por otro lado, el pago propiamente dicho de las tasas mediante EAT por orden del usuario y previa solicitud explícita o implícita del proveedor de servicios mediante el transpondedor (OBU, On-Board-Unit),
- -
- punto de pago en forma de un Road Side Equipment (RSE), que representa el punto de pago EAT de un proveedor de servicios (Service Provider) y que se encarga de la exacción de tasas de los vehículos que pasan o que emite tickets de entrada, o en forma de un Road-Side Equipment virtual, que permite en un dispositivo de detección del lado del usuario el inicio y la realización autónoma del pago por parte del usuario;
- -
- concentrador de un proveedor de servicios, que separa los datos de movimientos de los datos de pago de las transacciones EAT y que transmite las deudas activas acumuladas a los adquirentes,
- -
- punto de control EAT (cumplimiento), que puede hacer que un dispositivo de pago (OBE) compruebe el último pago realizado, y
- -
- instancia de admisión (Certification Authority), que garantiza que sólo pueden usarse aquellos componentes del sistema que cumplen todos los requisitos necesarios, como por ejemplo, de la protección de datos, la seguridad IT, la posibilidad de revisión y la justiciabilidad de acuerdos (relaciones contractuales).
En el diagrama 2, el modelo del sistema está
representado con más detalles.
En un sistema EAT interoperable, supranacional y
abierto (respecto a los medios de pago), la seguridad de todos los
participantes del sistema sólo puede garantizarse mediante una
combinación de medidas técnicas, organizativas y jurídicas, cuyo
cumplimiento es controlado por una instancia de admisión, lo cual
conduce a una institucionalización del sistema global.
Sin la acción de conjunto de técnica,
organización, derecho e institucionalización, no está realizada una
configuración abierta del sistema, que deja a todos los
participantes del sistema la mayor autonomía para tomar decisiones
posible en el marco de las condiciones marco generalmente
obligatorias.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
(Diagrama pasa a página
siguiente)
\newpage
Diagrama
2
Modelo del sistema del
concepto
Un requisito fundamental en el procedimiento o
sistema de exacción automática de tasas (EAT) es que no deben
procesarse ni almacenarse datos relacionados directamente con las
personas ni los vehículos. Todo el proceso de exacción cerrado en
sí está configurado de tal forma que no se generen trazas de datos
que puedan seguirse. En principio, el procedimiento EAT se divide
en tres áreas separadas, en las que debe tenerse en cuenta este
requisito, respectivamente:
- 1)
- la determinación de las tasas con los pasos información acerca de la oferta de servicio (a), declaración de la voluntad de compra y de pago (b), determinación del precio (c).
- 2)
- el proceso de pago
- 3)
- la entrega del recibo.
La determinación de las tasas puede realizarse
en el diálogo entre el dispositivo de pago, en el caso del ejemplo,
el transpondedor transportable o la OBU
(On-Board-Unit) con la tarjeta de
pago y el dispositivo de exacción, en el caso del ejemplo, el
emisor de consultas estacionario o RSE
(Road-Side-Equipment). Según la
reivindicación 2, la determinación de las tasas se realiza en el
dispositivo de pago del usuario sin acción externa (es decir, de
forma autónoma) debido a la valoración de una tabla almacenada o al
resultado de un algoritmo correspondiente. No es necesaria la
transmisión de datos de personas ni vehículos (individuales), ni
tampoco el almacenamiento de datos.
Es ventajoso que el usuario puede decidir
durante el proceso de pago qué medio de pago (admitido) va a
emplear.
A continuación, se describirán más
detalladamente la función y las opciones de realización de los
distintos componentes del sistema:
- -
- medio de pago,
- -
- On-Board Equipment,
- -
- Road-Side Equipment,
- -
- concentrador,
- -
- adquirente,
- -
- emisor,
- -
- collection agent
- -
- punto de control EAT (cumplimiento) e
- -
- instancia de admisión (institucionalización).
El concepto medio de pago se refiere a la forma
en la que un usuario, es decir, comprador de servicio en el sistema
EAT (sin efectivo), paga el servicio de un proveedor de servicios y
comprende todas las funciones y datos necesarios para el proceso de
pago y su aseguramiento. En principio, deben admitirse para la
exacción automática de tasas cualquier tipo de medios u opciones de
pago, debiendo tener el usuario en principio libertad de elección
(es decir, los mismos importes de tasas para todos los medios de
pago admitidos):
- -
- prepago (prepayment), mediante el empleo de un monedero electrónico o postpago (postpayment) mediante la indicación de una cuenta de crédito o débito,
- -
- el empleo de un medio de pago universal (es decir, independiente del servicio) o de un medio de pago (por ejemplo, EAT) específico según el transporte,
- -
- el empleo de un medio de pago que se acepta a nivel regional (por ejemplo, medio de pago válido a nivel regional de un explotador de autopistas) o a nivel suprarregional (por ejemplo, monedero nacional) o internacional (es decir, la instancia de admisión prescribe a nivel supranacional que todos los proveedores de servicios EAT han de aceptarlo como medio de pago).
La separación básica entre las aplicaciones del
medio de pago y la exacción automática de tasas y la posibilidad de
uso de un medio de pago universal en la exacción automática de tasas
hacen que sea necesario que como soporte para el medio de pago se
use un medio técnicamente madurado, económico, generalmente aceptado
y sobre todo seguro. Por lo tanto, en el concepto se parte de que
el medio de pago representa generalmente una aplicación en una
tarjeta chip estándar multifuncional. Las tarjetas chip que pueden
emplearse de forma universal de este tipo se habrán extendido en
pocos años ampliamente como soportes de monederos electrónicos
sustituyendo el dinero en efectivo, por lo que deben ser admitidas
en principio también para la exacción automática de tasas EAT.
Gracias a este planteamiento, en la realización
técnica del dispositivo de pago, es decir, el
On-Board Equipment (OBE), como por ejemplo, en el
diagrama 2, existe la posibilidad de que la tarjeta chip no sólo
puede ser el soporte del medio de pago sino que también puede
contener la aplicación de la exacción automática de tasas (véase el
párrafo siguiente).
Por otro lado, mediante este planteamiento no
debe excluirse que en la forma de realización más sencilla un medio
de pago específico según el transporte sea parte integrante
(funcional) del On-Board Equipment. Por ejemplo, al
pasar por una frontera debe ser posible adquirir un OBE en préstamo,
en cuya memoria (por ejemplo, chip EEPROM) esté cargado un
determinado importe disponible pagado previamente.
En principio, al emplear un medio de pago en un
sistema EAT (al igual que al pagar por cualquier otro servicio),
debe estar garantizado que la técnica no pueda omitir los acuerdos
jurídicos que han de fijarse entre los emisores de los medios de
pago, los adquirentes y los proveedores de servicios. En particular,
deben cumplirse los requisitos relevantes para la seguridad en los
que se basa la garantía de pago frente al proveedor de servicios,
lo cual debe asegurarse mediante la institucionalización. Por lo
tanto, deben poderse salvaguardar los diferentes intereses de
emisores y proveedores de servicios en principio mediante dominios
de seguridad separados.
Por consiguiente, en el concepto se parte de que
tanto la aplicación del medio de pago como también la aplicación de
la exacción automática de tasas pueden tener en principio sus
procedimientos de seguridad propios, separados unos de otros, que
en la normalización (por ejemplo, para el monedero electrónico) se
denominan Security Application Module (SAM).
Un SAM debe usarse siempre cuando deben existir
funciones de seguridad especialmente sensibles para la protección
de transacciones, y el mismo está formado por un componente software
y un componente hardware. El componente software está formado por
una lógica de control de ejecución para la aplicación que ha de ser
protegida y contiene algoritmos de cifrado, claves criptográficas
secretas y otros datos y parámetros relevantes para la seguridad,
mientras que el componente hardware sirve para la protección de las
funciones de seguridad propiamente
dichas.
dichas.
Según la invención, los dos SAMs pueden ser
idénticos. Esto permite que en caso de una forma de realización de
OBE sencilla o en caso de que un proveedor de servicios EAT emite su
medio de pago propio, las dos aplicaciones forman un dominio de
seguridad común usando, por lo tanto, los mismos mecanismos de
seguridad y claves.
Según la invención, preferiblemente está
previsto que una tarjeta chip que es soporte del medio de pago,
aunque no de la aplicación EAT, tenga un SAM propio, mediante el
cual pueda comprobarse o asegurarse la legitimidad del uso del medio
de pago en un sistema EAT.
Además, es preferible que por razones de la
aceptación e interoperabilidad sólo se usen tarjetas chip cuyas
propiedades físicas y eléctricas estén definidas en la norma ISO
7816, parte 1-3 o en la prenorma CEN prENV 1855. El
modelo de datos lógico interno del chip está definido en
7816-5 mediante una estructura de árbol, que
presenta como nivel superior un directorio principal (Master File,
MF) bajo el cual existen determinados ficheros (Elementary File,
EF) o subdirectorios (Dedicated File, DF). Esta forma de
estructuración de datos está prevista preferiblemente también para
las aplicaciones y datos que se encuentran en la OBU, sobre todo en
el caso de la opción de realización OBE I "solución compacta",
que se describirá más adelante.
El MF es creado por el fabricante de la tarjeta
y es personalizado por el emisor de la tarjeta, es decir, se
escriben o, en caso de existir ya previamente, se modifican los Efs
directamente subordinados. El directorio principal de la tarjeta
contiene informaciones generales acerca de la tarjeta y sus
propiedades (datos para la fabricación de chip, módulo y tarjeta,
características técnicas, aplicaciones disponibles y posibilidades
de selección, fecha de activación y caducidad, identificación del
país, etc.), acerca del titular de la tarjeta (nombre, preferencia
de idioma, protección PIN, etc.) y acerca de los mecanismos y datos
de seguridad independientes de la aplicación.
Cada subdirectorio en el siguiente nivel
corresponde a una aplicación y se crea según la elección del titular
de la tarjeta y bajo la responsabilidad del emisor de la tarjeta o
se personaliza y, dado el caso, actualiza, bajo la responsabilidad
del emisor de la aplicación. Un subdirectorio puede estar formado
por otros subdirectorios o ficheros individuales.
Con esta estructuración lógica de datos es
posible soportar la separación funcional entre los diferentes
participantes en la fabricación del módulo, la preparación de la
tarjeta y la entrega de la tarjeta y aplicación, así como la
independencia jurídica entre los diferentes emisores de aplicaciones
también desde el punto de vista técnico de tal forma que puedan
impedirse con seguridad, por ejemplo, interacciones no deseadas
entre diferentes aplicaciones y los mecanismos de seguridad de las
mismas. En este contexto es especialmente importante la norma ISO
10202, que define la arquitectura de seguridad de tarjetas de
crédito y débito.
Un elemento fundamental de la invención es la
realización de actos de uso de medios de pago por parte del
dispositivo de pago en lugar de por el usuario, de modo que se
automaticen estos actos. Para los sistemas EAT y sistemas
comparables que trabajan con los procedimientos según la invención,
el dispositivo de pago está realizado preferiblemente en forma del
On-Board-Equipment (OBE) ya
indicado. El dispositivo de pago se encarga en un grado
respectivamente diferente de la tramitación del proceso de pago y
los OBE están equipados correspondientemente de distintas
formas.
El dispositivo de pago puede encargarse, por
ejemplo, fundamentalmente sólo de los pasos del procedimiento
reservados para el usuario, mientras que los pasos del procedimiento
típicos para el proveedor son realizados por el dispositivo de
exacción.
Según la reivindicación 1, el dispositivo de
pago se encarga adicionalmente de las funciones esenciales del
dispositivo de exacción, en particular, de proporcionar los datos
que representan la tasa, que ha de ser pagada, etc. así como de
realizar y registrar el pago y de crear y almacenar el recibo.
El control del pago efectivamente realizado por
parte del proveedor, que en ambos casos es deseable, se realiza en
principio de la misma forma, aunque puede presentar diferentes
características técnicas. Por ejemplo, la comprobación de los datos
almacenados en el dispositivo de pago respecto a los comprobantes de
pago sólo es posible de forma aleatoria o de caso en caso o, en
caso de la reivindicación 1, también de forma periódica, por
ejemplo, después de un número configurable de procesos de pago,
respectivamente, de forma automática mediante el establecimiento de
una interfaz de comunicación adecuada con un punto de control EAT
(virtual). En cualquier caso, en la realización de la invención
será en la mayor parte de los casos preferible no unir la función
de control fijamente al dispositivo de exacción, para evitar un
esfuerzo desproporcionado (se denomina control separado a
diferencia del control integrado). Los controles de este tipo se
realizan también en la mayoría de los casos en un lugar y un
momento posterior al desarrollo de la tramitación de pago según la
invención.
A continuación, la invención se describirá en
primer lugar más detalladamente con ayuda de un ejemplo de
realización de un OBE, en el que el dispositivo de pago y el
dispositivo de exacción forman una interfaz de comunicación,
entendiendo el experto, no obstante, sin más que partes
considerables de esta descripción también son válidas para la
realización según la reivindicación 1.
Puesto que para la exacción automática de tasas
entre el medio soporte del medio de pago y la instalación de
exacción de tasas del proveedor de servicios queda excluido un
intercambio de datos con contacto para el proceso de pago, la
comunicación entre los dos componentes del sistema se realiza
mediante una transmisión por radio, que por parte del usuario es
realizado por el On-Board Equipment (OBE) en el
vehículo (interfaz aérea).
Además de las duras restricciones en cuanto al
tiempo en el caso de una comunicación a corta distancia mediante la
interfaz aérea a velocidad máxima, el requisito de la separación de
los datos de movimiento y de pago relacionados con el derecho de la
protección de datos y el requisito de rentabilidad de la limitación
de las cantidades de datos relevantes para el pago, son las razones
más importantes de tener que distinguir al usar un medio de pago en
forma de monedero universal generalmente, es decir, en el caso de
dominios de seguridad separados, entre el importe disponible
certificado que se administra en el On-Board
Equipment y las tasas individuales que han de descontarse del
mismo.
Esto significa, en particular, que para el
proceso de pago en la mayoría de los casos no es posible una
comunicación directa entre el medio de pago y el punto de exacción
de tasas, sino que la confirmación de pago de una tasa EAT se
transmite junto con el importe disponible certificado o la
información acerca de la cuenta certificada al punto de exacción de
tasas. Antes de transmitir el proveedor de servicios la deuda activa
individual (es decir, de cada una de las tasas cobradas de forma
automática) al adquirente, se produce una agregación de las
informaciones relevantes para el pago respecto a los datos
certificados por el medio de pago.
En los casos en los que es posible una
comunicación directa entre el medio de pago y el punto de exacción
de tasas (por ejemplo, por una comunicación
end-to-end entre la tarjeta chip y
el Road-Side-Equipment) o en los
que un proveedor de servicios emite sus medios de pago propios,
puede renunciarse eventualmente a una certificación adicional del
importe de adeudo durante un pago EAT.
Desde el punto de vista de la concepción, el
On-Board Equipment está formado por las siguientes
unidades funcionales que han de separarse a nivel lógico:
- -
- el sistema de comunicación: esta parte técnica del OBE tramita la parte del protocolo de comunicación relacionada con la transmisión en la interfaz aérea (por ejemplo, DSRC o GSM) y, dado el caso, en función de la forma de realización técnica, véase abajo, el protocolo de la tarjeta chip (por ejemplo, T=1 según ISO 7816-3) y se encarga del mando de los elementos de mando, pantalla, lámparas de control, etc.;
- -
- la aplicación ETA: esta unidad funcional lógica se activa por acciones que son iniciadas por el usuario, los sistemas de exacción de tasas de un proveedor de servicios, el componente de localización para puntos de pago virtuales o los puntos de control EAT, tramita el procesamiento y el almacenamiento de datos relacionados con la EAT y la parte relacionada con la aplicación de la comunicación con otros componentes del sistema y administra una o varias memorias de tickets; puede ser parte integrante de esta unidad funcional el EAT-SAM, que garantiza con mecanismo criptográficos, en particular, la autenticidad y la realización correcta de una exacción de tasas, del proceso de pago y del comprobante de pago; y
- -
- el medio de pago: la unidad funcional lógica del medio de pago, que se activa por la iniciación de la aplicación EAT o una instancia de carga y que interactúa con éstas está separada de la aplicación EAT; el medio de pago tiene generalmente un SAM propio, que asegura las transacciones relevantes para pagos con el mundo externo (por ejemplo, punto de aceptación de la tarjeta o instancia de carga, aquí: aplicación EAT).
Los componentes técnicos del OBE, como teclas,
pantalla, contactos, etc. no se explicarán en este contexto, puesto
que son irrelevantes para la concepción funcional. Estos componentes
son en principio conocidos en el estado de la técnica.
Diagrama
3
Estructura lógica de un
On-Board
Equipment
El diagrama 3 representa la estructura lógica
del OBE.
\global\parskip0.900000\baselineskip
Según la invención, gracias a esta concepción
son posibles varias opciones de realización.
- Opción I: "Solución compacta"
En la forma de realización más sencilla, el OBE
está formado por una única unidad técnica, que integra todas las
unidades funcionales lógicas (en este caso, coinciden OBE y OBU y
forman el dispositivo de pago). Esta forma puede usarse, por
ejemplo, para adquirir al cruzar al pasar por la frontera un OBE en
préstamo, que está cargado en una memoria interna con un
determinado importe disponible pagado previamente, que puede
gastarse sucesivamente y volver a cargarse en equipos de carga
especiales. Esto corresponde a las propiedades de un medio de pago
pagado previamente, específico según el transporte y nacional.
Esta variante también es adecuada cuando unos
clientes importantes acuerdan, por ejemplo, condiciones especiales
con proveedores de servicios y el pago se realiza a través de una
cuenta central. Esto corresponde a las propiedades de un medio de
pago pagado posteriormente, específico según el transporte y
regional o suprarregional.
En esta forma de realización puede estar
previsto de forma especialmente ventajosa que el módulo lógico de
datos y aplicación de la OBU presente una estructura como en el caso
de una tarjeta chip, puesto que todas las unidades funcionales
lógicas están unidas recomendablemente por razones económicas en un
solo chip. Además, gracias a sus propiedades técnicas y lógicas, un
chip puede emplearse en determinadas condiciones previas como
módulo de seguridad hardware, de modo que en principio pueden
reunirse funcionalmente los dos SAM de aplicación, puesto que
finalmente sólo debe asegurarse la comunicación mediante la interfaz
aérea.
- Opción II: "Solución con
transpondedor"
En esta forma de realización, el sistema de
comunicación está técnicamente separado del medio de pago y de la
aplicación EAT, que están unidos de forma conjunta en una tarjeta
chip estándar. En el caso de un medio de pago específico según el
transporte, también en esta variante es posible reunir el SAM de la
EAT y el SAM del medio de pago desde el punto de vista
funcional.
Por otro lado, es concebible que los emisores de
la aplicación EAT y del medio de pago sean instituciones
jurídicamente independientes o que el medio de pago tenga carácter
universal, de modo que la relación jurídica entre el proveedor de
servicies EAT y el emisor del medio de pago deba protegerse también
en razón de la seguridad (es decir, de forma criptográfica). En
este caso, las dos aplicaciones pueden tener en principio su SAM
propio para la separación de los dominios de seguridad, debiendo
controlarse la interacción de los SAMs mediante una gestión de
claves correspondiente.
- Opción III: "Solución
estándar"
Otra alternativa está en que el sistema de
comunicación reside junto con la aplicación EAT en la
On-Board Unit, mientras que el medio de pago está
integrado en aun tarjeta chip estándar completamente separada de
ésta. De esta forma se soporta en el concepto también el pago con
monederos electrónicos universales, que en el futuro se emplearán
ampliamente como sustituto del dinero en efectivo. En el concepto
para el pago de tasas EAT también puede usarse cualquier otro medio
de pago universal admitido basado en tarjetas chip estándar.
- Opción IV: "Solución de 2 tarjetas
chip"
La forma de realización más costosa que, no
obstante, ofrece también la mayor flexibilidad, permite tarjetas
chip separadas para las aplicaciones del medio de pago y EAT, lo
cual es poco razonable sin la independencia jurídica de los
emisores correspondientes. Por lo tanto, aquí ha de partirse siempre
de la existencia de un SAM del medio de pago y un SAM de la
aplicación EAT separado del otro, puesto que independientemente de
las propiedades del medio de pago debe anclarse técnicamente y
asegurarse siempre la relación jurídica entre los emisores. En este
caso, la OBU se limita desde el punto de vista funcional al sistema
de comunicación, que está montado, por ejemplo, fijamente en un
vehículo y que está provisto de dos lectores de tarjetas chip.
Siempre está previsto que las transacciones EAT
realizadas respectivamente en último lugar (el número total es
independiente de la forma de realización del OBE) queden almacenados
siempre en la memoria de transacciones, para que el usuario tenga
la posibilidad de comprobar los últimos pagos. Además del control de
los tickets por pantalla, para cada opción está previsto un
procedimiento para imprimir adicionalmente los comprobantes de
pago.
En la opción I, esto puede permitirse, por
ejemplo, porque la OBU se retira del vehículo y la memoria de
transacciones se imprime en un lector (de la instancia de carga o
de la agencia de venta). En el caso de las opciones II, III y IV,
la memoria de transacciones puede estar en lugar de ello en una
tarjeta chip y puede imprimirse correspondientemente en un lector de
tarjetas chip externo.
Además, el OBE dispone de otras indicaciones
ópticas y acústicas, con las que pueden señalizarse determinados
estados de servicio y de las transacciones (importe de las tasas,
saldo activo, pago realizado o no realizado, caída de tensión,
cumplimiento etc.).
\global\parskip1.000000\baselineskip
Como Road-Side Equipment (RSE)
se denomina en este concepto, por regla general, aquel terminal de
un proveedor de servicios EAT que establece una relación por
comunicación con un On-Board Equipment de un usuario
de un servicio para la exacción automática de tasas en un punto de
pago o para la emisión de tickets de entrada en un punto de
entrada.
La forma de realización típica para la exacción
de tasas para el uso de carreteras está basada en estaciones de
exacción que están instaladas en la carretera y que realizan un
intercambio de datos con los vehículos que van pasando mediante
microonda o infrarrojo. No obstante, mediante este concepto se
soportan también aquellos sistemas EAT que no sirven para la
exacción de tasas para el uso de carreteras sino, por ejemplo, de
tasas de garajes públicos.
Además, existen sistemas EAT basados en GNSS
(Global Navigation Satellite System, por ejemplo, GPS) que o
funcionan de forma autónoma (en el sentido del ejemplo de
realización según la reivindicación 1) (es decir, pago de la tasa
sólo mediante un procesamiento de datos interno del dispositivo de
pago, en particular, sin comunicación externa) o que establecen una
comunicación por radio, por ejemplo, mediante GSM, con un punto de
exacción externo. En estos casos, el impulso para el pago de las
tasas se realiza por alcanzar una posición geográfica determinada
que es detectada por un módulo de localización interno del vehículo
(por ejemplo, mediante la recepción de señales GPS y ajuste con un
mapa digital), de modo que frecuentemente se habla también de un
punto de pago virtual o de un Road-Side Equipment
virtual.
Las unidades funcionales más importantes del RSE
son:
- -
- el módulo de control EAT, que establece la comunicación relacionada con la aplicación a través de la interfaz aérea tanto de forma periódica como de forma orientada a eventos, que realiza la determinación y exacción automática de las tasas o la emisión de tickets para los vehículos detectados y que procesa los datos relevantes para el pago; puede formar parte integrante de esta unidad funcional un SAM, que controla fiablemente la integridad y autenticidad de datos, eventos e interlocutores de la comunicación con mecanismos criptográficos.
- -
- El sistema de comunicación, que comprende, por un lado, el dispositivo emisor y receptor para la parte de la técnica de transmisión del protocolo de comunicación en la interfaz aérea y que se encarga, por otro lado, de la transmisión o transferencia de ficheros de las transacciones para la introducción en los movimientos de pagos, y
- -
- dado el caso, una memoria de transacciones, en la que pueden acumularse los datos relevantes para los pagos de transacciones EAT, almacenarse de forma intermedia y, dado el caso, concentrarse previamente.
En el caso general, el RSE está conectado
mediante una línea de comunicación con un host del proveedor de
servicios (por ejemplo, el concentrador), transmitiéndose mediante
esta línea de forma periódica, por ejemplo, diaria, los datos
relevantes para los pagos acumulados de forma local en un protocolo
correspondiente. En sistemas especiales (por ejemplo, autómata de
un garaje público), también es posible que la memoria de
transacciones esté realizada como tarjeta chip o disquete, cuyo
contenido puede introducirse en los movimientos de pagos mediante
intercambio del medio de memoria, o que la memoria de transacciones
se vacíe mediante una comunicación por radio.
Diagrama
4
Estructura lógica de un
Road-Side
Equipment
El diagrama 4 representa la concepción lógica
del RSE.
En caso de un medio de pago anónimo, específico
según el transporte y pagado previamente, en el módulo de control
EAT puede realizarse una agregación previa de los datos relevantes
para el pago de tal forma que ya sólo se transmitan sumas de tasas
al host.
Los mecanismos de seguridad del SAM son usados
por el módulo de control EAT preferiblemente para proteger tanto
los procesos automáticos de pago a través de la interfaz aérea
contra manipulaciones no autorizadas como para asegurar los datos
relevantes para el pago, que se transmiten para la agregación al
concentrador del proveedor de servicios, impidiendo modificaciones
no detectadas o duplicación.
El concentrador representa en este modelo del
sistema el punto de encabezamiento del proveedor de servicios
frente a la caja de compensación. Su función es recibir o llamar de
todos los RSE del proveedor de servicios los datos de transacciones
relevantes para el pago, extraer de ellos los datos individuales
relevantes para el pago y agregarlos en la medida posible respecto
a los medios de pago. Según la relación contractual entre el
proveedor de servicios, el emisor de medio de pago y los
adquirentes, los datos respecto a los sistemas de pago se separan y
procesan de tal forma que puedan transmitirse al o a los
adquirentes.
Puesto que en el concentrador se juntan
múltiples datos individuales de los que podría abusarse para derivar
informaciones acerca de los movimientos y el comportamiento, estos
datos y sus posibilidades de procesamiento están sujetos a una
vinculación finalista estricta, que debe ser garantizada y
controlada según las disposiciones del derecho de la protección de
datos. En particular, deben protegerse los datos de transacción, que
por necesidades de la técnica de revisión deben almacenarse durante
largo tiempo, para impedir eficazmente su visualización, uso y
modificación.
En el caso del uso de un medio de pago pagado
posteriormente en el sistema EAT, un usuario puede exigir en
principio un desglose detallado de los datos de las transacciones
que le son facturados por su banco (emisor). No obstante, por
motivos relacionados con el derecho de la protección de datos esto
sólo es posible si el usuario autoriza el instituto que gestiona su
cuenta explícitamente para recibir estos datos de los proveedores
de servicios EAT. En este caso, el emisor puede reunir estos datos,
por ejemplo, en una factura mensual con comprobante de cada tasa
individual y remitirla al usuario.
En el modelo del sistema EAT, un adquirente es
aquella institución que compra de todos los proveedores de
servicios las deudas activas acumuladas respecto a los sistemas de
pago procesados por él y que realiza el pago (abono en cuenta). Se
comprueba la autenticidad e integridad de las deudas activas,
verificándose en particular la autenticidad de los medios de pago
con ayuda de los datos de certificación que se suministran junto
con las deudas activas. Después de la reclasificación
correspondiente y el procesamiento, los datos de las deudas activas
se transmiten a los emisores correspondientes, para que pueda
realizarse el pago de la deuda activa (adeudo en cuenta). La
función del adquirente puede ser asumida, por ejemplo, por un
instituto de crédito, una sociedad de tarjetas o un proveedor de
servicios de procesamiento.
El modelo permite la integración de uno o varios
adquirentes. Por ejemplo, es concebible que un adquirente procese
uno o varios medios de pago universales o que actúe como punto de
encabezamiento nacional o internacional para uno o varios medios de
pago específicos según el transporte. En el caso de la identidad
jurídica de un emisor de un medio de pago y de un proveedor de
servicios, la función de adquirente también puede ser asumida por el
propio proveedor de servicios.
En el modelo del sistema EAT, el concepto emisor
ha de entenderse como concepto general para el explotador o emisor
de un medio de pago o un instituto de crédito que gestiona las
cuentas. Según la propiedad del medio de pago, puede actuar como
emisor un instituto de crédito, una sociedad de tarjetas, una
asociación de transporte público de cercanías, un explotador de
autopistas, etc.
En este contexto, una función del emisor es la
elaboración y distribución de listas de bloqueo para aquellos
medios de pago que ya no deben ser aceptados, por ejemplo, por robo,
funcionamiento defectuoso u otras infracciones de seguridad. Las
informaciones necesarias para ello pueden ser recogidas, por
ejemplo, por los adquirentes, puesto que éstos pueden detectar
infracciones contra la seguridad en el comportamiento de pago
independientemente del servicio (como tarea subcontratada, la
responsabilidad le corresponde, no obstante, al emisor). En el
concepto está previsto que las informaciones de bloqueo de este tipo
puedan transmitirse hasta los dispositivos RSE pudiendo
transmitirse desde allí de forma opcional y selectiva también a
OBUs. Para los medios de pago pagados previamente, el emisor del
sistema de pago puede supervisar, además, saldos sombra respecto a
los medios de pago en circulación (por ejemplo, monederos
electrónicos), para poder detectar eventuales ataques contra la
seguridad.
\global\parskip0.900000\baselineskip
Este componente del modelo es importante cuando
se usan, por ejemplo, medios de pago pagados previamente en un
sistema EAT. Puede tratarse de una agencia de venta para tarjetas
chip u On-Board Units provista de la licencia del
emisor correspondiente o de una instancia de carga para monederos
electrónicos (cajero automático para dinero electrónico).
El punto de control EAT es un componente del
sistema que en principio está separado de la exacción de tasas.
Tiene las siguientes tareas:
- -
- comprobar la existencia y la autenticidad del último comprobante de pago respectivamente necesario,
- -
- comprobar si la tarificación era correcta,
- -
- dado el caso, y sólo en caso de un pago no realizado o realizado de forma incorrecta, reunir datos para asegurar pruebas y para el pago posterior de la tasa, y
- -
- conseguir un cobro lo más automatizado posible de tasas no pagadas y eventualmente de tasas suplementarias.
El punto de control EAT puede ser estacionario
para comprobar usuarios de la carretera móviles o puede ser móvil
para comprobar usuarios de la carretera móviles o estacionarios y
comunica mediante la interfaz aérea con las On-Board
Units.
Técnicamente, un control EAT puede estar también
acoplado a un RSE, para que pueda conseguirse directamente el
aseguramiento de pruebas para las personas que no pagan o que no
pagan correctamente con un pago posterior consecutivo. Esto se
denomina también cumplimiento integrado. A diferencia de ello, el
cumplimiento separado se realiza, como se ha explicado
anteriormente, mediante un control técnicamente separado de la
exacción de tasas, posterior en el tiempo y, en la mayoría de los
casos, sólo aleatorio.
Condición previa imprescindible para la
participación de todos los componentes en el sistema EAT es que los
requisitos de arquitectura relevantes para la seguridad se apliquen
en la realización de componentes del sistema de pago EAT completa y
correctamente en forma de medidas técnicas, organizativas y
jurídicas respetándose estas medidas también durante el
servicio.
Los requisitos relevantes para la seguridad
resultan porque deben garantizarse la seguridad contra
manipulaciones y de revisión, el cumplimiento de las disposiciones
de la protección de datos y el flujo correcto de todas las
corrientes de pago, puesto que en los distintos componentes del
sistema global se generan, almacenan, transmiten, valoran y guardan
una pluralidad de datos relacionados con los clientes, los pagos y
los servicios, por lo que también está expuesto a una gran variedad
de amenazas.
La instancia de admisión debe realizar las
siguientes tareas:
- -
- Para todos los componentes del sistema y personas jurídicas debe regularse la participación en el sistema global mediante un procedimiento de admisión, que impide eficazmente, es decir, también a la fuerza desde el punto de vista técnico en los procesos automatizados, el uso de sistemas no admitidos (tarjetas chip, aplicaciones, terminales, proveedores de servicios, etc.). Paralelamente existe un procedimiento de recepción para todos los componentes del sistema.
- -
- En cualquier lugar en el que se generen procesos de pago y flujos de datos correspondientes, debe poderse garantizar la fiabilidad, la autenticidad y, dado el caso, la confidencialidad. En particular, deben tomarse medidas que impidan una carga no autorizada de medios de pago o el adeudo en cuenta de importes y la simulación o repetición de pagos ya realizados, además de permitir el bloqueo de determinados participantes o grupos de participantes (tarjetas chip, aplicaciones, medios de pago, aparatos).
- -
- Debe asegurarse el carácter inequívoco de los procesos de pago y todas las transacciones y deudas activas deben poderse comprender de forma segura en una revisión. Deben tenerse en cuenta los requisitos especiales del derecho de la protección de datos para la adquisición, el almacenamiento, el procesamiento y la transmisión de datos relacionados con personas o datos que pueden relacionarse con personas (estrecha vinculación finalista).
- -
- La realización técnica de los sistemas y los procesos organizativos y técnicos deben estar configurados de tal forma que, entre otras cosas, puedan garantizarse todos los pagos entre los participantes admitidos del sistema. Esto debe reglamentarse mediante acuerdos contractuales correspondientes (por ejemplo, entre proveedores de servicios, adquirentes y emisores).
\global\parskip1.000000\baselineskip
Para la admisión del servicio deben elaborarse
contratos para todos los participantes que ofrezcan un servicio a
nivel local, nacional o europeo, de forma similar a los reglamentos
para el sistema de cajeros automáticos o de dinero electrónico de
la economía crediticia alemana. En estos contratos deben exigirse,
en particular, para la recepción de componentes del sistema,
comprobaciones obligatorias o dictámenes para la seguridad IT de
tarjetas chip, aplicaciones, On-Board Equipment,
RSE, conceptos de red, cajas de compensación, etc.
Los criterios de estas comprobaciones deben ser,
entre otros, la protección contra manipulaciones de aplicaciones
EAT y relevantes para el pago en los puntos de empleo más diversos
en el sistema global, así como la independencia y la ausencia de
retroactividad de distintas aplicaciones al emplear tarjetas chip
multifuncionales. Debe comprobarse que en todas las situaciones de
aplicación regulares e irregulares se salvaguarden los intereses de
todos los participantes del sistema en cada paso de procesamiento o
en el momento respectivamente real o al menos de forma
retrospectiva y que esté garantizada la garantía de pago para todas
las exacciones de tasas realizadas correctamente.
Dos tareas subordinadas a las funciones de
admisión pueden verse en el área de la gestión de claves
criptográficas:
- -
- En el caso de emisores de medios de pago y proveedores de servicios independientes, debe establecerse la admisión de un sistema de pago para el sistema EAT mediante la gestión de claves, que es necesaria para la activación de los SAMs. Para ello es recomendable intentar conseguir un procedimiento de seguridad armonizado para todos los emisores y proveedores de servicios con una arquitectura de claves compatible, lo cual pude coordinarse de forma ideal en el marco de los procedimientos de admisión.
- -
- En caso de emplear procedimientos de cifrado asimétricos para la autenticación del interlocutor y la generación de firmas digitales es necesaria una instancia de certificación, que asigna una clave a cada interlocutor admitido, de modo que cualquier otro participante del sistema pueda determinar la legitimidad de la asignación.
En caso de una extensión internacional o una
apertura del sistema EAT, la instancia de admisión y el sistema de
gestión de claves debe implementarse de forma jerárquica, para
integrar las tareas respectivamente nacionales y las competencias en
un procedimiento internacional de admisión y una gestión unificada
de claves. De esta forma pueden admitirse participantes del sistema
EAT a nivel nacional para el empleo internacional, basándose este
proceso en requisitos de seguridad armonizados y criterios de
admisión.
Respecto al proceso de pago al usar el servicio
mediante la interfaz aérea y la preparación de este proceso en el
On-Board Equipment, debe distinguirse si se trata de
un medio de pago a modo de monedero (prepago) o basado en una
cuenta (postpago). El punto de partida para las determinaciones en
una forma de realización especialmente preferible según la
invención es que, debido a los dominios de seguridad separados, sin
tenerse en cuenta una eventual identificación organizativa de
componentes del sistema (por ejemplo, coincidencia del emisor y del
proveedor de servicios), normalmente sólo el emisor del medio de
pago tiene las claves para la certificación de procesos de pago
proporcionándolas, con excepción del empleo en procedimientos
criptográficos asimétricos, sólo al adquirente para la comprobación
de la autenticidad para deudas activas presentadas por los
proveedores de servicios.
Al emplearse monederos universales, los datos
sólo pueden introducirse de forma comprimida en los movimientos de
pagos si no está certificada cada tasa EAT individual por el medio
de pago, sino si previamente, es decir, antes de la primera
exacción de tasas, se certifica un determinado importe disponible,
proporcionándose el mismo a la aplicación EAT en el OBE para el
pago de las tasas individuales que han de pagarse
posteriormente.
Por lo tanto, en el concepto está prevista en
una forma de realización especialmente preferible según la invención
que en caso de un pago con un monedero universal, como lo
representa el monedero de la economía crediticia alemana, antes de
comenzar el viaje se adeuda un importe disponible en el monedero,
transmitiéndose el mismo de forma certificada a la aplicación EAT
en el On-Board Equipment, independientemente de si
ésta se encuentra en la misma tarjeta chip, en otra tarjeta chip o
en la On-Board Unit. El importe disponible puede ser
elegido por el usuario o puede ser definido por un parámetro del
sistema determinado, por ejemplo, por el emisor, o puede resultar
del importe total disponible del monedero.
Este importe disponible que, por regla general,
está claramente por encima de las tasas EAT reales y que debe
administrarse de forma segura en la aplicación EAT del OBE, sirve
como valor de referencia para reunir las tasas individuales
correspondientes del lado del proveedor de servicios antes de la
introducción de las deudas activas EAT en los movimientos de pagos,
por lo que la suma de tasas individuales no debe superarlo. Del
importe disponible se descuentan en la aplicación EAT del OBE las
tasas individuales hasta que se haya gastado el importe y sea
necesario un nuevo proceso de adeudo. Un importe restante que queda
después de terminar el viaje puede permanecer en la aplicación EAT
o puede ser devuelto al monedero como extorno parcial. Por lo tanto,
en el marco de la admisión EAT del medio de pago "monedero
universal", es necesario que se cumplan los procesos de
seguridad del lado del equipo y del software y que los emisores
asuman una responsabilidad frente a los proveedores de servicios,
de pagarse realmente todas las deudas activas sumadas así
formadas.
\newpage
Si el monedero y la aplicación EAT tienen
dominios de seguridad idénticos, lo cual en el caso normal sólo es
posible en un monedero específico según el transporte, puede
renunciarse a una certificación del importe disponible si el medio
de pago sólo es aceptado por el proveedor de servicios emisor,
puesto que en este caso los movimientos de pago son realizados por
el propio proveedor de servicios o una empresa de servicios
encargada por él.
En el caso indicado en último lugar o en el caso
de sistemas basados en GNSS o en general, cuando lo permite el
requisito de tiempo del proceso de pago o la capacidad técnica de
los chips y las técnicas de transmisión, también puede tener lugar
una comunicación directa entre el medio de pago y el dispositivo de
exacción, de modo que pueda renunciarse a una puesta a disposición
previa de un importe disponible. En este caso, cada vez cuando se
paga una tasa se adeuda sólo la tasa realmente pagadera en el medio
de pago, de modo que no sea necesaria una recarga de importes
eventualmente no gastados.
En el caso de un pago por cuenta sólo es
necesario transmitir la información acerca de la cuenta en una forma
certificada a la aplicación EAT. En caso de no producirse ningún
error, estos datos pueden usarse para la compensación e
introducirse en los movimientos de pago, hasta que el usuario
proceda a elegir otro medio de pago. Esta variante de pago
corresponde a un procedimiento de cargo en cuenta, para el cual el
usuario del servicio concede una autorización de adeudo para su
cuenta.
Al igual de lo que se ha descrito anteriormente
en relación con el pago por monedero, también aquí puede renunciarse
a una certificación de la información acerca de la cuenta, además
de poderse tramitar el proceso de pago en una comunicación directa
entre el medio de pago y el dispositivo de exacción.
En las dos variantes de pago se comprueba antes
de la entrega del importe disponible certificado o de la información
acerca de la cuenta certificada si el sistema de pago es
generalmente aceptado por al aplicación EAT, lo cual requiere un
acuerdo contractual correspondiente entre el proveedor de servicios
EAT y el emisor del medio de pago y, en particular, si el medio de
pago concreto es válido (comprobación de la fecha de caducidad y de
identificadores de bloqueo). En el caso de dominios de seguridad
separados, la comprobación de la aceptación y de la validez, así
como el adeudo en cuenta o la autorización del cargo en cuenta son
asegurados mediante una gestión de claves
correspon-
diente.
diente.
En una forma de realización especialmente
preferible de la invención, el dispositivo de pago está configurado
como On-Board Equipment (OBE) para un vehículo, de
forma especialmente preferible un automóvil, de tal forma que
comprende una On-Board Unit (OBU), que se utiliza
con una tarjeta con microprocesador (ICC) del usuario. La ICC se
introduce como medio de pago pagado previamente en la OBU; la OBU
recibe del chip de la ICC las informaciones que el OBE necesita
para la tramitación automática del proceso de pago con el
dispositivo de
exacción.
exacción.
La comunicación entre una ICC y un OBE requiere
generalmente más tiempo que la comunicación entre la OBU y el
dispositivo de exacción, típicamente un dispositivo RSE. Por lo
tanto, es especialmente preferible cargar un importe disponible
determinado en forma de datos de la aplicación de monedero de la ICC
en la OBU ya antes de producirse un proceso de pago entre el
dispositivo de pago y el dispositivo de exacción, e incluso antes
de haberse creado la interfaz de comunicación entre los dos.
Habitualmente, esto se hace siempre cuando el usuario (y titular de
la tarjeta) introduce su ICC en la OBU. Además, una carga de este
tipo estará prevista habitualmente cuando el importe aún disponible
en la OBU ha quedado por debajo de un valor límite determinado
debido a pagos ya realizados, naturalmente con la condición previa
de que la ICC esté introducida en la OBU y presente por su cuenta
aún un importe disponible suficiente.
En la comunicación entre la ICC y la OBU, como
reacción a cada mensaje de la OBU a la ICC (comando) se emite un
mensaje de la ICC a la OBU (respuesta). La siguiente secuencia de
comandos describe el proceso de comunicación después de
introducirse una ICC en el dispositivo lector de una OBU:
- ATR
- Mediante el comando Answer to Reset con la respuesta correspondiente se proporcionan informaciones técnicas respecto a la ICC y la disponibilidad de aplicaciones.
- SLA
- El comando Select Application selecciona la aplicación de monedero de la ICC por la OBU. La respuesta contiene las informaciones que corresponden a la aplicación de monedero.
- RIDL
- Mediante el comando Read ID/Limit puede leerse la cantidad de dinero almacenada actualmente en la aplicación de monedero de la ICC, para comprobar si la ICC dispone aún de un importe disponible suficiente. En una forma de realización especialmente preferible de la invención, la OBU o el usuario pueden decidir qué importe debe cargarse realmente de la ICC en la OBU. En otra forma de realización preferible, cuando el proceso de adeudo se realiza o de forma autónoma (es decir, sin comunicación externa) o en comunicación directa con el dispositivo de exacción, esta información puede usarse par determinar si el medio de pago en principio puede ser usado.
\newpage
- GC
- Antes de poderse retirar un importe determinado de la aplicación de monedero, deben proporcionarse de forma independiente uno de otro dos números aleatorios, por un lado, por la ICC y, por otro lado, por la OBU o el dispositivo de exacción (RSE), que comprueban la autorización mutua de la ICC y la OBU o del RSE para la entrega del importe. Mediante comando y respuesta Get Challenge, el número aleatorio generado por la ICC se envía al entorno.
- UA
- Mediante el comando Update Amount, se descuenta una cantidad determinada de dinero electrónico de la ICC. Este comando y su respuesta están protegidos por una clave secreta, que usa los dos números aleatorios para impedir una retirara no autorizada o repetida. Además, el importe retirado puede ser certificado por la ICC con una segunda clave, que no conoce el proveedor de servicios, pero sí el adquirente.
En una forma de realización especialmente
preferible, después de haberse proporcionado un importe disponible
certificado en la OBU pueden tramitarse, dado el caso, varios
procesos de pago entre la OBU y uno o varios dispositivos de
exacción sin que esté implicada la ICC. Si ya no son necesarias más
transacciones y la ICC debe retirarse del dispositivo lector del
OBU, un importe disponible que eventualmente sigue existiendo debe
devolverse a la aplicación de monedero de la ICC. Esto también debe
producirse si debe transmitirse otro comando UA para proporcionar
un nuevo importe disponible; también en este caso debe cargarse en
primer lugar un importe restante del importe disponible
anteriormente en la ICC, antes de hacerse pasar un nuevo importe
disponible a la OBU.
- PR
- Mediante el comando Partial Reversal es posible devolver un importe restante de la OBU a la ICC. También este comando está protegido contra abusos mediante un código de autenticación, que se genera mediante una clave secreta y dos números aleatorios, que no se generan hasta directamente antes de introducirse este comando.
Concretamente, para las secuencias de comandos y
respuestas en la comunicación entre la ICC y la OBU se usan los
siguientes mensajes, refiriéndose "input" a aquellos datos que
se transmiten con un mensaje de comando a la ICC, mientras que
"output" se refiere a aquellos datos que se envían desde la ICC
mediante un mensaje de
respuesta:
respuesta:
- ATR
- no hay input;
- \quad
- Output: card_data
- SLA
- input: nombre de la aplicación de monedero;
- \quad
- no hay output
- RIDL
- no hay Input;
- \quad
- output: id_prevu, que contiene ICC/PREVU_ID, número entero de 8 (o más) bytes; importe, número entero de 2 (o más) bytes
- GC
- no hay Input;
- \quad
- output: número aleatorio hexadecimal de 4 u 8 bytes
- UA
- input: el comando correspondiente comprende los objetos type, ID, TA_Counter, amount, random y mac1.
- \quad
- Type es un número entero de 1 byte;
- \quad
- ID es un número entero de 4 bytes;
- \quad
- TA_Counter es un número entero de 2 bytes y amount es un número entero de 2 (o más) bytes.
- \quad
- Random y mac1 son números hexadecimales de 4 u 8 bytes.
- \quad
- Output: la respuesta correspondiente comprende los objetos status, ICC/PREVU_ID, ICC_TA_counter, amount, mac2 y mac3.
- \quad
- Status es un número hexadecimal de 2 bytes;
- \quad
- ICC/PREVU_ID es un número entero de 8 (o más) bytes.
- \quad
- ICC_TA_counter y Amount son números enteros de 2 (o más) bytes;
- \quad
- mac2 y mac3 son números hexadecimales de 4 u 8 bytes.
\newpage
- PR
- input; el comando comprende los objetos ID, TA_counter, amount1, mac1, amount 2, random y mac2.
- \quad
- ID es un número entero de 4 bytes.
- \quad
- TA_counter, amount1 y amount2 son números enteros de 2 (o más) bytes;
- \quad
- mac1, random y mac2 son números hexadecimales de 4 u 8 bytes.
La respuesta correspondiente (output) comprende
los objetos status y mac3. Status es un número hexadecimal de 2
bytes, mac3 un número hexadecimal de 8 bytes.
En otra forma de realización preferible de la
invención, cuando un proveedor de servicios emite, por ejemplo, su
sistema de pago propio o cuando hay requisitos menos estrictos en
cuestión de tiempo del proceso de pago, es posible que tenga lugar
una comunicación directa entre el medio de pago, por ejemplo, en
forma de una tarjeta con microprocesador, y el dispositivo de
exacción, relacionada con el aseguramiento criptográfico. En esta
forma de realización se suprime la necesidad del almacenamiento y
cifrado de datos en el transpondedor, puesto que éste se usa
fundamentalmente sólo para la conversión de protocolos de
transmisión. En este caso, los comandos UA y PR arriba descritos
deben ser sustituidos, por ejemplo, por SD (Secure Decrease:
adeudo asegurado de una tasa EAT de la memoria de importes de la
aplicación de monedero) y RF (Register Fee: confirmación
final del recibo positivo del pago y generación de un registro
logging):
- SD
- input; el comando comprende los objetos ID, tarif, amount, random y mac1.
- \quad
- ID es un número entero de 4 (o más) bytes.
- \quad
- tarif es un número entero de 1 byte;
- \quad
- amount es un número entero de 2 (o más) bytes;
- \quad
- random y mac1 son números hexadecimales de 4 u 8 bytes.
- \quad
- Output: la respuesta correspondiente comprende los objetos status y mac2.
- \quad
- Status es un número hexadecimal de 2 bytes;
- \quad
- mac2 es un número hexadecimal de 4 u 8 bytes.
- RF
- input; el comando comprende los objetos clase de vehículo, número de recibo, amount, result, encMsg.
- \quad
- Clase de vehículo es un número entero de 1 byte;
- \quad
- número de recibo es un número hexadecimal de 3 bytes;
- \quad
- amount es un número entero de 2 (o más) bytes;
- \quad
- result es un número hexadecimal de 2 bytes;
- \quad
- encMag es un número hexadecimal de 8 o 16 bytes, que comprende un mac3 hexadecimal de 4 u 8 bytes cifrado.
- \quad
- Output: la respuesta correspondiente comprende los objetos status y mac4.
- \quad
- Status es un número hexadecimal de 2 bytes;
- \quad
- mac4 es un número hexadecimal de 4 u 8 bytes.
Para la determinación y exacción automática de
tasas debe distinguirse entre un sistema EAT abierto o cerrado:
- -
- En el sistema abierto, es posible un pago de tasa en cada RSE.
- -
- En el sistema cerrado, el usuario de la carretera recibe en primer lugar un ticket de entrada, que debe presentar al salir de la zona y que representa la base para el cálculo de la tasa (por ejemplo, en un garaje público).
La exacción de tasas mediante la interfaz aérea
se realiza en el sistema abierto y al salir del sistema cerrado en
principio según los siguientes cinco pasos, que en principio ya se
han descrito anteriormente, para que puedan separarse
fundamentalmente los procesos para la determinación de la tasa, el
pago y la entrega del recibo. La entrada en un sistema cerrado se
realiza según los primeros tres de los cinco pasos indicados a
continuación. Para los contenidos detallados del protocolo, el
proveedor de servicios debe distinguir entre un dispositivo de
exacción del tipo "RSE de pago" (sistema abierto y salida del
sistema cerrado), en el que se realiza un pago inmediato de la tasa
y del tipo "RSE de entrada" (entrada en el sistema cerrado),
que sólo emite tickets de entrada. Por parte del usuario del
servicio, el pago se realiza mediante una interfaz de comunicación,
formada por la parte de transmisión del dispositivo de pago (parte
del On-Board Equipment, OBE).
T: tender (significa: indicación de la oferta de
servicio)
Al aproximarse un vehículo, el dispositivo de
pago del Road-Side Equipment recibe en primer lugar
informaciones acerca de los sistemas de pago aceptados por el
proveedor de servicios EAT (List of Accetable Payments) y
eventualmente datos acerca de la funcionalidad, del nivel del punto
de exacción de tasas y del proveedor de servicios. La List of
Acceptable Payments contiene para cada sistema de pago regional o
suprarregional (es decir, no aceptados obligatoriamente) una
entrada, que preferiblemente está estructurada según ISO
7816-5 (Issuer Identification Number o Registered
Application Provider Identifier), si éste es aceptado por el
proveedor de servicios EAT:
Además, en un RSE de pago puede ser necesario
que se realicen otras consultas de estado de tipo Boole (List of
Boolean Challenges), para consultar, por ejemplo, la existencia de
un ticket de entrada o de un identificador de bloqueo. En el caso
de un RSE de entrada, se envía en lugar de ello un número aleatorio
(RSE Random Challenge) para garantizar en lo sucesivo que los
tickets de entrada sólo son emitidos en dispositivos de pago
auténticos.
R: Registration (significa: declaración de la
voluntad de compra y pago)
Mediante la recepción de un mensaje T de un RSE
de pago, se solicita al dispositivo de pago que el mismo transmita
a su vez al RSE datos acerca de la clase del vehículo y las
condiciones especiales de pago (por ejemplo, tarifa para
minusválidos, abono para cliente importante, vehículo soberano,
etc.; Vehicle and Driver Dependent Class Table), acerca del estado
de validez (Expire Date, mínimo del final de caducidad de la
aplicación EAT y del medio de pago empleado), acerca del deseo de
pago (Issuer Identifier y Requested Currency), acerca de las
consultas de estado booleanas) (List of Boolean Responses) y, en el
sistema cerrado, acerca de un ticket de entrada cifrado
eventualmente existente del nivel de servicio correspondiente.
Gracias al cifrado de los tickets de entrada se impide el copiado
selectivo de tickets de entrada mediante intercepción de la interfaz
aérea. El ticket contiene indicaciones acerca de la hora y del
lugar de entrada y eventualmente otros datos de plausibilidad
anónimos (por ejemplo, clase de vehículo, número del ticket) para
que pueda comprobarse la legitimidad de su uso.
Además, con el mensaje R se transfieren datos
para el procedimiento de cifrado (por ejemplo, número de clave de
grupo), aunque éstos no permiten una identificación mediante el OBE.
Para todo el protocolo para el pago de tasas, según la invención es
especialmente preferible que deba realizarse previamente una
identificación del RSE. Además, se entrega un número aleatorio para
la autenticación del RSE (OBE Random Challenge). En el mensaje R se
transmite asimismo también el momento del último pago, si éste se ha
producido en el mismo punto de pago (Beacon ID).
En caso de un RSE de entrada, el dispositivo de
pago envía en el mensaje R datos acerca del deseo de pago, un
número aleatorio propio (OBE Random Challenge), que se usa para la
posterior autenticación del RSE, el número de clave de grupo, así
como un autenticador para estos datos.
PD/TT: Price Definition (significa:
determinación del precio) o Ticket Transfer (significa: emisión del
ticket de entrada).
Si debe realizarse un pago de tasa en el RSE
actual, previa evaluación de la validez de la aplicación de EAT o
del medio de pago (Expire Date), el RSE puede determinar a partir de
los datos recibidos por el dispositivo de pago el importe actual de
la tasa (Fee) en función de la clase del vehículo, las condiciones
especiales de pago, el momento de pago y un eventual ticket de
entrada, debiendo ser independiente el importe de la tasa del medio
de pago, puesto que el usuario tiene en principio libre elección de
la lista de medios de pago aceptados.
Como alternativa a ello (en el sistema cerrado)
puede emitirse un ticket de entrada en lugar de la determinación de
la tasa, siendo cifrado el mismo por las razones arriba expuestas
por el RSE de tal forma que sólo pueda ser descifrado por un RSE
del mismo proveedor de servicios. Además, junto con la transmisión
de ticket también pueden definirse valores booleanos, como por
ejemplo, poner una marca en un dispositivo de pago de que se ha
realizado la entrada en un sistema cerrado. Por motivos relacionados
con la protección de datos, un dispositivo de exacción no debe
realizar entradas no booleanos, por ejemplo, de tipo numérico, en un
dispositivo de pago, para excluir marcas y seguimientos sistemáticos
de los usuarios.
La tasa EAT solicitada o el ticket de entrada
cifrado se envía junto con la identificación RSE, la fecha y la
hora de la exacción de tasas, una información acerca del estado
(Error Code), la tarifa aplicada y, en caso de un posterior pago de
la tasa, otro número aleatorio para la autenticación del OBE (RSE
Random Challenge) al dispositivo de pago.
Para poder autenticar el dispositivo de exacción
y de pago, el mensaje PD o TT está provisto o de un autenticador
(Signature o Message Authentication Code), en el caso de un RSE de
pago, o está parcialmente codificado, en el caso de un RSE de
entrada, usándose en los dos casos un "Sessionkey", que depende
del número de clave de grupo y de los números aleatorios.
P: Payment (significa: realización del pago)
Después de recibirse un Tickettransfer (sistema
cerrado), en primer lugar se descifra el mensaje y se comprueba la
respuesta del OBE (OBE Random Response), de modo que el RSE y, por
lo tanto, también el ticket de entrada cifrado se consideran
autenticados en el caso positivo. En el caso de un RSE de entrada,
el proceso ha terminado con ello.
Después de recibir una Price Definition, se
verifica en primer lugar el autenticador, autenticándose de esta
forma el dispositivo de exacción mediante el dispositivo de pago.
Los datos de un mensaje PD autenticado, se almacenan como
comprobante de la voluntad de pago (Preliminary Receipt) hasta el
siguiente pago, para que pueda comprobarse el intento de pago en
caso de un proceso de pago eventualmente fallado ante un punto de
control EAT.
Para la realización del proceso de pago, la tasa
EAT (Fee) y los datos relevantes para el pago (Issuer Identifier y
Payment Object) se transmiten al RSE, estando provisto este mensaje
también de un campo de autenticador. Los posibles contenidos del
Payment Object dependen exclusivamente de los acuerdos bilaterales
entre el emisor y el proveedor de servicios y se discutirán a
continuación más detalladamente.
CR: confirmation and Receipt (significa: puesta
a disposición del comprobante de pago)
Después de la recepción del Payment y de la
comprobación del autenticador en el RSE, puede realizarse una
comprobación de bloqueos para el medio de pago empleado, si el
Payment Object contiene la identificación exacta del medio de pago.
En caso de detectarse una nota de bloqueo, por un lado, puede
indicarse al dispositivo de pago en una información de estado
(Error Code) una solicitud de bloquear el medio de pago y, por otro
lado, pueden introducirse las informaciones determinadas en el
proceso anterior de la transacción directamente al Cumplimiento. La
nota de bloqueo puede seguir puesta en la aplicación EAT del OBE,
para impedir un nuevo intento de pago con el medio de pago
bloqueado ya en el dispositivo de pago. Adicionalmente, puede
inducirse que el medio de pago realice un autobloqueo, por ejemplo,
en el caso de una tarjeta chip.
En el caso contrario, se confirma al dispositivo
de pago el pago que se ha realizado y se transfiere al dispositivo
de pago un recibo de cumplimiento provisto de un autenticador, así
como, dado el caso, de valores booleanos (por ejemplo, para el
reset de una marca de un ticket de entrada). Este mensaje es
parcialmente cifrado para impedir ataques mediante intercepción con
el Sessionkey arriba indicado. El recibo contiene todos los datos
importantes para un control EAT (Cumplimiento), como
RSE-ID, fecha y hora, número de recibo, datos acerca
de la clase del vehículo, tasa EAT,
etc. El autenticador del recibo de Cumplimiento es generado por una clave desconocida para el dispositivo de pago.
etc. El autenticador del recibo de Cumplimiento es generado por una clave desconocida para el dispositivo de pago.
Después de recibir y verificar el mensaje CR, el
recibo se deposita de tal forma en la memoria de transacciones del
OBE que el recibo expedido en último lugar, respectivamente, de un
nivel de servicio con su autenticador pueda usarse también como
comprobante de pago ante un punto de control EAT.
El Payment Object incluido en el mensaje P, está
formado, entre otras, de las siguientes cuatro partes de
información, aunque éstas no pueden ser asignadas de la misma forma
para todos los tipos de sistemas de pago.
- TR
- Transaction Related Data, por ejemplo, importe disponible o importe de la tasa, fecha o contador de secuencias del servicio;
- PAY
- Payment System Related Data, por ejemplo, identificación de la persona obligada al pago, cuenta adeuda o cuenta de compensación;
- ID
- Identity Related Data, por ejemplo, ID del medio de pago;
- SEC
- Security Related Data, por ejemplo, parámetros de cifrado y autenticador.
A continuación, se indican posibles contenidos
del Payment Object para tres ejemplos de pago.
* Tarjeta de valor anónima, específica para el
transporte, pagada previamente:
- -
- El campo de datos TR puede contener además de la tasa EAT propiamente dicha, por ejemplo, un contador de adeudos o el importe restante que existe en la tarjeta de valor, para que sea posible distinguir entre procesos individuales y para facilitar eventuales comprobaciones de seguridad.
- -
- Es concebible compensar tarjetas de valor en función de la fecha de expedición y/o de caducidad mediante distintas cuentas. Esto puede realizarse o de forma explícita, mediante una indicación de la cuenta en el campo de datos PAY, que se lee en el marco del adeudo de la tarjeta de valor, o de forma implícita, mediante el número (de grupo) de tarjetas de valor.
- -
- No son necesarios parámetros de seguridad adicionales en el caso de un medio de pago anónimo, específico según el transporte, de modo que para este fin tampoco es necesaria una identificación de tarjeta individual.
* Monedero universal de institutos
financieros:
- -
- Puesto que la comunicación con la tarjeta chip de monedero requiere mucho tiempo debido a los procedimientos de seguridad complejos, el monedero universal, dado el caso, sólo puede usarse como medio de pago en un entorno EAT mediante un adeudo previo de un importe disponible. Respecto al significado del importe disponible en el campo de datos TR se remite a las observaciones anteriormente expuestas respecto al tipo de pago "Pago mediante monedero".
- -
- Los otros datos previstos en el campo de datos TR son usados por el monedero universal en la formación del MAC, que asegura de forma criptográfica el proceso de adeudo en el monedero y deben ser transmitidos, por lo tanto, a aquel punto en los movimientos de pagos (es decir, el adquirente competente), que verifica el MAC.
* Procedimiento de cargo en cuenta:
- -
- El pago se realiza posteriormente mediante adeudo en una cuenta de débito o de crédito, que se indica en el campo de datos PAY. En este caso puede controlarse mediante el campo de datos T si el usuario autoriza cada adeudo de tasa EAT individual o si la autorización del adeudo se otorga en determinados intervalos de tiempo (por ejemplo, una vez al comenzar el viaje o diariamente).
- -
- El otorgamiento de la autorización de adeudo debe estar asegurado contra falsificación y debe poderse comprobar, por lo que requiere la generación de un Message Authentication Code o de una firma electrónica, asignándose las claves correspondientes o mediante la identificación de la cuenta o la tarjeta chip como soporte del medio de pago.
En otra forma de realización según la invención,
la determinación de la tasa puede realizarse, en particular, según
un ejemplo de realización de la reivindicación 1 de la invención
sin (es decir, de forma autónoma) o mediante la comunicación del
dispositivo de pago del lado del usuario y un emisor/receptor de
otro tipo, por ejemplo, radio celular (por ejemplo, GSM - Global
System for Mobile Telecommunications), estando asignado el
emisor/receptor como llamado punto de pago virtual a uno o varios
puntos de exacción de tasa estacionarios. En las dos variantes, un
pago de tasas se inicia mediante un GNSS (Global Navigation
Satellite System, por ejemplo, GPS - Global Positioning System). El
proceso global puede realizarse también en cinco pasos, análogos a
los pasos arriba descritos.
En un sistema de este tipo, un receptor GPS
suministra continuamente datos acerca de la posición geográfica del
vehículo al dispositivo de pago. Estos datos se comparan con un mapa
digital, en el que están registrados los puntos de pago virtuales.
Estos datos del mapa están almacenados en el dispositivo de pago. Si
se detecta una coincidencia, es decir, si el vehículo se encuentra,
por ejemplo, en una carretera sujeta al pago de tasas, la tasa para
el uso de la carretera determinada mediante una tabla de tarifas o
un algoritmo de tarifa se registra en el dispositivo de pago. Según
el sistema de pago empleado y el equipamiento técnico del
equipamiento del vehículo, esta tasa puede adeudarse, por ejemplo,
directamente en la tarjeta chip, sin otra comunicación externa
(sistema autónomo). Como alternativa, después de un número
determinado de procesos de pago de este tipo o cuando se alcance
una determinada posición geográfica o cuando se pase por un
"indicador de distancia de detección", se realiza una
comunicación mediante GSM o DSRC para la transmisión de los datos de
adeudos acumulados entretanto. Para los sistemas aptos para GMS, la
actualización de las tablas de tarifas, así como la recarga de un
medio de pago pagado previamente puede realizarse mediante servicio
radiotelefónico móvil.
Tanto en el caso de la exacción de tasas basada
en microondas como en el caso de una exacción de tasas mediante
otras técnicas de transmisión, los cinco pasos de la exacción de
tasas pueden realizarse mediante una comunicación a modo de
comandos (master-slave en lugar de
peer-to-peer) entre el dispositivo
de exacción y el dispositivo de pago. En el paso correspondiente,
el dispositivo de exacción envía uno o varios comandos al
dispositivo de pago, que los procesa y que los contesta con los
datos requeridos para la transmisión del siguiente paso. De esta
forma es fácil tener en cuenta en el sistema global requisitos
adicionales o especiales.
Los datos de transmisión acumulados en el
dispositivo de exacción se tratan periódicamente para la transmisión
al concentrador del proveedor de servicios. Esto se realiza en
forma de un fichero de transacción criptográficamente protegido con
número de versión, cronofechador e identificación RSE, para que en
el concentrador pueda comprobarse la autenticidad y la unicidad de
la presentación.
Como procedimientos de transmisión existen en
principio dos posibilidades:
- -
- transmisión online según un protocolo de comunicación, por ejemplo, basado en la "especificación de interfaces para la compensación entre los participantes del sistema" para sistema EAT (borrador estándar del CEN/TC 278) o
- -
- intercambio de soportes de datos, por ejemplo, mediante el uso de un disquete o una tarjeta chip de memoria para dispositivos de exacción de este tipo que no están integrados en una red de comunicación.
En el concentrador se comprueban los ficheros
de las transacciones recibidos o llamados verificándose que no han
sido manipulados durante la transmisión, que han sido generados por
el remitente (RSE) correcto y que, con excepción de un caso de
error, no han sido presentados previamente.
Para medios de pago universales, es decir, no
específicos según el transporte, en una forma de realización
especialmente preferible de la invención se realiza en el período de
compensación (por ejemplo, cada día laborable) una clasificación de
todas las transacciones individuales respecto a las identidades de
los medios de pago, de modo que puedan sumarse todos los pagos de
tasas que se han realizado en el caso de un medio de pago pagado
previamente respecto al mismo importe disponible certificado o en el
caso de un medio de pago pagado posteriormente respecto a la misma
identificación de cuenta certificada pudiendo procesarse
posteriormente como deuda activa
total.
total.
Los datos relevantes para el pago, que se
transmiten posteriormente al adquirente correspondiente, no
contienen datos de ningún tipo acerca del número, el importe y el
lugar de devengo de las tasas individuales sumadas, a no ser que el
cliente lo desee expresamente para elaborar un comprobante de las
tasas individuales. Estos datos son procesados para la transmisión
a un adquirente en forma de un fichero de deuda activa
criptográficamente protegido con número de versión, cronofechador e
identificación del presentador (proveedor de servicios), para que
el adquirente pueda comprobar la autenticidad y la unicidad de la
presentación.
Para medios de pago anónimos, específicos según
el transporte o del proveedor de servicios, en el RSE ya puede
realizarse una clasificación previa y agregación de modo que sólo
deban transmitirse las sumas de las tasas al host del proveedor de
servicios.
La estructura de datos para la interfaz entre el
RSE y el receptor de datos, habitualmente un ordenador central del
proveedor de servicios, se elige según la invención de tal forma que
pueda usarse también para el procesamiento posterior en las
instalaciones del adquirente y del emisor.
La estructura se refleja para todas las unidades
de datos del protocolo (Protocol data units, PDU) en el siguiente
diagrama, pudiendo integrarse en principio también otras PDUs, como
por ejemplo, según ISO 8583, EDIFACT:
\vskip1.000000\baselineskip
Diagrama
5
Descripción de los elementos de
datos
\vskip1.000000\baselineskip
- Message_Header:
- El elemento de datos Message_Header comprende un identificador de versión. Este identificador es un número entero, que identifica la versión válida del protocolo.
- Message_Class:
- Todos los mensajes de datos deberían pertenecer a una de seis clases distintas de mensajes (message classes). La Message_Class respectivamente adecuada para los Transaction_Files y Fee_Claim_Files son Advice y Advice Response.
- Message_Type:
- Indica la elección de un tipo determinado de mensaje. En el sistema según la invención, Message_Type es el tipo de mensaje Transaction.
- Sender_ID, Receiver_ID:
- Dentro del sistema, la identidad del emisor y del receptor deben estar definidas de forma inequívoca. Según la invención, se trata de un número de 4 bytes.
- Message_ID:
- El identificador de mensaje Message_Identifier identifica junto con Sender_ID y Receiver_ID un determinado mensaje existente y es determinado por el remitente del mensaje como número de 4 bytes. La respuesta del receptor del mensaje debe contener la misma indicación acerca del Message_Identifier.
- Message_Body:
- El Message_Body es una secuencia de Data_Objects de distintos tipos, como se definirá más adelante. Los Data_Objects contienen la "Automatic Fee Collection" (AFC) válida y datos de la transacción relacionados con el proceso de pago. En general, un Data_Object se refiere a un proceso de pago recibido por la OBU.
Los elementos de datos Message_Header,
Message_Class y Message_Type son todos números de 1 byte.
La transmisión de objetos de pago del RSE al
ordenador central del proveedor de servicios se realiza mediante
llamados Transaction_Files. Un Transaction_File comprende un
Header_Record y los Transaction_Records positivos o negativos
reales y define, por lo tanto, distintos tipos de DataObjects. El
Transaction_File se transmite como un mensaje de la clase Advice,
que contiene en su Messsage_Body un solo Data_Object del tipo 1, al
que siguen una serie de Data_Objects de los tipos 2, 3 ó 4.
Un tipo de objeto adicional se ha reservado para
el tipo de mensaje Advice Response, con el que se confirma la
recepción de un Transaction_File.
Se parte de que se realiza una llamada de la
transmisión de un Transaction_File mediante el ordenador central a
un nivel bajo del protocolo, por ejemplo, en un
File_Transfer_Protocoll, de modo que para este fin no están
previstos mensajes especiales. La transmisión de Transaction_Files
en este sentido se inicia siempre desde un ordenador RSE.
El Data_Object del tipo 1 comprende la
información acerca del Header para el Transaction_File, que es
enviado por el ordenador RSE, en particular al ordenador
central.
La estructura del Data_Object del tipo 1 se
muestra en el diagrama 6.
\vskip1.000000\baselineskip
Diagrama
6
\vskip1.000000\baselineskip
Este Object_Type comprende los siguientes
elementos de datos:
- TA_Number:
- Este elemento de datos contiene el número de Transaction_Records en el Transaction_File y determina, por lo tanto, el número de Data_Objects de los tipos 2, 3 y 4 en el mensaje.
- Fee_Sum:
- El elemento de datos Fee_Sum contiene la suma de todas las tasas contenidas en el elemento de datos correspondiente Data_Objects (tipo 2 ó 3) del Transaction_Record.
- MAC:
- Este elemento de datos contiene un Message Authentication Code.
Los elementos de datos TA_Number y Fee_Sum son
números de 4 bytes. MAC es un número hexadecimal de 8 bytes.
El Data_Object del tipo 2 contiene un
Pre-payment Transaction_Record positivo del
Transaction_File, que debe ser enviado por el ordenador RSE al
ordenador central. Positivo significa que la transacción entre el
RSE y la OBU se ha terminado correctamente, es decir, que se ha
realizado el pago. La estructura del Data_Object del tipo 2 se
muestra en el diagrama 7.
\vskip1.000000\baselineskip
Diagrama
7
\newpage
Este Data_Object_Type comprende los siguientes
elementos de datos:
- TA_ID:
- Este elemento de datos sirve para la numeración correlativa de los Transaction_Records del Transaction_File. El elemento de datos TA_ID es un número de 4 bytes.
- Issuer_ID:
- Este número de 4 bytes identifica el emisor del medio de pago que se ha usado para el pago de tasas y se ha transmitido con el mensaje Payment.
- PO:
- Este elemento de datos (Payment_Object) contiene datos individuales relevantes para los movimientos de pago relacionados con el sistema de pago pagado previamente. Es, por ejemplo, una información de 20 bytes que indica la carga previa de un importe disponible de la tarjeta inteligente en la OBU. Contiene preferiblemente los siguientes cuatro elementos:
- \quad
- ICC/PREVU ID: identificación de la aplicación de monedero en la tarjeta inteligente de la que se ha cargado el importe disponible en la OBU (número de 4 bytes).
- \quad
- ICC_TA_Counter: contador de transacciones, depende de la tarjeta inteligente (número de 2 bytes).
- \quad
- Amount: el importe disponible cargado desde la tarjeta inteligente en la OBU (número de 2 bytes).
- \quad
- MAC: Message Authentication Code generado por la tarjeta inteligente que certifica la autenticidad del importe cargado (número hexadecimal de 8 bytes).
- Fee:
- Este elemento de datos contiene la tasa que se ha exigido para un vehículo que ha pasado por el punto de pago y que ha sido deducida del importe disponible en la OBU. El elemento de datos Fee es un número de 2 bytes.
- MAC:
- Este elemento de datos de una longitud de 8 bytes contiene un Message Authentication Code.
El Data_Object del tipo 3 contiene un
Post-payment Transaction_Record positivo del
Transaction File, que debe ser enviado por el ordenador RSE al
ordenador central. Positivo significa que la transacción entre el
RSE y la OBU se ha terminado según lo previsto, es decir, que se ha
realizado el pago.
El diagrama 8 muestra la estructura del
Data_Object del tipo 3.
\vskip1.000000\baselineskip
Diagrama
8
Este tipo de Data_Object comprende los
siguientes elementos de datos:
- TA_ID:
- Este elemento de datos tiene el mismo significado que en el diagrama 7.
- Issuer_ID:
- Este elemento de datos tiene el mismo significado que en el diagrama 7.
- PO:
- El Payment_Object contiene datos relacionados con el sistema de pago pagado posteriormente. El elemento de datos PO es, por ejemplo, una información de 18 bytes, que se refiere, por ejemplo, al Post-Payment Account almacenado en la OBU. Comprende preferiblemente tres elementos:
- \quad
- OBU/Account ID: la identificación del Post-Payment Account (número de 8 bytes).
- \quad
- PP_Sel_Counter: Este contador siempre aumenta cuando el conductor del vehículo decide realizar un pago posterior realizando una función de selección OBU correspondiente. Por lo tanto, este valor es habitualmente constante durante un viaje para todas las transacciones OBU/RSE.
- \quad
- MAC: El Message Authentication Code generado por la OBU, que confirma la autenticidad de la identificación de la cuenta.
- Fee:
- Este elemento de datos contiene la tasa que se ha exigido para un vehículo que ha pasado por el punto de pago. El elemento de datos Fee es un número de 2 bytes.
- MAC:
- Este elemento de datos de una longitud de 8 bytes contiene un Message Authentication Code.
El Data_Object del tipo 4 contiene informaciones
acerca de transacciones negativas. Una transacción se llama
negativa cuando un vehículo que ha pasado por el punto de pago no ha
realizado ningún pago. En este caso podría haberse iniciado un
cumplimiento. Este Data_Object tiene la estructura indicada en el
diagrama 9.
\vskip1.000000\baselineskip
Diagrama
9
Este tipo de Data_Object comprende los
siguientes elementos de datos:
- TA_ID:
- Este elemento de datos tiene el mismo significado que en los diagramas anteriores.
- Error_ID:
- El elemento Error_ID contiene informaciones específicas respecto al tipo de error que se ha producido y, por lo tanto, respecto al motivo de un eventual cumplimiento. Es un número de 2 bytes.
- Error_Data:
- Este elemento de datos de longitud variable contiene informaciones específicas acerca del error que se ha producido realmente.
- MAC:
- Este elemento de datos de una longitud de 8 bytes contiene un Message Authentication Code.
El Data_Object del tipo 5 contiene informaciones
que en caso de haber mensajes de la clase Advice Response son
devueltas del ordenador central al RSE. Indica o la transmisión y
comprobación satisfactorias del fichero transmitido o ofrece
informaciones especiales en caso de un error. Un mensaje de la clase
Advance Response puede contener uno o varios Data_Objects de este
tipo. La estructura de un Data_Object del tipo 5 se muestra en el
diagrama 10.
Diagrama
10
Este tipo de Data_Object comprende los
siguientes elementos de datos:
- Response_Code:
- Este elemento de datos contiene un número de 2 bytes, que indica si la transmisión ha sido correcta o incorrecta. En caso de un error, el Response_Code define el tipo de error.
- Reference:
- Este elemento de datos es un número de 4 bytes y puede hacer referencia a un elemento de datos de la PDU o a un Data_Object, o un elemento de un Data_Object en el Message_Body en el que se ha encontrado un error.
- MAC:
- Este elemento de datos de una longitud de 8 bytes contiene un Message Authentication Code.
Un mensaje de la clase Advice del tipo arriba
definido contiene exactamente un Transaction_File. Deben
transmitirse distintos Transaction_Files mediante distintos
mensajes. Si existe una limitación respecto a la longitud del
mensaje, debe cerrarse un Transaction_File en cuanto se haya
producido un número determinado de Transaction_Records.
En la forma de realización expuesta a título de
ejemplo, para asegurar la transmisión de un Transaction_File, para
la autenticación de los Data_Objects y para la autenticación de los
Payment_Objects está previsto el uso de Message Authentication
Codes (MAC), que se generan mediante un algoritmo de cifrado
simétrico como, por ejemplo, del DEA (Data Encryption Algorithm) o
del IDEA (International Data Encryption Algorithm). Un algoritmo de
cifrado simétrico se caracteriza porque tanto el emisor como el
receptor deben disponer de forma confidencial y/o de forma
asegurada respecto a la integridad de los mensajes que han de ser
transmitidos del mismo secreto criptográfico
(clave).
(clave).
No obstante, en determinados casos puede ser
necesario usar en lugar de ello algoritmos de cifrado asimétricos,
por ejemplo, cuando deben emplearse firmas digitales o cuando de
esta forma puede simplificarse la gestión de claves. Al usar
algoritmos de cifrado asimétricos, los dos interlocutores de la
comunicación disponen de distintas partes de la clave que, no
obstante, presentan una relación matemática estricta entre sí, de
las que sólo debe mantenerse secreta una parte (la clave de
generación de firma) pudiendo ser pública la otra parte (la clave
de comprobación de firma). No obstante, en este caso debe ser
firmada (certificada) la clave pública de un participante por una
instancia independiente, como ya se ha explicado anteriormente en
relación con la instancia de certificación. Estos certificados de
claves pueden ser registrados, por ejemplo, en una lista pública
(por ejemplo, X.500 directory).
A pesar de la descripción del empleo de la
técnica MAC, las realizaciones, en particular de las estructuras de
datos, han de entenderse a título de ejemplo de tal forma que el
campo MAC correspondiente actúa como comodín para estructuras de
seguridad a elegir libremente, incl. informaciones adicionales
relacionadas con la seguridad, como identificador de algoritmo,
tipo y número de clave, modo de aplicación para algoritmo de cifrado
y muchas más. Esta observación también es valida para todas las
estructuras de datos que se describirán más adelante.
Concentrador \leftrightarrow Adquirente
\leftrightarrow Emisor
Los datos relevantes para el pago, procesados en
forma de un fichero de deuda activa (Fee Claim File), son recibidos
por los adquirentes correspondientes online según el mismo protocolo
de comunicación que también está previsto para la transmisión
online entre RSE y concentrador de un proveedor de servicios. Puesto
que en este interface se encuentran distintos dominios de
seguridad, la transmisión de estos datos está asegurada mediante
claves propias que han de ser fijadas especialmente y sólo para este
fin entre el proveedor de servicios y el adquirente.
Si se realizan las comprobaciones habituales de
la autenticidad y unicidad o novedad de los datos presentados de la
deuda activa con resultado positivo, entra en vigor la garantía de
pago basada en los acuerdos contractuales entre el proveedor de
servicios y el adquirente. Las comprobaciones incluyen también la
autenticación de los medios de pago empleados, verificándose los
importes disponibles o las informaciones de la cuenta certificados
para un proceso de pago. Gracias a la separación de los dominios de
seguridad entre los medios de pago y la aplicación EAT, los
certificados no pueden ser verificados inmediatamente por la
aplicación EAT de la OBU o del RSE durante el proceso de pago, sino
que no puede verificarse hasta después de haberse presentado un
fichero de la deuda activa al adquirente, que en calidad de
proveedor de servicios dispone de las claves correspondientes frente
al emisor.
Respecto a su estructura, los mensajes y datos
en la interfaz entre el proveedor de servicios y la caja de
compensación son similares a los que se han descrito ya
anteriormente para la interfaz entre el RSE y el proveedor de
servicios o el CC.
El proveedor de servicios envía, por ejemplo, a
diario un mensaje de la clase Advice, que contiene un llamado
Fee_Claim_File al adquirente. Este fichero está formado por un
Header_Record, que depende de un Data_Object del tipo 6 y los Fee
Claims reales, es decir, procesos de tasas individuales
representados por Data_Objects del tipo 7 u 8.
La transmisión correcta o incorrecta es
confirmada por el adquirente mediante un mensaje de la clase Advice
Response y este mensaje contiene uno o varios Data_Objects del tipo
5 arriba definido.
Los Data_Objects de los tipos 6, 7 y 8 están
definidos por las siguientes estructuras y contenidos:
El Data_Object del tipo 6 contiene la
información acerca del Header para el Fee Claim File, que es enviado
por el proveedor de servicios o el ordenador central de éste al
adquirente. El diagrama 11 muestra la estructura del Data_Object del
tipo 6.
\vskip1.000000\baselineskip
Diagrama
11
Este tipo de Data_Object comprende los
siguientes elementos de datos:
- FC_Number:
- Este elemento de datos contiene el número de Fee_Claim_Records respecto al prepago y postpago en el Fee Claim File y determina, por consiguiente, el número de Data_Objects del tipo 7 y 8 en el mensaje.
- Fee_Total_Sum:
- El elemento de datos Fee_Total_Sum contiene la suma de todos los importes de tasas que están contenidos en el elemento de datos correspondiente de los Fee Claim Record Data Objects del tipo 7 u 8.
- SP_Account:
- El número de cuenta (Account Number) del proveedor de servicios para el abono del importe Fee_Total_Sum.
- MAC:
- Este elemento de datos contiene el Message Authentication Code.
Los elementos de datos FC_Number y Fee_Total_Sum
son números de 4 bytes. El elemento de datos SP_Account es un número
de 10 bytes. MAC es un número hexadecimal de 8 bytes.
El Data_Object del tipo 7 contiene un
Fee_Claim_Record relacionado con el prepago del Fee Claim File, que
es enviado por el proveedor de servicios al adquirente. La
estructura del Data_Object del tipo 7 se muestra en el diagrama
12.
Diagrama
12
Este tipo de Data_Object comprende los
siguientes elementos de datos:
- FC_ID:
- Este elemento de datos cuenta de forma correlativa los Fee-Claim Records del Fee Claim File. El elemento de datos FC_ID es un número de 4 bytes.
- PO:
- Este elemento de datos es, por ejemplo, una información de 20 bytes según la definición en relación con el diagrama 7 respecto al Data-_Object del tipo 2.
- Fee_Total:
- Este elemento de datos contiene el importe total de todas las tasas individuales, que se han deducido del importe disponible en una OBU respecto al mismo Payment Object. El elemento de datos Fee-Total es un número de 2 bytes.
- MAC:
- Este elemento de datos de una longitud de 8 bytes contiene un Message Authentication Code.
El Data_Object del tipo 8 contiene un
Fee_Claim_Record relacionado con el postpago del Fee Claim File, que
debe ser enviado por el proveedor de servicios al adquirente. La
estructura del Data_Object del tipo 8 se muestra en el diagrama
13.
\vskip1.000000\baselineskip
Diagrama
13
Este tipo de Data_Object comprende los
siguientes elementos de datos:
- FC_ID:
- Este elemento de datos tiene el mismo significado que en el Data_Object del tipo 7, diagrama 12.
- PO:
- Este elemento de datos es, por ejemplo, una información de 18 bytes según la definición en relación con el Data_Object del tipo 3, diagrama 8.
- Fee_Total:
- Este elemento de datos contiene la suma total de todas las tasas que se han deducido en una OBU respecto al mismo PO. El elemento de datos Fee-Total es un número de 2 bytes.
- MAC:
- Este elemento de datos de una longitud de 8 bytes contiene un Message Authentication Code.
Todos los procesos que van unido al cumplimiento
de la garantía de pago para la iniciación de abonos en cuenta para
proveedores de servicios y cargos en cuenta para emisores son
procesos habituales en los movimientos de pago relacionados con los
movimientos bancarios nacionales e internacionales, por lo que no es
necesario explicarlos más detalladamente en este contexto.
No obstante, se supone que la transmisión de las
informaciones relevantes para la compensación del pago acerca de
abonos en cuenta y cargos en cuenta se realiza según el
procedimiento de intercambio de soportes de datos habitual en la
economía crediticia alemana (procedimiento DTA).
Además del intercambio de datos entre
adquirentes y emisores relevante para los movimientos de pagos, en
el caso de emplearse medios de pago pagados previamente puede ser
necesario proporcionar datos relacionados con procesos de carga y
descarga para supervisar la seguridad del sistema (respecto al
sistema de pago). De forma análoga a la organización de estas
tareas para el monedero universal de institutos financieros, según
la invención está previsto que esta supervisión sea realizada por
emisores.
Para ello, el emisor administra para cada medio
de pago correspondiente un saldo sombra, que resulta de la
compensación de importes de carga con importes de pago. Los importes
de carga deben ser anunciados por las agencias o terminales de
carga a los emisores en forma de llamados avisos de carga. Los
importes de pago que han de ser compensados con ellos se determinan
en el marco del procesamiento de los Fee Claim Files arriba
descritos y se transmiten a los emisores.
El saldo sombra está asignado exactamente a un
medio de pago concreto, aunque no dé a conocer ninguna referencia a
una persona, puesto que el ID del medio de pago no está relacionado
con personas. Generalmente, un saldo sombra está siempre positivo y
excepciones temporales sólo son posibles cuando los avisos de carga
de procesan con retraso frente a las transacciones de pago. Unos
saldos sombra permanentemente negativos indican, en cambio, un
ataque serio contra todo el sistema de pago pagado previamente.
Según la invención, los avisos de carga se
envían en un Load_File al emisor. Este fichero consta de un
Header_Record, que determina un Data_Object del tipo 9, y de los
Load_Records propiamente dichos, es decir, los diferentes importes
de carga y descarga representados por Data_Objects del tipo 10 y
11.
La estructura del Data_Object del tipo 9 es
idéntica a la del Data_Object del tipo 6 y contiene la información
acerca del Header del Load_File.
\vskip1.000000\baselineskip
Diagrama
14
Este tipo de Data_Object comprende los
siguientes elementos de datos:
- LR_Number:
- Este elemento de datos contiene el número de Load_Records del Load_File y determina, por lo tanto, el número de los Data_Objects del tipo 10 y 11.
- Load_Sum:
- Este elemento de datos corresponde a la suma de todos los importes de carga y descarga contenidos en los Load_Records sucesivos respecto a los medios de pago correspondientes.
- PP_Account:
- Una pluralidad de medios de pago pagados previamente (por ejemplo, monederos electrónicos) tiene asignada, por regla general, una sola cuenta pool, en la que se cargan los importes de los pagos realizados con los medios de pago correspondientes, que son presentados por proveedores de servicios para su abono en la cuenta del adquirente.
- MAC:
- Este elemento de datos contiene un Message Authentication Code.
Los elementos de datos LR_Number y Load_Sum son
números de 4 bytes. El elemento de datos PP_Account es un número de
10 bytes. MAC es un número hexadecimal de 8 bytes.
El Data_Object del tipo 10 contiene un
Load_Record del Load_File mediante un proceso de carga (por ejemplo,
para la carga de un monedero electrónico), que se transmite al
emisor.
\vskip1.000000\baselineskip
Diagrama
15
Este tipo de Data_Object comprende los
siguientes elementos de datos:
- LR_ID:
- Este elemento de datos numera de forma correlativa los Load_Records del Load_File y es un número de 4 bytes.
- Payment-Object:
- Este elemento de datos es, por ejemplo, una información de 20 bytes, que indica la carga de un importe disponible en un medio de pago pagado previamente. Su contenido puede constar de cuatro elementos iguales, que también están definidos para el proceso de pago mediante la interfaz aérea o la introducción en los movimientos de pagos para el Data_Object del tipo 2.
- MAC:
- Este elemento de datos contiene un Message Authentication Code.
Los procesos de descarga, es decir, la descarga
de medios de pago pagados previamente, se indican mediante
Data_Objects del tipo 11, cuya estructura es idéntica a la de los
Data_Objects del tipo 10.
Emisor \leftrightarrow instancia de
carga/agencia de venta \leftrightarrow medio de
pago/On-Board Equipment
Las interfaces que han de ser definidos en este
contexto se refieren en primer lugar a la comercialización de
medios de pago y On-Board Units, la carga o descarga
de medios de pago pagados previamente y las relaciones con los
clientes que van unidas a ello, por lo que no deben explicarse más
detalladamente en este contexto.
No obstante, hay que indicar que al emplear
tarjetas chip multifuncionales como medios soporte para medios de
pago y/o aplicaciones EAT, las dependencias técnicas ya mencionadas
entre distintos emisores de tarjetas y aplicaciones y las medidas
en razón de la técnica que van unidas a ello, también deben
reflejarse en las relaciones jurídicas/organizativas.
Las estructuras de los mensajes y objetos de
datos transmitidos en este interface corresponden fundamentalmente a
las que ya se han descrito anteriormente.
On Board Equipment \leftrightarrow Punto de
control EAT
La comprobación de la existencia de un
comprobante de pago en un On-Board Equipment
mediante un punto de control EAT móvil o estacionario se realiza en
una forma de realización especialmente preferible de la invención en
gran medida de forma análoga al proceso de pago propiamente dicho
con los pasos de protocolo ya definidos:
- T
- Tender
- \quad
- En primer lugar, el dispositivo de pago (OBE) recibe los datos acerca de la funcionalidad del punto de control EAT y del proveedor de servicios asignado (Beacon Service Table). También aquí son posibles consultas de estado adicionales (List of Boolean Challenges), de forma similar al caso de un RSE de pago.
- R
- Registration
- \quad
- Antes de presentar el OBE su comprobante de pago, debe verificarse la autenticidad del punto de control EAT por motivos relacionados con la protección de datos. Para este fin se genera un número aleatorio (OBE Random Challenge) y se transmite junto con el número de clave de grupo, así como una indicación del sistema de pago usado para el último pago (del nivel de servicio correspondiente) al punto de control EAT. Al mismo tiempo pueden transmitirse respuestas (List of Boolean Responses) a las consultas booleanas.
- RQ
- Receipt Request
- \quad
- Para que pueda autenticarse el punto de control EAT mediante el OBE, se envía la identificación del RSE, la fecha y la hora del control al OBE. Este mensaje está provisto de un autenticador, que como ya se ha descrito anteriormente depende de un "Sessionkey". Se envía también otro número aleatorio (RSE Random Challenge) para la posterior autenticación del OBE.
- RP
- Receipt Presentation
- \quad
- Después de recibir un mensaje RQ, el OBE autentica en primer lugar el punto de control EAT verificando para ello el autenticador. A continuación, se presenta en un mensaje autenticado o se comprueba (en el caso de un sistema cerrado) el ticket de entrada cifrado, que se ha recibido en primer lugar del nivel de servicio correspondiente o (en un sistema abierto) el pago que se ha realizado en último lugar (recibo para cumplimiento, sin cifrado) o en el caso de un pago fallado, el último intento de pago (Preliminary Ticket).
\newpage
- RC
- Receipt Confirmation
- \quad
- Después de haber recibido y comprobado la Receipt Presentation, el punto de control EAT indica su resultado de la comprobación en un mensaje cifrado al OBE. En caso de una comprobación negativa, los datos determinados pueden ser procesados o transmitidos por el punto de control EAT directamente para el aseguramiento de la prueba y el posterior pago de la tasa. Como opción, pueden transmitirse con el mensaje marcas booleanas (cifradas).
- \quad
- En principio, el punto de control EAT podría ser capaz, además, de realizar una comprobación de bloqueos del medio de pago empleado basándose en los datos de identificación. En caso de que durante este proceso se detectara una nota de bloqueo para el medio de pago empleado, por un lado, podría transmitirse al OBE una solicitud de bloquear el medio de pago y, por otro lado, podría procesarse y transmitirse la identificación del medio de pago empleado para la actualización de las listas de bloqueos.
Debido a los procesos de seguridad en el
protocolo de transmisión, una comprobación del pago sólo es posible
si en el OBE está activo el SAM de la aplicación EAT en el momento
de la comprobación. En el caso de las opciones de realización II y
IV del OBE, la comprobación de pago puede fallar, por lo tanto,
cuando la tarjeta chip con la aplicación EAT no está insertada en el
OBE en el momento del control.
Otras características y ventajas de la invención
resultan de la siguiente descripción de un sistema y del
procedimiento que se puede realizar con el mismo, así como de los
dibujos a los que se hace referencia. Muestran:
la fig. 1 un diagrama de bloques de un sistema
según la invención formado por un emisor de consultas y un
transpondedor;
la fig. 2 un alzado lateral generalizado de un
tipo de disposición típico de un sistema según la figura 1;
la fig. 3 un diagrama de bloques de una
disposición de transpondedor y emisor de consultas para el uso en un
sistema según las figuras 1 y 3;
la fig. 4 un diagrama de bloques más detallado
del transpondedor según la figura 3 para la representación de los
componentes del transpondedor y una tarjeta inteligente que puede
comunicar con el transpondedor; y
la fig. 5 un diagrama de tiempo general para la
representación del procedimiento que puede realizarse con la
disposición de transpondedor/tarjeta inteligente.
Los mismos componentes estarán provistos de los
mismos signos de referencia y símbolos en las distintas
figuras.
figuras.
La figura 1 muestra un diagrama de bloques de un
sistema 10 para la exacción automática de tasas con ayuda del
ejemplo de una exacción de tasas para el uso de carreteras, en la
que un emisor de consultas 12 comunica con un transpondedor 14
transportable mediante la emisión de una señal de consulta, una
consulta de transacción y una confirmación de transacción 15a al
transpondedor 14, que reenvía una señal de respuesta y una respuesta
de transacción 15b al emisor de consultas 12. En un sistema EAT 10
típico, el emisor de consultas 12 puede transmitir partes
relevantes de esta información a un ordenador central (host) 16 para
la administración y el procesamiento de informaciones de
compensación respecto al transpondedor 14 y a la tarjeta inteligente
66 asignada (véase la figura 4).
Como se muestra en la figura 2, unos carriles 28
están asignados a un punto de regulación de tráfico, como por
ejemplo un punto de exacción de tasas 29. Cada carril 28 tiene su
emisor de consultas 12 asignado. Cada emisor de consultas 12 inicia
una comunicación y la mantiene mediante una comunicación por radio
con transpondedors 14, que están previstos en vehículos 26, que se
mueven en el carril 28 asignado al emisor de consultas 12. Los
emisores de consultas 12 pueden tener parámetros eléctricos
interiores unificados, como por ejemplo, posición de carril del
emisor de consultas, parámetros de control del emisor de consultas y
frecuencia de referencia de consulta. En esta aplicación, la
función del emisor de consultas 12 es iniciar o activar un
transpondedor 14, consultarlo o estimular al transpondedor 14 para
que emita informaciones específicas y, en el caso de un intercambio
de datos admisible, confirmar este hecho al transpondedor 14. Como
se muestra en las figuras 1 y 2, el emisor de consultas 12 tiene
una antena 18, que está fijada preferiblemente por encima de la
carretera. El sistema electrónico del emisor de consultas 20 está
conectado con la antena 18 mediante un cable adecuado, por ejemplo
un cable coaxial de radio 22.
El emisor de consultas 12 comunica de forma
inalámbrica con el transpondedor 14 mediante la emisión de señales
de fase codificada y moduladas, seguidas de una señal continua de
ondas de alta frecuencia. El transpondedor 14 puede contestar al
emisor de consultas 12 mediante el reenvío modulado de la señal
continua de ondas de alta frecuencia, como está descrito, por
ejemplo, en el documento DE-R 37 74 015. Otros
detalles de la comunicación posterior entre el emisor de consultas
12 y el transpondedor 14 se describirán más adelante. Una tarea
posible del ordenador central 16 es controlar la operación del
emisor de consultas 12 y las funciones periféricas del punto de
exacción de tasas. Las funciones periféricas de sete tipo pueden
servir para el control de barreras de tráfico y otros equipamientos
de control de la calzada, como cámaras y luces de tráfico. Otras
funciones periféricas podrían ser comunicaciones entre los emisores
de consultas 12 y otro centro de cálculos no representado (por
ejemplo, de un adquirente), que procesa informaciones de procesos de
adeudos. La conexión 24 entre el emisor de consultas 12 y el
ordenador central 16 puede realizarse mediante Ethernet, Tokenring,
RS 232, RS 422 u otros.
La figura 2 muestra una disposición típica de un
sistema 10. En esta figura, un vehículo 26 se desplaza en un carril
28 y se aproxima de esta forma a la antena 18. El transpondedor 14
está dispuesto encima del vehículo 26 o en el interior de éste. El
transpondedor 14 está fijado preferiblemente en la luna delantera
del vehículo. En determinadas aplicaciones, como por ejemplo en el
caso de vehículos extraordinariamente grandes, pueden ser adecuados
otros lugares de fijación, como por ejemplo, el parachoques de un
camión, para reducir la variación de la altura de fijación del
transpondedor 14. Como se muestra en la figura, el vehículo 26 que
porta el transpondedor 14 se aproxima al emisor de consultas 12 del
punto de exacción de tasas 29. Otros detalles respecto a la
comunicación entre el transpondedor 14 y el emisor de consultas 12
se tratarán a continuación más detalladamente. También se
describirán más exactamente los componentes del emisor de consultas
12 y del transpondedor 14.
La figura 3 muestra un diagrama de bloques de
los componentes principales del sistema 10. En primer lugar, el
transpondedor 14 se describe haciéndose referencia a la figura 4 en
relación con las figuras 2 y 3. El sistema 10 comprende
preferiblemente antenas direccionales 18, estando dirigida cada
antena 18 a un carril 28 asignado a la misma. En cada carril 28
pueden ir uno o varios vehículos 26, presentando cada vehículo 26
uno o varios transpondedors 14. Cada transpondedor 14 comprende
preferiblemente lo siguiente: una antena 30, un ASIC analógico o
analógico/digital 32, un ASIC digital 34 y un reflector para la
modulación 41. La antena 30 y el reflector para la modulación 41
pueden formar una sola antena 31 integrada. El ASIC 32 y el ASIC 34
están integrados preferiblemente en un solo
ASIC.
ASIC.
Si se sigue haciendo referencia a la figura 3
puede verse que la antena del transpondedor 30 se hace funcionar
para la recepción de transmisiones de alta frecuencia del emisor de
consultas 12. El ASIC analógico 32 convierte una señal alimentada
por la antena del transpondedor 30 en una tensión, que activa el
transpondedor 14 al sobrepasarse un valor umbral. El ASIC analógico
32 detecta preferiblemente una modulación de alta frecuencia
superpuesta a una señal de la antena del transpondedor 30 y sólo
activará el transpondedor 14 cuando existe esta frecuencia de
modulación especial. De esta forma, el transpondedor 14 es
relativamente inmune a ser activado por transmisiones de alta
frecuencia perturbadoras que no procedan del emisor de consultas 12,
sino que sólo es activado cuando se transmite una frecuencia
especial del emisor de consultas 12. El valor umbral de tensión
puede ser ajustado.
Como también muestra la figura 3, el ASIC
analógico 32 y el ASIC digital 34 procesan típicamente la señal de
consulta recibida por un transmisor 52 y forman los datos de
respuesta necesarios. A continuación, el ASIC digital 34 entrega
una corriente de datos de respuesta formateada al reflector para la
modulación 41. El ASIC 34 puede ser un sistema digital simple, que
usa un formato fijo, o un sistema de procesamiento digital más
complejo, que puede presentar una pluralidad de opciones. Para el
ASIC 34 son pensables muchas funciones, por ejemplo, el
almacenamiento de datos, historial de transacciones, protocolos de
intercambio de datos y señales de aviso de la capacidad de la
batería. El reflector para la modulación 41 se modula mediante
variación de su longitud de onda visible, preferiblemente entre 1/4
y 1/2 de la longitud de la onda portadora \lambda. Si la longitud
de onda visible del reflector para la modulación 41 es 1/2\lambda,
la antena 30 refleja una gran parte de la energía portadora
incidente. Si el reflector para la modulación 41 presenta una
longitud de onda visible de 1/4\lambda, sólo refleja muy poco de
la energía portadora incidente. Como se sabe generalmente, puede
realizarse una conmutación de la antena entre 1/2\lambda y
1/4\lambda mediante la conexión o separación de dos tetones
adaptadores 1/4. En la forma de realización descrita, la variación
de la sección transversal de reflexión está situada preferiblemente
en el intervalo de 45 cm^{2} a 100 cm^{2}. Mediante la variación
de la sección transversal de reflexión según el formato específico,
se envían datos del transpondedor 14 al emisor de consultas 12.
Para la energía de servicio necesaria para ello, en el transpondedor
14 puede estar prevista una batería. Como alternativa, el
transpondedor 14 también puede recibir su potencia de servicio
directamente de la señal de alta frecuencia, como se da a conocer,
por ejemplo, en el documento DE-R 37 88 348. Los
transpondedors 14 pueden estar realizados típicamente en una forma
de construcción pequeña, del tamaño de una tarjeta de crédito,
pudiendo ser transportados fácilmente de esta forma.
Después de haberse descrito ahora los
componentes del transpondedor 14, se hablará de una forma de
realización preferible del emisor de consultas 12, haciéndose
referencia para ello también a la figura 3. El emisor de consultas
12 está dispuesto en un lugar específico, en el que se desea un
intercambio de datos, por ejemplo, un punto de pago de tasas. El
sistema 10 puede comprender un oscilador de referencia 50 general,
que genera en su salida 51 una onda portadora de referencia para la
coordinación entre los emisores de consultas 12. Cada emisor de
consultas 12 tiene una antena direccional 18 y un emisor 52, que
emite una señal de disparo con una intensidad de campo suficiente y
una distancia predeterminada, para iniciar o activar un
transpondedor 14 que es portado por un vehículo 26 en el carril 28
asignado al emisor de consultas 12.
La figura 4 muestra un diagrama de bloques de
una forma de realización preferible de un transpondedor 14 en el
estado de comunicación con una tarjeta inteligente 66 mediante una
interfaz 68. La tarjeta inteligente 66 se inserta en la unidad de
establecimiento de contacto con la tarjeta chip 70, de modo que
pueda realizarse una comunicación a través de la interfaz 68. El
transpondedor 14 comprende una interfaz del usuario 72, que
presenta a su vez una pantalla de cristal líquido 74 y un teclado
76. La pantalla de cristal líquido 74 se usa preferiblemente para
visualizar para el usuario el importe almacenado en el transpondedor
14 o la última tasa que se ha deducido. Después de haber comprobado
un microcontrolador 78 del transpondedor 14 que la tarjeta
inteligente 66 es compatible con el transpondedor 14, el
microcontrolador 78 puede iniciar opcionalmente un "proceso de
autorización", en el que el usuario introduce su número de
identificación personal (PIN) mediante el teclado 76. No obstante,
para asegurar que la tarjeta inteligente 66 puede ser usada con el
transpondedor 14, también pueden usarse otros "procedimientos de
autorización". Mediante la entrada del PIN, que es entregado por
el microcontrolador 78 del transpondedor 14 a la tarjeta inteligente
66 y que es comparado por ésta con un valor de identificación
almacenado en la misma, se asegura que los importes u otros datos de
la tarjeta inteligente 66 sólo se emitan de forma autorizada. La
comprobación anteriormente indicada y la "autorización" se
realizan preferiblemente a través de la interfaz 68, que es con
preferencia una interfaz serie.
En una forma de realización especial de la
invención, la tarjeta inteligente 66 puede transmitir datos que
representan un importe, que preferiblemente es un múltiplo del
importe de tasa que ha de ser pagado típicamente por el
transpondedor 14. En este proceso se generan datos acerca del valor
del importe de la transacción, del proveedor de servicios, de la
identificación de la tarjeta inteligente y acerca de otras
informaciones.
Inicialmente, la tarjeta inteligente 66 genera,
por lo tanto, una información que es almacenada en el transpondedor
14. La información generada actualmente por la tarjeta inteligente
66 se llama certificado de tarjeta inteligente. Este certificado de
tarjeta inteligente comprende habitualmente lo siguiente: 1) un área
de datos no cifrados, que representan el lugar, la hora, el número
de la tarjeta inteligente y otras informaciones necesarias para el
administrador del sistema para asegurar que ha tenido lugar un
proceso válido; 2) un área cifrada, que comprende informaciones
relevantes para la seguridad y otras informaciones. En caso de que
el microcontrolador 78 sea capaz de leer con éxito esta área
cifrada, el certificado se almacena en el transpondedor 14 bajo la
administración del microcontrolador 78. Este certificado de tarjeta
inteligente puede ser almacenado en la RAM 80 o en la EEPROM 82. La
ventaja de un almacenamiento en la EEPROM está en las
características de memoria permanente, no volátil de una EEPROM.
Por motivos relacionados con la seguridad y la
protección de datos, existe un dispositivo de cifrado/descifrado
84, que comunica con el microcontrolador 78. Este dispositivo de
cifrado/descifrado cifrará y descifrará o autenticará datos
transmitidos por y a la tarjeta inteligente 66. De esta forma se
impide a las personas omitir el uso de la tarjeta inteligente 66
mediante intervenciones no autorizadas en el transpondedor 14
aumentando de esta forma el importe almacenado en el transpondedor
14. De esta forma tampoco será posible retransmitir un importe
posteriormente aumentado del transpondedor 14 a la tarjeta
inteligente 66.
El transpondedor 14 recibe su energía
preferiblemente de baterías, aunque también la puede recibir del
vehículo o de otras fuentes. Además, el transpondedor 14 puede
estar integrado en un vehículo o en otro sistema.
La tarjeta inteligente 66 puede ser llevada por
un usuario a un equipo similar a un cajero automático, en el que
puede introducirse dinero y en el que se transmiten unidades de
valor que representan este importe u otro importe a la tarjeta
inteligente 66. Como alternativa, puede retirarse dinero de una
cuenta o deducirse de una cuneta de crédito y pueden cargarse datos
que representan este importe u otro importe en la tarjeta
inteligente 66. Después de haberse transferido estos datos del
equipo de carga externo a la tarjeta inteligente, el usuario puede
llevar la tarjeta inteligente 66 como monedero electrónico y usarla
en combinación con su transpondedor 14 o quizás con otras
posibilidades de aplicación.
La ventaja de un uso de este tipo de una tarjeta
inteligente está en que confiere al usuario cierto grado de
confidencialidad o de esfera privada. En sistemas en los que se usan
equipos externos como cajeros automáticos es posible, por ejemplo,
introducir directamente dinero en efectivo en esta máquina, por lo
que no es necesaria una identificación del usuario.
En una transacción de pago típica después de la
entrada en la zona de exacción de tasas de un sistema EAT abierto o
en la salida de un sistema cerrado (por ejemplo, garaje público), el
emisor de consultas 12 consultará el transpondedor 14. Esto
comienza con un mensaje de aproximación o de llamada para advertir
al transpondedor 14 que se encuentra en la zona de exacción de
tasas. La señal de aproximación puede contener ya informaciones
acerca del tipo, del servicio y de la localidad del punto de
exacción de tasas (Beacon Service Table). Después de la recepción
de la señal de aproximación por parte del transpondedor 14 y su
activación, el transpondedor 14 indica mediante la emisión de una
señal de listo para el servicio al emisor de consultas 12 su
disposición para la tramitación de una transacción. Esta señal de
listo para el servicio puede contener, a su vez, informaciones
acerca del tipo y del alcance de funciones del transpondedor
(Vehicle Service Table).
A continuación, el emisor de consultas 12 envía
una señal de consulta (T), que contiene datos acerca de los
contratos y procedimientos de pago (tarjeta de crédito o débito,
monedero, etc.) aceptados por el proveedor de servicios y
eventualmente otras informaciones acerca del punto de exacción de
tasas.
Con una señal de respuesta (R), el transpondedor
14 informa al emisor de consultas 12 acerca de la clase del
vehículo 26, de las condiciones especiales de pago (por ejemplo,
tarifa de minusválidos, cliente importante, vehículo soberano,
etc.), acerca del estado de validez del transpondedor o medio de
pago (expiry date), del tipo del medio de pago que ha de ser usado,
así como de un ticket de entrada eventualmente existente. Además,
la señal de respuesta contiene datos acerca del procedimiento de
cifrado (por ejemplo, número de clave de grupo), así como un número
aleatorio generado por el transpondedor 14 o la tarjeta inteligente
66 para la autenticación del emisor de consultas 12. Además, pueden
transmitirse en la señal de respuesta informaciones acerca del
momento del último pago, por ejemplo, si este pago se ha realizado
en el mismo punto de exacción de tasas.
El emisor de consultas 12 procesará esta
información y reenviará una consulta de transacción (PD) para
solicitar el pago de la tasa. El transpondedor 14 encontrará a
continuación un momento adecuado para realizar deducciones de las
unidades de valor totales almacenadas en las memorias 80, 82 del
transpondedor actualmente existentes. Como alternativa, también
puede estar previsto un sistema en el que el importe de la tasa
depende del tramo recorrido. En este caso, al entrar en esta zona
sujeta al pago de tasas sólo es necesario que en el punto de
entrada se almacene un código de lugar o un ticket de entrada en el
transpondedor 14. En caso de usarse este procedimiento, al
aproximarse el transpondedor 14 a la zona de tasas, indicará su
punto de entrada al emisor de consultas 12 en la señal de respuesta
(R). El emisor de consultas 12 calculará a continuación la tasa
resultante y la indicará al transpondedor 14 en la consulta de
transacción (PD). En este momento, el importe de la tasa se
deducirá del importe almacenado en el transpondedor 14, como ya se
ha descrito anteriormente.
En función del momento actual y debido a los
datos acerca de la case de vehículo, las condiciones especiales de
pago y el ticket de entrada (o lugar de entrada, duración de la
estancia, etc.) contenidos en la señal de respuesta (R), la tasa
que ha de ser pagada se determina en el emisor de consultas 12. A
continuación, el emisor de consultas 12 enviará al transpondedor 14
una consulta de transacción (PD), que contiene la tasa que ha de
ser pagada, así como la fecha y la hora del momento de la
transacción, un estado o código de error, un número aleatorio
generado por el transpondedor 12 para la autenticación del
transpondedor 14, así como una información acerca de la tarifa en
la que se basa la determinación del precio. La consulta de
transacción contiene también un Message Authentication Code (MAC),
que representa un código de seguridad cifrado usando un
procedimiento de cifrado, como por ejemplo, el Data Encryption
Standard (DES).
Después de la comprobación del MAC contenido en
la consulta de transacción (PD), es decir, la autenticación del
emisor de consultas 12 mediante el transpondedor 14, el importe
disponible almacenado en las memorias 80 ó 82 del transpondedor se
reduce mediante la deducción de la tasa solicitada y el resultado
del procesamiento (status) se transmite junto con el certificado de
la tarjeta inteligente en una respuesta de transacción (P) al
emisor de consultas 12. La respuesta de transacción (P) contiene
como certificado de transpondedor también un Message Authentication
Code (MAC) que es generado por el transpondedor 14. Este es
comprobado por el emisor de consultas 12 tras la recepción de la
respuesta de transacción (P), de modo que en el caso positivo el
transpondedor 14 se considera auténtico.
Para finalizar la transacción, el emisor de
consultas 12 envía a continuación una confirmación de transacción
(CR) parcialmente cifrada al transpondedor 14, que contiene al menos
una confirmación del pago realizado (status), informaciones acerca
del lugar y momento del pago, un número de recibo y un autenticador
(por ejemplo, MAC). Después de haberse realizado con éxito el
descifrado de la confirmación de la transacción (CR), los datos del
recibo se almacenan de tal forma en las memorias 80 ó 82 del
transpondedor que pueda emitirse tanto una información adicional
para el usuario como un comprobante de pago, por ejemplo, ante un
punto de control.
La transmisión del certificado de tarjeta
inteligente del transpondedor 14 al emisor de consultas 12 permite
a los dispositivos administrativos actualizar un llamado "balance
sombra" o realizar un contaje continuo de cuántas veces se ha
cargado una tarjeta inteligente 66 emitida y confirmar que una
cantidad de dinero existente en la tarjeta inteligente 66 emitida
coincide con la cantidad de dinero realmente cargada en esta tarjeta
inteligente 66. Esto no supone necesariamente una infracción contra
la esfera privada del usuario, puesto que generalmente no puede
relacionarse el nombre de un usuario con una tarjeta inteligente 66
emitida. Cada transacción tiene un número de transacción asignado,
de modo que al realizar la contabilidad de todas las transacciones
puedan identificarse fácilmente las transacciones que faltan.
Mediante la transmisión de la señal de
aproximación, de la señal de listo para el servicio, la señal de
consulta, la señal de respuesta, la consulta de transacción, la
respuesta de transacción y la confirmación de transacción, así como
mediante la actualización de las informaciones directamente entre
las memorias 80 ó 82 del transpondedor y el emisor de consultas 12
en lugar de hacerlo directamente entre la tarjeta inteligente 66 y
el emisor de consultas 12 se superan los problemas de tiempo
respecto a la transmisión de datos en una ventana de comunicación
en la que el transpondedor se encuentra dentro del lóbulo del emisor
de consultas. Gracias a los extensos procedimientos de seguridad,
los protocolos y el intercambio continuo entre el emisor de
consultas 12 y el transpondedor 14, se han superado en su mayor
parte los problemas de seguridad que van unidos a las aplicaciones
conocidas de "dinero en forma de tarjetas".
La velocidad de las transacciones ha mejorado
enormemente en esta forma de realización en comparación con los
sistemas en los que la tarjeta inteligente 66 comunica directamente
con emisores de consultas 12 mediante un modulador y demodulador de
transpondedor. Esto se debe a que la mayor parte de las tarjetas
inteligentes 66 tienen interfaces estándar serie lentos. Es
importante que el tiempo de transmisión de datos entre el emisor de
consultas 12 y el transpondedor 14 sea independiente del tiempo de
acceso a la determinación y el almacenamiento de datos de y en la
tarjeta inteligente 66. Gracias al depósito temporal de datos en las
memorias 80, 82 del transpondedor 14, puede tener lugar la
comunicación más lenta entre el transpondedor 14 y la tarjeta
inteligente 66 después de haber terminado la comunicación con el
punto de exacción de tasas.
En una forma de realización especial, toda la
cantidad de dinero almacenada en la tarjeta inteligente 66 puede
ser transmitida al transpondedor 14. Antes de retirar la tarjeta
inteligente 66, la cantidad de dinero restante puede retransmitirse
a la tarjeta inteligente 66. Durante este proceso es evidente la
importancia del cifrado de los datos almacenados en el
transpondedor 14. Es un requisito importante que ninguna persona
tenga la posibilidad de manipular los datos almacenados en el
transpondedor 14 o de generar una cantidad de dinero mayor mediante
la retransmisión del dinero del transpondedor 14 a la tarjeta
inteligente 66. El papel del dispositivo de cifrado 84 está en
cifrar estos datos e incorporarlos en secuencias de procesamiento de
tramitación seguro y asegurado contra manipulaciones.
Una transacción de datos completa puede
realizarse preferiblemente en 10 milisegundos (ms). Durante este
tiempo, el transpondedor 14 contestará a la señal de consulta del
emisor de consultas 12. Al mismo tiempo se determina la tasa y se
transmite al transpondedor 14. Se generan también los certificados y
el importe correcto se deduce del importe disponible en el
transpondedor 14. Mientras que la invención permite una realización
de estas transacciones en 10 ms, los dispositivos conocidos de
tarjeta inteligente/transpondedor pueden realizarlo típicamente
sólo en 300 a 500 ms. Después de haber terminado la transacción, el
transpondedor 14 puede actualizar los datos en la tarjeta
inteligente 66 cuando la velocidad de la comunicación ya no es
decisiva, es decir, cuando el transpondedor 14 ya no se encuentra en
la zona de detección del emisor de consultas 12.
La tarjeta inteligente 66 puede ser usada tanto
por distintos usuarios como también para distintas aplicaciones. De
esta forma se supera en esta aplicación el problema del
almacenamiento actual y directo de importes en el transpondedor 14,
lo cual tendría el inconveniente de la movilidad restringida, puesto
que el transpondedor existe habitualmente en un solo vehículo y no
puede ser usado para otras posibilidades de uso. En la presente
forma de realización, un usuario puede usar su tarjeta inteligente
66 con su transpondedor 14 para pagos de tasas, pudiendo usarla, no
obstante, también para distribuidores automáticos, instalaciones
públicas de teléfonos u otras posibilidades de aplicación.
Esta forma de realización tiene, además, la
ventaja de la protección de datos mejorada y de la mayor
flexibilidad en comparación de sistemas
"money-on-tag", en los que el
dinero está almacenado sólo directamente en un "tag". En los
sistemas de este tipo, conocidos en el estado de la técnica, son
necesarias agencias especiales o explotadores del sistema con
equipos especiales para cargar dinero en el transpondedor 14. En la
presente forma de realización, el transpondedor 14 se carga con
dinero de la tarjeta inteligente 66, que puede haber recibido a su
vez dinero a través de autómatas similares a los cajeros
automáticos.
La figura 5 representa un diagrama de tiempo
para una forma de realización de esta invención. El transcurso del
tiempo puede ser subdividido aquí en tres fases diferentes. La
primera fase "Fase A - introducción", describe la parte de la
operación del usuario cuando el usuario introduce la tarjeta
inteligente 66 en el transpondedor 14. En la figura 5, este paso
recibe el nombre de bloque 102.
En el siguiente paso, el usuario puede
introducir a elección un número secreto personal (PIN) en el teclado
76, siempre que el transpondedor 14 esté correspondientemente
equipado y el medio de pago contenido en la tarjeta inteligente 66
lo permita o requiera. Esto se llama el bloque 104. Después de la
entrada, el PIN es transmitido por el microcontrolador 78 del
transpondedor 14 a la tarjeta inteligente 66 y ésta lo compara con
un valor de identificación almacenado en la misma. En el caso
positivo, la autorización ha terminado y se pude acceder a los
datos relevantes para el pago en la tarjeta inteligente 66. En
función del grado de seguridad deseado o requerido del medio de
pago, este proceso de autorización también puede ser suprimido o
puede realizarse de otra forma.
En el bloque 106, la tarjeta inteligente 66
genera un certificado de tarjeta inteligente, que comprende: 1) una
parte de datos no cifrados, que contienen el lugar y la hora de la
puesta a disposición, el número de tarjeta inteligente, las
unidades de valor que representan la cantidad de dinero descargada
de la tarjeta inteligente y eventualmente otras informaciones
necesarias para el explotador del sistema de pago (por ejemplo,
contador de adeudos, Message Authentication Code); y 2) un área
cifrada con informaciones relevantes para la seguridad y otras
informaciones que son necesarias para la comprobación de la
autenticidad del proceso. En caso de que el microcontrolador 78
pueda interpretar con éxito esta área cifrada, el certificado se
almacena en el transpondedor 14 o en la RAM 80 o en la EEPROM 82
bajo el control del microcontrolador 78.
Después de haber realizado esto, el
transpondedor 14 está listo para realizar transacciones de exacción
de tasas con el emisor de consultas 12. Esto se muestra en la
figura 5 como "Fase B". Esta fase comienza cuando el
transpondedor 14 alcanza una zona de tasas, lo cual se muestra en el
bloque 110. El proceso de consulta comenzará con una señal de
aproximación o de llamada, para llamar la atención del transpondedor
14 sobre la entrada en una zona de tasas. La señal puede contener
los detalles arriba mencionados acerca del punto de tasas. El
transpondedor 14 señaliza al emisor de consultas 12 con una señal de
disposición que está listo para la realización de una transacción.
El emisor de consultas envía a continuación una señal de consulta
(T), que contiene datos acerca de los contratos y procedimientos de
pago aceptados por el proveedor de servicios. Con su señal de
respuesta (R), el transpondedor 14 informa al emisor de consultas 12
como se ha descrito anteriormente, entre otras cosas, acerca de la
clase de vehículo, las condiciones especiales de pago, el medio de
pago que ha de ser usado, un ticket de entrada eventualmente
existente, el procedimiento de cifrado y el número aleatorio que ha
de ser usado para la autenticación del emisor de consultas 12.
En el bloque 112, el emisor de consultas 12
envía al transpondedor 14 una consulta de transacción (PD), que
contiene la tasa que ha de ser pagada, así como la fecha y la hora
del momento de la transacción, otro número aleatorio para la
autenticación del transpondedor 14, así como una información acerca
de la tarifa de la tasa. La consulta de transacción contiene
también un Message Authentication Code (MAC), que representa un
código de aseguramiento cifrado usando un procedimiento de cifrado
como, por ejemplo, el Data Encryption Standard (DES). Después de la
autenticación del emisor de consultas 12 mediante el transpondedor
14 y la reducción del importe disponible depositado en las memorias
80 ó 82 del transpondedor, el transpondedor 14 envía su resultado
del procesamiento junto con el certificado de la tarjeta inteligente
en una respuesta de transacción (P) al emisor de consultas 12. La
respuesta contiene como certificado de transpondedor también un
Message Authentication Code (MAC), que es generado por el
transpondedor 14 y comprobado por el emisor de consultas 12 para la
autenticación del transpondedor 14 y del proceso de pago.
El emisor de consultas 12 procesará a
continuación esta información y reenviará una confirmación de
transacción (CR) para finalizar la transacción, lo cual está
representado en el bloque 114. La confirmación de la transacción
contiene las informaciones arriba indicadas acerca del pago
realizado, del lugar y momento de pago, un número de recibo y un
autenticador (por ejemplo, MAC). Después de haberse descifrado con
éxito la confirmación de la transacción (CR), los datos del recibo
se depositan en las memorias 80 ó 82 del transpondedor de tal forma
que pueda realizarse tanto una información adicional para el usuario
como una comprobación del pago ante un punto de control. Los pasos
110 a 114 pueden repetirse mientras la cantidad de unidades de valor
existente en la memoria 80 ó 82 no queda por debajo de un valor
mínimo.
La "Fase C" se refiere a la retirada de la
tarjeta inteligente según el deseo del usuario, lo cual se indica
en el bloque 120. En este momento, se retransmite toda la cantidad
de dinero restante en el transpondedor 14, preferiblemente mediante
la interfaz 68 de la tarjeta inteligente 66. La retransmisión se
realiza preferiblemente de forma cifrada e incorporada en un
protocolo de autenticación, de modo que en particular una
retransmisión sólo es posible si previamente se ha realizado un
adeudo autentico y certificado por la tarjeta inteligente 66 en el
transpondedor 14. El importe existente en la tarjeta inteligente 66
se actualiza (véase el bloque 124). Como se muestra en el bloque
126, ahora puede retirarse la tarjeta inteligente 66 del
transpondedor 14.
Anteriormente se han descrito algunas pocas
formas de realización preferibles. No obstante, está claro que el
alcance de la invención comprende también formas de realización que
difieren de las anteriormente descritas, como puede verse en las
patentes.
Los dispositivos de visualización pueden ser,
por ejemplo, tubos de rayos catódicos u otros dispositivos de
barrido de líneas, pantallas de cristal líquido o pantallas de
plasma. El concepto "microordenador" se ha usado en algunos
contextos en el sentido de que un microordenador requiere una
memoria, mientras que un "microprocesador" no requiere esta
memoria. A pesar de ello, estos conceptos pueden considerarse
sinónimos en la presente descripción. Los conceptos
"controlador", "circuito de procesador" y "circuito de
control" incluyen ASICs (Application Specific Integrated
Circuits), bloques integrados programables con estructura lógica,
como PAL o PLA, decodificadores, bloques de memoria, procesadores
no basados en software, otros circuitos de conmutación, ordenadores
digitales incluidos microprocesadores y microordenadores de
cualquier arquitectura o combinaciones de los mismos. Los
dispositivos de memoria se refieren a SRAM (Static Random Access
Memory), DRAM (Dynamic Random Access Memory), RAM pseudoestática,
circuitos de intercepción, EEPROM
(Electronically-Erasable Programmable
Read-Only Memory), EPROM (Erasable Programmable
Read-Only Memory), registros u otros dispositivos de
memoria conocidos en el estado de la técnica. Esta relación no
pretende ser completa respecto a la invención.
La modulación por desplazamiento de frecuencia
(frequency shift keyed modulation, FSK) debe considerarse un
procedimiento de modulación de datos posible, pero también la
modulación impulso/pausa (pulse-pause modulation),
la modulación por desplazamiento de amplitud (amplitude shift
keying, ASK), la modulación de amplitud en cuadratura (QAM), la
modulación por desplazamiento de fase (phase shift keying, PSK), la
modulación por desplazamiento de fase en cuadratura (quadrature
phase shift keying, QPSK) o cualquier otro tipo de modulación.
También pueden aplicarse distintos procedimientos múltiplex, como
la modulación de tiempo o frecuencia para evitar influencias de
señales parásitas. Una modulación también puede conseguirse mediante
la modulación por reflexión (back-scatter
modulation), mediante la modulación activa de una frecuencia
portadora o mediante otros procedimientos.
Una implementación puede realizarse tanto en
componentes parciales discretos como en circuitos de conmutación
completamente integrados de silicio, arseniuro de galio u otras
familias de materiales electrónicos. No obstante, también se
considera el uso de formas de realización ópticas o basadas en otras
tecnologías. En cualquier caso debería estar claro que distintas
formas de realización de la invención pueden usar hardware, software
o firmware.
Aunque la invención se ha descrito en relación
con una forma de realización ilustrativa, esto no debe implicar
ninguna restricción. Para los expertos de este campo de la técnica
queda claro que la descripción a título de ejemplo se refiere
también a las modificaciones y combinaciones más diversas tanto de
las formas de realización descritas como de otras. Las
reivindicaciones expuestas a continuación deben incluirlas.
Claims (30)
1. Procedimiento para la tramitación automática
de procesos de pago sin efectivo, preferiblemente sin contacto, en
particular, para la exacción automática de tasas y similares, entre
un proveedor de prestaciones o servicios y un usuario de estas
prestaciones o de este servicio, que paga por ellos con un medio de
pago sin efectivo, en particular, electrónico, como por ejemplo una
tarjeta de crédito, una tarjeta de débito o un monedero electrónico,
usándose el procedimiento en relación con un sistema de pago
abierto, que además de medios de pago específicos según el
transporte permite el uso de medios de pago universales sin
efectivo, en el que el usuario recibe el medio de pago de un emisor,
en particular un banco o similares, y la autorización del pago se
realiza en forma de una declaración vinculante de la disposición al
pago, mientras que la recepción del pago se realiza en forma de la
aceptación de la declaración, pagando el emisor al proveedor de
prestaciones o servicios, en particular mediante una caja de
compensación, la tasa o similares compensando este pago con el
usuario, comprendiendo el procedimiento los siguientes
pasos:
pasos:
- -
- inserción del medio de pago en un dispositivo de pago,
- -
- puesta a disposición de datos por parte del usuario, que permiten al menos la identificación del medio de pago y de los datos individuales relevantes para el pago y la compensación de éste, como importe disponible o identificación de la cuenta, así como de datos que permiten al menos la identificación del pago que ha de ser realizado;
- -
- autorización del pago en forma de la declaración vinculante en el dispositivo de pago;
- -
- puesta a disposición de un dispositivo de detección del lado del usuario, que lleva el usuario consigo, que al usar el usuario la prestación o el servicio emite una señal correspondiente, en particular en forma de datos que representan el uso realizado, al dispositivo de pago;
- -
- recepción de la señal emitida por el dispositivo de detección y determinación automática del pago que ha de ser realizado, en particular la tasa, con ayuda de una tabla o un algoritmo en el dispositivo de pago; y
- -
- elaboración y depósito de un recibo según un pago que ha de ser realizado en el dispositivo de pago; realizándose la autorización del pago y el depósito del recibo mediante la evaluación de datos de compensación correspondientes en el dispositivo de pago y habiéndose elegido la estructura de datos de los datos de compensación de tal forma que se usa para el procesamiento posterior en las instalaciones del emisor y, dado el caso, de la caja de compensación.
2. Procedimiento según la reivindicación l,
tratándose del pago de una tasa de uso, en particular de un medio de
transporte, una carretera, un edificio y de forma especialmente
preferible de una tasa para el uso de una carretera por parte de un
vehículo.
3. Procedimiento según una de las
reivindicaciones l ó 2, caracterizado porque el pago es
realizado por el usuario en forma de un prepago o un postpago, por
ejemplo, mediante la indicación de una cuenta o similares.
4. Procedimiento según una de las
reivindicaciones l a 3, caracterizado porque la tabla o el
algoritmo está disponible en el dispositivo de pago del lado del
usuario, adeudándose el pago que ha de ser realizado o directamente
en el medio de pago o almacenándose el mismo hasta la siguiente
transmisión de datos a un punto de registro externo.
5. Procedimiento según la reivindicación 4,
caracterizado porque una transferencia de datos de la
transmisión de datos se realiza en una interfaz de comunicación sin
contacto, en particular por radio.
6. Procedimiento según la reivindicación 4,
caracterizado porque un pago se inicia mediante un Global
Navigation Satellite System (GNSS).
7. Procedimiento según la reivindicación 1, para
la creación de dispositivos en forma de aparatos o en forma de
dispositivos funcionales para la protección contra el acceso no
autorizado a informaciones, la modificación no autorizada de
informaciones, hardware y software, así como correlaciones del
sistema, el perjuicio no autorizado de la funcionalidad de sistemas
y componentes e intervenciones no autorizadas en la posibilidad de
comprobar transferencias de datos, procesos de pago.
8. Procedimiento según la reivindicación 7,
basándose las medidas para la protección contra ataques conscientes
y eventos no intencionados en el uso de mecanismos criptográficos
usándose, en particular, mecanismos criptográficos para la
autenticación de datos, procesos y componentes que participan en una
comunicación.
9. Procedimiento según una de las
reivindicaciones 7 u 8, caracterizado porque para la
protección contra ataques conscientes se usan mecanismos de
autenticación basados en números aleatorios, Message Authentication
Codes, firmas digitales y similares.
10. Procedimiento según una de las
reivindicaciones 7 a 9, que comprende procedimientos de seguridad
estandarizados (SAMs) distintos o idénticos en las instalaciones del
proveedor de servicios y del emisor del medio de pago.
11. Procedimiento según la reivindicación 10,
realizándose las transferencias de datos parcial o completamente de
forma cifrada y codificándose en particular los datos para la
detección de errores mediante medidas criptográficas.
12. Procedimiento según una de las
reivindicaciones precedentes, caracterizado porque la
transmisión de datos de compensación se realiza mediante radio o
similares, mediante una línea de comunicación o mediante la
transmisión de medios de almacenamiento.
13. Procedimiento según una de las
reivindicaciones precedentes, caracterizado porque la
transferencia de datos de los datos de compensación se realiza en
forma de mensajes, que constan de un elemento de datos en forma de
Message_Header y una Protocoll_Data_Unit, identificando el
Message_Header la versión válida del protocolo y comprendiendo la
Protocoll_Data_Unit datos que comprenden la clase de mensaje, el
tipo de mensaje, la identidad del emisor del mensaje, así como la
identidad del receptor del mensaje y la identidad del mensaje,
transfiriéndose a continuación una secuencia de objetos de datos que
comprende los datos relacionados con el pago propiamente dicho.
14. Procedimiento según la reivindicación 13,
caracterizado porque los elementos de datos en forma de
Message_Header, Message_Class y Message_Type están concebidos como
números de 1 byte, mientras que los objetos de datos en forma de
Sender_ID, Receiver_ID y Message_ID están concebidos como números de
4 bytes.
15. Procedimiento según una de las
reivindicaciones precedentes, caracterizado porque los datos
se transmiten en forma de objetos de datos (Data Objects), que
comprenden elementos de datos en forma de números de 4 bytes y
parámetros de seguridad, por ejemplo, como Message Authentication
Code (MAC) o como firmas digitales.
16. Procedimiento según la reivindicación 15,
caracterizado porque los objetos de datos contienen
adicionalmente elementos de datos en forma de informaciones de 20
bytes, que están formadas por números de 8 bytes y números de 2
bytes, así como un número hexadecimal de 8 bytes.
17. Procedimiento según una de las
reivindicaciones precedentes, caracterizado porque los
objetos de datos comprenden adicionalmente elementos de datos en
forma de números de 2 bytes.
18. Procedimiento según una de las
reivindicaciones precedentes, caracterizado porque los
objetos de datos comprenden elementos de datos en forma de
informaciones de 18 bytes, que están formados por un número de 8
bytes, un número de 2 bytes y un número hexadecimal de 8 bytes.
19. Procedimiento según una de las
reivindicaciones precedentes, caracterizado porque todo el
flujo de datos se realiza desde el proveedor, dado el caso a través
del punto del concentrador, la caja de compensación, hasta el emisor
en forma de mensajes de una estructura conforme usándose los objetos
de datos definidos en las reivindicaciones precedentes.
20. Procedimiento según una de las
reivindicaciones precedentes, caracterizado porque el
explotador del terminal de carga transmite al emisor del medio de
pago electrónico datos para la supervisión de la seguridad del
sistema en forma de objetos de datos realizados de tal forma que su
estructura corresponda a los objetos de datos que se intercambian en
la interfaz de comunicación entre el dispositivo de pago y el
dispositivo de exacción.
21. Sistema para la tramitación automática de
procesos de pago sin efectivo, preferiblemente sin contacto, en
particular, para la exacción automática de tasas y similares, entre
un proveedor de prestaciones o servicios y un usuario de esta
prestación o de este servicio, que paga por ellos con un medio de
pago sin efectivo, en particular, electrónico, como por ejemplo una
tarjeta de crédito, una tarjeta de débito o un monedero electrónico,
usándose el sistema en relación con un sistema de pago abierto, que
además de medios de pago específicos según el transporte permite el
uso de medios de pago universales sin efectivo, en el que el usuario
recibe el medio de pago de un emisor, en particular un banco o
similares, y la autorización del pago se realiza en forma de una
declaración vinculante de la disposición al pago, mientras que la
recepción del pago se realiza en forma de la aceptación de la
declaración, pagando el emisor al proveedor de prestaciones o
servicios, en particular mediante una caja de compensación, la tasa
o similares compensando este pago con el usuario, comprendiendo el
sistema lo
siguiente:
siguiente:
- -
- un dispositivo de pago que el usuario lleva consigo para la puesta a disposición de datos por el usuario mediante la introducción del medio de pago en el dispositivo de pago, permitiendo los datos al menos la identificación del medio de pago y de los datos individuales relevantes para el pago y la compensación de éste, como importe disponible o identificación de la cuenta;
- -
- puesta a disposición de un dispositivo de detección del lado del usuario que lleva el usuario consigo, que al usar el usuario la prestación o el servicio emite una señal correspondiente, en particular en forma de datos que representan el uso realizado al dispositivo de pago;
- -
- estando realizado el dispositivo de pago para la recepción de la señal emitida por el dispositivo de detección y para la determinación automática del pago que ha de ser realizado, en particular la tasa, con ayuda de una tabla o un algoritmo estando realizado el dispositivo de pago para la autorización del pago en forma de la declaración vinculante;
- -
- estando realizado el dispositivo de pago para la elaboración y el depósito de un recibo según un pago que ha de ser realizado; y
- -
- estando realizado el dispositivo de pago para la autorización del pago y el depósito del recibo mediante la evaluación de datos de compensación correspondientes; habiéndose elegido la estructura de datos de tal forma que puedan usarse para el procesamiento posterior en las instalaciones del emisor y, dado el caso, de la caja de compensación.
22. Sistema según la reivindicación 2l,
comprendiendo un módulo electrónico (20) y una antena direccional
(18).
23. Sistema según la reivindicación 22,
caracterizado porque el módulo electrónico (20) comprende un
transmisor (52), una interfaz (56) para un ordenador central y un
receptor (54).
24. Sistema según una de las reivindicaciones 2l
a 23, comprendiendo un transpondedor (14), que presenta una interfaz
(68) para tarjetas IC.
25. Sistema según la reivindicación 24,
caracterizado porque la tarjeta IC es una tarjeta inteligente
(66).
26. Sistema según la reivindicación 25,
caracterizado porque la tarjeta inteligente (66) comunica
mediante una interfaz (68) y un microcontrolador (78) con la memoria
intermedia (80, 82).
27. Sistema según una de las reivindicaciones 24
a 26, caracterizado porque el transpondedor (14) presenta un
dispositivo de cifrado/descifrado (84).
28. Sistema según una de las reivindicaciones 24
a 27, caracterizado porque el transpondedor (14) presenta una
interfaz del usuario (72) con pantalla de cristal líquido (74) y un
teclado (76).
29. Sistema según una de las reivindicaciones 21
a 28, comprendiendo una memoria intermedia, que consta de una RAM
(80) y una EEPROM (82).
30. Sistema según una de las reivindicaciones 26
a 29, comprendiendo un microcontrolador (78), que está conectado con
un ASIC analógico (32), un ASIC digital (34) y una antena (30,
31).
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| WOPCT/EP95/05019 | 1995-12-19 | ||
| EP9505019 | 1995-12-19 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2286822T3 true ES2286822T3 (es) | 2007-12-01 |
Family
ID=8166142
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES96118760T Expired - Lifetime ES2286822T3 (es) | 1995-12-19 | 1996-11-22 | Procedimiento y dispositivos para el uso y la compensacion de medios de pago electronico en un sistema abierto e interoperable para la exaccion automatica de tasas. |
Country Status (7)
| Country | Link |
|---|---|
| EP (1) | EP0780801B1 (es) |
| AT (1) | ATE360865T1 (es) |
| AU (1) | AU1432697A (es) |
| DE (1) | DE59611427D1 (es) |
| ES (1) | ES2286822T3 (es) |
| PT (1) | PT780801E (es) |
| WO (1) | WO1997022953A1 (es) |
Families Citing this family (34)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6003014A (en) * | 1997-08-22 | 1999-12-14 | Visa International Service Association | Method and apparatus for acquiring access using a smart card |
| AT412033B (de) | 2000-02-08 | 2004-08-26 | Efkon Entwicklung Forschung & Konstruktion Von Sondermaschinen Gmbh | System zum automatischen verrechnen von gebühren |
| DE10007518B4 (de) * | 2000-02-18 | 2011-11-17 | T-Mobile Deutschland Gmbh | Verfahren und Anordnung zur Durchführung von bargeldlosem Zahlungsverkehr |
| KR101015341B1 (ko) * | 2000-04-24 | 2011-02-16 | 비자 인터내셔날 써비스 어쏘시에이션 | 온라인 지불인 인증 서비스 |
| DE10033318A1 (de) * | 2000-06-29 | 2002-01-17 | Mannesmann Ag | Einrichtung und Verfahren zum Erheben von Nutzungsgebühren |
| AT5229U1 (de) * | 2000-09-01 | 2002-04-25 | Moritzer Michael Mag | Verfahren zur drahtlosen erfassung, abrechnung und kontrolle von parkvorgängen |
| DE10046166A1 (de) * | 2000-09-19 | 2002-03-28 | Mannesmann Vdo Ag | Mehrteilige Vorrichtung zur Abrechnung von Entgelt für die Benutzung mautpflichtiger Verkehrswege |
| CN1248169C (zh) * | 2000-09-29 | 2006-03-29 | 爱信精机株式会社 | 车辆用自动收费装置的监视系统 |
| DE20100964U1 (de) * | 2001-01-18 | 2002-02-28 | Ryl, Peter, 87600 Kaufbeuren | System zur Identifikation, insbesondere zur bargeldlosen Bezahlung bzw. Abrechnung |
| DE10113499A1 (de) * | 2001-03-20 | 2002-09-26 | Alexander Wussler | Vorrichtung und Verfahren zum automatischen Management von merkmals- und zeitbezogenen Daten |
| DE10205162A1 (de) * | 2002-02-07 | 2003-08-28 | Daimler Chrysler Ag | Einrichtung zur Ermittlung von Nutzungsgebühren |
| DE10302449A1 (de) * | 2003-01-22 | 2004-08-12 | Francotyp-Postalia Ag & Co. Kg | Anordnung zum Erfassen und gesicherten Speichern von Erfassungswerten |
| WO2004066219A1 (de) * | 2003-01-22 | 2004-08-05 | Francotyp-Postalia Ag & Co. Kg | Verfahren und anordnung zur mobilen datenübertragung |
| JP2005031711A (ja) * | 2003-05-12 | 2005-02-03 | Omron Corp | 車載端末装置、車載端末制御プログラム、車載端末制御プログラムを記録した記録媒体、車載端末装置の通信決済方法、決済管理システム、決済管理プログラム、決済管理プログラムを記録した記録媒体、決済管理方法、料金収受システム、料金収受プログラム、料金収受プログラムを記録した記録媒体、および料金収受方法 |
| KR100605100B1 (ko) * | 2003-11-05 | 2006-07-26 | 삼성전자주식회사 | 데이터 전송 속도가 향상된 아이씨 카드, 아이씨 카드프로세서 및 아이씨 카드 시스템 |
| CA2566237C (en) | 2004-05-10 | 2015-11-03 | Rent A Toll, Ltd. | Toll fee system and method |
| DE102004037447A1 (de) | 2004-05-14 | 2005-12-08 | Daimlerchrysler Ag | Kommunikationssystem zur Erfassung von Mautgebühren |
| WO2006014125A1 (en) * | 2004-08-03 | 2006-02-09 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for tele-toll payment |
| US7831520B2 (en) | 2005-06-28 | 2010-11-09 | Ebay Inc. | Mobile device communication system |
| US8768753B2 (en) | 2005-09-07 | 2014-07-01 | Rent A Toll, Ltd. | System, method and computer readable medium for billing tolls |
| US20070124199A1 (en) | 2005-10-13 | 2007-05-31 | Rent-A-Toll, Ltd. | System, method and computer readable medium for toll service activation and billing |
| US8768754B2 (en) | 2006-01-09 | 2014-07-01 | Rent-A-Toll, Ltd. | Billing a rented third party transport including an on-board unit |
| WO2007081833A2 (en) | 2006-01-09 | 2007-07-19 | Rent A Toll, Ltd. | Billing a rented third party transport including an on-board unit |
| DE102006027200A1 (de) * | 2006-06-12 | 2007-12-27 | Giesecke & Devrient Gmbh | Datenträger und Verfahren zur kontaktlosen Kommunikation zwischen dem Datenträger und einem Lesegerät |
| DE102008003667A1 (de) * | 2008-01-09 | 2009-07-16 | Robert Bosch Gmbh | Mauterfassungsgerät für ein Kraftfahrzeug und Verfahren zum Betreiben eines Mauterfassungsgerätes |
| AT507031B1 (de) * | 2008-06-05 | 2011-07-15 | Efkon Mobility Gmbh | Verfahren und vorrichtung zum einheben von maut |
| WO2010042923A1 (en) | 2008-10-10 | 2010-04-15 | Rent A Toll, Ltd. | Method and system for processing vehicular violations |
| DE102010011645A1 (de) | 2010-03-16 | 2011-09-22 | Francotyp-Postalia Gmbh | Anordnung und Verfahren zur Datenverarbeitung in einem Fahrzeug |
| DE102016209380A1 (de) | 2016-05-31 | 2017-11-30 | Bayerische Motoren Werke Aktiengesellschaft | Verfahren und system zum automatischen durchführen von zahlungsvorgängen in einem fahrzeug |
| CN113435617B (zh) * | 2016-09-08 | 2024-10-15 | 北京嘀嘀无限科技发展有限公司 | 一种用车订单的代付处理方法、服务器和乘客终端 |
| CN108376427A (zh) * | 2018-01-15 | 2018-08-07 | 广安众道电子商务有限公司 | 一种智能停车收费方法 |
| DE102019115082B3 (de) | 2019-06-05 | 2020-12-03 | Emonvia GmbH | Zählertechnik für Messzähler mit unterschiedlichen Nutzergruppen |
| CN111275838B (zh) * | 2020-02-14 | 2022-06-17 | 北京万集科技股份有限公司 | 目标账户的绑定方法及装置、存储介质、电子装置 |
| US11615381B2 (en) | 2020-03-12 | 2023-03-28 | Toyota Motor North America, Inc. | Geo-fence responsibility creation and management |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4303904A (en) * | 1979-10-12 | 1981-12-01 | Chasek Norman E | Universally applicable, in-motion and automatic toll paying system using microwaves |
| US4578530A (en) * | 1981-06-26 | 1986-03-25 | Visa U.S.A., Inc. | End-to-end encryption system and method of operation |
| GB2153573B (en) * | 1984-01-25 | 1987-04-01 | Schlumberger Electronics | A prepayment system |
| BE1003237A5 (fr) * | 1989-06-02 | 1992-02-04 | Baets Thierry De | Systeme de taxation ou peage automatique pour vehicules routiers. |
| AU7901691A (en) * | 1990-05-17 | 1991-12-10 | John M Harrison | Electronic vehicle toll collection system and method |
| BR9205419A (pt) * | 1991-10-31 | 1994-04-19 | Kwang Sil Lee | Sistema de identificacao eletronica tendo capacidade de resposta remota automatica e processo de controle de identificacao automatica para o mesmo |
| US5557518A (en) * | 1994-04-28 | 1996-09-17 | Citibank, N.A. | Trusted agents for open electronic commerce |
| DE9214769U1 (de) * | 1991-11-15 | 1993-04-01 | MOBA - Electronic Gesellschaft für Mobil-Automation mbH, 65604 Elz | Ultraschallsensor-Regeleinrichtung für einen Straßenfertiger |
| EP1249712B1 (en) | 1992-06-25 | 2006-11-22 | Denso Corporation | Mobile object identification system |
| US5310999A (en) * | 1992-07-02 | 1994-05-10 | At&T Bell Laboratories | Secure toll collection system for moving vehicles |
| DE69419189T2 (de) | 1993-02-19 | 1999-10-28 | Mitsubishi Jukogyo K.K., Tokio/Tokyo | Elektronisches Mautgebührenempfangssystem |
| GB9311387D0 (en) | 1993-06-02 | 1993-07-21 | Cutts David J | Systems for pricing road usage |
| US5485520A (en) | 1993-10-07 | 1996-01-16 | Amtech Corporation | Automatic real-time highway toll collection from moving vehicles |
| US5450087A (en) | 1994-04-06 | 1995-09-12 | Texas Instruments Incorporated | Transponder maintenance mode method |
-
1996
- 1996-11-22 AU AU14326/97A patent/AU1432697A/en not_active Abandoned
- 1996-11-22 EP EP96118760A patent/EP0780801B1/de not_active Expired - Lifetime
- 1996-11-22 DE DE59611427T patent/DE59611427D1/de not_active Expired - Fee Related
- 1996-11-22 ES ES96118760T patent/ES2286822T3/es not_active Expired - Lifetime
- 1996-11-22 PT PT96118760T patent/PT780801E/pt unknown
- 1996-11-22 WO PCT/EP1996/005158 patent/WO1997022953A1/de active Search and Examination
- 1996-11-22 AT AT96118760T patent/ATE360865T1/de active
Also Published As
| Publication number | Publication date |
|---|---|
| DE59611427D1 (de) | 2007-06-06 |
| EP0780801A1 (de) | 1997-06-25 |
| PT780801E (pt) | 2007-08-03 |
| WO1997022953A1 (de) | 1997-06-26 |
| AU1432697A (en) | 1997-07-14 |
| ATE360865T1 (de) | 2007-05-15 |
| EP0780801B1 (de) | 2007-04-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2286822T3 (es) | Procedimiento y dispositivos para el uso y la compensacion de medios de pago electronico en un sistema abierto e interoperable para la exaccion automatica de tasas. | |
| ES2218832T3 (es) | Procedimiento de transaccion con un aparato movil. | |
| US9213977B2 (en) | Authentication of a data card using a transit verification value | |
| KR100366060B1 (ko) | 광지불송수신장치 및 이를 이용한 광결제시스템 | |
| AU2007345585B2 (en) | Signature based negative list for off line payment device validation | |
| RU2427915C2 (ru) | Аппаратура и способ осуществления платежа, интегрированного с доставкой электронных товаров | |
| US8025223B2 (en) | System and method for mass transit merchant payment | |
| US7527208B2 (en) | Bank issued contactless payment card used in transit fare collection | |
| JP2837612B2 (ja) | 自動料金収集方法及びそのシステム | |
| US20080203170A1 (en) | Fraud prevention for transit fare collection | |
| JPH09500998A (ja) | 走行車両からの自動的実時間高速道路料金収受 | |
| EP2430600A1 (en) | Apparatus and method for integrated payment and electronic merchandise transfer | |
| JP2000306032A (ja) | 携帯電話を利用した電子通貨と電子的財布。 | |
| BR102020026324A2 (pt) | Sistema de cobrança de tarifa de transporte coletivo |