ES2401409T3 - Procedimiento para generar transacciones de peaje - Google Patents

Abstract

Procedimiento para generar transacciones de peaje a partir de las grabaciones de ubicación de unaparato de vehículo que tiene una identificación única en un sistema de peaje viario, y que a bordo de un vehículograba continuamente su ubicación, con los siguientes pasos: leer (5) las grabaciones de ubicación (pi) y la identificación (OID) del aparato de vehículo (1) en un terminal deusuario (4) separado físicamente de éste durante la grabación de ubicación mencionada, siendo la identificaciónmencionada (OID) una identificación de aparato de vehículo o una identificación asignada al usuario, en particularuna identificación de cuenta de usuario; enviar (6) las grabaciones de ubicación (pi) con una identificación de emisor (RID), distinta a la identificación (OID),del terminal de usuario (4) a un servidor de cálculo de peaje (7) que a partir de esto calcula los datos de peaje (RES)anonimizados respecto a la ubicación, siendo la identificación de emisor (RID) un valor aleatorio, un códigoseleccionable por el usuario o una dirección de Internet temporal del terminal de usuario; recibir (8) los datos de peaje (RES) calculados y anonimizados respecto a la ubicación con la identificación deemisor (RID) en el terminal de usuario (4); y transmitir (10) los datos de peaje (RES), anonimizados respecto a la ubicación, y la identificación (OID) comotransacción de peaje (9) a una central (2) del sistema de peaje viario.

Description

Procedimiento para generar transacciones de peaje.

La presente invención se refiere a un procedimiento para generar transacciones de peaje a partir de las grabaciones de ubicación de un aparato de vehículo, que graba la ubicación, con una identificación única en un sistema de peaje viario.

Los aparatos de vehículo para sistemas de peaje viario se identifican también como "onboard units" u OBUs (unidades de a bordo). En la actualidad existen dos realizaciones distintas de OBUs que pueden determinar y grabar automáticamente su posición, por ejemplo, mediante un receptor de navegación por satélite: Los llamados OBUs "thick client" (cliente pesado) calculan datos de peaje anonimizados respecto a la ubicación sobre la base de mapas de peaje almacenados a partir de sus grabaciones de ubicación y los envían a una central del sistema de peaje viario, por ejemplo, a través de una red de móvil de comunicaciones, lo que requiere una distribución costosa de los mapas de peaje a los OBUs y una alta capacidad de cálculo en los OBUs. A diferencia de esto, los llamados OBUs "thin client" (cliente liviano) no evalúan automáticamente sus grabaciones de ubicación, sino que las envían en estado "bruto" a la central que lleva a cabo el cotejo de mapas de peaje ("map matching") para generar datos de peaje a partir de esto. Por tanto, los OBUs "thin client" tienen una construcción esencialmente más simple y económica, pero son problemáticos desde el punto de vista de la protección de datos, porque la central del sistema de peaje viario conoce todas las grabaciones de ubicación ("perfil de movimiento") de un OBU, incluyendo su permanencia en lugares no sujetos a peaje.

Por consiguiente, el documento WO2008/000227 ya propuso enviar las grabaciones de ubicación de un OBU "thin client" con una identificación de emisor anonimizada a un servidor de cálculo de peaje especial que ejecuta el "map matching" y reenvía al OBU los datos de peaje anonimizados respecto a la ubicación que el OBU transmite a continuación a la central. Debido a la transmisión de las grabaciones de ubicación, no transparente para el usuario, a un servidor de cálculo de peaje del operador del sistema, este sistema sigue siendo inadecuado para disipar completamente las dudas referentes a la protección de datos. Además, esta solución genera un tráfico de datos adicional en el sistema de peaje viario.

El documento WO2009/001303A1 muestra un sistema de cálculo de peaje con una unidad de a bordo, un servidor de cálculo de peaje que por medio de los datos, codificados por la unidad de a bordo y provistos de una identificación aleatoria, que representan los tramos recorridos que están sujetos a peaje, calcula el precio de un viaje correspondiente y lo envía a un servidor de Internet para la lectura.

