TECHNICAL FIELD

[0001] The present disclosure generally relates to requesting an emergency response and responding to an emergency request and, more particularly, to a networked community of persons or vehicles capable of having an emergency request placed by a member of the community and responded to by one or more other members of the community.

BACKGROUND

[0002] In general, an emergency request regarding an emergency situation is best addressed when measures are taken in a timely manner such that the emergency request is responded to and addressed by a respondent as quickly as possible. In other words, a short response time to an emergency situation is of utmost importance to resolving the emergency situation successfully. For example, a fire department, a police department, a ranger patrol unit, a health care provider, a roadside assistance agency, a water damage specialist or other emergency services would strive to dispatch personnel, such as a rapid response team (RRT) or emergency response team (ERT) thereof, to arrive at a scene of an emergency in the shortest period of time possible. However, short response time may not be always achievable due to various constrains, such a distance between a location of an emergency service provider and the scene of an emergency, or a physical condition of a distressed person of the emergency. For instance, a car accident may happen during rush hours in a busy street, and it may take a long time for an ambulance to drive through heavy traffic in order to arrive at the scene of the car accident. By the time the ambulance arrives the scene of the accident, a golden time period may have passed for rescuing the life of a seriously injured car passenger. As another example, a car may pull over to a shoulder of a highway at a remote location far from any health care facility, as a driver of the car is experiencing a mini stroke that prevents him or her from calling an emergency service or otherwise indicating a sign for help. No one in the passing traffic would know the driver is in need for medical attention, and the wellness of the driver may deteriorate to an irrevocable condition as the driver remains unattended for a period of time.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Non-limiting and non-exhaustive embodiments of the present disclosure are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various figures unless otherwise specified.

[0004] FIG. 1 is a diagram depicting an example community of vehicles in which embodiments in accordance with the present disclosure may be utilized.

[0005] FIG. 2 is a diagram depicting an example information flow within a community of vehicles in accordance with an embodiment of the present disclosure.

[0006] FIG. 3 is a flowchart depicting an example process in accordance with an embodiment of the present disclosure.

[0007] FIG. 4 is a flowchart depicting another example process in accordance with an embodiment of the present disclosure.

[0008] FIG. 5 is a flowchart depicting yet another example process in accordance with an embodiment of the present disclosure.

[0009] FIGS. 6 - 9 illustrate screenshots of a smartphone app in accordance with an embodiment of the present disclosure. [0010] FIG. 10 is a simplified block diagram depicting an example apparatus in accordance with an embodiment of the present disclosure.

DETAILED DESCRIPTION

[0011] In the following description, reference is made to the accompanying drawings that form a part thereof, and in which is shown by way of illustrating specific exemplary embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the concepts disclosed herein, and it is to be understood that modifications to the various disclosed embodiments may be made, and other embodiments may be utilized, without departing from the scope of the present disclosure. The following detailed description is, therefore, not to be taken in a limiting sense.

[0012] The present disclosure provides a crowd-sourced emergency response system as well as methods thereof. The system and the methods are collectively referred to as a "crowd- sourced emergency response service" herein. The crowd-sourced emergency response service may serve or otherwise benefit an automobile (herein interchangeably referred to as "vehicle") that is involved in a traffic accident (e.g., crashing with another vehicle or object) or in an impairment condition (e.g., having a flat tire, broken windshield, running out of fuel, wheels stuck in mud or snow and the like). Additionally, the crowd-sourced emergency response service may also be applicable to a vehicle occupant (e.g., a driver and/or a passenger) who experiences a medical emergency. In either case, the vehicle in need of emergency assistance (hereinafter "the distressed vehicle") may belong to a community of vehicles, and the crowd-sourced emergency response system may broadcast a request regarding the emergency of the distressed vehicle within the community of vehicles (i.e., the "crowd"). Some vehicles of the community of vehicles may have capable personnel riding therein, such as off-duty or retired doctors, nurses, police officers, emergency medical technicians (EMTs), firefighters and the like (hereinafter referred to as "volunteers"). One or more vehicles with volunteers may happen to be traveling or otherwise located within a closer vicinity of the distressed vehicle than a hospital or an emergency service facility that is located farther away. Upon receiving the request, one or more volunteers may respond to the emergency request and may arrive at the location of the distressed vehicle sooner than a response unit dispatched from the hospital or the emergency service facility that is located farther away. Advantageously, the crowd-sourced emergency response service is able to shorten the response time than what could otherwise be achieved by the hospital or the emergency service facility alone.

[0013] FIG. 1 illustrates an example community 100 of vehicles in which embodiments in accordance with the present disclosure may be utilized. Community 100 may include multiple vehicles such as vehicles 110(1) - 110(N) (with N being a positive integer greater than or equal to 1). Each vehicle of community 100 may be capable of wireless communication to transmit and receive data wirelessly. Any two or more vehicles of community 100 may be directly connected to one another, indirectly via one or more other vehicles in community 100 and/or indirectly via infrastructure for wireless communication. For simplicity, a data communication network (DCN) 180 is shown in FIG. 1 to represent such one or more other vehicles and/or infrastructure for wireless communication. That is, any two or more vehicles of community 100 may wirelessly communicate to one another directly and/or indirectly via DCN 180. DCN 180 may be realized by a cell phone network, a mobile communication network, a satellite network, walkie-talkies, various vehicle-to-vehicle (V2V) communication technologies, Bluetooth connectivity or any suitable technology. [0014] When a vehicle of community 100 is subject to an emergency situation or condition, the vehicle (i.e., the distressed vehicle) may make the condition known to one or more other vehicles of community 100 via DCN 180. For example, vehicle 110(1) may experience a condition of a flat tire on a highway that is in a rural area far away from any roadside service provider, shown as one or more emergency services 190 in FIG. 1. In this example, vehicle 110(1) does not carry tools that are necessary to install a spare tire. Vehicle 110(1) may notify one or more other vehicles of community 100 of the flat-tire condition via DCN 180, such as some of vehicles 110(2) - 110(N). At least one of the one or more other vehicles, such as vehicle 110(2) for example, may be traveling on the same highway, just a few exits away from vehicle 110(1), and equipped with the necessary tools. Vehicle 110(2) may subsequently respond to the flat-tire condition of vehicle 110(1) by informing vehicle 110(1), via DCN 180, about an aid action. The aid action in this example may involve vehicle 110(2) arriving at a current location of vehicle 110(1) with the necessary tools in a short period of time. The aid action provided by vehicle 110(2) may come to vehicle 110(1) faster than an aid action otherwise provided by any of the remote emergency services 190.

[0015] Within community 100, a respective occupant of each vehicle of community 100 may have a role of a user or a volunteer, or both, in terms of emergency response. For example, a respective occupant of each of vehicles 110(1), 110(4) and 110(N) may be a user (but not a volunteer) in community 100, and a respective occupant of vehicle 110(2) may be a volunteer (but not a user) in community 100. Meanwhile, a respective occupant of each of vehicles 110(3) and 110(5) may be both a user and a volunteer in community 100. A vehicle of community 100 having an occupant as a user may make an emergency condition known to any, some or all of the vehicles of community 100 the occupant(s) of which may be volunteer(s). Any, some or all of the vehicles of community 100 having occupants which are volunteers may subsequently respond to the emergency condition and offer an aid action. For example, vehicle 110(1) may make the flat-tire condition known to any, some or all of vehicles 110(2), 110(3) and 110(5), and at least one of vehicles 110(2), 110(3) and 110(5) may respond and offer an aid action to address the flat-tire condition.

