Method and device for vehicle occupant position detection

Abstract

System, comprehensive: a processor that is configured to: to determine the position of a wirelessly identified device within a vehicle; to obtain a locking scheme associated with the device and to determine locking states for vehicle systems with child safety locks; and to determine which of the vehicle's child safety systems are within a predefined proximity to the location of the device; and to set the locking states, based on the locking scheme, of vehicle systems with child safety locks in the predefined proximity to the position of the device.

Description

TECHNICAL AREA

[0001] The exemplary embodiments generally relate to a method and a device for detecting the position of vehicle occupants. BACKGROUND

[0002] Determining the presence, dwell time, and position of passengers and drivers inside and outside a vehicle can be useful for many purposes. Current occupant detection and positioning systems utilize cameras, seat sensors, and detection via key fobs or mobile devices. While suitable for many applications, each of these systems has some drawbacks.

[0003] Camera systems can be expensive due to the necessary computing power and optical requirements that allow a vision system camera to distinguish one face from another. Additionally, the user to be recognized must be within the camera's field of view and must not have any obstructions (scarf, coat collar, hat, etc.) that obscure a recognizable part of their face. Furthermore, environmental conditions, such as glare from excessive sunlight, shadows, or a dark environment, can cause difficulties in face recognition.

[0004] Seat sensors were presented as another occupant detection option. These sensors can detect weight in a seat, but they cannot necessarily distinguish between objects and an occupant. Furthermore, since several people may have similar weights, the sensor may have difficulty assigning an identity to a detected occupant.

[0005] Key fob recognition can be used to identify a driver and any other occupant carrying a key fob. A problem with this solution is that another party (spouse, child) could be carrying the key fob, and the system might not be able to distinguish which party is carrying it.

[0006] Similarly, mobile phone detection can work reasonably well because a person typically only carries their own phone and no others. Shared phones and phones left in vehicles can cause challenges. For example, a party might be misidentified if they possess another party's phone, or a phone left in a vehicle might be identified as belonging to an absent party.

[0007] If a vehicle can accurately identify and locate individual occupants, the vehicle can utilize a variety of useful, related services based on the identified occupants and their associated positions.

[0008] German patent application DE 10 2004 041 879 A1 describes a classifying seat occupancy detection device that distinguishes whether a particular seat is occupied by an adult, a small child, or not at all. Depending on this classification, the door lock assigned to that seat is switched either to a child-resistant mode or to a non-child-resistant mode.

[0009] Document DE 10 2004 045 819 A1 further describes a motor vehicle with a child safety device that controls an electrically controlled buckle of a safety belt of a vehicle seat to lock against a mechanical opening.

[0010] Furthermore, the document DE 10 2015 105 397 A1 describes methods and systems for detecting the operation of a vehicle door, wherein a sensor detects when a vehicle door is operated from the vehicle interior. A processor coupled to the sensor provides at least a notification when the vehicle door is operated from the vehicle interior, whereby the processor may also initiate further actions, for example, unlocking all non-childproof doors when a door is operated.

[0011] WO 2015 / 030 710 A1 further describes an individually configurable control device for controlling various vehicle functions of a vehicle, whereby in particular electronic devices of vehicle occupants, especially in the form of so-called wearables, are read out in order to make preference settings on the vehicle such as seat settings. SUMMARY

[0012] Against the background described above and the problems arising therefrom, the present invention proposes a system according to claim 1, a computer-implemented method according to claim 17, and a computer-implemented method according to claim 19. Preferred embodiments of the invention are the subject of the dependent claims.

[0013] The system therefore includes a processor configured to determine the position of a wirelessly identified device within a vehicle. The processor is also configured to determine an interlock scheme associated with the child safety lock device and to apply the interlock scheme to corresponding systems within a defined proximity of the identified device's position.

[0014] Furthermore, the computer-implemented method includes setting the states of child safety vehicle systems based on predefined state settings associated with an identified wireless device for which a device location within a vehicle has been identified, wherein the child safety vehicle systems are located within a predefined proximity to the device location.

[0015] In another aspect, the computer-implemented method involves retrieving an interlock scheme that defines state settings for a child safety system. This scheme is associated with a wireless device located within a vehicle at a specific position within the vehicle. The method also includes applying the interlock scheme to the child safety systems within the vehicle at a predefined proximity to this specific position, so that the child safety systems are set to states defined by the interlock scheme. BRIEF DESCRIPTION OF THE DRAWINGS Fig. Figure 1 shows an example of a vehicle computer system; Fig. 2 shows an example of a vehicle environment; The Fig. 3A and Fig. 3B shows an example of identification transfer; Fig. Figure 4 shows an exemplary procedure for facility registration and reporting; The Fig. 5A and Fig. Figure 5B shows an exemplary procedure for facility localization and registration; Fig. Figure 6 shows an exemplary procedure for setting a locking state; Fig. Figure 7 shows an exemplary procedure for creating an institution's profile; and Fig. Figure 8 shows an exemplary procedure for setting and uploading a locking scheme. DETAILED DESCRIPTION