La invención tiene el objetivo de eliminar las desventajas del estado de la técnica y crear especialmente un procedimiento para generar transacciones de peaje para OBUs "thin client", que garantice una protección de datos o una confidencialidad mejorada para el usuario. Este objetivo se consigue mediante un procedimiento con las características de la reivindicación 1.

La invención se basa en un concepto novedoso de map matching para OBUs "thin client", que proporciona al usuario una transparencia y una protección de datos completa. Al usar un terminal de usuario que está bajo su propio control, el usuario tiene pleno control sobre la anonimización de sus grabaciones de ubicación. Mediante la lectura de las grabaciones de ubicación en el terminal de usuario y la sustitución de su identificación por una identificación de emisor, distinta a ésta, en el terminal, estos pasos resultan transparentes y lógicos para el usuario. Esto permite disipar completamente cualquier duda referente a un seguimiento o una elaboración central de un perfil de movimiento del OBU. Además, el procedimiento según la invención no necesita una cantidad de datos elevada en el sistema de peaje viario.

La lectura mencionada se lleva a cabo preferentemente mediante la conexión física del aparato de vehículo o al menos de su memoria de grabación de ubicación al terminal de usuario, lo que aumenta una vez más la transparencia para el usuario.

La lectura mencionada se puede llevar a cabo alternativamente mediante el envío codificado de las grabaciones de ubicación desde el aparato de vehículo hasta la central y la descarga de las grabaciones de ubicación codificadas desde la central hasta el terminal de usuario, pudiendo seleccionar el usuario el código usado.

Es especialmente ventajoso que las grabaciones de ubicación estén subdivididas en paquetes de datos individuales que tienen en cada caso un header (cabecera) que indica la cantidad y/o un valor hash de las grabaciones de ubicación contenidas en el paquete de datos, lo que facilita las comprobaciones de consistencia en la central.

A tal efecto, las cabeceras se pueden enviar preferentemente también de manera directa del aparato de vehículo a la central junto con la identificación, lo que permite aquí cotejar los datos de peaje recibidos del terminal de usuario. El envío mencionado de las cabeceras con las identificaciones desde el aparato de vehículo hasta la central se lleva a cabo preferentemente mediante una red móvil de comunicaciones. De este modo se pueden usar, por ejemplo, OBUs "thin client" convencionales que están equipados con un transceptor móvil de comunicaciones.

En otra realización preferida de la invención, las cabeceras de los paquetes de datos, que sirven de base a éstas, se incorporan a los datos de peaje y se comparan en la central con las cabeceras recibidas de un aparato de vehículo con la misma identificación. De este modo se puede crear un sistema de control cerrado para cotejar los datos de peaje generados por el usuario mediante su terminal de usuario, sin afectar la protección de datos ni la transparencia del procedimiento para el usuario.

Las cabeceras indican preferentemente también en cada caso el período de grabación de las grabaciones de ubicación contenidas en el paquete de datos, lo que posibilita otras comprobaciones de plausibilidad en la central.

Según otra realización ventajosa de la invención, cada paquete de datos se provee de una identificación de paquete única entre todos los paquetes de datos de un mismo aparato de vehículo y preferentemente continua, lo que permite, por ejemplo, comprobar el orden y la integridad de los paquetes de datos.

En cualquier caso es especialmente favorable que las grabaciones de ubicación y preferentemente las cabeceras existentes opcionalmente sean codificadas por el aparato de vehículo con un código igual para varios aparatos de vehículo a fin de generar una firma de aparato y que en el servidor de cálculo de peaje se compruebe la autenticidad de la firma de aparato. Del mismo modo, los datos de peaje y preferentemente las cabeceras existentes opcionalmente pueden estar firmadas por el servidor de cálculo de peaje con una firma de servidor única, lo que permite comprobar preferentemente también la autenticidad de la firma de servidor en la central.

La identificación leída desde el aparato de vehículo puede ser tanto una identificación del propio vehículo como una identificación asignada al usuario, por ejemplo, una identificación de una cuenta de usuario para cobrar las tasas de peaje en el sistema de peaje viario.

