ES2411832B1

ES2411832B1 - Procedimiento para facilitar el uso compartido de vehículos privados, y dispositivo electrónico correspondiente

Info

Publication number: ES2411832B1
Application number: ES201132149A
Authority: ES
Inventors: Andreu CANALS BUTCHER
Original assignee: Individual
Current assignee: Individual
Priority date: 2011-12-30
Filing date: 2011-12-30
Publication date: 2014-06-16
Anticipated expiration: 2031-12-30
Also published as: ES2411832R1; ES2411832A2

Abstract

Procedimiento para facilitar el uso compartido de vehículos privados, y dispositivo electrónico correspondiente. A través de un servidor (1), unos conductores (2) y unos pasajeros (3) acuerdan el uso compartido de un vehículo para un trayecto. El servidor (1) recibe, a través de un sitio Web (4), datos de perfil personal y parámetros de filtro de perfil de cada conductor (2) y cada pasajero (3). Posteriormente el servidor intercambia mensajes SMS con los conductores (2) y los pasajeros (3) para recibir previsiones de trayectos de los conductores (2) y solicitudes de trayectos de los pasajeros (3), realiza una búsqueda de coincidencias de trayectos teniendo en cuenta los datos de perfil personal y los parámetros de filtro de perfil de cada conductor (2) y cada pasajero (3), envía mediante mensajes SMS propuestas de trayectos a los conductores (2) y los pasajeros (3), y recibe una confirmación, también mediante mensajes SMS.

Description

PROCEDIMIENTO PARA FACILITAR EL USO COMPARTIDO DE VEHÍCULOS PRIVADOS, Y DISPOSITIVO ELECTRÓNICO CORRESPONDIENTE

5 DESCRIPCIÓN

Campo de la invención

La invención se sitúa en el campo de los procedimientos y dispositivos que ofrecen 10 soluciones técnicas para facilitar el uso compartido de vehículos particulares.

Concretamente, la invención se refiere a un procedimiento para facilitar el uso compartido de vehículos privados, del tipo que utiliza un servidor al que se conectan por vía telem�tica una pluralidad de conductores de vehículos privados y

15 una pluralidad de pasajeros, donde el servidor realiza las etapas siguientes:

-: recibir de los conductores unas previsiones de trayectos que van a realizar con un vehículo privado, dichas previsiones de trayectos de conductores comprendiendo por lo menos la fecha, hora, origen y destino del trayecto;

-: almacenar dichas previsiones de trayectos de conductores;

20 -recibir de los pasajeros unas solicitudes de trayectos con un origen y un destino determinados;

-: realizar una búsqueda automática de coincidencias para encontrar las previsiones de trayectos de conductores almacenadas que correspondan, al menos en el origen y/o el destino, a las solicitudes de trayectos de pasajeros; y

25 -proporcionar a los conductores y a los pasajeros información de, respectivamente, las solicitudes de trayectos de pasajeros y las previsiones de trayectos de conductores que resultan de dicha búsqueda automática de coincidencias.

30 La invención se refiere asimismo a un dispositivo electrónico configurado como un servido para realizar este procedimiento.

Estado de la técnica

5 Son conocidos unos procedimientos del tipo descrito al principio, en los cuales un servidor, a través de un sitio Web, recibe propuestas de trayectos por parte de conductores y de pasajeros, almacena y ordena estas propuestas de trayectos y, a través del sitio Web, pone a disposición de los usuarios unas herramientas de búsqueda de trayectos coincidentes, de manera que un conductor que prev�

10 realizar un determinado trayecto pueda ponerse de acuerdo con uno o varios pasajeros que van a realizar un trayecto coincidente para compartir el uso de su vehiculo privado. En los sistemas conocidos, una vez que un usuario (conductor o pasajero) ha identificado, gracias a dichas herramientas de búsqueda, a otro usuario que planea realizar un trayecto coincidente con el suyo, se pone en

15 contacto directo con éste con el fin de concretar un acuerdo para el uso compartido del vehículo. La comunicación entre usuarios se realiza libremente, a través de correos electrónicos o de un “chat” (cibercharla), sin que el servidor intervenga en el contenido de las comunicaciones. El servidor sólo interviene, eventualmente, para proporcionar datos de contacto como las direcciones de correo electrónico, o

20 para proporcionar un canal interno de comunicación para que los usuarios se comuniquen entre s� directamente.

Estos procedimientos conocidos ofrecen un servicio útil y son ampliamente utilizados, pero presentan ciertos inconvenientes. El principal inconveniente es que 25 los conductores y pasajeros que utilizan uno de estos procedimientos conocidos tienen que emplear un tiempo considerable para buscar los trayectos y, sobre todo, para llegar a un acuerdo sobre las condiciones para compartir el uso del vehículo, ya que los usuarios deben ponerse en contacto directamente entre s� y es posible que no lleguen a un acuerdo sobre las condiciones del trayecto o que simplemente 30 uno de los usuarios rechace la propuesta del otro porque la comunicación con éste no le ha inspirado confianza. Además, los usuarios tienen que asumir un nivel de inseguridad importante en lo que se refiere a la fiabilidad de los otros usuarios con los que han llegado a un acuerdo, con lo cual tienen que emplear un tiempo adicional para intentar averiguar si la otra parte es fiable, sin poder obtener información concluyente en la mayoría de los casos. Por otra parte, estos procedimientos conocidos tienen el inconveniente de que, para buscar un trayecto correspondiente y llegar a un acuerdo, es necesario que cada usuario tenga acceso al sitio Web mediante un dispositivo equipado con un navegador y a través de un 5 punto de acceso a Internet, cuando actualmente la mayoría de usuarios no dispone de estas condiciones de forma permanente. Por todo lo expuesto, resulta que estos procedimientos conocidos son adecuados para planificar trayectos en vehículos compartidos cuando los usuarios disponen de un margen de tiempo amplio, pero son poco útiles y poco seguros cuando un pasajero busca un conductor para un

10 trayecto más inmediato.

Sumario de la invención

La invención tiene como finalidad proporcionar un procedimiento del tipo indicado al

15 principio, que permita planificar trayectos con poco margen de tiempo, de forma rápida, sencilla y con una seguridad elevada.

De acuerdo con la invención, se ha desarrollado un procedimiento para facilitar el uso compartido de vehículos privados del tipo indicado al principio, caracterizado

20 porque el servidor realiza las etapas siguientes:

-: recibir, a través de un sitio Web al que acceden los conductores y los pasajeros, unos datos personales de éstos que comprenden unos datos de perfil personal y unos parámetros de filtro de perfil, y almacenar dichos datos de perfil personal y dichos parámetros de filtro de perfil para cada conductor y cada pasajero;

25 - posteriormente, realizar una serie de comunicaciones con dichos conductores por una parte, y con dichos pasajeros por otra parte, sin comunicación directa entre dichos conductores y dichos pasajeros, a través de mensajes SMS mediante los cuales dicho servidor: recibe de uno de los pasajeros una solicitud de trayecto, proporciona a dicho pasajero una propuesta de un trayecto de

