SYSTEM COMPREHENSIVE OF A TELEMATICS CONTROL UNIT AND COMPUTER-IMPLEMENTED PROCEDURE

Abstract

System (100) comprising the following: a telematics control unit (114) and a control unit (108) connected to the telematics control unit (114) and several capacitive sensors (106), which is configured, to access notification settings (116) to determine a mobile device (118) to notify of a rain situation identified using the sensors (106); to instruct the telematics control unit (114) to send a rain warning to the mobile device (118) to receive confirmation to perform rain situation actions; To close vehicle doors in response to receiving confirmation; and to instruct the telematics control unit (114) to send a closing confirmation (608) indicating the rain situation actions performed to the mobile device (118); a vehicle control unit display (502) wherein the telematics control unit (114) is configured to display a user interface (500) for configuring the notification settings (116) on the vehicle control unit display (502) and to update the notification settings (116) in response to an input into the user interface (500); setting the notification settings (116): (i) which of the vehicle openings are to be closed in response to receiving the confirmation and (ii) which vehicle doors are to be unlocked in response to receiving the confirmation.

Description

TECHNICAL AREA

[0001] Aspects of the disclosure generally relate to a user interface for rain onset detection and automatic locking functionality of a vehicle. BACKGROUND

[0002] Systems have been proposed to close powered vehicle windows (windows that include, for example, front and rear door windows, side vent windows, sunroofs, glass roofs, and convertible tops) in the event of rain. Typically, these systems use dedicated rain sensors and perform automatic window closing actions based on detected precipitation. While these approaches may seem logical, they are not cost-effective in terms of component costs or the electrical power consumption of the key-off load (KOL) for a parked vehicle. Adding a sensor solely for rain detection proves difficult from an economic standpoint, as rain entering through windows is a relatively unlikely scenario.Although automatic window closing functions would be welcome at little or no extra cost, customers might not be willing to spend additional money on such a rarely used option.

[0003] To address the cost of additional sensors, some systems intend to utilize existing windshield rain sensors, which are used to activate the windshield wipers or adjust their speed based on windshield wetness. Such systems can read the windshield rain sensor while the vehicle is off and can provide an automatic closing function upon detecting wet glass. However, these systems are impractical for vehicles without intelligent wiper systems and are not cost-effective in terms of key operating level (KOL), as windshield rain sensors consume a significant amount of KOL while active. To keep additional KOL manageable, the windshield rain sensors can be sampled at long intervals, but this can reduce the effectiveness of such a system below acceptable levels.

[0004] Another disadvantage of such systems is that they do not consider the safety of animals or people who may be in the passenger compartment during an automatic locking process. For example, if rain gives way to sunny weather, the passenger compartment can experience a dangerous rise in temperature due to increased sun exposure.

[0005] DE 10 2014 204 848 A1 discloses a rain-initiation detection glazing closing system. US 2012 / 0 208 520 A1 discloses a system and a method for controlling a vehicle system from a telephone. US 2010 / 0 106 345 A1 discloses a vehicle control method. US 2013 / 0 265 178 A1 discloses a method for vehicle-related messaging. SUMMARY

[0006] In a first illustrative embodiment, a system includes a telematics control unit and a controller connected to the telematics control unit and several capacitive sensors, which is configured to access notification settings to determine a mobile device to notify of a rain situation identified using the sensors; to instruct the telematics control unit to send a rain alert to the mobile device to receive confirmation to perform rain situation actions; and to close vehicle openings in response to receiving the confirmation; and to instruct the telematics control unit to send a closing confirmation to the mobile device indicating the rain situation actions performed.a control unit display, wherein the telematics control unit is configured to display a user interface for configuring the notification settings on the control unit display and to update the notification settings in response to input into the user interface; wherein the notification settings specify: (i) which of the vehicle openings to close in response to receiving the confirmation and (ii) which vehicle doors to unlock in response to receiving the confirmation.

[0007] In a second illustrative embodiment, a computer-implemented method includes receiving notification settings to be applied in a vehicle control unit that determines a rain situation from a user's mobile device; identifying a rain situation by the vehicle control unit according to a capacitive change via sensor data received from multiple external capacitive sensors of the vehicle; and sending a rain alert to the mobile device to receive confirmation to perform rain situation actions specified by the notification settings, wherein the notification settings specify which vehicle openings to close in response to receiving the confirmation and specify one or more vehicle doors to unlock in response to receiving the confirmation.

[0008] In a third illustrative embodiment, a system includes a mobile device configured to display a user interface for setting notification settings to be applied in a vehicle control unit configured to determine rain situations; receiving, from the vehicle control unit, a rain warning requesting acknowledgment to execute rain situation actions specified by the notification settings; and, in response to user input into the mobile device, sending an acknowledgment to execute the rain situation actions. BRIEF DESCRIPTION OF THE DRAWINGS Fig. Figure 1A illustrates an exemplary system of a vehicle for rain detection and closing of windows, sunroofs or vent windows; Fig. 1B illustrates an exemplary system for using information from a weather service to assist in determining a rainfall situation; Fig. Figure 2 illustrates an example detection of a sudden rain situation using sensor data from a capacitive sensor and a detection threshold; Fig. Figure 3 illustrates an example of the detection of a rain situation using sensor data from several capacitive sensors; Fig. Figure 4A illustrates an example user interface of the notification application, which displays a main menu for configuring notification settings; Fig. Figure 4B illustrates an example user interface of the notification application, displaying the Enable submenu; Fig. Figure 4C illustrates an example user interface of the notification application, displaying the alert submenu; Fig. 4D and Fig. Figure 4E illustrates an example user interface of the notification application 120, which displays the closing conditions submenu; Fig. Figure 4F illustrates an example user interface of the notification application, displaying the Rain-Ends submenu; Fig. Figure 5A illustrates an example user interface for selecting applications for use in a vehicle control unit display; Fig. Figure 5B illustrates an example user interface of the notification application, which displays a main menu for configuring notification settings in a control unit display of the vehicle; Fig. Figure 6A illustrates an example user interface that demonstrates a warning displayed on the mobile device's screen; Fig. Figure 6B illustrates an example user interface demonstrating a closing confirmation displayed on the mobile device's screen; Fig. Figure 7 illustrates an exemplary process for rain detection in order to carry out rain situation actions and Fig. Figure 8 illustrates an exemplary process for carrying out rain situation actions in response to a detected rain situation. DETAILED DESCRIPTION

[0009] As required, detailed embodiments of the present invention are disclosed herein; however, it is understood that the disclosed embodiments are merely exemplary of the invention, which may be embodied in various and alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of specific components. The specific structural and functional details disclosed herein should therefore not be interpreted restrictively, but merely as a representative basis for teaching a person skilled in the art how the present invention may be used in various ways.

