WEARABLE DEVICES

TECHNICAL FIELD

[0001] The illustrative embodiments generally relate to utilizing features of wearable devices that interact with a vehicle computer system.

BACKGROUND

[0002] Wearable devices may be worn by users to monitor their daily activity. Wearable devices worn by users may also be utilized while in a vehicle. A vehicle may communicate data with a wearable device to be utilized in various vehicle settings.

SUMMARY

[0003] A first illustrative embodiment discloses a vehicle computer system comprising a wireless transceiver configured to receive wearable device data from one or more wearable devices each corresponding to an occupant. The vehicle computer system further comprises a processor configured to output to an off-board server a parameter indicative of a severity of a vehicle accident in response to the wearable device data indicating pre-accident to post-accident changes in relative occupant location.

[0004] A second illustrative embodiment discloses a vehicle comprising a vehicle processor in communication with a wireless transceiver that is configured to receive wearable device data from wearable devices worn by occupants of the vehicle and configured to output to an emergency service provider, in response to vehicle impact, a parameter indicative of a degree of the vehicle impact based on the wearable device data indicating pre-impact to post-impact changes in relative occupant location. [0005] A third illustrative embodiment discloses a vehicle computer system comprising a wireless transceiver configured to communicate with a plurality of wearable devices that each correspond to one of a plurality of occupants. The vehicle computer system further includes a processor configured to receive wearable device data from the wearable devices via the transceiver and, in response to a detected accident condition, to output to the transceiver age-range data of the occupants derived from the wearable device data.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Figure 1 illustrates an example block topology for a vehicle based computing system for a vehicle.

[0007] Figure 2 illustrates an example block topology of a vehicle based computing system utilizing various wearable devices during an emergency situation.

[0008] Figure 3 illustrates an illustrative sequence diagram identifying data communication between a vehicle and a wearable device during a vehicle emergency.

[0009] Figure 4 illustrates an exemplary flow chart for utilizing wearable device data in the event of a vehicle emergency.

DETAILED DESCRIPTION

[0010] As required, detailed embodiments of the present invention are disclosed herein; however, it is to be understood that the disclosed embodiments are merely exemplary of the invention that may be embodied in various and alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present invention. [0011] The invention now will be described more fully hereinafter with reference to the accompanying drawings, in which illustrative embodiments of the invention are shown. This invention, may however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Like numbers refer to elements throughout. As used herein the term "and/or" includes any and all combinations of one or more of the associated listed items.

[0012] Figure 1 illustrates an example block topology for a vehicle based computing system

1 (VCS) for a vehicle 31. An example of such a vehicle-based computing system 1 is the SYNC system manufactured by THE FORD MOTOR COMPANY. A vehicle enabled with a vehicle-based computing system may contain a visual front end interface 4 located in the vehicle. The user may also be able to interact with the interface if it is provided, for example, with a touch sensitive screen. In another illustrative embodiment, the interaction occurs through, button presses, spoken dialog system with automatic speech recognition and speech synthesis.

[0013] In the illustrative embodiment 1 shown in Figure 1, a processor 3 controls at least some portion of the operation of the vehicle-based computing system. Provided within the vehicle, the processor allows onboard processing of commands and routines. Further, the processor is connected to both non-persistent 5 and persistent storage 7. In this illustrative embodiment, the non- persistent storage is random access memory (RAM) and the persistent storage is a hard disk drive (HDD) or flash memory.

[0014] The processor is also provided with a number of different inputs allowing the user to interface with the processor. In this illustrative embodiment, a microphone 29, an auxiliary input 25 (for input 33), a USB input 23, a GPS input 24 and a BLUETOOTH input 15 are all provided. An input selector 51 is also provided, to allow a user to select between various inputs. Input to both the microphone and the auxiliary connector is converted from analog to digital by a converter 27 before being passed to the processor. Although not shown, these and other components may be in communication with the VCS over a vehicle multiplex network (such as, but not limited to, a CAN bus) to pass data to and from the VCS (or components thereof). [0015] Outputs to the system can include, but are not limited to, a visual display 4 and a speaker 13 or stereo system output. The speaker is connected to an amplifier 1 1 and receives its signal from the processor 3 through a digital-to-analog converter 9. Output can also be made to a remote BLUETOOTH device such as PND 54 or a USB device such as vehicle navigation device 60 along the bi-directional data streams shown at 19 and 21 respectively.

