ES2798673T3 - Sistemas y procedimientos para la comunicación de datos de emergencia - Google Patents

Sistemas y procedimientos para la comunicación de datos de emergencia Download PDF

Info

Publication number
ES2798673T3
ES2798673T3 ES16797695T ES16797695T ES2798673T3 ES 2798673 T3 ES2798673 T3 ES 2798673T3 ES 16797695 T ES16797695 T ES 16797695T ES 16797695 T ES16797695 T ES 16797695T ES 2798673 T3 ES2798673 T3 ES 2798673T3
Authority
ES
Spain
Prior art keywords
emergency
session
data
message
tracking
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
ES16797695T
Other languages
English (en)
Inventor
Dirceu Cavendish
Ashok Bhatia
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.)
Qualcomm Inc
Original Assignee
Qualcomm 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 Qualcomm Inc filed Critical Qualcomm Inc
Application granted granted Critical
Publication of ES2798673T3 publication Critical patent/ES2798673T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/021—Services related to particular areas, e.g. point of interest [POI] services, venue services or geofences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/023—Services making use of location information using mutual or relative location information between multiple location based services [LBS] targets or of distance thresholds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/029—Location-based management or tracking services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90—Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0261—Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level
    • 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/33—Services specially adapted for particular environments, situations or purposes for indoor environments, e.g. buildings
    • 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/38—Services specially adapted for particular environments, situations or purposes for collecting sensor information
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Health & Medical Sciences (AREA)
  • Emergency Management (AREA)
  • Environmental & Geological Engineering (AREA)
  • Public Health (AREA)
  • Telephonic Communication Services (AREA)
  • Alarm Systems (AREA)

Abstract

Un procedimiento (400) que comprende: recibir (410) por un servidor de llamadas de emergencia una indicación de una condición de emergencia en un dispositivo y establecer una sesión de llamada de emergencia con dicho dispositivo; determinar (420) si el dispositivo móvil debe rastrearse basándose, al menos en parte, en la indicación de la condición de emergencia; y transmitir (430) un mensaje desencadenante desde el servidor de llamadas de emergencia, en respuesta a una determinación de que el dispositivo debe rastrearse, para desencadenar en el dispositivo una sesión de rastreo para causar que el dispositivo recopile y envíe periódicamente datos de la sesión de rastreo a uno o más servidores, en el que la sesión de rastreo, establecida entre el dispositivo y los uno o más servidores, está separada de una sesión de llamada de emergencia establecida entre el dispositivo y el servidor de llamadas de emergencia.

Description