[0016] Fig. Figure 1 illustrates an exemplary block structure for a vehicle-based computer system 1 (VCS) for a vehicle 31. An example of such a vehicle-based computer system 1 is the SYNC system, manufactured by THE FORD MOTOR COMPANY. A vehicle equipped with a vehicle-based computer system may include a visual front-end interface 4 located in the vehicle. The user may also be able to interact with the interface, if provided, for example, via a touchscreen. In another exemplary embodiment, interaction is achieved by pressing buttons, a voice dialogue system with automatic speech recognition and speech synthesis.

[0017] At the in Fig. In the exemplary embodiment 1 shown, a processor 3 controls at least part of the operation of the vehicle-based computer system. The processor, located in the vehicle, enables the processing of instructions and routines within the vehicle. Furthermore, the processor is connected to both non-persistent and persistent memory 7. In this exemplary embodiment, the non-persistent memory is random-access memory (RAM), and the persistent memory is hard disk storage (HDD) or flash memory. In general, persistent (non-volatile) memory can include any form of storage that retains data when a computer or other device is powered off.

[0018] These include, but are not limited to, HDDs, CDs, DVDs, magnetic tapes, solid-state drives, portable USB drives and any other suitable form of permanent storage.

[0019] The processor is also equipped with a number of different inputs, allowing the user to connect to it. In this exemplary embodiment, a microphone 29, an auxiliary input 25 (for input 33), a USB input 23, a GPS input 24, a screen 4 (which can be a touchscreen), and a Bluetooth input 15 are all provided. An input selector 51 is also provided to allow the user to switch between different inputs. Inputs from both the microphone and the auxiliary input are converted from analog to digital by a converter 27 before being forwarded to the processor. Although not shown, many of the vehicle components and auxiliary components connected to the VCS can use a vehicle network (such as a CAN bus, among others) to transmit data to and from the VCS (or components thereof).

[0020] Outputs on the system can include, among other things, a visual display 4 and a speaker 13 or a stereo system output. The speaker is connected to an amplifier 11 and receives its signal from the processor 3 via a digital-to-analog converter 9. Output can also be made to a remote BLUETOOTH device, such as a PND 54, or a USB device, such as the vehicle navigation device 60, along the bidirectional data streams shown at 19 and 21, respectively.

[0021] In one exemplary embodiment, the system 1 uses the BLUETOOTH transceiver 15 to communicate with a user's mobile device 53 17 (e.g., mobile phone, smartphone, PDA, or any other Wi-Fi-enabled device). The mobile device can then be used, for example, to communicate with a network 61 outside the vehicle 31 by communicating 55 with a cell tower 57 59. In some embodiments, the tower 57 may be a Wi-Fi access point.

[0022] An example of communication between a mobile device and the BLUETOOTH transmitter-receiver is represented by signal 14.

[0023] Pairing a mobile device 53 with the BLUETOOTH transmitter-receiver 15 can be initiated by a button 52 or a similar input. Accordingly, the CPU is instructed to pair the vehicle's integrated BLUETOOTH transmitter-receiver with the mobile device's BLUETOOTH transmitter-receiver.

[0024] Data can be communicated between the CPU 3 and the network 61, for example, using a data plan, voice data, or DTMF tones associated with the mobile device 53. Alternatively, it may be desirable to provide an onboard modem 63 with an antenna 18 to communicate data between the CPU 3 and the network 61 via the voice band 16. The mobile device 53 can then be used, for example, to communicate with a network 61 outside the vehicle 31 by communicating 55 with a mobile phone mast 57 59. In some embodiments, the modem 63 can establish a connection 20 with the mast 57 to communicate with the network 61. As a non-limiting example, the modem 63 could be a USB mobile modem and the communication 20 could be a mobile phone communication.

[0025] In one exemplary embodiment, the processor is equipped with an operating system, including an API for communicating with modem application software. The modem application software can access an embedded module or firmware on the Bluetooth transceiver to establish a wireless connection with a remote Bluetooth transceiver (such as one in a mobile device). Bluetooth is a subset of the IEEE 802 PAN (Small Local Area Network) protocols. IEEE 802 LAN (Local Area Network) protocols include Wi-Fi and have considerable cross-functionality with IEEE 802 PAN. Both are suitable for wireless communication within a vehicle. Other communication methods that can be used in this area include free-space optical communication (such as IrDA) and non-standard consumer IR protocols.

[0026] In another embodiment, the mobile device 53 includes a modem for voice-band or broadband data communication. In the data-over-voice embodiment, a technique known as frequency-division multiplexing can be implemented, where the owner of the mobile device can speak while data is being transmitted. At other times, when the owner is not using the device, the entire bandwidth can be used for data transmission (300 Hz to 3.4 kHz in one example). While frequency-division multiplexing may be familiar and is still used in analog mobile communication between the vehicle and the internet, it has been largely replaced by hybrid code-division multiplexing (CDMA), time-division multiplexing (TDMA), and space-division multiplexing (SDMA) for digital mobile communication.If the user's mobile device is associated with a data plan, the plan may allow broadband transmission, enabling the system to utilize a significantly greater bandwidth (thereby increasing the data transmission speed). In yet another embodiment, the mobile device 53 is replaced by a cellular communication device (not shown) installed in the vehicle 31. In a further embodiment, the ND 53 can be a wireless local area network (LAN) device that can communicate, for example (and without limitation), via an 802.11g network (i.e., WiFi) or a WiMAX network.