30 conductor seleccionado que resulta de la búsqueda automática de coincidencias realizada por dicho servidor, recibe de dicho pasajero una notificación de aceptación o de rechazo de dicha propuesta, y si dicha notificación es de aceptación, informa a dicho conductor de dicha solicitud de trayecto del pasajero, recibe de dicho conductor una notificación de aceptación o de rechazo de dicha solicitud de trayecto, e informa a dicho pasajero de la aceptación o rechazo de su solicitud de trayecto por parte de dicho conductor;

donde dichos mensajes SMS enviados por dichos conductores y dichos pasajeros

5 contienen datos estructurados en un formato preestablecido, y dicho servidor lee dicho formato preestablecido y extrae de forma automática los datos contenidos en dichos mensajes SMS; y donde dicho servidor realiza dicha búsqueda automática de coincidencias, tras haber recibido dicha solicitud de trayecto del pasajero a través de un mensaje SMS,

10 a partir de los datos que ha extraído de dicho mensaje SMS y aplicando un filtrado en el que se descartan las previsiones de trayectos de los conductores cuyos datos de perfil personal no se adecuan a los parámetros de filtro de dicho pasajero, y se descartan asimismo las previsiones de trayectos de los conductores para cuyos parámetros de filtro resultan inadecuados los datos de perfil personal de dicho

15 pasajero.

En el presente documento el término “mensaje SMS” tiene el significado convencional de uso en el campo de las telecomunicaciones, es decir que se trata de un mensaje corto de texto que se puede enviar y recibir desde un teléfono móvil

20 u otro dispositivo de mano. Por otra parte, cabe puntualizar que en el presente documento, cuando se habla de que el servidor envía o recibe un mensaje SMS no significa obligatoriamente que lo haga directamente dicho servidor, sino que puede hacerlo, como se ver� más adelante en los ejemplos de realización, a través de una plataforma de tratamiento de mensajes SMS que es ajena a dicho servidor.

25 El procedimiento según la invención se basa en la idea de realizar una primera fase en la que los conductores y los pasajeros proporcionan primero al servidor, a través de un sitio Web, sus datos de perfil personal as� como unos parámetros de filtro de perfil que permitirán al servidor filtrar los resultados de la búsqueda automática de

30 coincidencias, de tal forma que cuando el servidor, como resultado de dicha búsqueda, propone a un pasajero un trayecto de conductor, dicho conductor tiene siempre unos datos de perfil personal que cumplen con los parámetros de filtro de perfil definidos por el pasajero, y viceversa, y una segunda fase en la que el servidor se comunica con los conductores y con los pasajeros a través de mensajes SMS, actuando siempre dicho servidor como intermediario entre un pasajero y un conductor.

5 El efecto técnico de las características diferenciadoras del procedimiento según la invención consiste en una reducción significativa del tiempo y los medios necesarios para que un pasajero realice una solicitud de trayecto y obtenga como respuesta una propuesta de trayecto de conductor y una aceptación final de dicho conductor, con la garantía de que, tanto el pasajero como el conductor, encontrar�

10 en el otro a una persona que responde a sus requisitos.

Este efecto técnico resuelve el problema de proporcionar un procedimiento más rápido, sencillo y seguro, mediante el cual un pasajero pueda realizar el proceso de buscar, encontrar y confirmar un trayecto de conductor que le convenga, con poco

15 margen de tiempo antes del trayecto y sin que sea necesario disponer de un equipo con navegador y un acceso a Internet.

En unas formas de realización preferidas, el procedimiento se caracteriza además porque, en dicha serie de comunicaciones a través de mensajes SMS entre el

20 servidor y los conductores, por una parte, y entre el servidor y los pasajeros por otra parte:

-: el mensaje SMS en el que dicho servidor recibe de uno de dichos pasajeros una solicitud de trayecto contiene los datos siguientes, estructurados en un formato preestablecido que es leído por dicho servidor: origen, destino, fecha y hora del

25 trayecto;

-: el mensaje SMS en el que dicho servidor proporciona a dicho pasajero una propuesta de un trayecto de conductor seleccionado contiene los datos siguientes: identificación del conductor, origen, destino, fecha y hora del trayecto de conductor seleccionado;

30 -el mensaje SMS en el que dicho servidor recibe de dicho pasajero una notificación de aceptación o de rechazo de dicha propuesta contiene los datos siguientes, estructurados en un formato preestablecido que es leído por dicho servidor: un código de aceptación o un código de rechazo;

-: el mensaje SMS en el que dicho servidor informa a dicho conductor de dicha solicitud de trayecto del pasajero contiene los datos siguientes: datos personales del pasajero, origen, destino, fecha y hora;

-: el mensaje SMS en el que dicho servidor recibe de dicho conductor una

5 notificación de aceptación o de rechazo de dicha solicitud de trayecto contiene los datos siguientes, estructurados en un formato preestablecido que es leído por dicho servidor: un código de aceptación o un código de rechazo.

Gracias a esta estructura de mensajes SMS, los conductores y los pasajeros solo

10 tienen que enviar al servidor unos mensajes SMS muy sencillos y cortos, y en cambio reciben del servidor unos mensajes SMS con toda la información necesaria para definir el trayecto e identificar a la otra parte, bien sea el conductor o el pasajero.

15 Preferentemente, en las formas de realización preferidas el servidor realiza una etapa consistente en comprobar si los datos contenidos en el mensaje SMS que ha recibido del conductor con una notificación de aceptación o de rechazo de la solicitud de trayecto contienen un código de aceptación, y en caso afirmativo realizar automáticamente una operación contable para retribuir a dicho conductor y

20 gravar a dicho pasajero con un importe preestablecido correspondiente al trayecto. Esta solución ofrece una forma rápida y simple de integrar en el procedimiento la gestión de las retribuciones que los pajareros pagan a los conductores por los servicios prestados por los primeros, de manera que éstos no tengan que ocuparse de la cuestión monetaria durante el proceso de buscar, encontrar y confirmar un

25 trayecto, y tampoco tengan que ocuparse de dicha cuestión después. Como se ver� más adelante en los ejemplos de realización, esta solución permite que el servidor gestione unas cuentas monetarias de los conductores y los pasajeros, de manera que estos últimos solo tengan que ocuparse de mantener su cuenta con crédito suficiente.

30 Preferentemente, en las formas de realización preferidas el servidor realiza una etapa de recibir previsiones de trayectos de conductores a través de un mensaje SMS que contiene por lo menos los datos siguientes estructurados en un formato preestablecido: identificación del conductor, origen, destino, fecha y hora del trayecto; y leer dicho formato preestablecido y extraer de forma automática dichos datos contenidos en dicho mensaje SMS. Es decir que la operación de proponer al servidor una previsión de trayecto por parte de un conductor se puede realizar

5 igualmente a través de un mensaje SMS, con lo cual también los conductores pueden realizar propuestas de una forma rápida, sencilla y con poco margen de tiempo antes del trayecto.

Preferentemente, en las formas de realización preferidas el servidor realiza la etapa

10 de recibir previsiones de trayectos de conductores y solicitudes de trayectos de pasajeros, además de a través de mensajes SMS enviados por dichos conductores y dichos pasajeros, también a través de dicho sitio Web al que acceden dichos conductores y dichos pasajeros. As�, los conductores o los pasajeros pueden utilizar igualmente el sitio Web para ofrecer y buscar trayectos cuando disponen de