DESCRIPCIÓN
Sistemas y procedimientos para la comunicación de datos de emergencia
REFERENCIA CRUZADA CON SOLICITUDES RELACIONADAS
[0001] La presente solicitud reivindica el beneficio de y prioridad a la solicitud no provisional de EE. UU. con n.° de serie 15/078,846, presentada el 23 de marzo de 2016, que reivindica prioridad a la solicitud provisional de EE. UU. con n.° de serie 62/268,241, presentada el 16 de diciembre de 2015, ambas tituladas "SYSTEMS AND METHODS FOR EMERGENCY DATA COMMUNICATION [SISTEMAS Y PROCEDIMIENTOS PARA LA COMUNICACIÓN DE DATOS DE EMERGENCIA]", ambas asignadas al cesionario.
ANTECEDENTES
[0002] Los sistemas de asistencia para emergencias (por ejemplo, para gestionar llamadas al 911, incidencias en carretera, etc.) generalmente funcionan suponiendo una posición concreta. Por lo tanto, los detalles de una llamada de emergencia (por ejemplo, la causa de la emergencia, la ubicación en la que se está produciendo la situación de emergencia, donde esa ubicación se obtiene a partir de los datos incluidos en la llamada recibida o mediante una conversación en vivo entre un usuario y un operador) generalmente solo se proporcionan durante la sesión de llamada de emergencia. Sin embargo, es posible que información adicional que se vuelve disponible después de finalizar la llamada de emergencia no pueda proporcionarse al servidor de llamadas de emergencia o a proveedores de servicios de emergencia específicos que se envían para atender la emergencia.
[0003] El documento US 2015/213708 se refiere a un dispositivo de seguimiento que transmite un mensaje de socorro que incluye una identificación del dispositivo de seguimiento a uno o más dispositivos de comunicación inalámbrica usando un protocolo de comunicación inalámbrica. En respuesta a la recepción del mensaje de socorro, un dispositivo de comunicación inalámbrico puede transmitir un mensaje de notificación a un servidor de localización de emergencia. El dispositivo de comunicación inalámbrica puede transmitir información relacionada con al menos una ubicación del dispositivo de comunicación inalámbrica al servidor de localización de emergencia. El mensaje de socorro, el mensaje de notificación y/o la transmisión de información relacionada con al menos una ubicación del dispositivo de comunicación inalámbrica pueden ser automáticos, sin intervención del usuario y/o notificación del usuario.
[0004] El documento US 8538374 se refiere a un sistema automatizado, procedimiento o producto de programa informático para proporcionar comunicaciones de emergencia, incluida una aplicación de comunicaciones de emergencia y un servidor de comunicaciones de emergencia MyFlare. La aplicación de comunicaciones de emergencia MyFlare puede ejecutarse en un dispositivo móvil y puede configurarse para, cuando se active, interactuar con el servidor de comunicaciones de emergencia MyFlare para enviar mensajes de emergencia preconfigurados a un conjunto preconfigurado de contactos de emergencia. Se pueden preconfigurar diferentes perfiles de emergencia para los cuales se pueden enviar diferentes mensajes de emergencia.
[0005] El documento US 2012/115430 se refiere a un aparato y procedimiento para localizar un dispositivo móvil en una situación de emergencia. El dispositivo móvil incluye un dispositivo de visualización, una interfaz de usuario para recibir una solicitud de modo de emergencia desde un usuario y un procesador. El procesador puede estar configurado para ejecutar instrucciones para implementar un proceso de modo de emergencia basado en la recepción de la solicitud de modo de emergencia desde el usuario. El proceso de modo de emergencia se implementa para: supervisar las señales recibidas para localizar una estación base, donde, una vez que se ha localizado una estación base, se transmite un breve mensaje de emergencia a la estación base que incluye la ubicación del dispositivo móvil. El proceso de modo de emergencia se implementa además para: supervisar las señales recibidas para recibir una señal de acuse de recibo desde la estación base; y reducir una pluralidad de primeras funciones no esenciales del dispositivo móvil para reducir el consumo de energía.
BREVE EXPLICACIÓN
[0006] De acuerdo con la presente invención, se proporcionan un procedimiento y un servidor de llamadas de emergencia, como se expone en las reivindicaciones independientes, respectivamente. Los modos de realización preferidos de la invención se describen en las reivindicaciones dependientes.07
[0007] En algunas variaciones, se proporciona un procedimiento que incluye recibir por un servidor de llamadas de emergencia una indicación de una condición de emergencia en un dispositivo, determinar si el dispositivo debe rastrearse basándose, al menos en parte, en la indicación de la condición de emergencia, y transmitir un mensaje desencadenante desde el servidor de llamadas de emergencia, en respuesta a una determinación de que el dispositivo debe rastrearse, para desencadenar en el dispositivo una sesión de rastreo para causar que el dispositivo recopile y envíe periódicamente datos de la sesión de rastreo a uno o más servidores. La sesión de rastreo, establecida entre el dispositivo y los uno o más servidores, está separada de una sesión de llamada de emergencia establecida entre el dispositivo y el servidor de llamadas de emergencia.
[0008] En algunas variaciones, se proporciona un servidor de llamadas de emergencia que incluye un transceptor configurado para recibir una indicación de una condición de emergencia en un dispositivo, y uno o más procesadores, acoplados al transceptor, configurados para determinar si el dispositivo debe rastrearse basándose, al menos en parte, en la indicación de la condición de emergencia. El transceptor está configurado además para transmitir un mensaje desencadenante desde el servidor de llamadas de emergencia, en respuesta a una determinación de que el dispositivo debe rastrearse, para desencadenar en el dispositivo una sesión de rastreo para causar que el dispositivo recopile periódicamente y envíe datos de la sesión de rastreo a uno o más servidores. La sesión de rastreo, establecida entre el dispositivo y los uno o más servidores, está separada de una sesión de llamada de emergencia establecida entre el dispositivo y el servidor de llamadas de emergencia.
[0009] En algunas variaciones, se proporciona un aparato que incluye medios para recibir por un servidor de llamadas de emergencia una indicación de una condición de emergencia en un dispositivo, medios para determinar si el dispositivo debe rastrearse basándose, al menos en parte, en la indicación de la condición de emergencia, y medios para transmitir un mensaje desencadenante desde el servidor de llamadas de emergencia, en respuesta a una determinación de que el dispositivo debe rastrearse, para desencadenar en el dispositivo una sesión de rastreo para causar que el dispositivo recopile y envíe periódicamente datos de la sesión de rastreo a uno o más servidores. La sesión de rastreo, establecida entre el dispositivo y los uno o más servidores, está separada de una sesión de llamada de emergencia establecida entre el dispositivo y el servidor de llamadas de emergencia.
[0010] En alguna variación, se proporciona un medio no transitorio legible por ordenador que se programa con instrucciones, ejecutable en un procesador, para recibir por un servidor de llamadas de emergencias una indicación de una condición de emergencia en un dispositivo, determinar si el dispositivo debe rastrearse basándose, al menos en parte, en la indicación de la condición de emergencia, y transmitir un mensaje desencadenante desde el servidor de llamadas de emergencia, en respuesta a una determinación de que el dispositivo debe rastrearse, para desencadenar en el dispositivo una sesión de rastreo para causar que el dispositivo recopile y envíe periódicamente datos de la sesión de rastreo a uno o más servidores. La sesión de rastreo, establecida entre el dispositivo y los uno o más servidores, está separada de una sesión de llamada de emergencia establecida entre el dispositivo y el servidor de llamadas de emergencia.
[0011] Otros objetivos, características, aspectos y ventajas adicionales de la presente divulgación se entenderán mejor con la siguiente descripción detallada de los dibujos adjuntos.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
[0012]
La FIG. 1 es un diagrama de un entorno operativo de ejemplo para dar soporte a la comunicación de datos de emergencia.
La FIG. 2 es un diagrama de flujo de un procedimiento de ejemplo para facilitar la provisión de datos de sesión de seguimiento por un dispositivo.
La FIG. 3 es un diagrama de flujo de implementaciones de ejemplo de comunicación de datos en situaciones de emergencia.
La FIG. 4 es un diagrama de flujo de un procedimiento de ejemplo, generalmente realizado en un servidor de llamadas de emergencia, para procesar comunicaciones de emergencia y facilitar el establecimiento de sesiones de seguimiento.
La FIG. 5 es un diagrama de flujo de un procedimiento de ejemplo, generalmente realizado en un servidor de seguimiento de emergencias, para recibir y procesar datos de emergencia.
La FIG. 6 es un diagrama de flujo de un procedimiento de ejemplo que ilustra operaciones e interacciones en todo el sistema entre un dispositivo, un servidor de llamadas de emergencia y un servidor de seguimiento de emergencias para facilitar la recopilación y la comunicación de datos de emergencia.
La FIG. 7 es un diagrama de flujo de un proceso de ejemplo para notificar una emergencia médica y establecer una sesión de seguimiento para comunicar datos médicos de emergencia.
La FIG. 8 es un diagrama de flujo de otro proceso de ejemplo para notificar una emergencia policial y establecer una sesión de seguimiento para comunicar datos criminales/forenses de emergencia.
La FIG. 9 es un diagrama de flujo de otro proceso de ejemplo para notificar una emergencia privada en carretera y establecer una sesión de seguimiento para comunicar datos de vehículos/accidentes de emergencia.
La FIG. 10 es un diagrama esquemático de un dispositivo inalámbrico de ejemplo (por ejemplo, un dispositivo inalámbrico móvil).
La FIG. 11 es un diagrama esquemático de un nodo de ejemplo (por ejemplo, un punto de acceso o un servidor).
La FIG. 12 es un diagrama esquemático de un sistema informático de ejemplo.
[0013] Símbolos de referencia similares en los diversos dibujos indican elementos similares.
DESCRIPCIÓN DETALLADA
[0014] En el presente documento se describen procedimientos, sistemas, dispositivos, aparatos, medios legibles por ordenador/procesador y otras implementaciones para la recopilación y comunicación de datos de emergencia. En algunos modos de realización, se proporciona un procedimiento que incluye recibir mediante un dispositivo (por ejemplo, un dispositivo móvil o cualquier otro tipo de dispositivo) un mensaje desencadenante desde un servidor de llamadas de emergencia en respuesta a una indicación de una condición de emergencia (por ejemplo, un mensaje E-911, un mensaje eCall, etc.) en el dispositivo para iniciar una sesión de seguimiento para recopilar y enviar periódicamente datos de sesión de seguimiento (también denominados datos de emergencia o metadatos de emergencia (e-metadatos)) asociados al dispositivo a uno o más servidores (por ejemplo, uno o más servidores de seguimiento de emergencia), establecer la sesión de seguimiento, separada de una sesión de llamada de emergencia entre el dispositivo y el servidor de llamadas de emergencia, con el uno o más servidores, y enviar, mediante el dispositivo al uno o más servidores, los datos de sesión de seguimiento recopilados durante la sesión de seguimiento por el dispositivo. En algunos modos de realización, el dispositivo que recibe el mensaje desencadenante puede haber iniciado la sesión de llamada de emergencia, por ejemplo, enviando la indicación de la condición de emergencia, mientras que en algunas situaciones, la indicación de la condición de emergencia puede haberse enviado en respuesta a un mensaje inicial (por ejemplo, mensaje de radiodifusión) desde el servidor de llamadas de emergencia, o la indicación de la condición de emergencia puede haber sido enviada por otro dispositivo (por ejemplo, gestionado por terceros que notifica la emergencia que involucró a la parte asociada al dispositivo que recibe el mensaje desencadenante). En algunos modos de realización, el procedimiento puede incluir además hacer que el dispositivo pase a un estado de modo de seguimiento de energía reducida, en respuesta a la recepción del mensaje desencadenante para establecer la sesión de seguimiento separada, lo que incluye reducir la energía proporcionada a los subsistemas del dispositivo que no se necesitan para recopilar o comunicar los datos de sesión de seguimiento asociados al dispositivo, y proporcionar al menos una energía parcial a uno o más subsistemas de sensor o comunicación del dispositivo para hacer que el uno o más subsistemas de sensor o comunicación funcionen al menos parcialmente mientras el dispositivo está en el estado de modo de seguimiento de energía reducida para comunicar al uno o más servidores al menos parte de los datos de sesión de seguimiento. En algunos modos de realización, el envío de los datos de sesión de seguimiento puede incluir determinar en un primer instante de tiempo uno o más tiempos de activación posteriores para transmitir datos al uno o más servidores, donde los uno o más tiempos de activación se determinan en base a, por ejemplo, el nivel de carga de una batería del dispositivo, el tiempo transcurrido desde la última vez que se comunicó el mensaje de emergencia con metadatos de emergencia, la periodicidad máxima con que el dispositivo comunica los datos de seguimiento y/u otros factores.
[0015] También se describen en el presente documento sistemas, procedimientos, dispositivos y otras implementaciones, incluido un procedimiento que incluye recibir mediante un servidor de llamadas de emergencia una indicación de una condición de emergencia en un dispositivo, determinar si el dispositivo debe ser rastreado en base a, al menos en parte, la indicación de la condición de emergencia, y transmitir un mensaje desencadenante desde el servidor de llamadas de emergencia, en respuesta a una determinación de que si el dispositivo debe ser rastreado, para iniciar en el dispositivo una sesión de seguimiento para hacer que el dispositivo recopile y envíe periódicamente datos de sesión de seguimiento a uno o más servidores. La sesión de seguimiento, establecida entre el dispositivo y el uno o más servidores, está separada (por ejemplo, es diferente y/o independiente) de una sesión de llamada de emergencia establecida entre el dispositivo y el servidor de llamadas de emergencia. Como se señaló, la indicación de la condición de emergencia puede haber sido enviada directamente por el dispositivo (ya sea por iniciativa del dispositivo o en respuesta a un mensaje de sondeo, tal como un mensaje de radiodifusión desde el servidor de llamadas de emergencia), o la indicación de la condición de emergencia puede haberse recibido desde algún otro dispositivo (por ejemplo, un dispositivo móvil gestionado por terceros que notifica una emergencia que involucra al usuario del dispositivo que recibe el mensaje desencadenante). En algunos modos de realización, el mensaje desencadenante transmitido al dispositivo se configura además para hacer que el dispositivo funcione en un estado de modo de seguimiento de energía reducida en el que se reduce la energía suministrada a subsistemas del dispositivo no requeridos para recopilar y comunicar datos de sesión de seguimiento asociados al dispositivo móvil, y en el que uno o más subsistemas de sensor o comunicación del dispositivo, configurados para realizar la comunicación de los datos de sesión de seguimiento, funcionan al menos parcialmente mientras el dispositivo está en el estado de modo de seguimiento de energía reducida.
[0016] Las implementaciones descritas en el presente documento también pueden incluir un procedimiento que incluye recibir mediante al menos un servidor (por ejemplo, un servidor de seguimiento de emergencias), desde un dispositivo (por ejemplo, un dispositivo móvil), una solicitud para establecer una sesión de seguimiento para recopilar y enviar periódicamente los datos de sesión de seguimiento al menos un servidor relacionados con una condición de emergencia en el dispositivo, donde la solicitud de establecer la sesión de seguimiento es enviada por el dispositivo en respuesta a un mensaje desencadenante procedente de un servidor de llamadas de emergencia para iniciar la sesión de seguimiento. El mensaje desencadenante se transmite desde el servidor de llamadas de emergencia al dispositivo durante una sesión de llamadas de emergencia, separada de la sesión de seguimiento, en respuesta a un mensaje de indicación de la condición de emergencia en el dispositivo transmitido al servidor de llamadas de emergencia. El procedimiento incluye además enviar mediante el al menos un servidor una respuesta al dispositivo para establecer la sesión de seguimiento, y recibir periódicamente mediante el al menos un servidor, desde el dispositivo, los datos de sesión de seguimiento recopilados por el dispositivo durante la sesión de seguimiento. En algunos modos de realización, el mensaje de indicación de la condición de emergencia en el dispositivo transmitido al servidor de llamadas de emergencia incluye uno de, por ejemplo, un mensaje de inicio del dispositivo con respecto a la condición de emergencia, un mensaje de respuesta del dispositivo en respuesta a un mensaje de sondeo del servidor de llamadas de emergencia o un mensaje de notificación de otro dispositivo para notificar la condición de emergencia en el dispositivo. En algunos modos de realización, el al menos un servidor puede configurarse para modificar las características de la sesión de seguimiento, por ejemplo, enviando comandos al dispositivo para cambiar su comportamiento de recopilación de datos, que incluyen, pero sin limitarse a, el tipo de datos de emergencia, frecuencia (ritmo) de recopilación, cantidad de datos, identidad del al menos un servidor para recibir datos de seguimiento, etc. En algunos modos de realización, la modificación de la sesión de seguimiento también puede incluir la terminación de los enlaces de comunicación entre al menos un servidor y el dispositivo.
[0017] Por lo tanto, los procedimientos, sistemas, dispositivos y otras implementaciones descritas en el presente documento pueden proporcionar datos de sesión de seguimiento de dispositivo en modo de bajo consumo de energía (suficiente para admitir la recopilación de datos de sesión de seguimiento/emergencia para el dispositivo y la comunicación de los datos a un servidor remoto, pero con otros subsistemas de dispositivo apagados, o su consumo de energía y correspondiente funcionalidad reducidas, para facilitar así la prestación de servicios de emergencia (por ejemplo, por un escuadrón de bomberos, una fuerza policial, un equipo de rescate médico, etc.)). En algunos modos de realización, la recopilación de datos de seguimiento puede continuar sin interrupciones incluso si el dispositivo es apagado por el usuario del dispositivo (es decir, el dispositivo queda bloqueado en el modo de seguimiento).
[0018] Por tanto, con referencia a la FIG. 1, se muestra un diagrama de un entorno operativo 100 de ejemplo que incluye un dispositivo 108, que puede ser un dispositivo inalámbrico (móvil o estacionario), o un subsistema de comunicación (por ejemplo, una unidad montada en un vehículo, tren, avión, etc.), configurado para iniciar una llamada de emergencia y proporcionar posteriormente datos periódicos de sesión de seguimiento, y que está en comunicación con uno o más dispositivos/nodos/servidores. El dispositivo 108 se puede configurar para comunicarse de acuerdo con uno o más protocolos de comunicación (por ejemplo, protocolos de campo cercano, tal como la tecnología inalámbrica Bluetooth®, o Zigbit, protocolos WLAn , tal como un protocolo WiFi de acuerdo con la norma IEEE 802.11 k, protocolos WWAN, etc.). Como se analiza con mayor detalle posteriormente, el dispositivo 108 puede configurarse, en algunos modos de realización, para enviar/comunicar (a iniciativa del dispositivo 108, o en respuesta a un mensaje, tal como un mensaje de radiodifusión de sondeo recibido por el dispositivo 108) a un servidor de llamadas de emergencia (tal como un servidor de llamadas de emergencia 120, que puede ser un servidor de punto de respuesta de seguridad pública, o PSAP) una indicación de una condición de emergencia (por ejemplo, un mensaje E-911 para notificar una emergencia médica, una incidencia en carretera, una emergencia notificada con respecto a terceros, etc.), y recibir un mensaje desencadenante desde el servidor de llamadas de emergencia en respuesta a la indicación de la condición de emergencia para iniciar una sesión de seguimiento para recopilar y enviar periódicamente datos de sesión de seguimiento asociados al dispositivo móvil a uno o más servidores (tal como un servidor de seguimiento de emergencias 122, que puede ser diferente del servidor 120 al que se comunicó el mensaje de indicación de emergencia). En algunos modos de realización, el mensaje desencadenante puede haberse recibido como resultado de un mensaje de indicación enviado desde otro dispositivo, asociado a terceros, para notificar la condición de emergencia asociada al dispositivo. Los datos de la sesión de seguimiento pueden recopilarse de sensores asociados al dispositivo 108, incluidos sensores alojados dentro del dispositivo (por ejemplo, sensores inerciales, transceptores, etc., como se describirá más en particular posteriormente), y sensores ubicados de forma remota al dispositivo. Los sensores remotos pueden ser sensores biométricos (tal como un sensor 132 llevado por un usuario 130), sensores montados en un vehículo (tal como un sensor 136, por ejemplo, un sensor de presión de aceite, ubicado en un vehículo 134), etc. Los sensores remotos pueden comunicarse con el dispositivo 108 por medio de uno o más enlaces de comunicación de campo cercano (por ejemplo, enlaces de tecnología inalámbrica Bluetooth®), por medio de enlaces de comunicación basados en LAN, etc. El dispositivo 108, que establece una sesión de seguimiento con el uno o más servidores que está separada de la sesión de llamada de emergencia, está configurado para enviar los datos de sesión de seguimiento recopilados durante la sesión de seguimiento al uno o más servidores de seguimiento. El dispositivo 108 también puede configurarse para reducir la energía (y así entrar en un estado de modo de seguimiento de energía reducida) proporcionada a los subsistemas del dispositivo no requeridos para recopilar y/o comunicar los datos de sesión de seguimiento asociados al dispositivo (por ejemplo, subsistemas tales como el subsistema de vídeo, el subsistema de procesador de aplicaciones que admite aplicaciones tales como la aplicación de correo electrónico, aplicaciones de terceros, etc.), y para proporcionar al menos una energía parcial a uno o más subsistemas de sensor o comunicación del dispositivo móvil para hacer que el uno o más subsistemas de sensor o comunicación funcionen al menos parcialmente mientras el dispositivo está en el estado de modo de seguimiento de energía reducida para comunicar al uno o más servidores (por ejemplo, los servidores de seguimiento) al menos parte de los datos de sesión de seguimiento. Por lo tanto, tras hacerse que inicie una sesión de seguimiento (por ejemplo, en respuesta a la recepción de un mensaje desencadenante o una solicitud del servidor de llamadas de emergencia para comenzar una sesión de seguimiento), el dispositivo está configurado para invocar ajustes de energía de emergencia (para funcionar a niveles de energía reducidos para conservar la fuente de alimentación del dispositivo) y comunicar periódicamente datos de sesión de seguimiento (también denominados datos de emergencia, o metadatos), que el dispositivo 108 está configurado para recopilar durante la sesión de seguimiento. Los datos de seguimiento de sesión proporcionan actualizaciones acerca de posibles cambios en la posición del dispositivo, actualizaciones referentes al estado médico del usuario (cuando la emergencia es una emergencia médica) que pueden ser proporcionadas por sensores biométricos (por ejemplo, ubicados de forma remota en dispositivos llevados por el usuario), y proporcionar de otro modo datos pertinentes a uno o más proveedores de servicios de emergencia para facilitar una pronta provisión de servicios de atención de emergencia. En algunos modos de realización, el procesamiento en tiempo real puede realizarse en los datos de seguimiento proporcionados al uno o más servidores para obtener un procesamiento en tiempo real (por ejemplo, filtrar datos irrelevantes, agregar constantes vitales en un conjunto de datos de estado de un paciente, suministrar datos procesados a un escuadrón de servicios de emergencias, etc.). Además, el procesamiento fuera de línea se puede realizar en los datos de sesión de seguimiento, por ejemplo, para obtener estadísticas de resolución de emergencias, realizar un análisis de riesgo para seguros, etc.
[0019] El dispositivo 108 (así como cualquier otro dispositivo ilustrado en la FIG. 1) se puede configurar para que funcione e interactúe con múltiples tipos de otros sistemas/dispositivos de comunicación, incluidos dispositivos (o nodos) de red de área local, tales como WLAN para comunicación en interiores, femtocélulas, transceptores basados en tecnología inalámbrica Bluetooth®, y otros tipos de nodos de red de comunicación en interiores, nodos de red inalámbrica de área amplia, sistemas de comunicación por satélite, otros dispositivos móviles, etc., y, como tal, el dispositivo 108 puede incluir una o más interfaces y/o transceptores para comunicarse con los diversos tipos de sistemas de comunicaciones. Los diversos dispositivos de la FIG. 1 se pueden configurar para establecer y funcionar de acuerdo con cualquier número de protocolos de comunicación.
[0020] Como se indicó, el entorno 100 puede contener uno o más tipos diferentes de sistemas o nodos de comunicación inalámbrica y/o cableada, cada uno de los cuales puede usarse para establecer enlaces de comunicación entre el dispositivo 108, el servidor de llamadas de emergencia 120 y/o el servidor de seguimiento de proveedor de servicios de emergencia 122 representados en la FIG. 1. Los nodos ilustrados en la FIG. 1 incluyen puntos de acceso inalámbricos (o WAP) y pueden incluir transceptores inalámbricos LAN y/o WAN, incluyendo, por ejemplo, estaciones base WiFi, transceptores de femtocélulas, transceptores de tecnología inalámbrica Bluetooth®, estaciones base celulares, transceptores WiMax, etc. Por tanto, por ejemplo, y haciendo aún referencia a la FIG. 1, el entorno 100 puede incluir puntos de acceso inalámbrico de red de área local (LAN-WAP) 106a-e que se pueden usar para la comunicación inalámbrica de voz y/o datos con el dispositivo 108. Los LAN-WAP 106a-e también se pueden utilizar, en algunos modos de realización, como fuentes independientes de datos de posición, por ejemplo, a través de procedimientos basados en huellas digitales, a través de la implementación de procedimientos basados en multilateración basados, por ejemplo, en técnicas basadas en temporización (por ejemplo, mediciones basadas en RTT), mediciones de intensidad de señal (por ejemplo, mediciones RSSI), etc., que pueden incluirse posteriormente como datos de seguimiento de emergencia enviados por el dispositivo móvil 108. Los LAN-WAP 106a-e pueden ser parte de una red inalámbrica de área local (WLAN), que puede funcionar en edificios y realizar comunicaciones en regiones geográficas más pequeñas que una WWAN. Adicionalmente, en algunos modos de realización, los LAN-WAP 106a-e también podrían incluir pico o femtocélulas. En algunos modos de realización, los LAN-WAP 106a-e pueden formar parte de, por ejemplo, redes WiFi (802.11x), picoredes celulares y/o femtocélulas, redes de tecnología inalámbrica Bluetooth®, etc. Aunque en la FIG. 1 se representan cinco (5) puntos de acceso LAN-WAP, se puede usar cualquier número de dichos LAN-WAP, y, en algunos modos de realización, el entorno 100 puede no incluir ningún punto de acceso LAN-WAP en absoluto, o puede incluir un único punto de acceso LAN-WAP.
[0021] Como se ilustra adicionalmente, el entorno 100 también puede incluir una pluralidad de uno o más tipos de puntos de acceso inalámbrico de red de área amplia (WAN-WAP) 104a-c, que se pueden usar para la comunicación inalámbrica de voz y/o datos, y también pueden servir como otra fuente de información independiente a través de la cual el dispositivo inalámbrico 108 (y/u otros dispositivos) puede determinar su posición/ubicación (que puede transmitirse posteriormente como parte de los datos de seguimiento de emergencia). Los WAN-WAP 104a-c pueden formar parte de una red inalámbrica de área amplia (WWAN), que puede incluir estaciones base celulares y/u otros sistemas inalámbricos de área amplia, tales como, por ejemplo, WiMAX (por ejemplo, 802.16). Una WWAN puede incluir otros componentes de red conocidos que no se muestran en la FIG. 1. Típicamente, cada WAN-WAP 104a-c dentro de la WWAN puede funcionar desde posiciones fijas o puede ser móvil, y puede proporcionar cobertura de red en grandes áreas metropolitanas y/o regionales. Aunque se representan tres (3) WAN-WAP en la FIG. 1, se puede usar un número cualquiera de dichos WAN-WAP. En algunos modos de realización, el entorno 100 puede no incluir ningún WAN-WAP en absoluto, o puede incluir un único WAN-WAP.
[0022] La comunicación hacia y desde el dispositivo 108 (para intercambiar datos, incluidos mensajes que indican una condición de emergencia y mensajes que incluyen datos de emergencia, y proporcionar operaciones y servicios de determinación de ubicación al dispositivo 108, etc.) puede implementarse usando diversas redes y/o tecnologías y/o codificaciones de comunicación inalámbrica, tales como una red inalámbrica de área amplia (WWAN), una red inalámbrica de área local (WLAN), una red inalámbrica de área personal (WPAN), una red de igual a igual, etc. El término "red" y "sistema" se pueden usar de manera intercambiable. Una WWAN puede ser una red de acceso múltiple por división de código (CDMA), una red de acceso múltiple por división de tiempo (TDMA), una red de acceso múltiple por división de frecuencia (FDMA), una red de acceso múltiple por división ortogonal de frecuencia (OFDMA), una red de acceso múltiple por división de frecuencia de única portadora (SC-FDMA), una red WiMax (IEEE 802.16) etc. Una red CDMA puede implementar una o más tecnologías de acceso radioeléctrico (RAT), tales como cdma2000, CDMA de banda ancha (W-CDMA), etc. cdma2000 incluye las normas IS-95, IS-2000 y/o IS-856. Una red TDmA puede implementar el sistema global de comunicaciones móviles (GSM), el sistema digital avanzado de telefonía móvil (D-AMPS) o alguna otra tecnología de acceso radioeléctrico RAT. GSM y W-CDMA se describen en documentos de un consorcio llamado "Proyecto de Colaboración de Tercera Generación" (3GPP). cdma2000 se describe en documentos de un consorcio llamado "Segundo Proyecto de Colaboración de Tercera Generación" (3GPP2). Los documentos del 3GPP y del 3GPP2 están a disposición del público. En algunos modos de realización, redes 4G, redes de Evolución a Largo Plazo ("LTE"), las redes LTE avanzadas, redes de Banda Ancha Ultramóvil (UMB) y todos los demás tipos de redes de comunicaciones celulares también pueden implementarse y usarse con los sistemas, dispositivos, procedimientos y otras implementaciones descritas en el presente documento. Una WLAN también puede implementarse, al menos en parte, usando una red IEEE 802.11x, y una WPAN puede ser una red de tecnología inalámbrica Bluetooth®, una red IEEE 802.15x o algún otro tipo de red. Las técnicas descritas en el presente documento también se pueden usar para cualquier combinación de WWAN, WLAN y/o WPAN.
[0023] En algunos modos de realización, y como se representa además en la FIG. 1, el dispositivo 108 también se puede configurar para al menos recibir información desde un sistema de posicionamiento vía satélite (SPS) 102a-b, que se puede usar como una fuente independiente de información de posición para el dispositivo móvil 108. Por lo tanto, el dispositivo 108 puede incluir uno o más receptores SPS dedicados configurados para recibir señales para obtener información de geolocalización de dispositivo desde los satélites SPS (que pueden transmitirse como parte de los datos de seguimiento de emergencia). En modos de realización en los que el dispositivo móvil 108 puede recibir señales de satélite, el dispositivo móvil puede utilizar un receptor (por ejemplo, un receptor GNSS) implementado específicamente para su uso con el SPS para extraer datos de posición a partir de una pluralidad de señales transmitidas por al menos los satélites SPS 102a-b. Las señales de satélite transmitidas pueden incluir, por ejemplo, señales marcadas con un código de ruido pseudoaleatorio (PN) que se repite de un número establecido de chips y se pueden ubicar en estaciones de control en tierra, equipos de usuario y/o vehículos espaciales. Las técnicas proporcionadas en el presente documento se pueden aplicar a, o implementarse de otro modo, para su uso en otros diversos sistemas tales como, por ejemplo, el Sistema de Posicionamiento Global (GPS), Galileo, Glonass, Compass, el Sistema de Satélites Cuasicenitales (QZSS) en Japón, el Sistema Indio de Satélites de Navegación Regional (IRNSS) en la India, Beidou en China, etc., y/o diversos sistemas de aumento (por ejemplo, un sistema de aumento basado en satélites (SBAS)) que se pueden asociar a, o habilitarse de otro modo, para su uso con uno o más sistemas de satélites de navegación global y/o regional. A modo de ejemplo, pero no de limitación, un SBAS puede incluir un/diversos sistema(s) de aumento que proporciona(n) información de integridad, correcciones diferenciales, etc., tales como, por ejemplo, el Sistema de Aumento de Área Amplia (WAAS), el Servicio Europeo de Navegación por Complemento Geoestacionario (EGNOS), el Sistema de Aumento por Satélite Multifuncional (MSAS), el Sistema de Navegación Aumentado Geostacionario Asistido por GPS o Sistema Navegación Aumentado Geostacionario con GPS (GAGAN), y/o similares. Por tanto, como se usa en el presente documento, un SPS puede incluir cualquier combinación de uno o más sistemas de satélites de navegación global y/o regional y/o sistemas de aumento, y las señales SPS pueden incluir señales SPS, de tipo SPS y/u otras señales asociadas a dichos uno o más SPS.
[0024] En algunos modos de realización, el entorno 100 puede incluir además una red 110 (por ejemplo, una red inalámbrica celular, una red WiFi, una red pública o privada basada en paquetes, tal como Internet pública), en comunicación con uno o más de los servidores 120, 122 y/o los diversos nodos inalámbricos del entorno 100. Cualquiera de los servidores 120 y 122 puede comunicarse, por medio de la red 110 o mediante transceptores inalámbricos incluidos con los servidores 120 y 122, con múltiples elementos o nodos de red, y/o dispositivos inalámbricos móviles. Por ejemplo, el servidor 120 puede configurarse para establecer enlaces de comunicación con uno o más de los nodos WLAN (por ejemplo, para establecer un enlace de comunicación con un dispositivo, tal como el dispositivo 108), tal como los puntos de acceso 106a-e, que pueden ser parte de la red 110, para comunicar datos y/o señales de control a esos puntos de acceso, y recibir datos y/o señales de control desde los puntos de acceso. Cada uno de los puntos de acceso 106a-e puede, a su vez, establecer enlaces de comunicación con dispositivos (por ejemplo, dispositivos móviles) ubicados dentro del alcance de los respectivos puntos de acceso 106a-e. Los servidores 120 y 122 también pueden configurarse para establecer enlaces de comunicación (directamente por medio de un/varios transceptor(es) inalámbrico(s) o, indirectamente, por medio de una conexión de red) con uno o más de los nodos WWAN (tal como los puntos de acceso WWAN 104a-c representados en la FIG. 1, que también puede ser parte de la red 110), y/o establecer enlaces de comunicación con un dispositivo inalámbrico, tal como el dispositivo 108.
[0025] Con referencia a la FIG. 2, se muestra un diagrama de flujo de un procedimiento 200 de ejemplo para facilitar el suministro de datos de sesión de seguimiento (datos o metadatos de emergencia) por parte de un dispositivo (que puede ser un dispositivo móvil personal, un dispositivo inalámbrico instalado en un vehículo, etc., y que tiene una configuración y funcionalidad similares a las del dispositivo 108 representado en la FIG. 1) en situaciones que involucran una emergencia. También se proporcionan detalles referentes al procedimiento 200 con respecto a la FIG.
3, que muestra un diagrama de flujo de llamada 300 de ejemplo que ilustra implementaciones de ejemplo de comunicación de datos en situaciones de emergencia. Por tanto, como se muestra, el procedimiento 200 incluye recibir 210 mediante un dispositivo (tal como el dispositivo 108) un mensaje desencadenante desde un servidor de llamadas de emergencia (que puede ser similar, en configuración y/o funcionalidad, al servidor 120 de la FIG. 1) en respuesta a una indicación de una condición de emergencia en el dispositivo para iniciar una sesión de seguimiento para recopilar y enviar periódicamente datos de sesión de seguimiento asociados al dispositivo a uno o más servidores. La indicación de la condición de emergencia puede haber sido enviada por iniciativa del dispositivo, o puede haber sido enviada por otro dispositivo (asociado a terceros que notifica una emergencia que involucra a otra parte). Los ejemplos de la indicación de la condición de emergencia transmitida al servidor de llamadas de emergencia incluyen un mensaje basado en E911, un mensaje eCall, etc. La indicación de la condición de emergencia (es decir, mensaje de emergencia) puede transmitirse al servidor de llamadas de emergencia a través de uno o más puntos de acceso con los que el dispositivo puede establecer un enlace de comunicación. Por ejemplo, en la FIG. 1 el mensaje de emergencia puede comunicarse al servidor de llamadas de emergencia 120 por medio de la estación base 104a. Sin embargo, se puede establecer un enlace de comunicación con el servidor de llamadas de emergencia 120 por medio de cualquier otro de los puntos de acceso, por medio de la red 110, o directamente entre el dispositivo y el servidor 120 (es decir, sin ningún nodo intermedio a través del cual se encamine el mensaje de emergencia). El establecimiento de una sesión de emergencia entre el dispositivo y el servidor de llamadas de emergencia puede incluir el establecimiento de un enlace de comunicación basado en voz entre los dos dispositivos, así como un canal de datos y control entre los dos dispositivos (que puede funcionar de manera autónoma a partir del enlace/canal de voz-datos). El enlace basado en voz puede conectar un operador activo con el usuario que maneja el dispositivo que envía la indicación de la condición de emergencia. De forma alternativa, el enlace basado en voz puede conectar al usuario del dispositivo con un mensaje de voz automatizado que guía al usuario para proporcionar información pertinente con respecto a la emergencia. En algunos modos de realización, la indicación de la emergencia puede enviarse como uno de un mensaje de protocolo de posicionamiento de evolución a largo plazo (LPP), un mensaje de protocolo de inicio de sesión (SIP), un mensaje de sistema de telecomunicaciones móviles universal (UMTS) o un mensaje de protocolo seguro de transferencia de hipertexto (HTTPS), o cualquier combinación de los mismos. En algunos modos de realización, la indicación de la condición de emergencia puede ser iniciada por el dispositivo (por ejemplo, el dispositivo detecta, determina o se le notifica la existencia de una condición de emergencia, y comienza la comunicación con el servidor de llamadas de emergencia). De forma alternativa, la indicación de la condición de emergencia se puede comunicar al servidor de llamadas de emergencia en respuesta a un mensaje (por ejemplo, un mensaje de radiodifusión) que el dispositivo recibe desde el servidor de llamadas de emergencia (por ejemplo, el servidor de llamadas de emergencia se puede configurar para sondear dispositivos para determinar si alguno de esos dispositivos puede tener una condición de emergencia existente). En algunos modos de realización, se puede configurar un mensaje desencadenante enviado por el servidor de llamadas de emergencia (en respuesta a un mensaje de notificación enviado por algún dispositivo asociado a terceros que es diferente del usuario del dispositivo al que se envía el mensaje desencadenante) para hacer que el dispositivo receptor (por ejemplo, el dispositivo 108) responda al mensaje de solicitud de alguna manera (por ejemplo, para entrar en una sesión de seguimiento con algún servidor designado de seguimiento de emergencia) sin que el dispositivo o su usuario puedan ejercer discreción.
[0026] Las operaciones de ejemplo para notificar una condición de emergencia y comunicar datos de sesión de seguimiento también se ilustran en la FIG. 3, que muestra un mensaje de solicitud de llamada de emergencia 310 de ejemplo que puede transmitirse desde un dispositivo de destino 302 (que puede ser similar, en configuración y/o funcionalidad, al dispositivo 108 de la FIG. 1) a un servidor de llamadas de emergencia 304 (que puede ser similar, en configuración y/o funcionalidad, al servidor 120 de la FIG. 1). Como se señaló, la indicación de la condición de emergencia puede haberse transmitido desde otro dispositivo diferente que notifica una emergencia que involucra al dispositivo 302 o al usuario del dispositivo 302. En algunas implementaciones, el servidor 304 puede ser un servidor PSAP. El mensaje de solicitud de llamada de emergencia 310 puede configurarse de acuerdo con un protocolo de inicio de sesión (SIP), un protocolo de posicionamiento de evolución a largo plazo (LTE), un protocolo de sistema de telecomunicaciones móviles universal (UMTS), un protocolo seguro de transferencia de hipertexto (HTTPS), o puede configurarse de acuerdo con cualquier otro protocolo de comunicación para establecer conectividad e interactividad entre el dispositivo de destino (108 o 302) y otro dispositivo/servidor. Como se muestra en la FIG. 3, el mensaje de solicitud de llamada de emergencia 310 (en este ejemplo, transmitido desde el dispositivo 302) puede incluir información tal como las capacidades de dispositivo (UE) para proporcionar datos referentes a las capacidades y recursos del dispositivo móvil (por ejemplo, disponible para admitir sesiones de comunicación) y el tipo de emergencia (por ejemplo, médica, de vehículo, criminal, etc.). Aunque no se muestra en la FIG. 3, los datos incluidos con el mensaje de solicitud de llamada de emergencia 310 también pueden incluir, en algunos modos de realización, información de posicionamiento, por ejemplo, una aproximación de posición obtenida por el dispositivo de destino y/o por un servidor de ubicación en base a las señales recibidas por el dispositivo de destino, mediciones de señales recibidas por el dispositivo de destino y comunicadas total o parcialmente al servidor 304, una indicación de puntos de acceso cercanos (de los cuales se puede obtener una posición aproximada o inexacta del dispositivo móvil), etc. Otra información que puede incluirse con el mensaje 310 puede incluir el nivel de batería actual, una estimación de la cantidad de recopilación de datos que el dispositivo podría permitirse con el nivel de batería actual, etc.
[0027] En algunas implementaciones, los datos incluidos con el mensaje de solicitud de llamada de emergencia 310 pueden usarse para determinar, por ejemplo, mediante el servidor de llamadas de emergencia 304 y/o mediante algún otro servidor, si una sesión de seguimiento (que, en general, es una sesión separada de/diferente a la sesión de llamada de emergencia actual establecida entre el dispositivo de destino 302 y el servidor de llamadas de emergencia 304) debe establecerse entre el dispositivo de destino 302 y uno o más servidores de seguimiento de emergencia, tal como un servidor 306 representado esquemáticamente en la FIG. 3 (el servidor 306 puede ser similar, en configuración y/o funcionalidad, al servidor 122 representado en la FIG. 1). La determinación de si se debe establecer una sesión de seguimiento puede basarse, por ejemplo, en las capacidades de dispositivo del dispositivo de destino 302 que pueden haberse comunicado en el mensaje 310. Por ejemplo, la información de capacidades puede incluir información tal como los transceptores y/o sensores del dispositivo de destino 302, protocolos de comunicación admitidos por el dispositivo de destino 302, etc., y, por lo tanto, puede indicar si el dispositivo de destino puede establecer una sesión de seguimiento con el servidor de seguimiento de emergencia 306. De forma alternativa y/o adicional, la decisión de iniciar una sesión de seguimiento puede estar condicionada de modo que una cantidad mínima de energía de la batería tenga que estar disponible actualmente en el dispositivo (en dichos modos de realización, el mensaje de solicitud 310 puede incluir, por tanto, el nivel de batería del dispositivo de destino). Se puede comunicar una solicitud de sesión de seguimiento al dispositivo móvil de destino 302 en respuesta a una determinación de que las capacidades de dispositivo para el dispositivo (como se especifica, por ejemplo, en el mensaje 310) coinciden o exceden los requisitos/criterios para establecer una sesión de seguimiento. La determinación de si la sesión de seguimiento debe establecerse también puede basarse en el tipo de emergencia indicado en la información comunicada en el mensaje 310. Por ejemplo, una emergencia médica puede justificar una sesión de seguimiento para enviar periódicamente información actualizada sobre la condición médica actual de una persona (la persona puede ser el usuario del dispositivo de destino que envió el mensaje 310), enviar datos acerca de los cambios a la ubicación del usuario (de modo que un equipo de emergencia enviado pueda localizar más rápidamente a la persona afectada), etc. Por otro lado, una emergencia para notificar una posible actividad delictiva que afecte a una persona que no sea la persona que llama puede no justificar la transmisión de datos de sesión de seguimiento periódica (por ejemplo, porque la persona que notifica puede haber abandonado el lugar de los hechos y ya no puede proporcionar datos relacionados con la situación de emergencia). Además, la determinación de si se debe iniciar una sesión de seguimiento también puede basarse en la entrada de un operador activo con el que el usuario del dispositivo de destino puede estar interactuando. Por ejemplo, a pesar de que el dispositivo de destino puede tener las capacidades necesarias para admitir una sesión de seguimiento, el operador activo puede decidir renunciar a una sesión de seguimiento si el operador activo determina, por ejemplo, que la emergencia no justifica una sesión de seguimiento (por ejemplo, la emergencia es de una naturaleza relativamente menor), que el usuario del dispositivo está notificando la emergencia en nombre de un tercero (en cuyo caso, la obtención de datos adicionales de la sesión de seguimiento no proporcionaría ninguna otra información útil), la propia sesión de seguimiento puede poner al usuario del dispositivo en una situación más peligrosa que la actual, etc. Por lo tanto, puede implementarse cualquier número de procedimientos/técnicas para determinar si una sesión de seguimiento debe establecerse en base a factores/criterios/requisitos, tales como el tipo de emergencia, las capacidades de dispositivo, el nivel de batería de dispositivo, una condición de usuario (por ejemplo, no rastrear a un tercero que notifica la emergencia pero que no se ve afectado por la misma) (incluidos procedimientos para enviar una solicitud a uno o más dispositivos que no han iniciado una llamada de emergencia, para iniciar una sesión de seguimiento en los mismos, por ejemplo, en situaciones catastróficas).
[0028] Por lo tanto, si se determina que se va a iniciar una sesión de seguimiento, el servidor de llamadas de emergencia 304 está configurado para transmitir un mensaje desencadenante, por ejemplo, un mensaje Solicitar Seguimiento de Metadatos 320 en el ejemplo de la FIG. 3, que está configurado para hacer que el dispositivo receptor (en este caso, el dispositivo de destino 302) genere o inicie una sesión de seguimiento, como se analizará en mayor detalle posteriormente, para que el dispositivo móvil recopile y envíe periódicamente datos de sesión de seguimiento (metadatos o datos de emergencia) asociados al dispositivo móvil a uno o más servidores de seguimiento de emergencias. La sesión de seguimiento que se iniciará está separada (por ejemplo, es diferente y/o independiente) de la sesión de llamada de emergencia entre el servidor de llamadas de emergencia 304 y el dispositivo 302. El mensaje 320 se puede configurar o formatear de acuerdo con el mismo protocolo de comunicación que el del mensaje iniciador 310 (por ejemplo, de acuerdo con un protocolo SIP, un protocolo LPP, un protocolo UMTS, un protocolo HTTPS o algún otro protocolo), y puede incluir (por ejemplo, en los campos de datos definidos para el mensaje) información tal como los tipos de datos (denominados "tipo de metadatos" en la FIG. 3) que el dispositivo móvil de destino va a recopilar y comunicar periódicamente a un servidor de seguimiento de emergencias (por ejemplo, para una emergencia médica, los tipos de datos pueden incluir datos de posicionamiento que reflejan cambios en la posición del dispositivo móvil, datos biométricos, etc.) e información que identifica el/los servidor(es) de seguimiento de emergencias (denotada como "URL de servidor ETS" en la FIG. 3) al/a los que se transmitirán los datos (o metadatos) de seguimiento recopilados por el dispositivo de destino 302. Por ejemplo, en algunos modos de realización, el mensaje 320 puede incluir una identificación de URL para el/los servidor(es) de seguimiento de emergencias, una dirección de red, un número de teléfono, algún otro identificador único del/de los servidor(es) que recibirá(n) los metadatos o datos de sesión de seguimiento recopilados, etc. En algunos modos de realización, al recibirse, mediante el dispositivo de destino 302, el mensaje desencadenante (por ejemplo, el mensaje Solicitar Seguimiento de Metadatos 320), puede terminarse el enlace de comunicación entre el dispositivo de destino 302 y el servidor de llamadas de emergencia 304.
[0029] Volviendo a la FIG. 2, después de recibir el mensaje desencadenante, la sesión de seguimiento, separada (por ejemplo, diferente y/o independiente) de la sesión de llamada de emergencia entre el dispositivo y el servidor de llamadas de emergencia, se establece 220 entre el dispositivo (108 o 302) y uno o más servidores. En algunos modos de realización, el establecimiento de la sesión de seguimiento separada requiere el establecimiento de diferentes enlaces de comunicación con el/los servidores de seguimiento de emergencia (tal como el servidor 122 de la FIG. 1 o el servidor 306 de la FIG. 3). En algunos modos de realización, el servidor de llamadas de emergencia 304 también puede usarse para implementar el servidor de seguimiento de emergencias 306 configurado para recibir, procesar y comunicar datos de seguimiento procedentes de dispositivos de destino (tales como el dispositivo móvil 108 o el dispositivo 302 de las FIG. 1 y 3, respectivamente).
[0030] Como se ilustra en la FIG. 3, el dispositivo de destino puede comunicar un mensaje Solicitud de Seguimiento de Emergencia 330 a uno o más servidores que se identificaron en el mensaje Solicitar Seguimiento de Metadatos 320 que recibió el dispositivo de destino 302, por ejemplo, el mensaje Solicitud de Seguimiento de Emergencia 330 puede transmitirse al/a los servidor(es) de seguimiento de emergencias correspondiente(s) a los URL proporcionados por el servidor 304 en el mensaje 320. El mensaje Solicitud de Seguimiento de Emergencia 330 puede incluir las capacidades de dispositivo del dispositivo 302 (que pueden ser iguales o diferentes de la información proporcionada con el mensaje 310 comunicado al servidor de llamadas de emergencia 304), información del tipo de emergencia (que también puede ser la misma o diferente de la información con respecto al tipo de emergencia proporcionado con el mensaje 310), el nivel de batería del dispositivo o una estimación de cuánto tiempo el dispositivo puede mantener una sesión de seguimiento, y también puede proporcionar una captura inicial de los datos de seguimiento que van a ser enviados periódicamente por el dispositivo de destino 302 (los datos de sesión de seguimiento/metadatos se proporcionan en el campo "metadatos de emergencia" del mensaje 330). Como se describe en el presente documento, los datos particulares de sesión de seguimiento que se recopilarán pueden haberse determinado durante la sesión de llamada de emergencia entre el servidor 304 y el dispositivo de destino, y especificado en el mensaje Solicitar Seguimiento de Metadatos 320 enviado por el servidor 304 al dispositivo de destino 302. El mensaje Solicitud de Seguimiento de Emergencia 330 enviado al/a los servidor(es) de seguimiento de emergencias puede incluir un tipo adicional de información no mostrado en la FIG. 3, tal como la duración de la sesión de seguimiento que debe cubrirse hasta que llegue el equipo de emergencia, donde tales datos indican un tiempo de llegada estimado (ETA) para la respuesta de emergencia (que puede usarse para decidir diferentes niveles de granularidad de datos a recopilar). El mensaje 330 (y cualquier mensaje posterior enviado durante la sesión de seguimiento) puede ajustarse a diversos protocolos de comunicación, tal como el protocolo SIP, o cualquier otro protocolo a través del cual el dispositivo de destino 302 y el/los servidor(es) de seguimiento de emergencias pueden comunicarse. El/los servidor(es) de seguimiento de emergencias 306 está(n) configurado(s) para recibir los datos/metadatos de sesión de seguimiento recopilados por el dispositivo de destino 302, procesarlos (por ejemplo, obtener aproximaciones de posición actualizadas para el dispositivo), obtener información actualizada de la emergencia (por ejemplo, información biométrica actualizada) y comunicar los datos a dispositivos apropiados asociados al personal de emergencia enviado para atender la emergencia o a bases de datos globales y sistemas expertos (por ejemplo, para obtener y mantener estadísticas, tales como estadísticas de resolución de emergencias, análisis de riesgo para seguros, etc.).
[0031] En algunos modos de realización, y como se ilustra adicionalmente en la FIG. 3, en respuesta a la recepción del mensaje Solicitud de Seguimiento de Emergencia 330 desde el dispositivo de destino 302 (que puede haber incluido las capacidades del dispositivo de destino, el tipo de emergencia y/o un conjunto de datos de sesión de seguimiento recopilados por el dispositivo de destino), el servidor de seguimiento de emergencias 306 puede generar y comunicar al dispositivo de destino 302 un mensaje Respuesta de Seguimiento de Emergencia 340. Para limitar la carga de procesamiento para el/los servidor(es) 306 (lo que puede basarse en el número de dispositivos/clientes atendidos por el servidor 306, el ancho de banda y/u otras limitaciones de recursos del servidor 306, etc.), el mensaje de respuesta 340 puede incluir, en algunos modos de realización, datos que indican una periodicidad máxima (por ejemplo, frecuencia máxima de transmisiones de datos, que refleja el intervalo de tiempo mínimo permitido entre transmisiones/cargas consecutivas de datos de seguimiento para ayudar a evitar que el servidor de seguimiento tenga fallos debidos a una sobrecarga de transmisión de datos).
[0032] En algunos modos de realización, el usuario y/o cualquiera de los uno o más servidores de seguimiento de emergencia (tal como el servidor 306 representado en la FIG. 3) puede ser capaz de terminar la sesión de seguimiento iniciada. Por ejemplo, si el usuario no está directamente involucrado en la emergencia (y simplemente notificó la situación de emergencia), ese usuario puede no desear que su dispositivo transmita datos de sesión de seguimiento (donde dichos datos de sesión de seguimiento se han planificado automáticamente para su transmisión como un resultado del mensaje desencadenante enviado desde el servidor de llamadas de emergencia). En esa situación, el usuario puede introducir un código (una contraseña) y/o seguir una secuencia de operaciones (por ejemplo, pulsar botones del dispositivo de acuerdo con algún patrón predeterminado) para anular la sesión de seguimiento iniciada (que también puede haber provocado que el dispositivo entre en una configuración de energía de emergencia, como se describirá más en detalle posteriormente). En otro ejemplo, el servidor de seguimiento de emergencias (por ejemplo, el servidor 122 de la FIG. 1 o el servidor 306 de la FIG. 3), puede determinar que la sesión de seguimiento puede finalizar (por ejemplo, debido a limitaciones de recursos porque, por ejemplo, no hay suficiente ancho de banda para realizar un seguimiento de una gran cantidad de sesiones de seguimiento actuales, porque un equipo de emergencia llegó al lugar de la emergencia, o por alguna otra razón). En tales circunstancias, el/los servidor(es) de seguimiento de emergencias puede(n) configurarse para transmitir un mensaje de finalización de sesión configurado para hacer que el dispositivo cancele la sesión de seguimiento, incluso para volver a la configuración de energía normal del dispositivo y para interrumpir los enlaces entre el dispositivo y el/los servidor(es) de seguimiento de emergencias. Además, el servidor de seguimiento de emergencias puede indicar al dispositivo que cambie su comportamiento de seguimiento, tal como el tipo de datos de seguimiento a recopilar, la cantidad de datos a recopilar o una combinación de ambas cosas. Sin embargo, otro mensaje de comando podría indicar al dispositivo que busque la continuación de la sesión de seguimiento con un servidor de seguimiento de emergencias diferente al que actualmente gestiona la sesión de seguimiento, debido, por ejemplo, a las limitaciones del servidor de seguimiento actual para gestionar la sesión de seguimiento de dispositivo (por ejemplo, redirección a otro servidor de seguimiento).
[0033] Como se señaló, en algunos modos de realización, en respuesta a la recepción del mensaje desencadenante desde el servidor de llamadas de emergencia (al que se envió la indicación de la condición de emergencia) para establecer la sesión de seguimiento separada, el dispositivo puede entrar en un estado de modo de seguimiento de energía reducida. Por ejemplo, se reduce la energía proporcionada a los subsistemas del dispositivo no requeridos para recopilar o comunicar los datos de sesión de seguimiento asociados al dispositivo, y se proporciona al menos una energía parcial a uno o más subsistemas de sensor o comunicación del dispositivo para hacer que el uno o más subsistemas de sensor o comunicación funcionen, al menos parcialmente, mientras el dispositivo está en el estado de modo de seguimiento de energía reducida para comunicar al uno o más servidores al menos algunos de los datos de sesión de seguimiento. Por lo tanto, cuando se inicia una sesión de seguimiento, el dispositivo de destino entra (generalmente de forma automática) en una configuración de energía de emergencia para conservar la energía de modo que los recursos del dispositivo se puedan dedicar a dar soporte a la sesión de seguimiento y tratar la condición de emergencia. En el estado de modo de seguimiento de energía reducida, los subsistemas del dispositivo de destino, tal como el subsistema de visualización/vídeo, el subsistema de procesador de aplicaciones (que admite funcionalidad de propósito general no relacionada con emergencias, por ejemplo, funcionalidad de correo electrónico) y otras funciones de control de subsistemas similares que no son necesarias para recopilar o comunicar datos de emergencia, tienen sus funciones significativamente reducidas (o completamente desactivadas). Por ejemplo, el procesador de aplicaciones puede pasar por un proceso de limpieza, con la mayoría de las actividades en segundo plano desactivadas, y puede notificar a otros subsistemas acerca del modo de emergencia. El subsistema de procesador de aplicaciones puede entrar en el estado de energía reducida (o modo de suspensión) tan pronto como finalice la llamada de emergencia y comience la sesión de seguimiento de emergencia. La configuración del estado de modo de seguimiento de energía reducida de emergencia puede realizarse usando un perfil de energía predeterminado u obtenible dinámicamente (por ejemplo, en base a parámetros de seguimiento especificados, por ejemplo, en el mensaje 340 enviado por un servidor de seguimiento de emergencias) para interrumpir el suministro de y/o proporcionar energía a un nivel específico a diversos subsistemas del dispositivo.
[0034] Como se señaló, durante un intervalo que se produce mientras el dispositivo está en la configuración de energía de emergencia (es decir, la configuración de estado de modo de seguimiento de energía reducida), algunos sensores y otros subsistemas (incluidos los subsistemas de comunicación, tales como los diversos transceptores del dispositivo móvil) pueden mantenerse activos para funcionar con al menos una operatividad o capacidad parcial. Por ejemplo, el subsistema de módem, que se encarga de solicitar, recopilar y cargar metadatos de dispositivo a un servidor de ubicación, puede, cuando se produce una condición de emergencia, consultar el subsistema de tecnología inalámbrica Bluetooth® para determinar/identificar dispositivos ponibles disponibles, y registrar una recopilación de datos de tecnología inalámbrica Bluetooth®, así como una recopilación de datos WLAN (por ejemplo, WiFi) y WWAN. En consecuencia, se puede configurar un temporizador de activación para recopilar, empaquetar y cargar datos de sesión de seguimiento (datos/metadatos de emergencia). En otro ejemplo, los subsistemas de conectividad (por ejemplo, los transceptores de tecnología inalámbrica WWAN/WLAN/Bluetooth®) pueden mantenerse activos (por ejemplo, en estado activo intenso, independientemente del estado de energía del dispositivo), para generar y comunicar datos WWAN/WLAN, así como para conectarse a dispositivos ponibles (por ejemplo, por medio de tecnología inalámbrica Bluetooth® o por medio de alguna otra tecnología de campo cercano). Como otro ejemplo, el subsistema de sensores puede mantenerse en estado activo intenso para generar datos de sensor (a partir del acelerómetro, el giroscopio, el barómetro, etc.) si es necesario. En algunos modos de realización, al menos algunos de los subsistemas necesarios para recopilar y comunicar datos de sesión de seguimiento pueden activarse de forma intermitente (con el fin de ahorrar energía) para recopilar datos y/o realizar mediciones.
[0035] Los sensores u otros subsistemas que se necesitan para recopilar y comunicar datos pueden determinarse, al menos en parte, en base al parámetro de seguimiento especificado, por ejemplo, en el mensaje de respuesta, tal como el mensaje 340, enviado al dispositivo como parte del procedimiento de establecimiento de sesión de seguimiento. En instantes de tiempo especificados durante la sesión de seguimiento (mientras el dispositivo está funcionando en la configuración de energía de emergencia) uno o más de los transceptores de comunicación pueden activarse para generar una transmisión periódica de al menos algunos de los datos de sesión de seguimiento recopilados (donde tales datos se recopilan durante el intervalo o cuando los subsistemas involucrados en la recopilación y la comunicación de datos de emergencia se activan de acuerdo con los tiempos de activación determinados). Si bien el consumo de energía real del dispositivo puede fluctuar cuando el dispositivo está realizando una sesión de seguimiento, la energía total consumida durante ese tiempo generalmente no supera algún nivel predeterminado (que, como se indicó, es un nivel reducido del nivel de energía alcanzado durante el funcionamiento normal del dispositivo cuando el dispositivo no admite una sesión de seguimiento debido a una condición de emergencia).
[0036] Los dispositivos y módulos de sensor que pueden mantenerse activos (aunque puedan funcionar con una configuración de energía inferior a la normal) pueden incluir sensores alojados dentro del dispositivo, incluidos uno o más sensores de inercia/orientación (por ejemplo, acelerómetro, giroscopio, magnetómetro, etc.), un termómetro, un barómetro, un sensor óptico, un sensor de humedad, un sensor de luz ambiental, etc. Los dispositivos y módulos de sensor que recopilan datos de sesión de seguimiento también pueden incluir sensores alojados fuera del dispositivo (posiblemente incluso de forma remota al dispositivo), y pueden incluir uno o más sensores biométricos (por ejemplo, monitor cardíaco, monitor de oxígeno, sensor respiratorio, etc.), uno o más sensores de vehículo para un vehículo desde el cual se envió el mensaje de emergencia (por ejemplo, sensor de indicador de aceite, sensor de temperatura del motor, sensor de indicador de combustible, indicadores y sensores basados en el panel de instrumentos, etc.). Sensores no acoplados directamente al dispositivo, tales como sensores de vehículo, o diversos sensores biométricos, pueden necesitar establecer enlaces de comunicación (por ejemplo, por medio de transceptores o interfaces de campo cercano del dispositivo) y, por lo tanto, se puede usar la configuración de energía de emergencia activada durante una sesión de seguimiento (por ejemplo, por un controlador del dispositivo móvil) para iniciar de forma periódica/intermitente un enlace de comunicación con uno cualquiera de los dispositivos o módulos de sensor remotos para obtener datos de medición/seguimiento a partir de esos dispositivos y/o módulos de sensor.
[0037] Los dispositivos y módulos de sensor del dispositivo de destino, que pueden funcionar durante una sesión de seguimiento, también pueden incluir transceptores y otros módulos sensoriales (por ejemplo, un módulo RTT, un módulo RSSI, etc.) para leer/medir señales de radio de nodos de red (por ejemplo, nodos WLAN, nodos WWAN, nodos de campo cercano, etc.), que pueden ser utilizadas (por el dispositivo de destino o por un servidor remoto, tal como el servidor de seguimiento de emergencias 306 o algún otro servidor de ubicación) para determinar los datos basados en ubicación para el dispositivo. Como tales, los datos recopilados por estos dispositivos de sensor pueden incluir datos basados en la ubicación, información de puntos de acceso WiFi, información de baja energía Bluetooth (BTLE) y/o información de determinación de distancias. Los datos recopilados durante la sesión de seguimiento también pueden incluir información de identificación asociada al dispositivo de destino (por ejemplo, su dirección MAC), así como datos recopilados por medio de puertos de acoplamiento directo (por ejemplo, puertos USB). Algunos de los subsistemas de comunicación y sensor del dispositivo (por ejemplo, uno o más de sus transceptores, tales como los transceptores WWAN o WLAN) pueden, al menos periódicamente, entrar en su estado activo para transmitir a dispositivos/nodos remotos (tal como el servidor de seguimiento de emergencias 306 de la FIG. 3) datos recopilados por los sensores y otros subsistemas que el dispositivo mantiene en un estado activo, o un estado activo parcial, durante la sesión de seguimiento.
[0038] En algunos modos de realización, cuando el dispositivo de destino entra en una sesión de seguimiento, el dispositivo puede configurarse para evitar o inhibir la desactivación de los subsistemas de sensor y de comunicación del dispositivo necesarios para la recopilación y comunicación de los datos de sesión de seguimiento. Por lo tanto, para garantizar que se pueda proporcionar un servicio de emergencia para remediar la condición de emergencia, el dispositivo se puede configurar para continuar funcionando en modo de emergencia (por ejemplo, estado de energía reducida) en el que los datos de sesión de seguimiento todavía se pueden recopilar y comunicar a servidores de seguimiento de emergencias incluso si el usuario intenta (y posiblemente consigue) apagar (por ejemplo, desconectar) el dispositivo.
[0039] Volviendo a la FIG. 2, los datos de sesión de seguimiento recopilados durante la sesión de seguimiento (de sensores y otros subsistemas que son activados o contactados, de manera intermitente o continua, por el dispositivo mientras el dispositivo está funcionando en estado de energía reducida/energía de emergencia) se envían 230 al uno o más servidores (por ejemplo, servidores de seguimiento de emergencias que pueden estar dedicados a una emergencia en particular, tal como una emergencia debida a un incendio, una emergencia médica, una emergencia de rescate, una emergencia en carretera, etc.) con los cuales el dispositivo ha establecido la sesión de seguimiento. En algunos modos de realización, el dispositivo (por ejemplo, el dispositivo 108 de la FIG. 1 o el dispositivo 302 de la FIG. 3) puede determinar el/los instante(s) de tiempo en los que enviar/transmitir al menos algunos de los datos de sesión de seguimiento recopilados. La periodicidad de los intervalos para recopilar datos y/o los instantes de tiempo en los que se enviarán al menos algunos de los datos recopilados en el/los intervalo(s) anterior(es) pueden ser elásticos/ajustables, es decir, el dispositivo puede determinar períodos ajustables para recopilar y enviar datos de sesión de seguimiento basándose, por ejemplo, en un valor de periodicidad máxima (que puede haber sido determinado por el uno o más servidores de emergencia e indicado, por ejemplo, en el mensaje 340 enviado al dispositivo), el nivel de batería del dispositivo (por ejemplo, a medida que disminuye el nivel de la batería, el período entre transmisiones consecutivas al uno o más servidores de emergencia puede ampliarse para conservar la energía), el tiempo transcurrido desde la última vez que se transmitió la indicación de la condición de emergencia al servidor de llamadas de emergencia (por ejemplo, en algunos modos de realización, cuanto más tiempo haya transcurrido, menos útil será la recopilación de algunos datos), la cantidad de datos recopilados, el ancho de banda de conectividad, el tiempo de llegada estimado del equipo de emergencia, etc. Por lo tanto, en algunos modos de realización, el envío de los datos de sesión de seguimiento puede incluir determinar en un primer instante de tiempo uno o más tiempos de activación posteriores para transmitir datos al uno o más servidores. La determinación del uno o más tiempos de activación posteriores puede incluir determinar uno o más tiempos de activación periódicos ajustables posteriores para transmitir los datos de sesión de seguimiento al uno o más servidores en base a, por ejemplo, el nivel de carga de una batería del dispositivo, el tiempo transcurrido desde que se comunicó el mensaje de emergencia (por ejemplo, la indicación de la condición de emergencia), una periodicidad máxima para comunicar mediante el dispositivo los datos de sesión de seguimiento, el ancho de banda de conectividad o cualquier combinación de los mismos.
[0040] Los datos de sesión de seguimiento transmitidos son recibidos y procesados posteriormente por uno o más servidores de emergencias. Por ejemplo, el uno o más servidores de emergencia (por ejemplo, servidores de seguimiento de emergencias) pueden usar los datos de sesión de seguimiento recibidos para actualizar los datos de ubicación para el dispositivo de destino (por ejemplo, pueden usar información de determinación de distancias, otros tipos de mediciones basadas en la ubicación, mediciones de sensores inerciales, así como aproximaciones de ubicación previamente calculadas para el dispositivo, para obtener una aproximación de ubicación actual para el dispositivo). En modos de realización en los que los datos de sesión de seguimiento incluyen datos de sensor de sensores externos al dispositivo (por ejemplo, sensores biométricos y/o sensores de vehículo en comunicación con el dispositivo), el uno o más servidores de seguimiento de emergencias pueden calcular información relevante para la condición de emergencia (por ejemplo, constantes vitales de un usuario del dispositivo que está experimentando una emergencia médica). El procesamiento de los datos de sesión de seguimiento recibidos también puede incluir comunicar datos (por ejemplo, los datos sin procesar reales recibidos desde el dispositivo, o datos procesados resultantes procesados en base a los datos sin procesar recibidos desde el dispositivo) a uno o más dispositivos remotos, tales como dispositivos asociados a equipos de emergencia enviados para tratar la condición de emergencia, y/o comunicar los datos a bases de datos especializadas y sistemas expertos (por ejemplo, para calcular estadísticas para el análisis de riesgo para seguros, para el análisis de resolución de emergencia, etc.).
[0041] La FIG. 3 ilustra un ejemplo del envío periódico de datos de sesión de seguimiento al servidor de seguimiento de emergencias 306 de ejemplo con el que el dispositivo 302 ha establecido un enlace de sesión de seguimiento. En el ejemplo de la FIG. 3, al recibir el mensaje de respuesta de seguimiento de emergencia 340 desde el servidor de seguimiento de emergencias 306, que incluye los parámetros de seguimiento con respecto a los cuales el dispositivo de destino va a comunicar datos, y un valor de periodicidad máxima, el dispositivo puede calcular uno o más instantes de tiempo posteriores en los cuales los datos de sesión de seguimiento (por ejemplo, de acuerdo con los parámetros de seguimiento indicados en el mensaje 340) se recopilarán para su transmisión. En algunos modos de realización, el dispositivo puede calcular solamente un único instante de tiempo posterior, y calculará el siguiente después de enviar el conjunto correspondiente de datos de sesión de seguimiento en ese instante de tiempo posterior. Determinar solamente un único instante de tiempo posterior a la vez puede realizarse, por ejemplo, cuando la determinación de los tiempos de transmisión depende en gran medida del nivel de energía de la batería, el grado (cantidad) de cambio de datos de una recopilación a la siguiente (por ejemplo, la cantidad de datos que han cambiado), y otras consideraciones similares. En tales circunstancias, el cálculo de los tiempos de recopilación/transmisión de datos se puede realizar de uno en uno, de modo que, por ejemplo, al calcular el siguiente tiempo de recopilación/transmisión de datos pueda tenerse en cuenta el nivel de energía más actualizado de la batería del dispositivo. Por otro lado, en algunos modos de realización, se pueden calcular múltiples tiempos de recopilación/transmisión de datos posteriores, donde la longitud de intervalo de tiempo entre intervalos sucesivos aumenta (en algunos modos de realización) de acuerdo con alguna formulación basada en uno o más de, por ejemplo, el nivel de batería, el valor de periodicidad máxima, el tiempo transcurrido desde que se envió la indicación de la condición de emergencia al servidor de llamadas de emergencia, la naturaleza de la emergencia, el ancho de banda disponible para la transmisión de los datos recopilados, otros recursos disponibles para que el dispositivo realice la transmisión de los datos de sesión de seguimiento, y/o en otros factores.
[0042] Por tanto, en la FIG. 3, en algún tiempo T1, un instante de tiempo posterior, T2, puede determinarse en qué sesión de seguimiento los datos recopilados por el dispositivo 302 se enviarán, por medio del mensaje 350, al servidor de seguimiento de emergencias 306. El dispositivo puede determinar en T1, o en algún otro momento posterior (por ejemplo, en el tiempo T2, cuando se transmite el mensaje 350) un instante de tiempo adicional T3 en el que los datos de sesión de seguimiento recopilados por el dispositivo (por ejemplo, datos recopilados entre los instantes de tiempo T2 y T3 o, aproximadamente, en el instante de tiempo T3) se comunican, por medio de un mensaje 360, al servidor de seguimiento de emergencias 306. El período entre T3 y T2 define, para el ejemplo de la FIG. 3, la periodicidad inicial. El dispositivo 302 también puede determinar el instante de tiempo posterior (es decir, los tiempos de transmisión posteriores) T4, T5 y/o instantes de tiempo adicionales, donde algunos de esos instantes de tiempo futuros se determinan conjuntamente (es decir, de forma sustancialmente simultánea) o por separado. Como se muestra en la FIG. 3, los períodos entre los tiempos de transmisión pueden permanecer constantes durante algunos de los intervalos (por ejemplo, el período definido por T4 y T3 es sustancialmente igual, en el ejemplo de la FIG. 3, que la periodicidad inicial definida por T3 y T2), pero puede cambiar para tiempos de transmisión posteriores. Por ejemplo, la periodicidad posterior a la transmisión de un mensaje de datos de sesión de seguimiento 370 en T4 puede reducirse (por ejemplo, si el nivel de batería para el dispositivo 302 ha disminuido en una medida tal que requiere intervalos más largos entre transmisiones), y, por lo tanto, el período definido por los instantes de tiempo de transmisión T5 (en los que se transmite un mensaje de datos de sesión de seguimiento 380) y T4 es mayor que para períodos anteriores. El período de tiempo ajustable puede estar limitado por el valor de "periodicidad máxima" recibido, por ejemplo, con el mensaje de respuesta de seguimiento de emergencia 340 enviado por el servidor de seguimiento de emergencias 306. El valor de periodicidad máxima puede corresponder al ritmo (frecuencia) máximo de transmisión de datos que el servidor de seguimiento de emergencias puede necesitar manejar por el dispositivo en dificultades/situación de emergencia (definiendo así un intervalo de tiempo mínimo entre transmisiones). Esto puede garantizar que el/los servido(es) de seguimiento puedan equilibrar su propia carga en base a, por ejemplo, el número de dispositivos en dificultades que maneja actualmente.
[0043] Como se muestra adicionalmente en la FIG. 3, en algunos modos de realización, la sesión de seguimiento puede ser finalizada por el servidor de seguimiento de emergencias 306 que transmite un mensaje Solicitar Modificación/Finalización del Seguimiento de Metadatos 390. En algunos modos de realización, la finalización de la sesión de seguimiento puede ser iniciada por el dispositivo 302 o por algún otro dispositivo o entidad. El mensaje 390, cuando es recibido y procesado por el dispositivo 302, está configurado para hacer que los enlaces de comunicación entre el dispositivo 302 y el servidor de seguimiento de emergencias 306 se interrumpan, y para finalizar las operaciones de sesión de seguimiento (por ejemplo, recopilación y comunicación de datos de sesión de seguimiento en instantes de tiempo determinados por el dispositivo 302). La finalización de la sesión de seguimiento también hace que se restablezca la configuración de energía normal y el funcionamiento normal del dispositivo. En algunos modos de realización, el mensaje 390 puede configurarse, de forma alternativa y/o adicional, para modificar la sesión de seguimiento (por ejemplo, solicitar al dispositivo 302 que modifique los tipos de datos que recopila y transmite, modificar los tiempos en que se envían esos datos, solicitar el cambio del servidor de seguimiento que da servicio al dispositivo en dificultades, etc.)
[0044] En algunos modos de realización, los mensajes enviados durante una sesión de llamada de emergencia y/o una sesión de seguimiento pueden comunicarse con al menos una parte de los datos comunicados que se procesan (por ejemplo, firmados/cifrados) usando una clave privada (a partir de una clave criptografía pública/privada asimétrica, tal como una clave ECDSA) asignada al dispositivo de origen/transmisor para confirmar la autenticidad de los datos/identidad de dispositivo comunicados. Posteriormente, el dispositivo receptor puede usar la clave pública del dispositivo de origen (esa clave pública ya puede estar disponible en el dispositivo receptor, ya sea el dispositivo móvil o uno de los servidores) para descifrar la parte cifrada de los datos transmitidos para confirmar así l la autenticidad de los datos, así como la identidad del dispositivo en dificultades (y posiblemente la identidad del usuario del dispositivo). Por ejemplo, los datos transmitidos por el dispositivo de origen (tal como el dispositivo móvil 108 o el dispositivo 302 de las FIG. 1 y 3) pueden incluir algún mensaje predeterminado que se cifra usando la clave privada del dispositivo de origen. El dispositivo receptor/de destino (por ejemplo, los servidores 120, 122, 304 y/o 306 ilustrados en las FIG. 1 y 3) descifra ese mensaje cifrado para recuperar el mensaje y lo compara con el mensaje predeterminado esperado que se suponía que era enviado por el dispositivo de origen. Si hay una coincidencia, se considera que los datos recibidos en el dispositivo de destino se han recibido desde el dispositivo o usuario correcto. La autenticación del dispositivo que produce los datos se puede usar para evitar, por ejemplo, llamadas falsas. En algunos modos de realización, además de cifrar al menos una parte de los datos comunicados por el dispositivo de origen para autenticar los datos, al menos alguna otra parte de los datos comunicados puede cifrarse para proteger los datos. Por ejemplo, los datos transmitidos (por ejemplo, los datos de sesión de seguimiento transmitidos a un servidor de seguimiento de emergencias) pueden cifrarse usando una clave de cifrado secreta (que puede ser una clave criptográfica simétrica o asimétrica) conocida por lo que se divulga al dispositivo receptor/de destino. La seguridad de los datos se puede implementar para garantizar la validez de los datos comunicados y/o proporcionar privacidad a los datos (por ejemplo, para protegerlos contra piratas informáticos/individuos deshonestos que intentan evitar que los proveedores de servicios de emergencias respondan a la situación de emergencia).
[0045] Con referencia ahora a la FIG. 4, se muestra un diagrama de flujo de un procedimiento 400 de ejemplo, generalmente realizado en un servidor de llamadas de emergencia (tal como el servidor 120 de la FIG. 1 o el servidor 304 de la FIG. 3), para procesar comunicaciones de emergencia y facilitar el establecimiento de una sesión de seguimiento. El procedimiento 400 incluye recibir 410 mediante un servidor de llamadas de emergencia una indicación de una condición de emergencia en un dispositivo (tal como el dispositivo móvil 108 o el dispositivo 302 de las FIG. 1 y 3, respectivamente). Como se describe en el presente documento, la indicación de la condición de emergencia puede ser un mensaje configurado de acuerdo con uno cualquiera de diversos protocolos posibles, incluidos el protocolo de inicio de sesión (SIP), un protocolo de posicionamiento de Evolución a Largo Plazo (LTE), el protocolo seguro de transferencia de hipertexto (HTTPS), un protocolo del Sistema Universal de Telecomunicaciones Móviles (UMTS) u otros tipos de protocolos. La indicación recibida de la condición de emergencia puede incluir información como las capacidades de dispositivo del dispositivo, datos representativos del tipo de emergencia, datos basados en la ubicación, capacidades de procesamiento de dispositivo, etc.
[0046] En algunos modos de realización, la transmisión de la indicación de la condición de emergencia puede haber sido iniciada por el dispositivo de destino; por ejemplo, al determinar la existencia de una emergencia, el dispositivo, tal como el dispositivo 108 de la FIG. 1, envía un mensaje de inicio/origen a un servidor de llamadas de emergencia. En algunos modos de realización, la indicación de la condición de emergencia puede haber sido transmitida por el dispositivo de destino en respuesta a un mensaje de radiodifusión (que puede ser uno de los mensajes de radiodifusión transmitidos periódicamente) transmitido por el servidor de llamadas de emergencia. Por lo tanto, en dichos modos de realización, recibir la indicación de la condición de emergencia puede incluir transmitir a uno o más dispositivos, incluido el dispositivo, un mensaje de radiodifusión configurado para determinar si al menos un dispositivo de los uno o más dispositivos tiene una emergencia, y recibir, en respuesta al mensaje de radiodifusión transmitido por el servidor de llamadas de emergencia, un mensaje de respuesta desde el dispositivo, donde el mensaje de respuesta incluye la indicación de la condición de emergencia. Además, en algunos modos de realización, un dispositivo de usuario que recibe un mensaje no solicitado (es decir, un mensaje recibido independientemente de las acciones del dispositivo) desde un servidor de llamadas de emergencia puede estar configurado, en respuesta a ese mensaje recibido, para responder a ese mensaje no solicitado o para establecer una sesión de seguimiento con algún servidor de seguimiento de emergencia designado, sin que el dispositivo o su usuario ejerzan ninguna discreción sobre si realizar alguna acción en respuesta al mensaje no solicitado (por ejemplo, en una situación en la que el usuario del dispositivo receptor no puede responder al mensaje no solicitado).
[0047] Una vez recibida la indicación de la condición de emergencia, se determina 420 si el dispositivo debe rastrearse en base a, al menos en parte, la indicación de la condición de emergencia. Como se analiza en el presente documento, determinar si se debe establecer una sesión de seguimiento puede basarse, por ejemplo, en la información des capacidades de dispositivo del dispositivo de destino desde el cual se recibió la indicación de la condición de emergencia. Por ejemplo, la información de capacidades puede indicar si el dispositivo de destino es capaz de establecer una sesión de seguimiento con un servidor de seguimiento de emergencias (directamente o por medio de otro(s) nodo(s) de red). Que el dispositivo de destino pueda admitir una sesión de seguimiento puede depender, por ejemplo, de los tipos de transceptores incluidos en el dispositivo, los tipos de protocolos de comunicación que puede admitir el dispositivo, los tipos de sensores incluidos en el dispositivo, el nivel de batería del dispositivo, etc. En otro ejemplo, el tipo de emergencia se puede usar para determinar si se requiere una sesión de seguimiento, por ejemplo, una emergencia médica puede justificar una sesión de seguimiento con el fin de recopilar y enviar periódicamente información actualizada acerca de la condición médica actual de una persona. Además, la determinación de si se debe iniciar una sesión de seguimiento también puede basarse en la entrada de un operador activo con el que el usuario del dispositivo de destino puede estar interactuando. En algunos modos de realización, el servidor de llamadas de emergencia también puede configurarse para determinar la posición del dispositivo en base a, al menos en parte, datos basados en la ubicación (por ejemplo, datos representativos de la identidad de los puntos de acceso con los que el dispositivo está interactuando, datos de medición tales como RTT o RSSI medidos por el dispositivo para señales que ha recibido, etc.) incluidos en la indicación recibida de la condición de emergencia. Dichos datos de posicionamiento también se pueden usar para determinar si se inicia o no una sesión de seguimiento y, de ser así, la identidad de los servidores de seguimiento de emergencias con los que el dispositivo debe establecer una sesión de seguimiento.
[0048] En respuesta a una determinación (hecha en 420) de que el dispositivo debe ser rastreado, un mensaje desencadenante (configurado de acuerdo con el mismo protocolo, u otro diferente, según la indicación de la condición de emergencia recibida del dispositivo de destino) se transmite 430 desde el servidor de llamadas de emergencia para iniciar en el dispositivo (que comunicó la indicación de la condición de emergencia) una sesión de seguimiento para que el dispositivo recopile y envíe periódicamente datos de sesión de seguimiento a uno o más servidores, donde la sesión de seguimiento (establecida entre el dispositivo y el uno o más servidores de seguimiento) está separada (por ejemplo, es diferente y/o independiente) de la sesión de llamada de emergencia que se estableció entre el dispositivo y el servidor de llamadas de emergencia. El mensaje desencadenante puede incluir datos tales como el tipo de datos de emergencia (los datos de sesión de seguimiento) que el dispositivo debe recopilar y enviar a un servidor de seguimiento de emergencias (el tipo de datos que recopilar y enviar puede determinarse en base a los datos de capacidades de dispositivo especificados en la indicación de la condición de emergencia, en base al tipo de emergencia, etc.). En algunos modos de realización, el mensaje desencadenante transmitido al dispositivo está configurado además para hacer que el dispositivo funcione en un estado de modo de seguimiento de energía reducida en el que la alimentación a los sistemas del dispositivo no necesarios para recopilar y/o comunicar datos de sesión de seguimiento asociados al dispositivo se reduce (por ejemplo, la energía se corta sustancialmente para aquellos subsistemas/módulos que no sean esenciales para el seguimiento del dispositivo), y en el que uno o más subsistemas de comunicación o de sensor del dispositivo, configurados para realizar la recopilación y comunicación de los datos de la sesión de seguimiento, funcionan al menos parcialmente mientras el dispositivo está en el estado de modo de seguimiento de energía reducida. En situaciones donde el servidor de llamadas de emergencia recibe un mensaje de notificación (con la indicación de la condición de emergencia en el dispositivo de destino) desde otro dispositivo (diferente del dispositivo de destino) asociado a terceros (por ejemplo, el usuario de ese dispositivo de destino puede haberse quedado inconsciente o es el autor de la emergencia), el mensaje desencadenante puede ordenar/requerir que el dispositivo de destino entre en una sesión de seguimiento. Por lo tanto, en dichas situaciones, la transmisión del mensaje desencadenante desde el servidor de llamadas de emergencia puede incluir la transmisión de un comando de sesión de seguimiento obligatorio (por ejemplo, en respuesta a la determinación de que el dispositivo debe ser rastreado) para que el dispositivo establezca la sesión de seguimiento, donde el comando de sesión de seguimiento obligatorio no puede ser anulado por el dispositivo o por un usuario del dispositivo.
[0049] El procedimiento 400 también puede incluir, en algunas implementaciones, determinar el uno o más servidores de seguimiento con los que el dispositivo debe establecer la sesión de seguimiento separada. La determinación de los servidores de seguimiento puede basarse, por ejemplo, en la ubicación del dispositivo de destino, las capacidades del dispositivo, etc. La ubicación del dispositivo puede ser determinada por el servidor de llamadas de emergencia en base a, por ejemplo, los datos de ubicación proporcionados por el dispositivo de destino (por ejemplo, datos de ubicación incluidos con la indicación de la condición de emergencia, o incluidos en un mensaje separado), donde los datos de ubicación incluyen mediciones de señal/temporización, ubicación aproximada (por ejemplo, proporcionados como identificadores del área celular o de nodos en comunicación con el dispositivo), etc. De forma alternativa, la ubicación exacta o aproximada puede ser calculada directamente por el dispositivo de destino. El/los servidor(es) de llamadas de emergencia puede(n) determinar uno o más identificadores representativos del uno o más servidores de seguimiento determinados y proporcionar esos identificadores al dispositivo de destino. El identificador puede ser URL o algún otro tipo de información de direccionamiento asociada a los servidores de seguimiento determinados (por ejemplo, dirección IP), que el dispositivo de destino puede usar para contactarse a uno o más servidores de seguimiento. En algunos modos de realización, el procedimiento 400 también puede incluir finalizar la sesión de llamada de emergencia (por ejemplo, enviando un mensaje configurado para hacer que el dispositivo finalice o cancele la sesión de llamada de emergencia).
[0050] Con referencia ahora a la FIG. 5, se muestra un diagrama de flujo de un procedimiento 500 de ejemplo, generalmente realizado en un servidor de seguimiento de emergencias (tal como el servidor 122 de la FIG. 1, o el servidor 306 de la FIG. 3), para recibir y procesar datos de emergencia (también denominados metadatos o datos de sesión de seguimiento). El procedimiento 500 incluye recibir 510 mediante al menos un servidor (por ejemplo, un servidor de seguimiento de emergencia), desde un dispositivo (tal como el dispositivo móvil 108 o el dispositivo 302 de las FIGS. 1 y 3, respectivamente) una solicitud (tal como el mensaje 330 de la FIG. 3) para establecer una sesión de seguimiento para recopilar y enviar periódicamente datos de la sesión de seguimiento al al menos un servidor en relación con una condición de emergencia en el dispositivo. El dispositivo envía la solicitud para establecer la sesión de seguimiento en respuesta a un mensaje desencadenante de un servidor de llamadas de emergencia (tal como el servidor 120 o 304 de las FIG. 1 y 3, respectivamente) para iniciar la sesión de seguimiento. Ese mensaje desencadenante puede haber sido enviado desde el servidor de llamadas de emergencia en respuesta a una determinación (basada en una indicación enviada anteriormente de un mensaje de condición de emergencia recibido por el servidor de llamadas de emergencia desde el dispositivo) de que se debe establecer una sesión de seguimiento. El mensaje desencadenante se transmite desde el servidor de llamadas de emergencia al dispositivo durante una sesión de llamadas de emergencia, separada de la sesión de seguimiento, en respuesta al mensaje de indicación de la condición de emergencia en el dispositivo transmitido al servidor de llamadas de emergencia. En algunos modos de realización, el mensaje de indicación puede haber incluido datos tales como las capacidades del dispositivo, el tipo de emergencia y otra información en base a la cual se puede tomar la determinación de establecer la sesión de seguimiento. Como se señaló, en algunos modos de realización, el dispositivo está configurado para funcionar durante la sesión de seguimiento en un estado de modo de seguimiento de energía reducida en el que la alimentación a los subsistemas del dispositivo no requeridos para recopilar y comunicar los datos de sesión de seguimiento asociados con el dispositivo se reduce, y en el que uno o más subsistemas de sensor o comunicación del dispositivo, configurados para realizar la recopilación y comunicación de los datos de sesión de seguimiento, funcionan al menos parcialmente mientras el dispositivo está en el estado de modo de seguimiento de energía reducida. En algunos modos de realización, el mensaje de indicación de la condición de emergencia en el dispositivo (transmitido al servidor de llamadas de emergencia) puede incluir, por ejemplo, un mensaje de inicio del dispositivo con respecto a la condición de emergencia, un mensaje de respuesta del dispositivo en respuesta a un mensaje de sondeo del servidor de llamadas de emergencia o un mensaje de notificación desde otro dispositivo para notificar la condición de emergencia en el dispositivo.
[0051] Una vez que el al menos un servidor ha recibido el mensaje de solicitud, el al menos un servidor envía 520 una respuesta (por ejemplo, el mensaje 340 de la FIG. 3) al dispositivo para establecer la sesión de seguimiento. Como se señaló, la sesión de seguimiento es diferente de la sesión de llamada de emergencia y, por lo tanto, generalmente requiere el establecimiento de enlaces de comunicación diferentes de los que se establecieron entre el dispositivo y el servidor de llamadas de emergencia. En algunos modos de realización, el envío de la respuesta al dispositivo puede incluir el envío de la respuesta con datos que indiquen un valor de periodicidad máxima usado para determinar el uno o más instantes de tiempo de activación, posteriores al primer instante, y con datos representativos de parámetros de datos a incluir con los datos de sesión de seguimiento enviados por el dispositivo. También se pueden incluir otros datos, incluidos con otros campos o partes de la respuesta al dispositivo, tal como el tiempo esperado que la sesión de seguimiento debe durar hasta que llegue el equipo de emergencia.
[0052] Con una sesión de seguimiento establecida, el al menos un servidor recibe periódicamente 530, desde el dispositivo, los datos de sesión de seguimiento recopilados por el dispositivo durante la sesión de seguimiento. Los datos de sesión de seguimiento recibidos periódicamente pueden recibirse en uno o más instantes de tiempo de activación (que son posteriores a un primer instante de tiempo, por ejemplo, cuando el dispositivo ha recibido la respuesta del al menos un servidor y se establece la sesión de seguimiento), donde esos uno o más instantes de tiempo de activación se determinan en base a, al menos en parte, el nivel de energía de una batería del dispositivo. Otros factores/datos que se pueden usar para determinar uno o más instantes de tiempo de activación (también conocidos como tiempos de transmisión) incluyen los tipos de datos que se transmitirán, el tipo de emergencia involucrado, el tiempo transcurrido desde la llamada de emergencia (por ejemplo, al servidor de llamadas de emergencia), el tiempo esperado de llegada del equipo de emergencia, el ancho de banda de conectividad, etc. En algunos modos de realización, el procedimiento 500 puede incluir además determinar una posición del dispositivo en base a, al menos en parte, datos de determinación de la ubicación (por ejemplo, mediciones de señal recopiladas por el dispositivo, mediciones de sensores inerciales) incluidos en los datos de sesión de seguimiento recibidos. Los datos de determinación de ubicación recibidos durante la sesión de seguimiento también se pueden usar para actualizar una aproximación de posición inicial obtenida, por ejemplo, durante la sesión de llamada de emergencia. La actualización de la aproximación de posición inicial se puede realizar, en algunos modos de realización, usando un filtro de Kalman, un filtro de partículas u otras técnicas de estimación de ubicación. En algunos modos de realización, el procedimiento 500 también puede incluir el procesamiento (de al menos algunos) de los datos de sesión de seguimiento recibidos (por ejemplo, para determinar la posición del dispositivo móvil, determinar la condición física de un usuario, formatear y organizar los datos recibidos, etc.) y transmitir al menos algunos de los datos procesados resultantes a uno o más dispositivos asociados a uno o más proveedores de servicios de emergencia. Por ejemplo, el procesamiento puede incluir el procesamiento en tiempo real aplicado a los datos recibidos (por ejemplo, para filtrar datos irrelevantes, actualizar el estado de la persona en dificultades, etc.) que pueden reenviarse a dispositivos inalámbricos de la policía y el personal de ambulancias que puedan haberse enviado para gestionar/atender la situación de emergencia. El procesamiento también puede incluir un procesamiento fuera de línea, incluido obtener estadísticas de resolución de emergencia, realizar análisis de riesgo para seguros, etc.
[0053] Con referencia ahora a la FIG. 6, se muestra un diagrama de flujo de un procedimiento 600 de ejemplo que ilustra operaciones e interacciones en todo el sistema entre un dispositivo (por ejemplo, un dispositivo móvil inalámbrico para uso personal, un dispositivo inalámbrico instalado en un vehículo o avión, un dispositivo estacionario, etc.), un servidor de llamadas de emergencia y un servidor de seguimiento de emergencias para facilitar la recopilación y comunicación de datos de emergencia. Como se ilustra, el procedimiento 600 comienza, en algunos modos de realización, con un dispositivo móvil, tal como el dispositivo 108 o 302 de las FIGS. 1 y 3, enviando 610 una indicación de una condición de emergencia (por ejemplo, un mensaje E-911) a un servidor de llamadas de emergencia. La indicación puede enviarse directamente al servidor de llamadas de emergencia (por ejemplo, un PSAP), o por medio de uno o más nodos intermedios, y puede enviarse por iniciativa directa del dispositivo o en respuesta a, por ejemplo, un mensaje (por ejemplo, un mensaje de radiodifusión) del servidor de llamadas de emergencia. En algunos modos de realización, la indicación de la condición de emergencia puede haber sido enviada por un dispositivo de terceros (por ejemplo, el teléfono móvil de un testigo de una emergencia) para notificar una situación de emergencia que involucra a otra persona cuyo dispositivo va a entrar en el modo de seguimiento. Aunque el dispositivo de la FIG. 6 se representa en estado inactivo, el dispositivo puede estar realizando una o más tareas no relacionadas con la situación de emergencia.
[0054] En respuesta a la recepción de la indicación de la condición de emergencia, el servidor de llamadas de emergencia (también representado en estado inactivo, pero que puede estar realizando una o más tareas), el servidor de llamadas de emergencia determina 615 si el dispositivo debe ser rastreado. Como se describe en el presente documento, esta determinación puede basarse, entre otras cosas, en información incluida en la indicación de la condición de emergencia recibida desde el dispositivo, que incluye información de capacidades de dispositivo (por ejemplo, tipos de transceptores, sensores, protocolos de comunicación que el dispositivo tiene o admite, que indican si el dispositivo tiene los recursos de comunicación y de recopilación de datos para admitir una sesión de seguimiento), el tipo de emergencia, la ubicación actual del dispositivo, etc. Si se determina que no se realizará una sesión de seguimiento (por ejemplo, debido a que los recursos del dispositivo son insuficientes para admitir una sesión, ya que un operador activo determinó que no es necesario o práctico realizar una sesión de seguimiento, etc.), la sesión de llamada de emergencia no se inicia (y el servidor de llamadas de emergencia puede volver a un estado inactivo o a algún otro estado para realizar tareas tales como atender otra indicación de una condición de emergencia procedente de otro dispositivo). Si, por otro lado, se determina, en 615, que se realizará una sesión de seguimiento, el servidor de llamadas de emergencia envía 620 (también denotado como '2' en la FIG. 6) al dispositivo un mensaje desencadenante (también denominado mensaje Solicitar Sesión de Seguimiento, que puede ser similar al mensaje 320 de la FIG. 3) con datos que indican uno o más servidores de seguimiento de emergencia con los que el dispositivo debe establecer una/diversas sesión(es) de seguimiento. Se pueden identificar uno o más servidores de seguimiento (por ejemplo, en base a los datos de ubicación proporcionados por el dispositivo de destino, las capacidades de dispositivo, etc.) a través de URL, otras diversas formas de direccionamiento de red, otros tipos de identificadores de red, etc. El mensaje desencadenante enviado en 620 puede incluir datos adicionales (dispuestos en campos adicionales o porciones de mensajes), tal como una indicación de la periodicidad máxima que se usará durante las transmisiones de datos de emergencia de la sesión de seguimiento. En situaciones en las que la indicación de la condición de emergencia se transmitió desde el dispositivo de terceros, puede ser necesario requerir que el dispositivo de destino (que va a enviar datos de sesión de seguimiento) entre en una sesión de seguimiento obligatoria (por ejemplo, si el usuario del dispositivo de destino ha quedado inconsciente). En ese caso, el mensaje desencadenante puede ser un comando de sesión de seguimiento obligatorio que no puede ser anulado por el dispositivo de destino o por su usuario (o cualquier otra persona).
[0055] Como se ilustra adicionalmente en la FIG. 6, el servidor de seguimiento de emergencia especificado (o múltiples servidores, si se especifica más de uno) está esperando, antes del establecimiento de una sesión de seguimiento entre él mismo y el dispositivo, actualizaciones de datos de emergencia (del dispositivo del presente ejemplo y/o de otros dispositivos que atiende para facilitar la gestión de situaciones de emergencia), como se indica en el bloque 625 (también denotado como '4' en la FIG. 6). Cuando el dispositivo recibe desde el servidor de llamadas de emergencia el mensaje desencadenante, el dispositivo puede entrar, en 630 (denotado como '5' en la FIG. 6), en un modo de seguimiento, iniciando así una sesión de seguimiento. La sesión de seguimiento es una sesión separada (y puede ser independiente de) la sesión de llamada de emergencia entre el dispositivo y el servidor de llamadas de emergencia. El dispositivo móvil puede configurarse, al inicio de la sesión de seguimiento, para notificar a sus subsistemas esenciales (recursos de emergencia) que permanezcan activos, incluso si el dispositivo está apagado (es decir, bloquear el dispositivo en un modo de seguimiento incluso si el dispositivo es apagado por usuario). El dispositivo también se puede configurar para activar la recopilación de datos de los sensores y para recopilar datos de emergencia (también denominados datos de sesión de seguimiento o metadatos de emergencia) que enviar a los servidores de seguimiento. Además, se ejecuta el proceso de limpieza del subsistema del procesador de aplicaciones, donde aplicaciones en segundo plano y subsistemas no esenciales (por ejemplo, el procesador de aplicaciones, el procesador de vídeo, etc.) y actividades (por ejemplo, actividades de correo electrónico, redes sociales) se desactivan o tienen su funcionalidad limitada/reducida.
[0056] Como se describe en el presente documento, el dispositivo puede estar configurado (antes de enviar una solicitud al servidor de seguimiento de emergencias o de recibir una respuesta del mismo) para configurar el temporizador de activación y así determinar (en 635, también denotado como '6' en la FIG. 6) uno o más instantes de tiempo de activación posteriores en los que los datos recopilados desde la última transmisión de datos de emergencia se comunican a la sesión de seguimiento de emergencia. La determinación del uno o más instantes de tiempo de activación posteriores puede depender del nivel de batería del dispositivo, pero también puede basarse en factores tales como el tiempo transcurrido desde que se envió el mensaje de emergencia (es decir, en 610 de la FIG. 6), los tipos y el volumen/cantidad de datos que deben enviarse al servidor de seguimiento de emergencias (los parámetros de datos pueden determinarse y especificarse, en algunos modos de realización, por el servidor de seguimiento de emergencias), datos nuevos en las recopilaciones de datos, el valor de periodicidad máxima (proporcionado, por ejemplo, por el servidor de llamadas de emergencia o el servidor de seguimiento de emergencias), el ancho de banda de conectividad, etc. En algunos modos de realización, el dispositivo está configurado para pasar a un estado de emergencia tras configurar el temporizador de activación y esperar los datos de emergencia que se recopilarán (por ejemplo, en 640).
[0057] En algunos modos de realización, los subsistemas de sensor y comunicación (incluidos transceptores y otros módulos que reciben y miden señales de radio, sensores internos, tales como sensores inerciales, y sensores externos, tales como sensores biométricos y sensores basados en vehículo) pueden entrar en un estado de energía que les permite recopilar datos durante el intervalo que precede al siguiente período de activación (dicho estado puede denominarse estado de modo de seguimiento de energía reducida). De forma alternativa y/o adicional, en algunos modos de realización, la recopilación de datos puede realizarse cuando los subsistemas esenciales (por ejemplo, subsistemas de sensores, subsistemas de módem y comunicación) se activan. Tras determinar, en 645, que se ha alcanzado el tiempo de activación determinado, se recopilan datos de emergencia (datos de sesión de seguimiento) (o se han recopilado en el intervalo entre la última transmisión de datos de emergencia y la transmisión actual que está a punto de tener lugar), como se muestra en 650 de la FIG. 6 (también denotado como '7'), a partir de los subsistemas del dispositivo (por ejemplo, subsistema de sensores, subsistema de conectividad/comunicación, sensores externos (por ejemplo, sensores ponibles tales como sensores biométricos), etc.). Los datos de emergencia/sesión de seguimiento recopilados se empaquetan, o se organizan de otro modo, en mensajes (generados de acuerdo con diversos protocolos de mensajería/comunicación posibles, tales como SIP, LPP, HTTPS, UMTS, etc.). En algunos modos de realización, el dispositivo también puede calcular el siguiente tiempo de activación (el siguiente instante de tiempo posterior) en el que se realizará la siguiente transmisión de datos de emergencia, donde el cálculo del siguiente instante de activación se basa, por ejemplo, en el nivel de batería actual, el tiempo transcurrido desde que se realizó la llamada de emergencia, los datos particulares que deben transmitirse, el ancho de banda de conectividad y/u otros factores. Como se indicó, en algunos modos de realización, el dispositivo puede haber calculado varios tiempos de activación en un instante de tiempo particular y, por lo tanto, es posible que el dispositivo no necesite calcular en 650 el siguiente tiempo de activación.
[0058] El dispositivo puede estar configurado a continuación para realizar transmisiones 655 (también denotado como '8' en la FIG. 6) al servidor de seguimiento de emergencias (con el que puede haber establecido previamente una sesión de seguimiento, separada de la sesión de seguimiento de emergencia). El servidor de seguimiento de emergencias está configurado para procesar 660 (también denotada como '9' en la FIG. 6) los datos de emergencia recibidos desde el dispositivo. Por ejemplo, como se describe en el presente documento, la aproximación de ubicación actual del dispositivo puede determinarse en base a los datos de determinación de ubicación incluidos en los datos de emergencia (por ejemplo, datos de sensor inercial, medidas de señal y/o temporización para señales de radio detectadas por los diversos transceptores del dispositivo, etc.), los datos de constantes vitales pueden determinarse en base a las mediciones incluidas con los datos de emergencia, los datos irrelevantes y/o atípicos pueden filtrarse o eliminarse, etc. Los datos procesados y/o los datos sin procesar pueden organizarse en tramas o paquetes de datos y comunicarse a uno o más dispositivos asociados a uno o más proveedores de servicios de emergencia (por ejemplo, una patrulla de policía, un servicio de ambulancia, etc.) El servidor de seguimiento de emergencias también puede enviar datos a diversas bases de datos y sistemas expertos (por ejemplo, sistemas expertos que compilan estadísticas, tales como estadísticas de resolución de emergencias, sistemas expertos para realizar análisis de riesgo para seguros, etc.).
[0059] Se proporcionan detalles adicionales con respecto a las implementaciones descritas en el presente documento con respecto a las FIGS. 7-9, que muestran modos de realización de ejemplo adicionales. En particular, con referencia a la FIG. 7, se muestra un diagrama de flujo de un proceso 700 de ejemplo para notificar una emergencia médica y establecer una sesión de seguimiento para comunicar datos de emergencia. En los modos de realización de la FIG.
7, el proceso de ejemplo para gestionar una emergencia médica se basa en un flujo de llamadas e-911 que se realiza, al menos en parte, usando un protocolo de posicionamiento (LPP) de Evolución a Largo Plazo (LTE). Por tanto, por ejemplo, un servidor de ubicación 704, tal como un Centro de Ubicación Móvil de Servicio Evolucionado (E-SMLC)/E-SLP (SUPL), puede enviar a un dispositivo móvil de destino/UE 702 (por ejemplo, en respuesta a una comunicación anterior desde el dispositivo de destino 702 al servidor 704, u otro servidor, para asesorar acerca de una condición de emergencia) un mensaje Solicitar Capacidades LPP 710. En algunos modos de realización, el servidor puede haber iniciado una comunicación con el dispositivo de destino 702 como parte de un proceso general de inspeccionar/sondear dispositivos dentro de su alcance, por ejemplo, para comunicarse periódicamente (por ejemplo, por medio de mensajes de radiodifusión) con dispositivos de usuario (que pueden ser dispositivos personales, dispositivos inalámbricos fijados a vehículos, etc.) para determinar si uno o más de esos dispositivos requieren servicios de respuesta de emergencia (en dichos modos de realización, los dispositivos de destino pueden configurarse para rechazar las comunicaciones, por ejemplo, si no hay emergencia, o para responder con una respuesta que proporciona la información solicitada). En algunos modos de realización, el servidor puede haber enviado el mensaje 710 en respuesta a recibir una indicación de una condición de emergencia desde algún otro dispositivo (diferente del dispositivo 702) que notificó una condición de emergencia que involucra al dispositivo 702.
[0060] En respuesta al mensaje Solicitar Capacidades LPP 710, el dispositivo de destino 702, que puede ser similar en configuración y/o funcionalidad a los dispositivos 108 o 302 de las FIGS. 1 y 3, transmite al servidor 704 un mensaje Proporcionar Capacidades LPP 720, que incluye datos con respecto a las capacidades del dispositivo de destino. Como se indicó, en algunos modos de realización, si el mensaje 710 se envió por iniciativa del servidor, el dispositivo 702 puede rechazar la solicitud (por ejemplo, si no hay emergencia). Si el dispositivo envía el mensaje 720, posteriormente, el servidor 704 transmite al dispositivo 702 un mensaje Proporcionar Datos de Asistencia / Solicitar Capacidades LPP 730 no solicitado y un mensaje Solicitar Información de Ubicación LPP 740, en respuesta a lo cual el dispositivo de destino 702 envía un mensaje Proporcionar Información de Ubicación LPP 750, con datos indicativos de la ubicación del dispositivo (por ejemplo, la posición más conocida). Basándose en la información, que incluye información de capacidades de dispositivo (proporcionada con el mensaje 720) que ha recibido desde el dispositivo de destino, información proporcionada en la indicación inicial de la condición de emergencia (que puede haberse recibido con o antes del mensaje con las capacidades de dispositivo, donde ese mensaje de indicación se ha recibido desde el dispositivo 702 o desde un dispositivo diferente), etc., el servidor 704 puede determinar si se debe establecer una sesión de seguimiento entre el dispositivo de destino y un servidor de seguimiento de emergencias. La identidad del/de los servidor(es) de seguimiento de emergencias que recibirán datos periódicos de emergencias/sesiones de seguimiento puede basarse, por ejemplo, en información de ubicación proporcionada por el dispositivo de destino (por ejemplo, en el mensaje 750), el tipo de emergencia notificada por el dispositivo, las capacidades del dispositivo y/o el procesamiento adicional de determinación de ubicación realizado por el servidor 704. Si el servidor 704 determina que se debe establecer una sesión de seguimiento (por ejemplo, la información de capacidades de dispositivo indica que el dispositivo de destino tiene los recursos para admitir una sesión de seguimiento), el servidor 704 envía al dispositivo de destino 702 un mensaje Solicitar Seguimiento de Metadatos LPP 760, que incluye el URL del/de los servidor(es) de seguimiento de emergencias a los que se enviarán los datos de emergencia (de forma alternativa, en el mensaje 760 puede incluirse otra información que identifique las direcciones de red o las identidades de los servidores de seguimiento de emergencias (por ejemplo, direcciones IP)).
[0061] En el ejemplo de la FIG. 7, al recibir el mensaje Solicitar Seguimiento de Metadatos LPP 760, el dispositivo de destino 702 establece una sesión de seguimiento (separada de la sesión que usó para comunicarse con el servidor 704) con el servidor de seguimiento de emergencias identificado en el mensaje 760. Por ejemplo, el dispositivo de destino 702 envía un mensaje Invitar 770 al servidor de seguimiento de emergencias 706 (que puede ser un servidor PSAP), y el servidor 706 responde con, por ejemplo, un mensaje OK 780, que puede incluir, por ejemplo, un valor de periodicidad máxima (y puede incluir otros tipos de información/parámetros, tales como los tipos de datos de emergencia que el dispositivo de destino va a enviar al servidor 706). Las otras operaciones ilustradas en la FIG. 7 puede ser similar a las descritas en relación con la FIG. 3, donde el dispositivo de destino determina tiempos de activación (para obtener una periodicidad elástica para enviar datos de emergencia, donde dicha periodicidad depende de, al menos, el nivel de batería del dispositivo), entra en el modo de energía de emergencia (para conservar la energía), y envía periódicamente datos de emergencia (datos, o metadatos, de sesión de seguimiento), tales como el mensaje 790, recopilados antes de las transmisiones respectivas. Los datos de emergencia periódicos pueden enviarse al servidor de seguimiento de emergencias usando, en algunos modos de realización, mensajes SIP, o usando otros tipos de mensajes (por ejemplo, mensajes LPP, mensaje HTTPS, etc.). En algunos modos de realización, los datos de emergencia periódicos proporcionados por el dispositivo 702 pueden incluir, por ejemplo, información de ubicación, tal como la ubicación de dispositivo, información de ID de célula, información de punto de acceso (por ejemplo, dirección MAC, información RSSI/RTT), información de barómetro, etc. Los datos de emergencia transmitidos por el dispositivo de destino 702 también pueden incluir información de uso médico, que puede haberse comunicado al dispositivo 702 desde dispositivos o sensores ponibles (por ejemplo, por medio de enlaces de tecnología inalámbrica Bluetooth® u otros tipos de enlaces de campo cercano, o por medio de enlaces LAN), que incluye información de pulso/frecuencia cardíaca, temperatura corporal, tensión arterial, nivel de saturación de oxígeno, etc. En algunos modos de realización, el servidor de seguimiento de emergencias puede configurarse para actualizar la ubicación del usuario, transmitir constantes vitales a los equipos de emergencia y/o suministrar registros de llamadas de socorro a sistemas expertos y bases de datos (por ejemplo, para mantener estadísticas globales de emergencias, para realizar análisis de causa y riesgo, etc.).
[0062] Con referencia a la FIG. 8, se muestra un diagrama de flujo de un proceso 800 de ejemplo para notificar una emergencia policial y establecer una sesión de seguimiento para comunicar datos de emergencia. En el ejemplo de la FIG. 8, la notificación y el seguimiento de una emergencia de tipo policial se realiza mediante eCall de UMTS. Como se ilustra, un servidor de llamadas de emergencia, implementado usando un controlador de red de radio (RNC) 804, envía un mensaje Solicitar Información de Ubicación RRC 810 a un dispositivo de destino 802 (que puede ser similar en configuración y/o funcionalidad a cualquiera de los dispositivos 108, 302 y 702 descritos en el presente documento). En algunos modos de realización, el RNC 804 puede enviar de forma independiente, es decir, por iniciativa propia, el mensaje 810 al dispositivo 802 (por ejemplo, como parte de un proceso general para inspeccionar/sondear dispositivos dentro de su rango para obtener información de ubicación, información sobre si hay una emergencia, etc.). En dichos modos de realización, el dispositivo de destino que se está contactando puede estar configurado para determinar si acepta y responde al mensaje de solicitud, o para rechazar la comunicación (por ejemplo, si no hay emergencia).
Como se indicó, en algunos modos de realización, un mensaje enviado inicialmente por el RNC (o algún otro servidor de llamadas de emergencia) puede configurarse para hacer que el dispositivo receptor responda al mensaje de solicitud de alguna manera (por ejemplo, para entrar en una sesión de seguimiento con algún servidor de seguimiento de emergencias designado) sin que el dispositivo o su usuario puedan ejercer discreción. Dichos modos de realización pueden incluir situaciones en las que el usuario no puede aceptar o acusar el recibo de un mensaje de solicitud (por ejemplo, si el usuario está inconsciente o no puede responder), cuando el usuario del dispositivo receptor está involucrado en alguna actividad delictiva y, por lo tanto, no desea ser rastreado, etc. En algunos modos de realización, el mensaje 810 puede haberse enviado en respuesta a un mensaje de comunicación de emergencia de inicio (por ejemplo, que indica el tipo de emergencia, capacidades de dispositivo, información de ubicación, etc.) del dispositivo 802, o en respuesta a un mensaje de inicio de algún otro dispositivo o nodo que notifica la condición de emergencia.
[0063] En respuesta al mensaje 810, el dispositivo de destino 802 envía un mensaje de respuesta RRC 820, que puede incluir información de ubicación (por ejemplo, identidad de puntos de acceso en comunicación con el dispositivo de destino 802), datos recopilados por los diversos sensores del dispositivo, tales como mediciones de barómetro, etc.). A continuación, el RNC 804 puede determinar si se debe establecer una sesión de seguimiento (por ejemplo, en base a información recibida en el mensaje anterior, incluido el mensaje con la indicación de la condición de emergencia), y si es así, envía un mensaje Solicitar Seguimiento de Metadatos RRC 830 al dispositivo de destino 802, que puede incluir datos que proporcionar, por ejemplo, la periodicidad máxima, el tipo de datos de emergencia que se enviarán durante la sesión de seguimiento, el URL del servidor de seguimiento de emergencias (o algún otro tipo de direccionamiento o información de identificación para el mismo), etc.
[0064] Al recibir el mensaje Solicitar Seguimiento de Metadatos RRC 830, el dispositivo de destino 802 establece una sesión de seguimiento con el servidor de seguimiento de emergencias identificado en el mensaje 830. Por ejemplo, el dispositivo de destino 802 envía un mensaje GET 840, que en el ejemplo de la FIG. 8 incluye algunos datos de emergencia y datos de capacidades de dispositivo. En respuesta al mensaje 840, el servidor de seguimiento de emergencias 806 envía un mensaje OK 850 (que puede incluir información tal como la periodicidad para comunicar datos de emergencia, y puede incluir otros tipos de información/parámetros, tales como los tipos de datos de emergencia que el dispositivo de destino va a enviar al servidor 806). Las otras operaciones ilustradas en la FIG. 8 puede ser similar a las descritas en relación con las FIGS. 3 y 7, donde el dispositivo de destino determina tiempos de activación (para obtener una periodicidad elástica para enviar datos de emergencia, donde dicha periodicidad depende de, al menos, el nivel de batería del dispositivo), entra en el estado de modo de seguimiento de energía reducida (para conservar la energía), y envía periódicamente datos de emergencia (datos, o metadatos, de sesión de seguimiento), tales como el mensaje POST 860, recopilados antes de las transmisiones respectivas. Los datos de emergencia periódicos pueden enviarse al servidor de seguimiento de emergencias usando, en algunos modos de realización, mensajes HTTPS, o usando otros tipos de mensajes (por ejemplo, mensajes SIP, mensajes LPP, etc.). En algunos modos de realización, los datos de emergencia periódicos proporcionados por el dispositivo 802 pueden incluir, por ejemplo, información de ubicación, tal como la ubicación de dispositivo, información de ID de célula, información de punto de acceso (por ejemplo, dirección MAC, información RSSI/RTT), información de barómetro, etc. Los datos de emergencia transmitidos por el dispositivo de destino 802 también pueden incluir información de uso policial, tal como información de tipo de navegación (proporcionada a través de mediciones realizadas por los diversos sensores inerciales del dispositivo de destino), información de huellas digitales (por ejemplo, obtenida por medio de una pantalla táctil del dispositivo o lectores de huellas digitales), muestras de fotos (obtenidas por medio de la cámara del dispositivo), etc. En algunos modos de realización, el servidor de seguimiento de emergencia 806 puede estar configurado para actualizar la ubicación del usuario, estimar la navegación del usuario (por ejemplo, información de rumbo, posición del cuerpo), identificar la persona que utiliza el dispositivo o identificar a un tercero que sea el sujeto de las fotos tomadas (por ejemplo, un sospechoso), transmitir constantes vitales a los equipos de emergencia y/o suministrar registros de llamadas de socorro a sistemas expertos y bases de datos (por ejemplo, para mantener estadísticas globales de emergencias).
[0065] Con referencia a la FIG. 9, se muestra un diagrama de flujo de un proceso 900 de ejemplo para notificar una emergencia privada en carretera y establecer una sesión de seguimiento para comunicar datos de emergencia. El proceso 900 comienza cuando el dispositivo de destino 902 (por ejemplo, un dispositivo móvil de un conductor, o un dispositivo inalámbrico dedicado para vehículo), envía una indicación de una condición de emergencia, tal como un mensaje Solicitud de Emergencia en Carretera 910. Como se analiza en el presente documento, la indicación de la condición de emergencia puede haberse transmitido desde un dispositivo diferente al dispositivo 902 (por ejemplo, un dispositivo que simplemente notifica la condición de emergencia en el dispositivo 902). De forma alternativa, el mensaje 910 puede haberse enviado (por el dispositivo 902 o algún otro dispositivo) en respuesta a un mensaje de inicio del servidor 904. El mensaje 910 puede incluir datos de ubicación tales como, por ejemplo, una ubicación determinada en base a un sistema de tipo GPS, o una ubicación determinada en base a puntos de acceso terrestres. En algunos modos de realización, el mensaje 910 puede incluir otros tipos de información basada en la ubicación, tal como una posición aproximada (por ejemplo, expresada como la identidad de un punto de acceso o estación base con la cual el dispositivo 902 se está comunicando, o como un conjunto de mediciones de señales recibidas desde puntos de acceso locales). El mensaje 910 también puede incluir otros tipos de información, tal como el tipo de emergencia (por ejemplo, un problema en la carretera, opcionalmente la identificación de problemas específicos, tales como problemas del motor, neumáticos pinchados u otra cosa), y datos de capacidades de dispositivo. El mensaje 910 se puede configurar de acuerdo con uno de diversos protocolos de mensajería posibles, incluidos SIP, LPP, UMTS, HTTPS, etc. El mensaje 910 se refiere a un servidor de llamadas de emergencia 904, que puede ser similar, en configuración y/o funcionalidad, a cualquiera de los servidores 120, 304, 704 u 804 analizados en relación con las FIGS. 1, 3, 7 y 8. Los datos incluidos en el mensaje 910 pueden dividirse y transmitirse en múltiples mensajes diferentes. El servidor 904 puede entonces determinar si se debe establecer una sesión de seguimiento para el dispositivo de destino 902, por ejemplo, basándose en las capacidades del dispositivo de destino, en la ubicación del dispositivo (que puede indicar si hay un servidor de seguimiento de emergencias dentro del alcance del dispositivo de destino), etc. Si se determina que se debe establecer una sesión de seguimiento, un mensaje desencadenante, tal como un mensaje Solicitar Seguimiento de Metadatos de Emergencia 920, se envía desde el servidor 904 al dispositivo de destino 902 para iniciar una sesión de seguimiento que está separada (por ejemplo, es diferente y/o independiente) de la sesión a través de la cual el dispositivo de destino 902 y el servidor 904 se han estado comunicando. El mensaje 920 puede incluir, por ejemplo, una indicación de la periodicidad máxima, los tipos de datos de emergencia a rastrear y el URL para el servidor de seguimiento de emergencias (o alguna otra información de direccionamiento de red o información de identificación de servidor). El servidor de seguimiento de emergencias particular usado puede seleccionarse en función de los datos de ubicación, datos de capacidades de dispositivo, etc., incluidos con el mensaje de Solicitud de Emergencia en Carretera 910 enviado al servidor 904.
[0066] En el ejemplo de la FIG. 9, el establecimiento de la sesión se puede lograr simplemente enviando la primera transmisión de datos de emergencia, en este caso a través de un mensaje Proporcionar Seguimiento de Metadatos 930, al servidor de seguimiento de emergencias de destino 906. Sin embargo, en algunos modos de realización, se puede implementar un intercambio de mensajes para solicitar, y posteriormente concederse, el establecimiento de una sesión de seguimiento. Operaciones adicionales realizadas por el dispositivo de destino 902 pueden ser similares a las descritas en relación con las FIGS. 3, 7 y 8, donde el dispositivo de destino puede determinar uno o más tiempos de activación (para obtener una periodicidad elástica para enviar datos de emergencia, donde dicha periodicidad depende de al menos el nivel de batería del dispositivo), entra en el modo de energía de emergencia (por ejemplo, estado de modo de seguimiento de energía reducida para conservar la energía) y envía periódicamente datos de emergencia (datos, o metadatos, de sesión de seguimiento), tales como los mensajes 930 o 940. Los datos de emergencia periódicos pueden enviarse al servidor de seguimiento de emergencias 906 usando una o más de diversas configuraciones y protocolos de mensajes, incluyendo SIP, LPP, HTTPS, UMTS, o usando otros protocolos/tipos de mensajes. En algunos modos de realización, los datos de emergencia periódicos proporcionados por el dispositivo 902 pueden incluir, por ejemplo, información de ubicación, tal como ubicación de dispositivo, información de ID de célula, información de punto de acceso (por ejemplo, dirección MAC, información RSSI/RTT), información de barómetro, etc. Los datos de emergencia transmitidos por el dispositivo de destino 902 también pueden incluir información de uso en carretera (asistencia para vehículos), tal como información del tipo de navegación (proporcionada a través de mediciones realizadas por los diversos sensores inerciales del dispositivo de destino), información de sensores de vehículo (nivel de batería del vehículo, temperatura del motor, niveles de gas y aceite, presión de los neumáticos, etc.) y otra información pertinente. En algunos modos de realización, el servidor de seguimiento de emergencias 906 puede configurarse para actualizar la ubicación del usuario, estimar la navegación del usuario (por ejemplo, información de rumbo, posición del cuerpo), transmitir información de vehículo relevante al equipo de emergencia enviado para atender la emergencia en carretera y/o suministrar datos de llamadas de socorro (datos sin procesar o procesados) a sistemas expertos y bases de datos (por ejemplo, para mantener estadísticas globales de emergencias).
[0067] Con referencia ahora a la FIG. 10, se muestra un diagrama esquemático que ilustra diversos componentes de un dispositivo inalámbrico 1000 de ejemplo (por ejemplo, un dispositivo móvil), que puede ser similar, en configuración y/o funcionalidad, a los dispositivos 108, 302, 702, 802 y 902 representados en las FIGS. 1, 3 y 7-9. En aras de la simplicidad, las diversas características/componentes/funciones ilustrados en los cuadros esquemáticos de la FIG. 10 están conectadas entre sí usando un bus común para representar que estas diversas características/componentes/funciones están acoplados operativamente entre sí. Otras conexiones, mecanismos, características, funciones o similares se pueden proporcionar y adaptar como sea necesario para a
de forma operativa un dispositivo inalámbrico. Además, una o más de las características o funciones ilustradas en el ejemplo de la FIG. 10 se pueden subdividir adicionalmente, o dos o más de las características o funciones ilustradas en la FIG. 10 se pueden combinar. Además, pueden excluirse una o más de las características o funciones ilustradas en la FIG. 10. En algunos modos de realización, algunos o todos los componentes representados en la FIG. 10 también se pueden usar en implementaciones de uno o más de los nodos/dispositivos 106a-e y/o 104a-c y/o los servidores 120 y 122 ilustrados en la FIG. 1, así como los servidores 304, 306, 704, 706, 804, 806, 904 y 906 mostrados en las FIGS. 3 y 7-9. En dichos modos de realización, los componentes representados en la FIG. 10 pueden configurarse para llevar a cabo las operaciones realizadas por dispositivos (dispositivos inalámbricos, servidores, tales como servidores de seguimiento y de llamadas de emergencia, etc.) como se describe en el presente documento con respecto a, por ejemplo, las FIGS. 2-9 (por ejemplo, para enviar mensajes de emergencia, determinar si se establece una sesión de seguimiento y/o comunicar periódicamente datos de emergencia/sesión de seguimiento si se establece dicha sesión de seguimiento).
[0068] Como se muestra, el dispositivo inalámbrico 1000 puede incluir uno o más transceptores de campo cercano/red de área local 1006 que se pueden conectar a una o más antenas 1002. El uno o más transceptores de campo cercano/red de área local 1006 comprenden dispositivos, circuitos, hardware y/o software adecuados para comunicarse con y/o detectar señales hacia/desde uno o más de los puntos de acceso WLAN 106a-e representados en la FIG. 1, y/o directamente con otros dispositivos inalámbricos (por ejemplo, dispositivos móviles) dentro de una red. Los transceptores 1006 también pueden configurarse para comunicarse con dispositivos cercanos (por ejemplo, sensores biométricos ponibles, sensores de vehículos) por medio de tecnologías de comunicación de campo cercano tal como la tecnología inalámbrica Bluetooth®, o por medio de enlaces de comunicación LAN. En algunos modos de realización, el/los transceptor(es) de campo cercano/red de área local 1006 puede(n) comprender un transceptor de comunicación WiFi (802.11x) adecuado para comunicarse con uno o más puntos de acceso inalámbrico; sin embargo, en algunos modos de realización, el/los transceptor(es) de campo cercano/ red de área local 1006 puede(n) configurarse para comunicarse con otros tipos de redes de área local, redes de área personal, etc. Además, se puede usar cualquier otro tipo de tecnologías inalámbricas de interconexión, por ejemplo, Banda Ultraancha, ZigBee, USB inalámbrico, etc.
[0069] El dispositivo inalámbrico 1000 también puede incluir, en algunas implementaciones, uno o más transceptores de red de área amplia 1004 que pueden conectarse a la una o más antenas 1002 (o pueden conectarse a antenas dedicadas para transceptores de tipo WAN). El transceptor de red de área amplia 1004 puede comprender dispositivos, circuitos, hardware y/o software adecuados para comunicarse con y/o detectar señales procedentes de uno o más de, por ejemplo, los puntos de acceso WWAN 104a-c ilustrados en la FIG. 1, y/o directamente con otros dispositivos inalámbricos dentro de una red (incluso con servidores tales como los servidores 120, 122, 304, 306, 704, 706, 804, 806, 904 y 906 descritos en el presente documento). En algunas implementaciones, el/los transceptor(es) de red de área amplia 1004 puede(n) comprender un sistema de comunicación CDMA adecuado para comunicarse con una red CDMA de estaciones base inalámbricas. En algunas implementaciones, el sistema de comunicación inalámbrica puede comprender otros tipos de redes de telefonía celular, tales como, por ejemplo, TDMA, GSM, WCDMA, LTE, etc. Además, se puede usar cualquier otro tipo de tecnologías inalámbricas de interconexión, que incluyen, por ejemplo, WiMax (802.16), etc.
[0070] En algunos modos de realización, un receptor SPS (también denominado receptor de sistema global de navegación por satélite (GNSS)) 1008 también puede incluirse con el dispositivo inalámbrico 1000. El receptor SPS 1008 puede conectarse a las una o más antenas 1002 (o puede conectarse a su(s) propia(s) antena(s) dedicada(s)) para recibir señales de satélite. El receptor SPS 1008 puede comprender cualquier hardware y/o software adecuado para recibir y procesar señales SPS. El receptor SPS 1008 puede solicitar información según sea apropiado de los otros sistemas, y puede realizar los cálculos necesarios para determinar la posición del dispositivo 1000 usando, en parte, mediciones obtenidas mediante cualquier procedimiento SPS adecuado. Además, los valores de medición para las señales de satélite recibidas pueden comunicarse a un servidor de ubicación configurado para facilitar la determinación de ubicación.
[0071] Como se ilustra adicionalmente en la FIG. 10, el dispositivo inalámbrico 1000 de ejemplo incluye uno o más sensores 1012 acoplados a un procesador/controlador 1010. Por ejemplo, los sensores 1012 pueden incluir sensores de movimiento (también denominados sensores inerciales, de orientación o navegación) para proporcionar información relativa de movimiento y/u orientación (que es independiente de los datos de movimiento obtenidos de las señales recibidas por el/los transceptor(es) de red de área amplia 1004, el/los transceptor(es) de red de área local 1006 y/o el receptor SPS 1008). A modo de ejemplo, pero no limitativo, los sensores de movimiento pueden incluir un acelerómetro 1012a, un giroscopio 1012b y un sensor geomagnético (magnetómetro) 1012c (por ejemplo, una brújula), cualquiera de los cuales puede implementarse mediante un sistema microelectromecánico (MEMS) o mediante alguna otra tecnología. El uno o más sensores 1012 pueden incluir además un altímetro (por ejemplo, un altímetro de presión barométrica) 1012d, un termómetro (por ejemplo, un termistor) 1012e, un sensor de audio 1012f (por ejemplo, un micrófono) y/u otros sensores (tales como un sensor de humedad, un sensor de proximidad, no mostrados). La salida del uno o más sensores 1012 puede proporcionarse como datos transmitidos a un dispositivo o servidor remoto (por medio de los transceptores 1004 y/o 1006, o por medio de algún puerto de red o interfaz del dispositivo 1000) para su almacenamiento o procesamiento adicional. Como se muestra adicionalmente en la FIG. 10, en algunos modos de realización, el uno o más sensores 1012 también pueden incluir una cámara 1012g (por ejemplo, una cámara de tipo dispositivo de carga acoplada (CCD), un sensor de imágenes basado en CMOS, etc.), que puede producir imágenes fijas o en movimiento (por ejemplo, una secuencia de vídeo) que se pueden mostrar en un dispositivo de interfaz de usuario, tal como un dispositivo de visualización o una pantalla, y que se pueden usar además para determinar un nivel ambiental de iluminación y/o información relacionada con los colores, la existencia y los niveles de iluminación UV y/o infrarroja. En algunos modos de realización, el uno o más sensores 1012 pueden incluir además un sensor de luz ambiental (ALS) separado 1012h configurado, por ejemplo, para percibir o detectar cambios en la luz. De forma alternativa y/o adicional, el uno o más sensores pueden incluir un sensor de proximidad (que puede ser igual o diferente al ALS 1012h) implementado, por ejemplo, usando un sensor de fotones, una célula solar, etc.
[0072] El/los procesador(es) (también denominado(s) controlador(es)) 1010 puede(n) estar conectado(s) a un/varios transceptor(es) de red de área local 1006, al/a los transceptor(es) de red de área amplia 1004, al receptor SPS 1008 y al uno o más sensores 1012. El procesador puede incluir uno o más microprocesadores, microcontroladores y/o procesadores de señales digitales que proporcionan funciones de procesamiento, así como otra funcionalidad de cálculo y control. El procesador 1010 puede estar acoplado a un medio de almacenamiento (por ejemplo, memoria) 1014 para almacenar datos e instrucciones de software para ejecutar la funcionalidad programada dentro del vehículo 1000. La memoria 1014 puede estar integrada en el procesador 1010 (por ejemplo, dentro de la misma cápsula IC), y/o la memoria puede ser memoria externa al procesador y estar funcionalmente acoplada a través de un bus de datos.
A continuación, en relación con la FIG. 12, se proporcionan detalles adicionales con respecto a un modo de realización de ejemplo de un procesador o sistema de cálculo, que puede ser similar al procesador 1010.
[0073] Varios módulos de software y tablas de datos pueden residir en la memoria 1014 y pueden ser utilizados por el procesador 1010 para gestionar las comunicaciones con dispositivos/nodos remotos (tales como los diversos nodos y/o servidores 120 o 122 representados en la FIG. 1 o cualquiera de los servidores de seguimiento y de llamadas de emergencia representados en las FIGS. 3 y 7-9), incluso para comunicarse con los servidores de seguimiento y de llamadas de emergencia de la manera descrita en el presente documento, realizar la funcionalidad de determinación de posicionamiento y/o realizar la funcionalidad de control de dispositivo. Como se ilustra en la FIG. 10, en algunos modos de realización, la memoria 1014 puede incluir un módulo de posicionamiento 1016, un módulo de emergencias 1018, un módulo de indicador de intensidad de señal recibida (RSSI) 1020 y/o un módulo de tiempo de ida y vuelta (RTT) 1022. Cabe señalar que la funcionalidad de los módulos y/o las estructuras de datos se pueden combinar, separar y/o estructurar de diferentes maneras dependiendo de la implementación del dispositivo móvil 1000. Por ejemplo, el módulo RSSI 1020 y/o el módulo RTT 1022 pueden realizarse cada uno, al menos parcialmente, como una implementación basada en hardware y, por lo tanto, pueden incluir dispositivos o circuitos tales como una antena dedicada (por ejemplo, una antena RTT y/o una antena RSSI dedicadas), una unidad de procesamiento dedicada para procesar y analizar las señales recibidas y/o transmitidas por medio de la(s) antena(s) (por ejemplo, para determinar la intensidad de señal de las señales recibidas, determinar información de temporización en relación con un ciclo RTT, etc.).
[0074] El módulo de emergencias 1018 puede incluir una aplicación para implementar procesos para comunicar una indicación de condición de emergencia, establecer una sesión de seguimiento (separada de una sesión de llamada de emergencia establecida con un servidor para comunicar una indicación de una condición de emergencia) y, cuando se establece una sesión de seguimiento (en respuesta a la recepción de un mensaje desencadenante), comunicar periódicamente datos de emergencia a uno o más servidores de seguimiento de emergencias. El módulo de emergencias 1018 puede configurarse además para controlar el suministro de energía a los módulos/subsistemas del dispositivo 1000, incluso para funcionar en un estado de modo de seguimiento de energía reducida cuando se determina que se debe establecer una sesión de seguimiento. En el estado de modo de seguimiento de energía reducida, se reduce la alimentación de los módulos/subsistemas no esenciales (es decir, no esenciales para la recopilación y comunicación de datos de sesión de seguimiento), mientras que el funcionamiento de módulos/subsistemas de sensor y comunicación para recopilar y comunicar los datos de sesión de seguimiento se mantiene, al menos parcialmente. El módulo de emergencias 1018 también puede configurarse para recibir y procesar mensajes de servidores de emergencia y/o procesar mensajes de emergencia y/o mensajes de datos de emergencia. El módulo de emergencias 1018 también puede incluir una aplicación para implementar un proceso que solicita información de posición del módulo de posicionamiento 1016, o que recibe datos de posicionamiento/ubicación desde un dispositivo remoto (por ejemplo, un servidor de ubicación remota).
[0075] La memoria 1014 también puede incluir un módulo de aplicaciones 1019. Las aplicaciones se ejecutan típicamente en una capa superior de las arquitecturas de software y pueden incluir aplicaciones de navegación en espacios cerrados, aplicaciones de compra, aplicaciones de servicio basado en la ubicación, etc. El módulo/circuito de posicionamiento 1016 puede obtener la posición del dispositivo inalámbrico 1000 usando información obtenido de diversos receptores y módulos del dispositivo móvil 1000, por ejemplo, en base a mediciones realizadas por el módulo RSSI y/o el módulo RTT. Los datos obtenidos por el módulo de posicionamiento 1016 se pueden usar para complementar la información de ubicación proporcionada, por ejemplo, por un dispositivo remoto (tal como un servidor de ubicación) o se pueden usar en lugar de los datos de ubicación enviados por un dispositivo remoto. Por ejemplo, el módulo de posicionamiento 1016 puede determinar la posición del dispositivo 1000 basándose en las mediciones realizadas por diversos sensores, circuitos y/o módulos del dispositivo 1000, y usar esas mediciones junto con datos de asistencia recibidos desde un servidor remoto para determinar la ubicación del dispositivo 1000.
[0076] Como se ilustra adicionalmente, el dispositivo inalámbrico 1000 también puede incluir un almacenamiento de datos de asistencia 1024 en el que se almacenan datos de asistencia, tales como información de mapas, registros de datos relacionados con información de ubicación en un área donde se encuentra actualmente el dispositivo, mapas térmicos (por ejemplo, indicativos de valores de intensidad de señal esperados, para señales transmitidas desde uno o más dispositivos inalámbricos, en varias ubicaciones). En algunos modos de realización, el dispositivo inalámbrico 1000 también puede configurarse para recibir información complementaria que incluye datos auxiliares de posición y/o movimiento que pueden determinarse a partir de otras fuentes (por ejemplo, desde el uno o más sensores 1012). Dichos datos de posición auxiliares pueden ser incompletos o ruidosos, pero pueden ser útiles como otra fuente de información independiente para estimar la posición del dispositivo 1000, o para realizar otras operaciones o funciones. La información complementaria también puede incluir, pero sin limitarse a, información que puede obtenerse o basarse en señales de tecnología inalámbrica Bluetooth®, balizas, etiquetas RFID y/o información obtenida de un mapa (por ejemplo, recibir coordenadas de una representación digital de un mapa geográfico mediante, por ejemplo, un usuario que interactúa con un mapa digital). La información complementaria puede almacenarse opcionalmente en el módulo de almacenamiento 1026 representado esquemáticamente en la FIG. 10. El dispositivo inalámbrico 1000 puede incluir adicionalmente el almacenamiento de datos de seguimiento 1028 para almacenar, temporalmente o a largo plazo, datos de sesión de seguimiento (metadatos de emergencia) recopilados por el dispositivo inalámbrico durante, por ejemplo, una sesión de seguimiento (establecida, por ejemplo, en respuesta a un mensaje de solicitud recibido desde un servidor de llamadas de emergencia). Los datos de sesión de seguimiento pueden incluir datos recopilados por los subsistemas de sensor y comunicación mientras el dispositivo inalámbrico funciona en modo de energía reducida, y al menos algunos de los datos pueden transmitirse periódicamente a un dispositivo remoto (por ejemplo, un servidor de seguimiento de emergencias remoto) en instantes de tiempo determinados. En algunos modos de realización, los datos de sesión de seguimiento que se han transmitido a un dispositivo remoto pueden eliminarse del almacenamiento para permitir que se almacenen nuevos datos (por ejemplo, recopilados después de la transmisión de al menos algunos de los datos de sesión de seguimiento). En algunos modos de realización, los datos almacenados en el almacenamiento 1028 pueden procesarse (antes o después de almacenarse en el almacenamiento 1028) para, por ejemplo, añadir indicaciones de tiempo a los datos almacenados, comprimir los datos almacenados, calcular datos diferenciales resultantes (representativos de cambios en los datos rastreados desde un instante de tiempo a otro), cifrar datos almacenados, etc.
[0077] El dispositivo inalámbrico 1000 puede incluir además una interfaz de usuario 1050 que proporcione sistemas de interfaz adecuados, tales como un micrófono/altavoz 1052, un teclado numérico 1054 y un dispositivo de visualización 1056 que permita la interacción del usuario con el vehículo 1000. El micrófono/altavoz 1052 (que puede ser igual o diferente del sensor de audio 1012f) proporciona servicios de comunicación de voz (por ejemplo, usando el/los transceptor(es) de red de área amplia 1004 y/o el/los transceptor(es) de campo cercano/red de área local 1006). El teclado numérico 1054 puede comprender botones adecuados para la entrada de usuario. El dispositivo de visualización 1056 puede incluir un dispositivo de visualización adecuado, tal como, por ejemplo, una pantalla LCD retroiluminada, y puede incluir además una pantalla táctil para modos adicionales de entrada de usuario.
[0078] Con referencia ahora a la FIG. 11, se muestra un diagrama esquemático de un nodo 1100 de ejemplo, tal como un punto de acceso o un servidor, que puede ser similar a y estar configurado para tener una funcionalidad similar a la de cualquiera de los diversos nodos representados en las FIGS. 1, 3 y 7-9 (por ejemplo, los nodos 104a-c, 106a-e y/o los servidores 120, 122, 304, 306, 704, 706, 804, 806, 904 y 906). El nodo 1100 puede incluir uno o más transceptores 1110a-n acoplados eléctricamente a una o más antenas 1116a-n para comunicarse con dispositivos inalámbricos, tales como, por ejemplo, los dispositivos 108, 302, 702, 802, 902 o 1000 de las FIGS. 1, 3 y 7-10, respectivamente. Cada uno de los transceptores 1110a-1110n puede incluir un transmisor respectivo 1112a-n para enviar señales (por ejemplo, mensajes de enlace descendente) y un receptor respectivo 1114a-n para recibir señales (por ejemplo, mensajes de enlace ascendente). El nodo 1100 también puede incluir una interfaz de red 1120 para comunicarse con otros nodos de red (por ejemplo, enviar y recibir consultas y respuestas). Por ejemplo, cada elemento de red puede configurarse para comunicarse (por ejemplo, comunicación por cable o inalámbrica) con una pasarela u otro dispositivo adecuado de una red, para facilitar la comunicación con uno o más nodos de red (por ejemplo, cualquiera de los otros puntos de acceso o servidores mostrados en las FIGS. 1,3 y 7-9 y/u otros dispositivos o nodos de red). De forma adicional y/o alternativa, la comunicación con otros nodos de red también se puede realizar usando los transceptores 1110a-n y las antenas respectivas 1116a-n.
[0079] El nodo 1100 también puede incluir otros componentes que se pueden usar con los modos de realización descritos en el presente documento. Por ejemplo, el nodo 1100 puede incluir, en algunos modos de realización, un controlador 1130 (que puede ser similar al procesador 1010 de la FIG. 10) para gestionar comunicaciones con otros nodos (por ejemplo, enviar y recibir mensajes) y proporcionar otra funcionalidad relacionada. Por ejemplo, el controlador 1130 puede configurarse para controlar el funcionamiento de las antenas 1116a-n para controlar de forma ajustable la potencia y fase de transmisión de las antenas, el patrón de ganancia, la dirección de antena (por ejemplo, la dirección en la que se propaga un haz de radiación resultante de las antenas 1116a-n), la diversidad de antena y otros parámetros de antena ajustables para las antenas 1116a-n del nodo 1100. En algunos modos de realización, la configuración de las antenas puede controlarse de acuerdo con datos de configuración previamente almacenados proporcionados en el momento de la fabricación o implantación del nodo 1100, o de acuerdo con los datos obtenidos de un dispositivo remoto (tal como un servidor central que envía datos representativos de la configuración de antena y otros parámetros operativos que se utilizarán para el nodo 1100).
[0080] En algunos modos de realización, el nodo 1100 también puede configurarse (por ejemplo, mediante operaciones realizadas en el controlador 1130) para recibir una indicación de una condición de emergencia en un dispositivo, determinar si el dispositivo en cuestión debe ser rastreado y transmitir un mensaje desencadenante al dispositivo para iniciar una sesión de seguimiento si se determina que el dispositivo debe ser rastreado. En algunas implementaciones, el nodo 1100 puede configurarse para recibir desde un dispositivo (por ejemplo, un dispositivo móvil personal) una solicitud para establecer una sesión de seguimiento, enviar una respuesta al dispositivo para establecer la sesión de seguimiento y recibir periódicamente desde el dispositivo datos de sesión de seguimiento recopilados durante la sesión de seguimiento por el dispositivo.
[0081] Además, el nodo 1100 puede incluir, en algunos modos de realización, controladores de relaciones de vecindad (por ejemplo, módulos de descubrimiento de vecinos) 1140 para gestionar relaciones de vecindad (por ejemplo, mantener una lista de vecinos 1142) y proporcionar otra funcionalidad relacionada. El controlador 1130 puede implementarse, en algunos modos de realización, como un dispositivo basado en procesador, con una configuración y funcionalidad similares a la mostrada y descrita en relación con la FIG. 12. En algunos modos de realización, el nodo también puede incluir uno o más sensores (no mostrados), tal como cualquiera de los uno o más sensores 1012 del dispositivo inalámbrico 1000 representado en la FIG. 10.
[0082] La realización de los procedimientos descritos en el presente documento también puede facilitarse mediante un sistema informático basado en procesador. Con referencia a la FIG. 12, se muestra un diagrama esquemático de un sistema informático 1200 de ejemplo. El sistema informático 1200 puede alojarse, por ejemplo, en un dispositivo tal como los dispositivos 108, 302, 702, 802, 902 y 1000 de las FIGS. 1, 3 y 7-10, y/o puede comprender al menos parte de, o la totalidad de, dispositivos inalámbricos, servidores, nodos, puntos de acceso o estaciones base, tales como los nodos 104a-b, 106a-c, 120, 122, 304, 306, 704, 706, 804, 806, 904, 906 y 1100 representados en las FIGS.
1,3, 7-9 y 11. El sistema informático 1200 incluye un dispositivo informático 1210, tal como un ordenador personal, un dispositivo informático especializado, un controlador, etc., que incluye típicamente una unidad de procesador central (CPU) 1212. Además de la CPU 1212, el sistema incluye memoria principal, memoria caché y circuitos de interfaz de bus (no mostrados). El dispositivo informático 1210 puede incluir un dispositivo de almacenamiento masivo 1214, tal como un disco duro y/o una unidad flash asociada al sistema informático. El sistema informático 1200 puede incluir además un teclado, o un teclado numérico, 1216 y un monitor 1220, por ejemplo, un monitor CRT (tubo de rayos catódicos), LCD (pantalla de cristal líquido), etc., que se pueden colocar donde un usuario pueda acceder a los mismos (por ejemplo, la pantalla de un dispositivo móvil).
[0083] El dispositivo informático 1210 está configurado para facilitar, por ejemplo, la implementación de uno o más de los procedimientos descritos en el presente documento, incluidos procedimientos para: a) recibir un mensaje desencadenante para iniciar una sesión de seguimiento, establecer una sesión de seguimiento (separada de una sesión de llamada de emergencia), y enviar a uno o más servidores los datos de sesión de seguimiento recopilados durante la sesión de seguimiento, b) recibir una indicación de una condición de emergencia en un dispositivo, determinar si el dispositivo en cuestión debe ser rastreado y transmitir un mensaje desencadenante al dispositivo para iniciar una sesión de seguimiento si se determina que el dispositivo debe ser rastreado, y c) recibir desde un dispositivo (por ejemplo, un dispositivo móvil) una solicitud para establecer una sesión de seguimiento, enviar una respuesta al dispositivo para establecer la sesión de seguimiento, y recibir periódicamente desde el dispositivo datos de sesión de seguimiento recopilados durante la sesión de seguimiento por el dispositivo. El dispositivo de almacenamiento masivo 1214 puede incluir, por tanto, un producto de programa informático que, cuando se ejecuta en el dispositivo informático 1210, hace que el dispositivo informático realice operaciones para facilitar la implementación de los procedimientos descritos en el presente documento, así como de procedimientos para controlar la funcionalidad general del dispositivo informático 1210, y procedimientos para implementar otras aplicaciones y operaciones.
[0084] El dispositivo informático puede incluir además dispositivos periféricos para posibilitar la funcionalidad de entrada/salida. Dichos dispositivos periféricos pueden incluir, por ejemplo, una unidad de CD-ROM y/o unidad flash, o una conexión de red, para descargar contenido relacionado al sistema conectado. Dichos dispositivos periféricos también se pueden usar para descargar software que contiene instrucciones informáticas para posibilitar el funcionamiento general del sistema/dispositivo respectivo. Por ejemplo, como se ilustra en la FIG. 12, el dispositivo informático 1210 puede incluir una interfaz 1218 con uno o más circuitos de interfaz (por ejemplo, un puerto inalámbrico que incluye circuitos de transceptor, un puerto de red con circuitos para interactuar con uno o más dispositivos de red, etc.) para proporcionar/implementar la comunicación con dispositivos remotos (por ejemplo, de modo que un dispositivo inalámbrico, tal como cualquiera de los dispositivos o nodos inalámbricos representados en cualquiera de las figuras, pueda comunicarse, a través de un puerto, tal como el puerto 1219, con otro dispositivo o nodo). De forma alternativa y/o adicional, en algunos modos de realización, se puede usar un circuito lógico de propósito especial, por ejemplo, una FPGA (matriz de puertas programables in situ), un procesador DSP, un ASIC (circuito integrado específico de la aplicación) u otros tipos de disposiciones de hardware y basadas en circuito en la implementación del sistema informático 1200. Otros módulos que se pueden incluir con el dispositivo informático 1210 son altavoces, una tarjeta de sonido, un dispositivo de puntero, por ejemplo, un ratón o una bola de seguimiento, mediante los cuales el usuario puede proporcionar datos de entrada al sistema informático 1200. El dispositivo informático 1210 puede incluir un sistema operativo (por ejemplo, un sistema operativo para hacer funcionar un dispositivo móvil).
[0085] Los programas informáticos (también conocidos como programas, software, aplicaciones de software o código) incluyen instrucciones máquina para un procesador programable y se pueden implementar en un lenguaje de programación procedural y/u orientado a objetos de alto nivel y/o en lenguaje ensamblador/máquina. Como se usa en el presente documento, el término "medio legible por máquina" se refiere a cualquier producto de programa informático no transitorio, aparato y/o dispositivo (por ejemplo, discos magnéticos, discos ópticos, memoria, dispositivos de lógica programable (PLD)) usados para proporcionar instrucciones máquina y/o datos a un procesador programable, incluyendo un medio legible por máquina no transitorio que recibe instrucciones máquina como una señal legible por máquina.
[0086] La memoria puede implementarse dentro del dispositivo informático 1210 o de manera externa al dispositivo. Como se usa en el presente documento, el término "memoria" se refiere a cualquier tipo de memoria a largo plazo, a corto plazo, volátil, no volátil u otra diferente, y no se debe limitar a ningún tipo de memoria o número de memorias en particular, ni al tipo de medio en el que se almacena la memoria.
[0087] Si se implementan en firmware y/o en software, las funciones se pueden almacenar como una o más instrucciones o código en un medio legible por ordenador. Ejemplos incluyen medios legibles por ordenador codificados con una estructura de datos y medios legibles por ordenador codificados con un programa informático.
Los medios legibles por ordenador incluyen medios de almacenamiento informáticos físicos. Un medio de almacenamiento puede ser cualquier medio disponible al que se pueda acceder mediante un ordenador. A modo de ejemplo, y no de limitación, dichos medios legibles por ordenador pueden comprender RAM, ROM, EEPROM, CD-ROM u otro almacenamiento en disco óptico, almacenamiento en disco magnético, almacenamiento de semiconductor u otros dispositivos de almacenamiento, o cualquier otro medio que se pueda usar para almacenar código de programa deseado en forma de instrucciones o estructuras de datos y al que se pueda acceder mediante un ordenador; como se usa en el presente documento, los discos incluyen disco compacto (CD), disco láser, disco óptico, disco versátil digital (DVD), disco flexible y disco Blu-ray, donde algunos discos reproducen normalmente datos de forma magnética, mientras que otros discos reproducen datos de forma óptica (por ejemplo, con láseres). Las combinaciones de lo anterior también se deben incluir dentro del alcance de los medios legibles por ordenador.
[0088] A menos que se defina de otro modo, todos los términos técnicos y científicos usados en el presente documento tienen el mismo significado que el adoptado común o convencionalmente. Como se usa en el presente documento, los artículos "un" y "una" se refieren a uno o a más de uno (es decir, a al menos uno) del objeto gramatical del artículo. A modo de ejemplo, "un elemento" significa un elemento o más de un elemento. "Aproximadamente" como se usa en el presente documento cuando se hace referencia a un valor medible, tal como una cantidad, una duración temporal y similares, engloba variaciones de ±20 % o ±10 %, ±5 % o 0,1 % del valor especificado, ya que dichas variaciones son apropiadas en el contexto de los sistemas, dispositivos, circuitos, procedimientos y otras implementaciones descritas en el presente documento. "Sustancialmente" como se usa en el presente documento cuando se hace referencia a un valor medible, tal como una cantidad, una duración temporal, un atributo físico (tal como la frecuencia) y similares, también engloba variaciones de ±20 % o ±10 %, ±5 %, o 0,1 % del valor especificado, ya que dichas variaciones son apropiadas en el contexto de los sistemas, dispositivos, circuitos, procedimientos y otras implementaciones descritas en el presente documento.
[0089] Como se usa en el presente documento, incluso en las reivindicaciones, "o", como se usa en una lista de elementos precedida por "al menos uno de" o "uno o más de" indica una lista disyuntiva de modo que, por ejemplo, una lista de "al menos uno de A, B o C" significa A o B o C o AB o AC o BC o ABC (es decir, A y B y C), o combinaciones con más de una característica (por ejemplo, AA, AAB, ABBC, etc.). Además, como se usa en el presente documento, a menos que se indique lo contrario, una afirmación de que una función u operación está "basada en" un elemento o condición significa que la función u operación se basa en el elemento o condición indicada y puede basarse en uno o más elementos y/o condiciones además del elemento o condición indicados.
[0090] Como se usa en el presente documento, un dispositivo o estación móvil (MS) puede hacer referencia a un dispositivo tal como un dispositivo celular u otro dispositivo de comunicación inalámbrica, un teléfono inteligente, una tableta electrónica, un dispositivo de un sistema de comunicación personal (PCS), un dispositivo de navegación personal (PND), un gestor de información personal (PIM), un asistente digital personal (PDA), un ordenador portátil u otro dispositivo móvil adecuado que pueda recibir señales inalámbricas de navegación y/o de comunicación, tales como señales de posicionamiento de navegación. El término "estación móvil" (o "dispositivo móvil" o "dispositivo inalámbrico") también pretende incluir dispositivos que se comunican con un dispositivo de navegación personal (PND), tal como mediante conexiones inalámbricas de corto alcance, infrarrojos, conexiones por cables u otras conexiones, independientemente de que se produzca una recepción de señales vía satélite, una recepción de datos de asistencia y/o un procesamiento relacionado con la posición en el dispositivo o en el PND. Además, el término "estación móvil" pretende incluir todos los dispositivos, incluidos dispositivos de comunicación inalámbrica, ordenadores, ordenadores portátiles, tabletas electrónicas, etc., que sean capaces de comunicarse con un servidor, tal como a través de Internet, WiFi u otra red, y de comunicarse con uno o más tipos de nodos, independientemente de que se produzca una recepción de señales vía satélite, una recepción de datos de asistencia y/o un procesamiento relacionado con la posición en el dispositivo, en un servidor o en otro dispositivo o nodo asociado a la red. Cualquier combinación operativa de lo anterior también se considera una "estación móvil". Un dispositivo móvil también puede denominarse terminal móvil, terminal, equipo de usuario (UE), dispositivo, terminal habilitado para su ubicación segura en el plano de usuario (SET), dispositivo de destino, objetivo o con algún otro nombre.
[0091] Si bien algunas de las técnicas, procesos y/o implementaciones presentadas en el presente documento pueden cumplir con todas o parte de una o más normas, dichas técnicas, procesos y/o implementaciones pueden, en algunos modos de realización, no cumplir con parte o la totalidad de dichas una o más normas.
[0092] La descripción detallada expuesta anteriormente en relación con los dibujos adjuntos se proporciona para permitir que un experto en la técnica realice o use la divulgación. Se contempla que se puedan realizar diversas sustituciones, alteraciones y modificaciones sin apartarse del alcance de la divulgación. A lo largo de esta divulgación, el término "ejemplo" indica un ejemplo o un caso, y no implica ni requiere ninguna preferencia por el ejemplo indicado. La descripción detallada incluye detalles específicos con el propósito de poder entender las técnicas descritas. Sin embargo, estas técnicas se pueden poner en práctica sin estos detalles específicos. En algunos casos, estructuras y dispositivos bien conocidos se muestran en forma de diagrama de bloques para no complicar los conceptos de los modos de realización descritos. Por tanto, la divulgación no se ha de limitar a los ejemplos y diseños descritos en el presente documento, sino que se le ha de otorgar el alcance más amplio consecuente con los principios y características novedosas divulgados en el presente documento.
Materia objeto adicional/modos de realización de interés
[0093] La siguiente enumeración se refiere a materia objeto adicional que puede ser de interés y que también se describe en detalle en el presente documento junto con la materia objeto presentada en las reivindicaciones iniciales presentadas en el presente documento:
A1 - Un procedimiento que comprende: recibir mediante al menos un servidor, desde un dispositivo, una solicitud para establecer una sesión de seguimiento para recopilar y enviar periódicamente datos de sesión de seguimiento al al menos un servidor en relación con una condición de emergencia en el dispositivo, donde la solicitud para establecer la sesión de seguimiento es enviada por el dispositivo en respuesta a un mensaje desencadenante de un servidor de llamadas de emergencia para iniciar la sesión de seguimiento, donde el mensaje desencadenante se transmite desde el servidor de llamadas de emergencia al dispositivo durante una sesión de llamadas de emergencia, separada de la sesión de seguimiento, en respuesta a un mensaje de indicación de la condición de emergencia en el dispositivo transmitido al servidor de llamadas de emergencia; enviar mediante el al menos un servidor una respuesta al dispositivo para establecer la sesión de seguimiento; y recibir periódicamente mediante el al menos un servidor, desde el dispositivo, los datos de sesión de seguimiento recopilados por el dispositivo durante la sesión de seguimiento.
A2 - El procedimiento mencionado en el ejemplo A1 de la materia objeto, en el que el dispositivo está configurado para funcionar durante la sesión de seguimiento en un estado de modo de seguimiento de energía reducida en el que la alimentación a los subsistemas del dispositivo no requeridos para recopilar y comunicar los datos de sesión de seguimiento asociados al dispositivo se reduce, y en el que uno o más subsistemas de sensor o comunicación del dispositivo, configurados para recopilar y comunicar los datos de sesión de seguimiento, funcionan, al menos parcialmente, mientras el dispositivo está en el estado de modo de seguimiento de energía reducida.
A3 - El procedimiento mencionado en el ejemplo A1 de la materia objeto, en el que la recepción periódica de los datos de sesión de seguimiento comprende: recibir los datos de sesión de seguimiento en uno o más instantes de tiempo, posteriores a un primer instante de tiempo, determinados en base a, al menos en parte, el nivel de energía de una batería del dispositivo.
A4 - El procedimiento mencionado en el ejemplo A3 de la materia objeto, en el que enviar la respuesta al dispositivo comprende: enviar la respuesta con datos que indican un valor de periodicidad máxima usado para determinar el uno o más instantes de tiempo, posteriores al primer instante de tiempo, y con datos representativos de parámetros de datos a incluir con los datos de sesión de seguimiento enviados por el dispositivo.
A5 - El procedimiento mencionado en el ejemplo A1 de la materia objeto, que comprende además: determinar una posición del dispositivo en base a, al menos en parte, datos de determinación de ubicación incluidos en los datos de sesión de seguimiento recibidos.
A6 - El procedimiento mencionado en el ejemplo A1 de la materia objeto, que comprende además: procesar los datos de sesión de seguimiento recibidos; y transmitir al menos algunos de los datos procesados a uno o más dispositivos asociados a uno o más proveedores de servicios de emergencia.
A7 - El procedimiento mencionado en el ejemplo A6 de la materia objeto, en el que el procesamiento de los datos de sesión de seguimiento recibidos comprende: filtrar los datos de sesión de seguimiento o agregar datos sin procesar incluidos en los datos de sesión de seguimiento, o cualquier combinación de los mismos, donde los datos sin procesar comprenden constantes vitales de un usuario del dispositivo, la posición del cuerpo del usuario derivada obtenida en base a sensores de orientación fijados al usuario, o datos de ubicación, o cualquier combinación de los mismos.
A8 - El procedimiento mencionado en el ejemplo A6 de la materia objeto, en el que la transmisión de al menos parte de los datos procesados comprende: transmitir los datos procesados a equipos de emergencia, o transmitir los datos procesados a uno o más sistemas de análisis, o cualquier combinación de los mismos, donde el uno o más sistemas de análisis incluyen un primer sistema para obtener estadísticas de tasa de éxito de resolución de emergencias, un segundo sistema para calcular un análisis de riesgos asociados a emergencias, o un tercer sistema para realizar análisis de causa raíz, o cualquier combinación de los mismos.
A9 - El procedimiento mencionado en el ejemplo A1 de la materia objeto, que comprende además: modificar la sesión de seguimiento para modificar: los tipos de datos recopilados y transmitidos al al menos un servidor por el dispositivo, los tiempos en que se envían los datos de sesión de seguimiento o la identidad de otro u otros servidores de seguimiento con los que el dispositivo va a comunicarse, o cualquier combinación de los mismos.
A10- El procedimiento mencionado en el ejemplo A1 de la materia objeto, en el que el mensaje de indicación de la condición de emergencia en el dispositivo transmitido al servidor de llamadas de emergencia comprende: un mensaje de inicio del dispositivo con respecto a la condición de emergencia, un mensaje de respuesta del dispositivo en respuesta a un mensaje de sondeo del servidor de llamadas de emergencia o un mensaje de notificación desde otro dispositivo para notificar la condición de emergencia en el dispositivo.
B1 - Un servidor que comprende: uno o más procesadores; y un transceptor, acoplado al uno o más procesadores, y configurado para: recibir, desde un dispositivo, una solicitud para establecer una sesión de seguimiento para recopilar y enviar periódicamente datos de sesión de seguimiento al al menos un servidor en relación con una condición de emergencia en el dispositivo, donde la solicitud para establecer la sesión de seguimiento es enviada por el dispositivo en respuesta a un mensaje desencadenante de un servidor de llamadas de emergencia para iniciar la sesión de seguimiento, donde el mensaje desencadenante se transmite desde el servidor de llamadas de emergencia al dispositivo durante una sesión de llamadas de emergencia, separada de la sesión de seguimiento, en respuesta a un mensaje de indicación de la condición de emergencia en el dispositivo transmitido al servidor de llamadas de emergencia; enviar una respuesta al dispositivo para establecer la sesión de seguimiento; y recibir periódicamente, desde el dispositivo, los datos de sesión de seguimiento recopilados por el dispositivo durante la sesión de seguimiento.
C1 - Un aparato que comprende: medios para recibir mediante al menos un servidor, desde un dispositivo, una solicitud para establecer una sesión de seguimiento para recopilar y enviar periódicamente datos de sesión de seguimiento al al menos un servidor en relación con una condición de emergencia en el dispositivo, donde la solicitud para establecer la sesión de seguimiento es enviada por el dispositivo en respuesta a un mensaje desencadenante de un servidor de llamadas de emergencia para iniciar la sesión de seguimiento, donde el mensaje desencadenante se transmite desde el servidor de llamadas de emergencia al dispositivo durante una sesión de llamadas de emergencia, separada de la sesión de seguimiento, en respuesta a un mensaje de indicación de la condición de emergencia en el dispositivo transmitido al servidor de llamadas de emergencia; medios para enviar mediante el al menos un servidor una respuesta al dispositivo para establecer la sesión de seguimiento; y medios para recibir periódicamente mediante el al menos un servidor, desde el dispositivo, los datos de sesión de seguimiento recopilados por el dispositivo durante la sesión de seguimiento.
D1- Un medio legible por ordenador no transitorio programado con instrucciones, ejecutables en un procesador, para: recibir mediante al menos un servidor, desde un dispositivo, una solicitud para establecer una sesión de seguimiento para recopilar y enviar periódicamente datos de sesión de seguimiento al al menos un servidor en relación con una condición de emergencia en el dispositivo, donde la solicitud para establecer la sesión de seguimiento es enviada por el dispositivo en respuesta a un mensaje desencadenante de un servidor de llamadas de emergencia para iniciar la sesión de seguimiento, donde el mensaje desencadenante se transmite desde el servidor de llamadas de emergencia al dispositivo durante una sesión de llamadas de emergencia, separada de la sesión de seguimiento, en respuesta a un mensaje de indicación de la condición de emergencia en el dispositivo transmitido al servidor de llamadas de emergencia; enviar mediante el al menos un servidor una respuesta al dispositivo para establecer la sesión de seguimiento; y recibir periódicamente mediante el al menos un servidor, desde el dispositivo, los datos de sesión de seguimiento recopilados por el dispositivo durante la sesión de seguimiento.
[0094] Aunque en el presente documento se han divulgado en detalle modos de realización particulares, esto se ha hecho a modo de ejemplo únicamente con propósitos ilustrativos, y no pretende limitar al alcance de las siguientes reivindicaciones adjuntas. Se considera que otros aspectos, ventajas y modificaciones están dentro del alcance de las siguientes reivindicaciones. Las reivindicaciones presentadas son representativas de los modos de realización y características divulgados en el presente documento. También se contemplan otros modos de realización y características no reivindicados. En consecuencia, otros modos de realización están dentro del alcance de las siguientes reivindicaciones.

