US20160332589A1 - Wearable data management during an incident - Google Patents
Wearable data management during an incident Download PDFInfo
- Publication number
- US20160332589A1 US20160332589A1 US14/713,008 US201514713008A US2016332589A1 US 20160332589 A1 US20160332589 A1 US 20160332589A1 US 201514713008 A US201514713008 A US 201514713008A US 2016332589 A1 US2016332589 A1 US 2016332589A1
- Authority
- US
- United States
- Prior art keywords
- data
- vehicle
- computer
- portable device
- user
- 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.)
- Granted
Links
- 238000013523 data management Methods 0.000 title 1
- 230000033001 locomotion Effects 0.000 claims abstract description 62
- 238000000034 method Methods 0.000 claims description 37
- 238000004891 communication Methods 0.000 description 88
- 230000007246 mechanism Effects 0.000 description 50
- 230000015654 memory Effects 0.000 description 14
- 230000001133 acceleration Effects 0.000 description 9
- 238000005259 measurement Methods 0.000 description 9
- 230000004044 response Effects 0.000 description 5
- 230000001413 cellular effect Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 230000006378 damage Effects 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 230000005355 Hall effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 239000000446 fuel Substances 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000035945 sensitivity Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
- 210000000707 wrist Anatomy 0.000 description 1
Images
Classifications
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R21/00—Arrangements or fittings on vehicles for protecting or preventing injuries to occupants or pedestrians in case of accidents or other traffic risks
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C5/00—Registering or indicating the working of vehicles
- G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
- G07C5/0816—Indicating performance data, e.g. occurrence of a malfunction
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
- B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
- B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
- B60R16/0231—Circuits relating to the driving or the functioning of the vehicle
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R21/00—Arrangements or fittings on vehicles for protecting or preventing injuries to occupants or pedestrians in case of accidents or other traffic risks
- B60R21/01—Electrical circuits for triggering passive safety arrangements, e.g. airbags, safety belt tighteners, in case of vehicle accidents or impending vehicle accidents
- B60R21/013—Electrical circuits for triggering passive safety arrangements, e.g. airbags, safety belt tighteners, in case of vehicle accidents or impending vehicle accidents including means for detecting collisions, impending collisions or roll-over
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R21/00—Arrangements or fittings on vehicles for protecting or preventing injuries to occupants or pedestrians in case of accidents or other traffic risks
- B60R21/01—Electrical circuits for triggering passive safety arrangements, e.g. airbags, safety belt tighteners, in case of vehicle accidents or impending vehicle accidents
- B60R21/015—Electrical circuits for triggering passive safety arrangements, e.g. airbags, safety belt tighteners, in case of vehicle accidents or impending vehicle accidents including means for detecting the presence or position of passengers, passenger seats or child seats, and the related safety parameters therefor, e.g. speed or timing of airbag inflation in relation to occupant position or seat belt use
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R21/00—Arrangements or fittings on vehicles for protecting or preventing injuries to occupants or pedestrians in case of accidents or other traffic risks
- B60R21/01—Electrical circuits for triggering passive safety arrangements, e.g. airbags, safety belt tighteners, in case of vehicle accidents or impending vehicle accidents
- B60R21/015—Electrical circuits for triggering passive safety arrangements, e.g. airbags, safety belt tighteners, in case of vehicle accidents or impending vehicle accidents including means for detecting the presence or position of passengers, passenger seats or child seats, and the related safety parameters therefor, e.g. speed or timing of airbag inflation in relation to occupant position or seat belt use
- B60R21/01512—Passenger detection systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
- G06F17/40—Data acquisition and logging
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C5/00—Registering or indicating the working of vehicles
- G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
- H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M1/00—Substation equipment, e.g. for use by subscribers
- H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
- H04M1/724—User interfaces specially adapted for cordless or mobile telephones
- H04M1/72403—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
- H04M1/72409—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by interfacing with external accessories
- H04M1/72415—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by interfacing with external accessories for remote control of appliances
-
- 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/025—Services making use of location information using location based information parameters
- H04W4/027—Services making use of location information using location based information parameters using movement velocity, acceleration information
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R21/00—Arrangements or fittings on vehicles for protecting or preventing injuries to occupants or pedestrians in case of accidents or other traffic risks
- B60R2021/0027—Post collision measures, e.g. notifying emergency services
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C2209/00—Indexing scheme relating to groups G07C9/00 - G07C9/38
- G07C2209/60—Indexing scheme relating to groups G07C9/00174 - G07C9/00944
- G07C2209/63—Comprising locating means for detecting the position of the data carrier, i.e. within the vehicle or within a certain distance from the vehicle
Definitions
- Response to an incident such as a vehicle collision may be improved by the timely availability of data.
- Information such as where an occupant was located in the vehicle at the time of the incident, the acceleration experienced by the occupant during the incident, and the location of the occupant following the incident can be of critical importance during an initial response.
- FIG. 1 is diagram of an exemplary system for determining location(s) of one or more occupants of a vehicle using a portable device.
- FIG. 2 is a top view of an exemplary vehicle including a communications mechanism for communicating with portable devices.
- FIG. 3 is a further top view of the exemplary vehicle of FIG. 2 , including the communications mechanism, illustrating location zones.
- FIG. 4 is a diagram of an exemplary process for managing wearable device data during and after an incident.
- portable devices 20 including portable devices 20 that are wearable by a human vehicle occupant, can be used as disclosed herein to provide additional and timelier data to emergency responders following an incident compared to what is presently available.
- Communications from one or more portable devices 20 may be used by a computer 100 in a vehicle 25 to determine where, within the vehicle 25 , a user of the portable device 20 was located in the vehicle 25 prior to the incident.
- One or more movement sensors 90 in each portable device 20 may additionally provide data indicating acceleration experienced by the user during the incident.
- the computer 100 based on communications with the portable device 20 , may determine a location of the user of the portable device 20 .
- the movement sensors 90 in the portable device 20 may further be used to determine a user state, e.g., whether the user is walking, standing, sitting, etc.
- the vehicle computer 100 may, based on data from the vehicle 25 Restraints Control Module 110 , or one or more vehicle sensors 115 , 120 , 125 , 130 , determine that an incident is in progress or imminent. Based on the determination, the computer 100 may request data from the one or more portable devices 20 such as movement data for a period of time. The computer 100 may receive the data from each portable device 20 and store the data. The computer 100 may, e.g., transmit the data to a remote server 30 . If the remote server 30 is not accessible, the computer 100 may transfer the collective set of data from all the portable devices 20 to memory in one or more of the portable devices 20 . Further, the computer 100 may download data related to the incident to the portable device 20 .
- data such as a user location in the vehicle 25 at the time of an incident, acceleration experienced by the user of the portable device 20 during the incident, and user state following the incident, may be made available to responders to the incident.
- responders may access the data from the remote server 30 .
- responders such as medical practitioners in a hospital, may be able to access data downloaded to the portable device 20 worn by a user.
- a system 10 includes a remote keyless entry device which may be a traditional fob or, e.g., a phone based remote entry telematics application (hereinafter fob) 15 , one or more portable devices 20 , a vehicle 25 , a server 30 and a network 35 .
- the fob 15 and portable device 20 may be communicatively coupled with the vehicle 25 .
- the portable device 20 may be, e.g., a wearable device with or without cellular capability, a mobile telephone, a tablet, etc., and may be directly communicatively coupled with the vehicle 25 , or indirectly coupled with the vehicle 25 , e.g., through another portable device 20 .
- the vehicle 25 may further be communicatively coupled with the server 30 via the network 35 .
- the fob 15 is configured, i.e., includes known mechanisms such as programming in a computer 60 and hardware such as a transceiver 65 for wireless communications, to send messages to the vehicle 25 , e.g., commands or instructions controlling operations of the vehicle 25 .
- the fob 15 may send commands to the vehicle 25 instructing the vehicle 25 to lock or unlock doors, open a trunk lid or other hatch, start the ignition, etc.
- the fob 15 further generally includes a user interface 70 .
- the fob 15 may be an app on the portable device 20 which sends these same commands to the remote sever 30 or network 35 which may then send commands to the vehicle 25 instructing the vehicle 25 to lock or unlock doors, open a trunk lid or other hatch, start the ignition, etc.
- One or more fobs 15 may be paired with a vehicle 25 .
- a fob 15 may be programmed with a specific identification code and the vehicle 25 may include a list of identification codes authorized to send commands to the vehicle 25 .
- the vehicle 25 may look for one or more identification codes upon receiving messages, and determine if the fob 15 is authorized.
- the fob 15 computer 60 includes a processor and a memory.
- the processor is programmed to execute programs stored in the memory, e.g., to send commands to the vehicle 25 .
- the transceiver 65 is configured to transmit radio frequency (RF) signals to, and optionally receive RF signals from the vehicle 25 .
- RF radio frequency
- typical fob 15 frequencies of operation for one-way communication are 315 MHz or 433 MH and for two-way communications are 902 MHz or 868 MHz.
- the vehicle 25 may send commands to Fob 15 using Low Frequency (LF) transmissions at frequencies of 125 kHz or 135 kHz.
- LF Low Frequency
- the fob 15 user interface 70 includes one or more input mechanisms and may include a display.
- the input mechanisms may be buttons, a touch screen display, a gesture sensing device, etc., for receiving input from a user.
- the display may include an LCD display, LED display, buzzers speakers, haptic feedback, etc., for providing information to the user.
- the vehicle 25 may be equipped with a passive entry system, e.g., that sends a message to fobs 15 proximate to the vehicle 25 and looks for a response from a paired fob 15 .
- a passive entry system e.g., that sends a message to fobs 15 proximate to the vehicle 25 and looks for a response from a paired fob 15 .
- Other possible systems to unlock/start/etc. the vehicle 25 include a keypad, remote entry mechanical key, telematics unlock system, etc.
- a portable device 20 may be, e.g., a wearable portable device 20 or a mobile portable device 20 .
- a wearable portable device 20 may include a connectivity product such as a “smart” watch, a fitness band, smart clothing, jewelry, etc.
- a mobile portable device 20 may include, e.g., a mobile telephone, tablet, laptop, etc. Some wearable portable devices 20 may include built-in modems or full cellular capability. Other wearable portable devices 20 may need to link or pair, e.g., with a mobile portable device 20 such as a mobile telephone, tablet, laptop, etc. in order to establish communications with the vehicle 25 .
- Each portable device 20 typically includes a computer 75 , a transceiver 80 , and an interface 85 .
- the portable device 20 may further include one or more sensors 90 , discussed further below.
- Each portable device 20 may be associated with a user.
- the portable device 20 may include a user profile 101 , and send the user profile 101 to the vehicle 25 when the portable device 20 initiates communication with the vehicle 25 .
- the portable device 20 may have been paired with the vehicle 25 , for example, via a synchronization system in the vehicle 25 .
- the vehicle 25 may maintain a user profile 101 associated with the paired (synchronized) portable device 20 .
- the user profile 101 may be a set of data associated with the user.
- the user profile 101 may include data such as user preferred vehicle settings (e.g., seat settings, minor settings, temperature settings, radio station), user characteristics (e.g., height, weight, age, medical conditions), routines (typically drives to work on weekday mornings), etc.
- the user profile 101 may be maintained by a computer 100 on the vehicle 25 .
- one or more portable devices 20 may maintain a user profile 101 identified with the user.
- the user profiles 101 maintained on the portable devices 20 may be accessed by the vehicle 25 and combined with the data in the vehicle 25 user profile 101 .
- the data in the user profile 101 may be entered by the user via an interface on the vehicle 25 or one of the portable devices 20 associated with the user, determined by the computer 100 in the vehicle 25 , downloaded from other computing devices, e.g., the server 30 , etc.
- the portable device 20 may be configured for short range, wireless communication with the vehicle 25 .
- the portable device 20 transceiver 80 may be a BLUETOOTH® transceiver capable of forming links with other BLUETOOTH transceivers.
- One or more portable devices 20 and the vehicle 25 may accordingly exchange messages.
- a portable device 20 may transmit a signal including, e.g., identification data (identifying the type of user device, the identity of a user, etc.), movement data, etc. to the vehicle 25 .
- identification data identifying the type of user device, the identity of a user, etc.
- movement data etc.
- other suitable wireless communication protocols e.g., NFC, IEEE 802.11 or other protocols as may be known, may be used for communication between the portable devices 20 and the vehicle 25 .
- a portable device 20 may be configured to link with other portable devices 20 .
- a first portable device 20 may be a smart watch, and a second portable device 20 may be a mobile telephone.
- the first portable device 20 may link with the second portable device 20 and exchange data with the second portable device 20 ; the first and second portable devices 20 may be associated with a same user.
- the first portable device 20 may include biometric sensors 90 to measure the heart rate of the user and transmit the heart rate to the second portable device 20 .
- the second portable device 20 may output the heart rate data to the user via the second portable device 20 interface 85 .
- BLUETOOTH communication links typically operate at frequencies from 2402-2480 MHz.
- other suitable wireless communication protocols such as are known may alternatively or additionally be used to form the communication links with other portable devices 20 .
- portable device 20 sensors 90 may include accelerometers, g-sensors, gyroscopes, compasses, light sensors, cameras, etc.
- the sensors 90 may measure movements of the portable device 20 and output movement data that the portable device 20 may then communicate to the vehicle 25 .
- the vehicle 25 may determine, based on the movement data, e.g., that the user of the portable device 20 has opened a door of the vehicle 25 .
- the vehicle 25 is generally a land-based vehicle having three or more wheels, e.g., a passenger car, light truck, etc.
- the vehicle 25 accordingly generally has a front, a rear, a left side and a right side, wherein the terms front, rear, left and right are understood from the perspective of a user of the vehicle 25 seated in a driver's seat in a standard operating position, i.e., facing a steering wheel 160 ( FIG. 2 ).
- the vehicle 25 includes the computer 100 including a processor and a memory.
- the memory includes one or more forms of computer-readable media, and storing instructions executable by the processor for performing various operations, including as disclosed herein.
- the computer 100 may include and/or be communicatively coupled to more than one other computer, e.g., Restraints Control Module 110 , steering sensors 115 , door sensors 120 , seat sensors 125 , other sensors 130 and controllers 135 .
- the vehicle 125 computer 100 is further typically communicatively coupled with a communications mechanism 145 configured for wireless communications with on-board and external wireless devices including the fob 15 , portable device 20 , remote server 30 and network 35 .
- the computer 100 is generally programmed and arranged for communications on a controller area network (CAN) bus or the like.
- the computing device 100 may also have a connection to an onboard diagnostics connector (OBD-II), e.g., according to the J1962 standard.
- OBD-II onboard diagnostics connector
- the computer 100 may transmit messages to various devices in a vehicle and/or receive messages from the various devices, e.g., controllers, actuators, sensors, etc.
- the computer 100 may be configured for communicating, e.g., with one or more remote servers 30 , with one or more fobs 15 , with one or more portable devices 20 , with the Restraints Control Module 110 , and/or with the network 35 .
- the steering sensors 115 may be steering angle sensors, steering torque sensors, motor sensors associated with power steering assist, etc., known to provide data related directly or indirectly to steering operations.
- a steering sensor 115 may be a steering angle sensor which senses a rotation of a vehicle 25 steering wheel 160 , and communicates the steering wheel 160 rotation data to the computing device 100 .
- a steering sensor 115 may sense rotation of a motor providing power assist for steering operations, and provide the motor rotation data to the computer 100 .
- Door sensors 120 may be mechanical switches that are activated by the door, proximity sensors, hall-effect sensors, or the like, such as are known, that indicate if a door is open or closed and that provide door status data to the computing device 100 .
- Seat sensors 125 may include a variety of sensors including occupancy sensors and seat position sensors such as are known.
- the seat sensors 125 may, e.g., determine whether a user is occupying a seat, determine the weight of the user, and communicate the determined weight to the computer 100 . Further, the seat sensors 125 may detect either directly or indirectly the position of a seat, angle of a seat back, height of a headrest, etc., and provide data to the computer 100 with regard to one or more of these settings. Yet further, the computer 100 , may, e.g., upon identifying a seat user, adjust settings to a user profile associated with the user.
- the vehicle 25 may include one or more other sensors 130 .
- the other sensors 130 may include, as non-limiting example only, cameras, optical sensors, radar, microphones, proximity sensors, ultrasonic sensors, pressure sensors, accelerometers, g-sensors, gyroscopes, temperatures sensors, current sensors, voltage sensors, infrared sensors, capacitive sensors, etc.
- the sensors may include processors and memories, and may be configured to communicate with and send data to the computer 100 , e.g., via a CAN bus or the like.
- the vehicle 25 may also include one or more controllers 135 for controlling vehicle 25 components.
- the one or more controllers 135 may include known controllers, as non-limiting examples, a seat controller, a power steering controller, a door lock controller, a door latch controller, a climate controller, a mirror adjustment controller, a seatbelt controller, a climate controller, a brake controller, etc.
- Each of the controllers 135 may include respective processors and memories, one or more actuators, and one or more sensors, as is known.
- the controllers 135 may be configured to receive instructions from the computing device 100 and control an actuator based on such instructions. For example, a door lock controller 135 may receive an instruction to unlock a door and may cause an actuator to unlock a lock associated with the door.
- the controller 135 may include sensors.
- the sensors may, e.g., detect the action of the actuator.
- the door lock controller 135 may detect the lock being in an unlocked condition.
- the controller 135 may provide data regarding the status of the lock to the computer 100 .
- the vehicle 25 may include a restraints control module (RCM) 110 .
- the RCM 110 may include, e.g., g-sensors, and may further receive input from other sensors 130 such as g-sensors, gyroscopes, pressure sensors, etc., in the doors or other areas within the vehicle 25 .
- the RCM 110 may, based on the input received the RCM 110 sensors and other sensors 130 , etc., identify or anticipate an incident.
- the RCM 110 may broadcast this information to the computer 100 , other vehicle components including vehicle controllers 135 , one or more remote servers 30 , etc.
- the information may be broadcast via a CAN network, or via a dedicated communications link.
- a vehicle 25 may further include a communications mechanism 145 for wireless communications with vehicle on-board and external devices configured for wireless communications.
- the communications mechanism 145 may include a computer 146 having a processor and a memory, and a measurement unit 147 .
- the communications may be direct communications, i.e., between a transceiver in the communications mechanism 145 and a transceiver in the wireless device, or indirect communications, e.g., via a network such as a network 35 .
- the communications block 145 may generally be configured to support communications with 1-Way (typically 315 MHz or 433 MHz), or 2-Way (typically 902 MHz or 868 MHz) remote keyless entry (RKE) systems, passive-entry passive-start (PEPS) systems (125 kHz LF challenge and 315 MHz or 433 MHz response), near field communications (NFC) (typically 13.56 MHz), Bluetooth systems (2402-2408 MHz), vehicle-to-vehicle (V2V) systems and vehicle-to-infrastructure (V2I) systems in the Dedicated Short Range Communications (DSRC) Band (5.9 GHz), portable devices in the cellular bands, Wi-Fi (typically 2.4 GHz or 5 GHz bands), GPS systems (1575.42 MHz and 1227.6 MHz), etc.
- 1-Way typically 315 MHz or 433 MHz
- 2-Way typically 902 MHz or 868 MHz
- RKE remote keyless entry
- PEPS passive-entry passive
- protocols that the communication block 145 may support include Bluetooth, NFC, DSRC, 3G UMTS protocols as defined by the 3GPP standards body, 4G LTE protocols as defined by the 3GPP standards body, Wi-Fi 802.11 protocols as defined by IEEE, W-Max 802.16 protocols as defined by IEEE, or other suitable wireless communication protocols.
- the communications mechanism 145 may be configured to communicate with the fob 15 , the portable device 20 and, via the network 35 , with a remote server 30 .
- the communications mechanism 145 may be configured to establish communications with one or more portable devices 20 .
- the computer 100 may instruct the communications mechanism 145 to search for and establish communications with portable devices 20 proximate to, e.g., within 3 meters of, the vehicle 25 .
- the communications mechanism 145 may search for all portable devices 20 proximate to the vehicle, or, e.g., a specific list of portable devices 20 associated with known users of the vehicle 25 .
- the portable devices 20 may then respond to the communications mechanism 145 .
- the communications mechanism 145 may, e.g., periodically search for, and establish communications with, portable devices 20 proximate the vehicle 25 .
- the communications block 145 may send instructions requesting user identification data, movement data, etc. from the portable devices 20 .
- the computer 100 may specifically establish communications directly or indirectly with wearable portable devices 20 .
- the communications mechanism 145 may determine a strength of signals received from respective portable devices 20 .
- the communications mechanism 145 may include a measurement unit 147 .
- the measurement unit 147 may receive signals from the portable devices 20 , and measure signal strength in a known manner. When applicable, e.g., when seeking to determine a location of a user, the measurement unit 147 should measure the signal strength of the signal transmitted from the wearable portable device 20 and not the signal transmitted from the supporting mobile portable device 20 . The measurement unit 147 may provide this information to the computer 100 .
- the strength of a signal received from a portable device 20 may be an indication of the distance (also referred to herein as range) of the portable device 20 from the communications mechanism 145 .
- This information may be used, particularly in the case of a wearable portable device 20 , to determine a boundary or zone where a user of the wearable portable device 20 , is located within the vehicle 25 .
- the measurement unit 147 may determine these zones with one transceiver antenna. Alternatively, two or more antennas may be used if, e.g., they exist for other features.
- the vehicle 25 communications mechanism 145 may further be configured to communicate, e.g., over a network 35 with a remote server 30 .
- the vehicle 25 may be able to transmit a message to the remote server 30 indicating that the vehicle 25 was involved in an incident, and may be able to send additional information such as the location of the vehicle 25 .
- the vehicle 25 is linked to one or more portable devices 20
- the vehicle 25 via the communications mechanism 145 may additionally or alternatively be able to send user status information, such as the user's vital signs, to the remote server 30 .
- the network 35 represents one or more mechanisms by which the vehicle 25 may communicate with remote computing devices, and may be one or more of various wired or wireless communication mechanisms, including any desired combination of wired (e.g., cable and fiber) and/or wireless (e.g., cellular, wireless, satellite, microwave and radio frequency) communication mechanisms and any desired network topology (or topologies when multiple communication mechanisms are utilized).
- Exemplary communication networks include wireless communication networks, local area networks (LAN) and/or wide area networks (WAN), including the Internet, providing data communication services.
- the vehicle 25 computer 100 may receive a signal from the fob 15 to unlock the vehicle 25 , or recognize another trigger event for starting a user location identification process. For example, a user of the vehicle 25 may activate the fob 15 , and the fob 15 may send an unlock command to the vehicle 25 . The vehicle 25 computer 100 may receive the unlock signal, and initiate a process to identify locations of one or more users in the vehicle 25 .
- a sensor 130 may detect a user grabbing or touching a door handle to pull on the door handle with the intent to open the door, and based on the detection, the computer 100 may initiate and establish communications with fobs 15 proximate the vehicle 25 to authorize unlocking a door. The computer 100 may determine that one or more of the fobs 15 is an authorized fob 15 for the vehicle 25 , e.g., in a manner as described above. Conversely, if the door was already unlocked the trigger of sensor 130 may still be used to inform computer 100 that a user is about to open a door.
- the computer 100 may also receive an input from a key pad on the vehicle 25 , a door or global unlock event activated by a mechanical key, an ignition activated by a mechanical key, from a telematics system, etc. that is identified as a trigger event for initiating a user location identification process. Still further, the computer 100 could initiate the user location identification process periodically, based on a timer, etc.
- the computer 100 may initiate a process to instruct the portable device 20 , which may be a wearable portable device 20 , to record g-sensor data for a specified period to identify hand motions and then monitor all vehicle 25 door sensors 120 to determine where users entered the vehicle 25 .
- the computer 100 may monitor g-sensor movements of the portable devices 20 associated with vehicle 25 users, and based on the movement data identify a device 20 , and hence a user, that may be associated with opening a particular vehicle 25 door. In the case of only one door opening and only one portable device 20 being identified with a signature movement data pattern, it may be possible to conclude who has entered that door. In cases where more doors have opened than there are detected portable devices 20 , additional data is required to predict the user's location.
- the computer 100 may further use the movement data as an indication of where the user is located in the vehicle 25 after entering the vehicle 25 .
- the vehicle 25 may include a steering wheel 160 , front left door 165 , front right door 170 , rear left door 175 , rear right door 180 , and rear hatch door 181 .
- the vehicle 25 may further include the communications mechanism 145 .
- the communications mechanism 145 may be located in a front center portion of the vehicle 25 .
- a portion of the communication mechanism 145 used to establish communication with the portable devices 20 may be located in the center front portion of the vehicle 25 , and other portions of the communications mechanism 145 may be located in one or more other locations in the vehicle 25 .
- the portion of the communications mechanism 145 used to establish communications with the portable devices 20 should be strategically placed such that the strength of a signal received from a respective portable device 20 is indicative of a definable zone within the vehicle 25 .
- the communications mechanism 145 may include a measurement unit 147 , and may be configured to establish communications with portable devices 20 .
- the measurement unit 147 may be configured to measure the strength of signals received from the portable devices 20 , and to report the strength of the signals from the respective portable devices 20 to the computer 100 of the vehicle 25 .
- the computer 100 Upon identifying a trigger event for initiating a user location identification process as described above, the computer 100 , based on the trigger event may activate the communications mechanism 145 , and instruct the communications mechanism 145 to search for and establish communications with portable devices 20 proximate the vehicle 25 .
- the computer 100 may limit the search to previously paired portable devices 20 .
- the measurement unit 147 should measure the signal strength of the signal transmitted from the wearable portable device 20 and not the signal transmitted from the supporting mobile portable device 20 .
- the computer 100 may find and establish communications (via the communications mechanism 145 ) with portable devices 20 a - 20 h which are determined to be wearable portable devices 20 .
- the computer 100 may command each of the wearable portable devices 20 a - 20 h to send movement data associated with the respective wearable portable devices 20 a - 20 h to the computer 100 .
- the computer 100 may determine, e.g., that the user of wearable portable device 20 a has opened a left side door 165 , 175 .
- Particular wrist movements e.g., one or more of twisting counter-clockwise to grab a door handle, swinging up and to the left to open a door handle, swinging to the left on an arc similar to the arc of a door handle on a left handed door being opened, may be indicative of opening a left side door 165 , 175 of the vehicle 25 .
- the computing device 100 may determine, e.g., that a user of wearable portable device 20 d also opened a left side door 165 , 175 , and further, in a similar manner, by identifying gestures associated with a right side door, that e.g., the user of wearable portable device 20 e has opened a right side door 170 , 180 .
- movements indicating a door opening In addition to identifying movements of a wearable portable device 20 worn by a user on an arm used for opening a door, other types of movements may be identified as movements indicating a door opening. For example, for a user opening a right door 170 , 180 with their right arm, and wearing a wearable portable device 20 on their left arm, particular movements, for example the swinging of the left arm around the body during door opening (or entering the vehicle 25 ) may be indicative of a right door 170 , 180 opening event. Other movements of wearable devices 20 may be determined to be characteristic of opening a vehicle 25 door, 165 , 170 , 175 , 180 , 181 . Further, movements that are characteristic of closing a vehicle 25 door 165 , 170 , 175 , 180 may indicate a user having entered a left door or a right door.
- a determination that a user has opened a particular vehicle 25 door 165 , 170 , 175 , 180 , 181 may be performed by the computer 100 . Additionally or alternatively, the determination may be made, e.g., by the computer 75 in the respective wearable portable device 20 , and the results communicated to the computer 100 . Additionally or alternatively, the determination may be made by another computer communicatively coupled to the computer 100 .
- Additional information regarding the location of users within a vehicle 25 may be determined based on a received signal strength of signals received by the communications mechanism 145 from portable devices 20 .
- the portable devices 20 may be wearable portable devices 20 .
- the vehicle 25 may be divided into three or more zones based on distance from the communications mechanism 145 ; a first zone 185 , a second zone 190 and a third zone 195 .
- the zones 185 , 190 , 195 may, e.g., be radially shaped around a receiver portion, e.g., an antenna, in the communications mechanism 145 .
- the receiver portion in the communications mechanism 145 may be directional, i.e., have a reception sensitivity that is greater in some directions than others, and the zones 185 , 190 , 195 may be defined by the directionality of the receiver portion.
- the zones 185 , 190 , 195 may extend beyond the vehicle 25 and/or the communications mechanism 145 may receive signals from outside of the defined zones, 185 , 190 , 195 .
- the communications mechanism 145 may be able to receive a signal from the portable device 20 that is beyond the third zone 195 .
- the zones 185 , 190 , 195 may form a set of concentric circles around the receive portion, and include areas outside of the vehicle 25 .
- the communications mechanism 145 may determine, based on the RSSI of the portable device 20 , that a portable device 20 is within range to communicate with the communications mechanism 145 , but outside of the third zone 195 .
- the portable devices 20 a and 20 b may be located in the first zone 185 .
- the portable devices 20 c, 20 d, 20 e may be located in the second zone 190
- the portable devices 20 f, 20 g, 20 h may be located in the third zone 195 .
- each of the portable devices 20 a - 20 h may be a wearable portable device 20 .
- the computing device 100 may establish communications via the communications mechanism 145 with each of the portable devices 20 a - 20 h.
- the communications mechanism 145 may be configured to measure received signal strength of the signals received from each of the portable devices 20 a - 20 h, and provide a received signal strength indication (RSSI) such as is known to the computer 100 respectively for each of the portable devices 20 a - 20 h.
- RSSI received signal strength indication
- the computer 100 may determine the zone in which each of the portable devices 20 a - 20 h is located. For example, if the RSSI is greater than or equal to a first predetermined threshold and less than a second predetermined threshold, the computing device may determine that the associated portable device 20 is located within the third zone 195 . If the RSSI is greater than or equal to the second predetermined threshold and less than a third predetermined threshold, the computer 100 may determine that associated portable device 20 is located in the second zone 190 . If the RSSI is greater than or equal to the third predetermined threshold, the computer 100 may determine that the associated portable device 20 is located in the first zone 185 .
- the first, second and third predetermined thresholds may be determined empirically based on representative portable devices 20 , the location of the communications mechanism 145 , the type of vehicle 25 , etc. In the example according to FIG. 3 , the computer 100 would determine that portable device 20 a - 20 b are in the first zone 185 , devices 20 c - 20 e are in the second zone 190 and devices 20 f - 20 h are in the third zone 195 .
- the computer 100 can be programmed to determine the driver and front passenger of the vehicle 25 .
- the computer 100 may further determine that the user of the portable device 20 a is located in a front left (driver's) seat of the vehicle 25 .
- the computer 100 may determine that the user of the portable device 20 b is in a front passenger seat.
- the same process for locating the driver and front row passenger can also be applied to right hand drive vehicles by reversing the relationships of detected door opening events.
- the vehicle may instruct portable devices 20 to start recording, then data generated by the sensors 90 of portable devices 20 (mobile data) may be collected by the vehicle 25 computer 100 and distributed, e.g., to the remote server 30 .
- An incident may include, e.g., a collision with an object or another vehicle, running off of the road, a severe braking event sufficient to trigger a fuel cut-off event, a rollover event etc.
- An incident may be determined to be imminent if, e.g., the vehicle 25 computer 100 , determines, based on a current vehicle status, i.e., speed, range from other objects, road condition, location on a road, etc., that an incident is unavoidable, or will occur within a predetermined time, e.g., three seconds or if computer 100 is advised by the restraints control module 110 of the same imminent condition.
- a current vehicle status i.e., speed, range from other objects, road condition, location on a road, etc.
- the mobile data may include, e.g., movement data representing movement of the portable device 20 , location data of the one or more portable devices 20 , biometric data of a user wearing the one or more portable devices 20 , identification data associated with the one or more portable devices 20 , etc.
- the mobile data may be collected and stored, together with an identifier for a user and/or device 20 associating the portable device 20 or user with the mobile data.
- the mobile data, together with other data collected by the vehicle 25 may additionally be transmitted to a remote server 30 for further processing.
- the mobile data and vehicle data may be transmitted to a remote server 30 associated with a hospital or emergency response center, which may use the mobile data and vehicle data to determine the nature of an incident and the injuries that may have been incurred by the vehicle 25 users and other incident victims.
- Mobile data may include identification of the portable device 20 , identification of the type of portable device 20 , e.g., smart watch, fitness band, mobile telephone, etc., movement data, biometric data of the user, timing data, location data, e.g., location based on GPS data, a user profile 101 , vehicle make and model, vehicle VIN, license plate of vehicle in which they rode, name of person associated with the portable device 20 if available, etc.
- the timing data from the portable device 20 may be in the form of a date and time stamped or encoded with some other form of time reference to allow synchronous comparison of data from the multiple portable devices 20 .
- Vehicle data may include, as non-limiting examples only, vehicle state data such vehicle speed, vehicle acceleration, vehicle location, e.g., based on GPS data, etc. Vehicle data may further include data from the sensors 115 , 120 , 125 , 130 and/or controllers 110 , 135 indicating steering angle, seat position, seat occupancy, door status, brake status, airbag deployment status, engine status, seatbelt status, etc. Still further, vehicle data may include user related data such as the number and location of vehicle users, user profiles 101 , etc.
- the vehicle 25 computer 100 may be programmed to determine, e.g., as is known, that an incident is in progress or imminent and send commands to vehicle components including the communications mechanism 145 .
- the computer 100 may further be programmed to determine an incident reference time identifying a time the incident occurred or will occur.
- the vehicle 25 may receive data from one or more vehicle steering sensors 115 , door sensor 120 , seat sensor 125 , other sensors 130 and/or the controllers 135 .
- the vehicle 25 other sensors 130 may include accelerometers, gyroscopes, pressure sensors, cameras, radar, ultrasonic sensors etc. which may provide data to the vehicle computer 100 .
- the vehicle 25 may, e.g., as is known, determine that an incident is in progress or is imminent.
- the computer 100 may send messages to the vehicle controllers 135 , e.g., one or more airbag controllers 110 , 135 to deploy airbags, one or more seatbelt controllers 135 to increase tension to seatbelts, etc.
- the computer 100 may further be programmed to send, via the communications mechanism 145 , one or more messages to one or more portable devices 20 , e.g., portable devices 20 identified as being located in the vehicle 25 at the reference time mentioned above.
- the message may indicate the incident reference time, and instruct the one or more portable devices 20 to send data from portable device 20 sensors 90 to the vehicle 25 computer 100 .
- the computer 100 may communicate with portable devices 20 identified as wearable devices, and request movement data, such as data collected from 3-axis accelerometers 90 included in the wearable portable devices 20 , during a predetermined time period.
- the predetermined time period may be defined, e.g., as starting one second before the reference time and extending for two seconds after the reference time, or for some other time period.
- the computer 100 may be programmed to request data such as the location data of the portable device 20 at the reference time.
- the computer 100 may further request biometric data, such as vital signs of the user of the portable device 20 .
- the computer 100 may associate data stored in the vehicle 25 , for example, the current location of the user of the portable device 20 , with the data received from the portable device 20 .
- the computer 100 may generate data, e.g., unique or substantially unique identifiers, associating, for example, movement data, location data, etc. with a particular portable device 20 and/or particular user.
- the identifiers may be included in a set of data referred to herein as a tag that may also include time stamps indicating when the data was generated relative to the reference time.
- the computer 100 may store the mobile data, including tags, in a memory associated with the computer 100 .
- the computer 100 may request movement data, identification data, biometric data, location data (to the extent available), etc. from the portable device 20 for one or more additional predetermined time periods.
- the one or more additional predetermined time periods could include three-second windows that occur every 10 seconds, for one minute following the reference time.
- the computer 100 could determine, based on a received signal strength, e.g., a location of the user of the portable device 20 following the incident, and could determine, for example, if the user has (or may have) been thrown from the vehicle 25 . For example, if, prior to the incident, the computer 100 determined that the user of the portable device 20 was in zone 185 , and after the incident, the computer 100 determined that the user is in zone 195 , the computer 100 may further determine that the user was thrown from the vehicle 25 .
- a received signal strength e.g., a location of the user of the portable device 20 following the incident
- the computer 100 may further determine that the user was thrown from the vehicle 25 .
- the computer 100 may further make the mobile data, along with data collected from the one or more vehicle sensors 115 , 120 , 125 , 130 and/or one or more vehicle controllers 110 , 135 , etc. available to other computers, for example the remote server 30 .
- the mobile data and vehicle data may, in this manner, be made available, for example, to emergency responders to the incident, or to product developers to improve safety features of newly developed vehicles.
- location data and movement data at the reference time may provide information related to the type, severity, etc. of an incident.
- Location data and movement data at a time after the reference time may provide information related to a condition of a user. For example, location data showing a portable device 20 outside the vehicle 25 may indicate that the user was thrown from the vehicle 25 during the incident. Movement data showing that the portable device 20 is moving at a time following the reference time may indicate that the user is walking, etc.
- the computer 100 may further initiate downloads of data to one or more portable devices 20 .
- the vehicle 25 computer 100 may collect vehicle data from the vehicle sensors 115 , 120 , 125 , 130 and vehicle controllers 110 , 135 related to an incident.
- the computer 100 may further collect mobile data from one or more portable devices 20 related to the incident. This data may include video or still frames from vehicle mounted cameras.
- the computer 100 may then download a portion or all of the data to a particular portable device 20 .
- the downloaded data may be stored by the portable device 20 , such that the data is available, for example, to a medical practitioner treating the user following the incident.
- the computer 100 may identify data, such as vehicle acceleration data at the reference time, movement data from portable devices 20 at the reference time, portions of the vehicle 25 damaged during the collision, etc., that is indicative of the condition of a user of a particular portable device 20 .
- vehicle acceleration data could indicate that the vehicle 25 was hit from the rear.
- Additional vehicle data could indicate that a rear portion of the vehicle was crushed, and that airbags were deployed for a first user driving the vehicle 25 and a second user in a front passenger seat.
- Movement data from the portable devices 20 worn respectively by the first and second users could indicate that acceleration was along a front-rear axis of the vehicle 25 and that both the first and second user were still in the vehicle 25 following the incident.
- the computer 100 may identify data that may be relevant to the condition of each of the first and second users such as acceleration data, airbag deployment data, etc., and download the data identified as relevant to the portable device 20 of the user.
- FIG. 4 is a diagram of an exemplary process 300 for managing data collected by one or more portable devices 20 and the vehicle 25 when it is determined by the vehicle 25 that an incident is in progress or imminent.
- the process 300 starts in a block 305 .
- the vehicle 25 computer 100 receives vehicle data from one or more vehicle sensors 115 , 120 , 125 , 130 and/or from one or more controllers 110 , 135 .
- the sensors 115 , 120 , 125 , 130 may include sensors such as accelerometers, gyroscopes, pressure sensors, cameras, radar systems, ultrasonic sensors, etc.
- the controllers 110 , 135 may include controllers such as seatbelt controllers, airbag controllers, etc.
- the process 300 continues in the block 310 .
- the computer 100 determines, e.g., in a known manner, based on the received data, that an incident is in progress or is imminent.
- the computer 100 may further determine additional information regarding the incident, such as the type and severity of the incident and may generate instructions to vehicle controllers 135 to respond to the incident.
- the computer 100 may establish a reference time which may be used as a reference for responding to the incident and tagging data related to the incident.
- the process 300 continues in the block 315 .
- the computer 100 instructs one or more portable devices 20 to send mobile data associated with the respective portable device 20 .
- the computer 100 may send an instruction to the portable device 20 indicating that the incident is in progress or imminent and include the reference time related to the incident.
- the computer 100 may instruct the portable device 20 to send location data, movement data, identification data, etc. associated with the portable device 20 during a predetermined time period related to the reference time.
- the portable device 20 may collect data including data from the sensors 90 , and send a message to the computer 100 including the mobile data.
- the process 300 continues in a block 320 .
- the computer 100 may receive mobile data from one or more portable devices 20 . As described above, the computer 100 may further receive a received signal strength indication (RSSI) from the communications mechanism 145 . Based on the RSSI, as described above, the computer 100 may determine a zone 185 , 190 , 195 where the portable device 20 is located. The process 300 continues in a block 325 .
- RSSI received signal strength indication
- the computer 100 may store and tag the mobile data.
- the computer 100 may receive location and movement data from the portable device 20 .
- the computer 100 may generate one or more tags for the location and movement data.
- the tags may indicate, e.g., a time when the location or movement data was generated, a portable device 20 which generated the location or movement data, a user associated with the portable device 20 that provided the data, etc.
- the computer 100 may then store the data, together with the generated tags, in a memory, e.g., a memory associated with the computer 100 .
- the process 300 continues in a block 330 .
- the computer 100 may send data related to the incident to a remote computer, e.g., the remote server 30 .
- the data may include vehicle data, such as the data received in block 305 related to the incident, and mobile data such as the data received in block 320 .
- the data may further include tags generated by the computer 100 as discussed in block 325 .
- the process 300 continues in a block 335 .
- the computer 100 may further download vehicle data and/or mobile data to one or more portable devices 20 .
- the computer 100 may identify data, e.g., data showing vehicle 25 acceleration during the incident, data such as data from pressure sensors 30 indicating damage to a particular section of the vehicle 25 , etc., which may be helpful to a healthcare practitioner treating the user of the portable device 20 .
- the computer 100 may transmit the data to the portable device 20 including instructions to store the data.
- the data may include mobile data from other portable devices 20 , or mobile data from the portable device 20 receiving the data, with the data organized and tagged in order to be accessible to the healthcare practitioner.
- the process 300 continues in a block 340 .
- the computer 100 may determine if the incident is still in progress. For example, the incident may be considered to be still in progress if an initial collision was detected, and the vehicle 25 is still in motion. Additionally or alternatively, the incident may be considered to be still in progress if an incident has not yet occurred but continues to appear imminent. As another example, the incident may be considered to be still in progress for a predetermined time period following the incident, for example, 1 minute.
- the process 300 may return to the block 315 to collect additional mobile data from the one or more portable devices 20 .
- the additional mobile data may indicate, e.g., that a user of a portable device 20 is still in the vehicle 25 , has been ejected from the vehicle 25 , is moving, is static, etc. If the computer 100 determines that the event is no longer in progress, the process 300 may end.
- Computing devices such as those discussed herein generally each include instructions executable by one or more computing devices such as those identified above, and for carrying out blocks or steps of processes described above.
- process blocks discussed above may be embodied as computer-executable instructions.
- Computer-executable instructions may be compiled or interpreted from computer programs created using a variety of programming languages and/or technologies, including, without limitation, and either alone or in combination, JavaTM, C, C++, Visual Basic, Java Script, Perl, HTML, etc.
- a processor e.g., a microprocessor
- receives instructions e.g., from a memory, a computer-readable medium, etc., and executes these instructions, thereby performing one or more processes, including one or more of the processes described herein.
- Such instructions and other data may be stored and transmitted using a variety of computer-readable media.
- a file in a computing device is generally a collection of data stored on a computer readable medium, such as a storage medium, a random access memory, etc.
- a computer-readable medium includes any medium that participates in providing data (e.g., instructions), which may be read by a computer. Such a medium may take many forms, including, but not limited to, non-volatile media, volatile media, etc.
- Non-volatile media include, for example, optical or magnetic disks and other persistent memory.
- Volatile media include dynamic random access memory (DRAM), which typically constitutes a main memory.
- DRAM dynamic random access memory
- Computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH-EEPROM, any other memory chip or cartridge, or any other medium from which a computer can read.
- exemplary is used herein in the sense of signifying an example, e.g., a reference to an “exemplary widget” should be read as simply referring to an example of a widget.
Abstract
Description
- This application is related to U.S. patent application Ser. No. ______, Attorney Docket No. 83522331(65080-1583), entitled “DETERMINING VEHICLE OCCUPANT LOCATION”, U.S. patent application Ser. No. ______, Attorney Docket No. 83522285(65080-1586), entitled “DETERMINING VEHICLE OCCUPANT LOCATION,” U.S. patent application Ser. No. ______, Attorney Docket No. 83528749(65080-1602), entitled “HAND-ON STEERING WHEEL DETECTION,” and U.S. patent application Ser. No. ______, Attorney Docket No. 83528745(65080-1603), entitled “DETERMINING VEHICLE OCCUPANT LOCATION,” all being filed on the same day as this application; the complete contents of each of which are hereby incorporated herein by reference in their entireties.
- Response to an incident such as a vehicle collision may be improved by the timely availability of data. Information such as where an occupant was located in the vehicle at the time of the incident, the acceleration experienced by the occupant during the incident, and the location of the occupant following the incident can be of critical importance during an initial response.
-
FIG. 1 is diagram of an exemplary system for determining location(s) of one or more occupants of a vehicle using a portable device. -
FIG. 2 is a top view of an exemplary vehicle including a communications mechanism for communicating with portable devices. -
FIG. 3 is a further top view of the exemplary vehicle ofFIG. 2 , including the communications mechanism, illustrating location zones. -
FIG. 4 is a diagram of an exemplary process for managing wearable device data during and after an incident. - Referring to
FIG. 1 ,portable devices 20, includingportable devices 20 that are wearable by a human vehicle occupant, can be used as disclosed herein to provide additional and timelier data to emergency responders following an incident compared to what is presently available. Communications from one or moreportable devices 20 may be used by acomputer 100 in avehicle 25 to determine where, within thevehicle 25, a user of theportable device 20 was located in thevehicle 25 prior to the incident. One ormore movement sensors 90 in eachportable device 20 may additionally provide data indicating acceleration experienced by the user during the incident. Following the incident, thecomputer 100, based on communications with theportable device 20, may determine a location of the user of theportable device 20. Themovement sensors 90 in theportable device 20 may further be used to determine a user state, e.g., whether the user is walking, standing, sitting, etc. - The
vehicle computer 100 may, based on data from thevehicle 25 Restraints ControlModule 110, or one ormore vehicle sensors computer 100 may request data from the one or moreportable devices 20 such as movement data for a period of time. Thecomputer 100 may receive the data from eachportable device 20 and store the data. Thecomputer 100 may, e.g., transmit the data to aremote server 30. If theremote server 30 is not accessible, thecomputer 100 may transfer the collective set of data from all theportable devices 20 to memory in one or more of theportable devices 20. Further, thecomputer 100 may download data related to the incident to theportable device 20. - In this manner, data, such as a user location in the
vehicle 25 at the time of an incident, acceleration experienced by the user of theportable device 20 during the incident, and user state following the incident, may be made available to responders to the incident. For example, responders may access the data from theremote server 30. Further, responders, such as medical practitioners in a hospital, may be able to access data downloaded to theportable device 20 worn by a user. - As shown in
FIG. 1 , asystem 10 includes a remote keyless entry device which may be a traditional fob or, e.g., a phone based remote entry telematics application (hereinafter fob) 15, one or moreportable devices 20, avehicle 25, aserver 30 and anetwork 35. As described below, thefob 15 andportable device 20 may be communicatively coupled with thevehicle 25. Further as described below, theportable device 20 may be, e.g., a wearable device with or without cellular capability, a mobile telephone, a tablet, etc., and may be directly communicatively coupled with thevehicle 25, or indirectly coupled with thevehicle 25, e.g., through anotherportable device 20. Thevehicle 25 may further be communicatively coupled with theserver 30 via thenetwork 35. - The
fob 15 is configured, i.e., includes known mechanisms such as programming in acomputer 60 and hardware such as atransceiver 65 for wireless communications, to send messages to thevehicle 25, e.g., commands or instructions controlling operations of thevehicle 25. For example, thefob 15 may send commands to thevehicle 25 instructing thevehicle 25 to lock or unlock doors, open a trunk lid or other hatch, start the ignition, etc. Thefob 15 further generally includes auser interface 70. Thefob 15 may be an app on theportable device 20 which sends these same commands to theremote sever 30 ornetwork 35 which may then send commands to thevehicle 25 instructing thevehicle 25 to lock or unlock doors, open a trunk lid or other hatch, start the ignition, etc. - One or
more fobs 15 may be paired with avehicle 25. For example, as is known, afob 15 may be programmed with a specific identification code and thevehicle 25 may include a list of identification codes authorized to send commands to thevehicle 25. Thevehicle 25 may look for one or more identification codes upon receiving messages, and determine if thefob 15 is authorized. - The
fob 15computer 60 includes a processor and a memory. The processor is programmed to execute programs stored in the memory, e.g., to send commands to thevehicle 25. Thetransceiver 65 is configured to transmit radio frequency (RF) signals to, and optionally receive RF signals from thevehicle 25. As is known,typical fob 15 frequencies of operation for one-way communication are 315 MHz or 433 MH and for two-way communications are 902 MHz or 868 MHz. For Passive Entry and Passive Start systems, thevehicle 25 may send commands toFob 15 using Low Frequency (LF) transmissions at frequencies of 125 kHz or 135 kHz. - The
fob 15user interface 70 includes one or more input mechanisms and may include a display. The input mechanisms may be buttons, a touch screen display, a gesture sensing device, etc., for receiving input from a user. The display may include an LCD display, LED display, buzzers speakers, haptic feedback, etc., for providing information to the user. - Additionally or alternatively, other systems may also be used to command the
vehicle 25 to unlock, start, etc. For example, thevehicle 25 may be equipped with a passive entry system, e.g., that sends a message to fobs 15 proximate to thevehicle 25 and looks for a response from a pairedfob 15. Other possible systems to unlock/start/etc. thevehicle 25 include a keypad, remote entry mechanical key, telematics unlock system, etc. - A
portable device 20 may be, e.g., a wearableportable device 20 or a mobileportable device 20. A wearableportable device 20 may include a connectivity product such as a “smart” watch, a fitness band, smart clothing, jewelry, etc. A mobileportable device 20 may include, e.g., a mobile telephone, tablet, laptop, etc. Some wearableportable devices 20 may include built-in modems or full cellular capability. Other wearableportable devices 20 may need to link or pair, e.g., with a mobileportable device 20 such as a mobile telephone, tablet, laptop, etc. in order to establish communications with thevehicle 25. Eachportable device 20 typically includes acomputer 75, atransceiver 80, and aninterface 85. Theportable device 20 may further include one ormore sensors 90, discussed further below. - Each
portable device 20 may be associated with a user. For example, theportable device 20 may include auser profile 101, and send theuser profile 101 to thevehicle 25 when theportable device 20 initiates communication with thevehicle 25. Alternatively, theportable device 20 may have been paired with thevehicle 25, for example, via a synchronization system in thevehicle 25. In this case, thevehicle 25 may maintain auser profile 101 associated with the paired (synchronized)portable device 20. - The
user profile 101 may be a set of data associated with the user. Theuser profile 101 may include data such as user preferred vehicle settings (e.g., seat settings, minor settings, temperature settings, radio station), user characteristics (e.g., height, weight, age, medical conditions), routines (typically drives to work on weekday mornings), etc. Theuser profile 101 may be maintained by acomputer 100 on thevehicle 25. Additionally or alternatively, one or moreportable devices 20 may maintain auser profile 101 identified with the user. The user profiles 101 maintained on theportable devices 20 may be accessed by thevehicle 25 and combined with the data in thevehicle 25user profile 101. The data in theuser profile 101 may be entered by the user via an interface on thevehicle 25 or one of theportable devices 20 associated with the user, determined by thecomputer 100 in thevehicle 25, downloaded from other computing devices, e.g., theserver 30, etc. - The
portable device 20 may be configured for short range, wireless communication with thevehicle 25. For example, theportable device 20transceiver 80 may be a BLUETOOTH® transceiver capable of forming links with other BLUETOOTH transceivers. One or moreportable devices 20 and thevehicle 25 may accordingly exchange messages. Aportable device 20 may transmit a signal including, e.g., identification data (identifying the type of user device, the identity of a user, etc.), movement data, etc. to thevehicle 25. In addition or alternatively to BLUETOOTH, other suitable wireless communication protocols, e.g., NFC, IEEE 802.11 or other protocols as may be known, may be used for communication between theportable devices 20 and thevehicle 25. - Further, a
portable device 20 may be configured to link with otherportable devices 20. For example, a firstportable device 20 may be a smart watch, and a secondportable device 20 may be a mobile telephone. The firstportable device 20 may link with the secondportable device 20 and exchange data with the secondportable device 20; the first and secondportable devices 20 may be associated with a same user. As one example, the firstportable device 20 may includebiometric sensors 90 to measure the heart rate of the user and transmit the heart rate to the secondportable device 20. The secondportable device 20 may output the heart rate data to the user via the secondportable device 20interface 85. BLUETOOTH communication links typically operate at frequencies from 2402-2480 MHz. As above, other suitable wireless communication protocols such as are known may alternatively or additionally be used to form the communication links with otherportable devices 20. - In addition to
biometric sensors 90,portable device 20sensors 90 may include accelerometers, g-sensors, gyroscopes, compasses, light sensors, cameras, etc. Thesensors 90 may measure movements of theportable device 20 and output movement data that theportable device 20 may then communicate to thevehicle 25. As described below, thevehicle 25 may determine, based on the movement data, e.g., that the user of theportable device 20 has opened a door of thevehicle 25. - The
vehicle 25 is generally a land-based vehicle having three or more wheels, e.g., a passenger car, light truck, etc. Thevehicle 25 accordingly generally has a front, a rear, a left side and a right side, wherein the terms front, rear, left and right are understood from the perspective of a user of thevehicle 25 seated in a driver's seat in a standard operating position, i.e., facing a steering wheel 160 (FIG. 2 ). Thevehicle 25 includes thecomputer 100 including a processor and a memory. The memory includes one or more forms of computer-readable media, and storing instructions executable by the processor for performing various operations, including as disclosed herein. Further, thecomputer 100 may include and/or be communicatively coupled to more than one other computer, e.g.,Restraints Control Module 110, steeringsensors 115,door sensors 120,seat sensors 125,other sensors 130 andcontrollers 135. Thevehicle 125computer 100 is further typically communicatively coupled with acommunications mechanism 145 configured for wireless communications with on-board and external wireless devices including thefob 15,portable device 20,remote server 30 andnetwork 35. - The
computer 100 is generally programmed and arranged for communications on a controller area network (CAN) bus or the like. Thecomputing device 100 may also have a connection to an onboard diagnostics connector (OBD-II), e.g., according to the J1962 standard. Via the CAN bus, OBD-II connector port, and/or other wired or wireless mechanisms, thecomputer 100 may transmit messages to various devices in a vehicle and/or receive messages from the various devices, e.g., controllers, actuators, sensors, etc. In addition, thecomputer 100 may be configured for communicating, e.g., with one or moreremote servers 30, with one ormore fobs 15, with one or moreportable devices 20, with theRestraints Control Module 110, and/or with thenetwork 35. - The
steering sensors 115 may be steering angle sensors, steering torque sensors, motor sensors associated with power steering assist, etc., known to provide data related directly or indirectly to steering operations. For example, asteering sensor 115 may be a steering angle sensor which senses a rotation of avehicle 25steering wheel 160, and communicates thesteering wheel 160 rotation data to thecomputing device 100. As another example, asteering sensor 115 may sense rotation of a motor providing power assist for steering operations, and provide the motor rotation data to thecomputer 100. -
Door sensors 120 may be mechanical switches that are activated by the door, proximity sensors, hall-effect sensors, or the like, such as are known, that indicate if a door is open or closed and that provide door status data to thecomputing device 100. For example, there may be onedoor sensor 120 associated with each door of thevehicle 25. -
Seat sensors 125 may include a variety of sensors including occupancy sensors and seat position sensors such as are known. Theseat sensors 125 may, e.g., determine whether a user is occupying a seat, determine the weight of the user, and communicate the determined weight to thecomputer 100. Further, theseat sensors 125 may detect either directly or indirectly the position of a seat, angle of a seat back, height of a headrest, etc., and provide data to thecomputer 100 with regard to one or more of these settings. Yet further, thecomputer 100, may, e.g., upon identifying a seat user, adjust settings to a user profile associated with the user. - The
vehicle 25 may include one or moreother sensors 130. Theother sensors 130, may include, as non-limiting example only, cameras, optical sensors, radar, microphones, proximity sensors, ultrasonic sensors, pressure sensors, accelerometers, g-sensors, gyroscopes, temperatures sensors, current sensors, voltage sensors, infrared sensors, capacitive sensors, etc. The sensors may include processors and memories, and may be configured to communicate with and send data to thecomputer 100, e.g., via a CAN bus or the like. - The
vehicle 25 may also include one ormore controllers 135 for controllingvehicle 25 components. The one ormore controllers 135 may include known controllers, as non-limiting examples, a seat controller, a power steering controller, a door lock controller, a door latch controller, a climate controller, a mirror adjustment controller, a seatbelt controller, a climate controller, a brake controller, etc. Each of thecontrollers 135 may include respective processors and memories, one or more actuators, and one or more sensors, as is known. Thecontrollers 135 may be configured to receive instructions from thecomputing device 100 and control an actuator based on such instructions. For example, adoor lock controller 135 may receive an instruction to unlock a door and may cause an actuator to unlock a lock associated with the door. Further, thecontroller 135 may include sensors. The sensors, may, e.g., detect the action of the actuator. For example, thedoor lock controller 135 may detect the lock being in an unlocked condition. Thecontroller 135 may provide data regarding the status of the lock to thecomputer 100. - Specifically, the
vehicle 25 may include a restraints control module (RCM) 110. TheRCM 110 may include, e.g., g-sensors, and may further receive input fromother sensors 130 such as g-sensors, gyroscopes, pressure sensors, etc., in the doors or other areas within thevehicle 25. TheRCM 110, may, based on the input received theRCM 110 sensors andother sensors 130, etc., identify or anticipate an incident. TheRCM 110 may broadcast this information to thecomputer 100, other vehicle components includingvehicle controllers 135, one or moreremote servers 30, etc. The information may be broadcast via a CAN network, or via a dedicated communications link. - As stated above, a
vehicle 25 may further include acommunications mechanism 145 for wireless communications with vehicle on-board and external devices configured for wireless communications. For example, thecommunications mechanism 145 may include acomputer 146 having a processor and a memory, and ameasurement unit 147. The communications may be direct communications, i.e., between a transceiver in thecommunications mechanism 145 and a transceiver in the wireless device, or indirect communications, e.g., via a network such as anetwork 35. - The communications block 145 may generally be configured to support communications with 1-Way (typically 315 MHz or 433 MHz), or 2-Way (typically 902 MHz or 868 MHz) remote keyless entry (RKE) systems, passive-entry passive-start (PEPS) systems (125 kHz LF challenge and 315 MHz or 433 MHz response), near field communications (NFC) (typically 13.56 MHz), Bluetooth systems (2402-2408 MHz), vehicle-to-vehicle (V2V) systems and vehicle-to-infrastructure (V2I) systems in the Dedicated Short Range Communications (DSRC) Band (5.9 GHz), portable devices in the cellular bands, Wi-Fi (typically 2.4 GHz or 5 GHz bands), GPS systems (1575.42 MHz and 1227.6 MHz), etc. Examples of protocols that the
communication block 145 may support include Bluetooth, NFC, DSRC, 3G UMTS protocols as defined by the 3GPP standards body, 4G LTE protocols as defined by the 3GPP standards body, Wi-Fi 802.11 protocols as defined by IEEE, W-Max 802.16 protocols as defined by IEEE, or other suitable wireless communication protocols. - As described in more detail below, the
communications mechanism 145 may be configured to communicate with thefob 15, theportable device 20 and, via thenetwork 35, with aremote server 30. - The
communications mechanism 145 may be configured to establish communications with one or moreportable devices 20. Upon receiving an instruction to unlock thevehicle 25 as described above, thecomputer 100 may instruct thecommunications mechanism 145 to search for and establish communications withportable devices 20 proximate to, e.g., within 3 meters of, thevehicle 25. Thecommunications mechanism 145 may search for allportable devices 20 proximate to the vehicle, or, e.g., a specific list ofportable devices 20 associated with known users of thevehicle 25. Theportable devices 20 may then respond to thecommunications mechanism 145. In another scenario, thecommunications mechanism 145 may, e.g., periodically search for, and establish communications with,portable devices 20 proximate thevehicle 25. Upon establishing communications with thedevices 20, the communications block 145 may send instructions requesting user identification data, movement data, etc. from theportable devices 20. In certain scenarios, thecomputer 100 may specifically establish communications directly or indirectly with wearableportable devices 20. - In addition to communicating with the one or more
portable devices 20, thecommunications mechanism 145 may determine a strength of signals received from respectiveportable devices 20. As shown inFIG. 1 , thecommunications mechanism 145 may include ameasurement unit 147. Themeasurement unit 147 may receive signals from theportable devices 20, and measure signal strength in a known manner. When applicable, e.g., when seeking to determine a location of a user, themeasurement unit 147 should measure the signal strength of the signal transmitted from the wearableportable device 20 and not the signal transmitted from the supporting mobileportable device 20. Themeasurement unit 147 may provide this information to thecomputer 100. As described below, the strength of a signal received from aportable device 20 may be an indication of the distance (also referred to herein as range) of theportable device 20 from thecommunications mechanism 145. This information may be used, particularly in the case of a wearableportable device 20, to determine a boundary or zone where a user of the wearableportable device 20, is located within thevehicle 25. Themeasurement unit 147 may determine these zones with one transceiver antenna. Alternatively, two or more antennas may be used if, e.g., they exist for other features. - The
vehicle 25communications mechanism 145 may further be configured to communicate, e.g., over anetwork 35 with aremote server 30. For example, when thevehicle 25 has been involved in an incident, thevehicle 25 may be able to transmit a message to theremote server 30 indicating that thevehicle 25 was involved in an incident, and may be able to send additional information such as the location of thevehicle 25. When thevehicle 25 is linked to one or moreportable devices 20, thevehicle 25, via thecommunications mechanism 145 may additionally or alternatively be able to send user status information, such as the user's vital signs, to theremote server 30. - The
network 35 represents one or more mechanisms by which thevehicle 25 may communicate with remote computing devices, and may be one or more of various wired or wireless communication mechanisms, including any desired combination of wired (e.g., cable and fiber) and/or wireless (e.g., cellular, wireless, satellite, microwave and radio frequency) communication mechanisms and any desired network topology (or topologies when multiple communication mechanisms are utilized). Exemplary communication networks include wireless communication networks, local area networks (LAN) and/or wide area networks (WAN), including the Internet, providing data communication services. - Identifying a Vehicle Unlock or other Trigger Event for a User Location Identification Process
- The
vehicle 25computer 100 may receive a signal from thefob 15 to unlock thevehicle 25, or recognize another trigger event for starting a user location identification process. For example, a user of thevehicle 25 may activate thefob 15, and thefob 15 may send an unlock command to thevehicle 25. Thevehicle 25computer 100 may receive the unlock signal, and initiate a process to identify locations of one or more users in thevehicle 25. - As another example, a
sensor 130 may detect a user grabbing or touching a door handle to pull on the door handle with the intent to open the door, and based on the detection, thecomputer 100 may initiate and establish communications withfobs 15 proximate thevehicle 25 to authorize unlocking a door. Thecomputer 100 may determine that one or more of thefobs 15 is an authorizedfob 15 for thevehicle 25, e.g., in a manner as described above. Conversely, if the door was already unlocked the trigger ofsensor 130 may still be used to informcomputer 100 that a user is about to open a door. Thecomputer 100 may also receive an input from a key pad on thevehicle 25, a door or global unlock event activated by a mechanical key, an ignition activated by a mechanical key, from a telematics system, etc. that is identified as a trigger event for initiating a user location identification process. Still further, thecomputer 100 could initiate the user location identification process periodically, based on a timer, etc. - Identifying Door Opening Events from Wearable Device Movements
- Upon recognizing a trigger event, the
computer 100 may initiate a process to instruct theportable device 20, which may be a wearableportable device 20, to record g-sensor data for a specified period to identify hand motions and then monitor allvehicle 25door sensors 120 to determine where users entered thevehicle 25. Thecomputer 100 may monitor g-sensor movements of theportable devices 20 associated withvehicle 25 users, and based on the movement data identify adevice 20, and hence a user, that may be associated with opening aparticular vehicle 25 door. In the case of only one door opening and only oneportable device 20 being identified with a signature movement data pattern, it may be possible to conclude who has entered that door. In cases where more doors have opened than there are detectedportable devices 20, additional data is required to predict the user's location. Thecomputer 100 may further use the movement data as an indication of where the user is located in thevehicle 25 after entering thevehicle 25. - Now referring to
FIG. 2 , thevehicle 25 may include asteering wheel 160, frontleft door 165, frontright door 170, rearleft door 175, rearright door 180, andrear hatch door 181. Thevehicle 25 may further include thecommunications mechanism 145. Thecommunications mechanism 145 may be located in a front center portion of thevehicle 25. Alternatively, for example, a portion of thecommunication mechanism 145 used to establish communication with theportable devices 20 may be located in the center front portion of thevehicle 25, and other portions of thecommunications mechanism 145 may be located in one or more other locations in thevehicle 25. The portion of thecommunications mechanism 145 used to establish communications with theportable devices 20 should be strategically placed such that the strength of a signal received from a respectiveportable device 20 is indicative of a definable zone within thevehicle 25. - As described above, the
communications mechanism 145 may include ameasurement unit 147, and may be configured to establish communications withportable devices 20. Themeasurement unit 147 may be configured to measure the strength of signals received from theportable devices 20, and to report the strength of the signals from the respectiveportable devices 20 to thecomputer 100 of thevehicle 25. - Upon identifying a trigger event for initiating a user location identification process as described above, the
computer 100, based on the trigger event may activate thecommunications mechanism 145, and instruct thecommunications mechanism 145 to search for and establish communications withportable devices 20 proximate thevehicle 25. Thecomputer 100 may limit the search to previously pairedportable devices 20. As above, when applicable, e.g., when seeking to identify a range of a user from thecommunications mechanism 145, themeasurement unit 147 should measure the signal strength of the signal transmitted from the wearableportable device 20 and not the signal transmitted from the supporting mobileportable device 20. - As shown in
FIG. 2 , in one example, thecomputer 100 may find and establish communications (via the communications mechanism 145) withportable devices 20 a-20 h which are determined to be wearableportable devices 20. Thecomputer 100 may command each of the wearableportable devices 20 a-20 h to send movement data associated with the respective wearableportable devices 20 a-20 h to thecomputer 100. - By monitoring and evaluating the movement data received from the wearable
portable devices 20 a-20 h, thecomputer 100 may determine, e.g., that the user of wearableportable device 20 a has opened aleft side door left side door vehicle 25. - In a similar manner, the
computing device 100 may determine, e.g., that a user of wearableportable device 20 d also opened aleft side door portable device 20 e has opened aright side door - In addition to identifying movements of a wearable
portable device 20 worn by a user on an arm used for opening a door, other types of movements may be identified as movements indicating a door opening. For example, for a user opening aright door portable device 20 on their left arm, particular movements, for example the swinging of the left arm around the body during door opening (or entering the vehicle 25) may be indicative of aright door wearable devices 20 may be determined to be characteristic of opening avehicle 25 door, 165, 170, 175, 180,181. Further, movements that are characteristic of closing avehicle 25door - As described above, a determination that a user has opened a
particular vehicle 25door computer 100. Additionally or alternatively, the determination may be made, e.g., by thecomputer 75 in the respective wearableportable device 20, and the results communicated to thecomputer 100. Additionally or alternatively, the determination may be made by another computer communicatively coupled to thecomputer 100. - Identifying Location Zones for Wearable Devices based on Received Signal Strength
- Additional information regarding the location of users within a
vehicle 25 may be determined based on a received signal strength of signals received by thecommunications mechanism 145 fromportable devices 20. When applicable, e.g., when seeking to determine a range of a user from thecommunications mechanism 145, theportable devices 20 may be wearableportable devices 20. - As shown in
FIG. 3 , thevehicle 25 may be divided into three or more zones based on distance from thecommunications mechanism 145; afirst zone 185, asecond zone 190 and athird zone 195. Thezones communications mechanism 145. As another example, the receiver portion in thecommunications mechanism 145 may be directional, i.e., have a reception sensitivity that is greater in some directions than others, and thezones - Further, the
zones vehicle 25 and/or thecommunications mechanism 145 may receive signals from outside of the defined zones, 185, 190, 195. For example, thecommunications mechanism 145 may be able to receive a signal from theportable device 20 that is beyond thethird zone 195. Further, thezones vehicle 25. Thecommunications mechanism 145 may determine, based on the RSSI of theportable device 20, that aportable device 20 is within range to communicate with thecommunications mechanism 145, but outside of thethird zone 195. - The
portable devices first zone 185. Theportable devices second zone 190, and theportable devices third zone 195. As above, each of theportable devices 20 a-20 h may be a wearableportable device 20. Also as above, thecomputing device 100 may establish communications via thecommunications mechanism 145 with each of theportable devices 20 a-20 h. - The
communications mechanism 145 may be configured to measure received signal strength of the signals received from each of theportable devices 20 a-20 h, and provide a received signal strength indication (RSSI) such as is known to thecomputer 100 respectively for each of theportable devices 20 a-20 h. - Based on the respective received signal strengths, the
computer 100 may determine the zone in which each of theportable devices 20 a-20 h is located. For example, if the RSSI is greater than or equal to a first predetermined threshold and less than a second predetermined threshold, the computing device may determine that the associatedportable device 20 is located within thethird zone 195. If the RSSI is greater than or equal to the second predetermined threshold and less than a third predetermined threshold, thecomputer 100 may determine that associatedportable device 20 is located in thesecond zone 190. If the RSSI is greater than or equal to the third predetermined threshold, thecomputer 100 may determine that the associatedportable device 20 is located in thefirst zone 185. The first, second and third predetermined thresholds may be determined empirically based on representativeportable devices 20, the location of thecommunications mechanism 145, the type ofvehicle 25, etc. In the example according toFIG. 3 , thecomputer 100 would determine thatportable device 20 a-20 b are in thefirst zone 185,devices 20 c-20 e are in thesecond zone 190 anddevices 20 f-20 h are in thethird zone 195. - Identifying the Driver and Front Seat Passenger based on Door Opening and Zone Data
- Based on the door opening data and zone data collected above, the
computer 100 can be programmed to determine the driver and front passenger of thevehicle 25. - For example, if, as described above, the
computer 100 determines based on the RSSI of theportable device 20 a that theportable device 20 is in thefirst zone 185, and determines based on the movement data from theportable device 20 a that the user ofportable device 20 a entered a left side door of thevehicle 25, thecomputer 100 may further determine that the user of theportable device 20 a is located in a front left (driver's) seat of thevehicle 25. - Further, if, in the example above, the
computer 100 determines based on the RSSI ofportable device 20 b that theportable device 20 b is also in thefirst zone 185, thecomputer 100 may determine that the user of theportable device 20 b is in a front passenger seat. The same process for locating the driver and front row passenger can also be applied to right hand drive vehicles by reversing the relationships of detected door opening events. - Management of Mobile Data and Vehicle Data Following Determination that an Incident is In Progress or Imminent
- Upon determination that an incident is in progress or imminent, the vehicle may instruct
portable devices 20 to start recording, then data generated by thesensors 90 of portable devices 20 (mobile data) may be collected by thevehicle 25computer 100 and distributed, e.g., to theremote server 30. An incident may include, e.g., a collision with an object or another vehicle, running off of the road, a severe braking event sufficient to trigger a fuel cut-off event, a rollover event etc. An incident may be determined to be imminent if, e.g., thevehicle 25computer 100, determines, based on a current vehicle status, i.e., speed, range from other objects, road condition, location on a road, etc., that an incident is unavoidable, or will occur within a predetermined time, e.g., three seconds or ifcomputer 100 is advised by therestraints control module 110 of the same imminent condition. - The mobile data may include, e.g., movement data representing movement of the
portable device 20, location data of the one or moreportable devices 20, biometric data of a user wearing the one or moreportable devices 20, identification data associated with the one or moreportable devices 20, etc. The mobile data may be collected and stored, together with an identifier for a user and/ordevice 20 associating theportable device 20 or user with the mobile data. The mobile data, together with other data collected by thevehicle 25, may additionally be transmitted to aremote server 30 for further processing. For example, the mobile data and vehicle data may be transmitted to aremote server 30 associated with a hospital or emergency response center, which may use the mobile data and vehicle data to determine the nature of an incident and the injuries that may have been incurred by thevehicle 25 users and other incident victims. - Mobile data may include identification of the
portable device 20, identification of the type ofportable device 20, e.g., smart watch, fitness band, mobile telephone, etc., movement data, biometric data of the user, timing data, location data, e.g., location based on GPS data, auser profile 101, vehicle make and model, vehicle VIN, license plate of vehicle in which they rode, name of person associated with theportable device 20 if available, etc. Further, the timing data from theportable device 20 may be in the form of a date and time stamped or encoded with some other form of time reference to allow synchronous comparison of data from the multipleportable devices 20. - Vehicle data may include, as non-limiting examples only, vehicle state data such vehicle speed, vehicle acceleration, vehicle location, e.g., based on GPS data, etc. Vehicle data may further include data from the
sensors controllers - The
vehicle 25computer 100 may be programmed to determine, e.g., as is known, that an incident is in progress or imminent and send commands to vehicle components including thecommunications mechanism 145. Thecomputer 100 may further be programmed to determine an incident reference time identifying a time the incident occurred or will occur. For example, thevehicle 25 may receive data from one or morevehicle steering sensors 115,door sensor 120,seat sensor 125,other sensors 130 and/or thecontrollers 135. Thevehicle 25other sensors 130 may include accelerometers, gyroscopes, pressure sensors, cameras, radar, ultrasonic sensors etc. which may provide data to thevehicle computer 100. Based on data, thevehicle 25 may, e.g., as is known, determine that an incident is in progress or is imminent. Thecomputer 100 may send messages to thevehicle controllers 135, e.g., one ormore airbag controllers more seatbelt controllers 135 to increase tension to seatbelts, etc. - The
computer 100 may further be programmed to send, via thecommunications mechanism 145, one or more messages to one or moreportable devices 20, e.g.,portable devices 20 identified as being located in thevehicle 25 at the reference time mentioned above. The message may indicate the incident reference time, and instruct the one or moreportable devices 20 to send data fromportable device 20sensors 90 to thevehicle 25computer 100. Specifically, thecomputer 100 may communicate withportable devices 20 identified as wearable devices, and request movement data, such as data collected from 3-axis accelerometers 90 included in the wearableportable devices 20, during a predetermined time period. - The predetermined time period may be defined, e.g., as starting one second before the reference time and extending for two seconds after the reference time, or for some other time period.
- In addition to requesting movement data, the
computer 100 may be programmed to request data such as the location data of theportable device 20 at the reference time. Thecomputer 100 may further request biometric data, such as vital signs of the user of theportable device 20. In some cases, thecomputer 100 may associate data stored in thevehicle 25, for example, the current location of the user of theportable device 20, with the data received from theportable device 20. - Upon receiving the requested data from the one or more
portable devices 20, thecomputer 100 may generate data, e.g., unique or substantially unique identifiers, associating, for example, movement data, location data, etc. with a particularportable device 20 and/or particular user. The identifiers may be included in a set of data referred to herein as a tag that may also include time stamps indicating when the data was generated relative to the reference time. Thecomputer 100 may store the mobile data, including tags, in a memory associated with thecomputer 100. - Following the incident, the
computer 100 may request movement data, identification data, biometric data, location data (to the extent available), etc. from theportable device 20 for one or more additional predetermined time periods. For example, the one or more additional predetermined time periods could include three-second windows that occur every 10 seconds, for one minute following the reference time. - Further, in a manner as described above, the
computer 100 could determine, based on a received signal strength, e.g., a location of the user of theportable device 20 following the incident, and could determine, for example, if the user has (or may have) been thrown from thevehicle 25. For example, if, prior to the incident, thecomputer 100 determined that the user of theportable device 20 was inzone 185, and after the incident, thecomputer 100 determined that the user is inzone 195, thecomputer 100 may further determine that the user was thrown from thevehicle 25. - The
computer 100 may further make the mobile data, along with data collected from the one ormore vehicle sensors more vehicle controllers remote server 30. The mobile data and vehicle data may, in this manner, be made available, for example, to emergency responders to the incident, or to product developers to improve safety features of newly developed vehicles. - For example, location data and movement data at the reference time may provide information related to the type, severity, etc. of an incident. Location data and movement data at a time after the reference time may provide information related to a condition of a user. For example, location data showing a
portable device 20 outside thevehicle 25 may indicate that the user was thrown from thevehicle 25 during the incident. Movement data showing that theportable device 20 is moving at a time following the reference time may indicate that the user is walking, etc. - The
computer 100 may further initiate downloads of data to one or moreportable devices 20. For example, as described above, thevehicle 25computer 100 may collect vehicle data from thevehicle sensors vehicle controllers computer 100 may further collect mobile data from one or moreportable devices 20 related to the incident. This data may include video or still frames from vehicle mounted cameras. Thecomputer 100 may then download a portion or all of the data to a particularportable device 20. The downloaded data may be stored by theportable device 20, such that the data is available, for example, to a medical practitioner treating the user following the incident. - For example, following the incident, the
computer 100 may identify data, such as vehicle acceleration data at the reference time, movement data fromportable devices 20 at the reference time, portions of thevehicle 25 damaged during the collision, etc., that is indicative of the condition of a user of a particularportable device 20. For example, vehicle acceleration data could indicate that thevehicle 25 was hit from the rear. Additional vehicle data could indicate that a rear portion of the vehicle was crushed, and that airbags were deployed for a first user driving thevehicle 25 and a second user in a front passenger seat. Movement data from theportable devices 20 worn respectively by the first and second users could indicate that acceleration was along a front-rear axis of thevehicle 25 and that both the first and second user were still in thevehicle 25 following the incident. Thecomputer 100 may identify data that may be relevant to the condition of each of the first and second users such as acceleration data, airbag deployment data, etc., and download the data identified as relevant to theportable device 20 of the user. - Process for Managing Portable Device and Vehicle Data during an Incident
-
FIG. 4 is a diagram of anexemplary process 300 for managing data collected by one or moreportable devices 20 and thevehicle 25 when it is determined by thevehicle 25 that an incident is in progress or imminent. Theprocess 300 starts in ablock 305. - In the
block 305, thevehicle 25computer 100 receives vehicle data from one ormore vehicle sensors more controllers sensors controllers process 300 continues in theblock 310. - In the
block 310, thecomputer 100 determines, e.g., in a known manner, based on the received data, that an incident is in progress or is imminent. Thecomputer 100 may further determine additional information regarding the incident, such as the type and severity of the incident and may generate instructions tovehicle controllers 135 to respond to the incident. Thecomputer 100 may establish a reference time which may be used as a reference for responding to the incident and tagging data related to the incident. Theprocess 300 continues in theblock 315. - In the
block 315, thecomputer 100 instructs one or moreportable devices 20 to send mobile data associated with the respectiveportable device 20. For example, thecomputer 100 may send an instruction to theportable device 20 indicating that the incident is in progress or imminent and include the reference time related to the incident. Thecomputer 100 may instruct theportable device 20 to send location data, movement data, identification data, etc. associated with theportable device 20 during a predetermined time period related to the reference time. Based on the instruction, theportable device 20 may collect data including data from thesensors 90, and send a message to thecomputer 100 including the mobile data. Theprocess 300 continues in ablock 320. - In the
block 320, thecomputer 100 may receive mobile data from one or moreportable devices 20. As described above, thecomputer 100 may further receive a received signal strength indication (RSSI) from thecommunications mechanism 145. Based on the RSSI, as described above, thecomputer 100 may determine azone portable device 20 is located. Theprocess 300 continues in ablock 325. - In the
block 325, thecomputer 100 may store and tag the mobile data. For example, thecomputer 100 may receive location and movement data from theportable device 20. Thecomputer 100 may generate one or more tags for the location and movement data. The tags may indicate, e.g., a time when the location or movement data was generated, aportable device 20 which generated the location or movement data, a user associated with theportable device 20 that provided the data, etc. Thecomputer 100 may then store the data, together with the generated tags, in a memory, e.g., a memory associated with thecomputer 100. Theprocess 300 continues in ablock 330. - In the
block 330, thecomputer 100 may send data related to the incident to a remote computer, e.g., theremote server 30. The data may include vehicle data, such as the data received inblock 305 related to the incident, and mobile data such as the data received inblock 320. The data may further include tags generated by thecomputer 100 as discussed inblock 325. Theprocess 300 continues in ablock 335. - In the
block 335, thecomputer 100 may further download vehicle data and/or mobile data to one or moreportable devices 20. For example, thecomputer 100 may identify data, e.g.,data showing vehicle 25 acceleration during the incident, data such as data frompressure sensors 30 indicating damage to a particular section of thevehicle 25, etc., which may be helpful to a healthcare practitioner treating the user of theportable device 20. Thecomputer 100 may transmit the data to theportable device 20 including instructions to store the data. The data may include mobile data from otherportable devices 20, or mobile data from theportable device 20 receiving the data, with the data organized and tagged in order to be accessible to the healthcare practitioner. Theprocess 300 continues in ablock 340. - In the
block 340, thecomputer 100 may determine if the incident is still in progress. For example, the incident may be considered to be still in progress if an initial collision was detected, and thevehicle 25 is still in motion. Additionally or alternatively, the incident may be considered to be still in progress if an incident has not yet occurred but continues to appear imminent. As another example, the incident may be considered to be still in progress for a predetermined time period following the incident, for example, 1 minute. Theprocess 300 may return to theblock 315 to collect additional mobile data from the one or moreportable devices 20. The additional mobile data may indicate, e.g., that a user of aportable device 20 is still in thevehicle 25, has been ejected from thevehicle 25, is moving, is static, etc. If thecomputer 100 determines that the event is no longer in progress, theprocess 300 may end. - Computing devices such as those discussed herein generally each include instructions executable by one or more computing devices such as those identified above, and for carrying out blocks or steps of processes described above. For example, process blocks discussed above may be embodied as computer-executable instructions.
- Computer-executable instructions may be compiled or interpreted from computer programs created using a variety of programming languages and/or technologies, including, without limitation, and either alone or in combination, Java™, C, C++, Visual Basic, Java Script, Perl, HTML, etc. In general, a processor (e.g., a microprocessor) receives instructions, e.g., from a memory, a computer-readable medium, etc., and executes these instructions, thereby performing one or more processes, including one or more of the processes described herein. Such instructions and other data may be stored and transmitted using a variety of computer-readable media. A file in a computing device is generally a collection of data stored on a computer readable medium, such as a storage medium, a random access memory, etc.
- A computer-readable medium includes any medium that participates in providing data (e.g., instructions), which may be read by a computer. Such a medium may take many forms, including, but not limited to, non-volatile media, volatile media, etc. Non-volatile media include, for example, optical or magnetic disks and other persistent memory. Volatile media include dynamic random access memory (DRAM), which typically constitutes a main memory. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH-EEPROM, any other memory chip or cartridge, or any other medium from which a computer can read.
- All terms used in the claims are intended to be given their plain and ordinary meanings as understood by those skilled in the art unless an explicit indication to the contrary in made herein. In particular, use of the singular articles such as “a,” “the,” “said,” etc. should be read to recite one or more of the indicated elements unless a claim recites an explicit limitation to the contrary.
- The term “exemplary” is used herein in the sense of signifying an example, e.g., a reference to an “exemplary widget” should be read as simply referring to an example of a widget.
- In the drawings, the same reference numbers indicate the same elements. Further, some or all of these elements could be changed. With regard to the media, processes, systems, methods, etc. described herein, it should be understood that, although the steps of such processes, etc. have been described as occurring according to a certain ordered sequence, such processes could be practiced with the described steps performed in an order other than the order described herein. It further should be understood that certain steps could be performed simultaneously, that other steps could be added, or that certain steps described herein could be omitted. In other words, the descriptions of processes herein are provided for the purpose of illustrating certain embodiments, and should in no way be construed so as to limit the claimed invention.
Claims (20)
Priority Applications (9)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/713,008 US9505365B1 (en) | 2015-05-15 | 2015-05-15 | Wearable data management during an incident |
US14/712,994 US9544742B2 (en) | 2015-05-15 | 2015-05-15 | Determining vehicle occupant location |
US14/713,045 US9467817B1 (en) | 2015-05-15 | 2015-05-15 | Determining vehicle occupant location |
MX2016006033A MX364759B (en) | 2015-05-15 | 2016-05-09 | Wearable data management during an incident. |
MX2016006034A MX357933B (en) | 2015-05-15 | 2016-05-09 | Determining vehicle occupant location. |
CN201610302271.1A CN106162551B (en) | 2015-05-15 | 2016-05-09 | Wearable data management during an event |
DE102016108723.8A DE102016108723A1 (en) | 2015-05-15 | 2016-05-11 | Portable data management during an accident |
MX2016006128A MX357934B (en) | 2015-05-15 | 2016-05-11 | Determining vehicle occupant location. |
RU2016118603A RU2713702C2 (en) | 2015-03-15 | 2016-05-13 | Computer and method of data management of portable device during incident |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/713,008 US9505365B1 (en) | 2015-05-15 | 2015-05-15 | Wearable data management during an incident |
Publications (2)
Publication Number | Publication Date |
---|---|
US20160332589A1 true US20160332589A1 (en) | 2016-11-17 |
US9505365B1 US9505365B1 (en) | 2016-11-29 |
Family
ID=57208993
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/713,008 Active 2035-08-07 US9505365B1 (en) | 2015-03-15 | 2015-05-15 | Wearable data management during an incident |
Country Status (5)
Country | Link |
---|---|
US (1) | US9505365B1 (en) |
CN (1) | CN106162551B (en) |
DE (1) | DE102016108723A1 (en) |
MX (1) | MX364759B (en) |
RU (1) | RU2713702C2 (en) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2018113087A1 (en) * | 2016-12-24 | 2018-06-28 | 华为技术有限公司 | Method and device for determining geographical location of user taking a vehicle |
CN109741631A (en) * | 2019-02-01 | 2019-05-10 | 南京沃旭通讯科技有限公司 | A kind of relative position detection device and its working method |
US10388084B1 (en) * | 2017-01-19 | 2019-08-20 | State Farm Mutual Automobile Insurance Company | Systems and methods for providing vehicular collision data |
US11130446B2 (en) * | 2019-10-15 | 2021-09-28 | Robert Bosch Gmbh | System to detect objects ejected from a vehicle |
US20220051493A1 (en) * | 2020-08-14 | 2022-02-17 | Kennith Burks | Systems and methods for an automobile status recorder |
US20220215954A1 (en) * | 2020-08-09 | 2022-07-07 | Kevin Patel | System for remote medical care |
WO2024046674A1 (en) * | 2022-08-30 | 2024-03-07 | Robert Bosch Gmbh | A controller to determine crash information of a vehicle and method for the same |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9646345B1 (en) | 2014-07-11 | 2017-05-09 | State Farm Mutual Automobile Insurance Company | Method and system for displaying an initial loss report including repair information |
US11540088B2 (en) * | 2015-10-08 | 2022-12-27 | Voxx International Corporation | System and method for locating a portable device in different zones relative to a vehicle and with device zone indicators |
US10738513B2 (en) | 2016-12-09 | 2020-08-11 | Toyota Motor Engineering & Manufacturing North America, Inc. | Flush power slide door handle |
CN108216260A (en) * | 2016-12-21 | 2018-06-29 | 福特全球技术公司 | The vehicle control of connection based on portable device |
CN110461681A (en) * | 2017-02-03 | 2019-11-15 | 福特全球技术公司 | Vehicle and wearable device operation |
US10913413B2 (en) | 2018-12-04 | 2021-02-09 | Toyota Motor Engineering & Manufacturing North America, Inc. | Wearable article detection and climate adjustment system for a vehicle interior |
KR20210016807A (en) | 2019-08-05 | 2021-02-17 | 삼성전자주식회사 | Method for determining position in vehicle using vehicle movement and apparatus therefor |
Family Cites Families (48)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8948442B2 (en) * | 1982-06-18 | 2015-02-03 | Intelligent Technologies International, Inc. | Optical monitoring of vehicle interiors |
DE19823708A1 (en) | 1998-05-27 | 1999-12-02 | Bayerische Motoren Werke Ag | Identification device for the user of a vehicle |
JP3900893B2 (en) | 2001-11-02 | 2007-04-04 | ソニー株式会社 | Steering device, driver authentication method, automobile |
US6693535B2 (en) | 2001-11-29 | 2004-02-17 | Motorola, Inc. | System and method for controlling the interior temperature of a vehicle |
US6982656B1 (en) | 2002-12-20 | 2006-01-03 | Innovative Processing Solutions, Llc | Asset monitoring and tracking system |
US7289786B2 (en) * | 2003-01-16 | 2007-10-30 | Qualcomm Incorporated | Method and apparatus for communicating emergency information using wireless devices |
WO2004072893A1 (en) | 2003-02-11 | 2004-08-26 | Harman Becker Automotive Systems Gmbh | High occupancy vehicle restriction aware navigation system |
US20090327888A1 (en) | 2005-05-31 | 2009-12-31 | Ipifini, Inc. | Computer program for indentifying and automating repetitive user inputs |
ATE415048T1 (en) | 2005-07-28 | 2008-12-15 | Harman Becker Automotive Sys | IMPROVED COMMUNICATION FOR VEHICLE INTERIORS |
US20130150004A1 (en) | 2006-08-11 | 2013-06-13 | Michael Rosen | Method and apparatus for reducing mobile phone usage while driving |
GB0713336D0 (en) | 2007-07-10 | 2007-08-22 | Hw Comm Ltd | Occupancy declaration/verification for passenger transport conveyances |
US7876205B2 (en) | 2007-10-02 | 2011-01-25 | Inthinc Technology Solutions, Inc. | System and method for detecting use of a wireless device in a moving vehicle |
CN101391589A (en) * | 2008-10-30 | 2009-03-25 | 上海大学 | Vehicle intelligent alarming method and device |
US20100280711A1 (en) | 2009-04-29 | 2010-11-04 | Gm Global Technology Operations, Inc. | System and method of using a portable device to recognize a frequent driver |
US9615213B2 (en) * | 2009-07-21 | 2017-04-04 | Katasi Llc | Method and system for controlling and modifying driving behaviors |
US20130088352A1 (en) | 2011-10-06 | 2013-04-11 | David Amis | Systems and methods utilizing sensory overload to deter, delay, or disrupt a potential threat |
US8284041B2 (en) | 2009-09-28 | 2012-10-09 | Ford Global Technologies, Llc | Method and apparatus for in-vehicle presence detection and driver alerting |
US8570168B2 (en) | 2009-10-08 | 2013-10-29 | Bringrr Systems, Llc | System, method and device to interrogate for the presence of objects |
US8504090B2 (en) * | 2010-03-29 | 2013-08-06 | Motorola Solutions, Inc. | Enhanced public safety communication system |
US9511683B2 (en) | 2010-08-25 | 2016-12-06 | GM Global Technology Operations LLC | Occupant recognition and verification system |
CN102303608B (en) * | 2011-06-16 | 2013-11-06 | 大连理工大学 | Embedded, mobile and intelligent interconnection drive assisting system |
KR101319939B1 (en) | 2011-09-09 | 2013-10-29 | 주식회사 유비벨록스모바일 | System and method for diagnosising accident using black box and detecting sensor |
US8768292B2 (en) | 2011-11-01 | 2014-07-01 | Alfonzo Welch | Portable wireless automobile and personal emergency responder and messenger system and method |
CN102431452A (en) * | 2011-12-07 | 2012-05-02 | 刘晓运 | Sensor based control method for driving safety |
US8548667B2 (en) | 2011-12-15 | 2013-10-01 | Steering Solutions Ip Holding Corporation | Hands on steering wheel detect in lane centering operation |
US20130226369A1 (en) * | 2012-02-23 | 2013-08-29 | Sirius XM Radio, Inc. | Portable vehicle telematics systems and methods |
US9536361B2 (en) | 2012-03-14 | 2017-01-03 | Autoconnect Holdings Llc | Universal vehicle notification system |
CN102602363A (en) * | 2012-03-27 | 2012-07-25 | 华南理工大学 | Method and device for vehicle passive keyless entering, starting and locking based on ultra-wide band |
WO2013188977A2 (en) | 2012-06-20 | 2013-12-27 | Brule David Allen | Wearable rfid storage devices |
KR101335344B1 (en) | 2012-08-09 | 2013-12-02 | 이보석 | Smart car watch |
CN102905031A (en) * | 2012-10-23 | 2013-01-30 | 广东欧珀移动通信有限公司 | Method and system for processing emergencies by mobile terminal |
US20140163771A1 (en) | 2012-12-10 | 2014-06-12 | Ford Global Technologies, Llc | Occupant interaction with vehicle system using brought-in devices |
US20140163768A1 (en) * | 2012-12-11 | 2014-06-12 | At&T Intellectual Property I, L.P. | Event and condition determination based on sensor data |
US9398423B2 (en) | 2012-12-26 | 2016-07-19 | Truemotion, Inc. | Methods and systems for driver identification |
US9008917B2 (en) | 2012-12-27 | 2015-04-14 | GM Global Technology Operations LLC | Method and system for detecting proximity of an end device to a vehicle based on signal strength information received over a bluetooth low energy (BLE) advertising channel |
US10052972B2 (en) | 2013-03-26 | 2018-08-21 | Intel Corporation | Vehicular occupancy assessment |
WO2014172321A1 (en) | 2013-04-15 | 2014-10-23 | Flextronics Ap, Llc | Access and portability of user profiles stored as templates |
CA3188150A1 (en) | 2013-05-08 | 2014-11-13 | Cellcontrol, Inc. | Driver identification and data collection systems for use with mobile communication devices in vehicles |
US9135758B2 (en) | 2013-05-13 | 2015-09-15 | Moj.Io Inc. | Vehicle status notification and operator identification |
US8738292B1 (en) | 2013-05-14 | 2014-05-27 | Google Inc. | Predictive transit calculations |
US20150025917A1 (en) | 2013-07-15 | 2015-01-22 | Advanced Insurance Products & Services, Inc. | System and method for determining an underwriting risk, risk score, or price of insurance using cognitive information |
US9053516B2 (en) | 2013-07-15 | 2015-06-09 | Jeffrey Stempora | Risk assessment using portable devices |
US20150070131A1 (en) | 2013-09-11 | 2015-03-12 | Here Global B.V. | Method and apparatus for detecting boarding of a means of transport |
KR101470240B1 (en) | 2013-11-14 | 2014-12-08 | 현대자동차주식회사 | Parking area detecting apparatus and method thereof |
US9037199B1 (en) | 2014-02-13 | 2015-05-19 | Google Inc. | Detecting transitions between physical activity |
US9270809B2 (en) | 2014-03-10 | 2016-02-23 | International Business Machines Corporation | Device function disablement during vehicle motion |
US9037125B1 (en) | 2014-04-07 | 2015-05-19 | Google Inc. | Detecting driving with a wearable computing device |
CN104112362B (en) * | 2014-06-19 | 2017-02-01 | 深圳科隆科技有限公司 | Help calling method and system for vehicle |
-
2015
- 2015-05-15 US US14/713,008 patent/US9505365B1/en active Active
-
2016
- 2016-05-09 CN CN201610302271.1A patent/CN106162551B/en active Active
- 2016-05-09 MX MX2016006033A patent/MX364759B/en active IP Right Grant
- 2016-05-11 DE DE102016108723.8A patent/DE102016108723A1/en active Pending
- 2016-05-13 RU RU2016118603A patent/RU2713702C2/en active
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2018113087A1 (en) * | 2016-12-24 | 2018-06-28 | 华为技术有限公司 | Method and device for determining geographical location of user taking a vehicle |
US10388084B1 (en) * | 2017-01-19 | 2019-08-20 | State Farm Mutual Automobile Insurance Company | Systems and methods for providing vehicular collision data |
US10909778B1 (en) * | 2017-01-19 | 2021-02-02 | State Farm Mutual Automobile Insurance Company | Systems and methods for providing vehicular collision data |
CN109741631A (en) * | 2019-02-01 | 2019-05-10 | 南京沃旭通讯科技有限公司 | A kind of relative position detection device and its working method |
US11130446B2 (en) * | 2019-10-15 | 2021-09-28 | Robert Bosch Gmbh | System to detect objects ejected from a vehicle |
US20220215954A1 (en) * | 2020-08-09 | 2022-07-07 | Kevin Patel | System for remote medical care |
US11664124B2 (en) * | 2020-08-09 | 2023-05-30 | Kevin Patel | System for remote medical care |
US20220051493A1 (en) * | 2020-08-14 | 2022-02-17 | Kennith Burks | Systems and methods for an automobile status recorder |
WO2024046674A1 (en) * | 2022-08-30 | 2024-03-07 | Robert Bosch Gmbh | A controller to determine crash information of a vehicle and method for the same |
Also Published As
Publication number | Publication date |
---|---|
CN106162551A (en) | 2016-11-23 |
MX2016006033A (en) | 2016-11-14 |
CN106162551B (en) | 2021-08-06 |
DE102016108723A1 (en) | 2016-11-17 |
RU2016118603A (en) | 2017-11-16 |
RU2016118603A3 (en) | 2019-07-24 |
MX364759B (en) | 2019-05-06 |
US9505365B1 (en) | 2016-11-29 |
RU2713702C2 (en) | 2020-02-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9505365B1 (en) | Wearable data management during an incident | |
US9544742B2 (en) | Determining vehicle occupant location | |
US9510159B1 (en) | Determining vehicle occupant location | |
US9630628B2 (en) | Hand-on steering wheel detection | |
CN106162558B (en) | Determining vehicle occupant position | |
JP6520800B2 (en) | Occupant information acquisition system | |
US10986466B2 (en) | System and method for locating a portable device in different zones relative to a vehicle based upon training data | |
EP3748589B1 (en) | Fault tolerant vehicle communication and control apparatus | |
JP7210881B2 (en) | Vehicle authentication system | |
CN106965674A (en) | When occupant undergoes potential illness for operating the method and system of vehicle | |
US20170103592A1 (en) | Automated door and gate lock/unlock | |
EP2492877B1 (en) | Electronic key system | |
US11818630B2 (en) | System and method for locating a portable device in different zones relative to a vehicle and with device zone indicators | |
JP2008509611A (en) | Two-way radio monitoring system | |
JP6287714B2 (en) | Electronic key system | |
US11760360B2 (en) | System and method for identifying a type of vehicle occupant based on locations of a portable device | |
CN106143368B (en) | Computer and method for determining the position of a vehicle occupant | |
JP2017133226A (en) | Vehicle door lock control device and vehicle door lock system | |
JP2017182347A (en) | Vehicle communication system, vehicle peripheral information transmission method, and control program | |
JP5928878B2 (en) | Control system | |
JP6424098B2 (en) | Equipment control system | |
JP2006224894A (en) | Control device for vehicle, control system for vehicle, control method for vehicle and electronic instrument | |
US20190351872A1 (en) | Enhanced vehicle door lock | |
JP2023173767A (en) | Vehicle control system, vehicle control program, and position confirmation device |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: FORD GLOBAL TECHNOLOGIES, LLC, MICHIGAN Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:VAN WIEMEERSCH, JOHN ROBERT;REEL/FRAME:035645/0863 Effective date: 20150507 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 8 |