15 tiempo suficiente antes del trayecto o cuando disponen de un navegador y una conexión a Internet.

Preferentemente, en las formas de realización preferidas el servidor realiza la etapa de generar en dicho sitio Web un calendario, personalizado para cada uno de

20 dichos conductores y accesible por éste, en el que se muestran las previsiones de trayectos de dicho conductor y las solicitudes de trayectos de pasajeros que han sido aceptadas por dicho conductor. Los conductores pueden as� planificar y organizar más fácilmente sus trayectos.

25 Preferentemente, en las formas de realización preferidas el servidor recibe una parte de dichos datos de perfil personal del propio conductor o pasajero al que se refieren dichos datos, a través de dicho sitio Web, y otra parte de dichos datos de perfil personal de otros conductores o pasajeros que han compartido un trayecto con el primero, también a través de dicho sitio Web, y dicho servidor almacena

30 todos estos datos de perfil personal. De esta forma, los parámetros de filtro de perfil proporcionados por los pasajeros o los conductores, para que el servidor filtre automáticamente los trayectos, se refieren igualmente a datos que son proporcionados por otros usuarios, con lo cual se evita que un conductor o pasajero proporcione unos datos de perfil personal falseados.

La invención se refiere asimismo a un dispositivo electrónico configurado como un

5 servidor, que almacena unas instrucciones ejecutables por ordenador para realizar las etapas del servidor en el procedimiento según la invención que acaba de describirse.

La invención también comprende otras características de detalle ilustradas en la

10 descripción detallada de unas formas de realización de la invención y en las figuras correspondientes.

Breve descripción de los dibujos

15 La Fig. 1 es una vista esquemática que muestra los canales de comunicación entre el servidor y los conductores, por una parte, y entre el servidor y los pasajeros por otra parte.

La Fig. 2 es un diagrama de bloques del procedimiento, incluyendo las diferentes

20 etapas del mismo desde que los conductores y los pasajeros proporcionan al servidor, a través del sitio Web, sus datos de perfil personal y sus parámetros de filtro de perfil, hasta que un pasajero y un conductor acuerdan un trayecto comunicándose con dicho servidor a través de mensajes SMS.

25 Descripción detallada de unas formas de realización de la invención

La Fig. 1 muestra de forma esquemática cómo los conductores 2 y los pasajeros 3 se relacionan con un servidor 1 que ejecuta las acciones características del procedimiento según la invención. Con el fin de simplificar el esquema y hacerlo 30 más comprensible, la Fig. 1 muestra un solo conductor 2 y un solo pasajero 3. Por supuesto, en el procedimiento según la invención participan una multitud de conductores 2 y pasajeros 3 que se relacionan individualmente con el servidor 1 de acuerdo con el esquema de la Fig. 1. El servidor 1 est� formado, de forma

conocida, por un equipo inform�tico que comprende unos medios de procesamiento de datos, unos medios de almacenamiento de datos y unos medios de conexión a una red de datos. En el presente ejemplo esta red de datos es la red Internet.

El servidor 1 se relaciona con los conductores 2 y con los pasajeros 3 a través de dos vías de comunicación diferentes.

La primera vía de comunicación est� formada por un sitio Web 4 al que tienen

10 acceso a través de la red Internet los conductores 2 y los pasajeros 3 que utilizan unos equipos inform�ticos 6 provistos de un navegador y una conexión a la red Internet. Estos equipos 6 pueden ser, por ejemplo, ordenadores personales, teléfonos móviles inteligentes (“smartphones”), etc. El servidor 1, por su parte, también tiene acceso al sitio Web 4 como administrador del mismo. El sitio Web 4

15 puede estar alojado por el propio servidor 1 o bien en otro equipo en conexión con este último a través de la red Internet.

La segunda vía de comunicación consiste en un sistema de emisión y recepción de mensajes SMS a través de una red hertziana de telefonía móvil, en el que una 20 plataforma 5 de emisión y recepción automáticas de mensajes SMS recibe los mensajes SMS que son enviados por los conductores 2 y por los pasajeros 3, y envía mensajes SMS a estos mismos. Los conductores 2 y pasajeros 3 envían y reciben estos mensajes SMS a través de teléfonos móviles 7. La plataforma 5 transmite automáticamente a dicho servidor 1 el texto de los mensajes SMS que 25 recibe de los conductores 2 y los pasajeros 3, incluyendo el número de teléfono de origen, y recibe de dicho servidor 1 el texto de los mensajes SMS que dicha plataforma 5 debe enviar automáticamente a los conductores 2 y a los pasajeros 3, incluyendo el número de teléfono de destino. Estos intercambios de datos entre el servidor 1 y la plataforma 5 se realizan a través de la red Internet. En resumen, el 30 servidor 1 intercambia mensajes SMS con los conductores 2 y con los pasajeros 3 a través de la plataforma 5, pero a afectos prácticos todo ocurre como si el servidor 1 intercambiara dichos mensajes SMS directamente con los conductores 2 y los pasajeros 3. No se considera necesario detallar aquí el funcionamiento de

semejante plataforma 5 de emisión y recepción automáticas de mensajes SMS, ni la forma en que esta se comunica con el servidor 1 a través de la red Internet, pues se trata de tecnología convencional al alcance del experto en la materia.

5 La Fig. 2 muestra las diferentes etapas que se realizan en el servidor 1 y que caracterizan el procedimiento según la invención.

En una fase inicial (etapa 8 en la Fig. 2), cada conductor 2 y cada pasajero 3 accede al sitio Web 4 para proporcionar al servidor 1 unos datos personales que 10 comprenden unos datos identificativos, unos datos de perfil personal y unos parámetros de filtro de perfil.

Los datos identificativos comprenden el nombre as� como el número de teléfono móvil del conductor 2 o el pasajero 3.

Los datos de perfil personal se refieren a unos campos determinados que definen un perfil del conductor 2 o del pasajero 3, pudiendo incluir en el caso de un conductor datos relativos al vehículo utilizado por éste en sus trayectos. Algunos de estos datos de perfil personal son declarados por el propio conductor 2 o pasajero 20 3, a través del sitio Web 4, mientras que otros son proporcionados, también a través del sitio Web 4, por los usuarios según su propia experiencia en trayectos compartidos con dicho conductor 2 o pasajero 3. En este ejemplo, los datos de perfil personal de conductor 2 son los siguientes: sexo, edad, años de permiso de conducción, precio kilométrico de trayecto, nota de valoración de la persona, nota 25 de puntualidad, nota de seguridad en la conducción, nota de confort del vehículo. Los cuatro primeros son proporcionados por el propio conductor 2 a través del sitio Web 4, mientras que los otros son una nota promedio de unas notas que son proporcionadas, también a través del sitio Web 4, por los pasajeros 3 que ya han viajado con este conductor 2. Los datos de perfil personal de pasajero son, en este 30 ejemplo, los siguientes: sexo, edad, nota de valoración de la persona, nota de puntualidad. Los dos primeros son proporcionados por el propio pasajero 3 a través del sitio Web 4, mientras que los otros son una nota promedio de las notas que son