[0027] In one embodiment, incoming data can be forwarded by the mobile device via data over voice or a data plan, through the onboard Bluetooth transceiver, and into the vehicle's internal processor 3. In the case of certain temporary data, the data can be stored, for example, on the HDD or another storage medium 7 until the data is no longer needed.

[0028] Additional sources that can establish a connection with the vehicle include a personal navigation device 54, for example, with a USB port 56 and / or an antenna 58, an in-vehicle navigation device 60 with a USB port 62 or other connection, an onboard GPS device 24, or a separate navigation system (not shown) with network connectivity 61. USB is one of a class of serial network protocols. The serial protocols IEEE 1394 (FireWire™ (Apple), i.LINK™ (Sony), and Lynx™ (Texas Instruments)), EIA (Electronics Industry Association), IEEE 1284 (Centronics Port), S / PDIF (Sony / Philips Digital Interconnect Format), and USB-IF (USB Implementers Forum) form the backbone of serial device-to-device standards. The majority of these protocols can be implemented for either electrical or optical communication.

[0029] Furthermore, the CPU could be connected to a variety of other auxiliary devices 65. These devices could be connected via a wireless 67 or wired 69 connection. Auxiliary devices 65 could include, but are not limited to, personal media playback devices, wireless health devices, portable computers, and the like.

[0030] Alternatively, the CPU could also be connected to a vehicle-based wireless router 73, for example, using a WiFi transmitter-receiver 71 (IEEE 803.11). This would allow the CPU to connect to remote networks within range of the local router 73. The CPU can also connect to location-based transmitter-receivers, such as those described in the exemplary embodiments contained in this document.

[0031] In addition to the execution of exemplary methods by a vehicle computer system located in a vehicle, the exemplary methods can, in certain embodiments, be executed by a computer system connected to the vehicle computer system. Such a system may include, among other things, a wireless device (e.g., a mobile phone) or a remote computer system (e.g., a server) connected via the wireless device. Together, such systems can be referred to as vehicle-associated computer systems (VACS). In certain embodiments, specific components of the VACS can execute specific parts of a method, depending on the specific implementation of the system.If a procedure includes, for example, and without limitation, a step of sending or receiving information with a coupled wireless device, it is likely that the wireless device will not perform that part of the procedure, since the wireless device would not be "sending and receiving" information to or from itself. A person skilled in the art will understand when it is inappropriate to apply a particular computer system to a particular solution.

[0032] With regard to the exemplary embodiments shown in the figures illustrating exemplary process flows, it should be noted that a general-purpose processor can be temporarily activated as a special-purpose processor for the purpose of executing some or all of the example procedures shown by these figures. When code is executed that provides instructions for performing some or all of the steps of the procedure, the processor can be temporarily reactivated as a special-purpose processor until the procedure is completed. In another example, to a reasonable extent, firmware acting in accordance with a pre-configured processor can cause the processor to act as a special-purpose processor intended for the purpose of executing the procedure or a reasonable variation thereof.

[0033] The exemplary embodiments utilize Bluetooth Low Energy (BLE) or other wireless signals to detect user wearables and triangulate user positions within a vehicle. Since a wearable (such as a wristwatch) is typically worn by its owner, and such a device is not usually left in the vehicle, tracking the position of a wristwatch or similar device and assigning a predicted owner (typically the owner) can result in a much higher detection rate. Furthermore, if the device incorporates biometric feedback, it may be able to distinguish between multiple wearers, providing even greater assurance that an owner prediction is accurate.

[0034] The exemplary embodiments use modules that include internal components with integrated wireless sensing and communication capabilities. Since these modules are capable of both detecting wireless device signals and transmitting them to a central storage unit, they are plug-and-play, allowing existing vehicles to be easily retrofitted with occupant position tracking. By using multiple modules, the user's position can be triangulated based on signal strength, thus enabling the position of wearables (and presumably the owner) within a vehicle to be determined by the modules in conjunction with a central system.

[0035] Fig. Figure 2 shows an exemplary vehicle environment. In this example, there are four occupants 213, 215, 217, 219 in a vehicle 201. The vehicle cabin is equipped with modules integrated into the ceiling lights 203, 205, 207, 209, and this or a similar arrangement of modules provides a line of sight (useful to prevent signal attenuation) to most positions in the vehicle as well as from each module to the central receiver 211.

[0036] In this example, the driver 213 is wearing a smartwatch 221, as are the front passenger 215 (wristwatch 223) and the occupant 217 behind the driver (wristwatch 225). The occupant 219 is holding a tablet or computer 227, which can also be detected.

[0037] Wearables typically transmit a presence signal; thus, any wearable 221, 223, 225 can periodically or continuously transmit a presence announcement via BLE or another wireless medium. On the other hand, devices such as a tablet or computer 227 may require explicit instructions to transmit a signal, or they may require the execution of a detectable application. Unless the tablet automatically identifies itself to local wireless receivers, it may be easier to identify a person using a wearable than using another of its own wireless devices.

[0038] It is also far less likely that an occupant would remove a wristwatch and pass it to another occupant. However, it is more likely that the tablet or computer 227 will be passed from occupant to occupant or stored in a center console, under a seat, etc. Thus, it may be difficult to determine both the person who possesses the tablet or computer and the location of that person within the vehicle. While this logic demonstrates that users of portable devices are more easily identified than tablet users, it is not intended to suggest that the exemplary embodiments cannot be carried out using non-portable wireless signal-providing devices.

