System and method for enabling vehicle requisition

Abstract

The present disclosure provides a system and method for enabling vehicle requisition. A vehicle is disclosed that includes a transceiver, a memory, and a processor. The transceiver may be configured to receive access instructions from a server to provide access rights to a user device of a user not associated with the vehicle. The memory may be configured to store vehicle access level information. The vehicle access level information may include a vehicle access level to be provided to the user. The processor may be configured to obtain the access instruction from the transceiver and authenticate the user based on the obtained access instruction. The processor may also obtain the vehicle access level information in response to authenticating the user, and enable activation of a vehicle component based on the vehicle access level information.

Description

Technical Field

[0001] The present disclosure relates to systems and methods for enabling vehicle requisitioning. Background Art

[0002] Natural disasters such as hurricanes, tornadoes, storms, and man-made events such as terrorist acts cause inconveniences to users. Such emergency situations often result in loss of property, vehicles, or in some cases, life. When users encounter emergency situations, they often seek refuge in a safe place. In many instances, users cannot easily find a place where they can seek shelter. Even if they identify such safe places, they may not be able to enter them.

[0003] Therefore, there is a need for a system that can allow users to easily enter a location during an emergency situation. Summary of the invention

[0004] The present disclosure describes a vehicle that can be configured to provide shelter and access to users who may be trapped in a geographic area experiencing an emergency situation (e.g., a natural disaster or a man-made disaster). In this sense, an emergency situation can be a situation characterized as a crisis, an emergency, a disaster, etc. (collectively referred to herein as an emergency situation). To obtain access to a vehicle, a user can transmit a request to a server that can be communicatively coupled to the vehicle via a user device. In response to receiving the request, the server can determine whether access to the vehicle can be provided to the user and the level of vehicle access that can be provided based on vehicle access information that can be pre-stored on the server. The vehicle access information can include: a confirmation from the vehicle owner that the vehicle can be used to provide access rights to users who may be trapped in an emergency situation, and the level of vehicle access that can be provided to the user. For example, the vehicle owner can allow the user to seek shelter only in the vehicle but not drive, or drive the vehicle only 10 miles or possibly reach the nearest police station, hospital or other designated destination via a specified route, or only touch the vehicle door and heating, ventilation and air conditioning (HVAC) system, etc. In some aspects, the server or vehicle may determine the designated route based on a number of parameters including, but not limited to, user input, cloud input, vehicle-based analysis of emergency situation patterns (e.g., predicted rain / wind speeds and known flooding patterns) when cloud input is not available, etc. In some aspects, the designated route may prevent the vehicle from traveling through areas that are known to be impassable.

[0005] In response to determining that the user can access the vehicle based on the vehicle access information, the server can transmit access instructions and the vehicle access information to the vehicle and transmit a vehicle access code to a user device associated with the user. In response to receiving the access instructions from the server, the vehicle can output an audio and / or visual notification, which can help the user locate the vehicle in an emergency situation. When the user locates the vehicle, the user can move toward the vehicle.

[0006] In response to the user arriving near the vehicle, the user device associated with the user may transmit the vehicle access code to the vehicle. In some aspects, the vehicle access code may be an authentication code by which the vehicle can authenticate the user device. In this case, the vehicle access code may not be visible to the user, and when the user device is near the vehicle, the user device itself may transmit the vehicle access code to the vehicle. In other aspects, the vehicle access code may be visible to the user on the user device, and the user may need to enter the vehicle access code on an external user interface associated with the vehicle to obtain access to the vehicle. The vehicle may authenticate the user based on the received vehicle access code. The vehicle may also authenticate the user based on facial recognition, scanning of a quick response (QR) code, input of a preset password (as described above), etc. In response to authenticating the user, the vehicle may use the vehicle access information to determine one or more vehicle components that the user can access, such as doors, vehicle ignition, vehicle steering wheel, windows, HVAC systems, etc. The vehicle may then enable the user to activate vehicle components, thereby providing shelter and vehicle access to the user in the event of an emergency.

[0007] In some aspects, a server, a vehicle owner via an owner device, and / or authorities / rescue teams may cause an autonomous vehicle to move in the event of an emergency situation (e.g., a crisis, emergency, disaster, calamity, etc.). As an example, when a vehicle owner desires that the vehicle move away from a geographic area experiencing an emergency situation, the vehicle owner may transmit an autonomous vehicle move request to the vehicle via an owner device or a server. In response to receiving the autonomous vehicle move request, the vehicle may move from its current location to a destination location. In some aspects, information associated with the destination location may be included in the autonomous vehicle move request, which may enable the vehicle to move to the destination location.

[0008] The present disclosure discloses a vehicle that facilitates users to seek shelter and access vehicle components in the event of a natural or man-made disaster. In this way, the vehicle can protect the user from experiencing adverse situations. In addition, the vehicle enables the user to access only those vehicle components that the vehicle owner may allow, thereby ensuring that the vehicle is used according to the preferences of the vehicle owner and is not misused. In addition, the vehicle can be configured to autonomously move away from an area experiencing an emergency situation, thereby protecting the vehicle from some adverse situations.

[0009] These and other advantages of the present disclosure are provided in detail herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Detailed description is set forth with reference to the accompanying drawings. The use of the same reference numerals may indicate similar or identical items. Various embodiments may utilize elements and / or components other than those shown in the accompanying drawings, and some elements and / or components may not be present in various embodiments. The elements and / or components in the accompanying drawings are not necessarily drawn to scale. Throughout this disclosure, singular and plural terms may be used interchangeably, depending on the context.

[0011] Figure 1 An example environment is depicted in which techniques and structures for providing the systems and methods disclosed herein may be implemented.

[0012] Figure 2 A block diagram of an example system for enabling vehicle requisitioning according to the present disclosure is depicted.

[0013] Figure 3 Depicted is an example view of multiple vehicles parked near a user in accordance with the present disclosure.

[0014] Figure 4A and Figure 4B Depicted are example diagrams illustrating movement of multiple vehicles in an emergency situation in accordance with the present disclosure.

[0015] Figure 5 A flow chart of an example method for enabling vehicle requisitioning according to the present disclosure is depicted. DETAILED DESCRIPTION

[0016] The present disclosure will be described more fully hereinafter with reference to the accompanying drawings, in which example embodiments of the disclosure are shown and which are not intended to be limiting.