La identificación de emisor usada para enviar las grabaciones de ubicación del terminal de ubicación al servidor de cálculo de peaje puede ser en el caso más simple una dirección de Internet temporal del ordenador del usuario. Sin embargo, ésta es preferentemente un valor aleatorio o un código seleccionable por el usuario, lo que aumenta aún más la transparencia para el usuario.

El procedimiento de la invención es adecuado para todos los tipos de aparatos de vehículo autolocalizadores, con independencia del modo en que determinan su ubicación, por ejemplo, mediante el reconocimiento de marcas terrestres o la identificación de balizas, por las que se guía el aparato de vehículo. Es especialmente ventajoso que el aparato de vehículo determine de forma conocida sus ubicaciones mediante navegación por satélite, pudiéndose usar para esto, por ejemplo, los OBUs "thin client" asistidos por GPS.

La invención se explica detalladamente a continuación por medio de un ejemplo de realización, representado en el dibujo adjunto, cuya única figura 1 muestra un diagrama de bloques de un sistema de peaje viario que funciona según el procedimiento de la invención.

Según la figura 1, un OBU 1 se mueve a bordo de un vehículo en el marco de un sistema de peaje viario con una central 2. La central 2 cobra el uso local del OBU 1 que está sujeto a peaje, por ejemplo, la circulación por una carretera de peaje, la entrada en una zona de pago, la permanencia en un aparcamiento sujeto al pago de tasas, etc., mediante cuentas de usuario correspondientes, y específicamente sobre la base de datos de peaje (transacciones de peaje) que se generan por el uso local del OBU 1, como es conocido en la técnica.

El OBU 1 es del tipo "thin client" autolocalizador y determina de forma continua, por ejemplo, periódica, su ubicación, por ejemplo, con ayuda de un receptor de navegación por satélite, y graba las ubicaciones determinadas de este modo ("position fixes", posición establecida) p1, p2, p3, ... en una memoria interna de grabación de ubicación.

Las grabaciones de ubicación pi (i = 1, 2, 3...) del OBU 1 se dividen en paquetes de datos individuales 3 para una manipulación más fácil. Cada paquete de datos 3 se compone de una identificación de paquete Pi (por ejemplo, una enumeración continua), de una cabecera H1, de las grabaciones de ubicación pi reunidas en el paquete y de una identificación única OID del OBU 1 y/o de su usuario. La cabecera Hi puede contener adicionalmente metadatos, como la cantidad de grabaciones de ubicación pi contenidas en el paquete de datos 3 o una suma de control o un valor hash de éstas, es decir, una representación de las mismas. La cabecera Hi puede contener adicionalmente también metadatos para plausibilizar las grabaciones de ubicación pi, como el período de grabación y/o un recorrido adicionado a partir de las grabaciones de ubicación pi.

Las grabaciones de ubicación pi y opcionalmente también la cabecera Hi, la identificación de paquete Pi y/o la identificación OID se pueden codificar con una firma de aparato So del OBU 1, como indica la parte sombreada en la figura 1. El código usado para generar la respectiva firma de aparato So no es específica de un OBU individual 1, sino común para todos o todos los OBUs 1 de un grupo, de manera que sólo a partir de la firma de aparato So no se podría deducir la identidad del OBU 1 o de su usuario; la firma de aparato So confirma únicamente que un paquete de datos 3 procede de un OBU 1 "auténtico", es decir, autentificado con una firma de aparato So en el sistema de peaje viario.

En un primer paso del procedimiento, las grabaciones de ubicación pi o los paquetes de datos 3 con las grabaciones de ubicación pi se leen en un servidor de usuario 4 (flecha 5). Esto se puede llevar a cabo, por ejemplo, semanalmente, mensualmente, a solicitud o cuando la memoria de grabación de ubicación del OBU 1 esté llena. La lectura 5 se lleva a cabo preferentemente mediante la conexión física del OBU 1 al terminal de usuario 4, por ejemplo, mediante una interfaz alámbrica, como una interfaz USB o una conexión de datos inalámbrica, como Bluetooth, WLAN (red de área local inalámbrica) o una red móvil de comunicaciones. La memoria de grabación de ubicación interna del OBU 1, por ejemplo, un chip de memoria, se podría extraer alternativamente del OBU 1 e insertar en el terminal de usuario 4 o conectar a éste.