[0039] Any device capable of self-identification can transmit a signal that can be detected by modules 203, 205, 207, and 209. Module 209 is likely to receive a stronger signal from wristwatch 221 than, for example, module 203. A signal of medium strength (relative to the other signals) will be received by module 207. Module 205 is likely to receive a weak or the weakest signal. This information (the received signal strength indicator, known as RSSI) can be used to determine that the owner of wristwatch 221 is closest to module 209 (the driver's seat). Similar determinations can be made for the positions of the other devices in the cabin based on the received signal strength corresponding to each device at each module (or each module receiving a signal).

[0040] The Fig. 3A and Fig. Figure 3B illustrates the identification transmission. In these examples, the modules act as relays, receiving signals from devices located inside the cabin (or otherwise within communicable proximity to the module) and transmitting these signals along with an RSSI for each signal from each device. The device can also have a unique identifier integrated into the signal it transmits, allowing for signal differentiation on a device-to-device basis.

[0041] In Fig. 3A Modules 203, 205, 207 and 209 each receive a signal from the device 221 worn by the driver. In Fig. 3B transmits the signal from each module to a centralized processing unit 211. This unit can track the occupant's position, track occupant profiles, track frequent occupants (e.g., frequent users), and upload any or all of this information to the cloud.

[0042] If an occupant's position and identification are known, then any settings or preferences displayed by that occupant can also be known and associated with that occupant's identity. For example, a person in a rear passenger seat who watches action movies in one vehicle (i.e., that the specific individual actively selects media) may have an action movie preference reflected in that profile for media suggestions in another vehicle. Similarly, seat settings, HVAC settings, and any other detectable vehicle configurations or preferences can be tracked based on the occupant, associated with a profile, uploaded to the cloud, and retrieved should that user ever be in a similarly equipped vehicle.This allows preferences to be transferred from vehicle to vehicle, regardless of where the specific user is located within a specific vehicle (assuming that a corresponding setting can be made at the current position).

[0043] Fig. Figure 4 shows an exemplary procedure for setup detection and reporting. In this example, the procedure begins searching for setup signals 401 after the vehicle has started (or in a background application running at low power). Since most wearables announce their position via BLE or other wireless signals, each module can determine whether any detectable BLE or other wireless signals are present 403.

[0044] When a signal is received, a small check is performed at the module in this example. First, the procedure determines whether the signal originates from another module (rather than from a facility). 405 Since each module transmits signals from the facilities, misidentification of facility information and location could occur if a module misinterprets a signal from another module as a facility signal, had those signals not been identified as originating from other modules. Accordingly, the transmitted signal may be encapsulated in a way that clearly distinguishes it from a facility signal.

[0045] In this example, the procedure also determines whether the vehicle has been in motion for longer than a threshold time quantity 407. If the vehicle has been moving for a certain period of time, it is unlikely that the detected signal relates to a new occupant (i.e., an occupant not previously detected), since people do not typically enter moving vehicles. Likewise, the module determines whether the doors have been closed for more than a threshold time quantity 409, since occupants do not typically enter through windows.

[0046] Although these checks 407 and 409 can help prevent redundancies, the procedure may also be designed to omit one or both checks, as some devices simply are not switched on before a certain point in a journey. Whether these or other check steps are included is largely a matter of design choice. Once it has been confirmed that the signal is not from another module, that the vehicle has not been in motion for longer than the threshold time, and that the doors have not been closed for longer than the associated threshold time, the signal is transmitted to the central processor 411 in this example.

[0047] Fig. Figure 5 shows an exemplary procedure for facility localization and registration. In this illustrative example, the processor receives a signal from one of the 501 modules. Each module that receives a signal from a specific facility reports this signal to the central processor, so that RSSI, in conjunction with the facility's ID (such as MAC address), can be used to triangulate the facility's location.

[0048] In this example, each signal has an integrated MAC address that identifies the device that originally identified itself to the transmitting module. Other suitable unique identifiers can also be used.

[0049] If the MAC address is in a database with a 503 status (meaning the signal has already occurred at least once), the procedure updates a 505 entry associated with that MAC address (and the device) within the database. This might include updating a timestamp associated with the received signal, as well as an updated RSSI (if the device has moved). Information about which module transmitted the signal is also included, so the database entry for each MAC address contains details about which devices detected the wearable's signal and the time.

[0050] If the MAC address is not stored, a new setup entry is created in the database (507). This can be a temporary or permanent entry, although the entry in this example is initially temporary. Along with adding the setup to the database, the reporting module, signal strength, timestamp, and any other relevant information are stored.

[0051] The procedure will determine for each wearable(i) already stored in the database whether any information has been received within a threshold period 509. For example, the procedure may run until the vehicle has been moving for two minutes, or until ten minutes have passed since the vehicle was started, or until the doors have been closed and the vehicle is moving, or until any other suitable threshold is determined that all occupants should be in the vehicle at that point and therefore signals should be received from all available devices and the positions of the devices should be relatively unchanged (in relation to the seat).

[0052] If a notification for a specific wearable has not yet been received and a threshold period has elapsed, the procedure can remove that wearable from the database. In this example, the database can contain permanent or temporary entries. The permanent entries can include users identified as frequent occupants (by detection or occupant instruction). Profile information and other useful information (preferences, settings, etc.) can be stored locally for these occupants. A counter for any identified devices can be stored so that a vehicle can count how often a specific device is observed to determine whether the device should be stored in the permanent part of the database.

[0053] The temporary database can contain information relating to all devices present in a vehicle for a specific trip. An entry for a specific device can be removed from the system after the trip ends, or it can remain until a trip in which that device is not reported (and is thus removed based on non-reporting). In this example, the procedure determines whether information about all expected wearables(i) in the database has been received.

[0054] If a database contains, for example, entries for four institutions 221, 222, 223 and 225, and these are in Fig. Given the occupant configuration shown in section 2, each facility 221, 223, and 225 will eventually report itself via these modules. Since facility 222 is currently not present (or shown), it will not report itself.

[0055] Before the threshold period or other journey initiation signals appear, step 513 will report "no" because information about facility 222 has not yet been received (since this specific facility is in Fig. 2 is not present). Once the threshold is exceeded, facility 222 is removed from the temporary database and step 513 will report "yes" because at least some information has been received about all present facilities that are also registered in the temporary database.

[0056] The procedure then triangulates the position of each of the 515 wearables. Although triangulation can be a continuous process or determined whenever a new signal is received (assuming sufficient data for triangulation is available), in this example, triangulation is delayed until the journey has begun (the initial threshold or sign). Each device and predicted owner is assigned a position within the vehicle, and all associated profile information is accessible and used as appropriate for that person at that position. As an alternative to triangulation, or as an alternative description of triangulation, the device position can be determined by which a relay module identifies the strongest received signal strength (RSSI).The setup of a seating position is assigned or associated with an associated or assigned relay module. This implementation may depend on the specific deployment positions of the relay transmitter-receivers, as a transmitter-receiver positioned equidistant between two seating positions may not be able to identify a nearby setup without additional information.

[0057] If the facility reports an owner identity (for example, determinable through biometric data), this information can also be used to identify the owner more precisely. If the owner is unexpected (i.e., not the previously observed owner), a profile can be created for this owner, and the facility can be associated with multiple owners. Additionally or alternatively, a facility profile can be modified to reflect multiple possible owners.

[0058] If a wearable is detected more than a threshold count 517 (which may be based on a counter associated with detecting the presence of a specific wearable for multiple trips), the procedure can add that wearable (i) to the persistent database 521. This database stores an entry for that owner and / or establishment as a frequent occupant / establishment, and local profile information can be stored, updated, and / or created as needed. The frequent occupant identification procedure can be completed for each wearable 519 as long as any wearables (i) remain for which the procedure has not yet been completed 523.

[0059] Likewise, each wearable(i) in the frequently occurring persistent database can have an associated location or locations. When a new or unexpected location is determined with respect to a specific wearable(i) 525, the procedure can update an entry about where that person is currently located and where that person frequently sits 527. Finally, in this example, the information about the wearables, their locations, and any associated profiles and / or settings or setting changes can all be uploaded to the cloud 529.

[0060] Using plug-and-play modules, any vehicle can be retrofitted with an occupant detection and positioning system. Simply by wearing a wearable device, individual occupant positions can be captured and tracked, and occupant setting changes and preferences can be stored in the cloud for easy retrieval, allowing settings to be ported from vehicle to vehicle. While precise owner identification cannot be guaranteed, a much more accurate identification of specific occupants and their corresponding positions can be achieved.

[0061] A non-limiting example of a use for the embodiments of the setup detection and position detection and the like described herein is the automatic activation or deactivation of child safety locks on vehicle doors. A typical child safety lock comprises a switch or physical latch that prevents a door from being opened from the inside, regardless of whether the door is unlocked or not. The controls can, if desired, also be applied to the windows, thereby preventing, for example, any or a specific setting, or at least the lowering of the window.

[0062] Further improvements can be made to the child restraint concept, such as, but not limited to, the exclusion of: seat adjustment, climate control for the rear seat(s), messaging or other electronic features for the rear seats, entertainment system controls (limited or no control based on locking states), electronic interfaces, etc. In general, the exemplary embodiments can provide controls over any electronic or manual system that features user interaction and is also designed for selective control. Embodiments can include a configurable set of options so that a parent or driver can control what is set and when, based on which child restraints are activated.Since the exemplary embodiments provide a method for identifying a facility position (and thus an owner position), specific configurations can be made on a facility-to-facility (or owner-to-owner) basis. The exemplary embodiment allows locking system state changes (lock / unlock) to be applied automatically in response to certain facilities being detected or being detected in specific positions. Manual changes (via a human-machine interface (HMI) input) can also be applied in relation to a specific trip.

[0063] For example, if Child A is nine and Child B is four, a Child A device located in the back seat can exclude door controls but not entertainment controls, and a Child B device can exclude both. Or, for example, if Child A's device is on the left and Child B's device is on the right, both doors can be excluded, entertainment controls but not HVAC controls on the left can be allowed, and everything on the right side from a control perspective can be locked. This is a non-restrictive example of how user-specific system exclusion can be applied at a finer level. A more general example involves simply excluding door / window use for children of a certain age or specific parties.In yet another example, the child safety lock could only be activated when a vehicle is moving, or when the vehicle is moving, only for children of a certain age (i.e., the door of the nine-year-old child can be unlocked when the vehicle stops, the door of the four-year-old child can remain locked, even though the corresponding device is detected near that door, regardless of the driving condition).

[0064] In this example, facility profiles and / or user profiles can also be created for facilities, stored locally, and uploaded to the cloud (or uploaded to the facility itself). For example, if a locking scheme is set for a particular facility, the profile associated with the facility (and / or its owner) can be uploaded, and entering other vehicles with that facility can trigger the application of similar settings.

[0065] In another example, facility settings can be applied until pre-configured vehicle settings for another vehicle dictate a safer setting state. This prevents the personal preference settings of the other vehicle's driver from being overridden by the presence of a facility with competing settings. Age-based controls could also be applied, so that, for example, a 16-year-old facility owner could have personalized settings that override vehicle settings, while more restrictive settings would be applied to, for example, a 4-year-old facility owner (i.e., either facility or vehicle settings would be overridden, based on which provides less control over the vehicle's features).

