Patent ID: 12202436

DETAILED DESCRIPTION

FIG.1shows a block diagram of components of a system100of vehicle101for providing passive entry to an approaching user of vehicle101(e.g., the driver), in accordance with some embodiments of the present disclosure. Vehicle101may be a car (e.g., a coupe, a sedan, a truck, an SUV, a bus), a motorcycle, an aircraft (e.g., a drone), a watercraft (e.g., a boat), or any other type of vehicle. Vehicle101may be an electric vehicle, internal combustion engine vehicle, hybrid vehicle, or any other type of vehicle.

Vehicle101may comprise processing circuitry102, which may comprise processor104and memory106. Processor104may comprise a hardware processor, a software processor (e.g., a processor emulated using a virtual machine), or any combination thereof. In some embodiments, processor104and memory106in combination may be referred to as processing circuitry102of vehicle101. In some embodiments, processor104alone may be referred to as processing circuitry102of vehicle101. Memory106may comprise hardware elements for non-transitory storage of commands or instructions, that, when executed by processor104, cause processor104to operate vehicle101in accordance with embodiments described above and below. Processing circuitry102may be communicatively connected to components of vehicle101via one or more wires, or via wireless connection.

Processing circuitry102may be communicatively connected to electric battery108, which may be configured to provide power to one or more of the components of vehicle101during operation. Image sensor118(e.g., a camera) may be communicatively coupled to processing circuitry102(e.g., by way of sensor interface114) and positioned at any suitable position in an interior or exterior of vehicle101. In some embodiments, image sensor118may capture images of destinations traveled to by vehicle101to identify the environment in which vehicle101is parked (e.g., an outdoor parking lot, an indoor parking lot, a garage, the number of nearby vehicles, etc.). Processing circuitry102may be communicatively connected to input interface112(e.g., a steering wheel, a touchscreen display, buttons, knobs, a microphone or other audio capture device, etc.) via input/output circuitry110. In some embodiments, a driver of vehicle101may be permitted to select certain settings in connection with the operation of vehicle101(e.g., passive entry settings). In some embodiments, processing circuitry102may be communicatively connected to Global Positioning System (GPS) system126of vehicle101, where the driver may interact with the GPS system via input interface112. GPS system126may be in communication with multiple satellites to ascertain the vehicle's location and provide navigation directions to processing circuitry102. As another example, the positioning device may operate on terrestrial signals, such as cell phone signals, Wi-Fi signals, or ultra-wideband signals to determine a location of vehicle101. The determined location may be in any suitable form such as a geographic coordinate, a street address, a nearby landmark such as an identification of the nearest charging station or a tagged location associated with the vehicle (e.g., a location of a home of the user stored in memory106).

Processing circuitry102may be communicatively connected to door122, seat124, display128, speaker130, and lights132, by way of input/output circuitry110. In some embodiments, input/output circuitry110may comprise one or more domain controllers. Display128may be located at a dashboard of vehicle101and/or a heads-up display at a windshield of vehicle101. For example, an interface for GPS system126or an interface of an infotainment system may be generated for display, and display128may comprise an LCD display, an OLED display, an LED display, or any other type of display. In some embodiments, display128may provide a driver with a navigation interface, an entertainment interface, a backup camera interface, etc. Speaker130may be located at any location within the cabin of vehicle101, e.g., at the dashboard of vehicle101, on an interior portion of the vehicle door. In some embodiments, speaker130may provide audio that is audible outside of vehicle101(e.g., a personalized greeting during a welcome action of the vehicle). Lights132may be interior or exterior lights that provide light from inside or outside of vehicle101(e.g., during a welcome action of the vehicle). Processing circuitry102may also be communicatively connected (e.g., by way of sensor interface114) to door sensor116(e.g., which may sense an open door of vehicle101).

Processing circuitry102may be in communication (e.g., via communications circuitry134) with mobile device136(e.g., of the driver of vehicle101). Such connection may be wired or wireless. In one example, such a connection is a two-way connection via the BLE standard (e.g., via a BLE transceiver). In some embodiments, communications circuitry134and/or mobile device136may be in communication with one or more servers138(e.g., over a communications network such as, for example, the Internet). As explained in further detail inFIG.2, vehicle101may include a vehicle access system (VAS) (e.g., implemented by processing circuitry102and communications circuitry134) for initiating passive entry features (e.g., providing passive entry to vehicle101) in response to determining that mobile device136has approached within a predetermined distance from vehicle101(e.g., two meters). In some embodiments, in order to improve distance modeling based on RSSI values, mobile device136may collect and share contextual information of mobile device136(e.g., that may affect RSSI values) with vehicle101, as explained in further detail below. In some embodiments, distance modeling may also be based on profile information of mobile device136, as explained in further detail below.