[0017] Figure 1 An example environment 100 is depicted in which techniques and structures for providing the systems and methods disclosed herein may be implemented. The environment 100 may include a vehicle 102 and a server 104 communicatively coupled to each other. The vehicle 102 may take the form of any passenger or commercial vehicle, such as a sedan, a work vehicle, a crossover vehicle, a truck, a minivan, a taxi, a bus, etc. In addition, the vehicle 102 may be a manually driven vehicle, and / or may be configured to operate in a fully autonomous (e.g., driverless) mode or a partially autonomous mode, and may include any powertrain, such as a gasoline engine, one or more electric actuation motors, a hybrid powertrain, etc. In some aspects, the vehicle 102 may be configured with or incorporate a phone-as-a-key (PaaK) system to support passive entry passive start (PEPS) vehicle operation.

[0018] exist Figure 1In the exemplary aspects depicted in , vehicle 102 may be parked or located in a geographic area experiencing an emergency situation. The emergency situation may be, for example, a natural disaster, such as a flash flood, a hail storm, a tornado, a forest fire, etc., or a man-made event, such as an act of terrorism. Environment 100 may also include a user 106, who may be caught in an emergency situation and attempting to identify one or more vehicles (e.g., vehicle 102) that user 106 can access to seek shelter and / or drive to a safe location. In some aspects, to identify one or more vehicles that user 106 can access to seek shelter and / or drive in an emergency situation, user 106 may transmit a vehicle identification request or a vehicle access request to server 104 via user device 108. User device 108 may be, for example, a mobile phone, a laptop computer, a wearable device, a computer, a tablet computer, or any other device with communication capabilities.

[0019] In some aspects, a PaaK application (“app”) may be installed in the user device 108, and the user 106 may transmit a vehicle access request to the server 104 by executing the PaaK app on the user device 108. In an exemplary aspect, the PaaK app may be hosted on the server 104, and the server 104 may be configured to store user information associated with a plurality of users (including the user 106) that may be registered with the server 104. The user information may include, for example, a user name, contact information, address, social security number, and / or any other user credential information.

[0020] In some aspects, when the user 106 may have registered (or "pre-registered") on the server 104, the user 106 may be able to transmit a vehicle access request to the server 104 via a PaaK app installed on the user device 108. In other words, the user 106 may be able to transmit a vehicle access request to the server 104 when the server 104 may have stored the user's credential information on the server 104. In other aspects, if the user 106 has not yet registered on the server 104, the user 106 may still transmit a vehicle access request to the server 104 via a PaaK app or other means. In this case, the user 106 may transmit one or more user credential information along with the vehicle access request to the server 104 for storage and user verification purposes.

[0021] In response to receiving a vehicle access request from a user device 108, the server 104 may identify one or more vehicles (e.g., vehicle 102) that may be located in the geographic vicinity of the user device 108 and that may be configured or "available" to provide access rights to a user who may be in an emergency situation. For example, the server 104 may identify that a vehicle owner 110 of the vehicle 102 may have "allowed" the server 104 to enable / provide vehicle access rights to a user who may be in an emergency situation. In this case, the vehicle owner 110 may have transmitted (e.g., previously provided) vehicle access level information (or vehicle access information) to the server 104 via the owner device 112 or a PaaK app installed on the owner device 112, indicating that the server 104 may enable / provide access rights to the vehicle 102 to the user who may be in an emergency situation. The owner device 112 may be similar to the user device 108. In an exemplary aspect, the vehicle access information may include, but is not limited to: an indication or confirmation that the vehicle owner 110 consents to use / moving the vehicle 102 during an emergency situation; a profile of users or entities that may be allowed to access the vehicle 102 during an emergency situation; a level of vehicle access that may be provided; a predefined distance that the vehicle 102 may be allowed to move during an emergency situation (which may vary based on the type of emergency situation), etc. As an example, in the vehicle access information, the vehicle owner 110 may indicate to the server 104 that only users that are pre-registered on the server 104 or entities belonging to a rescue operation (or police, fire station, etc.) may be allowed to access the vehicle 102 during an emergency situation. The vehicle owner 110 may also indicate in the vehicle access information that the user may only be able to seek shelter in the vehicle 102 but may not be able to drive it, or that the user may be able to drive the vehicle 102 only 10 miles or at most to the nearest police station or hospital, or that the vehicle 102 may be driven autonomously based solely on input / command signals transmitted from the server 104, or that the user may be able to access the vehicle's heating, ventilation and air conditioning (HVAC) system but may not be able to start the vehicle's ignition or the vehicle's steering wheel (and therefore may not be able to drive the vehicle 102), etc. In some aspects, the vehicle owner 110 may also provide the above-described vehicle access information to the vehicle 102 via the owner device 112 or the vehicle's infotainment system for use in the vehicle memory (in Figure 2 Shown as a local storage destination in memory 246).

[0022] In response to receiving a vehicle access request from a user device 108, the server 104 may correlate information associated with the user 106 that may be pre-stored in the server 104 or user credential information received as part of the vehicle access request with the vehicle access information provided by the vehicle owner 110. The server 104 may determine that the user 106 may be "allowed" to access the vehicle 102 during the emergency situation based on the correlation. In response to such a determination, the server 104 may transmit access instructions and / or vehicle access information to the vehicle 102. If the vehicle access information may be pre-stored in the vehicle memory, the server 104 may not transmit the vehicle access information to the vehicle 102. In some aspects, the access instructions may include at least one of a vehicle authorization code / token and instructions for outputting a notification from the vehicle 102. In addition, the server 104 may transmit the vehicle access code / token (which may be the same as the vehicle authorization code / token) to the user device 108.

[0023] In response to receiving the access instruction from the server 104, the vehicle 102 can determine that an emergency situation may have occurred and can output a notification via, for example, vehicle exterior lights, a vehicle speaker system, an infotainment system, etc. As an example, in response to receiving the access instruction from the server 104, the vehicle 102 can flash the vehicle exterior lights or output an audible notification via the vehicle speaker system. The notification output from the vehicle 102 can enable the user 106 to locate (e.g., see) a vehicle 102 that the user 106 can seek shelter or drive during the emergency situation. The user 106 can see the flashing vehicle exterior lights and / or hear the audible notification and move toward the vehicle 102.

[0024] Although the above description describes aspects in which the vehicle 102 outputs a notification to enable the user 106 to locate the vehicle 102, the present disclosure is not limited to this manner of notifying the user 106. In some aspects, the server 104 may transmit the geographic location of the vehicle 102 and turn-by-turn navigation instructions to a PaaK app installed on the user device 108. The user 106 may view the vehicle geographic location and follow the turn-by-turn navigation instructions on the PaaK app to locate and reach the vehicle 102.