[0066] If the driver's age (or another characteristic) is not included in a profile, a preset default for a device could be used. This could involve applying a generic default for devices of a particular type or category, applying specific defaults for devices typically associated with adults (e.g., a smartwatch) and different defaults for devices typically associated with children (e.g., a smartwatch for children, a phone for children, etc.). Usage demographics can be used to broaden the age ranges for device use (e.g., while not impossible, it is unlikely that a three-year-old child would own a personal mobile phone).

[0067] Fig. Figure 6 shows an exemplary method for setting a locking state. In this illustrative example, the method identifies one or more devices present in the vehicle, in accordance with the exemplary embodiments already presented. Thus, the system determines devices and associated positions for some or all devices, as well as which owners are likely to be in the same position as these devices. Accordingly, the method can communicate with the device 601 for at least one identified device or position for which locking controls exist. This communication can include receiving the device signal or receiving a transmitted device signal.As used in this description, communication does not necessarily mean that the process (which, for example, runs on a vehicle computer) communicates directly with the device, although such communication is possible in some implementations.

[0068] For each unit (or for a representative unit for each position if more than one unit is present in a single seating position), the device determined the position of the unit within the vehicle 601. This can be done, for example, in accordance with the embodiments presented here for determining unit positions.

[0069] If any of the facilities are identified as associated with a child 605, the procedure activates door / control interlocks near the systems corresponding to the seating position of the facility(ies) 607. Facilities can be identified as child facilities in a variety of ways. For example, a profile (local or in the cloud) may exist that is associated with a facility or a known facility owner and that corresponds to the identity of a child. Or the facility itself may be classified as a child facility (such as an electronic, shock / splash-resistant facility designed for children).In the future, it is also possible that any number of children's toys will be equipped with Bluetooth or another wireless function and can be described, identified, located, and associated with a child in the same way as the phones / tablets / wearables in the examples mentioned here. Child location tracking devices are another example of child devices that can be identified and located.