[0016] For illustrative purposes and without limiting the scope of the present disclosure, vehicles 110(1), 110(4) and 1 10(N) are labeled with the letter "U" in FIG. 1 to denote that the respective occupant of each of vehicles 110(1), 110(4) and 110(N) is a user of the crowd-sourced emergency response service in accordance with the present disclosure. Similarly, vehicle 110(2) is labeled with the letter "V" in FIG. 1 to denote that the respective occupant of vehicle 110(2) is a volunteer of the crowd-sourced emergency response service. Likewise, vehicles 110(3) and 110(5) are labeled with the letters "U, V" in FIG. 1 to denote that the respective occupant of each of vehicles 110(3) and 110(5) is both a user and a volunteer of the crowd-sourced emergency response service. Moreover, each of vehicles 110(1), 110(4) and 110(N) may be referred to as a "user vehicle" herein, while vehicle 110(2) may be referred to as a "volunteer vehicle" herein. Correspondingly, each of vehicles 110(3) and 110(5) may be referred to as a "user-and-volunteer vehicle" herein.

[0017] In some embodiments, community 100 may further include a data center 170 which may include one or more backend servers 175 through which various techniques and embodiments may be implemented to facilitate a flow of information among vehicles of community 100. The facilitation of information by data center 170 and the one or more backend servers 175 is to be provided in a greater detail in a later part of the present disclosure. Although illustrated as a single data center, data center 170 may be a single data center at a physical location or, alternatively, data center 170 may include multiple physical data centers dispersed across a wide geographical region. In some embodiments, community 100 may also include one or more emergency services 190. Any vehicle in community 100 may thus communicate with one or more emergency services 190 via DCN 180. Similarly, server(s) 175 of data center 170 may communicate with one or more emergency services 190 via DCN 180. Additionally or alternatively, server(s) 175 of data center 170 may communicate with one or more emergency services 190 via a wireless or fixed communication channel that is not part of DCN 180.

[0018] In embodiments in which one or more backend servers of a data center (e.g., server(s) 175 of data center 170) is utilized to realize a crowd-sourced emergency response service, various information may be efficiently facilitated among vehicles of a community (e.g., community 100) by the backend server(s). FIG. 2 illustrates an example scenario of information flow among a community 200 of vehicles and facilitated by a backend server 275. As shown in FIG. 2, community 200 may include vehicles 211 and 212 having users of a crowd-sourced emergency response service as occupants. Each of vehicles 211 and 212 may initiate a request for an aid action to some other vehicles of community 200 when experiencing an emergency condition. Vehicles 211 and 212 are user-only vehicles in the sense that the occupants thereof are not able to respond to a request for an aid action initiated by other vehicles of community 200. Community 200 may also include one or more vehicles, such as vehicle 222, having volunteers of the crowd-sourced emergency response service as occupants. Vehicle 222 may respond to a request for an aid action initiated by other vehicles of community 200, but do not initiate a request for an aid action. Community 200 may further include vehicles having occupants in both the user role and the volunteer role, such as vehicles 221, 223 and 224 of FIG. 2. Each of vehicles 221, 223 and 224 may have a respective occupant as a user of the crowd-sourced emergency response service and, thus, may initiate a request for an aid action when experiencing an emergency condition. In addition, the respective occupant of each of vehicles 221, 223 and 224 may at the same time serve as a volunteer of the crowd-sourced emergency response service and, thus, may respond to a request for an aid action initiated by other vehicles of community 200. Community 200 may be an example implementation of community 100 and, thus, description and features pertaining to community 100 are applicable to community 200.

[0019] In some embodiments, an occupant of any vehicle may participate in community 200 for the crowd-sourced emergency service by registering with and submitting vehicle data 251 to backend server 275 before the occupant/vehicle start using the service. Alternatively or additionally, the occupant of the vehicle may submit, replenish or amend vehicle data 251 when or after the vehicle becomes "active" in community 200 by registering with backend server 275. The vehicle data of a given vehicle may include information of the respective vehicle such as, for example and not limited to, a license plate number (e.g., Virginia plate number 123456), a vehicle identification number (VIN), an appearance description (e.g., make, model, color), a vehicle photo, a functional description (e.g., the respective vehicle may be a tow truck, an ambulance, or carrying some aid equipment such as a jump start kit, a spare tire, a car jack, a snow chain, an automated external defibrillator (AED), a medical first-aid kit, and the like), contact information (e.g., the respective vehicle may be equipped with some wireless communication device via which the respective vehicle may be contacted remotely), and the like. Vehicle data 251 of a respective vehicle may be identified by a unique identifier (e.g., the VIN of the respective vehicle) and may be stored in a database 250 that is accessible by backend server 275. [0020] Each vehicle of community 200 may have one or more occupants, with each occupant being either a driver or a passenger of the respective vehicle. An individual riding in a vehicle of community 200 of vehicles participating in the crowd-sourced emergency service may register with and submit individual data 252 to backend server 275 before the individual, as an occupant of a respective vehicle, starts using the service. Alternatively or additionally, the individual may submit, replenish or amend individual data 252 when or after the individual becomes "active" in community 200 by registering with backend server 275. The individual data of a respective individual may include information of the respective individual such as, for example and not limited to, a name, a personal photo, a social security number (SSN), a personal profile (e.g., age, gender, height, weight, blood type, pre-existing wellness conditions), a skill description (e.g., the respective individual may be a police officer, a doctor, a nurse, an EMT, a firefighter, a mechanical technician, a military veteran, a lifeguard, or possessing some aid skills such cardiopulmonary resuscitation (CPR), Heimlich maneuver, operating an AED, and the like), contact information (e.g., a cell phone number, street address, email address, and the like), emergency contact information (e.g., contact information of personal doctors, relatives or friends whom the individual intends to contact in an emergency situation), and the like. Individual data 252 of a respective individual may be identified by a unique identifier (e.g., the SSN of the respective individual) and may be stored in database 250 that is accessible by backend server 275.

[0021] In some embodiments, database 250 may store vehicle data 251 and individual data 252 for vehicles and individuals that are currently not part of community 200. That is, some vehicles and/or individuals may have submitted their respective individual data and/or vehicle data which is stored in database 250, but are not currently "active" and participating in the crowd- sourced response service. On the contrary, for each vehicle in community 200 and at least one occupant thereof, database 250 stores at least some vehicle data and/or individual data for the vehicle and respective occupant(s)/individual(s) that are currently "active" and participating in the crowd-sourced response service. That is, for a vehicle or an individual to become "active" in community 200 by registering with backend server 275 in accordance with some embodiments of the present disclosure, the vehicle and/or the individual would need to submit at least some data on the respective vehicle and/or individual data (e.g., VIN, SSN, contact information) to backend server 275, which in term may store the vehicle data and individual data in database 250.

[0022] A vehicle, along with one or more individuals riding the vehicle (i.e., the occupant(s) of the vehicle), may register with backend server 275 as a user and/or volunteer of the crowd-source emergency service and become an "active instance" of community 200. For example, vehicle 211 of FIG. 2, along with a driver and a passenger thereof, may register with backend server 275 as a user vehicle of community 200. Backend server 275 may accordingly create a respective user instance 261 for vehicle 211 and the occupants thereof indicating that the occupants are riding in vehicle 211. In some embodiments, the respective user instance 261 may include a current location of vehicle 211. The respective user instance 261 may be logged in an active registry 260 that is accessible by backend server 275. Backend server 275 may link or otherwise associate the respective user instance 261 for vehicle 211 and the occupants thereof with the respective vehicle data 251 of vehicle 211 and individual data 252 of the occupants of vehicle 211. As another example, vehicle 222 may be an ambulance having an AED and an EMT onboard. Vehicle 222 may register with backend server 275 as a volunteer vehicle of community 200. Accordingly, backend server 275 may create a respective volunteer instance 262 for vehicle 222 and the on-board EMT indicating that an EMT is riding in vehicle 222. In addition, each volunteer instance 262 may include a current location of the respective volunteer vehicle, as constantly or periodically reported and updated by the respective volunteer vehicle to backend server 275. The respective volunteer instance 262 may also be logged in active registry 260 that is accessible by backend server 275. Backend server 275 may link or otherwise associate the respective volunteer instance 262 for vehicle 222 and the EMT thereof with the respective vehicle data 251 of vehicle 222 and individual data 252 of the EMT.