[0016] In one illustrative embodiment, the system 1 uses the BLUETOOTH transceiver 15 to communicate 17 with a user's nomadic device 53 (e.g., wearable device, cell phone, smart phone, PDA, tablet, a device having wireless remote network connectivity, etc.). The nomadic device can then be used to communicate 59 with a network 61 outside the vehicle 31 through, for example, communication 55 with a cellular tower 57. In some embodiments, tower 57 may be a WiFi access point.

[0017] Exemplary communication between the nomadic device and the BLUETOOTH transceiver is represented by signal 14.

[0018] Pairing a nomadic device 53 and the BLUETOOTH transceiver 15 can be instructed through a button 52 or similar input. Accordingly, the CPU is instructed that the onboard BLUETOOTH transceiver will be paired with a BLUETOOTH transceiver in a nomadic device.

[0019] Data may be communicated between CPU 3 and network 61 utilizing, for example, a data-plan, data over voice, or DTMF tones associated with nomadic device 53. Alternatively, it may be desirable to include an onboard modem 63 having antenna 18 in order to communicate 16 data between CPU 3 and network 61 over the voice band. The nomadic device 53 can then be used to communicate 59 with a network 61 outside the vehicle 31 through, for example, communication 55 with a cellular tower 57. In some embodiments, the modem 63 may establish communication 20 with the tower 57 for communicating with network 61. As a non-limiting example, modem 63 may be a USB cellular modem and communication 20 may be cellular communication.

[0020] In one illustrative embodiment, the processor is provided with an operating system including an API to communicate with modem application software. The modem application software may access an embedded module or firmware on the BLUETOOTH transceiver to complete wireless communication with a remote BLUETOOTH transceiver (such as that found in a nomadic device). Bluetooth is a subset of the IEEE 802 PAN (personal area network) protocols. IEEE 802 LAN (local area network) protocols include WiFi and have considerable cross- functionality with IEEE 802 PAN. Both are suitable for wireless communication within a vehicle. Another communication means that can be used in this realm is free-space optical communication (such as IrDA) and non-standardized consumer IR protocols.

[0021] In another embodiment, nomadic device 53 includes a modem for voice band or broadband data communication. In the data-over-voice embodiment, a technique known as frequency division multiplexing may be implemented when the owner of the nomadic device can talk over the device while data is being transferred. At other times, when the owner is not using the device, the data transfer can use the whole bandwidth (300 Hz to 3.4kHz in one example). While frequency division multiplexing may be common for analog cellular communication between the vehicle and the internet, and is still used, it has been largely replaced by hybrids of Code Domain Multiple Access (CDMA), Time Domain Multiple Access (TDMA), Space-Domain Multiple Access (SDMA) for digital cellular communication. These are all ITU IMT-2000 (3G) compliant standards and offer data rates up to 2 mbs for stationary or walking users and 385 kbs for users in a moving vehicle. 3G standards are now being replaced by IMT-Advanced (4G) which offers 100 mbs for users in a vehicle and 1 gbs for stationary users. If the user has a data-plan associated with the nomadic device, it is possible that the data- plan allows for broad-band transmission and the system could use a much wider bandwidth (speeding up data transfer). In still another embodiment, nomadic device 53 is replaced with a cellular communication device (not shown) that is installed to vehicle 31. In yet another embodiment, the ND 53 may be a wireless local area network (LAN) device capable of communication over, for example (and without limitation), an 802. l lg network (i.e., WiFi) or a WiMax network.