[0070] Each facility can have a preset profile that defines which systems are locked for the associated owner based on the facility's presence. If no such profile exists, a default locking scheme can be used (including, among others, "lock all").

[0071] If any facility is identified as associated with an adult (609), the procedure can likewise disable all locks near those facility locations (611). Just as facilities can be identified as adult or child facilities, a known user profile for a typical facility occupant can identify the owner / occupant as an adult or a child, allowing similar actions to be taken. That is, a typical adult facility may be specifically known to be frequently occupied by a child, so the profile can dictate child actions instead of adult actions, even if the facility itself is an adult facility. By disabling locks for known adults, the procedure can prevent adult occupants from being locked out of the system control.

[0072] If one or more unknown devices are present 613 for which no profile is stored or no suitable estimate can be made regarding the owner's age, the procedure in this example may present a human-machine interface (HMI) in the vehicle or on a device belonging to the driver or another known adult 615. The HMI may then be used to select locking options for each device whose location has been identified.

[0073] For example, if the driver selects "lock" for a left rear seat (generally for all lockable systems or specifically for some lockable systems), the procedure can associate the known facility occupant with a state that should involve locking the associated systems. Thus, if any locks are manually instructed to activate, the procedure activates the associated locks and can further (if desired) designate this facility and / or this user (if the user can be distinguished from the facility) as a child. Additionally or alternatively, the locking scheme for this user (in this position or generally) can be stored with respect to this facility profile and / or user profile.

[0074] For some facilities, it may be possible to uniquely identify different owners (for example, biometric data can be used to differentiate between multiple owners), while for others, a facility profile can simply be created based on the assumption that it corresponds to a frequent user. It is also possible to develop profiles at a more granular level, for example, profiles of specific users with a particular facility in a specific location. On the other hand, a user-agnostic locking scheme can be applied generally to a facility for use in any suitable location.

[0075] If any systems are manually disabled for a particular facility or user (if locks already in use are now manually instructed to be unlocked by the HMI) 623, the procedure registers the instructed locks (or all locks) being disabled 625 and the facility as associated with an adult (or otherwise stores the locking scheme) 627.