[0023] In some embodiments, backend server 275 may determine, for each volunteer instance 261 in active registry 260, a list of one or more aid skills possessed by the respective vehicle and occupant(s) thereof. The list of aid skills may be included or otherwise associated with the respective volunteer instance 262. For instance, backend server 275 may determine that ambulance 222, along with the on-board EMT, possess aid skills to perform actions such as operating an AED, applying CPR, applying Heimlich maneuver, stopping a bleeding, rushing a patient to an emergency room, and the like. Backend server 275 may indicate the determined list of aid skills in the respective volunteer instance 262 of vehicle 222.

[0024] As stated previously, a vehicle of the crowd-sourced emergency response service may be both a user vehicle and a volunteer vehicle at the same time. For example, vehicle 221 of FIG. 2 may be a sedan driven by an off-duty doctor. The off-duty doctor may register vehicle 221 along with himself/herself with backend server 275 as a volunteer vehicle of community 200, as he/she is willing to provide medical aid in case of a medical emergency being experienced by occupant(s) of one or more other vehicles of community 200. Backend server 275 may accordingly create a respective volunteer instance 262 for vehicle 221 and the off-duty doctor. Meanwhile, the off-duty doctor may further register vehicle 221 along with himself/herself as a user vehicle of community 200, in case of a need for assistance in a car accident on his/her way home. In addition to the respective volunteer instance 262, backend server 275 may create a respective user instance 261 for vehicle 221 and the off-duty doctor.

[0025] Each vehicle in FIG. 2, along with one or more respective occupants therein, may be registered with backend server 275 as either or both of an active user vehicle and an active volunteer vehicle, and thus may have either or both of a corresponding user instance 261 and a corresponding volunteer instance 262 created in active registry 260. That is, active registry 260 may have a respective user instance 261 for each of user vehicles 211 and 212. Similarly, active registry 260 may have a respective volunteer instance 262 for volunteer vehicle 222. Likewise, active registry 260 may have a respective user instance 261 and a respective volunteer instance 262 for each of user-and-volunteer vehicles 221, 223 and 224. By accessing active registry 260, backend server 275 may identify or otherwise determine which vehicles are currently in community 200, as well as a role (i.e., user, volunteer or both) of each vehicle.

[0026] In general, there are four stages in the rendering of the crowd-sourced response service. Firstly, a distressed vehicle of a community of vehicles (e.g., community 200) may send a notification to a backend server (e.g., backend server 275) regarding an emergency condition to which the vehicle is currently subject. Secondly, the backend server may broadcast a request to one or more other vehicles in the community regarding the emergency condition of the distressed vehicle. Thirdly, a number of the one or more other vehicles, upon receiving the request, may send a response back to the backend server indicating an intention to address the emergency condition with an aid action. Fourthly, the backend server may inform the distressed vehicle regarding aid action(s) indicated by the vehicle(s) having responded to the request. [0027] For example, vehicle 211 may be subject to a condition of a flat tire and thus may transmit a notification 231 to backend server 275. Notification 231 may include a location of vehicle 211, a VIN of vehicle 211, a SSN of a driver of vehicle 211 and a description of the condition of vehicle 211 (e.g., having a flat tire for its front right wheel). Based on notification 231, backend server 275 may access database 250 and fetch or otherwise obtain vehicle data 251 of vehicle 211 and individual data 252 of the driver of vehicle 211 (e.g., according to the respective VIN and/or SSN). In particular, backend server 275 may fetch vehicle data 251 of vehicle 211 and determine that vehicle 211 carries a spare tire but not tools for replacing a tire. Backend server 275 may subsequently determine that a possession of tire replacement tools, such as a jack and a wrench, is an aid skill necessary for addressing the flat tire condition of vehicle 211. Backend server 275 may access volunteer instances 262 of active registry 260 and determine that each of vehicles 221, 222 and 223 possesses the necessary aid skill (i.e., carrying a jack and a wrench). Backend server 275 may then broadcast to vehicles 221, 222 and 223 a request 232 regarding the condition of vehicle 211. Request 232 may include a description of the condition of vehicle 211 (e.g., "flat tire at front right wheel; vehicle carries spare tire but no tools; jack and wrench needed"), the location of vehicle 211 according to notification 231, a license plate number and/or a photo of vehicle 211 according to the respective vehicle data 251 of vehicle 211, a name, a photo and/or contact information of the driver of vehicle 211 according to the respective individual data 252 of the driver, a total number of occupant(s) of vehicle 211, and a personal profile of the occupant(s) of vehicle 211. Request 232 may further include an estimated time of arrival (ETA) that is determined by backend server 275 based on the location of vehicle 211 and a current location of each of vehicles 221, 222 and 223 as indicated in their respective volunteer instances 262. The ETA for each of vehicles 221, 222 and 223 is an estimated time for the respective vehicle to move from its current location to the location of vehicle 211. Alternatively, the ETA may be determined by each of vehicles 221, 222 and 223, respectively, instead of by backed server 275. Request 232 may be presented to an occupant of vehicle 221, vehicle 222 and/or vehicle 223 via various human-perceivable means. For example, a comprehensive voice message regarding request 232 may be presented to the occupant of vehicle 221 by an infotainment center of vehicle 221. As another example, a current location of vehicle 211 as well as one or more map routes via which vehicle 222 may arrive at the location of vehicle 211 may be displayed or otherwise highlighted on a map screen of an infotainment center of vehicle 222.

[0028] Upon receiving request 232, an occupant of vehicle 221 may decide not to respond to request 232. On the contrary, an occupant of vehicle 222 and an occupant of vehicle 223 may respectively decide to respond to request 232 regarding the flat-tire condition of vehicle 211, and each may transmit a response indicating an intention to provide an aid action for the condition. That is, the occupant of vehicle 222 and the occupant of vehicle 223 are now "responders" to the flat-tire condition of vehicle 211. Vehicle 222 may send a response 233 A to backend server 275 indicating such an intention, and vehicle 223 may send a response 233B to backend server 275 also indicating such an intention.

[0029] In some embodiments, backend server 275 may then inform vehicle 211 regarding such intentions of vehicles 222 and 223. That is, upon receiving response 233 A, backend server 275 may inform vehicle 211 about an aid action 234A that vehicle 222 intends to provide. Likewise, upon receiving response 233B, backend server 275 may inform vehicle 211 about an aid action 234B that vehicle 223 intends to provide. Aid action 234A may include some or all of the following information: a current location of vehicle 222 according to response 233A, a name, a photo and contact information of the occupant of vehicle 222, a license plate number, a photo and a description of vehicle 222 according to the respective vehicle data 251 of vehicle 222, a total number of occupant(s) in vehicle 222 who may be capable of providing aid with respect to the condition of vehicle 211, a name, a photo and contact information of the occupant of vehicle 222 according to the respective individual data 252 of the occupant. Aid action 234A may also include an ETA of vehicle 222, indicating an estimated time for vehicle 222 to move from its current location to the location of vehicle 211. Likewise, Aid action 234B may include some or all of the following information: a current location of vehicle 223 according to response 233B, a name, a photo and contact information of the occupant of vehicle 223, a license plate number, a photo and a description of vehicle 223 according to the respective vehicle data 251 of vehicle 223, a total number of occupant(s) in vehicle 223 who may be capable of providing aid with respect to the condition of vehicle 211, a name, a photo and contact information of the occupant of vehicle 223 according to the respective individual data 252 of the occupant. Aid action 234B may also include an ETA of vehicle 223, indicating an estimated time for vehicle 223 to move from its current location to the location of vehicle 211. The ETA of vehicle 222 and the ETA of vehicle 223 may be determined by backend server 275 and then sent to vehicle 211 as part of aid actions 234A and 234B, respectively. Alternatively, the ETA of vehicle 222 and the ETA of vehicle 223 may be determined by vehicle 211 instead, based on the current location of vehicle 222 and the current location of vehicle 223 included in aid actions 234A and 234B, respectively. An occupant of vehicle 211 may be informed about aid actions 234A and 234B via various human-perceivable means. For example, a comprehensive voice message regarding aid actions 234A and 234B may be presented to the occupant of vehicle 211 by an infotainment center of vehicle 211. As another example, current locations of vehicles 222 and 223 as well as their respective ETA may be displayed on a map screen of the infotainment center of vehicle 211.