proporcionadas, también a través del sitio Web 4, por los conductores 2 que ya han viajado con este pasajero 3.

Supongamos, para ilustrar este ejemplo, que el servidor 1 ha recibido y 5 almacenado los siguientes datos identificativos y de perfil personal para dos conductores de nombre “Josep”” y Maria” y un pasajero de nombre “Pere”:

Datos identificativos y de perfil personal del conductor “Josep”:

-: nombre: “�Josep” 10 - Numero de telefono: 111111111

-: sexo: hombre

-: edad: 30

-: años de permiso de conducción: 10

-: precio kilométrico de trayecto: 0,12 EUR 15 - nota de valoración de la persona: 4/5

-: nota de puntualidad: 4/5

-: nota de seguridad en la conducción: 4/5

-: nota de confort del vehículo: 3/5

20 Datos identificativos y de perfil personal del conductor “Maria”

-: nombre: “�Maria”

-: Numero de telefono: 222222222

-: sexo: mujer

-: edad: 20 25 - años de permiso de conducción: 1

-: precio kilométrico de trayecto: 0,11 EUR

-: nota de valoración de la persona: 5/5

-: nota de puntualidad: 5/5

-: nota de seguridad en la conducción: 5/5 30 -nota de confort del vehículo: 4/5

Datos identificativos y de perfil personal del pasajero “Pere”:

-: nombre: “�Pere”

-: Numero de telefono: 333333333

-: sexo: hombre

-: edad: 19

- nota de valoración de la persona: 5/5 5 - nota de puntualidad: 4/5

Los parámetros de filtro de perfil se refieren a unos campos correspondientes a los de los datos personales de perfil, y sirven para que el servidor 1 aplique un filtrado personalizado cuando realiza la búsqueda automática de coincidencias de 10 trayectos. As�, en este ejemplo los parámetros de filtro de perfil que se aplican a los conductores 2, para un pasajero 3 determinado que ha proporcionado estos parámetros, son los siguientes: sexo, edad, precio kilométrico de trayecto, años de permiso de conducción, nota de valoración de la persona, nota de puntualidad, nota de seguridad en la conducción, nota de confort del vehículo, Los parámetros de

15 filtro de perfil que se aplican a los pasajeros 3, para un conductor 2 determinado que ha proporcionado estos parámetros, son los siguientes: sexo, edad, nota de valoración de la persona, nota de puntualidad. Siguiendo con el ejemplo, supongamos que los parámetros de filtro de perfil proporcionados por los conductores “Josep” y “Maria” y por el pasajero “Pere” son

20 los siguientes:

Datos de perfil personal de pasajero definidos por el conductor “Josep”:

-: sexo: indiferente

-: edad: igual o superior a 18 años 25 - nota de valoración de la persona: superior o igual a 3/5

-: nota de puntualidad: superior o igual a 4/5

Datos de perfil personal de pasajero definidos por el conductor “Maria”:

-: sexo: mujer 30 - edad: igual o superior a 18 años

-: nota de valoración de la persona: superior o igual a 4/5;

-: nota de puntualidad: superior o igual a 4/5;

Datos de perfil personal de conductor definidos por el pasajero “Pere”:

-: sexo: indiferente

-: edad: indiferente

-: precio kilométrico de trayecto: inferior o igual a 0,15 EUR 5 - años de permiso de conducción: superior o igual a 3

-: nota de valoración de la persona: 4/5

-: nota de puntualidad: 4/5

-: nota de seguridad en la conducción: 4/5

-: nota de confort del vehículo: 2/5

10 Por otra parte, en las formas de realización preferidas el servidor 1 también recibe de los conductores 2 y pasajeros 3, a través del sitio Web 4, unas definiciones de puntos geográficos en forma de unas palabras clave, y dicho servidor 1 las almacena como propias de cada conductor 2 o pasajero 3 que las ha

15 proporcionado.

Siguiendo con el ejemplo, el conductor “Josep” proporciona al servidor 1 las palabras clave “mataro” y “hospitalet” para definir un punto geográfico en las ciudades de Matar� y Hospitalet de Llobregat, respectivamente:

“mataro” = “Ajuntament de Mataro, Riera 48, 08301 Mataro”

“hospitalet” = “Mercat Bellvitge,, Mare de Deu de Bellvitge S/N, 08907 L'Hospitalet de Llobregat”

25 Asimismo, el pasajero 3 “Pere” proporciona al servidor 1 las palabras clave “casa” y “trabajo” para definir unos puntos geográficos en las ciudades de Matar� y Hospitalet de Llobregat, respectivamente:

30 “casa” = “Sant Antoni 10, 08301 Mataro”

“trabajo” = “Rambla Marina 100, 08907 Hospitalet de Llobregat” Además, en las formas de realización preferidas del procedimiento según la invención, el servidor 1 gestiona una cuenta monetaria para cada conductor 2 y cada pasajero 3. Los conductores 2 y los pasajeros 3 alimentan su cuenta monetaria para que ésta tenga crédito, por ejemplo mediante transferencias a una

5 cuenta bancaria de la empresa o la entidad que gestiona el servidor 1. Como se ver� más adelante, el servidor 1 gestiona estas cuentas transfiriendo de la cuenta de un pasajero a la cuenta de un conductor una cantidad preestablecida para el trayecto compartido.

10 Volviendo ahora a la Fig. 2, en una fase posterior (etapas 9 a 17 en la Fig. 2) el servidor 1 realiza las acciones que se describen a continuación, con la finalidad de que un pasajero 3 y un conductor 2 lleguen a un acuerdo para compartir un trayecto.

15 En primer lugar (etapa 9), el servidor 1 recibe de los conductores 2 unas previsiones de trayectos que estos van a realizar con un vehículo privado, indicando la fecha, hora, origen y destino del trayecto, y almacena estas previsiones de trayectos. El servidor 1 puede recibir estas previsiones de trayectos a través del sitio Web 4. Asimismo, el servidor 1 puede recibir estas previsiones de

20 trayectos a través de un mensaje SMS enviado por un conductor 2, que contiene los datos mencionados estructurados en un formato preestablecido. El servidor 1 lee este formato preestablecido y extrae automáticamente los datos contenidos en el mensaje SMS.

25 En este ejemplo el formato de datos preestablecido en los mensajes SMS para que un conductor 2 proporcione una previsión de trayecto es el siguiente: una primera letra “n” para indicar que se trata de una nueva previsión de trayecto, un espacio, el lugar de origen, el signo @, el lugar de destino, el signo @, la fecha en formato “día/mes”, un espacio, la hora en formato “hora.minutos”. Por ejemplo, el conductor

30 “Josep” envía el siguiente SMS al servidor 1:

n mataro@hospitalet@15/06 07.00

con lo cual est� definiendo una nueva previsión de trayecto el día 15 de junio a las 07h00 entre el punto de origen “Ajuntament de Mataro, Riera 48, 08301 Mataro” y el punto de destino “Mercat Bellvitge Mare de Deu de Bellvitge S/N, 08907 L'Hospitalet de Llobregat”.