[0076] By maintaining the scheme in a facility-to-facility, user-to-user, vehicle-to-vehicle, or a combination of the above, a specific or general locking scheme can be developed for particular vehicles or in general. Since this information can be uploaded to profiles stored in the cloud, the data can be retrieved to apply various settings. For example, settings for a rental vehicle can help ensure that a parent doesn't forget to activate child safety locks or consult the vehicle's manual to determine which features the vehicle may have and how to activate specific features.

[0077] Fig. Figure 7 shows an exemplary procedure for facility profiling. Again, a certain form of communication (direct, transmission of the ID, etc.) is used between the procedure and the individual facility(ies) (Figure 701). In this example, for each facility for which a determination is to be made, a facility ID and possibly a facility type are received (Figure 703) (by direct query or, for example, transmission of a facility signal, as discussed here). When used, facility types can, for example, help to identify the facility and its associated settings based on a specific user classification, such as a child or adult. Facility types can also include such facility classifications as a wearable, tablet, phone, etc.It is also possible to obtain information about user type and facility type after receiving a facility ID embedded in a transmitted signal. For example, the received facility ID may include a facility brand and / or model, which can be used to access a lookup table containing information about the facility type.

[0078] If a user profile or facility profile has already been created for a specific facility / facility ID, so that the facility is known, 705, the procedure accesses a previously stored locking scheme 707. Depending on the level of detail of the scheme, this could be a general scheme (for all vehicles), a position-in-vehicle scheme (for all vehicles based on facility position within the vehicle), a user-specific scheme (if the user / owner is identified), a vehicle-specific scheme, etc.

[0079] Of course, various other versions can also be used, which differ from the specific illustrative examples.

[0080] If the facility is unknown, but the facility type is known as a childcare facility (709), the procedure saves a profile for the facility as a childcare facility (711) and takes all actions already assigned to childcare facilities. This could include a predefined set of actions, a driver-defined set of actions, or a set of actions defined in response to a prompt. Specific actions (lock scheme) can also be defined for a particular facility. In other examples, the identification of a facility type and / or the specific actions to be taken for a particular facility type or facility can be imported from a cloud profile for the facility / user.

[0081] If the device itself is unknown, but the device type is identified as associated with an adult (713), the procedure stores the profile for the device as an adult device. Similar to the child device mentioned above, generic or specific unlocking / locking actions can be used, which may include defining this action for the device in other vehicles and / or defining this action in relation to a single vehicle.

[0082] It is also possible for child-parent relationships to be established for facilities, whereby only the presence of a parent facility can define a permanent, or at least cloud-persistent, locking scheme for a child facility. This prevents other parents (for example, in a carpool) from redefining an occupant facility locking scheme, possibly with the exception of their specific vehicles. Similarly, adult facilities can only be permanently defined on a vehicle-to-vehicle basis unless authorized by the facility owner.

[0083] If the facility is unknown and cannot be identified as an adult or child facility, the procedure can simply wait for a locking scheme (lock / unlock nearby systems) 717 to be defined for that facility. Once defined, the profile can be saved locally for that facility 719 and / or, if applicable, uploaded to the cloud. Storing a facility-specific scheme locally prevents the driver from having to redefine the scheme for every trip with typical occupants. Exporting (to the cloud) and importing (from the cloud) the scheme also allows for faster matching with desired settings, especially when traveling or when a family owns multiple vehicles.

[0084] Since not all vehicles have the same settings, undefined settings can be locked or unlocked as needed, based on different assignments (e.g., an unrestricted adult assignment unlocks all undefined settings, while a child assignment locks all undefined settings). Unwanted locking or unlocking of settings can be easily changed by a driver or other authorized operator, for example, via the vehicle's HMI. A message can also be generated and displayed when certain default settings are applied, so the driver / authorized operator is aware of any potentially unexpected settings that have been applied.

[0085] Fig.Figure 8 shows an exemplary procedure for setting and uploading an interlock scheme. In this illustrative example, an HMI (Hardware Interface) is displayed (Figure 801). This can be displayed on a vehicle display corresponding to a driver's (such as a center console display) or front passenger's position. If a known adult or parent is located near a rear HMI, the display can alternatively be shown at that position. The person interacting with the display (also referred to as the controller) can modify or define the settings for each identified unit, any unit that does not have predefined settings, or any other suitable control scheme.

[0086] For example, the display can show a wireframe model or image of the vehicle, indicating equipment / positions / owners present and a status for each or all lockable systems. The operator or driver can then assign activation or deactivation of lockable systems based on their interaction with the display. A similar display can additionally or alternatively be shown on a display of the driver's or operator's device if the device is connected to the vehicle.

[0087] When changes are implemented (i.e., when any interlocks are instructed to be activated or deactivated), the procedure determines which interlocks have been activated (803). For systems that are manually interlocked via the HMI, the procedure determines whether any facilities are known to be nearby (805). These facilities can then be identified as childcare facilities (807), and the interlock scheme now defined can be associated with them, either locally and / or with respect to a profile that exists in the cloud.