[0030] In some embodiments, when broadcasting a request, backend server 275 may not broadcast to all vehicles of community 200. Instead, upon receiving a notification from a user vehicle subject to a condition, backend server 275 may select a subset of all vehicles of community 200 and broadcast a request to the subset of vehicles. In selecting the subset of vehicles for broadcasting the request, backend server 275 may rank, for each occupant of each vehicle of community 200, an ability to address the condition associated with the notification. Specifically, in ranking the ability of each occupant of each vehicle, backend server 275 may consider a number of factors such as, for example and not limited to, an ETA for the respective vehicle to arrive at a location of the user vehicle, a total number of one or more occupants in the respective vehicle, as well as one or more aid skills possessed by the one or more occupants in the respective vehicle. Based on the ranking result, backend server 275 may select one or more vehicles of all vehicles of community 200 as recipient(s) of the broadcasting of the request. In some embodiments, backend server 275 may broadcast the request to the selected vehicles at the same time. In some embodiments, backend server 275 may broadcast the request to the selected vehicles in a descending order of priority based on the ranking result.

[0031] For example, upon receiving notification 231 that vehicle 211 has a flat tire, backend server 275 of FIG. 2 may evaluate and rank the ability of each occupant and each vehicle of community 200 with respect to addressing the condition associated with vehicle 211 as indicated in notification 231. In the example shown in FIG. 2, vehicle 212 is registered with backend server 275 as a user vehicle but not a volunteer vehicle. Namely, the occupant of vehicle 212 does not agree to provide assistance to a condition associated another vehicle of community 200, and thus the ranking of any occupant of vehicle 212 is low. Although each of vehicles 221, 222 and 223 is equipped with needed tools for performing a tire change for vehicle 211, an occupant of vehicle 221 and an occupant of vehicle 222 may be ranked higher than an occupant of vehicle 223 as vehicle 223 is located farther away from vehicle 211 as compared to vehicles 221 and 222. Namely, vehicle 223 has a longer ETA to get to a location of vehicle 211 than each of vehicles 221 and 222 does. An occupant of vehicle 224, although being physically closer to vehicle 211 than an occupant of vehicle 221, vehicle 222 or vehicle 223, may be ranked lower than an occupant of vehicle 221, vehicle 222 or vehicle 223, as vehicle 224 is not equipped with the needed tools. Between vehicle 221 and vehicle 222, an occupant of vehicle 221 may be ranker higher, as the volunteer instance 262 of vehicle 221 shows a driver and a passenger are riding in vehicle 221, while the volunteer instance 262 of vehicle 222 shows that vehicle 222 has one occupant which is the driver of vehicle 222. That is, the ranking result of the ability to address the flat-tire condition of vehicle 211 may be that vehicle 221 is ranked higher than vehicle 222, which is ranked higher than vehicle 223, which is ranked higher than vehicle 224, which is ranked higher than 212 (i.e., vehicle 221 > vehicle 222 > vehicle 223 > vehicle 224 > vehicle 212). Based on this ranking result, backend server 275 may select, and broadcast request 232 to vehicles 221, 222 and 223. Backend server 275 may broadcast request 232 to vehicles 221, 222 and 223 at the same time. Alternatively, backend server 275 may broadcast request 232 to vehicles 221, 222 and 223 in a descending order of priority according to the ranking result. That is, backend server 275 may send request 232 to vehicle 221 first, then to vehicle 222, and then to vehicle 223. In some embodiments, backend server 275 may broadcast request 232 in the descending order of priority with a predetermined wait period between transmitting request 232 to each of the vehicles. For example, backend server 275 may transmit request 232 to vehicle 221 first. If vehicle 221 does not respond within the predetermined wait period (e.g., 1 minute) after the transmitting with a response indicating an intention to provide assistance, backend server 275 may subsequently transmit request 232 to vehicle 222 at the end of the predetermined wait period. In contrast, if vehicle 221 does respond within the predetermined wait period after the transmitting with a response indicating an intention to provide assistance, backend server 275 may not proceed to transmit request 232 to vehicle 222 and/or vehicle 223. Otherwise, if vehicle

222 does not respond within the predetermined wait period after the transmitting with a response indicating an intention to provide assistance, backend server 275 may subsequently transmit request 232 to vehicle 223 at the end of the predetermined wait period.

[0032] As disclosed in previous examples, notification 231 may include less information than the information included in request 232, as notification 231 may merely include essential information regarding the condition to which vehicle 211 is subject. Upon receiving notification 231, backend server 275 may generate request 232 by supplementing the information in notification 231 with relevant vehicle data 251 and individual data 252 stored in database 250. Backend server 275 may additionally use relevant user instance 261 stored in active registry 260 in generating request 232. In some cases, however, the relevant vehicle data 251, individual data 252 and user instance 261 may not contain all the information needed for backend server 275 to generate a comprehensive and informative request 232. For such cases, vehicle 211 may need to include more information in notification 231 such that backend server 275 may have enough information to generate a comprehensive and informative request 232. For example, vehicle 211 may not have a respective vehicle description (e.g., make, model and color thereof) stored as part of its respective vehicle data 251 prior to the occurrence of the flat tire condition. Vehicle 211 may, upon the occurrence of the flat tire condition, include in notification 231 the make, model and color of vehicle 211. Backend server 275 may include such vehicle information of make, model and color of vehicle 211 in request 232.

[0033] Similarly, as disclosed in previous examples, response 233A may include less information than the information included in aid action 234A, as response 233A may merely include essential information such as the current location of vehicle 222 and the indication of the intention of vehicle 222 to provide aid to vehicle 211. Backend server 275 may generate aid action 234A by supplementing the information in response 233 A with relevant vehicle data 251 and individual data 252 stored in database 250. Backend server 275 may additionally use relevant volunteer instance 262 stored in active registry 260 in generating aid action 234A. In some cases, however, the relevant vehicle data 251, individual data 252 and volunteer instance 262 may not contain all the information needed for backend server 275 to generate a comprehensive and informative aid action 234A. For such cases, vehicle 222 may need to include more information in response 233A such that backend server 275 may have enough information to generate a comprehensive and informative aid action 234A. For instance, a driver of vehicle 222 may not have a personal photo stored as part of his or her respective individual data 252 prior to initiating response 233A. Vehicle 222 may include in response 233A a personal photo of the driver. Backend server 275 may include the personal photo of the driver vehicle 222 in aid action 234A so that an occupant of vehicle 211 may have a picture of a person who is coming to attend to the flat tire condition.