[0022] In one embodiment, incoming data can be passed through the nomadic device via a data-over-voice or data-plan, through the onboard BLUETOOTH transceiver and into the vehicle's internal processor 3. In the case of certain temporary data, for example, the data can be stored on the HDD or other storage media 7 until such time as the data is no longer needed. [0023] Additional sources that may interface with the vehicle include a personal navigation device 54, having, for example, a USB connection 56 and/or an antenna 58, a vehicle navigation device 60 having a USB 62 or other connection, an onboard GPS device 24, or remote navigation system (not shown) having connectivity to network 61. USB is one of a class of serial networking protocols. IEEE 1394 (FireWire™ (Apple), i.LI K™ (Sony), and Lynx™ (Texas Instruments)), EIA (Electronics Industry Association) serial protocols, IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) and USB-IF (USB Implementers Forum) form the backbone of the device-device serial standards. Most of the protocols can be implemented for either electrical or optical communication.

[0024] Further, the CPU could be in communication with a variety of other auxiliary devices

65. These devices can be connected through a wireless 67 or wired 69 connection. Auxiliary device 65 may include, but are not limited to, personal media players, wireless health devices, portable computers, nomadic device, key fob and the like.

[0025] Also, or alternatively, the CPU could be connected to a vehicle based wireless router

73, using for example a WiFi (IEEE 803.11) 71 transceiver. This could allow the CPU to connect to remote networks in range of the local router 73.

[0026] In addition to having exemplary processes executed by a vehicle computing system located in a vehicle, in certain embodiments, the exemplary processes may be executed by a computing system in communication with a vehicle computing system. Such a system may include, but is not limited to, a wireless device (e.g., and without limitation, a mobile phone) or a remote computing system (e.g., and without limitation, a server) connected through the wireless device. Collectively, such systems may be referred to as vehicle associated computing systems (VACS). In certain embodiments particular components of the VACS may perform particular portions of a process depending on the particular implementation of the system. By way of example and not limitation, if a process has a step of sending or receiving information with a paired wireless device, then it is likely that the wireless device is not performing the process, since the wireless device would not "send and receive" information with itself. One of ordinary skill in the art will understand when it is inappropriate to apply a particular VACS to a given solution. In all solutions, it is contemplated that at least the vehicle computing system (VCS) located within the vehicle itself is capable of performing the exemplary processes.

[0027] Figure 2 illustrates an example block topology of a vehicle based computing system that may be utilized for assistance during a vehicle emergency. The vehicle 201 may include vehicle modules to detect an emergency situation 203, including various sensors, processor, or controllers. Such vehicle modules may be utilized to detect a crash, sudden acceleration/deceleration, impacts, air bag deployment, etc. The modules may be in communication with one another or other remote services in order to recognize an emergency situation.

[0028] The vehicle may include multiple occupants, including a driver and passengers. The occupants may wear wearable devices that they own or utilize that interact with the vehicle computer system (VCS). Such wearable devices may include smart glasses, smart watch, pedometer, activity tracker or health monitor (e.g. FITBIT), clothing that includes sensors (e.g. E-textiles, smart shirt, etc), GPS watch, or other type of devices. The devices may interact with the vehicle computer system via wireless or wired communication. The vehicle computer system may be configured to interact with multiple devices 205, 207, 209. For example, the vehicle 201 may include a first occupant wearing a wearable device 205, a second occupant wearing a second wearable device 207, and a third occupant wearing a third wearable device (FITBIT) 209. The VCS may also be in communication with nomadic devices, such as phones. The vehicle computer system may exchange data with the wearable devices and nomadic devices for various applications.

[0029] During a vehicle emergency situation 203 (e.g. a crash), the vehicle 201 may send the transmission of all connected wearables data, which could include the number of passengers and additional info 21 1 to the cloud 213. The cloud 213 may utilize the data for enhancing emergency services, if necessary. The cloud may also have additional data to extract related to the user or vehicle based on the wearable devices and information/data from the vehicle computer system. For instance, the cloud may recognize attributes of a particular vehicle involved in the accident based on the vehicle identification number (VEST), which can tailor emergency services to the vehicle. Upon receiving the VIN information, the cloud 213 may have access to additional databases or off-board servers to communicate vehicle information, such as make, model, year, engine-type, etc. Additionally, the cloud 213 may receive data from the wearable devices to recognize an occupant. Upon receiving the data from the wearable device, the cloud may have additional access to other databases or servers to retrieve additional data, such as emergency contact information, preferred physician, or other data.