It should be appreciated thatFIG.1shows only some of the components of vehicle101, and it will be understood that vehicle101also includes other elements commonly found in vehicles, e.g., a motor, brakes, wheels, wheel controls, turn signals, windows, doors, etc. Vehicle101may also include a plurality of domain controllers and a central controller for managing power modes of components of vehicle101(e.g., during a passive entry feature).

FIG.2shows a block diagram of components of a system200of vehicle101and mobile device136ofFIG.1for providing contextual information of mobile device136to vehicle101, in accordance with some embodiments of the present disclosure. Mobile device136may execute instructions stored in memory to run a vehicle interface application to collect information (e.g., sensor/camera data, accelerometer data, location data, etc.), to determine contextual information of mobile device136based on the collected information, and to communicate the determined contextual information to vehicle101over a secure BLE connection established with vehicle101. The vehicle interface application may use existing hardware and sensors of mobile device136to collect the information used to determine the contextual information. The contextual information may serve as an indication for conditions (e.g., environmental conditions) that may affect the strength of the secure BLE connection between mobile device136and vehicle101(e.g., by affecting the antenna/signal strength). In one example, if mobile device136is in the pocket of a user, the strength of the secure BLE connection (e.g., signal strength) may be attenuated. In another example, if mobile device136is in a parking garage with vehicle101, the strength of the secure BLE connection may be amplified. However, it should be understood that these are only two examples and that the vehicle interface application may collect/obtain any suitable information from mobile device136that may be used to determine if there are any conditions that may affect the strength of the BLE connection.

As shown, mobile device136includes contextual engine208including in-pocket detection module210, user activity recognition module212, user semantic location module214and geo-fencing module216. Although only four modules are shown, it should be understood that contextual engine208may include more or fewer modules, depending on what contextual information is desired for a particular application.

In-pocket detection module210may determine if mobile device136is in the pocket of a user based on data from ambient light sensor202. For example, if no ambient light is detected by ambient light sensor202, in-pocket detection module210may determine that the mobile device136is likely in the pocket of a user. In some embodiments, in-pocket detection module210may utilize data from other sensors to improve the determination of whether mobile device136is in the pocket of a user. For example, in-pocket detection module210may further consider the current lock/unlock state of a screen of mobile device136, the temperature of mobile device136, as well as data from gyroscope/accelerometer204to determine whether mobile device136is in the pocket of a user, as well as the depth of the pocket and the location of the pocket relative to the user and vehicle101(e.g., front/side/rear pocket). For example, data from gyroscope/accelerometer204may vary based on whether mobile device136is being held by a user, is in a front pocket of a user, or is in a back pocket of a user. In some embodiments, in-pocket detection module210may determine if mobile device136is in a bag of a user (e.g., a backpack or purse). In some embodiments, in-pocket detection module210may leverage application programming interfaces (APIs) of the operating system (OS) of mobile device136to determine if mobile device136is in a pocket of a user or is in any other bag that may act to attenuate the signal received by vehicle101.

User activity recognition module212may determine events related to user activity based on data from gyroscope/accelerometer204. For example, user activity recognition module212may determine if a user is still, walking, running, riding a scooter, etc. In some embodiments, user activity recognition module212may leverage development kits provided by the OS of mobile device136for low-power activity sensing, thereby improving the battery life of mobile device136. In some embodiments, user activity recognition module212may utilize data from other sensors to improve the user activity determination. For example, user activity recognition module212may further consider GP S/cellular/network location sensor206to determine how quickly (or slowly) a user is moving (e.g., still, walking, running, etc.).