[0034] Various conditions associated with a user vehicle of community 200 may trigger the user vehicle to send, transmit or otherwise initiate a notification calling for help. For example, situations such as a crash with another vehicle or an object, a launch of an airbag, a damage or deformation of the vehicle body, a flat tire, a substantially empty fuel tank, a malfunction of a part of the user vehicle, an impairment of an occupant thereof, a wellness anomaly of the occupant thereof, and an unintended or involuntary control of the user vehicle may be conditions for the user vehicle to reach out for help by initiating a notification. An occupant of the user vehicle may initiate a notification if the occupant deems some situation associated with the occupant, another occupant and/or the user vehicle to be an emergency condition. For instance, the driver of vehicle 211 may initiate notification 231 when vehicle 211 runs out of fuel on a road. Alternatively or additionally, the user vehicle may be equipped with various kinds of sensors that may enable the user vehicle to sense one of various condition, such as those mentioned above, and initiate a notification automatically. The automatic initiation of a notification is especially advantageous if an occupant is unable to manually initiate a notification due to a physical constraint or even a threat of life. For example, vehicle 211 may be equipped with an airbag sensor that is able to sense a launch of an airbag. Suppose vehicle 211 is involved in a car accident and crashed into another vehicle, resulting in one or more airbags of vehicle 211 being launched or otherwise deployed. The airbag sensor may sense a launch of an airbag associated with the driver's seat and automatically trigger a notification for the condition and, as a result, vehicle 211 may transmit a notification (e.g., notification 231) to backend server 275.

[0035] In addition to sensors disposed in or on a user vehicle, the user vehicle may make use of sensors disposed on, or otherwise worn by, an occupant of the user vehicle so as to sense an emergency condition, which may be a medical symptom of the occupant. Whether disposed in the user vehicle or worn by the occupant of the user vehicle, one or more sensors may be used to sense one or more vital signs of one or more occupants of the vehicle, such as a heart rate, a respiration rate, a blood pressure reading, a body temperature, an oxygen saturation level, and the like. For example, vehicle 211 may be able to wirelessly communicate with a wearable heart rate detector worn by the driver of vehicle 211. When the wearable heart rate detector detects an abnormal drop in a heart rate of the driver, vehicle 211 may automatically send out notification 231 to backend server 275 regarding the condition of the abnormal drop in heart rate. Backend server 275 may broadcast a request (such as request 232), based on notification 231, to one or more other vehicles of community 200 (such as vehicles 221, 222 and 223). In addition, backend server 275 may transmit information regarding the condition to a hospital, a police department, an emergency service, or one or more predetermined emergency contact persons. For example, backend server 275 may find contact information of a doctor associated with the driver of vehicle 211 in the respective individual data 252 of the driver of vehicle 211, and send to the doctor a reading from the heart rate detector worn by the driver of vehicle 211. Vehicle 211 may continue to receive real-time reading of the driver's heart rate from the heat rate detector and send this information to backend server 275 which may, in turn, send to the doctor a real-time reading of the driver's heart rate.

[0036] FIG. 3 illustrates an example process 300 for a vehicle and an occupant thereof to receive a roadside assistance in accordance with the present disclosure. Process 300 may include one or more operations, actions, or functions shown as blocks such as 310, 320, 330, 340, 350, 360 and 370 as well as sub-blocks 312 and 314. Although illustrated as discrete blocks, various blocks of process 300 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Process 300 may be implemented by community 100 of FIG.1 and community 200 of FIG.2. For illustrative purposes and without limiting the scope of process 300, the following description of process 300 is provided in the context of vehicle 211 of community 200. Process 300 may begin with block 310. [0037] At 310, process 300 may involve vehicle 211 registering vehicle 211 and at least one occupant thereof with backend server 275. In some embodiments, in registering vehicle 211 and the at least one occupant thereof with backend server 275, process 300 may involve the processor associated with vehicle 211 performing a number of operations, as shown in sub- blocks 312 and 314. At 312, process 300 may involve the processor associated with vehicle 211 submitting vehicle data 251 regarding vehicle 211 to backend server 275. The vehicle data 251 regarding vehicle 211 may be stored in database 250 by backend server 275. At 314, process 300 may involve the processor associated with vehicle 211 submitting individual data 252 regarding the at least one occupant of vehicle 211 to backend server 275. The individual data 252 regarding the at least one occupant of vehicle 211 may also be stored in database 250 by backend server 275. Process 300 may proceed from 310 to 320.

[0038] At 320, process 300 may involve vehicle 211 providing a current location of vehicle 211 to backend server 275. Process 300 may proceed from 320 to 330.

[0039] At 330, process 300 may involve one or more sensors disposed in or on vehicle 211, worn by the at least one occupant of vehicle 211, or otherwise in communication with the processor associated with vehicle 211, sensing an impairment condition associated with vehicle 211 or with the at least one occupant of vehicle 211. For example, a sensor of vehicle 211 may sense a deformation of a body of vehicle 211 due to vehicle 211 crashing with another vehicle or an object. As another example, a respiration detector worn by an occupant of vehicle 211 may sense a drop in respiration rate of the occupant after a car crash. Process 300 may proceed from 330 to 340.

[0040] At 340, process 300 may involve vehicle 211 transmitting an emergency notification, such as notification 231 of FIG. 2, regarding the impairment condition to backend server 275. In some embodiments, the emergency notification transmitted by the processor associated with vehicle 211 to backend server 275 may include the location of vehicle 211. Moreover, the emergency notification may include some information about the at least one occupant of vehicle 211, such as a name, a photo, contact information and a personal profile thereof. In some embodiments, the emergency notification may also include some information about vehicle 211, such as a license plate number, a description, a photo, and a total number of occupant(s) thereof. In some embodiments, the emergency notification may further include a description of the impairment condition. In some embodiments, the emergency notification may also include a list of one or more aid skills needed to address the impairment condition. Process 300 may proceed from 340 to 350.

[0041] At 350, process 300 may involve vehicle 211 receiving a response from backend server 275, such as aid action 234A of FIG. 2, regarding roadside assistance to be provided to vehicle 211. In some embodiments, the response regarding the roadside assistance may include some information of a volunteer vehicle, such as vehicle 222, and of a responder riding therein who, by the response, indicates an intention to provide the roadside assistance. For example, the response received by vehicle 211 (i.e., aid action 234A) may include a location, a license plate number, a description, a photo, an ETA and a total number of occupant(s) of vehicle 222. In some embodiments, the response may also include one or more aid skills possessed by the responder. Process 300 may proceed from 350 to 360.

[0042] At 360, process 300 may involve vehicle 211 presenting the response regarding the roadside assistance in a human-perceivable way. For example, a comprehensive voice message regarding aid action 234 A may be presented to the at least one occupant of vehicle 211 by an infotainment center of vehicle 211. Additionally, the current location of vehicle 211 as well as one or more map routes via which vehicle 222 may arrive at the location of vehicle 211 may be displayed or otherwise highlighted on a map screen of the infotainment center of vehicle 211. Process 300 may proceed from 360to 370.

[0043] At 360, process 300 may involve vehicle 211 transmitting information regarding the impairment condition to a fixed-location emergency service (e.g., a hospital, a police department and/or an emergency service) and one or more predetermined emergency contact persons, or a combination of two or more thereof.

[0044] FIG. 4 illustrates an example process 400 in accordance with the present disclosure. Process 400 may include one or more operations, actions, or functions shown as blocks such as 410, 420, 430, 440, 450, 460 and 470 as well as sub-block 412. Although illustrated as discrete blocks, various blocks of process 400 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Process 400 may be implemented by community 100 of FIG.1 and community 200 of FIG.2. For illustrative purposes and without limiting the scope of process 400, the following description of process 400 is provided in the context of vehicle 222 of community 200. Process 400 may begin with block 410.