[0030] The cloud may send part or all of the data 221 to an emergency operator 215. The emergency operator 215 may be able to utilize the data to enhance services provided to the vehicle 201 and occupants. A wearable device may be able to send movement data to an emergency service provider that is related to the user. The movement data may be relevant to a specific body part of the user. The movement data may be analyzed pre-crash and post-crash to detect any serious conditions, injuries, or other data. The data utilized by the wearable device may be sent to the cloud 213 to be input to create a determination of various vehicle conditions (impact of the crash, number of occupants, ages of the occupants, situation of the occupant, severity of the accident, determines type of hospital to send users based on the emergency, etc.). For example, the vehicle may monitor the wearable device data before a crash, and compare it to the data after a crash. After analyzing such data, the severity of the accident may be determined (e.g. ranked low severity to high severity) and provided to an emergency responder or other third party.

[0031] The emergency operator 215 may also be able to send some or all of the data 223 to the emergency responder 217. The emergency responder may utilize the data for prompt responses. For example, the emergency responder may be able to utilize the analytics from the wearable device data that identifies the number of occupants, ages of the occupants, situation of the occupant, severity of accident, recommended type of hospital, etc. The analytics may also be able to be sent to a hospital, doctors, helicopter response, and fire-department. For example, if the wearable device data indicates that a roll-over accident occurred, the vehicle may send data indicating a roll-over occurred to an emergency responder. The vehicle or emergency responder may notify the fire department that the "Jaws of Life" may be needed to assist in the incident.

[0032] Figure 3 shows an illustrative sequence diagram of a vehicle based computing system in communication with wearable devices that illustrate the transfer of various communication and data. The VCS may utilize a Bluetooth transceiver to pair with a wear device 301. The pairing process may utilize different Bluetooth profiles to facilitate communication between the VCS and the wearable device. Some of these profiles may include HFP, A2DP, AVRCP, PBAP, HID, BVRA (part of the HFP profile), etc. The pairing process may be accomplished from either the wearable device or the VCS.

[0033] The vehicle may be in communication with a first wearable device 301, a second wearable device 302, or other wearable devices 303. Given m vehicle occupants, each with up to n possible wearables 303, one can represent an occupant-wearable (O-W) matrix in the form of the following matrix:

[0035] Where, An represents the j wearable of the i occupant. The vectorial Aj ₂ ... A _in ] represents the n possible wearables associated with the t ^th occupant.

[0036] The system may detect a number of wearables detected within the vehicle. For purposes of this embodiment, the system may assume P wearables are detected on the interior. In subsequent steps, these P wearables will need to be associated with the Q possible individual occupants with wearables.

[0037] The process of detecting the Q possible vehicle occupants with wearables itself may utilize four-dimensional (three spatial dimensions and one temporal dimension) spatial clustering to identify Q possible clusters and label the occupants from 1 to Q based on the locations of the detected wearables. Thus a single occupant may include multiple wearables that could be detected to be correlated to a specific occupant. For example, a single occupant may include a mobile device and a smart watch.

[0038] Based on a predetermined format, an O-W matrix may be mapped into a state matrix

"S" in the following manner: [0039] where,

[0040]

0 if the j wearable of the i occupant is not detected and 1 if it is detected.

[0041] The matrix S is expected to be a sparse matrix (i.e., containing a number of zeroes) but the key novelty is in using this matrix to infer a number of properties, including: (1) the minimum number of occupants; (2) the possible range of ages of occupants; (3) the locations of occupants; (4) measure of any gradual or sudden occupant movement. For example, the wearable device data may be utilized to determine all of these estimate either onboard at the vehicle or at an off-board server. Each of these estimates may be utilized to be output to a server of emergency service provider during a vehicle emergency. The wearable device may be able to track and monitor fine tune movement for a specific body part of a user, which a mobile phone or another device may not be able to do. Furthermore, a user may be wearing multiple wearable devices for more accurate fine movement precision.

[0042] To estimate the number of occupants, the following algorithm described below may be provided.