Otra posibilidad de la lectura 5 consiste en enviar las grabaciones de ubicación pi, por ejemplo, a través de la trayectoria de datos 11 explicada más adelante, en una forma codificada por el usuario desde el aparato de vehículo 1 hasta la central 2 y desde aquí descargarlas posteriormente en el terminal de usuario 4, en el que son descodificadas de nuevo por el usuario con el código que ha seleccionado.

Si se desea, el usuario puede ver y comprobar las grabaciones de ubicación pi con un software correspondiente en el terminal de usuario 4.

En un próximo paso 6, las grabaciones de ubicación pi se envían del terminal de usuario 4 a un servidor de cálculo de peaje 7 vía Internet. Sin embargo, antes de este envío se sustituye en el terminal de usuario 4 la identificación OID por una identificación de emisor RID "anónima" y distinta a ésta. La identificación de emisor RID es, por ejemplo, un código seleccionado libremente por el usuario o un valor generado de manera aleatoria por el terminal de usuario 4. Como identificación de emisor RID se podría usar alternativamente una dirección de Internet temporal del terminal de usuario 4, aunque con un carácter anónimo correspondientemente reducido.

Por consiguiente, los paquetes de datos 3' enviados al servidor de cálculo de peaje 7 se componen en cada caso de la identificación de paquete Pi, la cabecera Hi, las grabaciones de ubicación pi y la identificación de emisor anónima RID.

El servidor de cálculo de peaje 7 es un proxy "map matching" conocido que asigna las grabaciones de ubicación pi contenidas en los paquetes de datos 3' a lugares, regiones o tramos, sujetos a peaje, a partir de una base de datos de mapas de peaje y determina las tasas de peaje correspondientes a partir de la base de datos de mapas de peaje. Sobre la base de las tasas de peaje de todas las grabaciones de ubicación pi recibidas respecto a una identificación de emisor RID, el servidor de cálculo de peaje 7 calcula los datos de peaje RES "anonimizados así respecto a la ubicación" que ya no permiten sacar conclusiones de las grabaciones de ubicación individuales pi. Los datos de peaje RES son, por ejemplo, una única suma de tasas para todas las grabaciones de ubicación pi de todos los paquetes de datos 3' de una identificación de emisor RID.

El servidor de cálculo de peaje 7 está diseñado preferentemente de manera que sólo acepta paquetes de datos 3' de OBUs 1 "auténticos", es decir, autentificados mediante su firma de aparato So, y los procesa para obtener datos de peaje RES.

Por medio de la identificación de emisor RID, el servidor de cálculo de peaje 7 puede descartar también, por ejemplo, duplicados de paquetes de datos 3'. Así, por ejemplo, en el servidor de cálculo de peaje 7 se puede comprobar si hay duplicados de la identificación de emisor RID y en caso de existir un duplicado puede solicitar una nueva identificación de emisor RID al terminal de usuario 4.

Los datos de peaje RES se reenvían a continuación al terminal de usuario 4 identificado mediante la dirección de emisor RID (flecha 8). Los datos de peaje reenviados RES se pueden completar adicionalmente con las cabeceras Hi de aquellos paquetes de datos 3' que sirvieron de base a éstas y que, por ejemplo, están firmados aún con la firma de aparato So. De manera adicional se puede añadir una cabecera de datos de peaje propia HM que indica la cantidad y/o un valor hash de todas la cabeceras Hi transmitidas a la vez.

Los datos de peaje RES y preferentemente también las cabeceras Hi y HM añadidas opcionalmente se pueden firmar además con una firma de servidor SM del servidor de cálculo de peaje 7 para demostrar su procedencia de un servidor de cálculo de peaje 7 "auténtico", es decir, autentificado con una firma de servidor SM en el sistema de peaje viario.

Si se desea, el usuario puede repasar también los datos de peaje recibidos en su terminal de usuario 4 para comprobar el resultado del servidor de cálculo de peaje 7.

