ES2882885T3 - Integración eficaz de comunicación de unidad principal - Google Patents

Integración eficaz de comunicación de unidad principal Download PDF

Info

Publication number
ES2882885T3
ES2882885T3 ES13836234T ES13836234T ES2882885T3 ES 2882885 T3 ES2882885 T3 ES 2882885T3 ES 13836234 T ES13836234 T ES 13836234T ES 13836234 T ES13836234 T ES 13836234T ES 2882885 T3 ES2882885 T3 ES 2882885T3
Authority
ES
Spain
Prior art keywords
application
mobile device
vehicle
main unit
software
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.)
Active
Application number
ES13836234T
Other languages
English (en)
Inventor
Mike O'meara
Sagar Pawar
Leon Hong
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Airbiquity Inc
Original Assignee
Airbiquity Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Airbiquity Inc filed Critical Airbiquity Inc
Application granted granted Critical
Publication of ES2882885T3 publication Critical patent/ES2882885T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/48—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for in-vehicle communication
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34—Route searching; Route guidance
    • G01C21/36—Input/output arrangements for on-board computers
    • G01C21/3605—Destination input or retrieval
    • G01C21/362—Destination input or retrieval received from an external device or application, e.g. PDA, mobile phone or calendar application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/60—Substation equipment, e.g. for use by subscribers including speech amplifiers
    • H04M1/6033—Substation equipment, e.g. for use by subscribers including speech amplifiers for providing handsfree use or a loudspeaker mode in telephone sets
    • H04M1/6041—Portable telephones adapted for handsfree use
    • H04M1/6075—Portable telephones adapted for handsfree use adapted for handsfree use in a vehicle
    • H04M1/6083—Portable telephones adapted for handsfree use adapted for handsfree use in a vehicle by interfacing with the vehicle audio system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks
    • H04W84/22—Self-organising networks, e.g. ad-hoc networks or sensor networks with access to wired networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices
    • H04W88/182—Network node acting on behalf of an other network entity, e.g. proxy

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Telephone Function (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Information Transfer Between Computers (AREA)
  • Traffic Control Systems (AREA)

Abstract

Un procedimiento, realizado por un sistema que comprende un dispositivo móvil y un vehículo de motor, comprendiendo el procedimiento: acoplar un dispositivo móvil (20) y una interfaz de usuario alimentada por el vehículo de motor; recibir (2310), en el dispositivo móvil, una solicitud para que la interfaz de usuario utilice un recurso del dispositivo móvil; caracterizado por: determinar (2313), por el dispositivo móvil, en base a un identificador asociado con un destino indicado por la solicitud, si se autoriza la solicitud; y en respuesta a la determinación de autorizar la solicitud, utilizar un proxy del dispositivo móvil para establecer una conexión con el destino, en el que la interfaz de usuario y el destino utilizan seguridad de nivel de transporte para el intercambio de datos sobre la conexión (2322).

Description

DESCRIPCIÓN
Integración eficaz de comunicación de unidad principal
Antecedentes de la invención
Un vehículo de motor puede estar equipado con una "unidad principal" que tiene una interfaz de usuario. La interfaz de usuario puede incluir diversos componentes de recursos tal como una pantalla, altavoces, un micrófono, una pantalla táctil y/o un teclado, etc.
Los teléfonos inteligentes u otros teléfonos móviles (también denominados terminales) pueden descargar diversos programas de aplicación ("aplicaciones") que funcionan en el teléfono. Un usuario puede utilizar una interfaz de usuario del teléfono para controlar la aplicación y/o utilizar la aplicación de alguna manera (tal como ver la pantalla visual o escuchar la salida de audio). La extensión de las aplicaciones del teléfono móvil a la unidad central se ha convertido en una función muy popular que ofrecen diversos proveedores de servicios y fabricantes de vehículos. Como resultado, el usuario puede aprovechar los mejores componentes de la interfaz de usuario que ofrece la unidad principal (por ejemplo, una pantalla más grande y una salida de audio de mayor calidad). Es deseable proporcionar un mecanismo para controlar, gestionar y permitir la extensión de las aplicaciones de telefonía móvil a una unidad central del vehículo.
El documento US 2011/0093136 A1 se refiere a un dispositivo de red que almacena una asignación de los modos de operación de la aplicación a las condiciones del vehículo, tal como una primera condición del vehículo alimentado pero no en movimiento y una segunda condición del vehículo en movimiento. El dispositivo de red recibe una solicitud transmitida de forma inalámbrica para que una aplicación particular utilice una interfaz alimentada por el vehículo. El dispositivo de red compara un identificador de aplicación especificado por la solicitud recibida con la asignación. A continuación, el dispositivo de red identifica una parte de la interfaz del vehículo de acuerdo con la comparación y envía señales al software de control del vehículo para que conceda a la aplicación particular el acceso sólo a la parte identificada de la propia interfaz del vehículo. La aplicación puede residir en el dispositivo móvil y utilizar la interfaz del vehículo como una interfaz extendida, o la aplicación puede residir en el vehículo.
El documento US 2007/0155384 A1 se refiere a procedimientos y aparatos para controlar el acceso celular a servicios de datos desde un dispositivo móvil, tal como un teléfono celular o una PDA. La red inalámbrica supervisa el tráfico IP hacia y desde el dispositivo móvil. Los intentos de acceso a un servicio de datos se comprueban para determinar si el acceso solicitado está autorizado. El acceso al servicio de datos está sujeto a la autorización. El acceso al dispositivo móvil desde fuentes externas también está restringido.
El documento US 2007/0005206 A1 se refiere a un sistema de automoción que proporciona una interfaz de usuario integrada para funciones de control y comunicación en un automóvil u otro tipo de vehículo. La interfaz de usuario admite interacciones por voz, así como otros modos de interacción, tal como las interacciones manuales mediante controles tal como los montados en el tablero o en el volante. El sistema también incluye interfaces para dispositivos en el vehículo, tal como interfaces inalámbricas para dispositivos móviles que se introducen en el vehículo. El sistema también proporciona interfaces a fuentes de información, tal como un servidor remoto, por ejemplo, para acceder a la información.
Sumario de la invención
Los aspectos de la invención se exponen en las reivindicaciones. A continuación se presenta un resumen de la invención con el fin de proporcionar una comprensión básica de algunos de sus aspectos. Este resumen no pretende identificar los elementos clave/críticos de la invención ni delimitar su alcance de. Su único propósito es presentar algunos conceptos de la invención de forma simplificada como preludio a la descripción más detallada que se presenta más adelante. Las realizaciones que no entran en el ámbito de las reivindicaciones deben interpretarse como ejemplos útiles para la comprensión de la invención.
En un ejemplo, un dispositivo de red almacena una asignación de los modos de operación de la aplicación a las condiciones del vehículo, tal como una primera condición del vehículo alimentado pero no en movimiento y una segunda condición del vehículo en movimiento. El dispositivo de red recibe una solicitud transmitida de forma inalámbrica (enviada por un transmisor inalámbrico del vehículo o de un dispositivo móvil acoplado al vehículo) para que una aplicación particular utilice una interfaz alimentada por el vehículo. El dispositivo de red compara un identificador de aplicación especificado por la solicitud recibida con la asignación. A continuación, el dispositivo de red identifica una parte de la interfaz del vehículo de acuerdo con la comparación y envía señales al software de control del vehículo para que conceda a la aplicación particular el acceso sólo a la parte identificada de la interfaz del vehículo. La aplicación puede residir en el dispositivo móvil y utilizar la interfaz del vehículo como una interfaz extendida, o la aplicación puede residir en el propio vehículo.
En un ejemplo, un dispositivo de procesamiento envía, a un dispositivo de red remoto, una solicitud para que una aplicación de un dispositivo móvil utilice un recurso de una unidad principal del vehículo, la solicitud incluye un primer perfil de la unidad principal del vehículo y un segundo perfil del dispositivo móvil. En respuesta al envío de la solicitud, el dispositivo de procesamiento recibe una instrucción del dispositivo de red remoto, la instrucción a ser ejecutada por el software integrado de la unidad principal del vehículo para permitir que la aplicación utilice un recurso de la unidad principal del vehículo.
En un ejemplo, el software integrado comprende una plantilla de aplicación de Interfaz Hombre-Máquina (HMI) que incluye una pluralidad de pantallas HMI. En un ejemplo, la aplicación HMI de plantilla funciona sin un componente de interpretación.
En un ejemplo, el dispositivo móvil puede estar configurado para determinar si autoriza una solicitud para que la unidad principal del vehículo utilice un recurso del dispositivo móvil. El dispositivo móvil puede estar configurado para utilizar un proxy del dispositivo móvil para establecer una conexión con un destino en respuesta a la determinación de autorizar la solicitud.
Los aspectos y ventajas adicionales de esta invención serán evidentes a partir de la siguiente descripción detallada de las realizaciones preferentes, que procede con referencia a los dibujos adjuntos.
Breve descripción de los dibujos
La FIG. 1 ilustra un sistema para controlar el uso de una unidad principal como interfaz extendida para una aplicación telefónica de manera segura e inteligente.
La FIG. 2A ilustra un diagrama de flujo que muestra el funcionamiento del software 32 de la FIG. 1.
La FIG. 2B ilustra un diagrama de flujo que muestra un esquema de contención que puede ser utilizado por el software 32 de la FIG. 1.
La FIG. 3 ilustra un diagrama de flujo que muestra el funcionamiento del software 30A-B de la FIG. 1. La FIG. 4 ilustra un sistema para seleccionar y distribuir aplicaciones a un vehículo de forma segura e inteligente.
La FIG. 5 ilustra un diagrama de flujo que muestra el funcionamiento del software de la FIG. 4.
La FIG. 6 ilustra más detalles del sistema mostrado en las FIGS. 4-5.
La FIG. 7 ilustra un sistema para seleccionar y distribuir aplicaciones a un vehículo de forma segura e inteligente de acuerdo con las preferencias del usuario.
La FIG. 8 ilustra un diagrama de flujo que muestra el funcionamiento del software de la FIG. 7.
La FIG. 9 ilustra más detalles del sistema mostrado en las FIGS. 7-8.
La FIG. 10 ilustra un sistema para seleccionar una interfaz gráfica de la unidad principal de acuerdo con una configuración de la unidad principal.
La FIG. 11 ilustra un sistema para generar y enviar aprobaciones informáticas remotas a la unidad principal. La FIG. 12 ilustra un sistema para enviar actualizaciones de la interfaz gráfica de usuario a la unidad principal en respuesta al dispositivo móvil que genera una solicitud de una nueva aplicación o al portal web del usuario que selecciona una nueva aplicación.
La FIG. 13A ilustra un diagrama de flujo que muestra el funcionamiento previo de un esquema de control parental.
La FIG. 13B ilustra un diagrama de flujo que muestra el funcionamiento del esquema de control parental. La FIG. 14 ilustra un sistema para operar una unidad principal del vehículo tal como una interfaz extendida para un dispositivo móvil.
La FIG. 15 ilustra un diagrama de señalización que muestra un ejemplo de las operaciones que pueden realizar el servidor, la unidad principal del vehículo y el dispositivo móvil de la FIG. 14.
La FIG. 16 ilustra un sistema para extender una aplicación de usuario de teléfono móvil para utilizar una HMI de una unidad principal de vehículo de acuerdo con una realización de la presente divulgación.
La FIG. 17 es un diagrama de bloques funcional que ilustra un ejemplo de componentes de software contenidos en una aplicación de proxy de aplicación de teléfono (HAP).
La FIG. 18 es un diagrama simplificado que ilustra el flujo de datos entre un programa de aplicación de usuario y una HMI de la unidad principal del vehículo a través de una aplicación hAp integrada.
La FIG. 19 ilustra un diagrama de mensajería o señalización que muestra un ejemplo de mensajería entre componentes de software para procesar un evento recibido de una HMI de la unidad principal en relación con la ejecución de una aplicación de usuario en un teléfono móvil.
La FIG. 20 ilustra un diagrama de mensajería o señalización que muestra un ejemplo de mensajería entre componentes de software para procesar un mensaje recibido de una aplicación de usuario que se ejecuta en un teléfono móvil y, si es necesario, generar un mensaje de actualización a una HMI en una unidad principal.
La FIG. 21 ilustra un ejemplo de unidad principal de vehículo con una HMI que incluye una pantalla de visualización genérica.
La FIG. 22 ilustra un sistema para la integración eficiente de la comunicación de la unidad central.
La FIG. 23 es un diagrama de comunicación simplificado que ilustra una aplicación para teléfonos inteligentes que permite el intercambio de datos entre un sistema de infoentretenimiento para automóviles (IVI) y un backend (servidor remoto) que utiliza el protocolo SOCKS Proxy (SOCKet Secure).
La FIG. 24 es un diagrama de comunicación simplificado que ilustra una aplicación de smartphone que proporciona una funcionalidad de servidor proxy transparente para permitir el intercambio de datos entre un IVI y un backend (servidor remoto).
La FIG. 25 es un diagrama de comunicación simplificado que ilustra una aplicación de smartphone que permite el intercambio de datos entre un IVI de automóvil y un backend (servidor remoto) utilizando el encadenamiento de protocolos SOCKS Proxy.
La FIG. 26 es un diagrama de comunicación simplificado que ilustra una aplicación de smartphone que proporciona una funcionalidad de servidor proxy transparente para permitir el intercambio de datos entre un IVI y un backend (servidor remoto) utilizando el encadenamiento proxy transparente.
Descripción detallada de las realizaciones preferentes
En un ejemplo, un usuario acopla un teléfono a la unidad principal de un vehículo de motor utilizando una conexión por cable o inalámbrica con el fin de utilizar la unidad principal como una interfaz extendida para el teléfono. El usuario puede estar autorizado a controlar una aplicación en el teléfono utilizando la interfaz de la unidad principal, en función de una determinación a través de un servidor remoto, como se describe en el párrafo siguiente. Del mismo modo, se puede permitir al usuario ver o escuchar una salida de la aplicación a través de la interfaz de la unidad principal, en función de una determinación a través de un servidor remoto, como se describe en el siguiente párrafo.
El novedoso software de control del cliente en el teléfono y la unidad principal interactúa con el novedoso software de control del servidor en un servidor remoto a través de una conexión inalámbrica que se extiende desde el teléfono. El software de control del cliente identifica una aplicación telefónica para utilizar la unidad principal tal como una interfaz extendida.
El software de control del servidor compara la aplicación telefónica identificada con una o más bases de datos accesibles por el servidor remoto. En base a la comparación, el software de control del servidor determina si la aplicación identificada puede utilizar la unidad principal como interfaz extendida y, en caso afirmativo, qué componentes de la interfaz de la unidad principal podrán ser utilizados por la aplicación. El software de control del servidor indica al software de control del cliente que controle el teléfono y la unidad principal de acuerdo con la determinación. De este modo, cualquier utilización de la unidad principal como interfaz ampliada puede controlarse de forma segura e inteligente.
La FIG. 1 ilustra un sistema para controlar el uso de una unidad principal como interfaz extendida para una aplicación telefónica de manera segura e inteligente.
El sistema 100 incluye los programas informáticos 30A y 30B configurados, respectivamente, en un teléfono móvil 20 (u otro dispositivo móvil) y en la unidad principal 21 (u otra interfaz alimentada por un vehículo de motor, tal como una interfaz de usuario integrada en el volante o una interfaz de usuario integrada en el respaldo del asiento). El software 30A y 30B interactúa con el software 32 configurado en un servidor remoto 22 para regular y controlar cuándo y cómo las aplicaciones 40 que operan en el teléfono 20 acceden a los recursos de E/S 1-4 de la unidad principal 21.
La FIG. 2A ilustra un diagrama de flujo que muestra el funcionamiento del software 32 de la FIG. 1.
En el bloque 201, el software 32 recibe una solicitud para que una aplicación particular 40 del teléfono 20 utilice la interfaz (incluyendo los recursos de entrada 24 1-2 y los recursos de salida 25 3-4) de la unidad principal 21. La solicitud incluye un identificador de usuario correspondiente al usuario del vehículo de motor y/o de la unidad principal 21, un identificador de aplicación correspondiente a la aplicación particular 40, e información sobre el estado del vehículo. El identificador del usuario puede ser un identificador proporcionado por el usuario cuando el software de control 30A se activó por primera vez en el teléfono móvil 100, el número de teléfono del usuario, etc.
En el bloque 202, el software 32 autentifica al usuario. Esto puede incluir la determinación de si el usuario identificado por el identificador de usuario coincide con una base de datos 11 de abonados para el servicio de ampliación de la interfaz del teléfono 20 mediante la unidad principal 21. Si el usuario no se autentifica en el diamante 203, en el bloque 204A el software 32 indica al software 30A/B que bloquee el acceso de la aplicación 40 a la unidad principal 21. Debe comprenderse que el sistema 100 puede configurarse para que el bloque 202 sea opcional.
De lo contrario, si el usuario está autenticado, en el bloque 204B el software 32 autentifica la aplicación 40 comparando el identificador de la aplicación con una lista 12 de aplicaciones (también denominada lista blanca). Esta lista 12 puede ser comparada por el número de versión de manera tal que una versión particular de una aplicación 40 puede ser identificada en la lista mientras que una versión diferente es excluida. Si la aplicación particular 40 (o la versión particular) no está en la lista 12 en el diamante 205, entonces en el bloque 204A el software 32 indica al software 30A-B que bloquee el acceso de la aplicación 40 a la unidad principal 21.
De lo contrario, si la aplicación 40 está autentificada, entonces en el bloque 206 el software 32 compara el identificador de la aplicación y la información del estado actual del vehículo con una asignación 15 de los modos de operación de la aplicación. Como se muestra, la asignación 15 puede tener una entrada 17 para cada aplicación 40 de la lista 12. Cada entrada 17 incluye una asignación particularizada para la aplicación 40 correspondiente. Por ejemplo, una entrada 17 para la aplicación A asigna el estado del vehículo "vehículo en movimiento < que X" a los recursos 1,2 y 4 (es decir, a la aplicación A se le permitirá acceder sólo a la pantalla 1, al altavoz 2 y al micrófono 4 bajo esta condición de vehículo) mientras que la entrada 17 para la aplicación C asigna el estado del vehículo "vehículo en movimiento < que X" sólo a los recursos 2 y 4 (es decir, a la aplicación C se le permitirá acceder al altavoz 2 y al micrófono 4). Un ejemplo del mundo real puede ser una aplicación de navegación A y una aplicación de videojuego C, en la que incluso cuando un pasajero está presente, el sistema 100 no permitirá que la aplicación de videojuego C se muestre en la pantalla de la unidad principal 21, ya que se considera que es una distracción excesiva para el conductor, mientras que la aplicación de navegación A puede mostrarse en la pantalla de la unidad principal 21. Otra aplicación del mundo real puede ser un vehículo con una pluralidad de interfaces, tal como una unidad principal y una pantalla fijada al respaldo de un asiento. Una aplicación puede tener acceso a la pantalla del asiento trasero en condiciones en las que la misma aplicación no tendría acceso a la unidad principal.
Debe comprenderse que, en otros ejemplos, la asignación 15 puede almacenarse en el teléfono móvil 20. En este caso, la comparación descrita en el párrafo anterior puede ser realizada por el software de control 30A. En este caso, el software de control 30A comprueba el estado actual del vehículo en comunicación con la unidad principal 21.
En el bloque 207, el software 32 identifica un conjunto de algunos o todos los recursos de E/S de la unidad principal 21 de acuerdo con la comparación. En el bloque 208, el software 32 indica al software remoto proporcionar a la aplicación particular 40 acceso sólo a los recursos de E/S 1-4 del conjunto identificado. En un ejemplo, dicha señalización puede incluir el control del software 30A en el teléfono móvil 20 para que todas las solicitudes de acceso enviadas desde el teléfono móvil 20 se ajusten al conjunto identificado de los recursos de E/S. En otro ejemplo, dicha señalización puede incluir el control del software 30B en la unidad principal 21 para bloquear las solicitudes de acceso enviadas desde el teléfono móvil 20 de cualquier manera, como por ejemplo, simplemente inhabilitando los recursos de E/S en la unidad principal 21. En otros ejemplos, dicha señalización puede incluir el control tanto del software 30A como del software 30B.
La FIG. 2B ilustra un diagrama de flujo que muestra un esquema de contención que puede ser utilizado por el software 30B de la FIG. 1. Se puede utilizar un esquema de contención además del esquema mostrado en la FIG. 2A.
En el bloque 209, el software 30B determina si alguno de los recursos de E/S del conjunto identificado está actualmente en uso. Si no hay ninguno en uso en el diamante 210, entonces en el bloque 211A el software 30B proporciona a la aplicación particular acceso sólo a los recursos de E/S del conjunto identificado.
De lo contrario, si al menos uno de los recursos del conjunto está en uso, entonces en el bloque 211B el software 30B identifica una clasificación por recurso 13 de las aplicaciones para cada uno de los recursos en uso del conjunto identificado. Esto se muestra en la FIG. 1 en la cual hay una clasificación 13 para cada recurso 1-4. En el bloque 212, el software 30B compara el identificador de la aplicación con las clasificaciones por recursos 13 para determinar si la aplicación 40 tiene prioridad para cualquiera de los recursos en uso del subconjunto identificado (que puede realizarse mediante señalización ya que la clasificación 13 se muestra en el servidor remoto o la clasificación puede haber sido enviada a la interfaz del vehículo en un proceso anterior). Esta comparación indica si la aplicación que actualmente utiliza un determinado recurso en uso se considera más o menos prioritaria que la aplicación solicitante de ese recurso en uso. En el bloque 213, el software 30B proporciona a la aplicación particular 40 acceso sólo a aquellos de los recursos de E/S 1-4 del conjunto identificado que tampoco están actualmente en uso o están en uso por una aplicación de menor prioridad.
La FIG. 3 ilustra un diagrama de flujo que muestra el funcionamiento del software 30A-B de la FIG. 1.
En el bloque 301, el software 30A-B envía una solicitud para que una aplicación particular 40 del teléfono 20 utilice la interfaz de la unidad principal 21. En el bloque 302, el software 30A-B recibe nuevamente una señal que indica si la aplicación 40 está autorizada a acceder a la unidad principal 21 en este momento, y si es así, una identificación de qué recursos 1-4 pueden ser utilizados. Si la aplicación 40 no está autorizada en el diamante 303, entonces en el bloque 304A el software 30A-B emite una notificación de que la aplicación 40 no está autorizada a acceder a la unidad principal. Esta notificación puede ser emitida por el teléfono móvil 20 o por la unidad principal 21, o por ambos.
De lo contrario, si la aplicación 40 se autoriza en el diamante 303, entonces en el bloque 304B el software 30A-B controla el teléfono móvil 20 y la unidad principal 21 para hacer que la aplicación 40 se extienda a los recursos identificados. Si sólo se utiliza un subconjunto de recursos posibles para la aplicación 40 (de la asignación respectiva 17) debido a un conflicto, el software 30A-B puede generar una notificación para alertar al conductor sobre la suspensión de la aplicación de menor prioridad antes de activar la aplicación de mayor prioridad. En otro ejemplo, si los recursos están siendo utilizados por una aplicación de menor prioridad, el software 30A-B puede suspender/terminar automáticamente la aplicación de menor prioridad y permitir que la aplicación de mayor prioridad se active utilizando los recursos necesarios.
Si se determina que la aplicación 40 puede extenderse a la unidad principal 21, el servidor 22 puede descargar el correspondiente software de "panel de control" a la unidad principal para controlar la aplicación 40. Al tener que descargar este software en la unidad principal 21 en función de la aplicación solicitada, un proveedor de servicios puede personalizar y actualizar el "panel de control" en consecuencia cuando haya nuevas aplicaciones o se actualicen las existentes. La unidad central puede tener un renderizador de código web para mostrar el software del "panel de control".
Con referencia nuevamente a la FIG. 1, el software 30A-B interactúa con el software 32 a través de una conexión inalámbrica que se extiende desde el teléfono 20. Esta conexión inalámbrica puede utilizar una conexión de paquetes de datos (incluyendo, pero sin limitación, GPRS, EDGE, EVDO, UTMS, WiMAX, WiFi, etc.), Servicio de Mensajes Cortos (SMS), o módem de señalización en banda en el teléfono móvil 20 y el servidor remoto 22 como se describe en las Patentes Estadounidenses 6.144.3366.690.681y 6.493.338.
Continuando con la FIG. 1, se observa que el teléfono móvil 20 puede acoplarse a la unidad principal 21 mediante una conexión como la USB, Bluetooth o WiFi. Sin embargo, estos son sólo ejemplos, y en otros casos puede ser adecuada una conexión y/o un protocolo diferente para utilizar la interfaz de la unidad principal 21 para la aplicación 40 del teléfono 20.
Debe comprenderse que la asignación 15 puede tener cualquier estado del vehículo y que los cuatro ejemplos ilustrados son simplemente algunos ejemplos. Por ejemplo, otro estado del vehículo puede ser que el vehículo se mueve a más de una velocidad "X" Y hay un pasajero presente.
Debe comprenderse que la unidad principal 21 puede incluir menos de todos los recursos de ejemplo mostrados, u otros recursos que no se muestran. Por ejemplo, otro posible componente de recursos de E/S es un componente de texto a voz.
En el ejemplo ilustrado, a una primera aplicación se le puede permitir el acceso a un primer subconjunto de los recursos realmente presentes en la unidad principal 21, en base a una decisión inteligente del sistema 100, mientras que a una segunda aplicación diferente se le puede permitir el acceso a un segundo subconjunto de los recursos, o incluso a todos los recursos.
Debe comprenderse que las aplicaciones 40 pueden ser clasificadas "por recurso" como se ilustra o puede haber una única clasificación que incluya todas las aplicaciones 40. El sistema 100 se implementa con la clasificación "por recurso" como se muestra, pero los conceptos descritos en la presente memoria pueden implementarse en otro sistema que clasifique las aplicaciones independientemente del recurso.
La FIG. 4 ilustra un sistema para seleccionar y distribuir aplicaciones a un vehículo de forma segura e inteligente.
Una diferencia entre el sistema previamente discutido de la FIG. 1 y el sistema de la FIG. 4 es el sitio de instalación de las aplicaciones. Mientras que las aplicaciones A-C del sistema 100 de la FIG. 1 se instalan y funcionan en el teléfono móvil 20 (utilizando la unidad principal 21 u otra interfaz alimentada por el vehículo como interfaz extendida), las aplicaciones J-L del sistema 200 de la FIG. 4 están instalados en la unidad principal 221 u otro componente alimentado por el vehículo. En el sistema 200 de la FIG. 4, el software 230-232 permite a un proveedor seleccionar las aplicaciones que pueden instalarse en la unidad principal 221 y controlar la distribución de las aplicaciones seleccionadas en el vehículo.
Antes de discutir los detalles del sistema 200 en los siguientes párrafos, debe ser evidente que las estructuras y funciones del sistema 100 descritas en las FIGS. 1-3 pueden combinarse con las estructuras y funciones del sistema 200 (FIGS. 4-6) en un único sistema. Por ejemplo, un mismo sistema puede incluir algunas aplicaciones instaladas en un teléfono móvil que utilice una interfaz de un vehículo como interfaz extendida y algunas aplicaciones instaladas en un componente del vehículo.
La FIG. 5 ilustra un diagrama de flujo que muestra el funcionamiento del software de la FIG. 4.
En el bloque 501, en respuesta al encendido del vehículo, el software de control 230 envía una señal 244 al servidor 222 indicando el encendido del vehículo. La señal 244 puede enviarse a través de una conexión local, como una conexión USB o Bluetooth, para ser retransmitida por el dispositivo móvil 220 a través de una red de telecomunicaciones inalámbrica.
En el bloque 502, el software 232 comprueba un directorio de descarga 239 (a menudo denominado "caja de arena") asociado al vehículo para determinar si hay alguna aplicación que se pueda descargar en el vehículo. Un esquema para seleccionar inteligentemente las aplicaciones que están presentes en el directorio de descargas 239 se discutirá en detalle más adelante con referencia a la FIG. 6.
Si la comprobación realizada por el software 232 indica que el directorio de descarga 239 incluye al menos una aplicación, el proceso continúa. Por ahora, cabe suponer a efectos ilustrativos que el directorio de descarga 239 incluye las aplicaciones 240 (J-L). En consecuencia, en el bloque 503, el software 232 genera y envía la señalización 245 para hacer que el software de la pasarela IP 231 del teléfono móvil 220 funcione como una pasarela IP para reenviar aplicaciones a la unidad principal 221. En un ejemplo, la señalización 245 incluye comunicaciones para cargar dinámicamente el teléfono móvil 220 con el software 231 en respuesta a la determinación del bloque 502 y hacer que el software 231 funcione en este para la descarga al vehículo. La señalización 245 puede no tener lugar si el teléfono móvil 220 ya está cargado con el software 231 y preparado para el funcionamiento de la pasarela IP. En otros ejemplos, la señalización 245 puede proceder del software de control 230 de la unidad principal 221 en respuesta a la detección del encendido del vehículo.
En el bloque 504, el software 232 genera y envía paquetes IP 250 para descargar las aplicaciones 240 en el vehículo. Los paquetes IP 250 son recibidos por el teléfono móvil 220 y reenviados por operación del software 231 a la unidad principal 221. En el bloque 505, el software 230 recibe los paquetes IP 230 e instala las aplicaciones 240 (J-L) en el vehículo (la instalación puede ser en componentes de la unidad principal 221 u otros componentes del vehículo).
A continuación, un usuario del vehículo puede operar las aplicaciones J-L utilizando la unidad principal 221 como interfaz. Debe comprenderse que los programas informáticos 230 y 232 pueden funcionar de acuerdo con cualquiera de los principios descritos en las FIGS. 1-3. Por ejemplo, el software 230 y 232 puede regular la utilización de los recursos de E/S de la unidad principal 221 por parte de las aplicaciones activas de acuerdo con el estado actual del vehículo. Como otro ejemplo, en sistemas en los cuales las aplicaciones están instaladas tanto en el vehículo como en un dispositivo móvil, el software 230 y 232 puede incluir todas las aplicaciones que utilizan la interfaz del vehículo en una tabla de clasificación/prioridad de aplicaciones similar a la tabla 13 (FIG. 1).
En un ejemplo, la unidad principal 221 incluye un renderizador de código web 299, por ejemplo un renderizador HTML, controlado a través del software 230. El renderizador de código web 299 está configurado para mostrar el código HTML, pero a diferencia de un navegador, no permite al usuario navegar libremente a ubicaciones web. Específicamente, el renderizador de código web 299 sólo muestra las aplicaciones permitidas por el proveedor, por ejemplo, especificadas por el servidor 222.
Debe comprenderse que el diagrama de flujo descrito anteriormente se refiere a la actualización de las aplicaciones instaladas en el vehículo. El vehículo también puede estar precargado con determinadas aplicaciones, de modo que algunas de las aplicaciones instaladas en el vehículo se descargan de acuerdo el diagrama de flujo, mientras que otras se instalan en este durante la fabricación.
Por lo tanto, en base a los principios descritos anteriormente, los vehículos pueden ser fabricados sin ninguna de las aplicaciones instaladas en el vehículo, sino que las aplicaciones pueden ser descargadas en los vehículos cuando los conductores están presentes en los mismos. Los tipos de aplicaciones que se descargan en los vehículos se rigen por las preferencias definidas en el servidor de red que proporcionan los conductores.
La FIG. 6 ilustra más detalles del sistema mostrado en las FIGS. 4-5.
Se ha explicado anteriormente que el servidor 222 incluye un directorio de descarga 239 de aplicaciones en espera de ser descargadas por vehículo. La FIG. 6 ilustra los portales web de usuario 601, 604 y 605 que pueden participar en la selección de las aplicaciones en el directorio de descarga 239 y describe un ejemplo de uso de estos portales web 601,604 y 605.
Un proveedor, tal como un OEM del vehículo, opera el portal web 601. Utilizando una interfaz como un terminal informático 625, el proveedor controla una parte de selección de aplicaciones 608 del portal web 601 con comunicaciones 650 para reunir la lista controlada 610 de aplicaciones a partir de la lista 609 de todas las aplicaciones que pueden instalarse en el vehículo. Normalmente, la generación de la lista 610 a partir de la lista 609 implica la validación de las solicitudes desde un punto de vista técnico y/o comercial del proveedor.
El proveedor también envía comunicaciones 651 para seleccionar aplicaciones de la lista controlada 610 que se instalarán en un vehículo concreto. Estas selecciones pueden basarse, por ejemplo, en una asignación de modelos de vehículos a aplicaciones. Estas selecciones 652 se introducen en el directorio de descargas 239.
En cuanto a la lista de todas las aplicaciones disponibles 609, debe comprenderse que esta lista puede estar formada por aplicaciones desarrolladas por el proveedor y/o por terceros. En el caso de terceros que proporcionan aplicaciones, el tercero utiliza la parte de presentación de la aplicación 618 del portal web 604 (que está alojado en un servidor web operado por el proveedor en un ejemplo) para presentar una aplicación 649 para ser incluida en la lista 609.
Un usuario del vehículo también puede seleccionar las aplicaciones que se incluirán en el directorio de descarga 239 utilizando un terminal informático 626, por ejemplo, utilizando cualquier dispositivo informático accesible por Internet, como el dispositivo móvil o un ordenador de escritorio. El terminal informático 626 accede a la parte de selección de aplicaciones 628 del portal web del usuario 605 (que está alojado en un servidor web operado por el proveedor en un ejemplo) para ver la lista controlada 610 de aplicaciones que pueden instalarse en su vehículo. El usuario puede entonces enviar comunicaciones 661 para seleccionar aplicaciones de la lista controlada 610 que el usuario desea instalar en su vehículo. Estas selecciones 662 se introducen en el directorio de descargas 239.
El portal web de usuario 605 también puede configurarse para permitir a un usuario eliminar aplicaciones concretas del directorio de descargas 239, por ejemplo, el usuario puede desear eliminar una de las aplicaciones seleccionadas por el proveedor 652 añadidas al directorio de descargas 239 a través del proveedor. La eliminación puede ser mediante el borrado de una aplicación ya enviada al directorio 239 o indicando que no se desea una aplicación particular antes de que dicha aplicación se añada al directorio de descargas 239.
De acuerdo con lo anterior, las aplicaciones pueden acumularse en el directorio de descarga por vehículo 239. Al encender el vehículo, estas aplicaciones pueden descargarse e instalarse en este. El directorio de descargas 239 puede entonces acumular nuevas aplicaciones hasta un próximo encendido del vehículo.
Debe comprenderse que una interfaz similar a la del portal web 605 puede mostrarse en la unidad principal del vehículo. El usuario puede entonces hacer selecciones desde dicha interfaz para seleccionar aplicaciones de la lista controlada 610. Las aplicaciones seleccionadas pueden descargarse inmediatamente en el vehículo en lugar de ponerse en el directorio de descargas cuando se hacen las selecciones desde la interfaz.
La FIG. 7 ilustra un sistema para seleccionar y distribuir aplicaciones a un vehículo de forma segura e inteligente de acuerdo con las preferencias del usuario.
Una diferencia entre el sistema previamente discutido de la FIG. 1 y el sistema de la FIG. 7 es el sitio de instalación de las aplicaciones. Mientras que las aplicaciones A-C del sistema 100 de la FIG. 1 están instaladas y funcionando en el teléfono móvil 20 (utilizando la unidad principal 21 u otra interfaz alimentada por el vehículo como interfaz extendida), las aplicaciones M-P/Q-S en el sistema 300 de la FIG. 7 están instaladas en la unidad principal 321 u otro componente alimentado por el vehículo. En el sistema 300 de la FIG. 7, el software 330-332 permite a un proveedor seleccionar las aplicaciones que pueden instalarse en la unidad principal 321 y controlar la distribución de las aplicaciones seleccionadas en el vehículo.
Antes de discutir los detalles del sistema 300 en los párrafos siguientes, debe ser evidente que las estructuras y funciones de los sistemas 100 y 200 descritos en las FIGS. 1-6 pueden combinarse con las estructuras y funciones del sistema 300 (FIGS. 7-8) en un único sistema. Por ejemplo, un mismo sistema puede incluir algunas aplicaciones instaladas en un teléfono móvil que utilice una interfaz de un vehículo como interfaz extendida y algunas aplicaciones instaladas en un componente del vehículo.
La FIG. 8 ilustra un diagrama de flujo que muestra el funcionamiento del software de la FIG. 7.
En el bloque 801, la unidad principal 321 se acopla comunicativamente a un dispositivo móvil como el teléfono móvil 320. En un ejemplo, la conexión 540 se establece mediante el emparejamiento por Bluetooth de la unidad principal 321 y el teléfono móvil 320. El emparejamiento por Bluetooth puede ser una respuesta al encendido del vehículo (lo que hace que la unidad principal se encienda y busque un dispositivo Bluetooth), aunque debe ser evidente que el emparejamiento por Bluetooth puede ser el resultado de otras circunstancias, tal como el encendido del teléfono móvil 320, el acercamiento del teléfono móvil 320 al alcance de la unidad principal 321, el reemparejamiento después de que otro dispositivo Bluetooth se desconecte de la unidad principal 321, etc. En otros ejemplos, la conexión comunicativa puede ser establecida por un usuario que conecta el teléfono móvil 320 a la unidad principal 321 mediante una conexión USB.
En el bloque 802, el software de control 330 accede a un número de teléfono del teléfono móvil 320. Debe comprenderse que los teléfonos móviles se activan con un número de teléfono concreto junto con la suscripción a un plan de llamadas, que es el número de teléfono que el software de control 330 lee del teléfono móvil 320. En un ejemplo, la señalización 542 para obtener el número de teléfono se realiza utilizando la señalización Bluetooth.
En el bloque 803, el software de control 330 envía la señalización 543 al servidor 322. La señalización 543 puede enviarse a través de una conexión local, como una conexión USB, Bluetooth o WiFi, para ser retransmitida por el dispositivo móvil 320 a través de una red de telecomunicaciones inalámbrica. El contenido de la señalización 543 puede ser similar a la señal 244 descrita con más detalle anteriormente con respecto a la FIG. 4, pero además, puede proporcionar el número de teléfono obtenido.
En el bloque 804, el software de control 332 compara el número de teléfono incluido en la señalización 543 con la asignación 350. La asignación correlaciona cada uno de una pluralidad de directorios de descarga A-B accesibles a través de esta unidad principal particular 321 con un número de teléfono particular. Por ejemplo, en la asignación se correlaciona un primer número de teléfono con el directorio de descarga A y un segundo número de teléfono con el directorio de descarga B. El software de control 332 selecciona uno de los directorios de descarga A-B en base a la comparación del número de teléfono recibido con la asignación 350.
A continuación, el software 332 comprueba el directorio de descarga A-B seleccionado para determinar si hay alguna aplicación almacenada actualmente en el directorio seleccionado. Un esquema para seleccionar inteligentemente las aplicaciones que están presentes en los directorios de descarga A-B se discutirá en detalle más adelante con referencia a la FIG. 9. Por ahora, cabe suponer a efectos ilustrativos que los directorios de descarga 339A y 339B incluyen actualmente las aplicaciones 340A (M-P) y 340B (Q-S), respectivamente, además de las configuraciones de frontend de la unidad principal 369A y 369B.
Como se ha señalado brevemente en el párrafo anterior, los directorios de descarga A-B incluyen las configuraciones de frontend de la unidad principal A-B, respectivamente, además de las aplicaciones 340A y 340b . Las configuraciones A-B pueden almacenarse como código HTML u otro código web compatible con el renderizador de código web del 399. Dependiendo de cuál de las configuraciones de frontend A-B se descargue en la unidad principal 321, una pantalla 380 de la unidad principal 321 mostrará una interfaz gráfica de usuario diferente. Cada uno de los diferentes archivos de código web 369A y 369B producirá una interfaz gráfica de usuario diferente cuando se muestre utilizando la pantalla 380 y el renderizador 399. Por ejemplo, cada interfaz gráfica de usuario puede tener su propia configuración personalizada por el usuario, tal como un fondo de pantalla particular seleccionado por un usuario. Un esquema para generar las diferentes configuraciones de frontend A-B se discutirá en detalle más adelante con referencia a la FIG. 9.
En el bloque 805, el software 332 genera y envía una señalización para que el software de la pasarela IP 331 del teléfono móvil 320 funcione como una pasarela IP para el reenvío de aplicaciones a la unidad principal 321, de forma similar al esquema descrito en la f Ig . 4. En un ejemplo, similar al de la FIG. 4, dicha señalización incluye comunicaciones para cargar dinámicamente el teléfono móvil 320 con el software 331 para hacer que el software 331 funcione en él para la descarga al vehículo. Esta señalización puede no ocurrir si el teléfono móvil 320 ya está cargado con el software 331 y preparado para el funcionamiento de la pasarela IP. En otros ejemplos, la señalización 345 puede originarse en el software de control 330 de la unidad principal 321 después de establecer la conexión 540.
En el bloque 806, el software 332 genera y envía paquetes IP 545 para descargar los datos de uno de los directorios seleccionados en el vehículo, por ejemplo, las aplicaciones M-P y la configuración A o las aplicaciones Q-S y la configuración B. Los paquetes IP 545 son recibidos por el teléfono móvil 320 y reenviados por operación del software 331 a la unidad principal 321. Debe comprenderse que en esta ilustración particular los paquetes IP 545 incluyen tanto aplicaciones como una configuración para la interfaz gráfica de usuario, pero en otros escenarios los paquetes IP 545 pueden contener una aplicación o una configuración. Además, debe ser evidente que, si no hay aplicaciones actualmente en el directorio de descarga seleccionado y no ha habido cambios en las configuraciones almacenadas en el directorio de descarga desde una descarga anterior, entonces los paquetes IP 545 pueden no ser enviados.
En el bloque 807, el software 330 recibe los paquetes IP 545 e instala las aplicaciones incluidas en estos en el vehículo (la instalación puede ser en componentes de la unidad principal 321 u otros componentes del vehículo). El software 330 también procesa la configuración de los paquetes IP 545 utilizando el renderizador de código web 399 para generar una interfaz gráfica de usuario particular basada en el número de teléfono detectado.
A continuación, la salida de la interfaz gráfica de usuario a través de la pantalla 380 corresponde a una de las configuraciones A-B almacenadas en el directorio de descarga seleccionado. Un usuario del vehículo puede manejar las aplicaciones instaladas M-P o Q-S utilizando la unidad principal 321 como interfaz.
Debe comprenderse que los programas informáticos 330 y 332 pueden funcionar de acuerdo con cualquiera de los principios descritos en las FIGs . 1-3. Por ejemplo, el software 330 y 332 puede regular la utilización de los recursos de E/S de la unidad principal 321 por parte de las aplicaciones activas de acuerdo con el estado actual del vehículo. Como otro ejemplo, en los sistemas en los que las aplicaciones están instaladas tanto en el vehículo como en un dispositivo móvil, el software 330 y 332 puede incluir todas las aplicaciones que utilizan la interfaz del vehículo en una tabla de clasificación/prioridad de aplicaciones similar a la tabla 13 (FIG. 1).
En el ejemplo descrito anteriormente, el software de control 330 accede a un número de teléfono del teléfono móvil 320 para identificar de forma única el teléfono móvil 320 de otros teléfonos móviles. En otros ejemplos, el software de control en la unidad principal 321 puede acceder a un valor diferente en un teléfono móvil acoplado comunicativamente para identificar de forma única el teléfono móvil de otros teléfonos móviles. Otros ejemplos de valores pueden incluir, entre otros, una dirección física del teléfono móvil. Por ejemplo, si los otros valores son direcciones físicas, la asignación incluye direcciones físicas correlacionadas con directorios de descarga.
En el ejemplo descrito anteriormente, el software de control 330 envía el identificador único accedido (número de teléfono en este ejemplo) al servidor 322. En otros ejemplos, la asignación 350 puede almacenarse en el vehículo. En tal caso, el software de control 330 identifica un directorio de descarga concreto que figura en la asignación de acuerdo con la comparación y envía un identificador que especifica la descarga particular al servidor 322. El servidor 322 puede entonces responder con paquetes IP 545 enviando datos del directorio de descarga identificado.
La FIG. 9 ilustra más detalles del sistema mostrado en las FIGS. 7-8.
Se ha explicado anteriormente que el servidor 322 incluye una pluralidad de directorios de descarga 339A-B de aplicaciones en espera de ser descargadas. La FIG. 9 ilustra el portal web de usuario 905 que puede estar involucrado en la creación de los directorios de descarga 339A-B y la selección de las aplicaciones en una base por directorio y describe un ejemplo de uso de este portal web 905.
Un usuario del vehículo puede crear una pluralidad de perfiles correspondientes al vehículo utilizando la parte de creación de perfiles 930 del portal web del usuario 905. Se puede crear un perfil para cada persona que pueda utilizar el vehículo. Un campo 927 solicita un número de teléfono único u otro identificador único de un teléfono móvil correspondiente a cada persona. El nombre de cada persona u otra información de cada persona puede reunirse con el número o los números de teléfono. Después o durante la creación del perfil, el servidor 322 crea un directorio de descarga para cada perfil y actualiza la asignación 350 para cada combinación de número/directorio. En algunos ejemplos, la porción 930 puede estar configurada para permitir a un usuario clasificar los perfiles creados de manera que, si la unidad principal puede ser acoplada a más de uno de los dispositivos móviles simultáneamente (puede depender del protocolo de conexión si esto es posible), se utilizará uno de mayor rango de los perfiles correspondientes.
Durante o después de la creación del perfil, el portal web 905 puede ser operado para seleccionar las aplicaciones que se incluirán en los directorios de descarga 339A-B utilizando un terminal informático 926, por ejemplo, utilizando cualquier dispositivo informático accesible por Internet, como el dispositivo móvil o un ordenador de escritorio. El terminal informático 926 accede a la parte de selección de aplicaciones 928 del portal web del usuario 905 (que está alojado en un servidor web operado por el proveedor en un ejemplo) para ver la lista controlada de aplicaciones que pueden instalarse en el vehículo. El usuario puede entonces enviar comunicaciones 961 para seleccionar las aplicaciones de la lista controlada que el usuario desea instalar en su vehículo en base a un directorio. Estas selecciones 962 se introducen respectivamente en los directorios de descarga 339A-B de forma individual.
El portal web de usuario 905 también puede configurarse para permitir a un usuario eliminar aplicaciones particulares de los directorios de descarga 339A-B, por ejemplo, el usuario puede desear eliminar una de las aplicaciones seleccionadas por el proveedor 952 añadidas al directorio de descarga 339A o 339B a través del proveedor en una base por directorio. La eliminación puede ser mediante el borrado de una aplicación ya enviada al directorio de descarga 339A o 339B, o indicando que no se desea una aplicación concreta antes de que dicha aplicación se añada al directorio de descarga 339A o 339B.
El portal web del usuario 905 también puede incluir una parte de personalización de la configuración de frontend 928. Esta porción 928 permite añadir nuevas configuraciones 369A-B a los directorios de descarga 339A-B, con la configuración de cada persona personalizada de acuerdo con sus peticiones. Por ejemplo, se puede añadir un primer fondo de pantalla al directorio de descarga 339A y un segundo fondo de pantalla diferente al directorio de descarga 339B. Otras personalizaciones pueden incluir botones personalizados de la interfaz gráfica, diseño personalizado de la interfaz gráfica de usuario, imágenes personalizadas, etc.
De acuerdo con lo anterior, las aplicaciones pueden ser acumuladas en los directorios de descarga por vehículo 339A-B en base a cada directorio. Cuando la unidad principal se acopla a uno de los dispositivos móviles en particular, los datos de uno de los directorios de descarga 339A-B correspondientes pueden descargarse e instalarse en el vehículo para proporcionar un conjunto de aplicaciones personalizadas y una interfaz de usuario personalizada.
Debe comprenderse que una interfaz similar a la del portal web 905 puede mostrarse en la unidad principal del vehículo. El usuario puede entonces hacer selecciones desde dicha interfaz para seleccionar aplicaciones de la lista controlada. Las aplicaciones seleccionadas pueden descargarse inmediatamente en el vehículo en lugar de ponerse en el directorio de descargas cuando se hacen las selecciones desde la interfaz.
La FIG. 10 ilustra un sistema para seleccionar una interfaz gráfica de la unidad principal de acuerdo con una configuración de la unidad principal.
El sistema 1000 incluye un servidor 1022 y una unidad principal 1021 que puede incluir componentes similares a cualquiera de los servidores y unidades principales descritos anteriormente. Debe apreciarse que el servidor 1022 y la unidad principal 1021 se comunican utilizando un dispositivo móvil (no mostrado) que está acoplado a la unidad principal 1021. La unidad principal 1021 incluye el software de control 1030 y el servidor 1022 incluye el software de control 1032.
El software 1032 identifica una configuración de la unidad principal 1021, por ejemplo, por el sondeo 1081 la unidad principal 1021 para recoger información. El software 1030 responde 1082 con información que identifica la configuración de la unidad principal 1021. La respuesta 1082 puede incluir al menos uno de los siguientes datos: una marca/modelo/año del vehículo, un código predefinido, o un listado ad hoc de la configuración de la unidad principal 1021 (tal como pantalla en color/monocromática, resolución nativa, etc.).
El software 1032 selecciona entonces entre una pluralidad de interfaces gráficas de usuario en base a la información de la unidad principal 1082. Por ejemplo, si la información de la unidad principal 1082 incluye un código predefinido, el software 1032 puede comparar el código con una asignación almacenado 1085 de códigos a interfaces gráficas de usuario Y-Z. La interfaz gráfica de usuario seleccionada corresponde a una configuración particular de la unidad principal 1021 según la información 1082. Por ejemplo, si la unidad principal 1021 tiene una pantalla monocromática, la Interfaz Gráfica de Usuario (GUI) seleccionada puede ser la interfaz Y, mientras que si la unidad principal 1021 tiene una pantalla en color, la GUI seleccionada puede ser la interfaz Z. O bien, si la unidad principal 1021 tiene una resolución nativa de un primer valor, la GUI seleccionada puede ser la interfaz Y, mientras que si la unidad principal 1021 tiene una resolución nativa de un segundo valor, la GUI seleccionada puede ser la interfaz Z. Si la marca/modelo/año del coche indica un interior de un primer diseño, por caso un motivo de lujo, la GUI seleccionada puede ser la interfaz Y, mientras que si la marca/modelo/año del coche indica un interior de un segundo diseño, digamos un motivo deportivo, la GUI seleccionada puede ser la interfaz Z.
Una vez que se ha seleccionado una interfaz gráfica de usuario, el software 1032 realiza una transferencia de paquetes IP 1045 de la interfaz gráfica de usuario seleccionada Y-Z. Debe comprenderse que la transferencia de paquetes IP 1045 puede utilizar el software de pasarela IP del teléfono móvil descrito anteriormente (no mostrado). El software 1030 instala automáticamente la interfaz gráfica de usuario recibida. La interfaz gráfica de usuario seleccionada puede reemplazar una inferencia gráfica de usuario predeterminada 1090 o una interfaz gráfica de usuario previamente descargada que resida en la unidad principal 1021 antes de la transferencia 1045.
Debe comprenderse que las configuraciones de frontend descritas anteriormente pueden aplicarse a la GUI seleccionada e instalada. Por ejemplo, se puede instalar una interfaz gráfica de usuario seleccionada en la unidad principal 1021 y, a continuación, se puede modificar su aspecto en función de una selección de interfaz personalizada según un número de teléfono del dispositivo móvil actualmente acoplado a la unidad principal 1021.
La FIG. 11 ilustra un sistema para generar y enviar aprobaciones informáticas remotas a la unidad principal.
El sistema 1100 incluye un servidor 1122 y una unidad principal 1121 que puede incluir componentes similares a cualquiera de los servidores y unidades principales descritos anteriormente. Debe apreciarse que el servidor 1122 y la unidad principal 1121 se comunican mediante un dispositivo móvil 1131. La unidad principal 1121 incluye el software de control 1130 y el servidor 1122 incluye el software de control 1132.
La unidad principal 1121 incluye un programa de visualización de escritorio remoto tal como un cliente 1148 de Virtual Network Computing (VNC®) para conectarse al servidor VNC 1149 que se ejecuta en el dispositivo móvil 1131. A modo de antecedentes, un cliente y un servidor VNC se comunican para mostrar el escritorio del servidor u otra vista actual en la pantalla del cliente. Los dispositivos de interfaz humana conectados directamente al cliente, por ejemplo, el teclado, el ratón, etc., pueden utilizarse entonces junto con la imagen mostrada para controlar de forma remota el dispositivo informático que ejecuta el servidor VNC. Si una aplicación se ejecuta en modo de pantalla completa en el dispositivo informático con el servidor VNC, el dispositivo informático con el servidor VNC controla esa aplicación (en lugar de todo el escritorio).
El software de control 1130 recibe una solicitud 1155 del dispositivo móvil 1131 que especifica una aplicación X particular (1140). El software de control 1130 identifica el identificador de la aplicación correspondiente a la solicitud 1155, ya sea extrayendo el propio identificador de la solicitud 1155 o utilizando una búsqueda basada en la información obtenida de la solicitud o de cualquier comunicación con el dispositivo móvil 1131. El software de control 1130 envía la comunicación 1156 que contiene el identificador de la aplicación.
El software de control 1132 compara el identificador de la aplicación con una tabla interna y genera una aprobación VNC 1157 para la aplicación X. La aprobación VNC 1157 especifica las condiciones particulares bajo las cuales se aprueba el VNC en conjunto para esta aplicación X. Por ejemplo, si la aplicación X es una aplicación de navegación, la aprobación 1157 puede especificar que el VNC está aprobada cuando el vehículo está detenido o en movimiento. Por el contrario, si la aplicación X es una aplicación de creación de medios, la aprobación 1157 puede especificar que el VNC está aprobado sólo cuando el vehículo está parado.
La aprobación VNC 1157 también puede especificar diferentes aprobaciones basadas en si la aplicación se está ejecutando actualmente en modo de pantalla completa o en modo de ventana. Por ejemplo, la aplicación de navegación puede ser aprobada cuando el vehículo está en movimiento, pero sólo mientras la aplicación de navegación se ejecute en el dispositivo móvil 1131 en modo de pantalla completa. Esto impedirá la funcionalidad VNC inmediatamente si el usuario cambia la aplicación de navegación al modo de ventana mientras el vehículo está en movimiento.
La aprobación VNC 1157 también puede especificar números de teléfono. Por ejemplo, se puede permitir el VNC cuando el dispositivo móvil 1131 está ejecutando una aplicación de reproducción multimedia, pero sólo si el dispositivo móvil tiene un número de teléfono determinado (esto puede utilizarse como una forma de control parental).
El software de control 1130 almacena la aprobación VNC recibida 1157 en una base de datos 1135 de aprobaciones VNC. El software de control 1130 supervisa continuamente las condiciones en función de las aprobaciones VNC almacenadas en la base de datos 1135 para generar la señal de control 1160. La señal de control 1160 controla si una vista 1161 del dispositivo móvil 1131 puede ser mostrada actualmente en una pantalla de la unidad principal 1121 por el cliente VNC 1148. La señal de control 1160 también controla si las entradas realizadas mediante una interfaz de entrada de la unidad principal 1121 se enviarán 1162 al servidor VNC 1149.
La FIG. 12 ilustra un sistema para enviar actualizaciones de la interfaz gráfica de usuario a la unidad principal en respuesta al dispositivo móvil que genera una solicitud de una nueva aplicación o al portal web del usuario que selecciona una nueva aplicación.
El sistema 1200 incluye un servidor 1222 y una unidad principal 1221 que puede incluir componentes similares a cualquiera de los servidores y unidades principales descritos anteriormente. Debe apreciarse que el servidor 1222 y la unidad principal 1221 se comunican mediante un dispositivo móvil 1231.
El servidor 1222 puede recibir una indicación de una nueva aplicación que se utilizará en el sistema 1200 en al menos dos formas diferentes (el término nueva aplicación se refiere a una aplicación que no se ha descargado previamente en la unidad principal 1221 y/o utilizado la unidad principal 1221 como una interfaz extendida). En una forma, el dispositivo móvil 1231 envía una indicación de una nueva aplicación X (1240) para utilizar la unidad principal 1221 como una interfaz extendida. Más específicamente, esta indicación es una solicitud de aprobación 1271 generada y enviada por el software de control 1230 en respuesta a la recepción de una solicitud 1270 del dispositivo móvil 1231.
Otra forma en la que el servidor 1222 puede recibir una indicación de una nueva aplicación es desde el control del portal web del usuario 1205. El portal web del usuario 1205 es similar a los portales web descritos anteriormente. Mediante una herramienta de selección de aplicaciones 1228, un usuario puede utilizar cualquier ordenador remoto para seleccionar las aplicaciones que se incluirán en un directorio de descarga correspondiente (no mostrado) para su instalación en la unidad principal. Por lo tanto, una selección recibida 1274 que incluye una nueva aplicación es otra forma de indicación de una nueva aplicación a ser utilizada en el sistema 1200.
En respuesta a la detección de dicha indicación, el software de control 1232 determina si se debe transmitir una transferencia de paquetes IP 1245 que incluya una actualización de la interfaz gráfica de usuario para la nueva aplicación X. Debe ser evidente que no se enviará dicha transferencia de paquetes IP si la nueva aplicación X no está incluida en la lista controlada de aplicaciones previamente discutida (FIG. 6). En un ejemplo, la actualización de la interfaz gráfica de usuario modifica una interfaz gráfica de usuario previamente seleccionada e instalada (FIG. 10) para añadir un icono para acceder a la nueva aplicación X. En otro ejemplo, la actualización de la interfaz gráfica de usuario incluye cualquier otra forma de actualización de una interfaz gráfica de usuario previamente seleccionada e instalada para operar la nueva aplicación X. El software de control 1230 instala automáticamente la actualización en respuesta al envío de la solicitud 1270 y/o las selecciones 1274. Debe ser evidente que la transferencia 1245 puede incluirse con una descarga de la propia aplicación en el caso de que la descarga esté esperando el encendido del vehículo en un directorio de descarga.
La FIG. 13A ilustra un diagrama de flujo que muestra el funcionamiento previo de un esquema de control parental.
En el bloque 1301, el servidor designa al menos un perfil como sujeto a control parental. Este perfil puede ser seleccionado por el titular de la cuenta, por ejemplo, marcando una selección mediante el portal web.
En el bloque 1302, el servidor recibe un inicio de sesión de un usuario designado como padre (normalmente el titular de la cuenta) para el perfil sujeto a control parental. En el bloque 1303, el servidor hace que se muestre una lista de aplicaciones asociadas al perfil sujeto a control parental mediante el portal web.
En el bloque 1304, después de mostrar la lista, el servidor recibe selecciones de la lista mostrada. El servidor puede almacenar estas selecciones en el perfil sujeto al control parental. Las selecciones pueden incluir aplicaciones de la lista y/o información más detallada en el caso de una aprobación condicional (la aprobación condicional se trata más adelante con más detalle).
La FIG. 13B ilustra un diagrama de flujo que muestra el funcionamiento del esquema de control parental.
En el bloque 1320, en respuesta a un teléfono móvil que se acopla comunicativamente con la unidad principal, la unidad principal obtiene un número de teléfono del teléfono móvil que se utilizará para comunicarse con el servidor. En el bloque 1321, la unidad principal envía el número de teléfono al servidor para su análisis. Si el número de teléfono obtenido no coincide con un perfil designado como sujeto a control parental, entonces el proceso de control parental se completa en el bloque 1322.
De lo contrario, si el número de teléfono obtenido corresponde al perfil sujeto al control parental, en el bloque 1323 el servidor ejecuta el control parental. En un ejemplo, dicha ejecución incluye los bloques 1323-1327, similares al proceso de aprobación de VNC, discutido en el siguiente párrafo.
En el bloque 1323, el servidor transmite un mensaje de control parental a la unidad principal. En el bloque 1324, la unidad principal supervisa continuamente las condiciones basadas en el mensaje de control parental. En el bloque 1325, la unidad principal bloquea una aplicación concreta para que no utilice la unidad principal como interfaz extendida y/o bloquea la ejecución de una aplicación concreta instalada en la unidad principal. Por ejemplo, la unidad principal puede recibir una indicación de que el teléfono móvil concreto ha recibido una llamada telefónica, pero entonces bloquea el uso de la unidad principal como interfaz extendida para la llamada telefónica. O, en otro ejemplo, la unidad principal puede bloquear un intento de ejecutar una aplicación de reproducción multimedia en la unidad principal. La supervisión continua puede ser facilitada por una base de datos en la unidad principal que almacena los mensajes de control parental recibidos.
En el bloque 1326, la unidad principal bloquea condicionalmente una aplicación particular para que no utilice la unidad principal como una interfaz extendida y/o se ejecute directamente en la unidad principal. Por ejemplo, la unidad principal puede recibir una indicación de que el teléfono móvil en particular ha recibido una llamada telefónica, pero luego bloquear el uso de la unidad principal como una interfaz extendida en función de un valor de un campo de identificación de la llamada entrante. Más específicamente, el mensaje de control parental puede designar ciertos números de teléfono como excepciones para evitar que la unidad principal proporcione una interfaz extendida para el teléfono. La unidad principal obtiene el valor del identificador de llamadas del teléfono móvil y bloquea el teléfono móvil para que no utilice una interfaz de la unidad principal de forma condicional. En otro ejemplo, la unidad principal puede bloquear una aplicación de forma condicional basándose en una condición del vehículo, por ejemplo, la unidad principal bloquea el teléfono móvil para que no utilice una interfaz de la unidad principal sólo si el vehículo está en movimiento.
En el bloque 1327, la unidad principal no bloquea la aplicación particular si la aplicación está permitida de acuerdo con el mensaje de control parental. En este caso, la unidad principal permite que la aplicación funcione de acuerdo con la aprobación del servidor, por ejemplo, en función de si la aplicación está en la lista controlada (FIG. 6).
Debe ser evidente que, en otros ejemplos, un sistema puede hacer cumplir un esquema de control parental utilizando procesos diferentes a los descritos específicamente arriba. Por ejemplo, en otro ejemplo, los procesos de los bloques 1323-1327 no se utilizan. En cambio, la unidad principal informa continuamente de las condiciones y las solicitudes de aplicaciones al servidor, que retira dinámicamente una aprobación actual de acuerdo con la configuración del control parental. A continuación, el servidor controla la unidad principal para bloquear una aplicación actual desaprobada.
Esquema extensible para el funcionamiento de la unidad principal del vehículo como interfaz ampliada para el dispositivo móvil
Existen esquemas conocidos para el funcionamiento de una unidad principal del vehículo como una interfaz extendida para un dispositivo móvil. Sin embargo, en los esquemas conocidos, la configuración de la unidad principal del vehículo se fija en el momento de la fabricación y, como resultado, puede ser inoperable con las aplicaciones móviles recién lanzadas. En una solución parcial, la nueva aplicación del dispositivo móvil se descarga en la unidad principal del vehículo, lo que requiere que la unidad principal del vehículo se fabrique con componentes de hardware relativamente costosos para permitir la descarga, la instalación y el funcionamiento de la aplicación del dispositivo móvil (en la unidad principal del vehículo).
La FIG. 14 ilustra un sistema para operar una unidad principal del vehículo tal como una interfaz extendida para un dispositivo móvil.
El sistema 1400 incluye un servidor 1411, una unidad principal del vehículo 1412, y un dispositivo móvil 1413 (que puede ser un dispositivo inalámbrico de largo alcance, por ejemplo un teléfono celular, en un ejemplo), incluyendo dispositivos de procesamiento 1408, 1409, y 1410, respectivamente. La unidad principal del vehículo 1412 incluye una interfaz de entrada/salida de corto alcance, como un transceptor Bluetooth o un puerto USB, configurado para acoplar la unidad principal del vehículo 1412 a un dispositivo móvil disponible, como el dispositivo móvil 1413. La conexión 1415 representa la conexión entre la unidad principal del vehículo 1412 y el dispositivo móvil 1413. El servidor 1411 incluye una interfaz de red configurada para comunicarse con la unidad principal del vehículo 1412. Las comunicaciones 1416 del servidor 1411 pueden llegar a la unidad principal del vehículo 1412 a través de la conexión 1415 en un ejemplo (en algunos casos una unidad principal del vehículo puede utilizar una radio de largo alcance del dispositivo móvil para comunicarse con una red remota), o a través de otra trayectoria (en algunos casos una unidad principal del vehículo puede utilizar una radio de largo alcance del vehículo para comunicarse con una red remota).
El servidor 1411 contiene una memoria que almacena grupos de una o más instrucciones de aplicación 1425 (cada grupo corresponde a una aplicación del dispositivo móvil). Las instrucciones de aplicación de un grupo puede(n) ser actualizadas con el tiempo a medida que las aplicaciones de los dispositivos móviles son liberadas. La unidad principal del vehículo contiene un software integrado, como la aplicación HMI 1421, que, por el contrario, puede fijarse en el momento de la fabricación de la unidad principal del vehículo 1412. La aplicación HMI de plantilla 1421 es un "cliente ligero" que está configurado para ejecutar una instrucción de aplicación descargada. La plantilla de la aplicación HMI 1421 también puede denominarse "cliente ligero" y funciona independientemente de un intérprete, es decir, un componente que interpreta un lenguaje de scripting, por ejemplo, Java script, en otro lenguaje de programación. La plantilla de la aplicación HMI 1421 puede incluir una pluralidad de pantallas de visualización genéricas, por ejemplo, una pluralidad de pantallas HMI 1423.
Muchas pantallas de aplicaciones en las unidades principales pueden ser generalizadas como una de una pluralidad de tipos de pantalla. En un ejemplo, la pluralidad de tipos de pantalla incluye pantallas de tipo informativo, por ejemplo, pantallas que muestran listas de información, pantallas de tipo interactivo, por ejemplo, pantallas para mostrar un mensaje interactivo como una publicación en una red social o un mensaje de correo electrónico, pantallas de visualización de contenido, por ejemplo, pantallas que muestran contenido que se está reproduciendo, como el contenido de una aplicación de música o una aplicación de libros. En consecuencia, en un ejemplo, la pluralidad de pantallas de HMI 1423 incluye una pantalla de información, una pantalla de visualización de contenido y una pantalla de mensajes interactivos. Una combinación de la pluralidad de pantallas de visualización genérica, por ejemplo, la pluralidad de pantallas HMI 1423, puede combinarse para formar las pantallas de una aplicación determinada. El formato de la plantilla individual no puede cambiar de una aplicación determinada a otra, sólo el contenido, las imágenes de haberlas, el orden en que se muestran las pantallas y la asignación de botones a la función de la aplicación que reside en el teléfono cambian de una aplicación determinada a otra.
El dispositivo de procesamiento 1408 está configurado para descargar al menos uno de los grupos de instrucciones de aplicación 1425 a una memoria 1450 de la unidad principal del vehículo 1412. La descarga puede ocurrir en cualquier momento, pero en un ejemplo puede ocurrir en respuesta a la recepción de una solicitud del dispositivo de procesamiento 1409 o del dispositivo de procesamiento 1410.
La descarga de un grupo de instrucciones de aplicación también puede responder a la determinación de que la aplicación del dispositivo móvil 1413 está autorizada a utilizar un recurso de la unidad principal del vehículo 1412 en función de un estado actual del vehículo. Debe apreciarse que la determinación de si la solicitud está autorizada puede implicar cualquier combinación de los principios descritos en la presente memoria con referencia a las FIGS. 1-13B. En un ejemplo, la descarga puede no producirse al determinar que la aplicación no está autorizada a utilizar el recurso de la unidad principal del vehículo 1412. En un ejemplo, la descarga puede seguir ocurriendo tras determinar que la aplicación no está autorizada a utilizar el recurso de la unidad principal del vehículo 1412, pero el servidor 1411 puede impedir que la aplicación utilice el recurso de la unidad principal del vehículo 1412 en ese momento.
Las instrucciones de aplicación descargadas están configuradas para, cuando son ejecutadas por la aplicación de HMI de plantilla 1421, instruir a la aplicación de HMI de plantilla 1421 sobre cómo controlar la aplicación de dispositivo móvil particular 1414, incluyendo qué mandos pueden ser entendidos por la aplicación de dispositivo móvil particular 1414 y/o un formato de esos mandos. Expresado en forma más general, la descarga y ejecución de las instrucciones de aplicación permite que la aplicación de HMI de plantilla 1421 (que puede ser la aplicación de HMI original instalada en la unidad principal del vehículo en el momento de su fabricación) controle la aplicación de dispositivo móvil particular recién descubierta 1414 (que puede ser una aplicación "nueva» de dispositivo móvil, es decir, lanzada o incluso desarrollada después de la fabricación de la unidad principal del vehículo).
En un ejemplo, la instrucción delinea un orden específico para mostrar al menos una porción de la pluralidad de pantallas HMI para la aplicación solicitada. En otras palabras, el orden específico para la aplicación solicitada puede ser diferente de un orden específico correspondiente a otra aplicación (cada instrucción para una pluralidad de aplicaciones de un dispositivo móvil puede delinear un orden diferente). Debe apreciarse que una aplicación puede utilizar una porción diferente de la pluralidad de pantallas HMI que otra aplicación (por ejemplo, una aplicación dada puede utilizar todas las pantallas, mientras que otra aplicación dada puede utilizar sólo una de las pantallas).
Si se puede esperar que se envíen respuestas desde la aplicación de dispositivo móvil particular 1414 a la aplicación de HMI de plantilla 1421, entonces las instrucciones de aplicación descargadas pueden estar configuradas para, cuando son ejecutadas por la aplicación de HMI de plantilla 1421, proporcionar a la aplicación de HMI de plantilla 1421 un formato/estructura de la respuesta, incluyendo información que describa cómo la aplicación de plantilla 1421 debe mostrar la información incluida en la respuesta. Si se puede esperar que se envíen respuestas desde la aplicación de dispositivo móvil 1414 particular a la aplicación de HMI de plantilla 1421, entonces las instrucciones de aplicación descargadas pueden estar configuradas para, cuando son ejecutadas por la aplicación de HMI de plantilla 1421, proporcionar a la aplicación de HMI de plantilla 1421 una lista de mandos y respuestas que conforman el orden y la secuencia de los mensajes intercambiados entre la aplicación de HMI de plantilla 1421 y la aplicación de dispositivo móvil 1414 para el caso de uso involucrado.
La FIG. 15 ilustra un diagrama de señalización que muestra un ejemplo de las operaciones que pueden realizar el servidor, la unidad principal del vehículo y el dispositivo móvil de la FIG. 14.
Después de que la unidad principal del vehículo 1412 y el dispositivo móvil 1413 están acoplados, la unidad principal del vehículo 1412 proporciona un perfil de la unidad principal del vehículo al dispositivo móvil 1413 (señal 1502). El perfil de la unidad principal del vehículo puede incluir un identificador único para la unidad principal del vehículo 1412. El perfil de la unidad principal del vehículo puede incluir una lista de todos los grupos de instrucciones de aplicación almacenados actualmente en la unidad principal del vehículo 1412. En un ejemplo, el perfil de la unidad principal del vehículo también identifica al menos un idioma o protocolo soportado por la unidad principal del vehículo 1412.
El dispositivo móvil 1413 proporciona un perfil del dispositivo móvil y el perfil de la unidad principal del vehículo al servidor 1411 (señal 1503). El perfil del dispositivo móvil puede incluir un identificador único, por ejemplo, un identificador único del dispositivo móvil o un identificador de cuenta de usuario, que es diferente del identificador único de la unidad principal del vehículo 1412. El perfil del dispositivo móvil puede incluir una lista de todas las aplicaciones actualmente almacenadas en el dispositivo móvil 1413 (aunque en algunos ejemplos el identificador único puede corresponder a la cuenta de usuario permitiendo al servidor 1411 determinar todas las aplicaciones actualmente asociadas con la cuenta de usuario en base al identificador de la cuenta). En un ejemplo, el dispositivo móvil 1413 identifica las aplicaciones de HMI de plantilla 1421 soportadas por la unidad principal del vehículo 1412 e identifica las aplicaciones 1414 para operar con las aplicaciones de HMI de plantilla 1421.
El servidor 1411 descarga una instrucción de aplicación 1425, por ejemplo un conjunto de instrucciones de aplicación, al dispositivo móvil 1413 (señal 1507). En un ejemplo, el servidor 1411 puede descargar la lógica de la aplicación, por ejemplo, la lógica configurada para comandar/controlar una aplicación particular, correspondiente a una aplicación identificada. En un ejemplo, una instrucción de aplicación descargada comprende el resultado de un mando ejecutado por la lógica de aplicación correspondiente. La descarga para la unidad principal del vehículo 1412 puede comprender una actualización de unas instrucciones de aplicación de la lista, o unas nuevas instrucciones de aplicación aún no almacenadas en la unidad principal del vehículo 1412. Del mismo modo, una descarga para el dispositivo móvil 1413 puede ser una actualización para una aplicación existente del dispositivo móvil 1413, o una descarga para una nueva aplicación.
El dispositivo móvil 1413 almacena cualquier lógica de aplicación recibida en la memoria local y proporciona a la unidad principal del vehículo 1412 las instrucciones de aplicación descargadas 1425 (señal 1508). La lógica de la aplicación almacenada en la memoria del dispositivo móvil 1413 puede ejecutarse en respuesta a una entrada del usuario recibida por el dispositivo móvil 1413.
Si la unidad principal del vehículo 1412 recibe una instrucción de aplicación, la unidad principal del vehículo 1412 puede construir una interfaz gráfica de usuario con botones de software para una aplicación de dispositivo móvil que puede utilizar la unidad principal del vehículo 1412 como una interfaz extendida (señal 1509). La GUI mostrada puede utilizar una de las pantallas de la HMI 1423 (FIG. 14) de la plantilla de la aplicación HMI 1421 (FIG. 14). En respuesta a una entrada del usuario que selecciona una aplicación del dispositivo móvil para utilizar la unidad principal del vehículo 12 como una interfaz extendida, la unidad principal del vehículo 12 ejecuta una de las correspondientes instrucciones de la aplicación descargada (señal 1511). La unidad principal del vehículo opera la aplicación HMI de la plantilla en base al resultado de la ejecución de las instrucciones de aplicación correspondientes (señal 1513).
En un caso de uso de ejemplo, la ejecución de una primera instrucción de un grupo de instrucciones de aplicación hace que la unidad principal del vehículo envíe un mensaje particular a la aplicación del dispositivo móvil para hacer que la aplicación del dispositivo móvil responda devolviendo contenido a la unidad principal del vehículo. En este ejemplo de uso, la siguiente instrucción del grupo hace que la unidad principal del vehículo compare parte o todo el contenido con un parámetro o valor contenido en la siguiente instrucción. En función del resultado de la comparación, la unidad principal del vehículo puede pasar a la siguiente instrucción, o pasar directamente a otra instrucción después de la siguiente, o mostrar un determinado texto de una pantalla, o esperar a que un usuario introduzca una selección a través de una interfaz de la unidad principal del vehículo, o completar, etc., en función de las particularidades de la instrucción ejecutada.
En un ejemplo de funcionamiento de acuerdo con los principios descritos con referencias a las FIGS. 14 y 15, la lógica de la aplicación para utilizar un recurso de la unidad principal del vehículo se distribuye entre un dispositivo móvil y la unidad principal del vehículo. En otro ejemplo de funcionamiento de acuerdo con los principios descritos con referencias a las FIGS. 14 y 15, todo el código asociado a la lógica de la aplicación se almacena en el dispositivo móvil.
En un ejemplo, se proporciona un dispositivo de memoria que tiene instrucciones almacenadas que, en respuesta a la ejecución por un dispositivo de procesamiento, hacen que el dispositivo de procesamiento realice operaciones. Una operación incluye el acoplamiento de un dispositivo móvil y una unidad central del vehículo. Una operación incluye el envío, a un dispositivo de red remoto, de una solicitud para que una aplicación del dispositivo móvil utilice un recurso de la unidad principal del vehículo, incluyendo la solicitud un primer perfil de la unidad principal del vehículo y un segundo perfil del dispositivo móvil. Una operación incluye, en respuesta al envío de la solicitud, recibir una instrucción desde el dispositivo de red remoto, la instrucción a ser ejecutada por el software integrado de la unidad principal del vehículo para permitir que la aplicación solicitada utilice un recurso de la unidad principal del vehículo.
En un ejemplo, el software embebido comprende una aplicación HMI de plantilla y una pluralidad de pantallas HMI, y la instrucción delinea un orden específico para mostrar al menos una porción de la pluralidad de pantallas HMI para la aplicación solicitada. En un ejemplo, la aplicación HMI de plantilla funciona sin un componente de interpretación.
En un ejemplo, el primer perfil identifica un primer identificador único que corresponde a la unidad principal del vehículo e identifica un lenguaje o protocolo asociado con el software integrado. En un ejemplo, el segundo perfil identifica un segundo identificador único que es diferente del primer identificador único.
En un ejemplo, la instrucción comprende un resultado de un mando o función de control ejecutado por la lógica de aplicación asociada con la aplicación solicitada. En un ejemplo, las operaciones incluyen, en respuesta a la solicitud, la actualización del código almacenado en el dispositivo móvil y que corresponde a la lógica de la aplicación. En un ejemplo, el código correspondiente a la lógica de la aplicación está configurado para interoperar con la unidad principal del vehículo en respuesta al dispositivo móvil que recibe una entrada del usuario, estando la interoperación de acuerdo con un resultado de la ejecución de la instrucción por la unidad principal del vehículo.
En un ejemplo, se proporciona un dispositivo de memoria que tiene instrucciones almacenadas que, en respuesta a la ejecución por un dispositivo de procesamiento, hacen que el dispositivo de procesamiento realice operaciones. Una operación incluye la recepción de una solicitud para que una aplicación de un dispositivo móvil utilice un recurso de una unidad principal del vehículo, la solicitud incluye un primer perfil de la unidad principal del vehículo y un segundo perfil del dispositivo móvil. Una operación incluye la determinación de si la aplicación solicitada está autorizada a utilizar el recurso de la unidad principal del vehículo en base a un estado actual del vehículo. Una operación incluye, en respuesta a la determinación de que la aplicación solicitada está autorizada a utilizar el recurso del vehículo, la descarga de una instrucción a la unidad principal del vehículo, la instrucción que debe ser ejecutada por el software integrado de la unidad principal del vehículo para permitir que la aplicación solicitada utilice un recurso de la unidad principal del vehículo.
En un ejemplo, el software embebido comprende una aplicación HMI de plantilla y una pluralidad de pantallas HMI, y la instrucción delinea un orden específico para mostrar al menos una porción de la pluralidad de pantallas HMI para la aplicación solicitada. En un ejemplo, la aplicación HMI de plantilla funciona sin un componente de interpretación.
En un ejemplo, el primer perfil identifica un primer identificador único que corresponde a la unidad principal del vehículo e identifica un lenguaje o protocolo asociado con el software integrado. En un ejemplo, el segundo perfil identifica un segundo identificador único que es diferente del primer identificador único.
En un ejemplo, la instrucción comprende un resultado de un mando o función de control ejecutado por la lógica de aplicación. En un ejemplo, las operaciones incluyen, en respuesta a la determinación de que la aplicación solicitada está autorizada a utilizar el recurso del vehículo, la actualización del código que está almacenado en el dispositivo móvil y que corresponde a la lógica de la aplicación. En un ejemplo, el código correspondiente a la lógica de la aplicación está configurado para interoperar con la unidad principal del vehículo en respuesta al dispositivo móvil que recibe una entrada del usuario, estando la interoperación de acuerdo con un resultado de la ejecución de la instrucción por la unidad principal del vehículo.
Con referencia ahora a la FIG. 16, ilustra otro aspecto de la presente divulgación, a saber, otro sistema para extender una aplicación de usuario de teléfono móvil para utilizar una HMI de una unidad principal de vehículo. Este diagrama simplificado tiene tres componentes principales, un teléfono móvil 1640, una unidad principal del vehículo 1620 y un servidor remoto 1670. Como se indica en la Figura 16, el teléfono móvil 1640 incluye capacidad de comunicación para llevar a cabo comunicaciones de datos en paquetes 1652, por ejemplo, a través de una red móvil 1654. Se pueden utilizar varios servicios de voz y/o datos para las comunicaciones con el servidor. La red móvil, a su vez, puede tener una pasarela (no mostrada) a Internet, mostrada tal como Nube IP 1666. El servidor remoto 1670 tiene un componente de comunicaciones (no mostrado) para llevar a cabo las comunicaciones 1668 a través de Internet 1666.
Entre otras cosas, la disposición de la FIG. 16 permite la descarga de programas de aplicaciones de usuario, por ejemplo, una aplicación de usuario 1644 que se muestra instalada en el teléfono móvil 1640, desde el servidor 1670. Otros procedimientos de descarga de programas de aplicación del usuario fueron discutidos anteriormente. También es sabido que se puede adquirir un programa de aplicación móvil en una "tienda de aplicaciones" en línea. Además, el sistema ilustrado puede utilizarse para descargar la información de la aplicación del teléfono ("información de aplicación del teléfono") 1680 ubicada en el servidor 1670, al teléfono móvil. La información de la aplicación del teléfono puede proporcionarse por aplicación de usuario, como se explica más adelante. La información de la aplicación del teléfono 1680 puede ser adquirida, mantenida o actualizada desde un servidor remoto separado (no mostrado). En una realización preferente, la información de la aplicación del teléfono se descarga en un programa de aplicación HAP 1642 en el teléfono móvil.
La unidad principal del vehículo 1620 incluye un componente de software HUP 1630 que está dispuesto para llevar a cabo comunicaciones 1635 con el teléfono móvil. El proxy de la unidad principal 1630 está acoplado operativamente a la HMI 1622 de la unidad principal 1620. Por ejemplo, la HUP puede interactuar con la HMI a través de varios componentes de software y protocolos. Como se ha comentado anteriormente, la HMI de la unidad principal puede incluir una pantalla de visualización, que puede ser una pantalla táctil, un micrófono, altavoces y otros elementos de E/S. En esta ilustración, la HMI incluye una o más pantallas de visualización genéricas 1624. No se hace referencia a la pantalla física, sino a los elementos de software que definen la apariencia y el funcionamiento de una o varias pantallas genéricas. Estas pantallas de visualización genéricas pueden utilizarse para ampliar la interfaz de usuario del programa de aplicación de usuario 1644 que se ejecuta en el teléfono móvil 1640, como se explica con más detalle a continuación. La unidad principal y el teléfono móvil pueden estar acoplados mediante un enlace inalámbrico de corto alcance, por ejemplo un enlace Bluetooth®, u otros medios sin contacto, tal como infrarrojos, o mediante un cable.
La pantalla de la HMI de la unidad principal y la lógica de aplicación asociada no pueden actualizarse fácilmente debido a las limitaciones de los recursos de la plataforma de la unidad principal. En consecuencia, la HMI puede no estar bien adaptada para servir de interfaz ampliada para programas de aplicación de usuario más nuevos que pueden no haber existido en el momento en que se fabricó o programó la unidad principal. En algunos casos, puede ser costoso o poco práctico para el fabricante del vehículo o el OEM del automóvil actualizar el firmware de la unidad principal para acomodar los nuevos programas de aplicación del usuario y su correspondiente funcionalidad de mando y control con el fin de interactuar con la unidad principal.
Son conocidas varias plataformas de unidades principales en los mercados OEM y de posventa. Pueden utilizar varios tipos de procesadores y sistemas operativos integrados, por ejemplo Windows® Automotive, Android, QNX, etc. La unidad principal suele contener pantallas de visualización que pueden utilizarse para mostrar contenidos de forma pasiva. Es decir, la unidad principal puede recibir y mostrar un contenido, como un gráfico o una imagen, o reproducir un archivo de audio, sin conocer ni comprender ese contenido ni el significado de los datos que muestra. Además, normalmente, la unidad principal no es capaz de gestionar el estado o el caso de uso en relación con el estado de la aplicación que reside en el teléfono con el que puede estar interactuando. Por lo tanto, la unidad principal puede compararse con un terminal, que carece de la lógica empresarial específica de la aplicación del usuario.
Típicamente, una unidad principal incluye elementos de UI de entrada. Volviendo a la Figura 21, esta muestra un ejemplo simplificado de una unidad principal 2102 que puede encontrarse en un vehículo de motor. La unidad principal en esta ilustración muestra una pantalla física 2104, que puede ser una pantalla táctil, y también incluye uno o más botones o interruptores mecánicos 2110, 2112 que pueden estar situados en el bisel o marco que rodea la pantalla. Los botones 2110 y 2112 ilustran interruptores físicos reales que pueden ser presionados por los dedos del usuario como un dispositivo de entrada. La pantalla de visualización puede utilizarse para mostrar datos, mensajes, imágenes u otros contenidos recibidos por la unidad principal desde la aplicación de usuario, tal y como se discute en la presente memoria. El contenido puede incluir datos de audio o vídeo para su presentación a través de la unidad principal.
Muchas unidades principales implementan plantillas o diseños de pantalla genéricos. Por ejemplo, se puede proporcionar una plantilla sencilla para mostrar un vídeo y su título. Una plantilla de este tipo llena sólo dos regiones de una pantalla de visualización, por ejemplo, colocando el vídeo en una región 2134, y el título o la información relacionada en una región de visualización de texto o ventana 2140 debajo del vídeo. Otra plantilla puede prever seis botones de entrada. En el caso de los botones mecánicos, por ejemplo 2110 y 2112, pueden estar integrados en el bisel con tres en cada lado. El texto o las imágenes pueden enviarse a la HMI para mostrar una imagen correspondiente, una insignia u otro identificador adyacente a cada uno de los botones mecánicos. Estos identificadores pueden aparecer, a título ilustrativo, en las seis regiones marcadas 2120 en el dibujo, que corresponden a los seis botones mecánicos representados como heptágonos. De este modo, la función o el significado del botón duro puede variar mostrando un identificador diferente junto al botón duro. En el caso de que la pantalla 2104 sea sensible al tacto (una "pantalla táctil"), las mismas regiones 2120, debidamente identificadas, pueden ser utilizadas como botones de entrada en sí mismas. Una plantilla de visualización genérica para uso con una pantalla táctil puede configurarse para proporcionar cualquier tamaño y disposición predeterminados de las regiones táctiles detectables. En un ejemplo, la HMI simplemente emite un mensaje o evento que indicara qué región se ha pulsado. No es necesario que se comprenda su relevancia.
En general, la unidad principal 2102 puede ser utilizada para la entrada de un programa de aplicación de usuario que se está ejecutando en un teléfono móvil cercano, utilizando el sistema de la Figura 16. Además, la unidad principal puede tener otros servicios de entrada o hardware, no mostrados, tal como un micrófono para recibir mandos audibles. Además, la unidad principal puede tener acceso a una o más redes del vehículo, por ejemplo una red CAN, para adquirir información del vehículo que también puede servir como entrada a una aplicación del usuario. Por ejemplo, el estado del vehículo, como la velocidad, puede transmitirse al HAP para que lo considere en relación con la aplicación de las políticas de seguridad.
Para que una HMI genérica de una unidad principal, y más específicamente pantallas genéricas, sea utilizada para extender la interfaz de usuario de un programa de aplicación, se debe emplear información que es específica del programa de aplicación de usuario, para traducir y asignar apropiadamente las comunicaciones entre la aplicación de usuario 1644 y la HMI 1622. Ese tipo de información, identificada como 1680 en la Figura 16, puede mantenerse en el servidor remoto 1670 y descargarse a petición. Una vez que esa información ha sido descargada y almacenada en el teléfono móvil, de forma evaluable para la aplicación HAP, esta puede proporcionar esta funcionalidad. Más específicamente, en las realizaciones preferentes, la información de la aplicación de teléfono descargada 1680 puede ser utilizada por el HAP para gestionar el flujo de mandos y control y el estado para cada caso de uso en relación con la aplicación del sujeto instalada en el teléfono móvil, y la visualización u otra salida de datos a través de la unidad principal. El HAP puede emitir contenido en un formato apropiado para varias plantillas genéricas de visualización en pantalla, o diseños de plantillas, de modo que la unidad principal pueda mostrar esa información sin conocimiento o lógica que sea específica de la aplicación del usuario, como los casos de uso, el estado y la situación. Más bien, en una realización preferente, el estado de la aplicación del usuario y el estado son mantenidos por e1HAP en el teléfono móvil.
La FIG. 17 es un diagrama de bloques funcional que ilustra un ejemplo de componentes de software que puede contener una aplicación HAP, según lo indicado en 1642 en la Figura 16. En la Figura 17, e1HAP 1700 en una realización comprende una API 1702 acoplada a un componente de gestión de mensajes HAP 1704. Los siguientes componentes pueden ser implementados usando JavaScript o cualquier lenguaje de scripting adecuado. Se hace referencia a JavaScript a modo de ilustración. El componente de gestión de mensajes puede incluir un intérprete de JavaScript 1706. El intérprete de JavaScript está acoplado comunicativamente a componentes individuales de JavaScript para uno o más programas de aplicación del usuario, mostrados como "aplicación nómada" por ejemplo, el componente 1710, para las aplicaciones 1-n. Preferentemente se proporciona un componente JavaScript separado para cada programa de aplicación de interés. En el dibujo se muestran tres de estos JavaScripts a modo de ilustración, aunque este número no es crítico.
A su vez, cada JavaScript contiene o está acoplado para acceder a un traductor de mensajes de plantilla correspondiente 1712. Se utiliza para traducir los mensajes comunicados entre el teléfono móvil y la unidad central, como se explica más adelante. Los componentes de JavaScript para una determinada aplicación de usuario pueden descargarse a petición, como se ha indicado anteriormente, de la tienda de información de aplicaciones de teléfono 1680 en el servidor 1670. Una solicitud al servidor puede incluir un identificador del programa de aplicación del usuario. En una realización preferente de este aspecto de la invención, la solicitud de información de la aplicación telefónica no necesita identificar la unidad principal o la HMI específicamente. Puede identificar un tipo genérico de unidad principal o pantalla, o no identificar la unidad principal en absoluto.
La aplicación HAP 1700 puede incluir además una pila de protocolos 1720 para las comunicaciones con la unidad principal. Alternativamente, o además, el HAP 1700 puede incluir un componente de protocolo de enmarcado de mensajes más simple 1722, para la comunicación con unidades principales que no pueden soportar un protocolo más elaborado como HTTP/TCP/IP/SLIP. Un componente discriminador de protocolos 1730 sirve para determinar qué protocolos son aplicables y dirigir la comunicación en consecuencia. Por último, el discriminador de protocolos se acopla a un componente de comunicación adecuado 1740.
Cada JavaScript individual, por ejemplo 1720, implementa la lógica de la aplicación de usuario y la comprensión del formato de los mensajes que, de otro modo, estaría contenida en la unidad de aplicación HMI de la unidad principal asociada si estuviera diseñada para la interacción con la correspondiente aplicación de usuario. En este caso, sin embargo, la HMI no está configurada de esta manera, por lo que se trata como una HMI genérica. Una "pantalla de plantilla" estándar en la unidad principal no puede tomar decisiones ni persistir el estado de las aplicaciones. Sólo se puede utilizar para mostrar contenidos categorizados, por ejemplo, listas, mensajes básicos, resultados y pantallas de "sonando ahora". Por ejemplo, con referencia a la Figura 21, un área de visualización 2134 puede utilizarse para mostrar el contenido seleccionado como se ha señalado. Se puede utilizar un traductor de mensajes de plantilla para traducir los mensajes de solicitud y respuesta especificados por la aplicación nómada al formato requerido por las pantallas de la HMI de la unidad principal en base a plantillas. Además, el JavaScript 1710 puede contener información de asignación de botones junto con datos visuales de identificación de botones que pueden ser enviados a la pantalla para identificar visualmente el/los botón/es correspondiente/s, como se ha señalado anteriormente con referencia a la FIG. 21, en función de la aplicación de teléfono individual representada por el JavaScript asociado.
Con referencia ahora a la Figura 18, esta muestra un diagrama simplificado que ilustra un ejemplo de flujo de datos entre un programa de aplicación de usuario y una HMI de la unidad principal del vehículo que utiliza la aplicación HAP integrada. Una aplicación de usuario ("aplicación nómada") 1800 interactúa con una AP1 HAP 1802 dispuesta para comunicar mensajes a un programa JavaScript correspondiente 1810 también instalado en el teléfono móvil. El JavaScript 1810 incluye la lógica HMI de la aplicación de usuario y el código de gestión de estado 1812. Los mensajes 1814 de la aplicación de usuario se formatean como lo harían en el funcionamiento normal de la aplicación de usuario 1800.
El JavaScript 1810 para la aplicación de usuario 1800 incluye además un componente traductor de mensajes de plantilla ("TMT") 1820. En funcionamiento, el TMT recibe un mensaje de la lógica 1812, y lo traduce en un mensaje con formato de plantilla, es decir, compatible con la unidad principal. El mensaje con formato de plantilla 1824 se comunica entonces a la unidad principal 1830. A la inversa, en la otra dirección, un mensaje con formato de plantilla 1834 puede ser comunicado desde la unidad principal al JavaScript 1810, en el que es recibido por el TMT 1820, y traducido a una forma útil para la lógica de la aplicación y la gestión del estado 1812. La lógica puede entonces determinar el envío de un mensaje 1840 (con formato de aplicación de usuario) a la aplicación 1800 a través de la API HAP. Cada mensaje de solicitud recibido de la unidad principal da lugar a una o más transacciones entre el código JavaScript y la aplicación del usuario antes de que se devuelva un resultado a la unidad principal.
La FIG. 19 comprende un diagrama de mensajería o señalización que muestra un ejemplo de las interacciones entre los componentes de software en el caso de un mensaje síncrono, es decir, uno iniciado por la HMI de la unidad principal. Para empezar, se recibe un evento 1902 desde una unidad principa1HMI. Como ejemplo sencillo, puede ser pulsar un botón, correspondiente a PLAY, en el que se está ejecutando una aplicación de reproducción de música en el teléfono móvil. El evento se comunica a través de la HUP como se ilustra en la FIG. 16. En e1HAP se incorpora un interruptor JavaScript 1910, como se muestra, que incluye un gestor JavaScript 1912, un componente JavaScript abstracto 1920, un JavaScript de aplicación 1930 y un componente gestor de estado 1932. La aplicación JavaScript es específica de la aplicación de usuario mostrada como "aplicación nómada" 1940 que incluye una interfaz proxy de aplicación 1942. Un Interruptor JavaScript de este tipo suele estar disponible en los SDK de los teléfonos móviles.
El JavaScript abstracto traduce el mensaje para el JavaScript de aplicación, y el JavaScript de aplicación de 1930 ejecuta su lógica de negocio de aplicación en el evento HMI. Si una llamada a la aplicación de usuario es adecuada, se envía un mensaje o una llamada (1950) al gestor de mensajes HAP. El gestor de mensajes HAP, a su vez, envía el mensaje a la aplicación de usuario ("invokeAppNcationCaNback") 1952. La aplicación envía una respuesta al gestor de mensajes ("aqSendMsg") 1954. El gestor de mensajes puede traducir el mensaje y, a su vez, el JavaScript abstracto puede ejercer la lógica de traducción del mensaje para enviar un mensaje apropiado al JavaScript de la aplicación. La aplicación JavaScript ejecuta su lógica de negocio, almacena o actualiza el estado y el contenido 1932, y traduce la respuesta a un formato de plantilla para enviarla a la HMI, véase 1960.
La FIG. 20 comprende un diagrama de mensajería o señalización que muestra un ejemplo de interacciones entre componentes de software en el caso de un mensaje asíncrono, es decir, uno iniciado por la aplicación de usuario que se ejecuta en el teléfono móvil. Para empezar, la aplicación envía un mensaje que es recibido por e1HAP, véase 2010. El gestor de mensajes HAP 2012 envía el mensaje a la aplicación JavaScript, que llamará a su lógica, almacenará o recuperará el estado y el contenido y, si es necesario, generará un mensaje de actualización HMI 2030.
En un ejemplo, se proporciona un sistema. El sistema incluye una unidad principal del vehículo, la unidad principal implementa al menos un tipo de pantalla de visualización de aplicaciones genéricas; un ordenador servidor, el ordenador servidor está dispuesto para las comunicaciones a través de una red móvil a un teléfono móvil; en el que el ordenador servidor está dispuesto además para administrar información de la aplicación del teléfono asociada con un programa de aplicación de usuario específico ejecutable en un teléfono móvil, y el servidor administra la información de la aplicación del teléfono al teléfono móvil a través de la red móvil; y en el que la información de la aplicación del teléfono permite ampliar una interfaz de usuario del programa de aplicación de usuario específico para utilizar la pantalla de visualización de aplicaciones genéricas de la unidad principal del vehículo.
En un ejemplo, el sistema incluye una aplicación de software HAP ejecutable en un teléfono móvil; y una aplicación de software HUP ejecutable en la unidad principal; en la que el HAP y el HUP están dispuestos a comunicar mensajes o eventos entre ellos, y a utilizar aspectos de la información de la aplicación telefónica para permitir que el programa de aplicación de usuario específico en el teléfono móvil interactúe con la pantalla de visualización de la aplicación genérica de la unidad principal del vehículo. En un ejemplo, la unidad principal no instala ni ejecuta la lógica de la aplicación de visualización de la HMI desarrollada específicamente para interactuar con el programa de aplicación específico del usuario en el teléfono móvil. En un ejemplo, el HAP está dispuesto para enviar uno o más de los contenidos, textos e imágenes al HUP para su representación en la pantalla de visualización de la aplicación genérica de acuerdo con un diseño de plantilla predeterminado de la pantalla de visualización de la aplicación genérica. En un ejemplo, la aplicación de software HAP y la aplicación de software HUP se implementan cada una en un lenguaje de scripting. En un ejemplo, la información de la aplicación del teléfono incluye datos para implementar una política de seguridad en relación con la ejecución del programa de aplicación de usuario específico. En un ejemplo, e1HAP incluye un componente de gestión de mensajes, y al menos una pila de protocolos acoplada al componente de gestión de mensajes, para las comunicaciones con la unidad principal; el componente de gestión de mensajes incluye al menos un componente de lenguaje de scripting asociado a un programa de aplicación de usuario específico; y el componente de lenguaje de scripting incluye un componente traductor de mensajes de plantilla correspondiente, el componente traductor de mensajes configurado para traducir los mensajes de solicitud y respuesta generados por el programa de aplicación de usuario correspondiente a un formato compatible con unas pantallas de aplicación genérica en base a plantillas de una unidad principal del vehículo. En un ejemplo, el componente de lenguaje de scripting incluye la lógica de aplicación de usuario correspondiente para obviar la lógica de aplicación de usuario específica en la unidad principal. En un ejemplo, el componente de lenguaje de scripting mantiene el estado de la aplicación para la lógica de la aplicación de usuario correspondiente para obviar el mantenimiento del estado en la unidad principal.
En un ejemplo, se realiza un procedimiento implementado por ordenador para uso en un teléfono móvil. El procedimiento implementado por ordenador incluye la identificación de un programa de aplicación de usuario instalado en un teléfono móvil; la solicitud de información específica para la aplicación de usuario identificada desde un servidor remoto; la recepción de información de aplicación de teléfono descargada desde un servidor remoto en respuesta a la solicitud de información, en el que la información de aplicación de teléfono permite ampliar una interfaz de usuario del programa de aplicación de usuario identificado para utilizar una pantalla de visualización de aplicación genérica de una unidad principal del vehículo.
En un ejemplo, el procedimiento implementado por ordenador incluye la instalación de una aplicación de software HAP en el teléfono móvil; y la instalación de una aplicación de software HUP ejecutable en una unidad principal del vehículo; en el que el HAP y el HUP están dispuestos a comunicar mensajes o eventos entre sí, y a utilizar aspectos de la información de la aplicación del teléfono para permitir que el programa de aplicación de usuario identificado en el teléfono móvil interactúe con la pantalla de visualización de la aplicación genérica de la unidad principal del vehículo.
En un ejemplo, el procedimiento implementado por ordenador incluye, en la aplicación de software HAP, la traducción de los mensajes de solicitud y respuesta generados por el correspondiente programa de aplicación de usuario a un formato compatible con unas pantallas de aplicación genérica basada en plantillas de una unidad principal de vehículo.
En un ejemplo, el procedimiento implementado por ordenador incluye, en la aplicación de software HAP, la traducción de los mensajes o eventos recibidos de la unidad principal del vehículo a un formato compatible con el correspondiente programa de aplicación del usuario.
En un ejemplo, el procedimiento implementado por ordenador incluye, en la aplicación de software HAP, la traducción de un mensaje de solicitud generado por el programa de aplicación de usuario correspondiente a un formato compatible con unas pantallas de visualización de aplicación genérica basada en plantillas de una unidad principal de vehículo con el fin de representar uno o más contenidos, texto e imágenes en una pantalla de visualización de aplicación genérica de la unidad principal de vehículo.
En un ejemplo, el procedimiento implementado por ordenador incluye la recepción de un mensaje desde la unidad principal; la interacción con el programa de aplicación del usuario en respuesta al mensaje recibido; y la devolución de un resultado proporcionado por el programa de aplicación del usuario a la unidad principal. En un ejemplo, el procedimiento implementado por ordenador incluye la traducción del resultado a un formato compatible con las pantallas de la aplicación genérica en base a plantillas de la unidad principal del vehículo. En un ejemplo, el procedimiento implementado por ordenador incluye la traducción del mensaje de evento de pulsación de botón de la unidad principal basado en un estado actual del programa de aplicación del usuario y en base a un identificador de botón enviado previamente a la unidad principal para su visualización.
En un ejemplo, se proporciona un procedimiento para extender una interfaz de usuario de una aplicación de usuario de teléfono inteligente a una HMI de una unidad principal de vehículo. El procedimiento incluye la instalación de un programa de aplicación de usuario en un teléfono inteligente; el acoplamiento comunicativo del teléfono inteligente a una unidad principal de un vehículo; y la ejecución de un componente de software HAP en el teléfono inteligente; en el que el HAP incluye una API para interconectarse con la aplicación de usuario, y una interfaz para comunicarse con una unidad principal del vehículo; la recepción en el HAP de una notificación de pulsación de botón desde la unidad principal-HMI; en el HAP, la asignación de la notificación de pulsación de botón a un control de interfaz de usuario específico de la aplicación de usuario en ejecución; y en el hA p , la comunicación del control de interfaz de usuario a la aplicación de usuario en ejecución.
En un ejemplo, la asignación se basa en un identificador visual de botón previamente enviado desde e1HAP a la unidad principal para su visualización con el fin de identificar visualmente un botón seleccionado en una pantalla táctil genérica de una unidad principal del vehículo.
En un ejemplo, el procedimiento incluye el mantenimiento del estado del programa de aplicación del usuario en e1HAP para obviar el mantenimiento del estado del programa de aplicación del usuario en la unidad principal.
Integración eficiente de la comunicación de la unidad central
HTTP es a menudo el enfoque de comunicación elegido por los diseñadores de IVI automotriz en el vehículo en el cual hay una necesidad de comunicación entre el IVI y las aplicaciones que se ejecutan en el teléfono celular del usuario, y para la comunicación entre las aplicaciones que se ejecutan en el IVI y los servidores de contenido y configuración que se ejecutan en Internet u otra conexión de red basada en IP.
En el caso de que la aplicación IVI necesite comunicarse con un sistema backend en Internet u otra conexión de red basada en IP usando HTTP, e IVI depende de teléfono celular del usuario con conexión a Internet como la vía de comunicación para esta comunicación, el teléfono celular del usuario incluye una aplicación que recibe la petición HTTP de IVI y luego en nombre de la aplicación IVI crea una petición HTTP a un terminal específico sobre la IP móvil de la red celular para marchar la intención de la petición IVI a ese terminal en Internet.
En esta misma conexión IP, la aplicación del teléfono móvil también recibe la respuesta del terminal en Internet. Una vez recibida la respuesta, la aplicación de telefonía móvil debe enviar la respuesta a la aplicación IVI como si se tratara de la respuesta a la solicitud original pendiente de IVI. Este enfoque es necesario para evitar el coste añadido impuesto por el operador de telefonía móvil cuando se utiliza el teléfono móvil como un simple dispositivo de acceso a la red de Internet (PPP->IP->TCP a la red celular).
Cuando una aplicación de telefonía móvil actúa como proxy intermedio para las peticiones HTTP entre una aplicación IVI y un servicio backend, introduce el riesgo de interceptación o manipulación de la comunicación. En una configuración de este tipo, una aplicación IVI no puede hacer uso de los mecanismos de seguridad de nivel de transporte estándar para garantizar que su comunicación con un servicio backend sea segura, ya que la aplicación del teléfono móvil está actuando como un "hombre en el medio". Si se requieren garantías de seguridad acordes con el nivel de seguridad del transporte, se debe implementar una seguridad personalizada sobre HTTP. Esta seguridad personalizada aumenta el coste de desarrollo del sistema, introduce la probabilidad de incompatibilidad con los servicios backend existentes y amplía la superficie de ataque a la seguridad del sistema en general.
Cuando una aplicación de telefonía móvil actúa como proxy intermedio para las peticiones HTTP entre la aplicación IVI y el backend, por definición limita el protocolo a nivel de aplicación que puede ser utilizado. En dicha configuración, se impide que IVI haga uso de protocolos que no sean HTTP. En su lugar, las aplicaciones existentes deben ser rediseñadas para soportar la tunelización de sus peticiones a través de HTTP. La canalización de las solicitudes a través de HTTP aumenta la complejidad y el coste del sistema, e introduce la probabilidad de incompatibilidad del sistema con los servicios backend existentes.
Para hacer frente a la multitud de problemas con una solución de proxy sólo HTTP, una solución alternativa o complementaria hace uso de un proxy TCP o UDP incrustado en la aplicación del teléfono móvil.
La FIG. 22 ilustra un sistema para la integración eficiente de la comunicación de la unidad central.
El sistema 2200 incluye una unidad principal 2201 y un dispositivo móvil 2203. La unidad principal 2201 puede incluir un dispositivo de procesamiento 2202 configurado para acoplarse al dispositivo móvil 2203 y transmitir al dispositivo móvil 2203 una solicitud para utilizar un recurso del dispositivo móvil. El dispositivo móvil 2203 puede incluir un dispositivo de procesamiento 2204 configurado para determinar si se autoriza la solicitud. El dispositivo de procesamiento 2204 puede estar configurado para utilizar un proxy del dispositivo móvil para establecer una conexión con un destino en respuesta a la determinación de autorizar la solicitud.
La FIG. 23 es un diagrama de comunicación simplificado que ilustra una aplicación de smartphone que permite el intercambio de datos entre un IVI y un backend (servidor remoto) utilizando el protocolo Proxy SOCKS (SOCKet Secure).
En una realización, se incluye un proxy SOCKS (SOCKet Secure) estándar dentro de la aplicación del teléfono móvil. El proxy SOCKS actúa como intermediario entre el entorno IVI y el backend de la red IP mayor. Al autorizar los datos en la capa TCP o UDP, el IVI y el backend pueden hacer uso de una mayor gama de servicios de red que los disponibles sólo con un proxy HTTP.
En un ejemplo, la unidad principal 2301 puede iniciar la negociación SOCKS con el dispositivo móvil 2303 para proporcionar una solicitud para utilizar un recurso del dispositivo móvil 2303, por ejemplo, transmitir el mensaje de solicitud SOCKS 2310. El dispositivo móvil 2303 puede estar configurado para, en respuesta a la recepción de la solicitud, determinar 2313 si se autoriza la solicitud. En un ejemplo, la solicitud puede indicar un destino (es decir, un servidor 2305) para que la unidad principal 2301 se comunique con un recurso del dispositivo móvil 2303, por ejemplo, un transceptor de largo alcance del dispositivo móvil 2303. El dispositivo móvil 2303 puede estar configurado para determinar si autoriza la solicitud en base a un identificador asociado al destino indicado. En un ejemplo, el dispositivo móvil 2303 puede estar configurado para determinar si el identificador está incluido en una lista blanca almacenada local o remotamente, por ejemplo, puede estar configurado para comparar el identificador con la lista blanca.
La autorización basada en el destino puede ser una parte de un esquema de refuerzo de políticas. Por ejemplo, el dispositivo móvil 2303 puede estar configurado para comprobar un estado de suscripción/cuenta asociado a la solicitud. El dispositivo móvil 2303 puede estar configurado para determinar que la solicitud está autorizada si el destino está incluido en la lista blanca y el estado de la suscripción/cuenta corresponde a un estado predefinido, por ejemplo, un estado activo.
El dispositivo móvil 2303 puede estar configurado para, en respuesta a la determinación de autorizar la solicitud, transmitir una comunicación 2316 para establecer una conexión con el destino indicado. En un ejemplo, el dispositivo móvil 2303 puede estar configurado para abrir un socket al destino indicado para establecer una conexión TCP o UDP.
El dispositivo móvil 2303 puede estar configurado para transmitir un mensaje de terminación SOCKS 2319 correspondiente al mensaje de solicitud SOCKS 2310. La unidad principal 2301 puede comunicarse (2322) con el servidor 2305 a través del transmisor de largo alcance y sobre la conexión 2316.
La FIG. 24 es un diagrama de comunicación simplificado que ilustra una aplicación de smartphone que proporciona una funcionalidad de servidor proxy transparente para permitir el intercambio de datos entre un IVI y un backend (servidor remoto).
En otro ejemplo, la unidad principal 2401 utiliza un socket TCP o UDP sin negociación SOCKS y el dispositivo móvil 2403 se encarga de autorizar de forma transparente el socket TCP o UDP a un terminal de destino en nombre de la IVI. La unidad principal 2401 puede estar configurada para transmitir una comunicación 2410 para proporcionar una solicitud de utilización de un recurso del dispositivo móvil 2303. Por ejemplo, la unidad principal 2401 puede estar configurada para abrir un socket a un puerto bien conocido.
El dispositivo móvil 2403 puede estar configurado para determinar 2413 si autoriza la solicitud. En un ejemplo, el dispositivo móvil 2403 puede estar configurado para identificar el puerto en el que se recibe la solicitud en el dispositivo móvil. El dispositivo móvil 2403 puede estar configurado para determinar si una asignación local o remota incluye una entrada correspondiente al puerto identificado. El dispositivo móvil 2403 puede estar configurado para no autorizar la solicitud en respuesta a la determinación de que la asignación no incluye la entrada. El dispositivo móvil 2403 puede estar configurado para descubrir un destino en respuesta a la determinación de que la asignación incluye la entrada. En un ejemplo, la asignación de los puertos conocidos a los destinos es proporcionada por el servidor 2405.
De forma similar al ejemplo anterior, la autorización en base al destino puede ser una parte de un esquema de refuerzo de políticas. Por ejemplo, el dispositivo móvil 2403 puede estar configurado para comprobar un estado de suscripción/cuenta asociado a la solicitud. El dispositivo móvil 2403 puede estar configurado para determinar que la solicitud está autorizada si la asignación incluye la entrada correspondiente al puerto identificado y el estado de la suscripción/cuenta corresponde a un estado predefinido, por ejemplo, un estado activo.
El dispositivo móvil 2403 puede estar configurado para, en respuesta a descubrir el destino, transmitir una comunicación 2416 para establecer una conexión con el destino indicado. En un ejemplo, el dispositivo móvil 2403 puede estar configurado para abrir un socket al destino descubierto para establecer una conexión TCP o UDP.
El dispositivo móvil 2303 puede estar configurado para transmitir un acuse de recibo 2419 correspondiente a la comunicación 2410. La unidad principal 2401 puede comunicarse (2422) con el servidor 2405 a través del transmisor de largo alcance y sobre la conexión 2416.
En cada uno de los ejemplos descritos con respecto a las FIGS. 23 y 24, la aplicación IVI y el backend pueden comunicarse con mayor flexibilidad, ya que el protocolo de aplicación ya no se limita a HTTP, aunque no se excluye HTTP. Además, la aplicación IVI y el backend pueden utilizar la seguridad a nivel de transporte, incluyendo, pero sin limitación, Secure Socket Layer (SSL) o Transport Layer Security (TLS) para proporcionar fuertes garantías de seguridad para la comunicación. Además, la falta de un proxy HTTP intermedio permite una mayor eficiencia cuando se transmiten las solicitudes entre la aplicación IVI y el servicio backend, dado que el proxy intermedio no necesita analizar las solicitudes y las respuestas antes de transmitirlas.
La FIG. 25 es un diagrama de comunicación simplificado que ilustra una aplicación de teléfono inteligente que permite el intercambio de datos entre un IVI y un backend (servidor remoto) utilizando el encadenamiento de protocolos SOCKS Proxy.
En un ejemplo, se incluye un proxy, por ejemplo un proxy SOCKS, dentro de1HUP y e1HAP. Esto se denomina cadena de proxy. La cadena de proxy actúa como intermediaria entre el entorno IVI y el backend de la red IP mayor. Al autorizar datos en la capa TCP o UDP, el IVI y el backend pueden hacer uso de una mayor gama de servicios de red que los disponibles con un proxy HTTP solamente.
En un ejemplo, la unidad principal 2501 puede incluir una aplicación IVI 2502 con un cliente proxy SOCKS y un servidor proxy SOCKS 2504. La unidad principal 2501 puede iniciar la negociación SOCKS con el dispositivo móvil 2503 para proporcionar una solicitud de utilización de un recurso del dispositivo móvil 2503, por ejemplo, transmitir la comunicación de encadenamiento de proxy SOCKS 2510 para un mensaje de solicitud SOCKS originado por la aplicación IVI 2502.
La unidad principal 2501 puede estar configurada para realizar una porción inicial de una verificación de autorización antes de la transmisión de la comunicación de cadena de proxy 2510. Por ejemplo, la unidad principal 2501 puede estar configurada para comprobar el estado de la suscripción/cuenta y, en un ejemplo, hacer que se transmita la comunicación de encadenamiento del proxy 2510 en respuesta a la determinación de que el estado de la suscripción/cuenta corresponde a un estado predefinido de la suscripción/cuenta, por ejemplo, un estado activo de la suscripción/cuenta. Si el estado de la suscripción/cuenta no corresponde al estado predefinido de la suscripción/cuenta, por ejemplo, corresponde a un estado de suscripción/cuenta inactivo, la comunicación de cadena proxy 2510 no se transmite.
El dispositivo móvil 2503 puede estar configurado para, en respuesta a la recepción de la solicitud de la comunicación de cadena proxy SOCKS 2510, determinar 2513 si autorizar la solicitud. En un ejemplo, la determinación por parte del dispositivo móvil 2503 es una porción posterior del esquema de autorización. En un ejemplo, la porción posterior puede basarse en un destino asociado a la solicitud. Por ejemplo, la solicitud puede indicar un destino (es decir, un servidor 2505) para que la unidad principal 2501 se comunique con un recurso del dispositivo móvil 2503, por ejemplo, un transceptor de largo alcance del dispositivo móvil 2503. El dispositivo móvil 2503 puede estar configurado para determinar si autoriza la solicitud en base a un identificador asociado al destino indicado. En un ejemplo, el dispositivo móvil 2503 puede estar configurado para determinar si el identificador está incluido en una lista blanca almacenada local o remotamente, por ejemplo, puede estar configurado para comparar el identificador con la lista blanca.
En el ejemplo anterior, la aplicación de un esquema de autorización se distribuye entre la unidad principal 2501 y el dispositivo móvil 2503. En otro ejemplo de cadena de protocolos Proxy SOCKS, la aplicación de un esquema de autorización puede ser realizada por la unidad principal 2501 o el dispositivo móvil 2503.
El dispositivo móvil 2503 puede estar configurado para, en respuesta a la determinación de autorizar la solicitud, transmitir una comunicación 2516 para establecer una conexión con el destino indicado. En un ejemplo, el dispositivo móvil 2503 puede estar configurado para abrir un socket al destino indicado para establecer una conexión TCP o UDP.
El dispositivo móvil 2503 puede estar configurado para transmitir un mensaje de finalización SOCKS 2519 correspondiente al mensaje de solicitud SOCKS 2510. La unidad principal 2501 puede comunicarse (2522) con el servidor 2505 a través del transmisor de largo alcance y sobre la conexión 2516.
La FIG. 26 es un diagrama de comunicación simplificado que ilustra una aplicación de teléfono inteligente que proporciona una funcionalidad de servidor proxy transparente para permitir el intercambio de datos entre un IVI y un backend (servidor remoto) utilizando cadena proxy transparente.
En otro ejemplo, las aplicaciones IVI no necesitan implementar el protocolo de cliente SOCKS. En su lugar, la aplicación IVI utiliza un socket TCP o UDP sin negociación SOCKS y la aplicación de la unidad principal se encarga de encadenar de forma transparente el socket TCP o UDP a un terminal de destino en nombre de la iV i.
En un ejemplo, la unidad principal 2601 puede incluir una aplicación IVI 2602 sin un cliente proxy SOCKS y un servidor proxy transparente 2604. La aplicación IVI 2602 puede abrir un socket a un puerto bien conocido con el fin de iniciar una solicitud para utilizar un recurso de un dispositivo remoto.
De forma similar al ejemplo anterior, la unidad principal 2601 puede estar configurada para realizar una parte inicial de una verificación de autorización antes de abrir el socket al puerto conocido. Por ejemplo, la unidad principal 2601 puede estar configurada para verificar el estado de la suscripción/cuenta y, en un ejemplo, hacer que se abra un socket al puerto conocido en respuesta a la determinación de que el estado de la suscripción/cuenta corresponde a un estado predefinido de la suscripción/cuenta, por ejemplo, un estado activo de la suscripción/cuenta. Si el estado de la suscripción/cuenta no se corresponde con el estado predefinido de la suscripción/cuenta, por ejemplo, corresponde a un estado de suscripción/cuenta inactivo, el socket no se abre.
El dispositivo móvil 2603 puede estar configurado para, en respuesta a la recepción de la solicitud del mensaje de solicitud SOCKS 2610, determinar 2613 si autorizar la solicitud. En un ejemplo, la determinación por parte del dispositivo móvil 2603 es una porción posterior del esquema de autorización. En un ejemplo, la porción posterior puede basarse en un destino asociado a la solicitud. Por ejemplo, la solicitud puede indicar un destino (es decir, un servidor 2605) para que la unidad principal 2601 se comunique con un recurso del dispositivo móvil 2603, por ejemplo, un transceptor de largo alcance del dispositivo móvil 2603. El dispositivo móvil 2603 puede estar configurado para determinar si autoriza la solicitud basándose en un identificador asociado al destino indicado. En un ejemplo, el dispositivo móvil 2603 puede estar configurado para determinar si el identificador está incluido en una lista blanca almacenada local o remotamente, por ejemplo, puede estar configurado para comparar el identificador con la lista blanca.
En otro ejemplo de cadena de proxy, la aplicación de un esquema de autorización puede ser realizada por la unidad principal 2601 o el dispositivo móvil 2603. Como ejemplo del esquema de autorización realizado por la unidad principal 2601, la unidad principal 2601 puede estar configurada para determinar si autoriza la solicitud en respuesta a la apertura del socket. Por ejemplo, la unidad principal 2601 puede estar configurada para identificar el puerto en el que se recibe la solicitud en el servidor proxy transparente 2604. La unidad principal 2601 puede estar configurada para determinar si una asignación local o remota incluye una entrada correspondiente al puerto identificado. La unidad principal 2601 puede estar configurada para no autorizar la solicitud en respuesta a la determinación de que la asignación no incluye la entrada. La unidad principal 2601 puede estar configurada para descubrir un destino en respuesta a la determinación de que la asignación incluye la entrada. La unidad principal 2601 puede estar configurada para compartir el descubrimiento del destino con el dispositivo móvil 2603.
Independientemente del dispositivo o dispositivos que realicen la autorización, el dispositivo móvil 2603 puede estar configurado para, tras el descubrimiento del destino, transmitir una comunicación 2616 para establecer una conexión con el destino indicado. En un ejemplo, el dispositivo móvil 2603 puede estar configurado para abrir un socket al destino descubierto para establecer una conexión TCP o UDP.
El dispositivo móvil 2603 puede estar configurado para transmitir un mensaje de finalización SOCKS 2619 correspondiente a la comunicación 2610. La unidad principal 2601 puede comunicarse (2622) con el servidor 2605 a través del transmisor de largo alcance y sobre la conexión 2616.
En cada uno de los ejemplos descritos con respecto a las FIGS. 25 y 26, la aplicación IVI y el backend pueden comunicarse con mayor flexibilidad, ya que el protocolo de aplicación ya no se limita a HTTP, aunque no se excluye HTTP. Además, la aplicación IVI y el backend pueden utilizar la seguridad a nivel de transporte incluyendo, pero sin limitación, SSL o TLS para proporcionar fuertes garantías de seguridad para la comunicación. Además, la falta de un proxy HTTP intermedio permite una mayor eficiencia cuando se transmiten las solicitudes entre la aplicación IVI y el servicio backend, dado que el proxy intermedio no necesita analizar las solicitudes y las respuestas antes de transmitirlas.
En un ejemplo, se proporciona un procedimiento. El procedimiento incluye el acoplamiento de un dispositivo móvil y una unidad principal del vehículo; la recepción, en el dispositivo móvil, de una solicitud para que la unidad principal del vehículo utilice un recurso del dispositivo móvil; la determinación, por parte del dispositivo móvil, de si se autoriza la solicitud; y en respuesta a la determinación de autorizar la solicitud, la utilización de un proxy del dispositivo móvil para establecer una conexión con un destino.
En un ejemplo, la determinación se basa en un identificador asociado al destino. En un ejemplo, el procedimiento incluye determinar si el identificador o el destino están incluidos en una lista blanca.
En un ejemplo, el procedimiento incluye identificar un puerto en el que se recibe la solicitud en el dispositivo móvil; determinar si una asignación incluye una entrada correspondiente al puerto identificado; y en respuesta a determinar que la asignación incluye la entrada, descubrir el destino.
En un ejemplo, el proxy del dispositivo móvil comprende un primer servidor proxy que es diferente de un segundo servidor proxy que transmitió la solicitud de la unidad principal del vehículo. En un ejemplo, el primer servidor proxy comprende un primer servidor proxy SOCKS. En un ejemplo, la determinación se basa en un identificador asociado al destino. En un ejemplo, el procedimiento incluye determinar si el identificador o el destino están incluidos en una lista blanca. En un ejemplo, el procedimiento incluye la identificación de un puerto en el que se recibe la solicitud en el dispositivo móvil; la determinación de si una asignación incluye una entrada correspondiente al puerto identificado; y en respuesta a la determinación de que la asignación incluye la entrada, el descubrimiento del destino. En un ejemplo, la determinación, por parte del dispositivo móvil, de si se debe autorizar la solicitud comprende además la comprobación de un estado de suscripción/cuenta asociado a la solicitud; y la determinación de autorizar la solicitud en respuesta a la determinación de que la asignación incluye la entrada y el estado de suscripción/cuenta corresponde a un estado de suscripción/cuenta predefinido.
En un ejemplo, se proporciona un dispositivo de memoria especialmente configurado. El dispositivo de memoria tiene instrucciones almacenadas que, en respuesta a la ejecución por un dispositivo de procesamiento, hacen que el dispositivo de procesamiento realice operaciones que incluyen el acoplamiento de un dispositivo móvil y una unidad principal del vehículo; la recepción, en el dispositivo móvil, de una solicitud para que la unidad principal del vehículo utilice un recurso del dispositivo móvil; la determinación, por parte del dispositivo móvil, de si se autoriza la solicitud; y en respuesta a la determinación de autorizar la solicitud, la utilización de un proxy del dispositivo móvil para establecer una conexión con un destino.
En un ejemplo, la determinación se basa en un identificador asociado al destino. En un ejemplo, las operaciones incluyen determinar si el identificador o el destino están incluidos en una lista blanca.
En un ejemplo, las operaciones incluyen la identificación de un puerto en el que se recibe la solicitud en el dispositivo móvil; la determinación de si una asignación incluye una entrada correspondiente al puerto identificado; y en respuesta a la determinación de que la asignación incluye la entrada, el descubrimiento del destino.
En un ejemplo, el proxy del dispositivo móvil comprende un primer servidor proxy que es diferente de un segundo servidor proxy que transmitió la solicitud de la unidad principal del vehículo. En un ejemplo, el primer servidor proxy comprende un primer servidor proxy SOCKS. En un ejemplo, la determinación se basa en un identificador asociado al destino. En un ejemplo, las operaciones incluyen determinar si el identificador o el destino están incluidos en una lista blanca. En un ejemplo, las operaciones incluyen la identificación de un puerto en el que se recibe la solicitud en el dispositivo móvil; la determinación de si una asignación incluye una entrada correspondiente al puerto identificado; y en respuesta a la determinación de que la asignación incluye la entrada, el descubrimiento del destino. En un ejemplo, la determinación, por parte del dispositivo móvil, de si se debe autorizar la solicitud comprende además la comprobación de un estado de suscripción/cuenta asociado a la solicitud; y la determinación de autorizar la solicitud en respuesta a la determinación de que la asignación incluye la entrada y el estado de suscripción/cuenta corresponde a un estado de suscripción/cuenta predefinido.
Será evidente para aquellos con experiencia en la técnica que se pueden hacer muchos cambios en los detalles de las realizaciones descritas anteriormente sin apartarse de los principios subyacentes de la invención. Por lo tanto, el alcance de la presente invención debe determinarse únicamente por las siguientes reivindicaciones.
La mayoría de los equipos mencionados anteriormente comprenden hardware y software asociado. Por ejemplo, es probable que el dispositivo de navegación típico incluya uno o más procesadores y software ejecutable en esos procesadores para llevar a cabo las operaciones descritas. Se utiliza el término software en su sentido común para hacer referencia a programas o rutinas (subrutinas, objetos, complementos, etc.), así como a los datos, utilizables por una máquina o procesador. Como es bien sabido, los programas informáticos generalmente comprenden instrucciones que se almacenan en medios de almacenamiento legibles por máquina o por ordenador. Algunas realizaciones de la presente invención pueden incluir programas o instrucciones ejecutables que se almacenan en medios de almacenamiento legibles por máquina o por ordenador, como una memoria digital. Esto no implica que se requiera un "ordenador" en el sentido convencional en ninguna realización particular. Por ejemplo, se pueden utilizar diversos procesadores, integrados o no, en equipos como los componentes descritos en la presente memoria.
La memoria para el almacenamiento de software es bien conocida. En algunas realizaciones, la memoria asociada a un determinado procesador puede almacenarse en el mismo dispositivo físico que el procesador (memoria "a bordo"); por ejemplo, memoria RAM o FLASH dispuesta dentro de un microprocesador de circuito integrado o similar. En otros ejemplos, la memoria comprende un dispositivo independiente, como una unidad de disco externa, una matriz de almacenamiento o un llavero FLASH portátil. En tales casos, la memoria se "asocia" con el procesador digital cuando ambos están operativamente acoplados o en comunicación entre sí, por ejemplo, mediante un puerto de E/S, una conexión de red, etc., de manera que el procesador puede leer un archivo almacenado en la memoria. La memoria asociada puede ser de "sólo lectura" por diseño (ROM) o en virtud de la configuración de permisos, o no. Otros ejemplos son, entre otros, WORM, EPROM, EEPROM, FLASH, etc. Estas tecnologías suelen implementarse en dispositivos semiconductores de estado sólido. Otras memorias pueden incluir partes móviles, tal como una unidad de disco giratorio convencional. Todas estas memorias son "legibles por máquina" o "legibles por ordenador" y pueden utilizarse para almacenar instrucciones ejecutables para implementar las funciones descritas en la presente memoria.
Un "producto de software" se refiere a un dispositivo de memoria en el que se almacenan una serie de instrucciones ejecutables en una forma legible por la máquina, de modo que una máquina o procesador adecuado, con acceso apropiado al producto de software, pueda ejecutar las instrucciones para llevar a cabo un proceso implementado por las instrucciones. Los productos de software se utilizan a menudo para distribuir software. Cualquier tipo de memoria legible por máquina, incluyendo sin limitación las resumidas anteriormente, puede ser utilizada para hacer un producto de software. Dicho esto, también es sabido que los programas informáticos pueden distribuirse a través de una transmisión electrónica ("descarga"), en cuyo caso normalmente habrá un producto informático correspondiente en el extremo transmisor de la transmisión, o en el extremo receptor, o en ambos.
Habiendo descrito e ilustrado los principios de la invención en una de sus realizaciones preferentes, debe ser aparente que la invención puede ser modificada en su disposición y detalle sin apartarse del alcance de la invención como se define en las reivindicaciones. Se reivindican todas las modificaciones y variaciones que entran en el alcance de la invención tal y como se define en las siguientes reivindicaciones.

Claims (6)

REIVINDICACIONES
1. Un procedimiento, realizado por un sistema que comprende un dispositivo móvil y un vehículo de motor, comprendiendo el procedimiento:
acoplar un dispositivo móvil (20) y una interfaz de usuario alimentada por el vehículo de motor;
recibir (2310), en el dispositivo móvil, una solicitud para que la interfaz de usuario utilice un recurso del dispositivo móvil;
caracterizado por:
determinar (2313), por el dispositivo móvil, en base a un identificador asociado con un destino indicado por la solicitud, si se autoriza la solicitud; y
en respuesta a la determinación de autorizar la solicitud, utilizar un proxy del dispositivo móvil para establecer una conexión con el destino, en el que la interfaz de usuario y el destino utilizan seguridad de nivel de transporte para el intercambio de datos sobre la conexión (2322).
2. El procedimiento de la reivindicación 1, que comprende además determinar si el identificador o el destino están incluidos en una lista blanca.
3. El procedimiento de la reivindicación 1, en el que el proxy del dispositivo móvil (20) comprende un primer servidor proxy que es diferente de un segundo servidor proxy que transmitió la solicitud de la interfaz de usuario.
4. El procedimiento de la reivindicación 3, en el que el primer servidor proxy comprende un primer servidor proxy SOCKS.
5. El procedimiento de cualquier reivindicación anterior, en el que la interfaz de usuario es una unidad principal del vehículo de motor.
6. Un dispositivo de memoria que contiene instrucciones almacenadas que, en respuesta a la ejecución por un dispositivo de procesamiento, hacen que el dispositivo de procesamiento realice el procedimiento de cualquier reivindicación anterior.
ES13836234T 2012-12-20 2013-12-19 Integración eficaz de comunicación de unidad principal Active ES2882885T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201261740376P 2012-12-20 2012-12-20
PCT/US2013/076710 WO2014100489A2 (en) 2012-12-20 2013-12-19 Efficient headunit communication integration

Publications (1)

Publication Number Publication Date
ES2882885T3 true ES2882885T3 (es) 2021-12-03

Family

ID=50241504

Family Applications (1)

Application Number Title Priority Date Filing Date
ES13836234T Active ES2882885T3 (es) 2012-12-20 2013-12-19 Integración eficaz de comunicación de unidad principal

Country Status (7)

Country Link
US (3) US9370029B2 (es)
EP (1) EP2936861B1 (es)
JP (2) JP6396320B2 (es)
CN (1) CN104919833B (es)
CA (1) CA2895126C (es)
ES (1) ES2882885T3 (es)
WO (1) WO2014100489A2 (es)

Families Citing this family (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101664430B1 (ko) 2009-11-13 2016-10-10 삼성전자주식회사 리모트 ｕｉ 서비스 제공 방법 및 장치
US9002322B2 (en) 2011-09-29 2015-04-07 Apple Inc. Authentication with secondary approver
US11005720B2 (en) 2011-11-16 2021-05-11 Autoconnect Holdings Llc System and method for a vehicle zone-determined reconfigurable display
DE102012206745A1 (de) * 2012-04-24 2013-10-24 Mtu Friedrichshafen Gmbh Verfahren zum Betrieb einer Brennkraftmaschine, Brennkraftmaschine und Wartungssystem für eine Brennkraftmaschine, selbstausführbares Computerprogrammprodukt und nichtflüchtiges Speichermedium
JP6154894B2 (ja) 2012-06-08 2017-06-28 エアビクティ インコーポレイテッド 電子センサデータを評価して、自動車を遠隔的に識別し運転者の挙動を監視する方法
CA2895126C (en) 2012-12-20 2021-08-03 Airbiquity Inc. Efficient headunit communication integration
US9958289B2 (en) 2013-09-26 2018-05-01 Google Llc Controlling navigation software on a portable device from the head unit of a vehicle
US10054463B2 (en) 2013-09-26 2018-08-21 Google Llc Systems and methods for providing navigation data to a vehicle
US9109917B2 (en) 2013-09-26 2015-08-18 Google Inc. Systems and methods for providing input suggestions via the head unit of a vehicle
JP6239990B2 (ja) * 2014-01-22 2017-11-29 クラリオン株式会社 接続装置、プログラムおよび接続方法
US9576474B2 (en) * 2014-02-04 2017-02-21 General Motors Llc Providing cellular data to a vehicle over different data channels
KR101610199B1 (ko) * 2014-04-01 2016-04-07 주식회사 오비고 차량의 헤드 유닛을 이용하여 복수의 애플리케이션을 관리하기 위한 방법, 장치 및 컴퓨터 판독 가능한 기록 매체
US20150312317A1 (en) * 2014-04-29 2015-10-29 Ford Global Technologies, Llc Vehicle proxy lifecycle management
US9324067B2 (en) 2014-05-29 2016-04-26 Apple Inc. User interface for payments
US20150370419A1 (en) * 2014-06-20 2015-12-24 Google Inc. Interface for Multiple Media Applications
US20150370446A1 (en) * 2014-06-20 2015-12-24 Google Inc. Application Specific User Interfaces
US9539902B2 (en) 2014-11-20 2017-01-10 Toyota Motor Engineering & Manufacturing North America, Inc. System for synchronization of applications between vehicle head unit and companion device
KR101673305B1 (ko) * 2014-12-11 2016-11-22 현대자동차주식회사 이기종간 멀티 스트리밍 서비스를 제공하는 헤드 유닛 및 그의 스트리밍 제어 방법, 그리고 이를 실행하는 프로그램이 기록된 컴퓨터 판독 가능한 기록매체
WO2016183096A1 (en) 2015-05-14 2016-11-17 Airbiquity Inc. Centralized management of mobile-assisted motor vehicle software upgrading and vehicle data analytics
CN114608605A (zh) 2015-06-23 2022-06-10 谷歌有限责任公司 在汽车环境中的移动地理应用
US10817593B1 (en) * 2015-12-29 2020-10-27 Wells Fargo Bank, N.A. User information gathering and distribution system
US10045147B2 (en) * 2016-01-20 2018-08-07 Livio, Inc. Application control of primary-connected devices from secondary-connected devices
US10232709B2 (en) * 2016-02-19 2019-03-19 Xevo Inc. Dynamic application execution for automobile and cloud hybrid environments
US9775138B1 (en) 2016-05-06 2017-09-26 Ford Global Technologies, Llc Mechanism for moveable telematics services
US20170337900A1 (en) * 2016-05-17 2017-11-23 Google Inc. Wireless user interface projection for vehicles
CN114693289A (zh) 2016-06-11 2022-07-01 苹果公司 用于交易的用户界面
US10621581B2 (en) 2016-06-11 2020-04-14 Apple Inc. User interface for transactions
DK201670622A1 (en) 2016-06-12 2018-02-12 Apple Inc User interfaces for transactions
US10496808B2 (en) 2016-10-25 2019-12-03 Apple Inc. User interface for managing access to credentials for use in an operation
US20200019415A1 (en) * 2016-12-22 2020-01-16 Volkswagen Aktiengesellschaft User terminal, user interface, computer program product, signal sequence, means of transport, and method for setting up a user interface of a means of transport
US10752192B2 (en) * 2017-03-16 2020-08-25 Robert Bosch Gmbh Intelligent event system and method for a vehicle
US10269192B2 (en) 2017-04-07 2019-04-23 Airbiquity Inc. Technologies for verifying control system operation
GB2565282B (en) * 2017-08-02 2021-12-22 Vnc Automotive Ltd Remote control of a computing device
KR102185854B1 (ko) 2017-09-09 2020-12-02 애플 인크. 생체측정 인증의 구현
KR102143148B1 (ko) 2017-09-09 2020-08-10 애플 인크. 생체측정 인증의 구현
JP6759169B2 (ja) 2017-09-11 2020-09-23 株式会社東芝 情報処理装置、情報処理方法、および情報処理プログラム
US10567321B2 (en) 2018-01-02 2020-02-18 Snap Inc. Generating interactive messages with asynchronous media content
US10523606B2 (en) * 2018-01-02 2019-12-31 Snap Inc. Generating interactive messages with asynchronous media content
US11170085B2 (en) 2018-06-03 2021-11-09 Apple Inc. Implementation of biometric authentication
US11063889B2 (en) 2018-06-08 2021-07-13 Snap Inc. Generating interactive messages with entity assets
KR20200119601A (ko) * 2019-04-10 2020-10-20 현대모비스 주식회사 차량의 바이너리 데이터 처리 장치 및 방법
CN110233774B (zh) * 2019-05-28 2020-12-29 华中科技大学 一种Socks代理服务器的探测方法、分布式探测方法和系统
DE102019118189A1 (de) * 2019-07-05 2021-01-07 Bayerische Motoren Werke Aktiengesellschaft Koppelung von Benutzeroberflächen
US11366879B2 (en) * 2019-07-08 2022-06-21 Microsoft Technology Licensing, Llc Server-side audio rendering licensing
US11536581B2 (en) * 2019-10-11 2022-12-27 Toyota Motor Engineering & Manufacturing North America, Inc. Methods and systems for determining a usage preference of a vehicle operator
US11893092B2 (en) * 2020-01-17 2024-02-06 Sony Group Corporation Privilege auto platform
US11265274B1 (en) 2020-02-28 2022-03-01 Snap Inc. Access and routing of interactive messages
US11816194B2 (en) * 2020-06-21 2023-11-14 Apple Inc. User interfaces for managing secure operations
US11800324B2 (en) 2020-12-31 2023-10-24 Andrew Lyle GELTZ Apparatuses, computer-implemented methods, and computer program products for improved data transmission and tracking
US11784956B2 (en) 2021-09-20 2023-10-10 Apple Inc. Requests to add assets to an asset account
US20230290170A1 (en) * 2022-03-08 2023-09-14 Rockwell Automation Technologies, Inc. Systems and methods for providing extraction on industrial diagrams and graphics
DE102022107431B3 (de) 2022-03-29 2023-05-11 Volkswagen Aktiengesellschaft Verfahren zum Nachrüsten einer Socks-Kompatibilität für zumindest eine Anwendung in einem Kraftfahrzeug sowie entsprechend eingerichtetes Kraftfahrzeug
CN116708551B (zh) * 2022-09-27 2024-04-02 荣耀终端有限公司 代理上网方法和装置

Family Cites Families (264)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6850252B1 (en) * 1999-10-05 2005-02-01 Steven M. Hoffberg Intelligent electronic appliance system and method
JPH08223059A (ja) 1995-02-16 1996-08-30 Pioneer Electron Corp 放送局関連情報を有するデータベースを備えたｒｂｄｓ受信装置
US5794164A (en) 1995-11-29 1998-08-11 Microsoft Corporation Vehicle computer system
CA2242494C (en) 1996-02-29 2006-05-23 Janssen Pharmaceutica N.V. Novel n-substituted 4-((4'-aminobenzoyl)-oxymethyl)-piperidines having gastric prokinetic properties
JP4381486B2 (ja) 1996-11-28 2009-12-09 ソニー株式会社 送受信装置および送受信方法、受信装置および受信方法、並びに送信装置および送信方法
US6324592B1 (en) 1997-02-25 2001-11-27 Keystone Aerospace Apparatus and method for a mobile computer architecture and input/output management system
US5798695A (en) 1997-04-02 1998-08-25 Northrop Grumman Corporation Impaired operator detection and warning system employing analysis of operator control actions
US6144336A (en) 1997-05-19 2000-11-07 Integrated Data Communications, Inc. System and method to communicate time stamped, 3-axis geo-position data within telecommunication networks
US6493338B1 (en) 1997-05-19 2002-12-10 Airbiquity Inc. Multichannel in-band signaling for data communications over digital wireless telecommunications networks
US6690681B1 (en) 1997-05-19 2004-02-10 Airbiquity Inc. In-band signaling for data communications over digital wireless telecommunications network
DE19730904A1 (de) 1997-07-18 1999-02-11 Daimler Benz Ag Verfahren zur Bewertung von Betätigungen des Fahrpedals durch einen Fahrzeugführer zur Erkennung der Aktivität und Nervosität des Fahrzeugführers
JPH1155201A (ja) 1997-07-29 1999-02-26 Sony Corp 情報処理装置および方法、情報処理システム、並びに伝送媒体
US6105063A (en) 1998-05-05 2000-08-15 International Business Machines Corp. Client-server system for maintaining application preferences in a hierarchical data structure according to user and user group or terminal and terminal group contexts
JP3889510B2 (ja) 1998-05-21 2007-03-07 アルパイン株式会社 車載機器制御システム
JP2000009481A (ja) 1998-06-25 2000-01-14 Sanyo Electric Co Ltd ナビゲーション装置
US6185484B1 (en) 1998-08-05 2001-02-06 Eaton Corporation Method of operating a motor vehicle management computer system
US6434450B1 (en) 1998-10-19 2002-08-13 Diversified Software Industries, Inc. In-vehicle integrated information system
US6553375B1 (en) 1998-11-25 2003-04-22 International Business Machines Corporation Method and apparatus for server based handheld application and database management
US6487717B1 (en) 1999-01-15 2002-11-26 Cummins, Inc. System and method for transmission of application software to an embedded vehicle computer
AU771017B2 (en) 1999-01-22 2004-03-11 Pointset Corporation Method and apparatus for setting programmable features of an appliance
US7289611B2 (en) 1999-01-22 2007-10-30 Pointset Corporation Method and apparatus for setting programmable features of motor vehicle
US20020087655A1 (en) 1999-01-27 2002-07-04 Thomas E. Bridgman Information system for mobile users
JP2000339345A (ja) 1999-03-25 2000-12-08 Sony Corp 検索システム、検索装置および方法、ならびに、入力装置および方法
US6243642B1 (en) 1999-03-31 2001-06-05 Detroit Diesel Corporation System and method for detecting cold engine operation
US6674993B1 (en) 1999-04-30 2004-01-06 Microvision, Inc. Method and system for identifying data locations associated with real world observations
US6377810B1 (en) * 1999-06-11 2002-04-23 Motorola, Inc. Method of operation of mobile wireless communication system with location information
US20110208567A9 (en) 1999-08-23 2011-08-25 Roddy Nicholas E System and method for managing a fleet of remote assets
US6799201B1 (en) 2000-09-19 2004-09-28 Motorola, Inc. Remotely configurable multimedia entertainment and information system for vehicles
US7388953B2 (en) 1999-09-24 2008-06-17 Verizon Business Global Llc Method and system for providing intelligent network control services in IP telephony
US6535811B1 (en) 1999-11-03 2003-03-18 Holley Performance Products, Inc. System and method for real-time electronic engine control
US6559773B1 (en) 1999-12-21 2003-05-06 Visteon Global Technologies, Inc. Reconfigurable display architecture with spontaneous reconfiguration
US6973476B1 (en) 2000-03-10 2005-12-06 Atheros Communications System and method for communicating data via a wireless high speed link
CA2401939C (en) 2000-03-21 2011-06-21 Airbiquity Inc. Improved in-band signaling for data communications over digital wireless telecommunications networks
JP2002058013A (ja) 2000-05-30 2002-02-22 Ikuo Ota 放送情報コンテンツ配信システム、放送情報コンテンツ配信サイト、ユーザ受信端末、ユーザ受信プログラムを記録したコンピュータ読み取り可能な記録媒体及び放送情報コンテンツ配信方法
US7069434B1 (en) * 2000-06-13 2006-06-27 Hewlett-Packard Development Company, L.P. Secure data transfer method and system
WO2002003199A1 (fr) 2000-07-03 2002-01-10 Access Co., Ltd. Dispositif terminal d'informations mobile, serveur de stockage et procede permettant la mise a disposition d'une region de stockage
US7062528B2 (en) 2000-07-14 2006-06-13 Sony Corporation Method and system for identifying a time specific event
US20020103622A1 (en) 2000-07-17 2002-08-01 Burge John R. Decision-aid system based on wirelessly-transmitted vehicle crash sensor information
DE10037397A1 (de) 2000-08-01 2002-02-14 Daimler Chrysler Ag Verfahren zum Laden von Software
US20060025907A9 (en) 2000-08-18 2006-02-02 Nnt, Inc. Vehicle-interactive system
GB2366691B (en) 2000-08-31 2002-11-06 F Secure Oyj Wireless device management
AU2001288749A1 (en) 2000-09-06 2002-03-22 Robert Agresta System, device and method for remotely providing, accessing and using personal entertainment media
US6356812B1 (en) 2000-09-14 2002-03-12 International Business Machines Corporation Method and apparatus for displaying information in a vehicle
JP2002099513A (ja) 2000-09-25 2002-04-05 Pioneer Electronic Corp データ通信システム
DE10056076A1 (de) 2000-11-07 2002-06-13 Behr Thermot Tronik Gmbh Ventilgehäuse
FR2816741B1 (fr) 2000-11-10 2003-03-14 Renault Dispositif et procede d'aide au diagnostic d'un vehicule automobile
US6944679B2 (en) 2000-12-22 2005-09-13 Microsoft Corp. Context-aware systems and methods, location-aware systems and methods, context-aware vehicles and methods of operating the same, and location-aware vehicles and methods of operating the same
US6812942B2 (en) 2000-12-28 2004-11-02 International Business Machines Corporation Context-responsive in-vehicle display system
US6650534B2 (en) 2001-04-06 2003-11-18 Sony Corporation E-marker device with cord and plug attachment
US20020190856A1 (en) 2001-06-04 2002-12-19 Vehiclesense, Inc. Wireless vehicle detection systems
JP2003005883A (ja) 2001-06-26 2003-01-08 Imobile Inc 端末機能設定方法、端末機能設定システム、端末及びプログラム
FI111494B (fi) 2001-06-29 2003-07-31 Nokia Corp Langaton käyttöliittymän laajennus
US7107234B2 (en) 2001-08-17 2006-09-12 Sony Corporation Electronic music marker device delayed notification
US7127454B2 (en) 2001-08-17 2006-10-24 Sony Corporation E-marker find music
JP2003085388A (ja) 2001-09-10 2003-03-20 Nikon Gijutsu Kobo:Kk 製品情報提供方法および製品情報提供システム
JP3715224B2 (ja) 2001-09-18 2005-11-09 本田技研工業株式会社 車両に搭載されるエンターテイメントシステム
US7234111B2 (en) 2001-09-28 2007-06-19 Ntt Docomo, Inc. Dynamic adaptation of GUI presentations to heterogeneous device platforms
CN100354841C (zh) 2001-10-17 2007-12-12 因佛卡斯公司 数据会议方法、装置和系统
US6981022B2 (en) 2001-11-02 2005-12-27 Lucent Technologies Inc. Using PSTN to convey participant IP addresses for multimedia conferencing
JP2003216261A (ja) 2002-01-22 2003-07-31 Citizen Watch Co Ltd 外部機器設定システム
JP2003222523A (ja) 2002-01-30 2003-08-08 Sony Corp 車載機器、コンピュータ装置およびアプリケーションの動作管理方法
US6915176B2 (en) 2002-01-31 2005-07-05 Sony Corporation Music marking system
US20030147534A1 (en) 2002-02-06 2003-08-07 Ablay Sewim F. Method and apparatus for in-vehicle device authentication and secure data delivery in a distributed vehicle network
JP4510467B2 (ja) 2002-02-19 2010-07-21 スリーエム イノベイティブ プロパティズ カンパニー 高エネルギー電気化学電池のための温度制御装置および方法
CN1820474A (zh) * 2002-03-20 2006-08-16 全球通讯公司 共享的专用接入线路(dal)的网关路由选择判别
TW552501B (en) 2002-03-22 2003-09-11 Taiwan Semiconductor Mfg Version recording and tracking method
US6961536B2 (en) 2002-03-28 2005-11-01 International Business Machines Corporation Receiver control using vehicle state conditions
JP2003308211A (ja) 2002-04-15 2003-10-31 Mitsubishi Electric Corp 移動端末、サービス配信サーバ及びサービス配信システム
US20030195845A1 (en) 2002-04-16 2003-10-16 Anton Francis M. Method of conducting business among entities participating in a system for distributed network authentication, access and aggregation
US7218925B2 (en) 2002-06-06 2007-05-15 General Motors Corporation Method of initiating a telematics service
DE10226425A1 (de) 2002-06-13 2003-12-24 Bosch Gmbh Robert Verfahren zur Unterstützung des Fahrers bei der Entgegennahme von Anrufen sowie Einrichtung hierzu
US7182147B2 (en) 2002-06-27 2007-02-27 Snap-On Incorporated Tool apparatus, system and method of use
US20040002938A1 (en) 2002-06-28 2004-01-01 Sony Corporation And Sony Electronics Inc. Device and method for exchanging information
TWM241734U (en) 2002-07-26 2004-08-21 Sin Etke Technology Co Ltd Customized driving environment setting-apparatus
JP2004086418A (ja) 2002-08-26 2004-03-18 Toyota Motor Corp 情報提供方法、情報提供システム、情報提供装置および情報取得装置
US8626380B2 (en) 2002-09-06 2014-01-07 Jaguar Cars Limited Control systems
US7433676B2 (en) 2002-11-15 2008-10-07 Omron Corporation Charging method for use in service providing system, program, and storage medium
US7480512B2 (en) 2004-01-16 2009-01-20 Bones In Motion, Inc. Wireless device, program products and methods of using a wireless device to deliver services
DE602004030534D1 (de) 2003-01-28 2011-01-27 Cellport Systems Inc Ein System und ein Verfahren zum Steuern des Zugriffs von Anwendungen auf geschützte Mittel innerhalb eines sicheren Fahrzeugtelematiksystems
DE10304739A1 (de) 2003-02-06 2004-08-19 Robert Bosch Gmbh Verfahren zur Diagnose auf Signalplausibilität bei einem Geschwindigkeitssensor eines Kraftfahrzeugs
US7398055B2 (en) 2003-02-14 2008-07-08 Ntt Docomo, Inc. Electronic device and program
DE10310115A1 (de) 2003-03-06 2004-09-23 Siemens Ag Anordnung und Schnittstellenmodul zur Anbindung unterschiedlicher mobiler Funktelefone an Bedienkomponenten in einem Kfz
US7415243B2 (en) 2003-03-27 2008-08-19 Honda Giken Kogyo Kabushiki Kaisha System, method and computer program product for receiving data from a satellite radio network
JP2004309795A (ja) 2003-04-07 2004-11-04 Mitsubishi Electric Corp 音楽提供システム
US7206574B2 (en) 2003-04-17 2007-04-17 Lucent Technologies Inc. Automated exchange of broadband communication addresses over a non-broadband channel in a wireless telecommunication system
US6931309B2 (en) 2003-05-06 2005-08-16 Innosurance, Inc. Motor vehicle operating data collection and analysis
US7440842B1 (en) 2003-05-09 2008-10-21 Dimitri Vorona System for transmitting, processing, receiving, and displaying traffic information
KR100769741B1 (ko) 2003-05-29 2007-10-23 교세라 가부시키가이샤 무선 통신 시스템, 무선 통신 장치, 무선 통신 단말, 및 이동 무선 통신 장치
US7821421B2 (en) 2003-07-07 2010-10-26 Sensomatix Ltd. Traffic information system
WO2005006716A1 (en) 2003-07-08 2005-01-20 Nokia Corporation A casing for an electronic handheld device
JP2005028997A (ja) 2003-07-11 2005-02-03 Mitsubishi Electric Corp アプリ実行装置及びアプリケーションプログラム
JP2005044391A (ja) 2003-07-22 2005-02-17 Alpine Electronics Inc プレイリストを用いたオーディオ記録再生装置およびプレイリスト作成方法
US6853910B1 (en) 2003-08-11 2005-02-08 General Motors Corporation Vehicle tracking telematics system
US20070275410A1 (en) 2003-08-18 2007-11-29 Arena Pharmaceuticals, Inc. Methods and Compositions Relating to Modulation of Gpcr Signaling
EP1513311B1 (en) 2003-09-04 2011-03-16 Harman Becker Automotive Systems GmbH Method and system for controlling service access
AU2003259428A1 (en) 2003-09-08 2005-03-29 Nokia Corporation Automotive mobile terminal connection system providing mobile terminal function to enable dynamic external user interface
US20050060350A1 (en) 2003-09-15 2005-03-17 Baum Zachariah Journey System and method for recommendation of media segments
US20050097186A1 (en) * 2003-10-08 2005-05-05 International Business Machines Corporation Method, system, and computer program product for managing interaction between remote devices and server resources
US20050085965A1 (en) 2003-10-15 2005-04-21 Issa Nabil M. Programmable vehicle accessory features
US20060030985A1 (en) 2003-10-24 2006-02-09 Active Recognition Technologies Inc., Vehicle recognition using multiple metrics
US7389178B2 (en) 2003-12-11 2008-06-17 Greenroad Driving Technologies Ltd. System and method for vehicle driver behavior analysis and evaluation
US8041779B2 (en) 2003-12-15 2011-10-18 Honda Motor Co., Ltd. Method and system for facilitating the exchange of information between a vehicle and a remote location
WO2005059862A1 (ja) 2003-12-15 2005-06-30 Hitachi, Ltd. 車載制御装置の情報更新方法と更新情報通信システム、および、車両搭載制御装置と情報管理基地局装置
US20050216553A1 (en) 2004-02-13 2005-09-29 Mallonee Cynthia F Mobile apparatus, method and system for delivery management
US7634095B2 (en) 2004-02-23 2009-12-15 General Motors Company Dynamic tuning of hands-free algorithm for noise and driving conditions
US7334041B2 (en) 2004-02-26 2008-02-19 Teradyne, Inc. Vehicle communications interface
JP3653672B1 (ja) 2004-02-27 2005-06-02 株式会社プラットイーズ 番組情報サーバ、番組情報提供システム、番組情報提供方法及び携帯端末
US7128043B2 (en) 2004-03-19 2006-10-31 Ford Global Technologies, Llc Electromechanically actuated valve control based on a vehicle electrical system
US7072758B2 (en) 2004-03-19 2006-07-04 Ford Global Technologies, Llc Method of torque control for an engine with valves that may be deactivated
US7403769B2 (en) 2004-03-23 2008-07-22 Nokia Corporation System and method for music synchronization in a mobile device
US20050216902A1 (en) 2004-03-23 2005-09-29 General Motors Corporation Method and system for vehicle software configuration update management
EP1732780B1 (de) 2004-03-31 2017-04-26 Volkswagen Aktiengesellschaft Komunikationssystem und informationssystem für ein kraftfahrzeug
JP4836007B2 (ja) 2004-04-01 2011-12-14 コンティ テミック マイクロエレクトロニック ゲゼルシャフト ミット ベシュレンクテル ハフツング 制御装置と車輪モジュールとの間の伝送方法及び装置
US20050221878A1 (en) 2004-04-05 2005-10-06 Van Bosch James A Method for entering a personalized communication profile into a communication user interface
JP2005309645A (ja) 2004-04-20 2005-11-04 Sony Corp メニュー表示装置、メニュー表示方法、メニュー表示方法のプログラム及びメニュー表示方法のプログラムを記録した記録媒体
JP2005311810A (ja) 2004-04-23 2005-11-04 Aii Kk デジタル放送を用いた視聴履歴収集方法
US7715961B1 (en) 2004-04-28 2010-05-11 Agnik, Llc Onboard driver, vehicle and fleet data mining
US7346370B2 (en) * 2004-04-29 2008-03-18 Cellport Systems, Inc. Enabling interoperability between distributed devices using different communication link technologies
CA2564186C (en) 2004-04-30 2019-08-20 Research In Motion Limited System and method of operation control on an electronic device
JP4423550B2 (ja) 2004-05-19 2010-03-03 ソニー株式会社 情報処理装置、コンテンツタイトル表示方法及びコンテンツタイトル表示プログラム
CA2508738C (en) 2004-06-01 2013-12-03 Frank M. Franczyk Vehicle warning system
US7467028B2 (en) 2004-06-15 2008-12-16 Honda Motor Co., Ltd. System and method for transferring information to a motor vehicle
US20050283284A1 (en) 2004-06-16 2005-12-22 Grenier Alain H Vehicle services manager
WO2006024957A2 (en) 2004-07-01 2006-03-09 Harman Becker Automotive Systems Gmbh Computer architecture for a multimedia system used in a vehicle
US7139660B2 (en) 2004-07-14 2006-11-21 General Motors Corporation System and method for changing motor vehicle personalization settings
US7089099B2 (en) 2004-07-30 2006-08-08 Automotive Technologies International, Inc. Sensor assemblies
US20060036356A1 (en) 2004-08-12 2006-02-16 Vladimir Rasin System and method of vehicle policy control
US20060041337A1 (en) 2004-08-19 2006-02-23 Augsburger Brett N Web-enabled engine reprogramming
DE102005044943A1 (de) 2004-09-22 2006-03-23 Andreas Peiker Fahrzeugkommunikationssystem
US7643788B2 (en) 2004-09-22 2010-01-05 Honda Motor Co., Ltd. Method and system for broadcasting data messages to a vehicle
JP2006121573A (ja) 2004-10-25 2006-05-11 Canon Inc 通信装置及びその制御方法
US7657368B2 (en) 2004-11-08 2010-02-02 General Motors Company System and method for large route data handling within a telematics communication system
JP4229051B2 (ja) 2004-11-26 2009-02-25 日産自動車株式会社 運転意図推定装置、車両用運転操作補助装置および車両用運転操作補助装置を備えた車両
KR100843901B1 (ko) 2004-12-04 2008-07-03 주식회사 현대오토넷 텔레매틱스 시스템을 이용한 원격지 차량 제어 시스템 및그 제어방법
JP4649482B2 (ja) 2004-12-14 2011-03-09 バイエリッシェ モートーレン ウエルケ アクチエンゲゼルシャフト 車両内の移動端末にソフトウェア・アプリケーションを提供するためのシステム
US7053866B1 (en) 2004-12-18 2006-05-30 Emile Mimran Portable adaptor and software for use with a heads-up display unit
US7505732B2 (en) 2004-12-22 2009-03-17 Fmr Llc Broadcasting user-specific information
US20060141962A1 (en) 2004-12-23 2006-06-29 Sony Ericsson Mobile Communications Ab Selecting/acquiring desired multimedia content
US7684908B1 (en) 2004-12-29 2010-03-23 Snap-On Incorporated Vehicle identification key for use between multiple computer applications
US7327228B2 (en) 2005-01-10 2008-02-05 Byung Woo Min Installation and maintenance method and system for maintaining a control module for remote starter and alarm system for vehicles
JP4507884B2 (ja) 2005-01-11 2010-07-21 トヨタ自動車株式会社 遠隔制御システム及び遠隔制御装置を備える車両
US7312691B2 (en) 2005-03-14 2007-12-25 General Motors Corporation System and method of using telematics units for locking and unlocking vehicle functions
US20060253874A1 (en) 2005-04-01 2006-11-09 Vulcan Inc. Mobile interface for manipulating multimedia content
JP2006295715A (ja) 2005-04-13 2006-10-26 Toyota Motor Corp 車両遠隔操作装置及びシステム
JP2006317421A (ja) 2005-04-14 2006-11-24 Denso Corp 車載制御装置
US7688792B2 (en) 2005-04-21 2010-03-30 Qualcomm Incorporated Method and apparatus for supporting wireless data services on a TE2 device using an IP-based interface
JP2006319453A (ja) 2005-05-10 2006-11-24 Nec Access Technica Ltd ＳＩＰおよびＩＰｖ６にもとづく移動携帯端末装置、パケット通信方法ならびにパケット通信システム
JP2006352850A (ja) 2005-05-16 2006-12-28 Matsushita Electric Ind Co Ltd 携帯端末、車載用通信機器及びこれらを用いた車両内通信システム
US7693612B2 (en) 2005-06-23 2010-04-06 International Business Machines Corporation Method and system for updating code embedded in a vehicle
JP4628199B2 (ja) 2005-07-01 2011-02-09 アルパイン株式会社 表示装置
US7826945B2 (en) * 2005-07-01 2010-11-02 You Zhang Automobile speech-recognition interface
JP4839705B2 (ja) 2005-07-06 2011-12-21 トヨタ自動車株式会社 情報提供システム及び情報提供方法
JP4389879B2 (ja) 2005-07-07 2009-12-24 トヨタ自動車株式会社 リモート操作システム、リモート操作装置及びサービスセンタ
US7552009B2 (en) 2005-07-14 2009-06-23 Honda Motor Co., Ltd. System and method for synchronizing data for use in a navigation system
US20070021885A1 (en) 2005-07-25 2007-01-25 Honeywell International Inc. System and method for personalizing motor vehicle ride or handling characteristics
US20070043829A1 (en) 2005-08-17 2007-02-22 Robin Dua Method and system for accessing a storage or computing device via the Internet
US7251473B2 (en) 2005-08-19 2007-07-31 Gm Global Technology Operations, Inc. System and method for controlling access to mobile devices
US20090156193A1 (en) 2005-08-22 2009-06-18 Milos Urbanija Modem with acoustic coupling
WO2007047414A2 (en) 2005-10-12 2007-04-26 The Penn State Research Foundation Vigilance monitoring technique for vehicle operators
US8239327B2 (en) 2005-11-02 2012-08-07 Jump Technologies, Inc. System and method for user logging of audio and video broadcast content
IL172003A0 (en) 2005-11-16 2006-04-10 Starcom Gps Systems Ltd Interface for a communication and positioning device
US7616129B2 (en) 2005-12-01 2009-11-10 Discrete Wireless, Inc. In-vehicle conditional multi-media center
CA2541593C (en) 2005-12-07 2015-06-02 Netistix Technologies Corporation Methods and system for determining fuel consumption and fuel efficiency in vehicles
US8136138B2 (en) 2005-12-15 2012-03-13 Visteon Global Technologies, Inc. Display replication and control of a portable device via a wireless interface in an automobile
TWI291665B (en) 2005-12-30 2007-12-21 Ind Tech Res Inst Product managing system and method using RFID technology
US8274985B2 (en) 2005-12-30 2012-09-25 United States Cellular Corporation Control of cellular data access
US7917644B2 (en) 2006-01-11 2011-03-29 Nokia Corporation Extensions to rich media container format for use by mobile broadcast/multicast streaming servers
US8117090B2 (en) 2006-01-30 2012-02-14 Craig Duncan Romero Motor vehicle remarketing service
EP1982273A2 (en) 2006-02-07 2008-10-22 Hyran Media Services, Inc. System and method for providing commercial broadcast content information to mobile subscribers
KR20080106244A (ko) 2006-02-13 2008-12-04 올 프로텍트 엘엘씨 제 3 자에게 주어진 차량을 제어하는 시스템
US20070208464A1 (en) 2006-03-01 2007-09-06 Ford Motor Company System and method of interactively compiling a database for an in-vehicle display device
US20070229307A1 (en) 2006-03-31 2007-10-04 Ivan Pawlenko Detection technology for vehicular and other security applications
US8117246B2 (en) 2006-04-17 2012-02-14 Microsoft Corporation Registering, transfering, and acting on event metadata
US20070265744A1 (en) 2006-05-12 2007-11-15 Electronic Data Systems Corporation Vehicle information system and method
US8605698B2 (en) 2006-05-16 2013-12-10 Autonet Mobile, Inc Vehicle with mobile router
US20070281606A1 (en) 2006-05-30 2007-12-06 Baunach Jeremiah J Systems and methods for acquiring songs or products associated with radio broadcasts
US8014915B2 (en) 2006-06-21 2011-09-06 Sungkyunkwan University Foundation For Corporate Collaboration Vehicle management system and method using ECU
US20080005733A1 (en) 2006-06-29 2008-01-03 Balaji Ramachandran Method and apparatus for updating firmware and software
US20080004038A1 (en) 2006-06-30 2008-01-03 Dunko Gregory A Push-to-talk proximity-based configuration
US7677452B2 (en) 2006-06-30 2010-03-16 Caterpillar Inc. Method and system for providing signatures for machines
US8321524B2 (en) 2006-09-15 2012-11-27 General Motors Llc Method for obtaining electronic vehicle identification number (VIN)
US7970436B1 (en) 2006-09-22 2011-06-28 Sprint Communications Company L.P. Wireless interface extension for mobile devices
US8670798B2 (en) 2006-10-05 2014-03-11 Harman International Industries, Incorporated Extensible infotainment/telematics system having updatable user interface
GB0621340D0 (en) 2006-10-26 2006-12-06 Auto Txt Ltd In-vehicle apparatus
WO2008055117A2 (en) 2006-10-28 2008-05-08 Cooper Johnny G Personal computer for vehicles
US8391155B2 (en) 2006-11-13 2013-03-05 Joseph Harb Digital content download associated with corresponding radio broadcast items
US7765058B2 (en) 2006-11-20 2010-07-27 Ford Global Technologies, Llc Driver input analysis and feedback system
JP4797948B2 (ja) 2006-11-22 2011-10-19 株式会社デンソー 運転行動推定方法および装置
US20080143497A1 (en) 2006-12-15 2008-06-19 General Motors Corporation Vehicle Emergency Communication Mode Method and Apparatus
JP4825698B2 (ja) 2007-02-02 2011-11-30 富士通株式会社 通信プログラムおよび携帯端末装置
US7596445B2 (en) 2007-02-26 2009-09-29 Ford Global Technologies, Llc Method for improving the operation of electrically controlled actuators for an internal combustion engine
US8391775B2 (en) 2007-03-09 2013-03-05 Airbiquity Inc. Mobile digital radio playlist system
US9185123B2 (en) 2008-02-12 2015-11-10 Finsphere Corporation System and method for mobile identity protection for online user authentication
FR2914080A1 (fr) 2007-03-23 2008-09-26 Renault Sas Systeme et procede de gestion de donnees en provenance et a destination d'un vehicule automobile.
EP1978490A1 (en) 2007-04-02 2008-10-08 MAGNETI MARELLI SISTEMI ELETTRONICI S.p.A. System and method for automatic recognition of the operating state of a vehicle engine
US20080249886A1 (en) 2007-04-03 2008-10-09 Woodard William A Satellite radio-based on-demand purchase system
WO2008124795A1 (en) 2007-04-10 2008-10-16 Marvell Semiconductor, Inc. Apparatuses, systems, software and methods for wireless interaction with vehicle control systems
JP2008273370A (ja) 2007-04-27 2008-11-13 Toyota Motor Corp 車両用オーディオビジュアル装置、車両用オーディオビジュアルシステム、装置識別方法、プログラム、記憶媒体
US20090079555A1 (en) 2007-05-17 2009-03-26 Giadha Aguirre De Carcer Systems and methods for remotely configuring vehicle alerts and/or controls
US8843110B2 (en) * 2007-07-03 2014-09-23 General Motors Llc Method of providing data-related services to a telematics-equipped vehicle
ITTO20070484A1 (it) 2007-07-03 2009-01-04 Magneti Marelli Sistemi Elettr Sistema telematico multimediale integrato di bordo per informazioni ed intrattenimento
TW200904676A (en) 2007-07-20 2009-02-01 Automotive Res & Amp Testing Ct Management system and method for automobile biological characteristics identification access privilege
JP2009035024A (ja) 2007-07-31 2009-02-19 Fujitsu Ten Ltd 車載用電子システム及び車載用電子装置
US20090075624A1 (en) 2007-09-18 2009-03-19 Xm Satellite Radio, Inc. Remote vehicle infotainment apparatus and interface
JP2009077031A (ja) * 2007-09-19 2009-04-09 Nec Corp 携帯通信装置、モバイルコンピュータ、組織内システム、プログラム、外部通信接続制御システム、および、外部通信接続制御方法
TWM329579U (en) 2007-10-09 2008-04-01 Htc Corp Keyless identifier
US20090119657A1 (en) 2007-10-24 2009-05-07 Link Ii Charles M Methods and systems for software upgrades
ES2662493T3 (es) 2007-11-02 2018-04-06 Qualcomm Incorporated Sistema configurable de gestión de arbitraje de eventos y recursos
US8502642B2 (en) 2007-11-20 2013-08-06 Voxx International Corporation System for controlling the use of electronic devices within an automobile
US7926091B2 (en) 2007-11-27 2011-04-12 GM Global Technology Operations LLC Secure over-the-air modification of automotive vehicular options
JP5623287B2 (ja) 2007-12-05 2014-11-12 ジョンソン コントロールズテクノロジーカンパニーＪｏｈｎｓｏｎ Ｃｏｎｔｒｏｌｓ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏｍｐａｎｙ 車両ユーザインターフェースシステム及び方法
US8213612B2 (en) 2007-12-07 2012-07-03 Inside Contactless S.A. Secure software download
US8582499B2 (en) 2007-12-26 2013-11-12 General Motors Llc Method for controlling the timing of wireless communications involving telematics-equipped vehicles
KR20100110817A (ko) 2007-12-31 2010-10-13 시리트 엘엘씨 수송수단의 작동을 원격으로 변경하기 위한 시스템 및 방법
US7681558B2 (en) 2008-01-15 2010-03-23 Ford Global Technologies, Llc System and method to control fuel vaporization
JP5355898B2 (ja) * 2008-01-21 2013-11-27 パイオニア株式会社 車載機器、機能設定方法、機能設定プログラム、および記録媒体
US20090215466A1 (en) 2008-02-22 2009-08-27 Darcy Ahl Mobile phone based system for disabling a cell phone while traveling
US9753712B2 (en) 2008-03-20 2017-09-05 Microsoft Technology Licensing, Llc Application management within deployable object hierarchy
US8438559B2 (en) 2008-04-18 2013-05-07 Oracle America, Inc. Method and system for platform-agnostic software installation
US9208797B2 (en) 2008-04-18 2015-12-08 General Motors Llc Tone detection for signals sent through a vocoder
KR101020948B1 (ko) 2008-04-22 2011-03-09 현대자동차주식회사 차량용 네트워크 게이트웨이 및 네트워크 시스템
US8150105B2 (en) 2008-05-22 2012-04-03 International Electronic Machines Corporation Inspection using three-dimensional profile information
US20090300595A1 (en) 2008-05-30 2009-12-03 Ise Corporation System and Method for Remotely Updating Control Software in a Vehicle With an Electric Drive System
EP2318807B1 (en) 2008-08-11 2012-12-26 Telcordia Technologies, Inc. System and method for using networked mobile devices in vehicles
US20100049397A1 (en) 2008-08-22 2010-02-25 Garmin Ltd. Fuel efficient routing
US20100082559A1 (en) 2008-09-19 2010-04-01 General Motors Corporation Method of managing a schedule-based software package update
US8594627B2 (en) * 2008-10-06 2013-11-26 Telecommunications Systems, Inc. Remotely provisioned wirelessly proxy
US20100088367A1 (en) 2008-10-08 2010-04-08 Research In Motion Limited Mobile wireless communications device and system providing dynamic management of carrier applications and related methods
US20100125387A1 (en) 2008-11-17 2010-05-20 Chung-Ang University Industry-Academy Cooperation Foundation System of integrated telematics service and method of controlling the system
JP2010130669A (ja) 2008-12-01 2010-06-10 Fujitsu Ten Ltd 車載装置および無線通信システム
US20100153207A1 (en) 2008-12-11 2010-06-17 Randy Roberts Method and system for providing consumer services with a telematics system
CA2691492A1 (en) 2009-01-29 2010-07-29 James P. Speers Method and system for regulating emissions from idling motor vehicles
US8825222B2 (en) 2009-02-27 2014-09-02 Toyota Motor Engineering & Manufacturing North America, Inc. Remote management of vehicle settings
US20100235045A1 (en) 2009-03-10 2010-09-16 Panasonic Automotive Systems Company Of America, Division Of Panasonic Corporation Of North America Virtual feature management for vehicle information and entertainment systems
DE102009001617A1 (de) 2009-03-17 2010-09-23 Robert Bosch Gmbh Sensormodul für ein Fahrzeugsicherheitssystem und Verfahren zum Betreiben eines solchen Sensormoduls
US8234034B2 (en) 2009-06-26 2012-07-31 Autoliv Asp, Inc. Enhanced electronic assembly
US20110038807A1 (en) 2009-08-14 2011-02-17 Demitri Papolos Compositions and methods for treating bipolar disorder
US8537747B2 (en) 2009-08-14 2013-09-17 General Motors Llc Packet data origination for vehicle communication with a call center
US20110054768A1 (en) 2009-08-27 2011-03-03 Sullivan Joshua Ward Systems and methods for optimizing vehicle fuel efficiency
US9003429B2 (en) 2009-09-23 2015-04-07 Aliphcom System and method of enabling additional functions or services of device by use of transparent gateway or proxy
US8942888B2 (en) 2009-10-15 2015-01-27 Airbiquity Inc. Extensible scheme for operating vehicle head unit as extended interface for mobile device
US9002574B2 (en) 2009-10-15 2015-04-07 Airbiquity Inc. Mobile integration platform (MIP) integrated handset application proxy (HAP)
US8838332B2 (en) 2009-10-15 2014-09-16 Airbiquity Inc. Centralized management of motor vehicle software applications and services
US8831823B2 (en) 2009-10-15 2014-09-09 Airbiquity Inc. Centralized management of motor vehicle software applications and services
DE102009058881A1 (de) 2009-12-18 2011-06-22 Continental Automotive GmbH, 30165 Be- bzw. Entfüllassistent
JP4879347B2 (ja) * 2009-12-25 2012-02-22 キヤノンＩｔソリューションズ株式会社 中継処理装置、中継処理方法及びプログラム
US8600606B2 (en) 2010-02-11 2013-12-03 GM Global Technology Operations LLC Vehicle safety systems and methods
US20110195658A1 (en) 2010-02-11 2011-08-11 Electronics And Telecommunications Research Institute Layered retransmission apparatus and method, reception apparatus and reception method
US20110224865A1 (en) 2010-03-11 2011-09-15 Honeywell International Inc. Health monitoring systems and methods with vehicle velocity
US8868679B2 (en) * 2010-05-24 2014-10-21 Nuance Communications, Inc. Systems, methods and articles for providing communications and services via a peer-to-peer network over a data transport link
US8676151B2 (en) 2010-10-19 2014-03-18 Guardity Technologies, Inc. Detecting a transport emergency event and directly enabling emergency services
US20120130604A1 (en) 2010-11-24 2012-05-24 Kirshon Michael W Automatic shutdown system for automobiles
JP5692578B2 (ja) 2011-01-25 2015-04-01 日本精機株式会社 車両情報取得装置及び車両情報取得方法
US9371786B2 (en) 2011-08-24 2016-06-21 Walbro Llc Fuel injected engine system
WO2013039763A1 (en) 2011-09-12 2013-03-21 Airbiquity Inc. Mobile intergration platform (mip) integrated handset application proxy (hap)
US20130304338A1 (en) 2012-05-09 2013-11-14 Caterpillar Paving Products Inc. Clutch control system for paver
US20130307972A1 (en) 2012-05-20 2013-11-21 Transportation Security Enterprises, Inc. (Tse) System and method for providing a sensor and video protocol for a real time security data acquisition and integration system
US20130307989A1 (en) 2012-05-20 2013-11-21 Transportation Security Enterprises, Inc. (Tse) System and method for real-time data capture and packet transmission using a layer 2 wireless mesh network
JP6154894B2 (ja) 2012-06-08 2017-06-28 エアビクティ インコーポレイテッド 電子センサデータを評価して、自動車を遠隔的に識別し運転者の挙動を監視する方法
US20130331056A1 (en) 2012-06-12 2013-12-12 Guardity Technologies, Inc. Automatic Speech Message Validation of an Emergency Teletype Text Message
US8799360B2 (en) 2012-08-31 2014-08-05 Tweedle Group, Inc. Systems, methods and articles for a server providing communications and services involving automobile head units
CA2895126C (en) 2012-12-20 2021-08-03 Airbiquity Inc. Efficient headunit communication integration
US9184778B2 (en) 2013-02-22 2015-11-10 Nissan North America, Inc. Vehicle information gathering system
US9069641B2 (en) 2013-09-17 2015-06-30 Blackberry Limited Updating firmware on mobile devices

Also Published As

Publication number Publication date
CA2895126A1 (en) 2014-06-26
US9730254B2 (en) 2017-08-08
JP6396320B2 (ja) 2018-09-26
EP2936861A2 (en) 2015-10-28
CN104919833A (zh) 2015-09-16
JP2019004499A (ja) 2019-01-10
CN104919833B (zh) 2019-11-08
JP2016506671A (ja) 2016-03-03
EP2936861B1 (en) 2021-07-21
WO2014100489A3 (en) 2014-09-04
US10159098B2 (en) 2018-12-18
US9370029B2 (en) 2016-06-14
US20170289810A1 (en) 2017-10-05
US20140179274A1 (en) 2014-06-26
CA2895126C (en) 2021-08-03
JP6761452B2 (ja) 2020-09-23
WO2014100489A2 (en) 2014-06-26
US20150230277A1 (en) 2015-08-13

Similar Documents

Publication Publication Date Title
ES2882885T3 (es) Integración eficaz de comunicación de unidad principal
CA2846449C (en) Mobile integration platform (mip) integrated handset application proxy (hap)
JP5668073B2 (ja) 自動車両ソフトウェアアプリケーション及びサービスの集中管理
US8942888B2 (en) Extensible scheme for operating vehicle head unit as extended interface for mobile device
JP5645941B2 (ja) 自動車両ソフトウェアアプリケーション及びサービスの集中管理
US9002574B2 (en) Mobile integration platform (MIP) integrated handset application proxy (HAP)