Claims (15)

REIVINDICACIONES
1. Un procedimiento (400) que comprende:
recibir (410) por un servidor de llamadas de emergencia una indicación de una condición de emergencia en un dispositivo y establecer una sesión de llamada de emergencia con dicho dispositivo;
determinar (420) si el dispositivo móvil debe rastrearse basándose, al menos en parte, en la indicación de la condición de emergencia; y
transmitir (430) un mensaje desencadenante desde el servidor de llamadas de emergencia, en respuesta a una determinación de que el dispositivo debe rastrearse, para desencadenar en el dispositivo una sesión de rastreo para causar que el dispositivo recopile y envíe periódicamente datos de la sesión de rastreo a uno o más servidores, en el que la sesión de rastreo, establecida entre el dispositivo y los uno o más servidores, está separada de una sesión de llamada de emergencia establecida entre el dispositivo y el servidor de llamadas de emergencia.
2. El procedimiento de la reivindicación 1, en el que el mensaje desencadenante transmitido al dispositivo está configurado además para causar que el dispositivo funcione en un estado de modo de rastreo de energía reducida en el cual se reduce la energía suministrada a subsistemas del dispositivo no requeridos para recopilar y comunicar los datos de la sesión de rastreo asociados con el dispositivo, y en el cual uno o más subsistemas de sensor o comunicación del dispositivo, configurados para recopilar y comunicar los datos de la sesión de rastreo, funcionan al menos parcialmente mientras el dispositivo está en el estado de modo de rastreo de energía reducida.
3. El procedimiento de la reivindicación 2, en el que el mensaje desencadenante transmitido al dispositivo está configurado además para bloquear el dispositivo en el estado de modo de rastreo de energía reducida para evitar la desactivación del uno o más subsistemas de sensor y comunicación del dispositivo necesarios para recopilar y comunicar los datos de la sesión de rastreo incluso si el dispositivo se apaga por un usuario.
4. El procedimiento de la reivindicación 1, en el que determinar (420) si el dispositivo debe rastrearse comprende:
determinar si el dispositivo debe rastrearse basándose, al menos en parte, en la indicación de la condición de emergencia, capacidades del dispositivo transmitidas al servidor de llamadas de emergencia o datos basados en la localización para el dispositivo, o cualquier combinación de los mismos; y
en el que las capacidades de dispositivo del dispositivo comprenden: protocolos de comunicación soportados por el dispositivo, tipos de transceptores incluidos con el dispositivo, tipos de sensores incluidos con el dispositivo, o el nivel de batería del dispositivo o cualquier combinación de los mismos.
5. El procedimiento de la reivindicación 1, que comprende además:
determinar una posición del dispositivo basándose, al menos en parte, en datos basados en la localización incluidos con la indicación recibida de la condición de emergencia, los datos basados en la localización que comprenden: una aproximación calculada de la localización del dispositivo, mediciones de sensor para el dispositivo, medidas de temporización medidas por el dispositivo, o medidas de intensidad de señal medidas por el dispositivo, o cualquier combinación de las mismas.
6. El procedimiento de la reivindicación 1, en el que recibir (410) por el servidor de llamadas de emergencia la indicación de la condición de emergencia comprende:
recibir por el servidor de llamadas de emergencia un mensaje de emergencia iniciado por el dispositivo; o
transmitir a uno o más dispositivos, incluyendo el dispositivo, un mensaje de radiodifusión configurado para causar una determinación de si al menos uno de los uno o más dispositivos tiene una emergencia; y
recibir, en respuesta a un mensaje de radiodifusión transmitido por el servidor de llamadas de emergencia, un mensaje de respuesta desde el dispositivo, comprendiendo el mensaje de respuesta la indicación de la condición de emergencia; o
recibir por el servidor de llamadas de emergencia: un mensaje del protocolo de posicionamiento de evolución a largo plazo, LPP, un mensaje del protocolo de inicio de sesión, SIP, un mensaje del sistema universal de telecomunicaciones móviles, UMTS, o un mensaje del protocolo seguro de transferencia de hipertexto, HTTPS, o cualquier combinación de los mismos.
7. El procedimiento de la reivindicación 1, en el que transmitir (430) el mensaje desencadenante desde el servidor de llamadas de emergencia comprende:
transmitir un comando de sesión de rastreo obligatorio en respuesta a la determinación de que el dispositivo debe rastrearse, para causar que el dispositivo establezca la sesión de rastreo, en el que el comando de sesión de rastreo obligatorio no puede anularse por el dispositivo o por un usuario del dispositivo.
8. El procedimiento de la reivindicación 1, que comprende además:
determinar los uno o más servidores con los cuales el dispositivo debe establecer la sesión de rastreo; y
comunicar al dispositivo uno o más identificadores respectivos representativos de las identidades del uno o más servidores con los cuales el dispositivo debe establecer la sesión de rastreo.
9. El procedimiento de la reivindicación 8, en el que comunicar al dispositivo los uno o más identificadores respectivos de los uno o más servidores comprende:
comunicar, al dispositivo, una o más URL asociadas con los uno o más servidores, una dirección IP o un identificador de elemento de red, o cualquier combinación de los mismos; o
en el que determinar los uno o más servidores con los cuales el dispositivo debe establecer la sesión de rastreo comprende:
determinar los uno o más servidores basándose en uno o más de: capacidades de dispositivo del dispositivo, datos basados en la localización para el dispositivo, o tipo de emergencia en el dispositivo, o cualquier combinación de los mismos.
10. Un servidor de llamadas de emergencia que comprende:
un transceptor configurado para:
recibir (410) una indicación de una condición de emergencia en un dispositivo; y
uno o más procesadores, acoplados al transceptor, configurados para:
establecer una sesión de llamada de emergencia con dicho dispositivo;
determinar (420) si el dispositivo móvil debe rastrearse basándose, al menos en parte, en la indicación de la condición de emergencia; y
en el que el transceptor está configurado además para transmitir (430) un mensaje desencadenante desde el servidor de llamadas de emergencia, en respuesta a una determinación de que el dispositivo debe rastrearse, para desencadenar en el dispositivo una sesión de rastreo para causar que el dispositivo recopile y envíe periódicamente datos de la sesión de rastreo a uno o más servidores, en el que la sesión de rastreo, establecida entre el dispositivo y los uno o más servidores, está separada de una sesión de llamada de emergencia establecida entre el dispositivo y el servidor de llamadas de emergencia.
11. El servidor de llamadas de emergencia de la reivindicación 10, en el que el mensaje desencadenante transmitido al dispositivo está configurado además para causar que el dispositivo funcione en un estado de modo de rastreo de energía reducida en el cual se reduce la energía suministrada a subsistemas del dispositivo no requeridos para recopilar y comunicar datos de la sesión de rastreo asociados con el dispositivo móvil, y en el cual uno o más subsistemas de sensor o de comunicación del dispositivo, configurados para recopilar y comunicar los datos de la sesión de rastreo, funcionan al menos parcialmente mientras el dispositivo está en el estado de modo de rastreo de energía reducida.
12. El servidor de llamadas de emergencia de la reivindicación 11, en el que el mensaje desencadenante transmitido al dispositivo está configurado además para bloquear el dispositivo en el estado de modo de rastreo de energía reducida para evitar la desactivación del uno o más subsistemas de sensor y comunicación del dispositivo necesarios para recopilar y comunicar los datos de la sesión de rastreo incluso si el dispositivo se apaga por un usuario.
13. El servidor de llamadas de emergencia de la reivindicación 10, en el que los uno o más procesadores están configurados para:
determinar (420) si el dispositivo debe rastrearse basándose, al menos en parte, en la indicación de la condición de emergencia, capacidades de dispositivo del dispositivo transmitidas al servidor de llamadas de emergencia, o datos basados en la localización para el dispositivo, o cualquier combinación de los mismos; o
determinar los uno o más servidores con los cuales el dispositivo establecerá la sesión de rastreo; y comunicar al dispositivo uno o más identificadores respectivos representativos de las identidades de los uno o más servidores con los cuales el dispositivo debe establecer la sesión de rastreo
en el que la determinación de los uno o más servidores se basa en uno o más de: las capacidades de dispositivo del dispositivo, datos basados en la localización para el dispositivo, o tipo de emergencia en el dispositivo, o cualquier combinación de los mismos.
14. El servidor de llamadas de emergencia de la reivindicación 10, en el que el transceptor está configurado además para:
recibir un mensaje de emergencia iniciado por el dispositivo; o
transmitir a uno o más dispositivos, incluyendo el dispositivo, un mensaje de radiodifusión configurado para causar una determinación de si al menos uno de los uno o más dispositivos tiene una emergencia; y enviar, en respuesta a un mensaje de radiodifusión transmitido por el servidor de llamadas de emergencia, un mensaje de respuesta desde el dispositivo, comprendiendo el mensaje de respuesta la indicación de la condición de emergencia; o
recibir un comando de sesión de rastreo obligatorio en respuesta a la determinación de que el dispositivo debe rastrearse para causar que el dispositivo establezca la sesión de rastreo, en la que el comando de sesión de rastreo obligatorio no puede anularse por el dispositivo ni por un usuario del dispositivo; o recibir por el servidor de llamadas de emergencia: un mensaje de protocolo de posicionamiento de evolución a largo plazo, LPP, un mensaje de protocolo de inicio de sesión, SIP, un mensaje de sistema de telecomunicaciones móviles universal, UMTS, o un mensaje de protocolo seguro de transferencia de hipertexto, HTTPS, o cualquier combinación de los mismos.
15. Un medio no transitorio legible por ordenador programado con instrucciones, ejecutables en un procesador, para llevar a cabo las etapas de procedimiento de las reivindicaciones 1-9.
ES16797695T 2015-12-16 2016-11-01 Sistemas y procedimientos para la comunicación de datos de emergencia Active ES2798673T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201562268241P 2015-12-16 2015-12-16
US15/078,846 US10142772B2 (en) 2015-12-16 2016-03-23 Systems and methods for emergency data communication
PCT/US2016/059930 WO2017105653A1 (en) 2015-12-16 2016-11-01 Systems and methods for emergency data communication