[0045] At 410, process 400 may involve vehicle 222 registering a responder (i.e., an occupant of vehicle 222) with backend server 275. The registration may indicate that the responder agrees to provide assistance to one or more impairment conditions associated with one or more occupants of one or more vehicles, such as other vehicles of community 200. In some embodiments, in registering vehicle 222 with backend server 275, process 400 may involve vehicle 222 performing a number of operations, as shown in sub-block 412. At 412, process 400 may involve vehicle 222 providing to backend server 275 a list of one or more aid skills possessed by the responder of vehicle 222. Process 400 may proceed from 410 to 420.

[0046] At 420, process 400 may involve vehicle 222 providing a current location of vehicle 222 to backend server 275. Process 400 may proceed from 420 to 430.

[0047] At 430, process 400 may involve vehicle 222 receiving from backend server 275 a request regarding an impairment condition associated with a requester who is an occupant of a vehicle. For example, a processor associated with vehicle 222 may receive request 232 from backend server 275 regarding the drop in heart rate of an occupant of vehicle 211. Process 400 may proceed from 430 to 440.

[0048] At 440, process 400 may involve vehicle 222 determining an ETA for the responder/vehicle 222 to travel from the current location of the responder to a current location of the requester. For example, a processor associated with vehicle 222 may determine an ETA for vehicle 222 to travel from the current location of vehicle 222 to a current location of vehicle 211. Process 400 may proceed from 440 to 450.

[0049] At 450, process 400 may involve vehicle 222 transmitting a response to backed server 275 indicating an intention of the respondent to provide assistance for the impairment condition. For example, vehicle 222 may transmit response 233A to backed server 275 indicating an intention of the respondent to provide assistance to the occupant of vehicle 211 who is experiencing a drop in heart rate. Process 400 may proceed from 450 to 460.

[0050] At 460, process 400 may involve vehicle 222 displaying a map with the current location of the requester and the current location of the responder/vehicle 222 indicated on the map. In some embodiments, process 400 may further involve vehicle 222 highlighting on the map a route for the responder to travel to the current location of the requester. For example, the processor associated with vehicle 222 may display a map on screen of an infotainment center of vehicle 222 with the respective current locations of vehicles 211 and 222 indicated on the map. Furthermore, the processor associated with vehicle 222 may highlight on the map a route for vehicle 222 to travel to the current location of vehicle 211. Process 400 may proceed from 460 to 470.

[0051] At 470, process 400 may involve vehicle 222 receiving from backend server 275 one or more notifications regarding other assistance intended to be provided for the impairment condition by one or more other responders. For example, the processor associated with vehicle 222 may receive from backend server 275 a notification regarding assistance intended to be provided by vehicle 223 to the occupant of vehicle 211 who is experiencing a drop in heart rate. In some embodiments, the processor associated with vehicle 222 may display on the screen of the infotainment center of vehicle 222 information regarding the assistance intended to be provided by vehicle 223 to the occupant of vehicle 211.

[0052] FIG. 5 illustrates an example process 500 of a crowd-sourced emergency response service in accordance with the present disclosure. Process 500 may include one or more operations, actions, or functions shown as blocks such as 510, 520, 530, 540, 550, 560 and 570. Although illustrated as discrete blocks, various blocks of process 500 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Process 500 may be implemented by community 100 of FIG.1 and community 200 of FIG.2. For illustrative purposes and without limiting the scope of process 500, the following description of process 500 is provided in the context community 200. Process 500 may begin with block 510. [0053] At 510, process 500 may involve receiving, from a first vehicle of a community of vehicles, a notification regarding a condition associated with the first vehicle. In some embodiments, the condition of the first vehicle may include, for example and not limited to, a crash of the first vehicle, a launch of an airbag of the first vehicle, a damage or deformation of a body of the first vehicle, a flat tire of the first vehicle, a substantially empty fuel tank of the first vehicle, a malfunction of a part of the first vehicle, an impairment of an occupant of the first vehicle, a wellness anomaly of the occupant of the first vehicle, an unintended control of the first vehicle, an emergency indicated by the occupant of the first vehicle, or a combination of two or more thereof. For example, backend server 275 may receive from vehicle 211 notification 231 regarding a flat tire of vehicle 211. In some embodiments, notification 231 may include a location of vehicle 211, a VIN of vehicle 211, a SSN of a driver of vehicle 211 and a description of the condition that vehicle 211 got a flat tire at a front right wheel of vehicle 211. In some embodiments, the notification is initiated and transmitted automatically by the first vehicle based on one or more sensors disposed in or on the first vehicle, or by an occupant of the first vehicle, or by both. For example, notification 231 regarding the flat tire of vehicle 211 may be initiated by a driver of vehicle 211. Alternatively, notification 231 may be initiated by a tire pressure sensor disposed in the tire that is losing pressure. Process 500 may proceed from 510 to 520.

[0054] At 520, process 500 may involve ranking an ability of an occupant of each vehicle of the community of vehicles with respect to addressing the condition. For example, backend server 275 may rank an ability of each occupant of each vehicle of community 200 with respect to addressing the flat tire of vehicle 211. In some embodiments, backend server 275 may rank the ability of each occupant of each vehicle of community 200 by determining factors such as, for example and not limited to, an ETA for the respective vehicle to arrive at a location of the user vehicle, a total number of one or more occupants in the respective vehicle, as well as one or more aid skills possessed by the one or more occupants in the respective vehicle. Process 500 may proceed from 520 to 530.

[0055] At 530, process 500 may involve selecting the one or more other vehicles of the community of vehicles for the broadcasting of the request based on a result of the ranking. For example, backend server 275 may rank the ability for an occupant of vehicle 221 to address the flat tire of vehicle 211 higher than that of vehicle 222, which is ranked than that of vehicle 223, which is ranked than that of vehicle 224, which is ranked than that of vehicle 212. Based on this result, backend server 275 may select vehicles 221, 222 and 223 to which request 232 is broadcasted. Process 500 may proceed from 530 to 540.

[0056] At 540, process 500 may involve broadcasting, to one or more other vehicles of the community of vehicles, a request regarding the condition based on the notification. For example, backend server 275 may broadcast request 232 to vehicles 221, 222 and 223 of community 200 regarding the flat-tire condition of vehicle 211 based on notification 231. In some embodiments, backend server 275 may broadcast request 232 to vehicles 221, 222 and 223 at the same time. In some embodiments, backend server 275 may broadcast request 232 to vehicles 221, 222 and 223 in a descending order of priority according to the ranking result. That is, backend server 275 may send request 232 to vehicle 221 first, then to vehicle 222, and then to vehicle 223.

[0057] In some embodiments, either or both of the notification and the request may include some or all of the following information: a location of the first vehicle, a name of at least one occupant of the first vehicle, a photo of the at least one occupant of the first vehicle, contact information of the at least one occupant of the first vehicle, a license plate number of the first vehicle, a description of the first vehicle, a photo of the first vehicle, a total number of one or more occupants of the first vehicle, a personal profile of the at least one occupant of the first vehicle, a description of the condition, a list of one or more aid skills needed to address the condition, a description of an impairment condition associated with the at least one occupant of the first vehicle, a list of one or more aid skills needed to address the impairment condition, or a combination of two or more thereof. In some embodiments, the description of the impairment condition may include some or all of the following information: a description of one or more symptoms of an ill occupant in the first vehicle, and wherein the personal profile comprises one or more vital signs of the ill occupant. Process 500 may proceed from 540 to 550.

[0058] At 550, process 500 may involve receiving, from a second vehicle of the one or more other vehicles, a response indicating an intention to provide an aid action for the condition. For example, backend server 275 may receive from vehicle 222 response 233A which is initiated by an occupant of vehicle 222. Response 233A may indicate an intention of the occupant of vehicle 222 to provide an aid action for the flat tire of vehicle 211. Process 500 may proceed from 550 to 560.