[0025] Furthermore, in response to receiving the access command, the vehicle 102 may receive a vehicle access code / token from the user device 108 when the user 106 arrives in the vicinity of the vehicle 102. Although the above description describes aspects in which the vehicle 102 outputs a notification when the vehicle 102 receives the access command, in additional or alternative aspects, the vehicle 102 may output a notification (indicating to the user 106 that the user 106 has arrived at the correct vehicle) when the vehicle 102 receives the vehicle access code from the user device 108.

[0026] In response to receiving the vehicle access code, the vehicle 102 may compare the vehicle access code to a vehicle authorization code that the vehicle 102 may have received from the server 104. When the vehicle access code matches the vehicle authorization code, the vehicle 102 may authenticate the user 106. In additional aspects, the vehicle 102 may authenticate the user 106 by one or more additional or alternative means including, but not limited to, facial recognition, quick response (QR) code scanning, and the like.

[0027] In response to authenticating the user 106, the vehicle 102 may provide the user 106 with access to one or more vehicle components based on the vehicle access information. For example, when the vehicle access information does not enable the user 106 to drive the vehicle 102, the vehicle 102 may enable the user 106 to simply open the door and seek shelter in the vehicle 102. As another example, when the vehicle access information enables the user 106 to drive a predefined distance, the vehicle 102 may enable the user 106 to drive the vehicle 102 a predefined distance. As yet another example, if the vehicle access information indicates that the vehicle 102 may be autonomously driven based on a command signal obtained from the server 104 when the user 106 may be inside the vehicle 102, the vehicle 102 may achieve autonomous vehicle movement. In this case, in response to detecting that the user 106 may have entered the vehicle 102 (e.g., based on input obtained from a vehicle interior camera or sensor), the vehicle 102 may transmit a request to the server 104 to obtain a destination location where the vehicle 102 may need to be autonomously driven. In response to receiving a request from the vehicle 102, the server 104 may transmit a command signal including a destination location (which may be pre-stored in the server 104 or provided by the vehicle owner 110 via the owner device 112) to the vehicle 102. The destination location may be, for example, the nearest police station or hospital, a rescue camp, etc. In response to receiving a command signal including the destination location from the server 104, the vehicle 102 may autonomously move from its current (or source) location to the destination location. In some aspects, the vehicle 102 itself (or via the server 104) may determine a designated route to the destination location. The designated route may be determined based on a plurality of parameters, including but not limited to user input, cloud input, vehicle-based analysis of emergency situation patterns (e.g., predicted rain / wind speeds and known flood patterns) when cloud input is not available, etc. In some aspects, the designated route may prevent the vehicle from traveling through a known impassable area.

[0028] In this manner, the vehicle 102 may enable the user 106 to seek shelter and / or move to a location when the user 106 may be in an emergency situation.

[0029] While the above description describes aspects in which a user 106 transmits a vehicle access request to a server 104 via a user device 108 to identify a vehicle 102 in which the user 106 may seek shelter, the present disclosure is not limited to such applications. In some aspects, when an emergency situation such as the one described above may exist, the vehicle owner 110 may transmit a vehicle movement request to the server 104 via the owner device 112. In this case, in response to receiving the vehicle movement request from the owner device 112, the server 104 may transmit a command signal to the vehicle 102 to autonomously move the vehicle 102 away from the geographic area experiencing the emergency situation. In this manner, the server 104 may protect the vehicle 102 from adverse situations during times of emergency, disaster, calamity, etc. In aspects in which the vehicle 102 may not be an autonomous vehicle, the server 104 may identify one or more users (e.g., the user 106) who may be near the vehicle 102 and who may have pre-registered on the server 104 to move the vehicle 102. In this case, in response to identifying the user 106, the server 104 can transmit a request and a corresponding vehicle access code to the user device 108, requesting that the user 106 access the vehicle 102 and drive the vehicle 102 to a safe location. In other aspects, instead of or in addition to identifying one or more users who may move the vehicle 102, the server 104 can identify one or more rescue entities or vehicles (e.g., towing vehicles) that can tow the vehicle 102 to a certain location.

[0030] In further aspects, instead of or in addition to the vehicle owner 110 transmitting the vehicle movement request, authorities and / or rescue teams may also transmit a vehicle movement request to move the vehicle 102. For example, when a fire truck may be needed to reach a house experiencing an emergency situation and the fire station operator determines that the vehicle 102 may be located in front of or near the house (thus blocking the fire truck from entering the house, or on the road leading to the house), the fire station operator may transmit the vehicle movement request to the server 104 via the operator device. Also in this case, in response to receiving the vehicle movement request, the server 104 may cause the vehicle to move, either via the user 106 or autonomously, so that the fire truck can conveniently reach the house. In some aspects, when the fire truck leaves the house, the server 104 may cause the vehicle 102 to return to its original parking location.

[0031] Furthermore, although the above description describes the aspect that the user device 108 transmits the vehicle access request to the server 104, and the server 104 Figure 1102 is depicted as a separate unit, but the present disclosure is not limited to this aspect. In some aspects, the server 104 can be part of the vehicle 102 (or any other vehicle) and hosted in the vehicle memory. When the server 104 can be part of the vehicle 102 (or any other vehicle), when the connection with the "central" server may be lost due to an emergency situation, the user device 108 can still access the server 104 (e.g., via an app that pre-stores the user credentials). In this case, the vehicle 102 itself can authenticate the user device 108 because the server 104 can be hosted in the vehicle 102. In addition, in this case, the server 104 can also cache the user credentials in anticipation of a loss of connection. As an example, once the emergency situation is known, the server 104 can cache the credentials of only available users within a limited distance of the vehicle 102. Similarly, the server 104 / vehicle 102 can provide a vehicle access code to an app executed on the user device 108 to enable the user 106 to obtain access to the vehicle 102.

[0032] Combine the following Figure 2 Further details associated with the vehicle 102 , the server 104 , and a process for facilitating a user to requisition the vehicle 102 during an emergency situation are described.