Publications (1)

Publication Number Publication Date
ES2798673T3 true ES2798673T3 (es) 2020-12-11

Family

ID=57326493

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16797695T Active ES2798673T3 (es) 2015-12-16 2016-11-01 Sistemas y procedimientos para la comunicación de datos de emergencia

Country Status (6)

Country Link
US (2) US10142772B2 (es)
EP (1) EP3391674B1 (es)
CN (1) CN108476395B (es)
ES (1) ES2798673T3 (es)
HU (1) HUE048903T2 (es)
WO (1) WO2017105653A1 (es)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10142816B2 (en) 2015-12-16 2018-11-27 Qualcomm Incorporated Systems and methods for emergency data communication
US10142772B2 (en) 2015-12-16 2018-11-27 Qualcomm Incorporated Systems and methods for emergency data communication
CN106937242B (zh) * 2016-12-27 2020-01-07 四川雷克斯智慧科技股份有限公司 一种基于物联网的火场进入控制方法
FR3063558A1 (fr) * 2017-03-02 2018-09-07 Stmicroelectronics (Rousset) Sas Procede de controle de la detection en temps reel d'une scene par un appareil de communication sans fil et appareil correspondant
KR102248793B1 (ko) * 2017-06-07 2021-05-07 에더트로닉스, 잉크. 고도 변경 객체들을 갖는 시스템들을 위한 전력 제어 방법
US10681639B2 (en) * 2017-06-15 2020-06-09 HyperTrack Inc. Systems and methods for receiving sensor data from a mobile device
US10129704B1 (en) * 2017-06-27 2018-11-13 Honeywell International Inc., A Delaware Corporation First responder tracking breadcrumbs
US10952052B2 (en) 2017-10-11 2021-03-16 Blackberry Limited Method and system for dynamic APN selection
US10716068B2 (en) * 2017-10-13 2020-07-14 Denso International America, Inc. Power saving methods for communication in localization systems
US10981576B2 (en) 2017-12-27 2021-04-20 Micron Technology, Inc. Determination of reliability of vehicle control commands via memory test
US10933882B2 (en) 2017-12-27 2021-03-02 Micron Technology, Inc. Determination of reliability of vehicle control commands using a voting mechanism
CN110418294A (zh) * 2018-04-27 2019-11-05 国基电子（上海）有限公司 通信方法、车载装置及计算机可读存储介质
US11507175B2 (en) * 2018-11-02 2022-11-22 Micron Technology, Inc. Data link between volatile memory and non-volatile memory
KR102611371B1 (ko) * 2018-12-13 2023-12-06 엘지전자 주식회사 차량용 시스템 및 방법
CN109673002B (zh) * 2019-01-22 2021-06-15 维沃移动通信有限公司 一种求救方法及装置
US11109309B2 (en) * 2019-03-29 2021-08-31 Blackberry Limited Systems and methods for establishing short-range communication links between asset tracking devices
DE102019215195A1 (de) * 2019-10-02 2021-04-08 Robert Bosch Gmbh Vorrichtung und Verfahren zum Verfolgen einer Position
KR20210108784A (ko) * 2020-02-26 2021-09-03 삼성전자주식회사 무선 데이터 통신 id를 이용하여 차량의 내부 시스템을 제어하는 전자 장치 및 그 동작 방법
CN113411854B (zh) * 2021-06-17 2023-03-10 海能达通信股份有限公司 一种会话切换管控方法及装置
WO2023143712A1 (en) * 2022-01-26 2023-08-03 Telefonaktiebolaget Lm Ericsson (Publ) Emergency call with ios data

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030144042A1 (en) 2002-01-29 2003-07-31 Aaron Weinfield Negotiation of position information during low battery life
US7359716B2 (en) * 2003-01-31 2008-04-15 Douglas Rowitch Location based service (LBS) system, method and apparatus for authorization of mobile station LBS applications
KR20070086974A (ko) 2004-12-07 2007-08-27 샤프 가부시키가이샤 휴대 단말기, 긴급 통보 시스템 및 긴급 통보 방법
WO2008144051A1 (en) 2007-05-17 2008-11-27 Airo Wireless Inc. A system and method for providing tracking for mobile resources over a network
US8270935B2 (en) * 2007-12-05 2012-09-18 Apple Inc. Method and system for prolonging emergency calls
CN102036204B (zh) * 2009-09-24 2015-06-03 中兴通讯股份有限公司 一种实现紧急定位的方法及系统
US8886157B2 (en) 2010-11-08 2014-11-11 Qualcomm Incorporated Mobile device having an emergency mode
US8594614B2 (en) 2011-01-04 2013-11-26 Blackberry Limited Handling emergency calls on an electronic device
CN103002425B (zh) 2011-09-16 2015-03-11 三星电子（中国）研发中心 自动触发紧急呼叫的方法和系统及其移动终端
US8937554B2 (en) 2011-09-28 2015-01-20 Silverplus, Inc. Low power location-tracking device with combined short-range and wide-area wireless and location capabilities
US8693979B2 (en) 2011-11-01 2014-04-08 Qualcomm Incorporated Power efficient emergency call triggered tracking method
US8538374B1 (en) 2011-12-07 2013-09-17 Barry E. Haimo Emergency communications mobile application
EP2654025B1 (en) 2012-04-17 2017-06-07 Harman Becker Automotive Systems GmbH Mounting location of automatic in-vehicle emergency call device.
KR20150024880A (ko) * 2012-06-05 2015-03-09 넥스트나브, 엘엘씨 사용자 장치의 위치 찾기를 위한 시스템 및 방법
GB201301576D0 (en) 2013-01-29 2013-03-13 Georeach System
WO2014069909A1 (en) 2012-11-01 2014-05-08 Lg Electronics Inc. Method and apparatus of providing integrity protection for proximity-based service discovery with extended discovery range
US9204256B2 (en) * 2013-03-11 2015-12-01 Qualcomm Incorporated Method and apparatus for providing user plane or control plane position services
CN104112247A (zh) 2013-04-19 2014-10-22 华为技术有限公司 急救服务器、呼叫终端及紧急呼叫方法
US20150189485A1 (en) 2013-12-26 2015-07-02 Intel Corporation Emergency mobile originated location report
US20150213708A1 (en) * 2014-01-28 2015-07-30 Sony Corporation Apparatus and methods for tracking in wireless communication systems in response to an activation event
US10356589B2 (en) 2015-05-15 2019-07-16 Rave Wireless, Inc. Real-time over the top 9-1-1 caller location data
US10142816B2 (en) 2015-12-16 2018-11-27 Qualcomm Incorporated Systems and methods for emergency data communication
US10142772B2 (en) 2015-12-16 2018-11-27 Qualcomm Incorporated Systems and methods for emergency data communication