El servidor 1 recibe este mensaje SMS y extrae los datos contenidos en el mismo, as� como el número de teléfono del remitente de dicho mensaje SMS, que en este caso es el “111111111”. El servidor 1 consulta su base de datos e identifica al conductor “Josep” a través de este número de teléfono.

10 El servidor 1 contesta automáticamente al conductor “Josep” enviándole el siguiente mensaje SMS para solicitarle confirmación, pidiéndole que para confirmar reenv�e simplemente un SMS con el código de confirmación “OK” seguido del código de trayecto que el servidor ha asignado (por ejemplo el 445):

15 Viaje nuevo: de Ajuntament de Mataro, Riera 48, 08301 Mataro a “Mercat Bellvitge,, Mare de Deu de Bellvitge S/N, 08907 L'Hospitalet de Llobregat el 15/06/2011 a las

07.00 CONFIRMA: “OK 445”

20 Para confirmar la previsión de trayecto, el conductor “Josep” contesta al servidor 1 enviando el siguiente mensaje SMS:

OK 445

25 El servidor 1 recibe este mensaje SMS y almacena definitivamente los datos de esta previsión de trayecto para el conductor “Josep” con el código de trayecto “445”.

Obviamente, esta etapa 9 se repite tantas veces como un conductor 2 defina una

30 previsión de trayecto, con lo cual el servidor 1 tiene almacenadas una pluralidad de previsiones de trayectos de conductores.2.

A continuación (etapa 10), el servidor 1 recibe mediante un mensaje SMS de uno de los pasajeros 3 una solicitud de trayecto que contiene los datos siguientes estructurados en un formato preestablecido: origen, destino, fecha y hora del trayecto. El servidor 1 lee este formato preestablecido y extrae automáticamente

5 los datos contenidos en el mensaje SMS.

En este ejemplo el formato de datos preestablecido en los mensajes SMS para que un pasajero 3 proporcione una solicitud de trayecto es el siguiente: lugar de origen, el signo @, el lugar de destino, el signo @, la fecha en formato “día/mes”, un

10 espacio, la hora en formato “hora.minutos”.

Siguiendo con el ejemplo, supongamos que el pasajero “Pere” envía el siguiente SMS al servidor 1:

15 casa@trabajot@15/06 07.30

con lo cual est� pidiendo al servidor 1 que busque y le ofrezca trayectos de conductores que coincidan con el trayecto que desea realizar el día 15 de junio a las 07h30 entre el punto de origen “Sant Antoni 10, 08301 Mataro” y el punto de

20 destino “Rambla Marina 100, 08907 Hospitalet de Llobregat”.

El servidor 1 recibe este mensaje SMS y extrae los datos contenidos en el mismo, as� como el número de teléfono del remitente de dicho mensaje SMS, que en este caso es el “333333333”. El servidor 1 consulta su base de datos e identifica al

25 pasajero “Pere” a través de este número de teléfono.

Tras recibir este mensaje SMS y haber extraído los datos contenidos en el mismo, el servidor 1 realiza (etapa 11) una búsqueda automática de coincidencias en modo filtrado, que consiste en buscar las previsiones de trayectos de los conductos que 30 coinciden suficientemente, en lo que respecta al origen, destino, fecha y hora, con la petición de trayecto que ha sido enviada por dicho pasajero 3 a través del mensaje SMS, pero descartando aquellas previsiones de trayectos de conductores 2 cuyos datos de perfil personal no superan el filtro que había sido definido por el

pasajero 3 mediante los parámetros de filtro de perfil (proporcionados en la etapa 8), y descartando también las previsiones de trayectos de los conductores 2 que habían definido un filtro, mediante los parámetros de filtro de perfil (proporcionados en la etapa 8), que no es superado por los datos de perfil personal de dicho

5 pasajero 3.

Siguiendo con el ejemplo, la búsqueda automática de coincidencias realizada por el servidor 1 descartar� automáticamente todas previsiones de trayectos proporcionadas por el conductor “Maria”, porque el perfil de este conductor no

10 supera el filtro de perfil de conductor que el pasajero “Pere” ha definido a través de los parámetros de filtro de perfil. En efecto, en los datos de perfil del conductor “Maria” el campo de años de permiso de conducción tiene el valor 1, mientras que los parámetros de filtro de perfil para los conductores definidos por el pasajero “Pere” especifican que este campo debe tener un valor superior o igual a 3.

15 De entre las previsiones de trayectos que no han sido descartadas por este filtrado, el servidor 1 selecciona automáticamente aquellas que cumplen con unos criterios de coincidencia predefinidos para el origen, destino, fecha y hora del trayecto. En este ejemplo, estos criterios de coincidencia son los siguientes:

20 - origen o destino: existen coincidencia cuando los dos puntos geográficos est�n separados por una distancia inferior o igual a 500 metros;

-: fecha: existe coincidencia solo cuando las dos fechas son iguales;

-: hora: existe coincidencia cuando la diferencia entre las dos horas es inferior o igual a 60 minutos;

25 - y existe coincidencia de dos trayectos cuando existe coincidencia en el origen, el destino, la fecha y la hora de los mismos.

Por supuesto, es posible definir otros criterios de coincidencia. Por ejemplo, para el origen o destino se puede aplicar un criterio que consiste en considerar que existe

30 coincidencia cuando los dos puntos geográficos est�n separados por una distancia inferior o igual a una fracción determinada, por ejemplo el 30%, de la distancia del trayecto.

En unas formas de realización, estos criterios de coincidencia son específicos para cada pasajero 3, que los proporciona al servidor 1 en la etapa 8 a través del sitio Web 4.

5 Para determinar la distancia que separa dos puntos geográficos, el servidor 1 utiliza por ejemplo aplicaciones inform�ticas que se basan las aplicaciones “Google Maps”

o “Google Earth” (marcas registradas) y que proporcionan la distanciaentre dos puntos geográficos definidos cada uno por una dirección. Estas aplicaciones est�n al alcance del experto en la materia, con lo cual no se considera necesario

10 describirlas en el presente documento.

Siguiendo con el ejemplo, como resultado de la búsqueda automática de coincidencias el servidor 1 habr� seleccionado por lo menos la previsión de trayecto del conductor “Josep”, con código de trayecto “445”. En efecto, la distancia

15 que separa los dos orígenes es inferior a 500 metros, la distancia que separa los dos destinos es inferior a 500 metros, la fecha es la misma y la diferencia entre las dos horas es inferior a 60 minutos.

Si el servidor 1, como resultado de la búsqueda automática de coincidencias, ha

20 seleccionado igualmente otras previsiones de trayectos, las ordena por nivel de coincidencia, aplicando un criterio que puede haber sido definido por el pasajero 3 a través de un campo específico en los datos de perfil personal. Por ejemplo, un pasajero 3 puede especificar que el servidor 1 ordene los resultados de la búsqueda de coincidencias según el precio de trayecto, de manera que la primera

25 propuesta enviada por el servidor 1 sea la del trayecto más económico.. Para continuar con el ejemplo, supondremos que la previsión de trayecto del conductor “Josep”, con código de trayecto “445”, es la que presenta un mayor grado de coincidencia con la solicitud de trayecto enviada por el usuario “Pere”.