[0010] Fig. Figure 1 illustrates an exemplary System 100 of a vehicle 102 for rain detection and closing of windows, sunroofs, or vent windows. System 100 may include aspects of a passive keyless entry / passive start (PEPS) system for rain detection, aspects of an electric window system for providing window closing (e.g., closing of electric front and rear door windows, powered vent windows, electric sunroofs, and glass roofs), and aspects of a telematics system for user notification and configuration. System 100 can take many different forms and includes multiple and / or alternative components and features. Although in Fig. The fact that an exemplary System 100 is shown in Figure 1 is not intended to be restrictive. In fact, additional or alternative components and / or implementations may be used.

[0011] In a PEPS system, a user can carry an electronic transmission device, such as a PEPS key fob 104, to enable "keyless" access to the vehicle 102. To initiate a door unlocking sequence, the user can touch or move in close proximity to a capacitive PEPS handle sensor 106 on the door handle of the vehicle 102. Upon identification of a user's potential presence by a capacitive sensor 106, a controller 108 of the vehicle 102 can initiate a request-receipt sequence with the key fob 104. This sequence may involve the controller 108 sending a low-frequency message to the key fob 104 and listening for a high-frequency response from the key fob 104 containing an identification code.Once the correct identification code has been received, the vehicle control unit 108 can unlock the doors of the vehicle 102.

[0012] A vehicle 102 equipped with capacitive PEPS sensors 106 may have multiple capacitive sensors 106 on each door handle. For example, the door handles may each have one capacitive sensor 106 for a locking function and a second capacitive sensor 106 for an unlocking function. A vehicle tailgate or loading flap may typically have only one capacitive unlocking sensor 106. As another example, capacitive sensors 106 may include capacitive keypads, which are used in some vehicles 102 to grant access to the vehicle 102 after a correct key code entered on the keypad has been received.Other types of capacitive sensors 106 of the vehicle 102, such as any other capacitive sensors on the outside that can be used for keyless access purposes, such as locking / unlocking, latching or keypad actuations, can also be used by the system 100.

[0013] The controller 108 can be configured to receive capacitive values ​​from the capacitive sensors 106 and identify a baseline capacitance value. This can be done, for example, based on an average of the values ​​received by the sensors or based on data received from other environmental sensors of the vehicle 102. The baseline capacitance value can fluctuate upwards or downwards due to various environmental conditions, such as changes in air temperature or humidity. If the controller 108 detects a significant change from the baseline capacitance value during a relatively short period, the controller 108 can determine the potential presence of a user. For example, the capacitive sensors 106 can detect a change in capacitance due to an approaching human hand.Capacitive sensors 106, such as PEPS handle sensors 106 and capacitive keyboard sensors 106, can also be sensitive to the onset of moisture. Therefore, capacitive sensors 106 can be considered rain sensors that are sensitive to the detection of rain.

[0014] A vehicle 102 equipped with a PEPS system can include one or more capacitive sensors 106 on each of its multiple door handles, resulting in a matrix of sensors 106 that can be used to detect rain. For example, a vehicle 102 that includes two capacitive sensors 106 on each of its four doors can be considered to have a matrix of eight rain sensors, while a vehicle 102 with two capacitive sensors 106 on the two front doors can be considered to have a matrix of four sensors. Furthermore, in some vehicles 102 with a capacitive trunk release, the rear trunk release sensor 106 could enable a matrix of nine rain sensors 106 in a four-door sedan or a matrix of five rain sensors 106 in a two-door sedan.Other vehicles 102 may include various matrices of capacitive sensors 106, such as capacitive keypad sensors 106, to unlock associated vehicle doors. However, the use of capacitive PEPS handle sensors 106 for rain detection by the controller 108 provides a matrix of capacitive sensors 106 that does not exhibit either increasing component costs or increasing key-of-life (KOL), since many vehicles 102 may have keyless PEPS access systems as standard, and since the capacitive PEPS handle sensors 106 can be active when the vehicle 102 is parked to enable keyless access.

[0015] The controller 108 can be configured to receive sensor data from the capacitive PEPS handle sensors 106, indicating relative capacitance values. This input from the capacitive PEPS handle sensors 106 to the controller 108 can be used to identify the onset of a rain event. For example, if sensor data received from two or more capacitive sensors 106 show relatively simultaneous changes in capacitance, and furthermore, if the vehicle is locked, no key fob 104 is detected by the controller 108 near the prompt zone of the outside of a door handle, and if the vehicle is unlocked, there is no door opening event within a specified time period after the detected change in capacitance, the controller 108 can conclude that a rain event has begun.In another example, if sensor data received from at least one capacitive sensor 106 per door handle registers a detection of a change in capacitance that is not followed by a door opening event for a door corresponding to the at least one capacitive sensor 106, the controller 108 can conclude that a rain situation has begun.

[0016] In some cases, the controller 108 can implement a two-stage process to determine the onset of a rain event. For example, based on the receipt of a change in the capacitance of a capacitive PEPS handle sensor 106, and in the absence of a detection of a PEPS key fob 104 near the sensor 106 or a door opening event, the system 100 can wake the vehicle 102 and search for secondary signs of rain before concluding that a rain event exists. As some examples of secondary signs, the controller 108 can activate a smart wiper rain sensor 112 to identify whether the windshield appears wet, or activate a connection to a local weather information source via the telematics control unit 114 to determine whether rain is forecast (e.g., with reference to...). Fig. (1B discussed in more detail), use the vehicle 102's onboard humidity sensors to determine if humidity readings indicate rain, compare capacitive locking and unlocking sensors 106 on a designated door handle for sensor data 202 confirming the rain situation, compare readings from other locations of capacitive sensors 106 of the vehicle 102 for sensor data 202 confirming the rain situation, or use the vehicle 102's onboard solar exposure sensors to identify the solar exposure to which the vehicle 102 is subjected. As a more specific example, the solar exposure sensors can be used to exclude data from capacitive sensors 106 that otherwise indicate a window closure in the case of solar exposure values ​​that are inconsistently high for a true rain situation.However, the use of solar exposure sensors to confirm a rain situation may be limited to use during certain time periods, e.g., time of day, as determined according to the vehicle's onboard date and time display 102, and may be supplemented by position information available to the vehicle (e.g., according to a navigation system or GPS receiver).