Also Published As

Publication number Publication date
EP3391674A1 (en) 2018-10-24
WO2017105653A1 (en) 2017-06-22
US10841732B2 (en) 2020-11-17
US20190090088A1 (en) 2019-03-21
EP3391674B1 (en) 2020-04-15
CN108476395B (zh) 2021-09-17
US10142772B2 (en) 2018-11-27
CN108476395A (zh) 2018-08-31
US20170180929A1 (en) 2017-06-22
HUE048903T2 (hu) 2020-08-28

Similar Documents

Publication Publication Date Title
ES2794946T3 (es) Sistemas y procedimientos para la comunicación de datos de emergencia
ES2798673T3 (es) Sistemas y procedimientos para la comunicación de datos de emergencia
US10912056B2 (en) Method and system for locating a network device in an emergency situation including public location information
US10588004B2 (en) Method and system for locating a network device in an emergency situation
US20210014659A1 (en) Systems and methods for emergency communications amongst groups of devices based on shared data
US9980113B2 (en) Emergency communications from a local area network hotspot
US11089441B2 (en) Method and system for locating a network device in an emergency situation including public location information with device verification
US10511950B2 (en) Method and system for an emergency location information service (E-LIS) for Internet of Things (IoT) devices
US9715815B2 (en) Wirelessly tethered device tracking
US9094816B2 (en) Method and system for an emergency location information service (E-LIS) from unmanned aerial vehicles (UAV)
US8918075B2 (en) Method and system for an emergency location information service (E-LIS) from wearable devices
WO2018144104A1 (en) Systems and methods for position estimation using proximity devices
US10609541B1 (en) Method and apparatus for emergency alert in client devices
US11546955B2 (en) Sidelink-based device-to-device communication
US10667257B2 (en) Remote initiation of tasks on idle wireless computing devices
WO2018144103A1 (en) Systems and methods for position estimation using proximity devices