En el próximo paso, los datos de peaje RES recibidos del servidor de cálculo de peaje 7 se vuelven a proveer de la identificación OID en el ordenador de usuario 4 y se transmiten así, preferentemente junto con las cabeceras Hi, HM, como transacción de peaje 9 a la central 2 (flecha 10). Por medio de la firma de servidor SM de los datos de peaje RES se puede comprobar en la central 2 la transacción de peaje 9 respecto al cálculo de sus tasas por parte de un servidor de cálculo de peaje 7 "auténtico".

La transacción de peaje 9 se puede transmitir del terminal de usuario 4 a la central 2 de cualquier manera, por ejemplo, vía Internet, mediante una red móvil de comunicaciones o también simplemente mediante el envío físico de un soporte de datos.

En la central 2 se pueden cotejar opcionalmente los datos de peaje RES con ayuda de una trayectoria de datos directa 11 desde el OBU 1 hasta la central 2. En la trayectoria de datos 11, el OBU 1 envía a la central 2, por ejemplo, periódicamente, a solicitud o cuando su memoria de grabación de ubicación está llena, las cabeceras Hi de los paquetes de datos 3 junto con su identificación OID u opcionalmente las identificaciones de paquete Pi en paquetes de prueba 12. De este modo, las cabeceras Hi de una transacción de peaje 9, que se han recibido respecto a una identificación OID desde el terminal de usuario 4, se pueden comparar en la central 2 con las cabeceras Hi recibidas directamente del OBU 1 a partir de los paquetes de prueba 12 a fin de detectar inconsistencias o la ausencia de paquetes de datos que pudieran indicar un mal funcionamiento del sistema o una infracción de peaje.

La trayectoria de datos 11 se crea preferentemente mediante una red de móvil de comunicaciones, a través de la que la propia central 2 puede seleccionar también un OBU 1 y solicitarle el envío de paquetes de prueba 12. La trayectoria de datos 11 se puede implementar alternativamente también de otra manera, por ejemplo, con ayuda de estaciones de emisión y recepción descentralizadas de la central 2, por ejemplo, según el estándar DSRC (dedicated short range communication, comunicación dedicada de corte alcance), WLAN (wireless local area network, red de área local inalámbrica) o WAVE (wireless access in a vehicle environment, conexión inalámbrica en un entorno vehicular).

La invención no está limitada a las realizaciones representadas, sino que comprende todas las variantes y modificaciones que entran en el marco de las reivindicaciones adjuntas.

Claims (15)

1. REIVINDICACIONES

   1.

   Procedimiento para generar transacciones de peaje a partir de las grabaciones de ubicación de un aparato de vehículo que tiene una identificación única en un sistema de peaje viario, y que a bordo de un vehículo graba continuamente su ubicación, con los siguientes pasos:

   leer (5) las grabaciones de ubicación (pi) y la identificación (OID) del aparato de vehículo (1) en un terminal de usuario (4) separado físicamente de éste durante la grabación de ubicación mencionada, siendo la identificación mencionada (OID) una identificación de aparato de vehículo o una identificación asignada al usuario, en particular una identificación de cuenta de usuario; enviar (6) las grabaciones de ubicación (pi) con una identificación de emisor (RID), distinta a la identificación (OID), del terminal de usuario (4) a un servidor de cálculo de peaje (7) que a partir de esto calcula los datos de peaje (RES) anonimizados respecto a la ubicación, siendo la identificación de emisor (RID) un valor aleatorio, un código seleccionable por el usuario o una dirección de Internet temporal del terminal de usuario; recibir (8) los datos de peaje (RES) calculados y anonimizados respecto a la ubicación con la identificación de emisor (RID) en el terminal de usuario (4); y transmitir (10) los datos de peaje (RES), anonimizados respecto a la ubicación, y la identificación (OID) como transacción de peaje (9) a una central (2) del sistema de peaje viario.

2. 2.

   Procedimiento según la reivindicación 1, caracterizado porque la lectura mencionada (5) se lleva a cabo mediante la conexión física del aparato de vehículo (1) o al menos de su memoria de grabación de ubicación al terminal de usuario (4).