30 A continuación (etapas 12 a 17), el servidor 1 realiza una serie de etapas para proponer al pasajero 3 un trayecto de conductor que ha seleccionado, obtener la conformación tanto del pasajero 3 como del conductor 2 y gestionar el pago del trayecto al conductor 2 por parte del pasajero 3.

Siguiendo con el ejemplo, en la etapa 12 el servidor 1 envía al pasajero “Pere” el siguiente mensaje SMS para ofrecerle el trayecto del conductor “Josep” con código de trayecto “445”, indicando la identificación del conductor, origen, destino, fecha y

5 hora del trayecto de conductor seleccionado, y el código de identificación del trayecto:

Josep va de Ajuntament de Mataro, Riera 48, 08301 Mataro a Mercat Bellvitge Mare de Deu de Bellvitge S/N, 08907 L'Hospitalet de Llobregat el 15/06/2011 a las 10 7h00. CONFIRMA: ”OK 445”

Si el pasajero “Pere” est� de acuerdo en compartir este trayecto, contesta al servidor 1 enviando el siguiente mensaje SMS:

15 OK 445

El servidor 1 recibe este mensaje SMS (etapa 13), lo lee automáticamente y detecta que contiene el código de conformación “OK” para el trayecto de conductor con código 445. En este caso el servidor 1 (etapa 14) envía al conductor “Josep” el

20 siguiente mensaje SMS para informarle de la solicitud de trayecto del pasajero “Pere”:

Pere solicita una plaza en el trayecto de Ajuntament de Mataro, Riera 48, 08301 Mataro a Mercat Bellvitge Mare de Deu de Bellvitge S/N, 08907 L'Hospitalet de 25 Llobregat el 15/06/2011 a las 7h00. CONFIRMA: “OK 445” .

Si el conductor “Josep” est� de acuerdo en compartir este trayecto con el pasajero “Pere”, contesta al servidor 1 enviando el siguiente mensaje SMS:

30 OK 445

El servidor 1 recibe este mensaje SMS (etapa 15), lo lee automáticamente y detecta que contiene el código de confirmación “OK” para la solicitud de trayecto

con código 445. En este caso el servidor 1 (etapa 16) realiza automáticamente una operación contable para retribuir al conductor “Josep” y gravar al pasajero “Pere” con un importe preestablecido correspondiente al trayecto que han acordado compartir. En este ejemplo, el importe preestablecido resulta de multiplicar la 5 distancia del trayecto en kilómetros por el precio kilométrico de trayecto que est� definido en los datos de perfil personal del conductor “Josep”. Esta operación contable consiste en disminuir en dicho importe el saldo de la cuenta monetaria del pasajero “Pere” y aumentar en dicho importe la cuenta monetaria del conductor “Josep”. Como se ha dicho anteriormente, el servidor 1 gestiona una cuenta 10 monetaria para cada conductor 2 y cada pasajero 3, y estos alimentan estas cuentas monetarias realizando pagos a una empresa o una entidad que gestiona el servidor 1. En unas formas de realización, se prev� que el servidor 1 ncluya el precio del trayecto en el mensaje SMS que envía a un pasajero 3 para proporcionarle una propuesta de trayecto de conductor (etapa 12). De esta forma,

15 cuando el pasajero envía al servidor 1 un mensaje SMS con su aceptación de la propuesta, acepta al mismo tiempo el precio del trayecto.

A continuación, el servidor 1 realiza una última etapa (etapa 17) que consiste en enviar al pasajero 3 un mensaje SMS para confirmar que el conductor 2 le ha 20 aceptado para compartir el trayecto. Siguiendo con el ejemplo, en esta última etapa el servidor 1 envía al pasajero “Pere” el siguiente mensaje SMS:

Josep te ha aceptado en su trayecto el 15/06/2011. Salida a las 7h00 en Ajuntament de Mataro, Riera 48, 08301 Mataro. LLegada a Mercat Bellvitge,

, Mare 25 de Deu de Bellvitge S/N, 08907 L'Hospitalet de Llobregat. Buen viaje !!

En la etapa 13, si el pasajero 3 decide no aceptar la propuesta enviada por el servidor 1, envía un mensaje SMS con un código de rechazo. En el ejemplo, el pasajero “Pere” enviaría el mensaje siguiente:

NO 445

El servidor 1 recibe este mensaje SMS, lo lee automáticamente y detecta que contiene el código de rechazo “NO” para el trayecto de conductor con código 445. En este caso el servidor 1 vuelve a la etapa 12 y envía al pasajero “Pere” otra propuesta de trayecto de conductor, entre las seleccionadas como resultado de la

5 búsqueda realizada en la etapa 11. Si no hay más trayectos de conductor que proponer, el servidor 1 envía al pasajero “Pere” un mensaje SMS en el que le informa de ello.

En la etapa 15, si el conductor 2 decide no aceptar la solicitud del pasajero 2, envía

10 al servidor 1 un mensaje SMS con un código de rechazo. En el ejemplo, el conductor “Josep” enviaría el mensaje siguiente:

NO 445

15 El servidor 1 recibe este mensaje SMS, lo lee automáticamente y detecta que contiene el código de rechazo “NO” para la solicitud de trayecto con código 445. En este caso el servidor 1 envía al pasajero “Pere” un mensaje SMS en el que le informa de que el conductor “Josep” ha rechazado su solicitud, y seguidamente vuelve a la etapa 12 y envía al pasajero “Pere” otra propuesta de trayecto de

20 conductor, de entre las seleccionadas como resultado de la búsqueda realizada en la etapa 11. Si no hay más trayectos de conductor que proponer, el servidor 1 envía al pasajero “Pere” un mensaje SMS en el que le informe de ello.

Por otra parte, el servidor 1 también est� configurado para que los conductores 2 y

25 los pasajeros 3 puedan realizar otras gestiones a través del sitio Web 4. En particular, el servidor 1 est� configurado para recibir las previsiones de trayectos de conductores 2 y las solicitudes de trayectos de pasajeros 3, además de a través de mensajes SMS enviados por dichos conductores 2 y dichos pasajeros 3, también a través del sitio Web 4. En unas formas de realización, un conductor 2 puede definir

30 a través del sitio Web 4 unas previsiones de trayecto regulares, por ejemplo definiendo un origen, un destino y una hora y especificando que el trayecto se realiza todos los días laborables entre dos fechas determinadas. Entonces el servidor 1 crea automáticamente y almacena una pluralidad de previsiones de trayectos correspondientes para este conductor 2. Asimismo, se prev� que el servidor 1 est� configurado para generar en el sitio Web 4 un calendario, personalizado para cada conductor 2 y accesible por éste, en el que se muestran las previsiones de trayectos de dicho conductor 2 y las solicitudes de trayectos de pasajeros 3 que han sido aceptadas por dicho conductor 2.

Claims

REIVINDICACIONES

1.-Procedimiento para facilitar el uso compartido de vehículos privados, que utiliza 5 un servidor (1) al que se conectan por vía telem�tica una pluralidad de conductores

(2)

de vehículos privados y una pluralidad de pasajeros (3), donde dicho servidor

(1)

realiza las etapas siguientes:

-

recibir de dichos conductores (2) unas previsiones de trayectos que van a