[0043] Assume the initial occupant count (N_occupant) = 0;

[0044] For i = 1 to m:

If at least one of the elements in the following vector is not equal to zero,

[0046] Then N_occupant = N_occupant + 1 ;

[0047] Else N_occupant = N_occupant; [0048] On an opt-in basis, and based on the availability of the appropriate wearable devices, a number of other estimates could be made, including: (1) the current and immediate past heart-rates; (2) the current and immediate past pulse-rates; (3) blood glucose rates, where applicable; (4) other conditions including but not limited to whether or not there are occupants with special needs. For example, the wearable device data may be utilized to determine all of these estimate either onboard at the vehicle or at an off-board server. Each of these estimates may be utilized to be output to a server of emergency service provider during a vehicle emergency.

[0049] The vehicle crash detection modules 305 may include various sensors and modules utilized to determine an emergency situation. Such modules may include impact sensors, cameras, restraint control modules, gyroscopes, accelerometers, air bag sensors, etc. The vehicle crash detection modules may communicate data or information to a wireless connectivity medium 307. Upon an accident or another emergency event occurring, the vehicle crash detection modules 305 may trigger various events to occur (e.g. airbag deployment, seatbelt restraint, etc.). Furthermore, the vehicle crash detection modules may communicate information and data to a wireless connectivity medium 307, which may include a vehicle computer system connected or paired with various nomadic devices to connect with the cloud, to identify that an emergency event has occurred. In response to the data communicated to the vehicle computer system, the VCS may communicate information to nomadic devices (e.g. wearable device) that an emergency event has occurred. The VCS may also send data indicative of the emergency to the wearable devices or request the wearable device to send data related to the occupant or user of the wearable device. The wearable device may send information to the VCS or to off-board servers. In alternative embodiments, the wireless connectivity medium 307 may be the wearable device itself, a mobile phone, an embedded telematics module, etc.

[0050] The wireless connectivity medium 307 may then utilize its communication capability to communicate with the emergency response infrastructure 309. The emergency response infrastructure may include a public-safety answering point (PSAP), emergency medical service (EMS), hospital, fire department, etc. Each of the various servers or establishments within an emergency response infrastructure may utilize data communicated from the vehicle, including those from the wearable devices, to assist occupants during a vehicle emergency. [0051] Figure 4 illustrates an exemplary flow chart for utilizing wearable device data in the event of a vehicle emergency. A vehicle computer system may be in communication with one or more devices inside of the vehicle, including a mobile phone, tablet, or wearable device. The vehicle computer system may pair with wearable devices of one or more occupants 401. The vehicle may allow one or more occupants of the vehicle to connect their wearable device with the vehicle computer system (VCS). The VCS may have the ability to pair with multiple wearable devices in order to communicate data.

[0052] The system may be able to use some form of a wireless (e.g., radio-frequency, ultrasonic, infrared) sensing system to passively (i.e., without requiring any "pairing" action on the part of the occupant) detect the presence of wearable devices. Once the vehicle doors are shut, the sensing system could scan the vehicle interior to detect wearables. In an alternative embodiment, the system could also be programmed to scan the exterior to detect wearables.

[0053] The VCS may monitor wearable device data constantly while in communication with the wearable devices 403. For example, the VCS may send requests to receive wearable device data constantly or at specific intervals. The wearable device may send various data to the VCS, including location of the user, movement data of the user, body information (e.g. blood pressure, heart rate, blood glucose, etc.), and other data related to the user or wearable device. The constant communication between the VCS and the wearable devices may allow the VCS to associate the wearable device data with a specific time and identify of the vehicle environment at that time. For example, during sudden braking or acceleration of the vehicle, the VCS may retrieve the wearable device data to analyze a change in various data, such as movement of a user or relative location. Such monitoring may be utilized during emergency situations.