[0017] Once a reasonable probability of rain is determined, the controller 108 can be configured to perform various actions. For example, the controller 108 can be configured to provide information to electric window actuators 110, which are configured to close the various windows (e.g., electric front and rear door windows, powered side vent windows, electric sunroofs, and glass roofs) of the vehicle 102, thus preventing rain from entering the vehicle 102. In some cases, the controller 108 can identify that the vehicle doors are locked and that the closed vehicle window was previously open further than a predefined window threshold (e.g., to allow access to the passenger compartment). In such a case, the controller 108 can open at least one of the vehicle doors (e.g.,(The door, whose window was closed) unlocks to maintain access to vehicle 102. As another example, the control unit 108 can be configured to warn the user of vehicle 102 of rain and request confirmation from the user to close the windows. The warning can be sent to the user, for example to the user's mobile device 118, via a telematics control unit 114 of vehicle 102.

[0018] In some examples, the controller 108 can also be configured to detect the end of a rain event. For example, similar to detecting the start of a rain event, the controller 108 can detect a change in the opposite direction or a return of a capacity value to a baseline capacity value. After detecting the end of a rain event, the controller 108 can be configured to perform various additional actions. For example, the controller 108 can be configured to cause the windows of vehicle 102 to reopen. In the case of vehicles 102 that support reporting window position information, the controller 108 can be configured to reopen the windows by recording the position of the windows before they were closed and returning the windows to the recorded position once the end of the rain event is detected.In the case of vehicles 102 that do not support the reporting of window position information, the controller 108 can, for example, record a time period required to close the window and provide a reopening command to the window for the duration of the recorded time period as soon as the end of the rain situation is detected.

[0019] The actions performed by the vehicle 102 when rain is detected or when the rain has ended can be based on the vehicle 102's notification settings 116. These notification settings 116 can include, among other things, whether the automatic rain closing functionality should be enabled if it is, whether warnings should be sent to the user, whether confirmation of warnings is required before closing actions are performed, which specific windows should be closed, and they can also include, among other things, geographical differences in behavior, differences in behavior based on which key fob 104 was last used, differences in behavior based on which mobile device 118 was last connected to the telematics control unit 114, and settings regarding reopening windows after the rain has ended.

[0020] The notification settings 116 can be maintained by the controller 108 and can be accessible to the telematics control unit 114 via the vehicle controller area network (CAN) bus. Alternatively, the notification settings 116 can be maintained in a different memory location of the vehicle 102, such as in the memory of the telematics control unit 114.

[0021] The telematics control unit 114 can be configured to provide the vehicle 102 with telematics services. These services can include, as some non-limiting possibilities, navigation, turn-by-turn directions, vehicle health reports, local business search, accident reporting, and hands-free calling. In one example, the system 100 can include the SYNC system, manufactured by The Ford Motor Company in Dearborn, MI. To support these and other telematics services, the telematics control unit 114 can use network hardware configured to enable communication between the vehicle's ECUs, such as the control unit 108, and with other system 100 devices. In one example, the telematics control unit 114 can connect to a wireless transceiver configured to communicate with a user's mobile device 118 via Bluetooth and / or Wi-Fi and / or wired USB.

[0022] The mobile device 118 can undergo a process when it is first connected to the telematics control unit 114, in which the telematics control unit 114 searches for mobile devices 118 and the user manually confirms the identification of the mobile device 118 to be connected to the telematics control unit 114. This process can be referred to as pairing. The telematics control unit 114 can maintain paired device data, including device identifiers or other information regarding mobile devices 118 that were previously paired with the telematics control unit 114.Once the pairing process is complete, the telematics control unit 114 can use the paired equipment data to automatically reconnect to the mobile device 118 when the mobile device 118 is identified via the wireless transceiver as being near the telematics control unit 114. The telematics control unit 114 can also maintain a record of the mobile device 118 that was last paired with it.

[0023] The mobile devices 118 can be any of the various types of portable data processing devices, such as mobile phones, tablet computers, smartwatches, laptop computers, portable music players, or other devices used for communication over a communications network (e.g., the one in Fig. 1B shown communication network 124) are capable. In one example, the mobile devices 118 can communicate with the communication network 124 via a wireless transceiver of the mobile device 118. The mobile devices 118 can include one or more processors configured to execute instructions from mobile applications that have been loaded from a storage medium of the mobile device 118 into a memory of the mobile device.

[0024] The notification application 120 can be an example of a mobile application installed in the mobile device 118. The notification application 120 can be configured to receive input (e.g., user input into a user interface of the mobile device 118) and to communicate with the vehicle 102 via the telematics control unit 114, as discussed in more detail below. In particular, the notification application 120 can be used by users to configure the notification settings 116 of the vehicle 102, to receive rain warnings from the vehicle 102, and to send acknowledgments of the received warnings to the vehicle 102.

[0025] Fig. Figure 1B illustrates an example system 100 for using information from a weather service 126 to support rainfall prediction. As shown, the system 100 component can include the weather service 126 and a backend server 122 that communicates with the vehicle 102 via the communication network 124. The weather service 126 can be configured to provide information regarding predicted weather conditions, and the backend server 122 can be configured to maintain location, window status, or other information about the vehicle 102 that can be used to support rainfall predictions based on the weather service 126's forecast.

[0026] In one example, the telematics control unit 114 of vehicle 102 can periodically or based on a trigger, such as vehicle 102 being parked or the key being turned off, send the current GPS position of vehicle 102 and the current status of its windows to the backend server 122 via the communication network 124. Additionally or alternatively, the telematics control unit 114 can send information to the backend server 122 indicating whether vehicle 102 is identified as parked outdoors or indoors (e.g., determined based on vehicle 102's onboard solar exposure sensors, which identify the solar exposure to which vehicle 102 is subjected, based on the fact that its current location is associated with a garage or other covered structure).

[0027] The backend server 122 can be configured to maintain the information received from the vehicles 102. The backend server 122 can also be configured to access the weather service 126 to periodically or otherwise check the weather forecast for the locations maintained by the vehicles 102. If the weather forecast indicates a potential for rain, the backend server 122 can optionally be configured to send a notification to the driver's mobile device 118 with instructions, such as closing the windows now, closing them immediately before the rain, etc. If the weather service announces impending rain, the backend server 122 can send a warning or other communication to the vehicle 102 to initiate automatic rain-closing actions.Alternatively, the message to vehicle 102 can cause vehicle 102 to activate the Smart-Wipe rain sensor 112 to confirm the rain situation before triggering automatic rain closing actions.

[0028] Fig. Figure 2 illustrates an exemplary detection of a sudden rainfall event using sensor data 202 from a capacitive sensor 106 and a detection threshold 204. The sensor data 202 can include data collected periodically by a capacitive PEPS sensor 106. The controller 108 can receive the raw sensor data 202 and can identify whether the values ​​of the received sensor data 202 change above the detection threshold 204. In some examples, the sensor 106 can process and evaluate capacitive changes and report only sudden changes to the controller 108. The detection threshold 204 can, in some examples, be set to a predetermined distance above the current sensor data 202, or it can be a predetermined distance above an average of the most recent samples of the sensor data 202.In some examples, the controller 108 can set the threshold value in the sensor or in the memory of the controller 108, at least partially, based on specific information from the vehicle 102 that was programmed into the vehicle 102 (e.g., during assembly) in order to compensate for different vehicle body shapes and handle shapes in which a standard capacitive handle sensor 106 can be used. In some cases, the detection threshold 204 can be the threshold value used to determine the potential presence of a user by the capacitive sensor 106. If the controller 108 detects that the value of the received sensor data 202 has changed above the detection threshold 204, the controller 108 can identify that the sensor data 202 indicates the beginning of a rain event.

[0029] If, instead, the controller 108 detects that the value of the received sensor data 202 has changed without triggering the detection threshold 204, the controller 108 can selectively adjust the detection threshold 204 according to the new sample. Accordingly, the controller 108 can selectively adjust the detection threshold 204 to account for changes in humidity and temperature, thereby maintaining a relative detection threshold 204 as an offset change in capacity.

[0030] If the controller 108 also determines that the value of the received sensor data 202 has fallen below the detection threshold 204 again, the controller 108 can identify the end of the rain situation.

[0031] Fig. Figure 3 illustrates an exemplary detection of a rain event using sensor data 202 from multiple capacitive sensors 106. As illustrated, the sensor data 202-A can include data periodically sampled by a first capacitive PEPS sensor 106-A, while the sensor data 202-B can include data periodically sampled by a second capacitive PEPS sensor 106-B. The controller 108 can receive the sensor data 202-A and 202-B and can identify a rain event based on the identification of an substantially simultaneous or otherwise relatively constant change across the sensor data 202-A and 202-B, in the absence of a door opening event. As shown, the controller 108 identifies an indication of a rain event based on the identification of a relatively large change in capacitance in both the sensor data 202-A and the sensor data 202-B.Furthermore, based on a further finding that the received sensor data 202-A and 202-B have each returned to a baseline capacity value, the controller 108 can also identify an end to the rain situation.

[0032] It should be noted that variations in the exemplary capacitive measurements and the use of this information to determine the onset of rainfall are possible. For example, it should be noted that although capacitive measurements involve detecting a rainfall event using two capacitive PEPS sensors 106, a larger number of capacitive sensors 106 can also be used. Furthermore, it should also be noted that the use of detection thresholds 204, as described in reference to Fig. 2 described, furthermore with reference to several sensors 106, as with reference to Fig. 3 described, can be used.

[0033] Fig. Figure 4A illustrates an example user interface 400-A of the notification application 120, which displays a main menu for configuring the notification settings 116. As shown, the user interface 400-A can be presented by the notification application 120 on a display 402 of the mobile device 118 and can include a list of selectable menu items 404-A to 404-D (collectively 404) of functions of the notification application 120. Each of the selectable menu items 404 can display a category of notification settings 116. The user interface 400-A can also include a title label 406 to indicate to the user that the user interface 400-A displays an options menu of the notification application 120.

[0034] As illustrated, the main menu includes a 404-A menu item for an Enable submenu, a 404-B menu item for a Warning submenu, a 404-C menu item for a Closing Conditions submenu, and a 404-D menu item for a Rain Finished submenu. In some cases, the 404 menu items may be displayed on a touchscreen, allowing the user to tap them to select and access associated functions. As another example, the 400-A user interface may support voice command selection of the 404 menu items. For instance, the user could say "Warning" to access the Warning submenu. It should be noted that the illustrated 404 menu items are merely examples, and multiple or different submenus or arrangements of options may be available.

[0035] Fig. Figure 4B illustrates an example user interface 400-B of the notification application 120, which displays the Activate submenu. Similar to user interface 400-A, user interface 400-B can also be presented by the notification application 120 on the display 402 of the mobile device 118. In one example, user interface 400-B can be accessed in response to a user selection of menu item 404-A in user interface 400-A. Compared to user interface 400-A, the title label 406 can indicate to the user that user interface 400-B displays the Activate submenu of the notification application 120.Instead of the main menu items 404, the user interface 400-B can also include an activation button 408-A, which, when selected by the user, is configured to cause the notification application 120 to update the notification settings 116 to indicate that the automatic rain closing functionality is to be activated by the controller 108, and a deactivation button 408-B, which, when selected by the user, is configured to cause the notification application 120 to update the notification settings 116 to indicate that the automatic rain closing functionality is to be deactivated by the controller 108. Thus, the user can use the activation submenu to activate or deactivate the automatic rain closing functionality without affecting other settings of the system 100.The user interface 400-B may also include a Return to Menu button 410 which, when selected by the user, is configured to cause the notification application 120 to return to displaying the main menu user interface 400-A.

[0036] Fig. Figure 4C illustrates an example user interface 400-C of the notification application 120, which displays the alert submenu. As with user interfaces 400-A and 400-B, user interface 400-C can also be presented by the notification application 120 on the display 402 of the mobile device 118. In one example, user interface 400-C can be invoked in response to a user selection of entry 404-B of user interface 400-A. The title label 406 can indicate to the user that user interface 400-C displays the alert submenu of the notification application 120.

[0037] The warning submenu can include options which, when selected by the user, cause the notification application 120 to update the notification settings 116 relating to the vehicle 102 providing warnings to the mobile device 118 when a rain situation is identified by the controller 108. For example, the warning submenu can include a control 412-A that allows the user to select whether the automatic closing functionality is enabled or not, a control 412-B that allows the user to select whether warnings should be sent to the mobile device 118 when a rain situation is identified by the controller 108, and a control 412-C that allows the user to select whether the automatic closing functionality should be executed or not if the user does not respond within a specified time period (e.g.,within two minutes) to confirm the warning.

[0038] The user interface 400-C may also include the Return to Menu button 410, which, when selected by the user, is configured to cause the notification application 120 to return to displaying the main menu user interface 400-A.

[0039] Fig. 4D and Fig. Figure 4E illustrates an example user interface 400-D of the notification application 120, which displays the closing conditions submenu. As with user interfaces 400-A to 400-C, user interface 400-D can also be presented by the notification application 120 on the display 402 of the mobile device 118. In one example, user interface 400-D can be accessed in response to a user selection of entry 404-C of user interface 400-A. The title label 406 can indicate to the user that user interface 400-D displays the closing conditions submenu of the notification application 120.

[0040] The closing conditions submenu may include options which, when selected by the user, cause the notification application 120 to update the notification settings 116 relating to the vehicle 102 providing warnings to the mobile facility 118 when a rain situation is identified by the controller 108.For example, the closing conditions submenu can contain a control 412-D that allows the user to select to close all openings of the vehicle 102 when rain is detected; a control 412-E that allows the user to select to close all openings of the vehicle 102 except for vent windows when rain is detected; a control 412-F that allows the user to select to close openings of the vehicle 102 regardless of the vehicle 102's location; and a control 412-G that allows the user to select, in response to the vehicle 102 receiving a weather report indicating rain (i.e.,from the weather server 126 by means of the telematics control unit 114, as a confirmation of or in other cases without direct rain detection by the control unit 108 using data from the capacitive sensors 106), to close the openings of the vehicle 102, an operating element 412-H that allows the user to select for the vehicle 102 not to close openings of the vehicle 102 when it is at the home location of the vehicle 102, and an operating element 412-I that allows the user to select for the vehicle 102 not to close openings of the vehicle 102 during daylight hours.

[0041] With reference to Fig. 4E can also include a control element 412-J in the closing conditions submenu, which allows the user to select to lock all doors of vehicle 102 when rain is detected, and a control element 412-K, which allows the user to select to close all doors of vehicle 102 except the driver's door (e.g.to prevent the driver from being locked out after closing the window), a control element 412-L which allows the user to select that the automatic locking functionality is activated for any key remote control 104, a control element 412-M which allows the user to select that the automatic locking functionality is activated only for a specific key remote control 104 of the user, and a control element 412-N which allows the user to select that the automatic locking functionality is activated for parked vehicles that were last paired with one from a list of mobile devices 118.The 400-D user interface can also include a device directory control element 414, which the user can use to include identifiers of mobile devices 118 that cause the automatic locking functionality to be activated if they have recently been paired with the telematics control unit 114. In some cases, the device directory control element 414 can be populated with data from paired devices by the telematics control unit 114.

[0042] Since the closing conditions submenu can contain more controls 412 than are displayed on the screen 402 at any one time, the user interface 400-D can (e.g., in Fig. 4D shown) Scroll-down control 416 and a (e.g. in Fig. The user interface 400-D (shown in Figure 4E) may include a scroll-up control 418 to allow the user to navigate the user interface 400-D to view the available controls. The user interface 400-D may also include a Return to Menu button 410, which, when selected by the user, is configured to cause the notification application 120 to return to display the main menu user interface 400-A.

[0043] Fig. Figure 4F illustrates an example user interface 400-E of the notification application 120, which displays the Rain-Ends submenu. As with user interfaces 400-A through 400-D, user interface 400-E can also be presented by the notification application 120 on the display 402 of the mobile device 118. In one example, user interface 400-E can be invoked in response to a user selection of entry 404-D in user interface 400-A. The title label 406 can indicate to the user that user interface 400-E displays the Rain-Ends submenu of the notification application 120.

[0044] The Rain Ends submenu can include options which, when selected by the user, cause the notification application 120 to update the notification settings 116 relating to actions that the vehicle 102 should perform when a rain situation is no longer identified by the controller 108. For example, the Rain Ends submenu can include a control 412-O that allows the user to select that the controller 108 open the vehicle 102's openings after a predetermined period of time has elapsed since the rain ended (e.g.,after 10 minutes); a control element 412-P that allows the user to select that the control 108 returns the openings of the vehicle 102 to the state they were in before they were automatically closed after a predetermined period of time has elapsed, and a control element 412-Q that allows the user to select that the control 108 keeps the openings closed despite the end of the rain.

[0045] The user interface 400-E may also include a Return to Menu button 410 which, when selected by the user, is configured to cause the notification application 120 to return to displaying the main menu user interface 400-A.

[0046] Although the user interfaces 400-A to 400-E for configuring the notification settings 116 are described as being displayed to the user via the notification application 120 running on the user's mobile device 118, the configuration of the notification settings 116 can also be performed using the vehicle 102, either additionally or alternatively.

[0047] Fig. Figure 5A illustrates an exemplary user interface 500-A for selecting applications for use in a control unit display 502 of the vehicle 102. The control unit display 502 can, for example, be driven by a video connection to the telematics control unit 114 of the vehicle 102. The user interface 500-A can include a category directory 504 with one or more content menu screens to be displayed on the main screen area 506 of the control unit display 502.As some examples, the category directory 504 may include an audio menu screen through which the audio settings of the vehicle 102 can be configured, a climate control menu screen through which the climate control settings of the vehicle 102 can be configured, a telephone menu screen through which telephone services can be used, a navigation menu screen through which maps and route guidance can be displayed, an application menu screen through which installed applications can be accessed, and a settings menu screen through which backlighting or other general settings of the control unit display 502 can be accessed.The user interface 500-A can also include a general information area 508, on which time, current temperature and other information can remain visible to the user, regardless of which specific menu screen or application is active in the main screen area 506.

[0048] As shown, the application menu screen is illustrated as selected from the category directory 504, and the main screen area 506 is illustrated as showing a directory of available applications that can be accessed. These applications may include, for example, a Find New Apps application menu item 504-A, an Internet Radio menu item 504-B, a Satellite Radio menu item 504-C, a Streaming Radio menu item 504-D, an icon 504-E for selecting the Notification application 120, a Map menu item 504-F, a News icon 504-G, and a Weather icon 504-H.

[0049] Fig. Figure 5B illustrates an example user interface 500-B of the notification application 120, which displays a main menu for configuring the notification settings 116. The user interface 500 can also display and enable configurations using any submenu and / or any option previously described with reference to user interfaces 400-B to 400-E. Similar to user interface 400-A, user interface 500-B can thus be used to select various menu screens of the notification settings 116 of the notification application 120, but using the control unit display 502 of the vehicle 102 instead of the display 402 of the mobile device 118.

[0050] Regardless of whether the notification settings 116 were set with the mobile device 118 or the control unit display 502, they can be used by the controller 108 to perform rain detection and any other specified actions.

[0051] Fig. Figure 6A illustrates an example user interface 600-A, which demonstrates a warning 602 displayed on the display 402 of the mobile device 118. The warning 602 can be displayed by the notification application 120, for example, in response to the mobile device 118 receiving a message sent by the telematics control unit 114 of the vehicle 102 as a result of a rain detection performed by the control unit 108 of the vehicle 102.

[0052] As shown, warning 602 can include a title label 604 to indicate to the user that warning 602 indicates the presence of rain at vehicle 102. Warning 602 can further include an acknowledgement button 606-A, which, when selected by the user, is configured to cause the notification application 120 to send a warning response message to vehicle 102, indicating that the controller 108 is to perform the rain closing actions specified by the notification settings 116; and a rejection button 606-B, which, when selected by the user, is configured to cause the notification application 120 to send a warning response message to vehicle 102, indicating that the controller 108 is not to perform the rain closing actions.Thus, the warning 602 can enable the user of the mobile device 118 to decide whether to close windows or perform the other actions specified by the notification settings 116.

[0053] Fig. Figure 6B illustrates an example user interface 600-B, which demonstrates a closing confirmation 608 displayed on the display 402 of the mobile device 118. The closing confirmation 608 can be displayed by the notification application 120, for example, in response to the mobile device 118 receiving a message sent by the vehicle 102's telematics control unit 114 in response to the completion of the actions to be performed by the vehicle 102's control unit 108, as defined by the notification settings 116.

[0054] As shown, the closing confirmation 608 can include a title label 610 to indicate to the user that the notification settings 116 were executed (or not executed, for example, if a window was blocked and could not be closed). The closing confirmation 608 can also include a summary label 612 that displays the actions performed. For example, the summary label 612 can show which openings were closed (e.g., all windows, all windows except awning windows), whether any doors were locked or unlocked (e.g., all doors locked, driver's door left unlocked, etc.), any further details of the conditional closing (e.g.,, whether the closure was authorized by means of an approved key remote control 104 or a mobile device 118, which was last used with the vehicle 102 before the detection of the rain situation) and what actions, if any, the vehicle 102 can perform once the rain situation has ended (e.g. reopening openings, keeping openings closed, etc.).

[0055] Fig. Figure 7 illustrates an exemplary process 700 for rain detection in order to execute actions in rain situations. Process 700 can be executed by various devices, such as the control unit 108 of the vehicle 102, which is connected to one or more capacitive sensors 106.

[0056] In workflow 702, the controller 108 identifies whether the preconditions for activating rain detection are met. For example, the rain detection function can be activated if all doors of vehicle 102 are closed and no gear is engaged (e.g., if the vehicle is in park or neutral). In another example, the controller 108 can access the notification settings 116 to confirm that the rain detection function is activated. If the preconditions are met, the controller proceeds to workflow 704. Otherwise, process 700 ends.

[0057] In workflow 704, the controller 108 identifies a capacitive change characteristic of a rain situation. In some examples, the controller 108 can detect a rain situation using sensor data 202 from a capacitive sensor 106 and a detection threshold 204, as previously described with reference to Fig. 2 discussed, or using sensor data 202 from several capacitive sensors 106, as previously discussed with reference to Fig. 3. Discussed, detect.

[0058] In workflow 706, the controller 108 determines whether the vehicle 102 is parked with its doors electronically locked. In some scenarios, such as a family picnic or when the vehicle is parked in the driveway, users may leave their vehicles 102 unlocked. If a vehicle 102 is unlocked, or if a door is ajar, many PEPS systems cannot search for a PEPS key fob 104. If the vehicle 102 is electronically unlocked, the controller proceeds to workflow 712. Otherwise, the controller proceeds to workflow 708.

[0059] In process 708, the controller 108 queries for a key fob 104 near the handles of the vehicle 102. For example, the controller 108 can send a low-frequency key message to a key fob 104 and listen for a high-frequency response from the key fob 104 containing an identification code. If the key fob 104 is present, then the capacitive change, regardless of whether it is raining, can indeed result from a user's attempts to gain access to the vehicle 102.

[0060] In operation 710, the controller 108 determines whether the key fob 104 is near a handle of the vehicle 102. For example, the controller 108 can determine whether the PEPS key fob 104 is near the low-frequency handle prompt zone of the door handles, indicating normal passive PEPS access operation. If no response is received from the key fob 104, or if the response received is incorrect, or if the key fob 104 is found to be inside the passenger compartment, the controller 108 can conclude that the key fob 104 is not near the handle of the vehicle 102. If no key fob 104 is near the handle, the controller proceeds to operation 714. Otherwise, process 700 ends.In some cases, if the key remote control 104 is detected, process 700 may transition to or revert to a key unlocking process performed by the PEPS system.

[0061] In workflow 712, the controller 108 determines whether a door of the vehicle 102 is opened after the identified change in capacitance detected by the capacitive sensors 106. This can be performed to differentiate between conditions in which (a) the change in capacitance is a result of the user approaching a handle of an unlocked door or (b) it is a result of rain. For example, a user may approach an unlocked vehicle without the key fob 104 in their possession and open a door of the vehicle 102. In such an example, the identified change in capacitance could be due to rain, a hand near the capacitive handle sensor 106, or both (e.g., a user running to their vehicle 102 because of the rain).Furthermore, it is also possible that two or more arriving passengers grasp door handles almost simultaneously to open the doors of vehicle 102. To distinguish between a rain situation and these other types of situations affecting access to vehicle 102, the controller 108 can be configured to search within a predetermined time period (e.g., 2-3 seconds) for a door opening event that coincides with, or occurs shortly after, a sustained large change in capacitance at the capacitive vehicle door sensor 106, which has detected a change in capacitance characteristic of a rain situation.

[0062] In workflow 714, the control unit 108 performs second stages of assessments regarding the presence of a rain situation.For example, the controller 108 can activate a smart wipe rain sensor 112 to identify whether the windshield appears wet, activate a connection to a local weather information source via an embedded telematics modem to determine whether rain is forecast, use the vehicle's onboard humidity sensors 102 to determine whether humidity readings indicate rain, compare capacitive locking and unlocking sensors 106 on a designated door handle for sensor data 202 confirming the rain situation, compare readings from other positions of capacitive sensors 106 on the vehicle 102 for sensor data 202 confirming the rain situation, or use the vehicle's onboard solar exposure sensors 102 to identify the solar exposure to which the vehicle 102 is subjected.

[0063] During workflow 716, the controller 108 determines whether the second stage of the assessment confirms the rain situation. For example, the controller 108 can identify the rain situation as confirmed if the rain sensor 112 indicates a wet condition or if a humidity sensor confirms a damp condition, and proceed to workflow 718. Otherwise, process 700 ends.

[0064] In workflow 718, the controller 108 executes actions related to a rainfall event. Further aspects of these actions are described in more detail below with reference to process 800. After workflow 718, process 700 ends. Variations of this process 700 are possible. For example, the controller 108 can rely on the capacity change characteristic of a rainfall event without performing further second-stage assessments in workflows 714 and 716.

[0065] Fig. Figure 8 illustrates an example of Process 800 for executing rain-related actions in response to a detected rain situation. As with Process 700, Process 800 can be executed by various devices, such as the control unit 108 of the vehicle 102.

[0066] In workflow 802, control 108 determines whether to send a warning 602 to the user. For example, control 108 can access notification settings 116 to determine if the user has selected to be warned about rain. If control 108 determines to send a warning 602 to the user, it proceeds to workflow 804. Otherwise, it proceeds to workflow 810.

[0067] In workflow 804, the controller 108 sends a message containing warning 602 to the user's mobile device 118. In one example, the controller 108 instructs the telematics control unit 114 to send the warning message to the mobile device 118 that was last paired with the telematics control unit 114. In another example, the controller 108 instructs the telematics control unit 114 to send the warning message to a mobile device 118 specified in the notification settings 116. An example display of a message containing warning 602 from the mobile device 118 is shown above with reference to Fig. 6A discussed.

[0068] In workflow 806, controller 108 determines whether acknowledgment of warning 602 has been requested. For example, controller 108 can access notification settings 116 to determine if the user has selected to acknowledge the rain situation before allowing controller 108 to perform rain situation actions. If controller 108 determines that acknowledgment is required, it proceeds to workflow 808. Otherwise, it proceeds to workflow 810.

[0069] In workflow 808, the controller 108 determines whether an acknowledgment of warning 602 has been received from vehicle 102. In one example, the controller 108 may receive a message from the telematics control unit 114 indicating that the warning response message has been sent back to vehicle 102, indicating that the controller 108 should perform the automatic rain closing actions specified in the notification settings 116 (e.g., in response to a user selection of the acknowledgment button 606-A for warning 602). In another example, the controller 108 may receive a message indicating that no automatic rain closing actions should be performed. In yet another example, the controller 108 may not receive an acknowledgment message within a predetermined timeout period (e.g., two minutes, ten minutes, etc.).If an acknowledgment is received within the predetermined timeout period, the control system proceeds to workflow 810. Otherwise, process 800 ends.

[0070] In workflow 810, the controller 108 closes the openings of the vehicle 102. For example, the controller 108 can access the notification settings 116 to determine which openings of the vehicle 102 are to be closed (e.g., all windows, all windows except vent windows, etc.). For the openings identified for closing, the controller 108 can trigger a closing action for at least one actuator 110 of an electric window (e.g., a closing action for a door window, a vent window, or a sunroof). For vehicles 102 that support reporting window position information, the controller 108 can be configured to record the positions of the windows before they are closed and to close only those windows that are reported as open.For vehicles 102 that do not support reporting window position information, the controller 108 can, for example, record the time it takes to close a window until the actuator 110 of an electric window indicates a closed state. The time taken to close the window can also be saved.

[0071] In workflow 812, the controller 108 adjusts the locking status of vehicle 102. For example, the controller 108 can access the notification settings 116 to determine which locking actions to perform on vehicle 102 (e.g., lock all doors, lock all doors but ensure the driver's door is unlocked, etc.). As another example, based on recorded window position information, the controller 108 can determine whether the doors of vehicle 102 are locked and, furthermore, whether any of the automatically locked windows were previously open beyond a certain threshold (e.g., a predefined distance or percentage). In such a situation, the user may have intentionally left a window open to gain access to the passenger compartment of vehicle 102.Since the open windows were closed in workflow 810, the user can no longer access the passenger compartment and may ultimately be locked out. If it is determined that a closed window was open further than a specified threshold (e.g., a certain distance or percentage), the controller 108 can unlock one or more doors of the vehicle 102 (e.g., the door with the automatically closed window that was previously open further than the specified amount or percentage, all doors, etc.) to allow the user to maintain access to the vehicle 102 and prevent them from being locked out.In another example, the controller 108 can identify whether the PEPS key fob 104 is located inside a locked passenger compartment of the vehicle 102 with automatically closed windows that were previously open further than a specified threshold, and unlock one or more doors of the vehicle 102 if these conditions are met. The controller 108 can also record which of the doors 102 were automatically unlocked.

[0072] In workflow 814, the controller 108 determines whether the user needs to be updated on the actions performed. For example, the controller 108 can access the notification settings 116 to determine whether the user wants to receive a closing confirmation 608 of the actions performed. If the notification settings 116 indicate that the user should be warned, the controller proceeds to workflow 816. Otherwise, the controller proceeds to workflow 818.

[0073] In workflow 816, the controller 108 sends the closing confirmation 608 to the user's mobile device 118. In one example, the controller 108 instructs the telematics control unit 114 to send the closing confirmation message 608 to the mobile device 118 that was last paired with the telematics control unit 114. In another example, the controller 108 instructs the telematics control unit 114 to send the closing confirmation message 608 to a mobile device 118 specified in the notification settings 116. An example display of a closing confirmation message 608 from the mobile device 118 is shown above with reference to Fig. 6B discussed.

[0074] In workflow 818, the controller 108 determines whether the rain situation has ended. For example, as previously mentioned with reference to the Fig. 2 and Fig.As discussed in section 3, the controller 108 can identify a capacitive change characteristic of the end of a rain event. In some cases, the controller 108 can further perform a second stage of assessment to confirm the end of the rain event, for example, by means of a rain sensor 112 that no longer indicates a wet condition, or a solar exposure sensor that indicates a solar exposure consistent with the shining sun.

[0075] In workflow 820, the controller 108 performs regeneration actions. For example, the controller 108 can access the notification settings 116 to determine whether the openings of the vehicle 102 should be reopened, whether the windows should return to their previous state, or whether the openings of the vehicle 102 should remain closed. The controller 108 can also use the notification settings 116 to determine a waiting period before the openings of the vehicle 102 are reopened (e.g., immediately, wait two minutes, wait ten minutes, etc.). Based on the notification settings 116, the controller 108 can trigger an opening action for at least one actuator 110 of an electric window (e.g., an opening action for a door window, a vent window, or a sunroof).For vehicles 102 that support reporting window position information, the controller 108 can be configured to reopen the windows to the recorded positions they were in before they were closed. For vehicles 102 that do not support reporting window position information, the controller 108 can, for example, operate the electric window actuators 110 for the same duration as the time it took to close the windows. In some examples, based on recorded door unlock information, the controller 108 can also relock any doors that may have been automatically unlocked in workflow 812.

[0076] In workflow 822, control 108 determines whether the user should be warned about the execution of the regeneration actions. For example, control 108 can access notification settings 116 to determine whether the user should be warned about the regeneration actions. If so, the control proceeds to workflow 824. Otherwise, process 800 terminates.

[0077] In workflow 824, the controller 108 sends a reopening confirmation message to the user's mobile device 118. In one example, the controller 108 instructs the telematics control unit 114 to send the reopening confirmation message to the mobile device 118 to which the warning 602 or the closing confirmation 608 was sent. The reopening confirmation message may be similar to the closing confirmation 608 message, but it may include information regarding changes made after the rain stopped, rather than because of the rain. Similar to the closing confirmation 608, the reopening confirmation may be displayed on the user interface of the mobile device 118. After workflow 824, process 800 ends.

[0078] The rain detection system 100 of a vehicle 102 can therefore automatically close windows using existing capacitive sensors 106, which incur neither additional component costs nor additional KOLs when rain is detected. Furthermore, the rain detection system 100 can enable additional functions or applications.

[0079] As an example, similar to identifying rain based on a detected change in capacity, the Rain Detection System 100 can similarly detect an accumulation of snow on a stationary vehicle. When a snow accumulation is detected, the Rain Detection System 100 can be configured to request a telematics control unit 114 of the vehicle 102 to send a telematics alert to inform the vehicle user that additional time may be needed to remove the accumulated snow from the vehicle or driveway. Alternatively, when snow is detected, the Rain Detection System 100 can ask the vehicle user whether the vehicle 102 should initiate a remote start action.

[0080] In another example, data from the Rain Detection System 100 can be transmitted to a data collection system for aggregation and further processing. For instance, the Vehicle 102 can provide rainfall activity data, indicating when rain events were detected (regardless of whether any windows were closed), along with location data for the Vehicle 102. Based on the received data, the data collection system can generate a weather map showing precipitation in the area where the Vehicle 102 might be located. Such a data collection system can be particularly useful in relatively rural areas that lack adequate radar or weather collection services but where Vehicle 102s implementing the Rain Detection System 100 might be located.

[0081] In general, computing systems and / or equipment, such as the Controller 108, the Telematics Control Unit 114, and the Mobile Equipment 118, can use any number of computer operating systems, including, but not limited to, versions and / or variants of the Microsoft Windows® operating system, the Unix operating system (e.g., the Solaris® operating system of Oracle Corporation in Redwood Shores, California, USA), the AlX UNIX operating system distributed by International Business Machines in Armonk, New York, USA, the Linux operating system, the Mac OS X and iOS operating systems distributed by Apple Inc. in Cupertino, California, USA, the BlackBerry OS distributed by Research In Motion in Waterloo, Canada, and the Android operating system developed by the Open Handset Alliance.

[0082] Computing devices, such as the Controller 108, the Telematics Control Unit 114, and the Mobile Unit 118, generally contain computer-executable instructions that can be carried out by one or more processors of the computing devices. Computer-executable instructions can be compiled or interpreted by computer programs created using a variety of programming languages ​​and / or technologies, including, but not limited to, and either alone or in combination, Java™, C, C++, Visual Basic, JavaScript, Perl, etc. Generally, a processor or microprocessor receives instructions, for example, from memory, a computer-readable medium, etc., and executes these instructions to carry out one or more processes, including one or more of the processes described herein.Such instructions and other data can be stored and transmitted using a variety of computer-readable media.

[0083] A computer-readable medium (also called a processor-readable medium) includes any non-perishable (e.g., tangible) medium involved in providing data (e.g., instructions) that can be read by a computer (e.g., by a processor in a computing device). Such a medium can take many forms, including, but not limited to, non-volatile and volatile media. Non-volatile media can include, for example, optical or magnetic disks and other permanent storage devices. Volatile media can include, for example, dynamic random-access memory (DRAM), which typically forms main memory. Such instructions can be transmitted by one or more transmission media, including coaxial cables, copper wire, and optical fibers, including the wires that comprise a system bus coupled to a computer's processor.Common forms of computer-readable media include, for example, a floppy disk, a diskette, a hard disk, a magnetic tape, any other magnetic medium, a CD-ROM, a DVD, any other optical medium, punched cards, paper tape, any other physical medium with hole patterns, a RAM, a PROM, an EPROM, a flash EEPROM, any other memory chip or any other memory cartridge or any other medium from which a computer can read.

[0084] Databases, data repositories, or other data storage devices described herein may include various mechanisms for storing, retrieving, and accessing different types of data, including a hierarchical database, a file set in a file system, an application database in a proprietary format, a relational database management system (RDBMS), and so on. Each such data storage device is generally contained within a computing unit that employs a computer operating system, such as one of those mentioned above, and is accessed via a network using any number of methods. A file system may be accessible by a computer operating system and may contain files that can be stored in various formats.An RDBMS generally uses the Structured Query Language (SQL), in addition to a language for creating, storing, editing and executing stored procedures, such as the PL / SQL language mentioned above.

[0085] In some examples, system elements can be implemented as computer-readable instructions (e.g., software) on one or more computing devices (e.g., servers, personal computers, etc.) that are stored on associated computer-readable media (e.g., disks, memory, etc.). A computer program product can comprise such instructions stored on a computer-readable medium for executing the functions described herein. Some or all of the computer operations disclosed herein as being performed by the controller 108 can be such computer program products. In some examples, these computer program products can be provided as software that, when executed on one or more processors, provides the computer operations described herein.Alternatively, the computer program product can be provided as hardware or firmware, or as combinations of software, hardware and / or firmware.

[0086] With reference to the processes, systems, procedures, heuristics, etc., described herein, it is understood that, although the steps of such processes, etc., have been described as occurring in a specific, ordered sequence, such processes could be carried out with the described steps performed in a different order than that described herein. Furthermore, it is understood that certain steps can be performed simultaneously, that further steps can be added, or that certain steps described herein can be omitted. In other words, the present descriptions of processes serve the purpose of illustrating specific embodiments and should in no way be interpreted as limiting the claims.

[0087] Accordingly, it is understood that the above description is intended to be illustrative rather than limiting. A review of the above description would reveal many other embodiments and applications beyond the given examples. The scope of protection is not to be determined by reference to the above description, but instead by reference to the accompanying claims together with the full range of equivalents to which these claims entitle. It is expected and intended that future developments will occur in the technologies discussed herein and that the disclosed systems and methods will be integrated into such future embodiments. In summary, it is understood that the application may be modified and amended.

[0088] All terms used in the claims shall be understood in their broadest reasonable interpretation and in their usual meaning, as understood by persons with expertise in the technologies described herein, unless explicitly stated otherwise. In particular, the use of singular articles such as "a", "a", "an", "the", "the", "said", "said", etc., shall be understood as indicating one or more of the elements shown, unless a claim expressly specifies a limitation to the contrary.

[0089] The summary of disclosure is provided to enable the reader to quickly determine the nature of the technical disclosure. It is submitted with the understanding that it is not intended to be used to interpret or limit the scope of protection or the meaning of the claims. Additionally, it can be seen from the preceding detailed description that various features in different embodiments are grouped together for the sake of clarity. This approach to the disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly stated in each claim. Rather, the subject matter of the invention lies in fewer than all the features of a single disclosed embodiment, as set forth in the following claims.Therefore, the following claims are hereby included in the Detailed Description, each claim being a separate subject matter being claimed independently.

[0090] Although exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the invention. Instead, the terms used in the specification are descriptive rather than limiting, and it is understood that various modifications can be made without deviating from the concept and scope of the invention. Furthermore, the features of different implementations can be combined to form further embodiments of the invention.

Images