realizar con un vehículo privado, dichas previsiones de trayectos de conductores 10 (2) comprendiendo por lo menos la fecha, hora, origen y destino del trayecto;

-

almacenar dichas previsiones de trayectos de conductores (2);

-

recibir de dichos pasajeros (3) unas solicitudes de trayectos con un origen y un destino determinados;

-

realizar una búsqueda automática de coincidencias para encontrar las

15 previsiones de trayectos de conductores (2) almacenadas que correspondan, al menos en el origen y/o el destino, a las solicitudes de trayectos de pasajeros (3); y

-

proporcionar a dichos conductores (2) y a dichos pasajeros (3) información de, respectivamente, las solicitudes de trayectos de pasajeros (3) y las previsiones 20 de trayectos de conductores (2) que resultan de dicha búsqueda automática de

coincidencias; caracterizado porque dicho servidor (1) realiza las etapas siguientes:

-

recibir, a través de un sitio Web (4) al que acceden dichos conductores (2) y dichos pasajeros (3), unos datos personales de éstos que comprenden unos

25 datos de perfil personal y unos parámetros de filtro de perfil, y almacenar dichos datos de perfil personal y dichos parámetros de filtro de perfil para cada conductor (2) y cada pasajero (3);

-

posteriormente, realizar una serie de comunicaciones con dichos conductores

(2) por una parte, y con dichos pasajeros (3) por otra parte, sin comunicación

30 directa entre dichos conductores (2) y dichos pasajeros (3), a través de mensajes SMS mediante los cuales dicho servidor (1): recibe de uno de dichos pasajeros (3) una solicitud de trayecto, proporciona a dicho pasajero (3) una propuesta de un trayecto de conductor (2) seleccionado que resulta de dicha búsqueda automática de coincidencias realizada por dicho servidor (1), recibe de dicho pasajero (3) una notificación de aceptación o de rechazo de dicha propuesta, y si dicha notificación es de aceptación, informa a dicho conductor (2) de dicha solicitud de trayecto del pasajero (3), recibe de dicho conductor (2) una

5 notificación de aceptación o de rechazo de dicha solicitud de trayecto, e informa a dicho pasajero (3) de la aceptación o rechazo de su solicitud de trayecto por parte de dicho conductor (2);

donde dichos mensajes SMS enviados por dichos conductores (2) y dichos pasajeros (3) contienen datos estructurados en un formato preestablecido, y dicho

10 servidor (1) lee dicho formato preestablecido y extrae de forma automática los datos contenidos en dichos mensajes SMS; y donde dicho servidor (1) realiza dicha búsqueda automática de coincidencias, tras haber recibido dicha solicitud de trayecto del pasajero (3) a través de un mensaje SMS, a partir de los datos que ha extraído de dicho mensaje SMS y aplicando un

15 filtrado en el que se descartan las previsiones de trayectos de los conductores (2) cuyos datos de perfil personal no se adecuan a los parámetros de filtro de dicho pasajero (3), y se descartan asimismo las previsiones de trayectos de los conductores (2) para cuyos parámetros de filtro resultan inadecuados los datos de perfil personal de dicho pasajero (3).

20 2.- Procedimiento según la reivindicación 1, caracterizado porque en dicha serie de comunicaciones a través de mensajes SMS:

-

el mensaje SMS en el que dicho servidor (1) recibe de uno de dichos pasajeros

(3) una solicitud de trayecto contiene los datos siguientes, estructurados en un

25 formato preestablecido que es leído por dicho servidor (1): origen, destino, fecha y hora del trayecto;

-

el mensaje SMS en el que dicho servidor (1) proporciona a dicho pasajero (3) una propuesta de un trayecto de conductor (2) seleccionado contiene los datos siguientes: identificación del conductor, origen, destino, fecha y hora del trayecto

30 de conductor (2) seleccionado;

-

el mensaje SMS en el que dicho servidor (1) recibe de dicho pasajero (3) una notificación de aceptación o de rechazo de dicha propuesta que contiene los

datos siguientes, estructurados en un formato preestablecido que es leído por dicho servidor (1): un código de aceptación o un código de rechazo;

-

el mensaje SMS en el que dicho servidor (1) informa a dicho conductor (2) de dicha solicitud de trayecto del pasajero (3) contiene los datos siguientes: datos

5 personales del pasajero (3), origen, destino, fecha y hora del trayecto de conductor (2) seleccionado;

-

el mensaje SMS en el que dicho servidor (1) recibe de dicho conductor (2) una notificación de aceptación o de rechazo de dicha solicitud de trayecto contiene los datos siguientes, estructurados en un formato preestablecido que es leído

10 por dicho servidor (1): un código de aceptación o un código de rechazo.
3.- Procedimiento según las reivindicaciones 1 � 2, caracterizado porque dicho servidor (1) realiza una etapa de:

-

comprobar si los datos contenidos en el mensaje SMS que ha recibido del

15 conductor (2) con una notificación de aceptación o de rechazo de la solicitud de trayecto contienen un código de aceptación, y en caso afirmativo realizar automáticamente una operación contable para retribuir a dicho conductor (2) y gravar a dicho pasajero (3) con un importe preestablecido correspondiente al trayecto.

20 4.- Procedimiento según cualquiera de las reivindicaciones 1 a 3, caracterizado porque dicho servidor (1) realiza una etapa de:

-

recibir previsiones de trayectos de conductores (2) a través de un mensaje SMS que contiene por lo menos los datos siguientes estructurados en un formato

25 preestablecido: identificación del conductor (2), origen, destino, fecha y hora del trayecto; y leer dicho formato preestablecido y extraer de forma automática dichos datos contenidos en dicho mensaje SMS.
5.- Procedimiento según la reivindicación 4, caracterizado porque dicho servidor (1) 30 realiza la etapa de:

-

recibir previsiones de trayectos de conductores (2) y solicitudes de trayectos de pasajeros (3), además de a través de mensajes SMS enviados por dichos conductores (2) y dichos pasajeros (3), también a través de dicho sitio Web (4) al que acceden dichos conductores (2) y dichos pasajeros (3).
6.- Procedimiento según cualquiera de las reivindicaciones 1 a 5, caracterizado 5 porque dicho servidor (1) realiza la etapa de:

-

generar en dicho sitio Web (4) un calendario, personalizado para cada uno de dichos conductores (2) y accesible por éste, en el que se muestran las previsiones de trayectos de dicho conductor (2) y las solicitudes de trayectos de pasajeros (3) que han sido aceptadas por dicho conductor (2).

10 7.- Procedimiento según cualquiera de las reivindicaciones 1 a 6, caracterizado porque dicho servidor (1) recibe una parte de dichos datos de perfil personal del propio conductor (2) o pasajero (3) al que se refieren dichos datos, a través de dicho sitio Web (4), y otra parte de dichos datos de perfil personal de otros

15 conductores (2) o pasajeros (3) que han compartido un trayecto con el primero, también a través de dicho sitio Web (4), y dicho servidor (1) almacena todos estos datos de perfil personal.
8.- Dispositivo electrónico configurado como un servidor, que almacena unas