3. 3.

   Procedimiento según la reivindicación 1, caracterizado porque la lectura mencionada (5) se lleva a cabo mediante el envío codificado de las grabaciones de ubicación (pi) desde el aparato de vehículo (1) hasta la central (2) y la descarga de las grabaciones de ubicación codificadas (pi) desde la central (2) hasta el terminal de usuario (4), pudiendo seleccionar el usuario el código usado.

4. 4.

   Procedimiento según una de las reivindicaciones 1 a 3, caracterizado porque las grabaciones de ubicación (pi) están subdivididas en paquetes de datos individuales (3) que tienen en cada caso una cabecera (Hi) que contiene metadatos, preferentemente la cantidad y/o una suma de control y/o un valor hash de las grabaciones de ubicación (pi) contenidas en el paquete de datos (3).

5. 5.

   Procedimiento según la reivindicación 4, caracterizado porque las cabeceras (Hi) se envían del aparato de vehículo (1) junto con su identificación (OID) a la central (2).

6. 6.

   Procedimiento según la reivindicación 5, caracterizado porque el envío mencionado (11) del aparato de vehículo (1) a la central (2) se lleva a cabo a través de una red móvil de comunicación.

7. 7.

   Procedimiento según la reivindicación 5 ó 6, caracterizado porque a los datos de peaje (RES) se incorporan las cabeceras (Hi) de los paquetes de datos (3), que sirven de base a éstas, y se comparan en la central

   (2) con las cabeceras (Hi) recibidas de un aparato de vehículo (1) con la misma identificación (OID).

8. 8.

   Procedimiento según una de las reivindicaciones 4 a 7, caracterizado porque las cabeceras (Hi) indican en cada caso también el período de grabación de las grabaciones de ubicación (pi) contenidas en el paquete de datos (3).

9. 9.

   Procedimiento según una de las reivindicaciones 4 a 8, caracterizado porque cada paquete de datos

   (3) se provee de una identificación de paquete (Pi) única entre todos los paquetes de datos de un mismo aparato de vehículo (1) y preferentemente continua.

10. 10.

    Procedimiento según una de las reivindicaciones 1 a 9, caracterizado porque las grabaciones de ubicación (pi) y preferentemente las cabeceras (Hi) existentes opcionalmente son codificadas por el aparato de vehículo (1) con un código igual para varios aparatos de vehículo a fin de generar una firma de aparato (So).

11. 11.

    Procedimiento según la reivindicación 10, caracterizado porque en el servidor de cálculo de peaje (7) se comprueba la autenticidad de la firma de aparato (So).

12. 12.

    Procedimiento según una de las reivindicaciones 1 a 11, caracterizado porque los datos de peaje (RES) y preferentemente las cabeceras (Hi) existentes opcionalmente están firmadas por el servidor de cálculo de peaje (7) con una firma de servidor única (SM).

13. 13.

    Procedimiento según la reivindicación 12, caracterizado porque en la central (2) se comprueba la autenticidad de la firma de servidor (SM).

14. 14.

    Procedimiento según una de las reivindicaciones 1 a 13, caracterizado porque el aparato de vehículo

    (1) determina sus ubicaciones (pi) mediante navegación por satélite.
15. 15. Procedimiento según una de las reivindicaciones 1 a 14, caracterizado porque tanto en el servidor de cálculo de peaje (7) como en la central (2) del sistema de peaje viario se comprueba la integridad y la duplicación de las grabaciones de ubicación (pi) o de los datos de peaje (RES) anonimizados respecto a la ubicación con la ayuda de las cabeceras (Hi) y se toman medidas correctivas, en particular una nueva solicitud de datos y/o mensajes de error.

    REFERENCIAS CITADAS EN LA DESCRIPCIÓN

    Esta lista de referencias citadas por el solicitante es únicamente para la comodidad del lector. No forma parte del documento de la patente europea. A pesar del cuidado tenido en la recopilación de las referencias, no se pueden 5 excluir errores u omisiones y la EPO niega toda responsabilidad en este sentido.

    Documentos de patente citados en la descripción10 WO2008000227A [0003] WO2009001303A1 [0004]