[0088] If any lockouts are instructed to be deactivated by the HMI 809, and if any facilities are located near the deactivated lockouts 811, these facilities can be designated as adult facilities in a similar manner 813, and the lockout scheme can be permanently associated with them, either locally and / or in the cloud. It is also possible for a parent to initially activate all lockouts for a particular facility and later deactivate some, but not all, lockouts. It may be inappropriate to designate such a facility as an adult facility based on limited deactivation, with appropriate control mechanisms included as needed. For example, the adult designation may not occur in some cases unless all lockouts for a particular facility are deactivated.

[0089] If communication with one or more facilities is available (815), the locking settings in this example are also sent to the specific facilities to which the changes or assignments are applied. This allows the facility to identify a locking scheme itself, which can be especially useful for child facilities entering vehicles that cannot access the cloud but still need to use the locking scheme. For specific facilities (or all facilities, if desired), the owner can consent to the settings being saved and / or uploaded. When a parent-child relationship is established between a parent facility / vehicle and a child facility, the settings can be saved and / or uploaded automatically.Depending on requirements, the locking scheme changes / assignments are also uploaded to the cloud 817.

[0090] By using the portable locking schemes described here, a locking scheme can be created for various child safety systems in a multitude of situations. Based on different levels of detail, these can be defined generically or as specifically as possible for a facility, for example, for a user in a particular vehicle in a specific position. An implementer can decide which level of definition is appropriate for a given situation.

[0091] While representative embodiments have been described above, these embodiments are not intended to describe all possible forms of the invention. The terms used in the patent specification are descriptive rather than limiting, and it is understood that various modifications can be made without departing from the spirit and scope of the invention. Furthermore, the features of different implementing embodiments can be logically combined to form situation-appropriate variations of the embodiments described herein.

Claims

[1] System, encompassing: a processor that is configured to: to determine the position of a wirelessly identified device within a vehicle; to obtain a locking scheme associated with the device and to determine locking states for vehicle systems with child safety locks; and to determine which of the vehicle's child safety systems are within a predefined proximity to the location of the device; and to set the locking states, based on the locking scheme, of vehicle systems with child safety locks in the predefined proximity to the position of the device. [2] System according to claim 1, wherein the systems with child safety locks comprise child safety locks on vehicle doors. [3] System according to claim 1, wherein the systems with child safety locks comprise climate controls. [4] System according to claim 1, wherein the systems with child safety locks comprise entertainment controls. [5] System according to claim 1, wherein the processor is configured to obtain the locking scheme from a setup profile stored in the vehicle. [6] System according to claim 1, wherein the processor is configured to receive the locking scheme from a remotely stored setup profile, which is retrieved wirelessly by the processor. [7] System according to claim 1, wherein the systems with child safety locks comprise human-machine vehicle interfaces. [8] System according to claim 1, wherein the processor is configured to: to represent a human-machine interface (HMI) including selectable control via systems with child safety locks; To receive inputs to the HMI that instruct a state change of a system with child lock within the predefined proximity of the device; and to adapt the locking scheme associated with the facility based on the inputs received. [9] System according to claim 1, wherein the systems with child safety locks comprise seat adjustment controls. [10] System according to claim 1, wherein the processor is configured to: to categorize an institution for which no known profile exists as a childcare facility, and to obtain a predefined locking scheme for child safety devices stored in the vehicle as the locking scheme associated with the device. [11] System according to claim 10, wherein the processor is configured to categorize the facility as a childcare facility based on the fact that the facility wirelessly identifies itself as a childcare facility. [12] System according to claim 10, wherein the processor is configured to categorize the facility as a childcare facility based on a search of predefined categories of facilities using a facility identification obtained wirelessly from the facility. [13] System according to claim 1, wherein the processor is configured to: to categorize an institution for which no known profile exists as an adult institution, and a predefined locking scheme for adult facilities stored in the vehicle to obtain the locking scheme associated with the device. [14] System according to claim 13, wherein the processor is configured to categorize the facility as an adult facility based on the fact that the facility wirelessly identifies itself as an adult facility. [15] System according to claim 13, wherein the processor is configured to categorize the facility as an adult facility based on a search of predefined categories of facilities using a facility identification obtained wirelessly from the facility. [16] System according to claim 1, wherein the processor is configured to: to wirelessly upload a setup profile, including state settings for child safety vehicle systems associated with the setup, to a remote system. [17] Computer-implemented method, comprising: Obtaining a locking scheme associated with an identified wireless device, wherein the scheme defines locking state settings for child safety vehicle systems; Setting the states of vehicle systems with child safety locks based on the locking state settings, and wherein the systems are determined to be in a predefined proximity to a position of the device within a vehicle. [18] Method according to claim 17, wherein the predefined locking state settings are obtained from at least one of the following: from the facility, through wireless communication with the facility, from a locally stored facility profile, or from a remotely stored facility profile. [19] Computer-implemented method, comprising: Obtaining a locking scheme that defines locking state settings for a child safety system, wherein the scheme is associated with a wireless device inside a vehicle at a specific position within the vehicle; and Applying the locking scheme to the child safety systems inside the vehicle at a predefined proximity to the specified position, so that the child safety systems are set to the locking states defined by the locking scheme when the child safety systems are within the predefined proximity to the position of the device. [20] Method according to claim 19, wherein the method comprises retrieving the locking scheme from at least one of the following: from the device, by wireless communication with the device, from a locally stored device profile or a remotely stored device profile.

Images