20 instrucciones ejecutables por ordenador para realizar las etapas del servidor (1) en el procedimiento según cualquiera de las reivindicaciones 1 a 7.

3 FIG. 1

6

7

6

7

Sitio Web

SMS

FIG. 2

OFICINA ESPAÑOLA DE PATENTES Y MARCAS

N.� solicitud: 201132149

ESPA�A

Fecha de presentación de la solicitud: 30.12.2011

Fecha de prioridad:

INFORME SOBRE EL ESTADO DE LA TECNICA

51 Int. Cl. : G06Q10/00 (2012.01) G06Q30/00 (2012.01)

DOCUMENTOS RELEVANTES

Categor�a

56 Documentos citados Reivindicaciones afectadas

X

US 2003040944 A1 (HILEMAN) 27.02.2003, 1-8

p�rrafos [0021-0038]; figuras 1-4.

X

FR 2945364 A1 (GOODKAP) 12.11.2010, 1-8

p�gina 12, línea 24 – página 14, línea 19; página 15, líneas 10-26; figuras 1,3.

A

US 2006190276 A1 (WILLIAMSON) 24.08.2006, 1-8

p�rrafos [0017-0044]; figuras.

A

WO 2009148298 A1 (ERICSSON TELEFON AB L M) 10.12.2009, 1-8

p�gina 5, línea 17 – página 15, línea 24; figuras 1-6.

A

US 2009234658 A1 (GREENWELL et al.) 17.09.2009, 1-8

p�rrafos [0019-0031]; figuras.

A

WO 2008050217 A1 (RIZZI GAETANO) 02.05.2008, 1-8

p�gina 3, línea 5 – página 7, línea 31; figuras 1,2.

Categor�a de los documentos citados X: de particular relevancia Y: de particular relevancia combinado con otro/s de la misma categoría A: refleja el estado de la técnica O: referido a divulgación no escrita P: publicado entre la fecha de prioridad y la de presentación de la solicitud E: documento anterior, pero publicado después de la fecha de presentación de la solicitud

El presente informe ha sido realizado • para todas las reivindicaciones • para las reivindicaciones n�:

Fecha de realización del informe 25.08.2013

Examinador P. Pérez Fernández Página 1/4

INFORME DEL ESTADO DE LA TÉCNICA

N� de solicitud: 201132149

Documentaci�n mínima buscada (sistema de clasificación seguido de los símbolos de clasificación) G06Q Bases de datos electrónicas consultadas durante la búsqueda (nombre de la base de datos y, si es posible, términos de

b�squeda utilizados) INVENES, EPODOC, WPI, PAJ

Informe del Estado de la Técnica Página 2/4

OPINI�N ESCRITA

N� de solicitud: 201132149

Fecha de Realización de la Opinión Escrita: 25.08.2013

Declaraci�n

Novedad (Art. 6.1 LP 11/1986)

Reivindicaciones 6 Reivindicaciones 1-5,7,8 SI NO

Actividad inventiva (Art. 8.1 LP11/1986)

Reivindicaciones Reivindicaciones 6 SI NO

Se considera que la solicitud cumple con el requisito de aplicación industrial. Este requisito fue evaluado durante la fase de examen formal y técnico de la solicitud (Artículo 31.2 Ley 11/1986).

Base de la Opinión.-

La presente opinión se ha realizado sobre la base de la solicitud de patente tal y como se publica.

Informe del Estado de la Técnica Página 3/4

OPINI�N ESCRITA

N� de solicitud: 201132149

1. Documentos considerados.-

A continuación se relacionan los documentos pertenecientes al estado de la técnica tomados en consideración para la realización de esta opinión.

Documento

Número Publicación o Identificación Fecha Publicación

D01

US 2003040944 A1 (HILEMAN) 27.02.2003
2. Declaración motivada según los artículos 29.6 y 29.7 del Reglamento de ejecución de la Ley 11/1986, de 20 de marzo, de Patentes sobre la novedad y la actividad inventiva; citas y explicaciones en apoyo de esta declaración

Falta de Novedad

Las características técnicas del documento en estudio residen exclusivamente en la existencia de: -un servidor, y -la conexión por vía telem�tica de una pluralidad de conductores y pasajeros

Reivindicaci�n n� 1

Se establece el documento D01 como el más próximo del Estado de la Técnica. Dicho documento D01 hace referencia a “un sistema de transporte por demanda” y contiene: -un servidor (22) (ver párrafo 0022). -agentes que demandan el servicio (pasajeros) (32) (ver párrafo 0024; figura 1). -agentes que ofrecen el servicio (vehículos (40) (ver párrafo 0021; figura 1). -El pasajero (32) hace peticiones de transporte y peticiones de opciones de transporte al servidor (22) (ver párrafo 0028; figura 2). -El servidor evalúa las peticiones de transporte del usuario y determina las opciones de transporte y las guarda en memoria (ver párrafo 0028; figura 2). -El servidor (22) hace una búsqueda de identidades entre los trayectos del conductor (40) y las peticiones de los pasajeros

(32) (ver párrafo 0030; figura 3). -La comunicación entre conductores (40) y pasajeros (32) se realiza mediante canales de comunicación inalámbricos (60). Dicho servidor (22) est� en comunicación con fuentes de información (24) mediante internet (26) (ver párrafo 0023; figura 1). El objeto de la invención recogido en la reivindicación n�1 deriva directamente y sin ningún equívoco del documento D01. Por tanto, la reivindicación n�1 carece de Novedad (Art 6.1 LP).

Reivindicaci�n n�2

Las características de la reivindicación n�2 aparecen ya en el documento D01 (ver párrafo 0029). Por consiguiente, la reivindicación n� 2 carece de Novedad (Art 6.1 LP).

Reivindicaci�n n�3

En objeto de la reivindicación n� 3 est� contenido en el documento D01 (ver párrafo 0032; figura 2). En consecuencia, la reivindicación n� 3 carece de Novedad (Art 6.1 LP).

Reivindicaci�n n� 4

Las características de la reivindicación n�4 aparecen ya en el documento D01 (ver párrafo 0028; figura 2). Por lo tanto, la reivindicación n�4 carece de Novedad (Art 6.1 LP).

Reivindicaci�n n�5

El objeto de la reivindicación n�5 est� contenido en el documento D01 (ver párrafo 0023; figura 1). Por consiguiente, la reivindicación n� 5 carece de Novedad (Art 6.1 LP).

Reivindicaci�n n� 7

Las características de la reivindicación n�7 aparecen ya en el documento D01 (ver párrafo 0034; figura 3). En consecuencia, la reivindicación n� 7 carece de Novedad (Art 6.1 LP).

Reivindicaci�n n�8

Un dispositivo electrónico configurado como servidor, es decir, un servidor aparece ya en D01 (ver párrafos 0021,0022; figura 1). Por lo tanto, la reivindicación n� 8 carece también de Novedad (Art 6.1 LP).

Falta de Actividad Inventiva

Reivindicaci�n n� 6

Resulta obvio para el experto en la materia la generación de un calendario con información asociada al mismo. Por consiguiente, la reivindicación n� 6 carece de Actividad Inventiva (Art 8 LP).

Informe del Estado de la Técnica Página 4/4