User semantic location module214may determine if mobile device136is in a specific location or type of location based on data from GPS/cellular/network location sensor206and/or location-based services207provided by the OS of mobile device136. For example, user semantic location module214may determine if mobile device136is in a trusted place (e.g., the user's home or office) or a public place (e.g., shopping mall, parking lot, parking garage).

Geo-fencing module216may determine if mobile device136is in a custom geofenced area based on data from GPS/cellular/network location sensor206and/or location-based services207provided by the OS of mobile device136.

Contextual events processor218may identify contextual events based on data from one or more of in-pocket detection module210, user activity recognition module212, user semantic location module214, and geo-fencing module216and selectively output contextual information to BLE transceiver220to be communicated to vehicle101. In some embodiments, contextual events processor218may apply processing to smooth data and track contextual information over time (e.g., to avoid communicating errant data to vehicle101). As explained in greater detail with reference toFIG.4, contextual information may be included in a BLE packet transmitted to vehicle101over a secure BLE connection.

As shown, vehicle101may include VAS222including BLE transceiver224(e.g., implemented by communications circuitry134) and wake-up module226(e.g., implemented by processing circuitry102). As explained in greater detail below, wake-up module226may determine the distance between mobile device136and vehicle101based on RSSI and the contextual information received from mobile device136to provide reliable passive entry to vehicle101under a variety of conditions.

FIG.3shows an illustrative mobile device300for controlling vehicle101using a vehicle interface application, in accordance with some embodiments of the present disclosure. Mobile device136ofFIGS.1and2may be implemented as the mobile device300. As shown, the mobile device300may be a smartphone. As shown, mobile device300includes and input/output (I/O) path302, control circuitry304, which includes processing circuitry306and storage308, one or more sensors310, user input interface312, and display314. Mobile device300may receive and send data (e.g., authentication information, contextual information, etc.) using the I/O path302, which may connect the control circuitry304(and specifically processing circuitry306) to the communication paths described above (e.g., the BLE communication path and the mobile communication path). Control circuitry304may be based on any suitable processing circuitry such as processing circuitry306. Control circuitry304may execute instructions for a vehicle interface application stored in memory (i.e., the storage308). Specifically, control circuitry304may be instructed by the vehicle interface application to perform the functions discussed above and below. A user may send instructions to control circuitry304using user input interface312. User input interface312may be any suitable user interface, such as a touchscreen, a voice recognition interface, etc. Display314may be provided as a stand-alone device or integrated with other elements of mobile device300. For example, display314may be a touchscreen that is integrated or combined with the user input interface312.

FIG.4shows an illustrative data format of a packet400communicated from mobile device136to vehicle101via a BLE connection, in accordance with some embodiments of the present disclosure. Packet400may be a BLE command that is communicated from mobile device136to vehicle101after a secure BLE connection is established (e.g., after mobile device136is connected and authenticated by a master BLE transceiver with authentication capability). As shown, packet400includes a plurality of portions including packet number portion402, RSSI portion404, contextual header portion406, and HMAC portion408. Packet number portion402may be used to establish packet ordering, RSSI portion404includes an RSSI value, and HMAC portion408is used to establish a secure connection. Contextual header portion406may be a portion for communicating contextual information aggregated by contextual events processor218ofFIG.2, as described below.

As shown, contextual header portion406may be a two-byte data field including a validity bit (V410), an extension flag bit (X412), and14attribute bits (A0414-A13442). Validity bit V410may be used to indicate whether the attribute bits (A0414-A13442) should be read (e.g., set to 1 if valid). By setting validity bit V410to invalid (e.g., set to 0), the remainder of contextual header portion406does not need to be parsed, and the last known contextual information (e.g., included in the last valid contextual header portion) is used, thereby allowing contextual header portion406to refresh at a lower frequency than that of RSSI transmission, which may change much more quickly than contextual information of mobile device136. Extension flag bit X412may provide future-proof capability to extend definitions of the contextual header portion406. For example, if extension flag bit X412is flagged (e.g., set to 1), another 16-bit extension header may be included after contextual header portion406.

Attribute bits (A0414-A13442) represent the contextual information aggregated by contextual events processor218ofFIG.2at the time when RSSI values are captured. Table 1 below includes one example of the attributes that may be represented by attribute bits (A0414-A1416). As shown, each attribute is represented by two bits (e.g., corresponding to four possible values or interpretations). However, this is only an example and each attribute may be represented by one bit or greater than two bits.

TABLE 1A(x)AttributeInterpretationA0-A1Inside00 - IndeterminatePocket01 - Not Inside Pocket10 - Inside Pocket11 - In TransitionA2-A3Pocket00 - IndeterminateType01 - Front Pocket(small attenuation when approaching)10 - Back Pocket(large attenuation when approaching)11 - Deep Pocket(large attenuation all directions)A4-A5Movement00 - IndeterminateSpeed01 - Still10 - Walking11 - RunningA6-A7Movement00 - IndeterminateDirection01 - Moving Toward Vehicle10 - Moving Away from Vehicle11 - Moving (uncertain direction)A8-A9At Home00 - Indeterminate01 - At Home10 - Not at Home11 - In TransitionA10-A11At Custom00 - IndeterminatePlace01 - At Custom Place10 - Not at Custom Place11 - In TransitionA12-A13Reserved

In addition to packet400, mobile device136may also communicate profile information of mobile device136. The profile information may include information related to the type of device (e.g., folded phone, iOS phone, Android phone, phone model, etc.). In some embodiments, each profile may be linked to a set of specific parameters used for distance modeling. For example, BLE characteristics of different mobile devices may be significantly different from each other. Accordingly, each set of specific parameters may represent the RSSI-to-distance relationship. In some embodiments, the RSSI-to-distance relationship may be established by calibrating the RSSI value when the mobile device is separated from vehicle101by one meter and adjusting the RSSI-to-distance relationship based on a scaling factor dependent on the specific environment. For example, the RSSI-to-distance relationship for a particular mobile device in a specific environment may be determined based on the equation d=(RSSIi(do)−RSSIi(d))/10*n, where d0is one meter, d is the current distance, and n is a scaling factor dependent on the specific environment (e.g., an indoor parking garage). In some embodiments, a distance model is generated from a curve fitting the calibration data (e.g., logarithmic curve fitting). In some embodiments, each set of specific parameters may be stored in a look-up table (LUT).

In some embodiments, the RSSI-to-distance relationship may be established by calibrating the RSSI value when the mobile device is in vehicle101. In one example, if the mobile device detected at a known location within vehicle101(e.g., a wireless charging pad), the RSSI value may be calibrated based on the known distance between the known charging location and one or more BLE transceivers in vehicle101.

In some embodiments, it may be advantageous to monitor the behavior of a user (e.g., the driver) of the mobile device over time to calibrate the RSSI value when the mobile device is in a pocket of the user. For example, for a particular user, there is a high probability that they will keep their mobile device in the same pocket (e.g., their front left pocket). Additionally, there is also a high probability that the user (e.g., the driver) will sit in a fixed location when entering vehicle101(e.g., the driver's seat of vehicle101). Thus, by monitoring the behavior of the user of the mobile device, the RSSI-to-di stance relationship for a particular user, when the mobile device is in a pocket of the user, may be established by calibrating the RSSI value when the user is sitting in vehicle101, based on the estimated distance between the location of the user's pocket and one or more BLE transceivers in vehicle101. Thereafter, when the user is approaching vehicle101, the RSSI-to-distance relationship calibrated for the user may be retrieved from a profile associated with the user, and a more accurate distance model may be provided. In some embodiments, different RSSI-to-distance relationships for a particular user may be determined based on the clothes that the user is likely wearing and whether those clothes are likely to interfere with the RSSI value. For example, a cold weather RSSI-to-distance relationship may be determined when the user is likely wearing a coat with deep pockets (e.g., which may reduce the RSSI value), and a warm weather RSSI-to-distance relationship may be determined when the user is likely not wearing a coat.

In some embodiments, the profile information may be an eight-bit parameter corresponding to a LUT for different device profiles. As described in further detail below with reference toFIG.8, when a new device is added to a user profile (e.g., a user logs in to a vehicle interface application on a new smartphone), a new set of specific parameters used in distance modeling may be loaded. Table 2 below includes one example of an eight-bit phone profile parameter that indicates the corresponding LUT (“phone model LUT”) to use for distance modeling for different phones. However, this is only one example, and a set of parameters for distance modeling may be associated with a device in any suitable manner.

TABLE 2PhonePhone Model LUTComment0LUT00Default LUT1LUT01iPhone LUT2LUT02Samsung phone LUT3LUT03Pixel phone LUT4LUT04Reserved5LUT05Reserved6LUT06Reserved7LUT07Reserved

FIGS.5A and5Bshow illustrative distance models for different mobile devices in various environments, in accordance with some embodiments of the present disclosure. As shown, each distance model (501a,501b,501c,505a,505b, and505c) includes an RSSI-to-distance relationship that is calibrated for a particular mobile device in a particular environment, as explained above. In some embodiments, certain distance models include a user specific RSSI-to-distance relationship (e.g., and RSSI-to-distance relationship calibrated when the particular mobile device is the user's pocket, as explained above). As explained in further detail below, when a mobile device (e.g., mobile device136) is detected by vehicle101, a particular distance model for determining the distance between mobile device136and vehicle101may be selected based on received contextual information of mobile device136and device profile information of mobile device136. In some embodiments, a selected distance model may be adjusted (e.g., by applying a scaling factor) based on other detected conditions that may affect the RSSI-to-distance relationship (e.g., the number of surrounding cars in a parking lot).

FIG.5Ashows illustrative distance models501a,501b, and501c(collectively referred to as distance models501) for a first mobile device. For example, with reference to Table 2 above, the first mobile device may be “Phone1” and the distance models may be stored in “LUT01.” Distance model501amay be a distance model representing a situation in which a user approaches vehicle101with the first mobile device in their hand (e.g., not in a pocket or bag). For example, when attribute bits A0414-A1416, in packet400received by vehicle101, indicate “not in pocket” (e.g., “01”), distance model501amay be selected. As shown by curve503ain distance model501a, when the first mobile device is one meter away from vehicle101, the RSSI value corresponds to a received signal power of −45 decibel milliwatts (dBm). In some embodiments, because RSSI is a relative value and dBm is an absolute value, the RSSI value may be specified on a scale of 0 to 255 and may correspond the absolute number representing the received signal power (e.g., in dBm).

Distance model501bmay be a distance model representing a situation in which a user approaches vehicle101with the first mobile device in their pocket. For example, when attribute bits A0414-A1416, in packet400received by vehicle101, indicate “inside of pocket” (e.g., “10”), distance model501bmay be selected. As shown by curve503bin distance model501b, when the first mobile device is one meter away from vehicle101, the RSSI value corresponds to a received signal power of −55 dBm. In some embodiments, distance model501bmay be further adjusted (e.g., by applying a scaling factor) if attribute bits A2418-A3420indicate a pocket type. For example, if attribute bits A2418-A3420indicate that the first mobile device is in a “deep pocket” (e.g., “11”), the scaling factor will adjust distance model501bso that a further attenuated RSSI value (e.g., −60 dBm) corresponds to a distance of one meter. As explained above, distance model501bmay be calibrated by monitoring the behavior of the of the mobile device over time to calibrate the RSSI value when the mobile device is in a pocket of the user.

Distance model501cmay be a distance model representing a situation in which a user approaches vehicle101with the first mobile device in their hand (e.g., not in a pocket or bag), but in an environment that amplifies the BLE signal (e.g., an indoor parking garage). As shown by curve503cin distance model501c, when the first mobile device is one meter away from vehicle101, the RSSI value corresponds to a received signal power of −40 dBm. In some embodiments, distance model501cmay be selected when packet400indicates the environment. In some embodiments, vehicle101may indicate the environment (e.g., based on a location determined by GPS126). In some embodiments, vehicle101may apply a scaling factor based on environmental determinations (e.g., image sensor118identifies obstacles around vehicle101, such as other vehicles or structures).

FIG.5Bshows illustrative distance models505a,505b, and505c(collectively referred to as distance models505) for a second mobile device. For example, with reference to Table 2 above, the second mobile device may be “Phone2” and the distance models may be stored in “LUT02.” As similarly discussed above with reference toFIG.5A, distance model505amay be a distance model representing a situation in which a user approaches vehicle101with the second mobile device in their hand. As shown by curve507ain distance model505a, when the second mobile device is one meter away from vehicle101, the RSSI value corresponds to a received signal power of −50 dBm.

As similarly discussed above with reference toFIG.5A, distance model505bmay be a distance model representing a situation in which a user approaches vehicle101with the second mobile device in their pocket. As shown by curve507bin distance model505b, when the second mobile device is one meter away from vehicle101, the RSSI value corresponds to a received signal power of −63 dBm.

As similarly discussed above with reference toFIG.5A, distance model505cmay be a distance model representing a situation in which a user approaches vehicle101with the second mobile device in their hand, but in an environment that amplifies the BLE signal. As shown by curve507cin distance model505c, when the first mobile device is one meter away from vehicle101, the RSSI value corresponds to a received signal power of −45 dBm. Although three distance models are described for each mobile device, it should be understood that any suitable number of distance models may be associated with one or more mobile devices. In some embodiments, parameters for one or more distance models may be stored in a LUT. Further, in some embodiments, it should be understood that for one or more distance models, a calibrated RSSI-to-distance value at a one-meter distance may be determined (e.g., measured) and stored along with scaling factors for each environment. Still further, it should be understood that the user specified calibrated RSSI-to distance value may be determined (e.g., measured) for a particular user when the user is sitting inside of vehicle101. Still further, it should be understood that more than one scaling factor may be combined to generate or adjust a distance model to reflect the current environmental conditions. Still further, it should be understood that if contextual information from the approaching mobile device indicates a change in environment (e.g., a user takes their phone out of their pocket), the currently selected distance model may be replaced with a new distance model corresponding to the change.

FIG.6shows an illustrative diagram600for providing passive entry to vehicle101, in accordance with some embodiments of the present disclosure. The process may be executed by processing circuitry102and mobile device136ofFIG.1, or, more specifically, system200ofFIG.2. As shown, user602may be located outside of vehicle101. In some embodiments, vehicle101may have transitioned to a sleep state in order to conserve battery. While in the sleep state, VAS222may monitor the area around vehicle101to detect the presence of user602. For example, in one embodiment, VAS222(e.g., a domain controller/module implemented by communications circuitry134and processing circuitry102ofFIG.1) may listen, using a plurality of BLE transceivers (604a,604b,604c,604d, collectively referred to as BLE transceivers or BLE sensors), for an advertisement from mobile device136(e.g., an authorized mobile device) of user602, transmitted according to the BLE standard. In some embodiments, VAS222may determine the RSSI of the advertisement from one or more of BLE transceivers604and select the one with the highest RSSI to determine the distance of mobile device136from vehicle101. For example, the BLE transceiver with the highest RSSI may correspond to the BLE transceiver with the best line-of-sight to mobile device136and may therefore provide the best estimate of the distance (“d”) of mobile device136from vehicle101.

In response to establishing a secure BLE connection between mobile device136and VAS222, VAS222may receive packets (e.g., packets400) including contextual information of mobile device136. As described above, VAS222may also receive profile information of mobile device136. Based on the received contextual information and profile information, VAS222may select a distance model (e.g., one of the distance models illustrated inFIGS.5A and5B) and determine the distance d based on the selected distance model and determined RSSI values. Once VAS222determines that mobile device136is within a predetermined range, mobile device136may initiate a passive entry feature.

Although passive entry (e.g., unlocking one or more doors of vehicle101) is described as the passive entry feature, it should be understood that the passive entry feature (or sequence of actions) may include additional actions or steps performed at the same or different times. For example, if certain domain controllers of vehicle101take several seconds to wake up, the passive entry feature may include waking up the domain controllers as the user is approaching vehicle101so the user does not have to wait for certain functions to be available when reaching vehicle101. For example, as shown, when VAS222determines that mobile device136enters a near zone defined by boundary line606(which may be approximately 10 meters), VAS222begins transitioning certain domain controllers (electronic control units) of vehicle101from a sleep state to a standby or ready state, so that the domain controllers that take several seconds to wake up may be quickly transitioned to an on state when the user reaches the vehicle. In some embodiments, boundary line606may be dynamically determined based on how quickly the user is approaching the vehicle.

When VAS222determines that mobile device136enters a close zone defined by boundary line608(which may be approximately 1-2 meters), VAS222may automatically unlock one or more doors of vehicle101to provide passive entry to vehicle101. A passive entry algorithm executed by VAS222may require a threshold number of RSSI samples before making a determination to unlock one or more doors. However, in some embodiments, if the received contextual information of mobile device136indicates that the user is quickly approaching vehicle101(e.g., attribute bits A4424-A7430indicate that the user is running toward vehicle101), the threshold number of RSSI samples may be reduced so as to enable VAS222to make a decision to unlock one or more doors before the user reaches vehicle101.

In some embodiments, VAS222may modify wake-up boundaries or thresholds based on location information (e.g., provided by user semantic location module214or geo-fencing module216ofFIG.2or by vehicle101). For example, when vehicle101is at a public place (e.g., a shopping mall), VAS222may wait until the user is closer to vehicle101before unlocking vehicle101(e.g., compared to when vehicle101is at a trusted location). Additionally, when vehicle101is at the home of a user, VAS222may use machine learning to adjust wake-up boundaries based on historical information (e.g., associated with a user profile) to avoid initiating the wake-up process when the user walks by their garage. However, this is only one example; VAS222may adjust wake-up boundaries, distance models, parameter sensitivity or any other components of the passive entry algorithm based on historical information.

FIG.7shows a flowchart of an illustrative process700for providing passive entry to vehicle101, in accordance with some embodiments of the present disclosure. The process may be executed by processing circuitry102ofFIG.1, or, more specifically, VAS222ofFIG.2. Process700begins at step702when processing circuitry102detects a mobile device (e.g., mobile device136) in the vicinity of vehicle101. For example, processing circuitry102may detect an advertisement signal from the mobile device (e.g., via BLE).

At704, processing circuitry102may establish a secure BLE connection with the mobile device. For example, processing circuitry102may authenticate the detected mobile device to establish the secure BLE connection.

At706, processing circuitry102may receive one or more signals from the mobile device over the secure BLE connection. For example, processing circuitry102may receive from an application executing on the mobile device associated with a user, the one or more signals. For example, processing circuitry102may receive a plurality of the command packets illustrated inFIG.4.

At708, processing circuitry102may determine a signal strength based on the one or more signals. For example, processing circuitry102may determine RSSI values of the one or more signals. In some embodiments, an RSSI value is determined from each signal (e.g., command packet). In some embodiments, multiple values are determined across multiple signals, and an average or medium value is selected as the determined signal strength for the multiple signals.

At710, processing circuitry102may determine contextual information associated with the mobile device based on the one or more signals. For example, processing circuitry102may receive the contextual header described above with reference toFIG.4(e.g., contextual header portion406). Processing circuitry102may parse a received contextual header to identify the contextual information associated with the mobile device (e.g., indicating whether the mobile device is in the pocket or backpack of a user thereby impacting the received signal strength). In some embodiments, processing circuitry102may receive contextual information in one or more other signals from the mobile device (e.g., via other BLE signals or cellular signals). In some embodiments, step710may be combined with step708.

At712, processing circuitry102may receive device profile information associated with the mobile device based on the one or more signals. In some embodiments, device profile information may be transmitted separately from the packets including the contextual header. For example, processing circuitry102may recognize previously paired mobile devices based on a received BLE advertisement. In some embodiments, processing circuitry102may determine a user profile associated with the recognized device.

At714, processing circuitry102may select a distance model corresponding to the device profile information and the contextual information. In some embodiments, selecting a distance model includes selecting a distance model and modifying the selected distance model based on one or more additional environmental factors that may affect the RSSI-to-distance relationship of the selected distance model (e.g., as the additional environmental factors are not accounted for by the selected distance model). For example, if the vehicle is parked in an outdoor parking lot and the user approaches the vehicle with the phone in their pocket, processing circuitry102may select a corresponding distance model (if available). If, however, the selected distance model does not correspond to the number of cars that are in the outdoor parking lot (e.g., the vehicle determines that the outdoor parking lot is more or less crowded than the environment associated with the distance model), processing circuitry102may modify the selected distance model to more closely reflect the current vehicle environment (e.g., by apply a correction factor to the selected distance model). In some embodiments, selecting a distance model includes selecting a user specific distance model associated with a profile of a particular user when the user approaches the vehicle with the phone in their pocket. For example, the selected distance model may include a calibrated received signal strength indicator (RSSI) value that was calibrated when the mobile device is in the pocket of the user and the user is sitting in the vehicle.

At716, processing circuitry102may determine a distance between vehicle101and the mobile device based on the selected distance model and the determined signal strength. For example, if distance model501aofFIG.5Ais selected, processing circuitry102may determine the distance as one meter if the determined signal strength is −45 dBm)

At718, processing circuitry102may determine if the mobile device is approaching vehicle101and has entered within a predetermined distance from vehicle101(e.g., based on the determined distance). In response to determining that the mobile device is approaching vehicle101and within the predetermined distance (“Yes” at step718), process700proceeds to step720. Otherwise (“No” at step720), processing circuitry returns to step706and continues to receive signals and determine changes in distance (or contextual information). In some embodiments, steps710-714may not be performed each time a new signal (e.g., packet400) is received. For example, as detailed above, if validity bit V410is set to invalid for a received packet400, processing circuitry102may skip parsing contextual header portion406and determine the updated distance (step716) based on the last known contextual information (e.g., included in the last valid contextual header portion). In some embodiments, by periodically skipping steps710-714, the distance may still be accurately determined while reducing processing (e.g., because RSSI may change more quickly than contextual information).

At720, processing circuitry102may initiate a passive entry feature of vehicle101. For example, as described above with reference toFIG.6, processing circuitry102may first wake up domain controllers in response to determining that the mobile device is within a first distance, before unlocking one or more doors of vehicle101in response to determining that the mobile device is within a second distance less than the first distance. However, this is only one example, and the processing circuitry102may execute any suitable passive entry features based on the determined distance.

FIG.8shows a flowchart of an illustrative process800for adding new device profiles and for selecting a distance model based on the received device profile information, in accordance with some embodiments of the present disclosure. The process may be executed by processing circuitry102ofFIG.1, or, more specifically, VAS222ofFIG.2. Process800begins at step802when processing circuitry102determines if any new device profiles have been received. For example, in each vehicle software over-the-air (OTA) update, VAS222may check for any new device profiles (e.g., new device profile LUT) included in the software package. In some embodiments, new device profiles may be provided via a server (e.g., server138). In response to determining that no new device profiles have been received (“No” at step802), process800proceeds to step808. Otherwise (“Yes” at step802), process800proceeds to step804.

At804, processing circuitry102may add the new device profile to stored profiles. For example, processing circuitry102may add the new device profile to a stored table or database (e.g., as described in Table 2 above) by updating device profile LUT enumerated (“enum”) definitions.

At806, processing circuitry102may load one or more distance models associated with the new device profile to VAS222, before any new mobile device is connected and authenticated to VAS222. In some embodiments, once the new mobile device is connected and authenticated to VAS222after the one or more distance models have been loaded to VAS222, the new mobile device may provide updated values or distance models by a device profile builder in the vehicle interface application executed by the new mobile device.

At808, during normal operation (e.g., when passive entry is enabled), processing circuitry102may listen for and receive BLE commands from one or more mobile devices associated with vehicle101. For example, processing circuitry may listen for an advertisement (e.g., a BLE advertisement packet) from the one or more mobile devices.

At810, in response to receiving a BLE command, processing circuitry102may parse the BLE command to determine if the BLE command includes any device profile information. In response to determining that the BLE command does not include any device profile information (“No” at step810), process800returns to step808and waits to receive another BLE command. Otherwise (“Yes” at step810), process800proceeds to step812.

At812, processing circuitry102may parse the received device profile information to identify a corresponding device profile (e.g., loaded in VAS222), as similarly described above in step712ofFIG.7.

The processes discussed above are intended to be illustrative and not limiting. One skilled in the art would appreciate that the steps of the processes discussed herein may be omitted, modified, combined and/or rearranged, and any additional steps may be performed without departing from the scope of the invention. For example, if certain contextual information or device profile information is not available, a default distance model or the distance model most closely matching the available information may be selected. Additionally, as described above, steps710-714may be periodically skipped while continuing to determine the distance between the vehicle and the mobile device based on the last known contextual information. More generally, the above disclosure is meant to be exemplary and not limiting. Only the claims that follow are meant to set bounds as to what the present invention includes. Furthermore, it should be noted that the features and limitations described in any one embodiment may be applied to any other embodiment herein, and flowcharts or examples relating to one embodiment may be combined with any other embodiment in a suitable manner, done in different orders, or done in parallel. In addition, the systems and methods described herein may be performed in real time. It should also be noted that the systems and/or methods described above may be applied to, or used in accordance with, other systems and/or methods.