[0033] The vehicle 102, server 104, user 106, and vehicle owner 110 implement and / or perform operations as described herein in the present disclosure in accordance with the owner's manual and safety guidelines. In addition, any actions taken by the user 106 and / or vehicle owner 110 based on recommendations or notifications provided by the vehicle 102 and / or server 104 should comply with all rules specific to the location (e.g., federal, state, country, city, etc.) and operation of the vehicle 102. Recommendations or notifications as provided by the vehicle 102 and / or server 104 should be considered suggestions and followed only in accordance with any rules specific to the location and operation of the vehicle 102.

[0034] Figure 2 A block diagram of an example system 200 for enabling vehicle requisitioning according to the present disclosure is depicted. Figure 2 When Figure 3 , Figure 4A and Figure 4B .

[0035] The system 200 may include a vehicle 102, a server 104, a user device 108, and an owner device 112 that are communicatively coupled to each other via one or more networks 202. In an exemplary aspect, the server 104 (or system 104) may include a server transceiver 204, a server processor 206, and a server memory 208. The server transceiver 204 may be configured to receive / transmit information, data, signals, etc. from / to one or more devices or systems, including but not limited to multiple vehicles (including the vehicle 102), user devices 108, owner devices 112, one or more additional servers (not shown), etc. The server memory 208 may be configured to store information, data, signals, etc. received from the server transceiver 204. In addition, the server processor 206 may utilize the server memory 208 to store programs and / or store data in code form to perform operations in accordance with the present disclosure. The server memory 208 may be a non-transitory computer-readable storage medium or memory that stores program code or instructions that, when executed, enable the server processor 206 to perform operations in accordance with the present disclosure. The server memory 208 may include any one or combination of volatile memory elements (e.g., dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), etc.), and may include any one or more non-volatile memory elements (e.g., erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), etc.). Figure 1 The operation / functionality of the server 104 is briefly described and will be described in detail in the description below.

[0036] Although Figure 2 A single vehicle 102 and two user devices (user device 108 and owner device 112 ) communicatively coupled to the server 104 are depicted, but the server 104 may be communicatively coupled to multiple vehicles and multiple user devices simultaneously.

[0037] The network 202 illustrates an example communication infrastructure in which the connected devices discussed in various embodiments of the present disclosure may communicate. The network 202 may be and / or include the Internet, a private network, a public network, or other configurations operating using any one or more known communication protocols, such as, for example, Transmission Control Protocol / Internet Protocol (TCP / IP), BLE, Wi-Fi based on the Institute of Electrical and Electronics Engineers (IEEE) standard 802.11, ultra-wideband (UWB), and cellular technologies such as time division multiple access (TDMA), code division multiple access (CDMA), high-speed packet access (HSPDA), long-term evolution (LTE), global system for mobile communications (GSM), and fifth generation (5G), to name a few examples.

[0038] The vehicle 102 may include a plurality of units including, but not limited to, a vehicle computer 210, a vehicle control unit (VCU) 212, and a commandeering system 214 (or system 214). The VCU 212 may include a plurality of electronic control units (ECUs) 216 arranged to communicate with the vehicle computer 210.

[0039] In some aspects, the user device 108 and the owner device 112 may be connected to the vehicle computer 210 and / or the system 214 via the network 202, which may communicate via one or more wireless connections and / or may communicate using a near field communication (NFC) protocol, Protocol, Wi-Fi, ultra-wideband (UWB), and other possible data connection and sharing technologies to connect directly with the vehicle 102. As described above, each of the user device 108 and the owner device 112 can be installed with a PaaK app that can enable the corresponding device to access the vehicle 102.

[0040] According to the present disclosure, the vehicle computer 210 and / or the system 214 may be installed anywhere in the vehicle 102. In addition, the vehicle computer 210 may operate as a functional part of the system 214. The vehicle computer 210 may be or include an electronic vehicle controller having one or more processors 218 and a memory 220. In addition, the system 214 may be separate from the vehicle computer 210 (e.g., Figure 2 ), or may be integrally formed as part of the vehicle computer 210.

[0041] The processor 218 may be configured to communicate with one or more memory devices (eg, memory 220 and / or memory 220) configured to communicate with a corresponding computing system. Figure 2The processor 218 may utilize the memory 220 to store programs and / or store data in code for performing operations according to the present disclosure. The memory 220 may be a non-transitory computer-readable storage medium or memory that stores vehicle requisition program code. The memory 220 may include any one or combination of volatile memory elements (e.g., dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), etc.), and may include any one or more non-volatile memory elements (e.g., erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), etc.).

[0042] According to some aspects, the VCU 212 can share a power bus with the vehicle computer 210 and can be configured and / or programmed to communicate between vehicle systems, connected servers (e.g., server 104), and other vehicles operating as part of a vehicle fleet (e.g., Figure 2 The VCU 212 may include or communicate with any combination of ECUs 216, such as a body control module (BCM) 222, an engine control module (ECM) 224, a transmission control module (TCM) 226, a telematics control unit (TCU) 228, a driver assistance technology (DAT) controller 230, etc. The VCU 212 may also include and / or communicate with a vehicle perception system (VPS) 232, which can connect and / or control one or more vehicle sensing systems 234. The vehicle sensing system 234 may include one or more vehicle sensors, including but not limited to radio detection and ranging (lidar or "radar") sensors configured to detect and locate objects inside and outside the vehicle 102 using radio waves, seating area lock sensors, seating area sensors, light detection and ranging ("lidar") sensors, door sensors, proximity sensors, temperature sensors, wheel sensors, one or more ambient weather or temperature sensors, vehicle interior and exterior cameras, steering wheel sensors, etc.

[0043] In some aspects, VCU 212 may control aspects of vehicle operation and implement one or more instruction sets received from server 104 , from one or more instruction sets stored in memory 220 , including instructions to operate as part of system 214 .

[0044] The TCU 228 may be configured and / or programmed to provide vehicle connectivity to wireless computing systems on and off the vehicle 102 and may include a navigation (NAV) receiver 236 for receiving and processing GPS signals, module (BLEM) 238, a Wi-Fi transceiver, a UWB transceiver, and / or may be configured to communicate between the vehicle 102 and other systems (e.g., a vehicle key fob ( Figure 2 ), server 104, user device 108, owner device 112, etc.), other wireless transceivers (not shown) for wireless communication (including cellular communication) between computers and modules Figure 2 2). The TCU 228 may be arranged to communicate with the ECU 216 via a bus. In some aspects, the TCU 228 may be configured to determine a real-time vehicle geographic location, for example, via a NAV receiver 236.