[0059] At 560, process 500 may involve informing the first vehicle about the aid action indicated by the second vehicle based on the response from the second vehicle. For example, backend server 275 may, based on response 233A, send a message to vehicle 211 to inform vehicle 211 that the occupant(s) of vehicle 222 indicated an intention to provide assistance regarding the flat tire of vehicle 211. In some embodiments, either or both of the response and the aid action indicated by the second vehicle may include some or all of the following information: a location of the second vehicle, a name of a responder riding in the second vehicle, a photo of the responder, contact information of the responder, one or more aid skills possessed by the responder, a license plate number of the second vehicle, a description of the second vehicle, a photo of the second vehicle, a total number of one or more occupants in the second vehicle capable of providing aid with respect to the condition, an ETA of the second vehicle, or a combination of two or more thereof. Process 500 may proceed from 560 to 570.

[0060] At 570, process 500 may involve transmitting information regarding the condition to a hospital, a police department, an emergency service, one or more predetermined emergency contact persons, or a combination of two or more thereof. For example, backend server 275 may transmit the license plate number and the current location of vehicle 211 to an emergency roadside service provider.

[0061] In some embodiments, the crowd-sourced emergency response service of FIG. 1 or FIG. 2 may be implemented by a smartphone app that is connected or otherwise in wireless communication with one or more of the vehicles of community 100 or community 200.

[0062] Each vehicle of community 100 and community 200, regardless of the role of its respective occupant being a user or a volunteer, or both, may participate in the crowd-sourced emergency response service through a smartphone app installed in a smartphone or a computer device disposed in the respective vehicle. FIGS. 6 - 9 illustrate screenshots of a smartphone app in accordance with an embodiment of the present disclosure. For illustrative purposes and without limiting the scope of the present disclosure, the following description of a smartphone app is provided in the context of community 200 with reference to FIGS. 6 - 9.

[0063] An occupant of a vehicle may register the vehicle with a backend server via the smartphone app installed on a smartphone to enable the vehicle to participate in the community of vehicles, either as a user vehicle or a volunteer vehicle. For example, a driver of vehicle 211 may carry a first smartphone having the smartphone app installed, and may register vehicle 211 via the smartphone app as a user vehicle by selecting "driver" as the "Choose Your Role" setting of the smartphone app, as shown in area 611 of screenshot 610. The driver of vehicle 211 may register vehicle 211 with backend server 275 via sign-in area 612 of screenshot 610 using an email address and a password. After vehicle 211 is registered with or otherwise signed in to community 200, the smartphone app may receive a driver profile from backend server 275 and subsequently display at least a part of the driver profile on a screen of the first smartphone, such as a picture 621 and a name 622 of the driver as shown on screenshot 620. The driver of vehicle 211 may further provide a total number of passengers riding in vehicle 211 through the smartphone app, as indicated in area 623 of screenshot 620.

[0064] On the other hand, an occupant of vehicle 222 may carry a second smartphone having the smartphone app installed, and may register vehicle 222 via the smartphone app as a volunteer vehicle by selecting "responder" as the "Choose Your Role" setting of the smartphone app, as shown in area 661 of screenshot 660. Similarly, the occupant of vehicle 222 may register vehicle 222 with backend server 275 via sign-in area 662 of screenshot 660 using an email address and a password.

[0065] Vehicle 211 may send out notification 231 through the smartphone app to backend server 275 regarding an emergency condition associated with vehicle 211. For example, an airbag sensor disposed in vehicle 211 may detect a launch of an airbag of vehicle 211 and send a signal to the smartphone app, which triggers the smartphone app to send out notification 231 regarding a condition of possible car crash of vehicle 211. The smartphone app may display a map on the screen of the first smartphone with a current location of vehicle 211 indicated on the map, as shown in area 711 of screenshot 710. The smartphone app may also display at least a part of the driver profile on the screen of the first smartphone, such as the name, an age, one or more pre-existing conditions and a phone number of the driver of vehicle 211, as shown in area 712 of screenshot 710. The smartphone app may further display on the screen of the first smartphone a responder list indicating any other vehicle of community 200 which has indicated an intention to provide assistance to the condition of possible car crash of vehicle 211, as shown in area 713 of screenshot 710. As indicated in the list of responders, currently there has not been any other vehicle of community 200 that has indicated an intention to provide assistance to the condition of possible car crash of vehicle 211.

[0066] After receiving notification 231 regarding the condition of the airbag launch of vehicle 211, backend server 275 may broadcast request 232 to vehicles 221, 222 and 223. The second smartphone carried by the occupant of vehicle 222 may, upon receiving request 232, display on the screen of the second smartphone a message 761 regarding the condition of the airbag launch of vehicle 211, as shown in screenshot 760 of FIG. 7. Alternatively or additionally, the second smartphone may present request 232 to the occupant of vehicle 222 using a voice message or other human-perceivable ways. The smartphone app may display a map on the screen of the second smartphone with both the current location 774 of vehicle 211 and a current location 775 of vehicle 222 indicated on the map, as shown in area 771 of screenshot 770. The smartphone app may also display at least a part of the driver profile of the driver of vehicle 211 on the screen of the second smartphone, as shown in area 772 of screenshot 770. The smartphone app may further display on the screen of the first smartphone a responder list on the screen of the second smartphone a "YES" button and a "NO" button, as shown in area 773 of screenshot 770. The occupant of vehicle 222 may respond by touching one of the two buttons. The occupant of vehicle 222 may touch the "YES" button for the smartphone app to transmit to backend server 275 response 233A which indicates an intention of the occupant of vehicle 222 to provide assistance to vehicle 211 regarding the condition of the possible car crash. The occupant of vehicle 222 may touch the "NO" button for the smartphone app to transmit to backend server 275 an indication of no intention of the occupant of vehicle 222 to provide assistance to vehicle 211 regarding the condition of the possible car crash.

[0067] After the smartphone app transmits response 233A to backend server 275, backend server 275 may accordingly transmit aid action 234A to vehicle 211 based on response 233A. Aid action 234A may include a name, a phone number and one or more aid skills of the occupant of vehicle 222. The smartphone app may then display on the screen of the first smartphone (i.e., the smartphone carried by the driver of vehicle 211) at least some information included in aid action 234A. For example, the smartphone app may display on the screen of the first smartphone the name, the phone number and the one or more aid skills of the occupant of vehicle 222, as shown in area 813 of screenshot 810. As can be seen in area 813 of screenshot 810, the smartphone app shows that there has been at least two vehicles of community 200 that, as responders, have indicated an intention to provide assistance to vehicle 211 regarding the condition of the possible car crash. An ETA 814 associated with each responder is also displayed on the screen of the first smartphone to indicate an estimated time for the respective responder to arrive the current location of vehicle 211. As with screenshot 710, the smartphone app may display a map on the screen of the first smartphone with a current location of vehicle 211 indicated on the map, as shown in area 811 of screenshot 810. Moreover, the smartphone app may display at least a part of the driver profile on the screen of the first smartphone, such as the name, an age, one or more pre-existing conditions and a phone number of the driver of vehicle 211, as shown in area 812 of screenshot 810. [0068] The same information regarding the driver of vehicle 211 (as shown in area 812 of screenshot 810) may be transmitted from backend server 275 to vehicle 222 and shown on the screen of the second smartphone (i.e., the smartphone carried by the occupant of vehicle 222), as shown in area 862 of screenshot 860. Likewise, the same information of the responder list (as shown in area 813 of screenshot 810) may be transmitted from backend server 275 to vehicle 222 and shown on the screen of the second smartphone, as shown in area 863 of screenshot 860. This enables the responder (i.e., the occupant of vehicle 222) to know about other assistance intended to be provided for vehicle 211 by one or more other responders of community 200. The current location 864 of vehicle 211 and the current location 865 of vehicle 222 may also be indicated on the map, as shown in area 861 of screenshot 860. In addition, a "directions" button 866 is provided on the screen of the second smartphone. The occupant of vehicle 222 may touch button 866, which triggers the smartphone app to provide a turn-by-turn instruction for vehicle 222 to travel from location 865 to location 864, as shown in screenshot 870 of the smartphone app. The instruction shown in screenshot 870 may also include a map indicating the current location 874 of vehicle 211, the current location 875 of vehicle 222 as well as a highlighted route 876 from location 875 to location 874.