[0054] The VCS may then monitor for an emergency situation at the vehicle 405. The VCS itself may monitor for an emergency, or it may receive a signal or other incoming data to identify an emergency. In one example, the VCS may be in communication with a restraint control module (RCM) that monitors crash detection, air-bag deployment, or other emergency situations. The VCS may then be in communication with the RCM, or similar vehicle module to receive data indicating an emergency situation. If no emergency situation occurs, the VCS may continue to monitor data and operate as normal. Upon the emergency situation arising, the VCS may react appropriately to activate emergency services, such as FORD SYNC's 911 ASSIST, or other type of services. Furthermore, the wearable device data may be monitored and aggregated to determine changes with respect to the wearable device data before and after an emergency. While a typical vehicle emergency may be a vehicle crash or accident, other situations may arise to be an emergency, such as sudden acceleration or deceleration, or sudden swerving or braking.

[0055] Upon an emergency situation occurring, the VCS may receive the wearable device data from the various wearable devices in the vehicle 407. The VCS may also be in communication with other modules in the vehicle to retrieve their data. The VCS may also communicate with nomadic devices, such as mobile phones or tablets, to retrieve data or utilize functionality during a vehicle emergency. The nomadic devices may communicate solely with the VCS or through the wearable device, which may be paired with the nomadic device. The VCS may retrieve different types of wearable device data, such as occupant-data, location data, movement data, gait data, health data (blood sugar, pulse, hear rate, etc.), user data (e.g. identify or other information about the user), and other data. Different types of wearable devices may send or utilize different types of data to the VCS.

[0056] The VCS may then aggregate data from each individual wearable device 409. A number of wearable devices that collect and send different data to the VCS may be able to utilize each of its own data collectively in a unique, novel fashion. The VCS may then utilize the aggregated data from each of the wearable devices 409. The aggregated data may include all the various data collected by the VCS, including wearable device data and occupant data, vehicle data from other vehicle controllers, vehicle environment data (e.g. data to determine the vehicle' s surrounding environment) from various sensors, and dynamic data from off-board servers (e.g. weather data, traffic data, local event data, etc.). The aggregated data may be utilized in conjunction with data collected from the wearable device data to assist during various vehicle events or conditions.

[0057] The aggregated data may then be utilized by the VCS 411 for various conditions. The

VCS may utilize wearable device data in a number of different fashions. In one example, the occupant-wearable matrix may be utilized to assign a value to the vehicle, as a whole. Based on the value assigned to the vehicle by the occupant-wearable matrix, various conditions or estimates may be determined by the vehicle or an off -board server. The value may be utilized to determine the minimum number of occupants; the possible age-range of occupants; the locations of occupants; and any measure of any gradual or sudden occupant movement. Coordinating the occupant to wearable devices may be utilized for these estimates. Of course, additional data may be utilized to improve accuracy or identify further attributes of the vehicle.

[0058] The VCS may also be utilized to output the data collected from the wearable device

413. The VCS may output the data to an off -board server for further processing. Additionally, and as explained above, the VCS may output the data to an emergency service provider to facilitate a driver or occupant in a vehicle emergency. The VCS may also continuously send data to the emergency service provider in real-time. For example, the VCS may collect real-time wearable device data and determine if movement is occurring at the vehicle with a user. The VCS or off- board server may categorize the movement as normal or severe. Additionally, if there is a lack of movement, the vehicle may categorize lack of movement to identify that a user may be unconscious. The vehicle or cloud may send such categorization of the movement to the emergency responder for the appropriate response.

[0059] While exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms encompassed by the claims. The words used in the specification are words of description rather than limitation, and it is understood that various changes can be made without departing from the spirit and scope of the disclosure. As previously described, the features of various embodiments can be combined to form further embodiments of the invention that may not be explicitly described or illustrated. While various embodiments could have been described as providing advantages or being preferred over other embodiments or prior art implementations with respect to one or more desired characteristics, those of ordinary skill in the art recognize that one or more features or characteristics can be compromised to achieve desired overall system attributes, which depend on the specific application and implementation. These attributes can include, but are not limited to cost, strength, durability, life cycle cost, marketability, appearance, packaging, size, serviceability, weight, manufacturability, ease of assembly, etc. As such, embodiments described as less desirable than other embodiments or prior art implementations with respect to one or more characteristics are not outside the scope of the disclosure and can be desirable for particular applications.