[0045] ECU 216 may control various aspects of vehicle operation and communications using input from a human driver, input from vehicle computer 210 , system 214 , and / or via wireless signal input received from other connected devices (server 104 , etc.) over a wireless connection.

[0046] The BCM 222 typically includes an integration of sensors, vehicle performance indicators, and varactors associated with vehicle systems, and may include processor-based power distribution circuits that control functions associated with the vehicle body, such as lights, windows, security devices, cameras, audio systems, speakers, wipers, door locks and access controls, and various comfort controls. The BCM 222 may also operate as a gateway for bus and network interfaces to communicate with remote ECUs ( Figure 2 (not shown) interaction.

[0047] The DAT controller 230 may provide Level 1 to Level 3 automated driving and driver assistance functions, which may include, for example, active park assist, vehicle back-up assist, adaptive cruise control, and / or lane keeping, among other features. The DAT controller 230 may also provide various aspects of user and environmental input that may be used for user authentication.

[0048] In some aspects, the vehicle computer 210 may be connected to an infotainment system 240 (or vehicle human-machine interface (HMI)). The infotainment system 240 may include a touch screen interface portion, and may include a voice recognition feature, a biometric recognition capability that may recognize a user based on facial recognition, voice recognition, fingerprint recognition, or other biometric recognition means. In other aspects, the infotainment system 240 may also be configured to receive user commands via the touch screen interface portion, and / or output or display notifications, navigation maps, real-time user geographic location, etc. on the touch screen interface portion.

[0049] The computing system architecture of the vehicle computer 210, VCU 212 and / or system 214 may omit certain computing modules. It should be readily understood that Figure 2The computing environment depicted in FIG. 1 is an example of possible implementations according to the present disclosure and, therefore, should not be considered limiting or exclusive.

[0050] According to some aspects, the system 214 can be formed integrally with and / or executed as part of the ECU 216. The system 214, whether formed integrally with the vehicle computer 210 or the ECU 216, or whether operating as a standalone computing system in the vehicle 102, can include a transceiver 242, a processor 244, and a computer readable memory 246.

[0051] The transceiver 242 may be configured to receive information / input from one or more external devices or systems (e.g., user device 108, owner device 112, server 104, etc.) via the network 202. In addition, the transceiver 242 may transmit notifications, requests, signals, etc. to the external devices or systems. In addition, the transceiver 242 may be configured to receive information / input from vehicle components (such as, vehicle sensing system 234, one or more ECUs 216, etc.). In addition, the transceiver 242 may transmit signals (e.g., command signals) or notifications to vehicle components, such as BCM 222, infotainment system 240, etc.

[0052] The processor 244 and the memory 246 may be the same or similar to the processor 218 and the memory 220, respectively. In some aspects, the processor 244 may utilize the memory 246 to store programs and / or store data in code form to perform operations in accordance with the present disclosure. The memory 246 may be a non-transitory computer-readable storage medium or memory that stores vehicle requisition program code. In some aspects, the memory 246 may additionally store instructions / information / data obtained from the server 104, the user device 108, the owner device 112, etc.

[0053] In operation, when an emergency situation may exist (e.g., a natural disaster or a man-made disaster as described above), the server 104 may receive a message from one or more additional servers ( Figure 2 The server transceiver 204 may receive an alert notification associated with a geographic area experiencing an emergency situation (not shown). The additional server may be associated with one or more authorities that may transmit an alert notification, such as via an emergency alert system (EAS), when an emergency situation may exist. In response to receiving the alert notification, the server transceiver 204 may transmit the alert notification to the server memory 208 for storage purposes and to the server processor 206. When the server processor 206 obtains the alert notification, the server processor 206 may determine that an emergency situation may exist in the geographic area.

[0054] The server transceiver 204 may also receive a vehicle access request from a user device 108 associated with a user 106 that may be located in a geographic area experiencing an emergency situation. When the user 106 desires the server 104 to identify one or more vehicles for the user 106 in which the user 106 may seek shelter and / or drive to a certain location, the user 106 may transmit the vehicle access request to the server 104 via the user device 108. In response to receiving the vehicle access request, the server transceiver 204 may transmit the vehicle access request to the server processor 206.

[0055] In addition, as above combined Figure 1 As described, the server 104 may store (e.g., in the server memory 208) vehicle access information associated with a plurality of vehicles that may be located in a geographic area experiencing an emergency situation. For example, the server memory 208 may pre-store vehicle access information associated with a plurality of vehicles 102, 302a, 302b, 302c, 302d, 302n that may be located in a geographic area experiencing an emergency situation, such as Figure 3 As shown in . The vehicle access information can be transmitted to the server 104 (specifically, the server transceiver 204) by the owners of the plurality of vehicles 102, 302a to 302n using the corresponding user devices. Figure 1 As described, the vehicle access information may include: an indication or confirmation (or absence of confirmation) of the vehicle owner's consent to use / moving the vehicle during the emergency situation; a profile of users or entities that may be allowed to access the vehicle during the emergency situation; a level of vehicle access that may be provided; a predefined distance that the vehicle may be allowed to move during the emergency situation, etc. In some aspects, the vehicle access information may include vehicle availability information associated with the plurality of vehicles 102, 302a to 302n, or may provide an indication of whether one or more of the plurality of vehicles 102, 302a to 302n may be "available" for access by the user 106 during an emergency, disaster, calamity, etc.

[0056] In some aspects, in response to obtaining the alert notification from the authority and obtaining the vehicle access request from the user device 108, the server processor 206 may retrieve or obtain vehicle access information associated with the plurality of vehicles 102, 302a-302n from the server memory 208. In response to obtaining the vehicle access information, the server processor 206 may correlate user information or user credential information (which may be part of the vehicle access request or pre-stored in the server memory 208) with the vehicle access information to identify one or more vehicles (e.g., vehicles 102, 302a and 302d) of the plurality of vehicles 102, 302a-302n that are accessible to the user 106 in the geographic area experiencing the emergency situation.

[0057] In response to identifying the vehicles 102, 302a, and 302d, the server processor 206 may transmit access instructions and / or corresponding vehicle access information to the vehicles 102, 302a, and 302d via the server transceiver 204, and transmit a vehicle access code to the user device 108. In some aspects, the access instructions may include instructions for causing the vehicles 102, 302a, and 302d to output audible and / or visual notifications via, for example, corresponding vehicle exterior lights, vehicle audio systems or speakers, vehicle infotainment systems, etc. In response to receiving the access instructions from the server 104, the vehicles 102, 302a, and 302d may output audible and / or visual notifications. For example, Figure 3 As shown in FIG, vehicles 102, 302a, and 302d may flash corresponding vehicle exterior lights in response to receiving an access instruction from server 104. The flashing vehicle exterior lights may provide a visual indication to user 106 regarding vehicles that may be accessible to user 106. In some aspects, by viewing the flashing vehicle exterior lights, user 106 may move toward one of the vehicles (e.g., vehicle 102) that user 106 may desire to access.

[0058] Although the above description describes aspects in which the vehicles 102, 302a, and 302d output notifications (e.g., flashing corresponding exterior lights) to indicate to the user 106 that the vehicles may be accessible, the present disclosure is not limited to such aspects. In some aspects, the server processor 206 can transmit the geographic locations of the vehicles 102, 302a, and 302d (which the server 104 can obtain from the corresponding vehicles) to the user device 108 via the server transceiver 204. In response to receiving the geographic locations of the vehicles 102, 302a, and 302d, the user device 108 can display the geographic locations of the vehicles, for example, on a PaaK app installed on the user device 108, such as Figure 3 As shown in view 304 of FIG. Figure 3 In the exemplary aspect depicted in FIG, the vehicle geographic location is displayed as a location icon. User 106 can view the vehicle geographic location and can select one of the vehicles (e.g., vehicle 102) that user 106 may desire to visit, for example, by clicking on the corresponding location icon of vehicle 102 on the PaaK app. In response to user 106 clicking on the location icon associated with vehicle 102, server processor 206 can transmit turn-by-turn navigation instructions to user device 108 via server transceiver 204, thereby assisting user 106 in moving from the user device's current location to the geographic location associated with vehicle 102.

[0059] In another aspect, the respective license plates of the vehicles 102, 302a, and 302d may include an indication (e.g., a license plate indicating that the vehicles 102, 302a, and 302d are available for access during an emergency, disaster, calamity, etc.) Figure 3306 of FIG. 10 ). For example, as shown in view 306 , the license plate may include text such as “Available in an emergency,” “This vehicle may be requisitioned in an emergency,” and / or any other type of indicator light text, which may facilitate user 106 identifying vehicles 102 , 302 a , and 302 d that may be used for access during an emergency, disaster, calamity, etc. In yet another aspect, server 104 may transmit a command signal to a drone (not shown) that may be located in a geographic area experiencing an emergency situation. The drone may hover above vehicles 102 , 302 a , and 302 d in response to obtaining the command signal from server 104 , thereby providing user 106 with an indication that vehicles 102 , 302 a , and 302 d are available for access. When user 106 selects a vehicle to access (e.g., vehicle 102 ), user 106 may move toward vehicle 102 .

[0060] In some aspects, the access instructions transmitted by the server processor 206 to the vehicles 102, 302a, and 302d may also include a vehicle authorization code, which may enable the vehicles 102, 302a, and 302d to provide access rights to the user 106 (specifically, the user device 108) when the user 106 moves toward the corresponding vehicle. In other aspects, the vehicle authorization code may be pre-stored in the corresponding vehicle memory (e.g., the memory 246 or the memory 220).

[0061] In some aspects, when the user 106 moves toward the vehicle 102, the user device 108 may transmit a vehicle access code (the vehicle access code obtained by the user device 108 from the server 104, as described above) to the transceiver 242. When the user device 108 may be disposed within a predefined distance range of the vehicle 102, the transceiver 242 may receive the vehicle access code from the user device 108. In response to receiving the vehicle access code, the transceiver 242 may transmit the vehicle access code to the processor 244. In addition, the transceiver 242 may transmit access instructions (obtained by the transceiver 242 from the server 104, as described above) to the processor 244. The access instructions may provide an instruction to the processor 244 to provide vehicle access rights to a user device (e.g., the user device 108) that may be associated with a third party / user (e.g., the user 106) that may not be associated with the vehicle 102.

[0062] In response to obtaining the vehicle access code and access instructions from the transceiver 242, the processor 244 can output (e.g., by sending a command signal to the BCM 222) an audible and / or visual notification via vehicle exterior lights, a vehicle speaker system, the infotainment system 240, etc., as described above. In addition, in response to obtaining the vehicle access code and access instructions, the processor 244 can authenticate the user 106 based on the vehicle access code and the access instructions. In some aspects, to authenticate the user 106, the processor 244 can compare the vehicle access code to a vehicle authorization code (which the processor 244 can obtain from the server 104 or can be pre-stored in the memory 246). Based on the comparison, the processor 244 can determine that the user 106 is authenticated when the vehicle access code matches the vehicle authorization code.

[0063] In some aspects, the processor 244 may additionally or alternatively authenticate the user 106 based on facial recognition, or may request the user 106 to enter a vehicle access password (which may be provided by the server 104 and may be the same as or different from the vehicle access code) at an input interface disposed at an exterior portion of the vehicle to authenticate the user 106, or may request the user 106 to scan a 3-dimensional (3D) barcode or a quick response (QR) code disposed at an exterior portion of the vehicle to authenticate the user 106. To authenticate the user 106 based on facial recognition, the transceiver 242 may receive a user facial image (e.g., via the user device 108 or a vehicle exterior camera), and may transmit the user facial image to the processor 244. The processor 244 may also obtain a plurality of facial images associated with a plurality of users who may be allowed to access the vehicle 102 from the server 104 or one or more other servers (not shown). In response to obtaining the plurality of facial images, the processor 244 may compare the user facial image with the plurality of facial images. The processor 244 may authenticate the user 106 based on the comparison. Specifically, processor 244 may authenticate user 106 when the user's facial image matches at least one facial image of the plurality of facial images.

[0064] In response to authenticating the user 106, the processor 244 may obtain vehicle access information from the server 104 or the memory 246 (in which case the vehicle access information may be provided to the vehicle 102 by the vehicle owner 110 via the owner device 112 or the infotainment system 240), as described above. The vehicle access information may include information associated with a vehicle access level to be provided to the user 106. Based on the vehicle access level, the processor 244 may determine one or more vehicle components that may be enabled for the user 106. The vehicle components may be, for example, vehicle doors, a heating, ventilation and air conditioning (HVAC) system, a vehicle ignition, a vehicle steering wheel, vehicle windows, an infotainment system 240, vehicle interior and exterior lights, and the like. As an example, when the vehicle access level indicates that the user 106 may only seek shelter in the vehicle 102 but may not drive, the processor 244 may determine the vehicle doors and / or the HVAC system as vehicle components that the user 106 may access. As another example, when the vehicle access level indicates that the user 106 can drive the vehicle 102 for 10 miles, the processor 244 can determine the vehicle doors, vehicle ignition, and other additional vehicle components as vehicle components that the user 106 can access (until the vehicle 102 is driven 10 miles). In response to determining the vehicle components that the user 106 can access, the processor 244 can enable activation of the corresponding vehicle components for the user 106. For example, in response to determining the vehicle components that the user 106 can access, the processor 244 can unlock the vehicle doors for the user 106, enable the vehicle ignition and vehicle steering wheel activation for the user 106, etc. In some aspects, when the vehicle ignition and vehicle steering wheel can be activated / enabled, the user 106 may be able to drive the vehicle 102.

[0065] Although the above description describes aspects in which the user 106 accesses the vehicle 102 via the user device 108, the present disclosure is not limited to such vehicle access aspects. In alternative aspects, the user 106 may "pass" or "transfer" vehicle access to any other third-party user (or towing vehicle). In such a case, the third-party user may be required to provide the third-party user credential information to the server 104 (e.g., via the user device 108) before the third-party user may be allowed access to the vehicle 102.

[0066] In other aspects, instead of or in addition to the user 106 accessing and driving the vehicle 102, the server 104 and / or the owner device 112 can transmit an autonomous vehicle movement request to the transceiver 242. For example, when the vehicle owner 110 may desire to move the vehicle 102 away from a geographic area experiencing an emergency situation, the vehicle owner 110 can transmit an autonomous vehicle movement request to the transceiver 242 via the owner device 112. The transceiver 242 can transmit the autonomous vehicle movement request to the processor 244.

[0067] In response to obtaining the autonomous vehicle movement request, processor 244 may transmit a command signal to VCU 212 to cause autonomous vehicle movement from the vehicle's current location (e.g., a "source location") to a destination location. In some aspects, the autonomous vehicle movement request may include information associated with the destination location or a predefined distance and direction that vehicle 102 may traverse. In response to receiving the command signal from processor 244, VCU 212 may cause vehicle 102 to move from the source location to the destination location (which may be away from a geographic area experiencing the emergency situation), thereby protecting vehicle 102 from the adverse situation.

[0068] In additional aspects, one or more rescue teams or authorities may also transmit an autonomous vehicle movement request to the vehicle 102 (via the server 104 or directly) when the rescue team or authorities desire the vehicle 102 to move. Figure 4A and Figure 4B An example scenario in which a rescue team causes an autonomous vehicle to move is shown in FIG.

[0069] exist Figure 4A and Figure 4B In the exemplary aspect depicted in FIG. 4 , a fire truck 402 may be required to reach a house 404 that may be experiencing an emergency situation (e.g., a fire). Figure 4A As shown in FIG. 1 , one or more vehicles 406 a, 406 b, 406 c (collectively referred to as vehicles 406, which may be the same as vehicle 102) may be located near house 404, such that the movement of the fire truck near house 404 or on a road leading to house 404 may be interfered with or restricted due to the presence of vehicles 406. In response to detecting such a scenario, the fire truck operator (or operator user device) or the fire station may transmit an autonomous vehicle movement request to vehicle 406 directly or via server 104.

[0070] In this case, in response to receiving an autonomous vehicle movement request, vehicle 406 may autonomously move away from house 404, such as Figure 4B , thereby enabling fire truck 402 to conveniently reach house 404. In a further aspect, when fire truck 402 leaves house 404, vehicles 406 may return to their original parking positions near house 404 (e.g., based on autonomous vehicle movement command signals obtained from server 104). In a scenario where one or more of vehicles 406 may not be autonomous, server 104 may identify one or more users (e.g., user 106) that may be located near house 404 and request user 106 to move vehicle 406. In this case, server 104 may transmit a vehicle requisition request along with a corresponding vehicle access code to user device 108 to enable user 106 to move vehicle 406 away from house 404.

[0071] Figure 5 A flow chart of an example method 500 for enabling vehicle requisitioning according to the present disclosure is depicted. Figure 5 The following process is exemplary and is not limited to the steps described below. Furthermore, alternative embodiments may include more or fewer steps than shown or described herein, and may include the steps in an order different from the order described in the example embodiments below.

[0072] The method 500 begins at step 502. At step 504, the method 500 may include obtaining, by the processor 244, from the server 104 an access instruction to provide access rights to a user device 108 associated with a user 106 not associated with the vehicle 102, and obtaining a vehicle access code from the user device 108. At step 506, the method 500 may include authenticating, by the processor 244, the user 106 based on the access instruction and the vehicle access code, as described above. The user 106 may additionally be authenticated based on facial recognition, scanning of a 3D barcode, a QR code, etc.

[0073] At step 508, method 500 may include obtaining, by processor 244, vehicle access level information from server 104 or memory 246 in response to authenticating user 106. At step 510, method 500 may include enabling, by processor 244, activation of one or more vehicle components based on the vehicle access level information in response to authenticating user 106.

[0074] Method 500 may end at step 512 .

[0075] In the above disclosure, reference has been made to the accompanying drawings that form a part of the above disclosure, which illustrate specific implementations in which the present disclosure can be practiced. It should be understood that other implementations can be utilized and structural changes can be made without departing from the scope of the present disclosure. References to "one embodiment", "embodiment", "exemplary embodiment" and the like in this specification indicate that the described embodiment may include specific features, structures or characteristics, but each embodiment may not necessarily include the specific features, structures or characteristics. In addition, such phrases do not necessarily refer to the same embodiment. In addition, when features, structures or characteristics are described in conjunction with an embodiment, whether or not explicitly described, those skilled in the art will recognize such features, structures or characteristics in conjunction with other embodiments.

[0076] In addition, where appropriate, the functions described herein may be performed in one or more of the following: hardware, software, firmware, digital components, or analog components. For example, one or more application specific integrated circuits (ASICs) may be programmed to perform one or more of the systems and programs described herein. Certain terms are used throughout the specification and claims to refer to specific system components. As will be appreciated by those skilled in the art, components may be referred to by different names. This document is not intended to distinguish between components that have different names but the same function.

[0077] It should also be understood that the word "example" as used herein is intended to be non-exclusive and non-limiting in nature. More specifically, the word "example" as used herein indicates one of several examples, and it should be understood that no undue emphasis or preference is placed on the specific example described.

[0078] Computer-readable media (also referred to as processor-readable media) include any non-transitory (e.g., tangible) media that participate in providing data (e.g., instructions) that can be read by a computer (e.g., by a processor of a computer). Such media may take many forms, including, but not limited to, non-volatile media and volatile media. A computing device may include computer-executable instructions, where the instructions may be executable by one or more computing devices (such as those listed above) and stored on a computer-readable medium.

[0079] With respect to the processes, systems, methods, heuristics, etc. described herein, it should be understood that although the steps of such processes, etc. have been described as occurring according to a certain ordered sequence, such processes may be practiced by performing the described steps in an order different from the order described herein. It should also be understood that certain steps may be performed simultaneously, other steps may be added, or certain steps described herein may be omitted. In other words, the descriptions of the processes herein are provided for the purpose of illustrating various embodiments and should in no way be construed as limiting the claims.

[0080] Therefore, it should be understood that the above description is intended to be illustrative rather than restrictive. Upon reading the above description, many embodiments and applications other than the examples provided will be apparent. The scope should not be determined with reference to the above description, but should be determined with reference to the entire scope of the appended claims and equivalents to which such claims are entitled. It is anticipated and expected that the technology discussed herein will develop in the future, and the disclosed systems and methods will be incorporated into such future embodiments. In short, it should be understood that the present application is capable of modification and change.

[0081] Unless explicitly indicated to the contrary in this article, all terms used in the claims are intended to be given their ordinary meanings as understood by the skilled person described herein. Specifically, unless the claims state an explicit limitation to the contrary, the use of singular articles such as "one", "the", "said" and the like should be interpreted as describing one or more of the indicated elements. Unless otherwise specifically stated or understood in other ways within the context when used, conditional language such as, in particular, "can", "may", "can" or "may" is generally intended to express that certain embodiments may include certain features, elements and / or steps, while other embodiments may not include certain features, elements and / or steps. Therefore, such conditional language is generally not intended to imply that one or more embodiments require each feature, element and / or step in any way.

[0082] According to an embodiment, the access instructions include instructions for outputting a notification from the vehicle.

[0083] According to an embodiment, the system processor is further configured to transmit the geographic location of the vehicle to the user device.

[0084] According to the present invention, a method for achieving access to a vehicle includes: a processor obtaining an access instruction from a server to provide access rights to a user device of a user who is not associated with the vehicle; the processor authenticating the user based on the access instruction; the processor obtaining vehicle access level information from a vehicle memory in response to authenticating the user, wherein the vehicle access level information includes a level of vehicle access rights to be provided to the user; and the processor enabling the start-up of vehicle components based on the vehicle access level information in response to authenticating the user.

[0085] In one aspect of the invention, the method includes: determining the vehicle component based on the vehicle access level; and enabling activation of the vehicle component in response to determining the vehicle component.

[0086] In one aspect of the invention, the vehicle component is at least one of: a vehicle door, a heating, ventilation and air conditioning (HVAC) system, a vehicle ignition, a vehicle steering wheel, a vehicle window, an infotainment system, or vehicle interior and exterior lights.

Claims

1. A vehicle comprising: a transceiver configured to receive an access instruction from a server to provide access rights to a user device of a user not associated with the vehicle; a memory configured to store vehicle access level information, wherein the vehicle access level information includes a vehicle access level to be provided to the user; as well as a processor communicatively coupled to the transceiver and the memory, wherein the processor is configured to: obtaining the access instruction; authenticating the user based on the access instruction; obtaining the vehicle access level information in response to authenticating the user; and Activation of a vehicle component is enabled based on the vehicle access level information. 2 . The vehicle of claim 1 , wherein the transceiver is further configured to receive a vehicle access code from the user device, and wherein the processor is further configured to authenticate the user based on the vehicle access code.

3. The vehicle of claim 1, wherein the processor is further configured to: determining the vehicle component based on the vehicle access level; and Activation of the vehicle component is enabled in response to determining the vehicle component.

4. The vehicle of claim 2, wherein the access instruction includes a vehicle authorization code.

5. The vehicle of claim 4, wherein the processor is further configured to: comparing the vehicle authorization code to the vehicle access code; and Based on the comparison, it is determined that the user is authenticated when the vehicle authorization code matches the vehicle access code.

6. The vehicle of claim 1, wherein the transceiver is further configured to receive a facial image of a vehicle user.

7. The vehicle of claim 6, wherein the processor is further configured to: obtaining a plurality of facial images associated with a plurality of users permitted to access the vehicle; comparing the user facial image to the plurality of facial images; and The user is authenticated based on the comparison.

8. The vehicle of claim 1, wherein the vehicle component is at least one of: a vehicle door, a heating, ventilation and air conditioning (HVAC) system, a vehicle ignition, a vehicle steering wheel, a vehicle window, an infotainment system, or vehicle interior and exterior lights.

9. The vehicle of claim 1, wherein the processor is further configured to: Obtaining an autonomous vehicle movement request from the server or a vehicle owner user device; and An autonomous vehicle movement is caused from a source location to a destination location in response to obtaining the autonomous vehicle movement request, wherein the autonomous vehicle movement request includes the destination location.

10. The vehicle of claim 1, wherein the processor is further configured to output a notification in response to obtaining the access instruction.

11. The vehicle of claim 10, wherein the processor outputs the notification via at least one of: vehicle exterior lights, a vehicle speaker system, or an infotainment system.

12. A system comprising: A system transceiver, the system transceiver being configured to: receiving alert notifications associated with a geographic area; and receiving a vehicle access request from a user device associated with a user located in the geographic area; a system memory configured to store information associated with a plurality of vehicles located at the geographic area, wherein the information includes availability information associated with the plurality of vehicles to provide access rights to the user; as well as A system processor, the system processor being configured to: obtaining the alarm notification and the vehicle access request; identifying a vehicle from the plurality of vehicles for the user based on the information in response to obtaining the alert notification and the vehicle access request; and Access instructions are transmitted to the vehicle in response to identifying the vehicle.

13. The system of claim 12, wherein the system processor is further configured to transmit a vehicle access code to the user device in response to identifying the vehicle.

14. The system of claim 12, wherein the alert notification is associated with an emergency situation including a natural disaster or a man-made disaster.

15. The system of claim 12, wherein the access instruction includes a vehicle authorization code.

Images