[0069] The smartphone app may update, for the driver of vehicle 211, a location status of each of the responders on the screen of the first smartphone. As shown in screenshot 910 of FIG. 9, one of the two responders, Carl Garcia, has arrived at the location of vehicle 211, and the other responder, Linette Savard, is estimated to arrive in less than 1 minute. A minute later, the location status is updated to show both responders have arrived the location of vehicle 211, as shown in screenshot 920. [0070] FIG. 10 illustrates an example apparatus, or response manager 1000, in accordance with an embodiment of the present disclosure. Response manager 1000 may perform various functions related to techniques, methods and systems described herein, including those described above with respect to community of vehicles 100 and community of vehicles 200 as well as those described above with respect to process 300, 400 and process 500. Response manager 1000 may be installed, equipped or otherwise implemented in each vehicle of community 100 and community 200 to effect various embodiments in accordance with the present disclosure. Response manager 1000 may include at least some of the components illustrated in FIG. 10.

[0071] Response manager 1000 may include one or more sensors 1070(1) - 1070(M), where M is a positive integer greater than or equal to 1. The one or more sensors 1070(1) - 1070(M) may be configured to detect one or more conditions associated with the respective vehicle (e.g., vehicle 211). For instance, the one or more sensors 1070(1) - 1070(M) may detect a crash with another object, a launch of an airbag, a damage or deformation of the vehicle body, a flat tire, a substantially empty fuel tank, a malfunction of a part of the user vehicle, an impairment of an occupant thereof, a wellness anomaly of the occupant thereof, an unintended or involuntary control of the respective vehicle.

[0072] Response manager 1000 may include a user input device 1030 configured to receive one or more user inputs from a user of the vehicle. User input device 1030 may include one or more features to allow the user to enter user input(s) in one or more manners. The one or more features may include, for example and not limited to, one or more touch-sensing panels, one or more buttons, one or more turn knobs, and one or more microphones with accompanying logics to recognize human speech by the user. With user input device 1030, a user may make user input(s) to denote one or more user responses such as, for example and not limited to, vehicle conditions (e.g., low fuel level, broken head lamp, dead battery and the like), unexpected events (e.g., strike, terrorist attack, hijack and the like), road hazards (e.g., a flat tire, car accident, loose object on the road and the like) and so on.

[0073] Response manager 1000 may include a communication device 1040 configured to wirelessly transmit and receive data.

[0074] Response manager 1000 may further include one or more processors, such as a main processor 1010, coupled to receive data on the one or more conditions from the one or more sensors 1070(1) - 1070(M) and to receive the one or more user inputs from the user input device 1030. Main processor 1010 may execute one or more actions such as registering the vehicle to a backend server located remotely, transmitting an emergency notification regarding an impairment condition sensed by the one or more sensors 1070(1) - 1070(M) to the backend server, receiving from the backend server a response regarding a roadside assistance intended to be provided by another vehicle.

[0075] In some embodiments, main processor 1010 may execute one or more other actions such as providing to the backend server a current location of the responder, receiving a request from the backend server regarding an impairment condition associated with another vehicle, determining an ETA for the respective vehicle to travel from the current location of the respective vehicle to a current location of another vehicle having the impairment condition.

[0076] Response manager 1000 may also include a memory device 1020 coupled to main processor 1010. Memory device 1020 may be configured to store data, firmware and software programs therein. For example, memory device 1020 may store vehicle data 1021 pertaining to the respective vehicle and individual data 1022 pertaining to the one or more occupants of the respective vehicle.

[0077] In some embodiments, the one or more processors of response manager 1000 may also include a graphics processor 1050 coupled to main processor 1010. Additionally, response manager 1000 may include a display device 1060 coupled to graphics processor 1050. Display device 1060 may receive data to be displayed from graphics processor 1050.

[0078] In the above disclosure, reference has been made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration specific implementations in which the present disclosure may be practiced. It is understood that other implementations may be utilized and structural changes may be made without departing from the scope of the present disclosure. References in the specification to "one embodiment," "an embodiment," "an example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0079] Implementations of the systems, apparatuses, devices, and methods disclosed herein may comprise or utilize a special purpose or general-purpose computer including computer hardware, such as, for example, one or more processors and system memory, as discussed herein. Implementations within the scope of the present disclosure may also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer system. Computer- readable media that store computer-executable instructions are computer storage media (devices). Computer-readable media that carry computer-executable instructions are transmission media. Thus, by way of example, and not limitation, implementations of the present disclosure can comprise at least two distinctly different kinds of computer-readable media: computer storage media (devices) and transmission media.

[0080] Computer storage media (devices) includes RAM, ROM, EEPROM, CD-ROM, solid state drives ("SSDs") (e.g., based on RAM), Flash memory, phase-change memory ("PCM"), other types of memory, other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.

[0081] An implementation of the devices, systems, and methods disclosed herein may communicate over a computer network. A "network" is defined as one or more data links that enable the transport of electronic data between computer systems and/or modules and/or other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a transmission medium. Transmissions media can include a network and/or data links, which can be used to carry desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. Combinations of the above should also be included within the scope of computer- readable media.

[0082] Computer-executable instructions comprise, for example, instructions and data which, when executed at a processor, cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.

[0083] Those skilled in the art will appreciate that the present disclosure may be practiced in network computing environments with many types of computer system configurations, including, an in-dash vehicle computer, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, tablets, pagers, routers, switches, various storage devices, and the like. The disclosure may also be practiced in distributed system environments where local and remote computer systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks. In a distributed system environment, program modules may be located in both local and remote memory storage devices. [0084] Further, where appropriate, functions described herein can be performed in one or more of: hardware, software, firmware, digital components, or analog components. For example, one or more application specific integrated circuits (ASICs) can be programmed to carry out one or more of the systems and procedures described herein. Certain terms are used throughout the description and claims to refer to particular system components. As one skilled in the art will appreciate, components may be referred to by different names. This document does not intend to distinguish between components that differ in name, but not function.

[0085] It should be noted that the sensor embodiments discussed above may comprise computer hardware, software, firmware, or any combination thereof to perform at least a portion of their functions. For example, a sensor may include computer code configured to be executed in one or more processors, and may include hardware logic/electrical circuitry controlled by the computer code. These example devices are provided herein purposes of illustration, and are not intended to be limiting. Embodiments of the present disclosure may be implemented in further types of devices, as would be known to persons skilled in the relevant art(s).

[0086] At least some embodiments of the present disclosure have been directed to computer program products comprising such logic (e.g., in the form of software) stored on any computer useable medium. Such software, when executed in one or more data processing devices, causes a device to operate as described herein.

[0087] While various embodiments of the present disclosure have been described above, it should be understood that they have been presented by way of example only, and not limitation. It will be apparent to persons skilled in the relevant art that various changes in form and detail can be made therein without departing from the spirit and scope of the present disclosure. Thus, the breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents. The foregoing description has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the present disclosure to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. Further, it should be noted that any or all of the aforementioned alternate implementations may be used in any combination desired to form additional hybrid implementations of the present disclosure.

[0088] What is claimed is: