Multi-sensor life detection within a vehicle

Abstract

Sensor data can be collected from a first set of sensors (165) associated with a first seat (210) within the vehicle (135) during a first vehicle phase. The output of each sensor in the first set of sensors (165) can be aggregated to compute a probability of life within the first seat (210) during the first vehicle phase.

Description

BACKGROUND

[0001] The present invention relates generally to the field of vehicle safety, and in particular to multi-sensor life detection within a vehicle.

[0002] The temperature inside a vehicle can quickly rise when not in motion, even on days when the temperature seems mild. Being left in a confined space where the temperature quickly rises can be fatal, especially for young children. Most hot car deaths are accidental, occurring when a caregiver forgets their child in the backseat.

[0003] There are several market solutions for preventing children from being accidentally left in a vehicle, but they are often limited because they require a caregiver to pre-emptively purchase and install. Likewise, vehicle manufacturers have begun implementing single-sensor backseat detection systems, the ability of which to accurately detect life without false positives under all conditions is limited. In sum, what the existing solutions to this problem lack is that they are generally 1) must be purchased and installed separately, 2) only apply to children in car seats, 3) collect insufficient data (e.g., from a single sensor) leading to inaccurate predictions, 4) only issue alerts based on sequential conditions being met, and / or 5) only active during the end-vehicle phase after the vehicle has already been turned off. SUMMARY

[0004] Embodiments of the present invention are directed to a method for life detection within a vehicle. The method can include collecting sensor data from a first set of sensors associated with a first seat within the vehicle during a first vehicle phase. The method can also include aggregating an output of each sensor in the first set of sensors to compute a probability of life within the first seat during the first vehicle phase.

[0005] Advantageously, the above-described method allows for life detection within a vehicle using multiple sensors associated with the vehicle. As such, aspects do not require separate purchase and installation as pre-existing solutions in the art. Furthermore, aspects of the present invention are not limited to a particular seat within the vehicle. Moreover, by collectively considering sensor data received by multiple sensors within the vehicle, a probability of life can be more accurately computed, while reducing false positives and false negatives that are readily apparent in simple one-sensor systems.

[0006] Other aspects of the present invention are directed to systems and computer program products configured to perform the above-described method.

[0007] Embodiments of the present invention relate to an additional method for life detection within a vehicle. The method includes collecting sensor data from each of a plurality of sets of sensors during a first vehicle phase, each set of sensors being associated with each of a plurality of respective seats within the vehicle. The method further includes aggregating the output of each sensor in each respective set of sensors to calculate a probability of life for each seat within the vehicle during the first vehicle phase. The method further includes aggregating the probability of life for each seat to calculate a probability of life for the entire vehicle during the first vehicle phase. The method further includes calculating a probability of life throughout at least two phases of the vehicle by aggregating the probability of life for the entire vehicle during the first vehicle phase with the probability of life for the entire vehicle during at least one additional vehicle phase.

[0008] Advantageously, the above-described method allows for life detection within a vehicle using a plurality of sensors associated with the vehicle. Accordingly, aspects do not require separate purchase and installation as pre-existing solutions in the prior art. Further, aspects of the present invention are not limited to specific seats within a vehicle. Further, by collectively considering sensor data received by a plurality of sensors within a vehicle, a probability of life can be more accurately calculated while reducing false positives and false negatives that are readily apparent in simple one-sensor systems. Further, aspects allow for calculation of a probability of life throughout individual vehicle phases for a single seat or multiple seats. Accordingly, a probability of life can be calculated throughout all phases of a vehicle, providing a more comprehensive and accurate calculation of life detection.

[0009] Additional aspects of the present invention are directed to computer program products configured to perform the above-described additional method.

[0010] The above summary of the present invention is not intended to describe each illustrated embodiment or every implementation of the present invention. BRIEF DESCRIPTION OF DRAWINGS

[0011] The accompanying drawings included in the present disclosure are incorporated into and form part of the specification. They illustrate embodiments of the invention and, together with the specification, serve to explain the principles of the invention. The drawings are only typical embodiments' illustrations and do not limit the invention.

[0012] Figure 1 is a block diagram illustrating an example computing environment in which an illustrative embodiment of the present invention can be implemented.

[0013] Figure 2 is a diagram depicting two exemplary vehicle sensor configurations in accordance with embodiments of the present invention.

[0014] Figure 3 is a diagram depicting sensor output over time across two vehicle phases in accordance with embodiments of the present invention.

[0015] Figure 4is a graph depicting life probability computation for individual seats within a vehicle according to embodiments of the application.

[0016] Figure 5 is a graph depicting life probability computation for an entire vehicle across multiple vehicle stages according to embodiments of the application.

[0017] Figure 6A and Figure 6B is a flowchart collectively depicting an example method for computing life probability within a vehicle according to embodiments of the application.

[0018] Figure 7 is a flowchart depicting an example method for determining a vehicle stage according to embodiments of the application.

[0019] Figure 8 is a flowchart depicting an example method for issuing life protection actions based on life probability computation according to embodiments of the application.

[0020] Figure 9 is a diagram illustrating a cloud computing environment according to embodiments of the application.

[0021] Figure 10 is a block diagram illustrating an abstraction model layer according to embodiments of the application.

[0022] Figure 11 is a high-level block diagram illustrating an example computer system that can be used to implement one or more methods, tools, modules, and any related functionality described herein according to embodiments of the application.

[0023] While embodiments described herein can have various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the specific DETAILED DESCRIPTION

[0024] Aspects of the present application relate generally to the field of vehicle safety, and particularly to multi-sensor life detection within a vehicle. While the present application is not necessarily limited to such applications, various aspects of the application can be understood with reference to this context.

[0025] The temperature inside a vehicle can quickly rise when not in motion, even on days when the temperature seems mild. Being left in a confined space where the temperature quickly rises can be deadly, especially for young children. Most hot car deaths are accidental, occurring when a caregiver forgets their child in the backseat.

[0026] There are several market solutions for preventing children from being accidentally left in vehicles, but they are often limited in that they require the caregiver to pre-emptively purchase and install. Likewise, vehicle manufacturers have begun implementing single-sensor backseat detection systems, the ability of which to accurately detect life without false positives under all conditions is limited. In sum, what the existing solutions to this problem lack is that they are often 1) must be purchased and installed separately, 2) only apply to children in car seats, 3) collect insufficient data (e.g., from a single sensor) leading to inaccurate predictions, 4) only issue alerts based on sequential conditions being met, and / or 5) only active during the end-vehicle phase after the vehicle has already been turned off.

[0027] Aspects of the present invention solve the above complex problems using a multi-sensor life detection system. Sensor data can be collected during a first vehicle phase (e.g., the exemplary vehicle phase depicted in FIG. 1) from a first set of sensors associated with a first seat within the vehicle. The output of each sensor can then be aggregated to calculate a probability of life (e.g., a probability of the presence of life such as a human or animal) within the first seat during the first vehicle phase. Figure 7

[0028] In embodiments, additional sensor data can be collected during the first vehicle phase from each of a plurality of sets of sensors, each set associated with each of a plurality of respective seats within the vehicle. The output of each sensor in each respective set of sensors can be aggregated to calculate a probability of life for each seat within the vehicle during the first vehicle phase. Thereafter, in embodiments, the probability of life for each seat during the first vehicle phase can be aggregated to calculate a probability of life for the entire vehicle during the first vehicle phase.

[0029] In embodiments, a probability of life throughout at least two phases of the vehicle can be calculated by aggregating the probability of life for the entire vehicle during the first vehicle phase with the probability of life for the entire vehicle during at least one additional vehicle phase.

[0030] ​Various benefits are realized through the above-described embodiments. First, the solution can be fully integrated with the vehicle. Thus, aspects do not need to be purchased and installed separately as with pre-existing solutions in the prior art. Further, aspects of the present invention are not limited to a particular seat within the vehicle (e.g., a seat having a car seat installed in the car). Aspects of the present invention allow for detection of life in any individual seat within the vehicle, regardless of the seating configuration. Further, aspects of the present invention can calculate a probability of life throughout various vehicle stages. Thus, the probability of life can be calculated throughout all stages of the vehicle, providing a more comprehensive and accurate calculation of life detection. Further, by collectively considering sensor data received by multiple sensors within the vehicle, the probability of life can be more accurately calculated, while reducing false positives and false negatives that are evident in simple one-sensor systems.

[0031] Turning now to the drawings, Figure 1 is a block diagram illustrating an example computing environment 100 in which illustrative embodiments of the present invention can be implemented. The computing environment 100 includes a plurality of devices 105-1, 105-2,..., 105-N (collectively referred to as devices 105), at least one vehicle 135, and a network 150.

[0032] The devices 105 and the vehicle 135 include one or more processors 115-1, 115-2,..., 115-N (collectively referred to as processors 115) and processor 145, respectively, and one or more memories 120-1, 120-2,..., 120-N (collectively referred to as memories 120) and memory 155, respectively. The devices 105 and the vehicle 135 can be configured to communicate with each other through internal or external network interfaces 110-1, 110-2,..., 110-N (collectively referred to as network interfaces 110) and network interface 140. In some embodiments, the network interfaces 110 and 140 are modems or network interface cards. The devices 105 and / or the vehicle 135 can be equipped with displays. Additionally, the devices 105 and / or the vehicle 135 can include optional input devices (e.g., keyboards, mice, scanners, biometric scanners, video cameras, or other input devices), and / or any commercially available or custom software (e.g., browser software, communication software, natural language processing software, search engine and / or web crawler software, image processing software, etc.). In embodiments, the devices 105 can be mobile devices, wearable devices, laptops, etc. The vehicle 135 can be any suitable vehicle configured to transport an individual from a starting location to a destination, including a car, a truck, a bus, an airplane, a boat, etc. In some embodiments, the vehicle 135 can be semi-autonomous or fully autonomous.

[0033] Device 105 and vehicle 135 can be remote from each other and communicate through network 150. In some embodiments, a server (not shown) can be a central hub from which device 105 and vehicle 135 can establish a communication connection, such as in a client-server networking model. Alternatively, vehicle 135 and device 105 can be configured in any other suitable networking relationship (e.g., in a peer-to-peer (P2P) configuration or using any other network topology).

[0034] In some embodiments, network 150 can be implemented using any number of any suitable communication media. For example, network 150 can be a wide area network (WAN), a local area network (LAN), the Internet, or an intranet. In certain embodiments, device 105 and vehicle 135 can be local to each other and communicate via any suitable local communication medium. For example, device 105 and vehicle 135 can communicate using a local area network (LAN), one or more hardwired connections, a wireless link, or a router or intranet. In some embodiments, device 105 and vehicle 135 can be communicatively coupled using a combination of one or more networks and / or one or more local connections. For example, a first device 105-1 can be hardwired to vehicle 135 (e.g., connected with an Ethernet cable), while a second device 105-2 can communicate with vehicle 135 using network 150 (e.g., over the Internet).

[0035] In some embodiments, network 150 is implemented within a cloud computing environment or using one or more cloud computing services. According to various embodiments, a cloud computing environment can include a network-based distributed data processing system that provides one or more cloud computing services. Further, a cloud computing environment can include a number of computers (e.g., hundreds or thousands of computers or more) arranged within one or more data centers and configured to share resources over network 150. In some embodiments, network 150 can be substantially similar to or the same as cloud computing environment 50 described in Figure 9

[0036] Vehicle 135 includes a life detection application 160. Life detection application 160 can be configured to determine a probability of life within vehicle 135. In embodiments, a probability of life can be calculated for each seat (e.g., seat 210 of vehicle 135) and / or for a particular vehicle stage (e.g., a vehicle stage 220). Figure 2 Figure 7 ​​The life probability within each seat and / or specific vehicle stage can be aggregated (e.g., collectively considered) to compute a life probability within the vehicle throughout the various vehicle stages. The determination output by the life detection application 160 can be sent to the device 105 over a network. This allows the user to take action to mitigate any risk to life within the vehicle 135. In some embodiments, one or more features of the vehicle 135 can be activated in response to the life probability exceeding a threshold. For example, in response to determining that the life probability exceeds a threshold when the vehicle 135 is not in motion, the vehicle 135 can be powered on and an air conditioner (A / C) can be activated, windows can be opened, doors can be unlocked, and / or doors can be opened. Alerting and / or activating vehicle features to attempt to support life within the vehicle is referred to herein as a “life protection action.”

[0037] The sensors 165 of the vehicle 135 can be configured to collect data about conditions in the environment of the vehicle 135. Various vehicle sensors 165 can be implemented, including but not limited to weight sensors, motion sensors (e.g., optical-based motion sensors), temperature sensors, audio / video system sensors, microphones, cameras, door sensors, window sensors, seatbelt sensors, and lock sensors. In embodiments, the sensors 165 can be configured to collect data periodically (e.g., based on a polling frequency) and / or in response to a state change. For example, a motion sensor can be configured to collect data periodically (e.g., every 10 seconds), while a lock sensor can be configured to collect data when a state changes (e.g., a lock transitions from locked to unlocked, or vice versa).

[0038] In embodiments, the sensors 165 can be associated with a particular seat or the entire vehicle. For example, lock sensors, window sensors, seatbelt sensors, and door sensors can be associated with a first seat, while temperature sensors and motion sensors can collect data about the state of the entire vehicle. Thus, when computing a life probability for each seat within the vehicle 135, the life probability for each seat can consider the respective seat sensors and the vehicle- inclusive sensors, which collect data about the state of the entire vehicle.

[0039] In embodiments, the metrics collected from sensors 165 used to calculate the probability of life are weighted based on values collected from other sensors and / or based on the phase of the vehicle. For example, audio / video (A / V) system sensors (e.g., sensors configured to detect whether the vehicle 135 is currently emitting audio through speakers) can influence the weight of the microphone on the probability of life calculation, as the A / V system can emit sounds that are received by the microphone (thus potentially negatively impacting the microphone’s ability to detect life). As another example, motion sensor data can be weighted differently based on the phase of the vehicle (e.g., motion sensors can be weighted more heavily when the vehicle is stopped than when the vehicle is moving).

[0040] Based on the polling and / or state changes, the output collected from sensors 165 over time can be aggregated to calculate the probability of life for each respective seat within the current vehicle phase. The probability of life for each respective seat within the current vehicle phase can then be aggregated to calculate the probability of life within the entire vehicle within the current vehicle phase. The probability of life within the current vehicle phase can then be propagated (e.g., considered in the future) when calculating the probability of life within the next vehicle phase. Thus, the probability of life within all phases of the entire vehicle can take into account the probability of life within each seat as well as the probability of life calculations for vehicle 135 within previous vehicle phases.

[0041] In embodiments, the weighting of sensor data used to calculate the probability of life within vehicle 135 can be fine-tuned, for example, using a machine learning algorithm. That is, feedback can be received as to whether there is an actual life within the vehicle when calculating the probability of life. Based on the received feedback as compared to the probability of life calculations, the weights of the individual sensor values used to calculate the probability of life can be adjusted. This can be iterated continuously to increase the accuracy of the probability of life calculations by ensuring that the sensor data output receives the appropriate weighting when calculating the probability of life within vehicle 135.

[0042] The machine learning algorithm that can be used to adjust the weights of sensors 165 used to calculate the probability of life within vehicle 135 can include, but is not limited to, decision tree learning, association rule learning, artificial neural networks, deep learning, inductive logic programming, support vector machines, clustering, Bayesian networks, reinforcement learning, representation learning, similarity / metric learning, sparse dictionary learning, genetic algorithms, rule-based learning, and / or other machine learning techniques.

[0043] For example, the machine learning algorithm can utilize one or more of the following example techniques: K-Nearest Neighbors (KNN), Learning Vector Quantization (LVQ), Self-Organizing Map (SOM), logistic regression, Ordinary Least Squares Regression (OLSR), linear regression, stepwise regression, Multivariate Adaptive Regression Splines (MARS), ridge regression, Least Absolute Shrinkage and Selection Operator (LASSO), elastic net, Least Angle Regression (LARS), probabilistic classifiers, Naive Bayes classifier, binary classifier, linear classifier, hierarchical classifier, Canonical Correlation Analysis (CCA), Factor Analysis, Independent Component Analysis (ICA), Linear Discriminant Analysis (LDA), Multidimensional Scaling (MDS), Nonnegative Matrix Factorization (NMF), Classification and Regression Tree (CART), Chi-squared Automatic Interaction Detection (CHAID), Expectation-Maximization algorithm, feed-forward neural network, logistic learning machine, self-organizing map, single-linkage clustering, fuzzy clustering, hierarchical clustering, Boltzmann machine, convolutional neural network, recurrent neural network, Hierarchical Temporal Memory (HTM), and / or other machine learning techniques.

[0044] Although Figure 1 The life detection application 160 is depicted as integrated with the vehicle 135, in embodiments, aspects of the life detection application 160 can be remotely located (e.g., stored on a server or device 105). In these embodiments, the vehicle 135 can transmit sensor data over the network 150 for processing.

[0045] Note, Figure 1 The representative major components are intended to depict a representative example computing environment 100. However, in some embodiments, the various components can have greater or lesser complexity than Figure 1 depicted in FIG. 1, different components than those shown in FIG. 1, and / or variations thereof, and the number, types, and configurations of these components can vary. Figure 1 Moreover, the various models, modules, systems, and components shown in FIG. 1 can exist on a plurality of devices, servers, and / or vehicles, if at all. Figure 1

[0046] Referring now to Figure 2 , a schematic diagram of two vehicle sensor configurations is shown, in accordance with embodiments of the present application. The first vehicle 205 configuration includes sensors associated with first seat 210 through fifth seat 230. The second vehicle 235 configuration includes sensors associated with first seat 240 through fifth seat 260, and also includes a vehicle-enclosure sensor (e.g., a sensor such as a vehicle motion sensor and / or temperature sensor, which can collect data about the state of the entire vehicle). Note, Figure 2 ​The vehicle and sensor configurations shown (e.g., the number of seats, the number of sensors per seat, and the type of sensors) are merely exemplary and any suitable vehicle and / or sensor configuration can be implemented.

[0047] Such as about Figure 2 The "Y" discussed n "A sensor is a sensor that outputs data when its state changes (e.g., door sensor, window sensor, seatbelt sensor, lock sensor, etc.)." m "A sensor refers to a sensor that periodically outputs data (e.g., motion sensors, microphones, weight sensors, etc.)." rc "This refers to the location of a given sensor within the vehicle, based on the seat." rc The "r" identifier within the quotation marks indicates the row number of sensors from the front to the rear of the vehicle. "L" rc The "c" identifier within the text refers to the column number of sensors from the left to the right side of the vehicle. Therefore, the L sensor associated with the first seat 210 of the first vehicle 205... 11 The Y1 sensor refers to the first state change sensor located in the first row and first column. Similarly, the L sensor associated with the first seat 210 of the first vehicle 205... 11 The X1 sensor refers to the first periodic sensor located in the first row and first column. It is symbolized by "L". r0 The term "sensor" refers to a sensor that collects the output of the entire vehicle. As shown in vehicle 235, sensor L... 10 X 1-5 This refers to the sensor located in the first row that collects the output of the entire vehicle; sensor L 30 X 1-5 This refers to the sensor located in the third row that collects the output of the entire vehicle.

[0048] Now for reference Figure 3 The illustration depicts a scene from the first vehicle stage “S” according to an embodiment of the invention. p "and the second vehicle phase "S p+1 Figure 300 shows the sensor output of samples over time. Note that... Figure 3 The sensor outputs depicted are merely exemplary, and any suitable sensor outputs can be collected over any suitable time range and / or number of vehicle phases.

[0049] like Figure 3 As shown, at each time interval d (e.g., based on the polling frequency), from L r0 X m and L rc X m The sensor collects data. Therefore, L can be collected at t0, t2, t4, etc.r0 X m and L rc X m Sensor data (e.g., at each interval d). At each state change, data can be obtained from the applicable L... rc Y n Sensor collects L rc Y n Sensor data. For example... Figure 3 As shown, L was collected at t1 and t5. rc Y n Sensor data. From the first vehicle stage S p Transition to the second vehicle phase S p+1 After that, at time t g It can collect data from all applicable sensors L r0 X m L rc X m and L rc Y n The output of L. Afterwards, L can be collected every d intervals. r0 X m and L rc X m Sensor data, and can continue to be collected when applicable state changes. rc Y n Sensor data.

[0050] Now for reference Figure 4 Figure 400 illustrates an example survival probability calculation for seats in a vehicle at different times during two vehicle phases, according to an embodiment of the present invention. Figure 4 As shown, at time t3, given seat "P rc The probability of a person's life is represented by P. rc (S p ,t3,L rc [X M |Y N ],L r0 X M In this expression, S p t3 represents the vehicle phase, t3 represents time, and L represents the vehicle phase. rc [X M |Y N ] represents all L rc X m and L rc Y n The collection of sensor outputs, and L r0 X M Represents all L r0 X m The set of outputs. In this expression, each sensor value (e.g., L) is...rc X M , L rc Y n or L r0 X m The value) can represent a probability of life, which can represent, for example, between 0 and 1, where 0 represents a minimum confidence of a probability of life and 1 represents a maximum confidence of a probability of life within a given seat. As described above, the values output by the individual sensors can be weighted based on other sensor values and / or vehicle phase S p P rc (S p , t3, L rc [X M | Y N ], L r0 X M ) represents a collective consideration of all sensor outputs for a given seat at t3 during vehicle phase S P

[0051] At t g , the outputs of all applicable sensors L r0 X m , L rc X m , and L rc Y n may be collected. The probability of life P g for a seat in the vehicle at time t rc is then represented as P rc (S p , t g , L rc [X M | Y N ], L r0 X M ). This represents the probability of life for a given seat during the entire first vehicle phase S p At time t g+4 , the probability of life P p+1 for a given seat during the second vehicle phase S rc is represented by P rc (S p+1 , t g+4 , L rc [X M | Y N ], L r0 X M ).

[0052] Referring now to Figure 5 , a graph 500 illustrating an example probability of life calculation describing an entire vehicle by collectively considering all probability of life calculations for individual seats within the vehicle at different times according to embodiments of the present application is shown. ​

[0053] like Figure 5 As shown, the life probabilities of the first and second seats at time t3 are respectively expressed as P. 11 (S p ,t3,L rc [X M |Y N ],L r0 X M ) and P 12 (S p ,t3,L rc [X M |Y N ],L r0 X M Then, the survival probabilities of the first and second seats can be considered together (e.g., summed) to obtain the overall vehicle P(S). p ,t3,P RC (S p ,t3),P -1 The probability of survival for the entire vehicle. In this expression, P represents the probability of survival for the entire vehicle, and S... p t3 represents the vehicle phase, t3 represents time, and P represents the time phase. RC (S p , t g ) indicates the vehicle phase S p The probability of survival (P0) of all legally available seats (e.g., seats with seat belts) at time t3 during the period. 11 (S p ,t3,L rc [X M |Y N ], L r0 X M ) and P 12 (S p ,t3,L rc [X M |Y N ], L r0 X M And P -1 This represents the vehicle's previous life probability calculation (e.g., calculated during a previous time or phase). Therefore, when calculating the overall vehicle life probability at a given time during a given vehicle phase, the life probability calculated for each corresponding seat, as well as the previously determined overall vehicle life probability, can be considered together. Figure 5 As shown, P(S) p ,t g ,P RC (S p ,t g ),P -1 ) indicates that at t g Located in Sp The overall vehicle life probability, P(S p+1 , t g+4 , P RC (S p+1 , t g+4 , P -1 ) represents the overall vehicle life probability at t p+1 during phase S g+4 .

[0054] Reference is now made to Figure 6A and Figure 6B showing flowcharts collectively illustrating a method 600 for calculating life probabilities for individual seats, individual vehicle phases, and overall vehicle life probabilities over individual vehicle phases, according to embodiments of the present application. Figure 6A - Figure 6B One or more operations described in the detailed description can be completed by one or more computing devices (e.g., vehicle 135, device 105, or a server).

[0055] Method 600 begins at operation 605, where sensor data is collected from all sensors of the vehicle during the current vehicle phase. The current output of all sensors can be initially collected at any suitable time. For example, the collection can be initiated in response to a user request, in response to a vehicle phase transition, or in response to any other suitable predetermined trigger (e.g., a particular time, a particular location, etc.). As described above, various vehicle sensors can be implemented, including but not limited to weight sensors, motion sensors (e.g., optical-based motion sensors), temperature sensors, audio / video system sensors, microphones, video cameras, door sensors, window sensors, seatbelt sensors, and lock sensors. Thereafter, the collection of sensor data can continue based on a polling frequency (e.g., within a predetermined time period), based on a state change, or based on a vehicle phase transition.

[0056] It is then determined whether a state change occurred for any state change sensors. This is shown at operation 610. State change sensors can include sensors that change from a first state to a second state. Example state change sensors include door lock sensors (with locked and unlocked states), window sensors (with open and closed states), door sensors (with open and closed states), seatbelt sensors (with buckled and unbuckled states), and A / V system sensors (with on and off states). In embodiments, the state change can be binary, with two possible states. However, in embodiments, the state change can be partial (e.g., volume change of an A / V system, partially open window, etc.).

[0057] If a state change is determined to have occurred in any state change sensor, an output is collected from the single state change sensor that changed state. This is illustrated at operation 615. Therefore, state change sensor data can be continuously collected throughout method 600 in response to any state change of the state of the state change sensor. Figure 3 As shown, at times t1, t5, t g and t g+2 Collect data from state change sensor Y rc Y n The data.

[0058] Then it is determined whether the polling frequency has been reached for any polled sensor. This is illustrated at operation 620. Polling sensors may include sensors from which sensor data is collected periodically. Example polling sensors include motion sensors, temperature sensors, weight sensors, cameras, and microphones. The polling frequency of each sensor can vary. For example, sensor data from a first polling sensor (e.g., a camera) may be collected at a first time interval (e.g., per second), and sensor data from a second polling sensor (e.g., a temperature sensor) may be collected at a second time interval (e.g., per minute).

[0059] If it is determined that the polling frequency has been reached for any polled sensor, then sensor output is collected for any individual polled sensor whose polling frequency has been reached. This is illustrated at operation 625. Therefore, in response to any polled sensor reaching the corresponding polling frequency, polled sensor data can continue to be collected throughout method 600. Figure 3 As shown, at t0, t2, t4, t g+1 t g+3 and t g+4 Every d time intervals, data is collected from the polled sensor X. rc X m The data.

[0060] In an embodiment, when collecting sensor data, the sensor data outputs can be processed into values ​​indicating the probability of survival. For example, values ​​from weight sensors, motion sensors, locking sensors, etc., can be processed into values ​​between 0 and 1, where 0 indicates the minimum confidence level of the probability of survival, and 1 indicates the maximum confidence level of the probability of survival. As an example, if the weight sensor value output for a given seat is, for example, 50 pounds, that 50-pound value can be processed into an output of "0.75," representing a high confidence level of the probability of survival. However, relying on this single sensor value may be inaccurate, as the weight applied to the seat may not be necessary for survival. Therefore, the weight sensor values ​​can be weighted and summed with other sensor value outputs to accurately predict the probability of survival. Finally, each sensor output can be processed into a standardized value so that the sensor values ​​can be summed to calculate the probability of survival for each seat in the vehicle.

[0061] Then it is determined whether there is a request for the probability of life from a user. This is shown at operation 630. In embodiments, the request may be received from the user on a graphical user interface (GUI) of the device or vehicle. For example, a user request for the probability of life may be received on a graphical user interface associated with the life detection application 160 on vehicle 135 or on a display of device 105-1; however, in some embodiments, the request may not be initiated by the user but may be issued automatically based on a predetermined trigger. For example, the probability of life may be automatically requested in response to vehicle triggers (such as a door opening, a window opening, a change in seatbelt status) (e.g., via one or more processing circuits of the vehicle). If it is determined that there is a request for the probability of life within the vehicle, method 600 proceeds to operation 640. Figure 6B If it is determined that there is no request for a life probability within the vehicle, method 600 proceeds to operation 635, where it is determined whether the vehicle should transition to the next vehicle phase.

[0062] If it is determined that the vehicle is to be transitioned to the next vehicle stage, then method 600 proceeds to... Figure 6B Operation 640. If it is determined that the vehicle has not transitioned to the next vehicle phase, method 600 returns to operation 610, where it is determined whether a state change has occurred for any state change sensor. Therefore, within the current vehicle phase (e.g., between operations 610 and 635), sensor data can be continuously collected at operations 615 and 625, where applicable. Figure 7 The example triggering of vehicle phase transitions is described in the text.

[0063] Now for reference Figure 6B If, in operation 630, it is determined that there is a request for a life probability, or if, in operation 635, a vehicle transition phase is determined, method 600 proceeds from operation 640 to operation 645, wherein, in total, Figure 6AThe output of sensors collected in the vehicle is used to calculate the survival probability of each seat during the current vehicle phase. For example, as Figure 4 As shown, P can be calculated for each corresponding seat. rc (S p ,t,L rc [X M |Y N ], L r0 X M As mentioned above, each individual sensor L r0 X M L rc X M and / or L rc Y n The output can be processed into values ​​between 0 and 1, where 0 represents the minimum confidence level of the survival probability and 1 represents the maximum confidence level. Furthermore, each value can be weighted according to the sensor type, the outputs of other sensors, and / or the current vehicle stage. Aggregating the individual sensors to calculate the survival probability for the corresponding seat may include multiplying the sensor output of each processed sensor by each corresponding weight and summing the results.

[0064] Then, sum up for each corresponding seat "P" within the current vehicle phase. rc "The calculated life probability is used to calculate the probability of the entire vehicle within the current vehicle phase. This is shown at operation 650. For example, as..." Figure 5 As shown, P corresponding to the first and second seats can be totaled. 11 (S p ,t,L rc [X M |Y N ], L r0 X M ) and P 12 (S p ,t,L rc [X M |Y N ], L r0 X M To calculate the overall vehicle survival probability P(S) p ,t,P RC (S p ,t)), where P RCrepresents the aggregate life probability between the first seat and the second seat. Any suitable aggregation technique can be used to compute the life probability for the entire vehicle, including applying a mean, maximum, minimum, and / or median value to the dataset of life probabilities for each individual seat. For example, if the life probability output for the first seat is "1.0" and the life probability output for the second seat is "0.5," if there are only two seats in the vehicle, the aggregate life probability can include computing a mean (e.g., 0.75), maximum (e.g., 1.0), minimum (e.g., 0.50), or median (e.g., 1.0 or 0.50) of the two life probabilities for each respective seat.

[0065] The life probability computed for the entire vehicle for the current vehicle phase is then propagated as input data to the next vehicle phase. This is shown at operation 655. Thus, the future life probability for the entire vehicle can be computed as P(S p ,t,P RC (S p ,t),P -1 ) where P -1 represents the life probability computed for the previous vehicle phase. Thus, the life probability for the entire vehicle for the current vehicle phase computed at operation 650 can be stored in memory and used at a future time to increase the accuracy of future life probability computations within future vehicle phases.

[0066] It is then determined whether there is a previous vehicle phase. This is shown at operation 660. If it is determined that there is a previous vehicle phase, the life probability for the entire vehicle for each vehicle phase is aggregated to obtain a life probability within the entire vehicle across all considered phases. This is shown at operation 665. Thus, the life probability of the previous vehicle phase stored at operation 655 is propagated as input data into the life probability computation for the entire vehicle across multiple phases. For example, as depicted in Figure 5 , P(S p+1 ,t,P RC (S p+1 ,t),P -1 ) considers the life probability P P computed at a previous time and / or phase (e.g., phase S -1 or time t5).

[0067] The life probabilities computed for individual seats at operation 645, the life probabilities computed for the entire vehicle at operation 650 for a particular vehicle phase, and / or the life probabilities for the entire vehicle across multiple considered phases at operation 665 can be sent to a user at any suitable time. For example, upon computing the life probabilities, the life probabilities can be sent to a user so that they can be aware of the life status within their vehicle. As an example, when a vehicle transitions from a "driving and parking phase" to a "non-driving and driving off phase," the life probabilities for each respective phase can be sent to a user at the beginning of each respective vehicle phase.

[0068] In embodiments, if the life probabilities for individual seats, the entire vehicle, and / or multiple phases of the entire vehicle exceed a threshold, a life protection action can be performed (e.g., by the life detection application 160). The life protection action can include sounding an alarm (e.g., notifying a device 105, calling a user, calling a monitoring station, etc.) and activating a vehicle feature (e.g., activating a vehicle alarm, automatically opening a door, activating an air conditioning system, automatically opening a window, automatically opening a door, etc.). Such actions can prevent or mitigate a danger caused by a temperature increase within a vehicle. Reference is made to Figure 8 Sounding a life protection action is further described.

[0069] In embodiments, feedback can be collected regarding the life probability computations output at operations 645, 650, and 665. The feedback can indicate whether an actual life was present in a particular vehicle seat during a particular vehicle phase, in the entire vehicle during a particular vehicle phase, and / or in the entire vehicle across multiple considered phases. Based on a comparison between the received feedback and the life probabilities, the weights of the values used to compute the life probabilities can be adjusted. In embodiments, one or more machine learning algorithms can be configured to make adjustments to the weights based on the received feedback so that more accurate life probability computations can be made in the future. As an example, if a first seat has a life probability of "1.0" (e.g., indicating a maximum life probability) during a first vehicle phase and the feedback indicates that a life was not present in the vehicle, the weighting of a first sensor value used to compute the life probability of the first seat during the first vehicle phase can be changed (e.g., reduced using a machine learning algorithm).

[0070] The above-described operations can be completed in any order, and are not limited to those described. Additionally, some, all, or none of the above-described operations can be completed while still remaining within the scope of the present disclosure. For example, in some embodiments, the state change sensor data can not be collected at operation 615 if the life probability computation does not consider state change sensors. As another example, in some embodiments, operations 650 and / or 665 can not be completed as the life probability computation can be computed based on each seat alone.

[0071] Reference is now made toFigure 7 FIG. 7 shows a flowchart illustrating an exemplary method 700 for determining a vehicle phase of a vehicle, in accordance with embodiments of the present application. Figure 7 One or more operations described above can be completed by one or more computing devices (e.g., device 105, vehicle 135, and / or a server). Referring to FIG. 1, the one or more computing devices can include device 105, vehicle 135, and / or server 140. Figure 7 The vehicle phases described above can be the same as or substantially similar to the vehicle phases described above with reference to FIG. 6. Figure 1 - Figure 6B

[0072] Method 700 begins at operation 705, where it is determined whether the ignition state of the vehicle is "on" or "off." If the ignition state is "off," it is determined that the vehicle is in a parked and not traveling phase (SI). This is shown at operation 710.

[0073] If it is determined that the ignition state is "on," it is determined whether the gear is engaged in park "P" or neutral, reverse, or forward "N / R / D." If the gear is engaged in park "P," it is determined that the vehicle is in a parked and traveling phase (S2). This is shown at operation 720.

[0074] If it is determined that the gear is engaged in neutral, reverse, or forward "N / R / D," it is determined whether the vehicle is currently moving. This is shown at operation 725. The determination of whether the vehicle is currently moving can be completed based on accelerometer data, speedometer data, brake data, or any other suitable data indicative of the mobility state of the vehicle. If it is determined that the vehicle is not moving, it is determined that the vehicle is in a traveling and stopped phase (S3). This is shown at operation 730. If it is determined at operation 725 that the vehicle is currently moving, it is determined that the vehicle is in a traveling and moving phase (S4). This is shown at operation 735.

[0075] The operations described above can be completed in any order, and are not limited to those described. Additionally, some, all, or none of the operations described above can be completed while still remaining within the scope of the present application. Furthermore, the vehicle phases described above with reference to FIG. 6 are merely exemplary. Any suitable vehicle phase consistent with the present disclosure can be used without departing from the scope of the present application. For example, the vehicle phases can vary based on the type of vehicle being implemented. Figure 7

[0076] Referring now to FIG. 8, an exemplary method 800 for issuing a life protection action based on a received life probability calculation, in accordance with embodiments of the present application is shown. Figure 8

[0077] Method 800 begins at operation 805, where a life probability calculation is received. The life probability calculation can be any life probability calculation calculated throughout method 600. For example, the life probability calculation can include the life probability calculation calculated at operation 620 of method 600. Figure 6B ​​​those computed at operations 645, 650, and 665. In embodiments, the life probability computation can be received in response to a predetermined condition, such as a vehicle phase transition (e.g., Figure 7 described in the background section), a user request, a vehicle state change (e.g., a door opening), or another condition.

[0078] It is then determined whether the life probability exceeds a threshold. This is shown at operation 810. The threshold can be any suitable value, and can be defined in any suitable manner. For example, the threshold can be 25%, 50%, 75%, etc. A lower threshold can indicate that the system is more cautious (e.g., issuing a life protection action when the life probability is relatively low). In some embodiments, the threshold can be user-defined. In some embodiments, the threshold can be determined using machine learning techniques.

[0079] If the life probability exceeds the threshold, it is determined whether conditions for a life protection action are met. This is shown at operation 815. In some embodiments, a life protection action is always issued if the life probability exceeds the threshold. However, in some embodiments, a life protection action is only issued if certain conditions are met. For example, a life protection action can only be issued if the vehicle is in a particular vehicle phase, the vehicle is at a particular temperature, there is no weight in the driver's seat (e.g., as collected by a weight sensor), the windows and doors are closed, the user device is a predetermined distance from the vehicle (e.g., based on global positioning system (GPS) data, etc.).

[0080] If it is determined that the conditions for a life protection action are met, the life protection action is issued. This is shown at operation 820. The life protection action can include issuing an alert (e.g., notifying device 105, calling the user, calling a monitoring station, etc.) and activating a vehicle feature (e.g., activating a vehicle alarm, automatically opening a door, activating an air conditioning system, automatically opening a window, automatically opening a door, etc.). Such actions can prevent or mitigate the danger caused by the elevated temperature within the vehicle. After the life protection action is issued, method 800 ends.

[0081] The above-described operations can be completed in any order, and are not limited to those described. Additionally, some, all, or none of the above-described operations can be completed, while still remaining within the scope of the present invention. For example, in some embodiments, operation 815 can not be completed, as the life protection action can be automatically issued based on the life probability exceeding the threshold.

[0082] It should be appreciated that while the present invention includes detailed descriptions of cloud computing, implementation of the teachings described herein are not limited to a cloud computing environment. Rather, embodiments of the present invention are capable of implementation in conjunction with any other type of computing environment now known or later developed.

[0083] Cloud computing is a model of service delivery for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g. networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a provider of the service. This cloud model can be composed of at least five characteristics, at least three service models, and at least four deployment models.

[0084] The characteristics are as follows:

[0085] On-demand self-service: cloud consumers can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with the service's provider.

[0086] Broad network access: capabilities are available over a network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0087] Resource pooling: the provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to demand. There is a sense of location independence in that the consumer generally has no control or knowledge over the exact location of the provided resources but can be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter).

[0088] Rapid elasticity: capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out and rapidly scale in. To the consumer, the provider's ability to provision capabilities on-demand and in near real-time allows for rapidly adjusting to changing business demand.

[0089] Measured service: cloud systems automatically control and optimize resource use by leveraging usage-based pricing models for cloud consumers. Consumers can access services from the cloud provider that are measured on a per-use basis, so the more the user consumes, the more they pay. In a public cloud environment, underlying cloud infrastructure, such as servers, storage, or networking - resources, are typically owned and operated by an enterprise itself, a third-party cloud provider, or a combination of both. In the case of the latter, the cloud provider delivers common business applications online that are accessed from a web browser, while the consumer in a private cloud operates and controls the software and possibly its customization on a proprietary network.

[0090] The service models are as follows:

[0091] Software as a Service (SaaS): the capability provided to the consumer is to use the provider's applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based e-mail). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0092] Platform as a Service (PaaS): the capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including networks, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations.

[0093] Infrastructure as a Service (laaS): the capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).

[0094] Deployment models are as follows:

[0095] Private cloud: the cloud infrastructure is operated solely for an organization. It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0096] Community cloud: the cloud infrastructure is shared by several organizations and supports mission-oriented business

[0097] Public cloud: the cloud infrastructure is made available to general public or a large industry group and is owned by an organization selling cloud services.

[0098] Hybrid cloud: the cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together, giving customers the benefit of combined services.

[0099] A cloud computing environment is service-oriented, with a focus on statelessness, loose coupling, modularity, and semantic interoperability. At the core of cloud computing is an infrastructure comprising a network of interconnected nodes.

[0100] Reference is now made to Figure 9The illustration depicts a cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 to which local computing devices used by cloud consumers can communicate. These local computing devices are, for example, personal digital assistants (PDAs) or cellular phones 54A (e.g., device 105), desktop computers 54B, laptop computers 54C, and / or automotive computer systems 54N. The nodes 10 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as private clouds, community clouds, public clouds, or hybrid clouds, or combinations thereof, as described above. This allows the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service, without requiring cloud consumers to maintain resources on their local computing devices. It should be understood that... Figure 9 The types of computing devices 54A-N shown are for illustrative purposes only, and computing node 10 and cloud computing environment 50 can communicate with any type of computerized device on any type of network and / or network-addressable connection (e.g., using a web browser).

[0101] Now for reference Figure 10 This demonstrates a cloud computing environment of 50 ( Figure 9 This provides a set of functional abstractions. It should be understood beforehand that... Figure 10 The components, layers, and functions shown are for illustrative purposes only, and embodiments of the invention are not limited thereto. As depicted, the following layers and corresponding functions are provided:

[0102] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include: a host 61; a server 62 based on a RISC (Reduced Instruction Set Computer) architecture; a server 63; a blade server 64; a storage device 65; and network and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0103] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual server 71; virtual storage 72; virtual network 73, including virtual private network; virtual application and operating system 74; and virtual client 75.

[0104] In one example, management layer 80 can provide the functions described below. Resource provisioning 81 provides dynamic procurement of computing resources and other resources that are utilized to perform tasks within the cloud computing environment. Metering and Pricing 82 provide cost tracking as resources are utilized within the cloud computing environment, and billing or invoicing for consumption of these resources. In one example, these resources can include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. User portal 83 allows for access to and task computing resources that are offered by the service provider. Service level management 84 provides cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment 85 provide pre-arrangement for, and procurement of, cloud computing resources for which a future requirement is anticipated in accordance with an SLA.

[0105] Workloads layer 90 provides examples of functionality for which the cloud computing environment can be utilized. Examples of workloads and functions which can be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analytics processing 94; transaction processing 95; and, vehicle life detection 96.

[0106] Referring now to the drawing Figure 11 , a high-level block diagram of an example computer system 1101 that can be used in various devices discussed herein (e.g., device 105 and vehicle 135) and that can be used to implement one or more of the methods, tools, and modules described herein, as well as any related functionality (e.g., using one or more processor circuits or computer processors of the computer), in accordance with embodiments of the present application is shown. In some embodiments, the primary components of computer system 1101 can include one or more CPUs 1102 (also referred to herein as processor(s)), a memory 1104, a terminal interface 1112, a storage interface 1114, an I / O (input / output) device interface 1116, and a network interface 1118, all of which can communicate directly or indirectly with one another in a suitable manner for inter-component communication via a memory bus 1103, an I / O bus 1108, and an I / O bus interface unit 1110.

[0107] Computer system 1101 can contain one or more general-purpose programmable central processing units (CPU) 1102A, 1102B, 1102C, and 1102D, also referred to herein as CPUs 1102 in general. In some embodiments, computer system 1101 can contain a plurality of processors typical of a relatively large system; however, in other embodiments, computer system 1101 can alternatively be a single CPU system. Each CPU 1102 can execute instructions stored in memory subsystem 1104 and can include one or more levels of on-board cache.

[0108] The memory 1104 can include computer system readable media in the form of volatile memory, such as random access memory (RAM) 1122 or cache memory 1124. The computer system 1101 can further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, a storage system 1126 can be provided for reading from and writing to non-removable, non-volatile magnetic media (e.g., a "hard drive"). Although not explicitly shown, a magnetic disk drive can also be provided for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive can be provided for reading from or writing to a removable, non-volatile optical disk (e.g., a "CD-ROM" or "DVD-ROM"). Additionally, the memory 1104 can include flash memory, such as a flash drive or a flash storage card. The memory devices can be connected to the memory bus 1103 by one or more data media interfaces. The memory 1104 can include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of various embodiments.

[0109] One or more program / utility 1128, having a set (e.g., at least one) of program modules 1130, can be stored in memory 1104 by way of example, and not limitation, an operating system, one or more application programs, other program modules, and program data. Each of the operating systems, one or more application programs, other program modules, and program data or some combination thereof, can include an implementation of a networking environment. Programs 1128 and / or program modules 1130 generally carry out the functions or methodologies of various embodiments.

[0110] Although the memory bus 1103 is shown in Figure 11 as a single bus structure providing a direct communication path between the CPU 1102, the memory 1104, and the I / O bus interface 1110, the memory bus 1103 can comprise multiple different buses or communication paths, which can be arranged in any of various forms, such as peripheral component interconnect (PCI) bus, PCI Express bus, industry standard architecture (ISA) bus, universal serial bus (USB), advanced graphics processing (AGP), audio processing, video processing, multi-media processing, or any other appropriate type of communication path, and / or combinations thereof. Furthermore, while the I / O bus interface 1110 and the I / O bus 1108 are shown as single respective units, in some embodiments the computer system 1101 can include multiple I / O bus interface units 1110, multiple I / O buses 1108, or both. Moreover, while the I / O bus 1108 is shown as direct communication paths between the I / O bus interface 1110 and the various I / O devices, in other embodiments the I / O bus 1108 can comprise multiple I / O bus segments that are each connected to various I / O devices and / or intervening I / O bus segments, and the I / O bus interface 1110 can be connected to the various I / O devices by one or more I / O bus interface units 1110 and / or one or more I / O bus segments.

[0111] In some embodiments, computer system 1101 can be a multi-user large

[0112] Note that Figure 11 It is intended to describe a representative Figure 11 greater or less complexity than that shown in FIG. 11, different Figure 11 components than those shown in FIG. 11, and / or additional or fewer

[0113] As discussed in greater detail herein, it is contemplated that some or all of the operations of some embodiments of the methods described herein can be performed in alternative orders, or can not be performed at all; furthermore, multiple operations can occur simultaneously or as an internal part of a larger process.

[0114] The present application can be a system, a method, and / or a computer program product. The computer program product can include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present application.

[0115] The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium can be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch cards or

[0116] The computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network can comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions into the respective computing / processing device for storage in a computer readable storage medium within the respective computing / processing device.

[0117] Computer readable program instructions for carrying out operations of the present application can be assembly instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) can execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present application.

[0118] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0119] These computer readable program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions can also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including

[0120] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0121] The flow diagrams and the block diagrams in the drawings are illustrations of architectures, functionalities, and operations of possible implementations of systems, methods, and computer program products according to various embodiments presented throughout this disclosure. In this regard, each block in the flow diagrams or block diagrams can represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or in the reverse order, depending on the functionality involved. Also, a block that represents a combination of executable instructions can be implemented with hardware-based systems as well.

[0122] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of various embodiments. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and / or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. In the previous detailed description of various embodiments, reference has been made to the accompanying drawings (in which like numbers represent like elements), which form a part of the detailed description, and in which are shown by way of illustration specific embodiments in which various embodiments can be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the embodiments, but other embodiments can be utilized and logical, mechanical, electrical, and other changes can be made without departing from the scope of the various embodiments. In the previous description, numerous specific details are set forth in order to provide a thorough understanding of the various embodiments. However, various embodiments can be practiced without the specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the understanding of this description.

[0123] Different instances of the word "embodiment" as used herein do not necessarily have the same meaning, but they can have the same meaning. Any data and data structures shown or described herein are examples only and, in other embodiments, different amounts of data, different types of data, different numbers and types of fields, field names, numbers and types of rows, records, entries, or organization of data can be used. Also, any data can be combined with logic such that separate data structures can not be needed. Therefore, the foregoing detailed description should not be interpreted as limiting.

[0124] The description of the various embodiments of the application has been presented for purposes of illustration, but is not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others skilled in the art to understand the embodiments disclosed herein.

[0125] While the application has been described in terms of specific embodiments, it is anticipated that alterations and modifications will be apparent to those skilled in the art. Accordingly, the appended claims should be interpreted in the broadest appropriate manner consistent with the principles of the application.

[0126] A non-limiting list of examples is provided below to illustrate some aspects of the application. Example 1 is a computer-implemented method. The method includes collecting sensor data from a first set of sensors associated with a first seat within a vehicle during a first vehicle phase; and aggregating outputs of each sensor in the first set of sensors associated with the first seat to compute a probability of life within the first seat during the first vehicle phase.

[0127] Example 2 includes the method of Example 1, including or excluding optional features. In this example, during the first vehicle phase, additional sensor data is collected from each of a plurality of sets of sensors, each set of sensors being associated with each of a plurality of respective seats within the vehicle, wherein outputs of each sensor in each respective set of sensors are aggregated to compute a probability of life for each seat within the vehicle during the first vehicle phase.

[0128] Example 3 includes the method of Example 2, including or excluding optional features. In this example, the probabilities of life for each seat are aggregated to compute a probability of life for the entire vehicle during the first vehicle phase.

[0129] Example 4 includes the method of Example 3, including or excluding optional features. In this example, the method further includes computing a probability of life throughout at least two phases of the vehicle by aggregating the probability of life for the entire vehicle during the first vehicle phase with a probability of life for the entire vehicle during at least one additional vehicle phase.

[0130] Example 5 includes the method of any of Examples 1-4, including or excluding optional features. In this example, the outputs of each sensor are weighted based on at least an output of another sensor and based on the vehicle being in the first vehicle phase.

[0131] Example 6 includes the method of any of Examples 1 to 5, including or excluding optional features. In this example, the method further includes collecting feedback regarding whether a life was actually present within a first seat of the vehicle during a first vehicle phase; comparing the feedback to the probability of life within the first seat during the first vehicle phase; and adjusting a weight of at least one sensor output used to calculate the probability of life within the first seat during the first vehicle phase.

[0132] Example 7 includes the method of any of Examples 1 to 6, including or excluding optional features. In this example, at least one sensor of the set of sensors associated with the first seat is a vehicle surround.

[0133] Example 8 includes the method of any of Examples 1 to 7, including or excluding optional features. In this example, the method further includes comparing the probability of life within the first seat to a threshold; and issuing a life protection action in response to the probability of life within the first seat exceeding the threshold.

[0134] Example 9 includes the method of Example 8, including or excluding optional features. In this example, prior to issuing the life protection action, determining whether a condition for issuing the life protection action is satisfied.

[0135] Example 10 is a system. The system includes a memory that stores program instructions and a processor, where the processor is configured to execute the program instructions to perform the method of any of Examples 1 to 9.

[0136] Example 11 is a computer program product. The computer program product includes a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processor to cause the processor to perform the method of any of Examples 1 to 9.

[0137] Example 12 is a method. During a first vehicle phase, collecting sensor data from each of a plurality of sets of sensors, each set associated with each of a plurality of respective seats within a vehicle; aggregating outputs of each sensor in each respective set of sensors to calculate a probability of life within each seat of the vehicle during the first vehicle phase; aggregating the probability of life of each seat to calculate a probability of life of the entire vehicle during the first vehicle phase; and calculating a probability of life in at least two phases of the entire vehicle by aggregating the probability of life of the entire vehicle during the first vehicle phase with a probability of life of the entire vehicle during at least one additional vehicle phase.

[0138] Example 13 includes the method of Example 12, including or excluding optional features. In this example, the method includes comparing the probability of life throughout the at least two stages of the vehicle to a threshold; and issuing a life protection action in response to the probability of life throughout the at least two stages of the vehicle exceeding the threshold.

[0139] Example 14 is a computer program product. The computer program product includes a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processor to cause the processor to perform a method according to Example 12.

[0140] In a preferred embodiment of the invention, a method is provided, comprising: during a first vehicle stage, collecting sensor data from each of a plurality of sets of sensors, each set associated with each of a plurality of respective seats within a vehicle; aggregating the output of each sensor in each respective set of sensors to calculate a probability of life for each seat within the vehicle during the first vehicle stage; aggregating the probability of life for each seat to calculate a probability of life for the entire vehicle during the first vehicle stage; and calculating a probability of life throughout at least two stages of the vehicle by aggregating the probability of life for the entire vehicle during the first vehicle stage with the probability of life for the entire vehicle during at least one additional vehicle stage. The method preferably further comprises: comparing the probability of life throughout the at least two stages of the vehicle to a threshold; and issuing a life protection action in response to the probability of life throughout the at least two stages of the vehicle exceeding the threshold. In a preferred embodiment of the invention, a computer program product is provided, comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processor to cause the processor to perform a method, the method comprising: during a first vehicle stage, collecting sensor data from each of a plurality of sets of sensors, each set associated with each of a plurality of respective seats within a vehicle; aggregating the output of each sensor in each respective set of sensors to calculate a probability of life for each seat within the vehicle during the first vehicle stage; aggregating the probability of life for each seat to calculate a probability of life for the entire vehicle during the first vehicle stage; and calculating a probability of life throughout at least two stages of the vehicle by aggregating the probability of life for the entire vehicle during the first vehicle stage with the probability of life for the entire vehicle during at least one additional vehicle stage.

Claims

1. A method for life detection inside a vehicle, comprising: Sensor data is collected from a first set of sensors associated with a first seat inside the vehicle during the first vehicle phase. The outputs of each of the first set of sensors associated with the first seat are aggregated to calculate the probability of survival in the first seat during the first vehicle phase. The aggregation includes, for each of the first set of sensors, weighting the outputs of the sensors based on the output of at least another sensor and based on the vehicle being in the first vehicle phase. Collect feedback on whether there is actually life in the first seat of the vehicle during the first vehicle phase; The feedback is compared with the probability of survival in the first seat during the first vehicle phase; and Adjust the weights of at least one sensor output used to calculate the probability of life in the first seat during the first vehicle phase.

2. The method according to claim 1, wherein, During the first vehicle phase, additional sensor data is collected from each of multiple sets of sensors, each set associated with each of multiple corresponding seats within the vehicle, wherein the output of each sensor in each corresponding sensor set is aggregated to calculate the probability of survival for each seat within the vehicle during the first vehicle phase.

3. The method according to claim 2, wherein, The survival probability of each seat is summed to calculate the overall survival probability of the vehicle during the first vehicle phase.

4. The method according to claim 3, further comprising: The probability of survival across at least two phases of the vehicle is calculated by summing the probability of survival of the entire vehicle during the first vehicle phase and the probability of survival of the entire vehicle during at least one additional vehicle phase.

5. The method according to claim 1, wherein, At least one of the sensors in the first set associated with the first seat is surrounded by the vehicle.

6. The method according to claim 1, further comprising: Compare the probability of survival in the first seat with a threshold; as well as A life protection action is initiated in response to the probability of life in the first seat exceeding the threshold.

7. The method according to claim 6, wherein, Before issuing the life-saving action, it is determined whether the conditions for issuing the life-saving action are met.

8. A system for life detection in a vehicle, comprising: Memory that stores program instructions; as well as Processor, wherein the processor is configured to execute the program instructions to perform a method comprising: Sensor data is collected from a first set of sensors associated with a first seat inside the vehicle during the first vehicle phase. The outputs of each of the first set of sensors associated with the first seat are aggregated to calculate the probability of survival in the first seat during the first vehicle phase. The aggregation includes, for each of the first set of sensors, weighting the outputs of the sensors based on the output of at least another sensor and based on the vehicle being in the first vehicle phase. Collect feedback on whether there is actually life in the first seat of the vehicle during the first vehicle phase; The feedback is compared with the probability of survival in the first seat during the first vehicle phase; and Adjust the weights of at least one sensor output used to calculate the probability of life in the first seat during the first vehicle phase.

9. The system according to claim 8, wherein, During the first vehicle phase, additional sensor data is collected from each of multiple sets of sensors, each set associated with each of multiple corresponding seats within the vehicle, wherein the output of each sensor in each corresponding sensor set is aggregated to calculate the probability of survival for each seat within the vehicle during the first vehicle phase.

10. The system according to claim 9, wherein, The survival probability of each seat is summed to calculate the survival probability of the entire vehicle during the first vehicle phase.

11. The system according to claim 10, wherein, The method executed by the processor further includes: The probability of survival across at least two phases of the vehicle is calculated by summing the probability of survival of the entire vehicle during the first vehicle phase and the probability of survival of the entire vehicle during at least one additional vehicle phase.

12. The system according to claim 8, wherein, At least one of the first set of sensors associated with the first seat is located around the vehicle.

13. The system according to claim 8, wherein, The method executed by the processor further includes: Compare the probability of survival within the first seat with a threshold; and A life protection action is initiated in response to the probability of life in the first seat exceeding the threshold.

14. The system according to claim 13, wherein, Before issuing the life-saving action, it is determined whether the conditions for issuing the life-saving action are met.

15. A computer program product comprising a computer-readable storage medium having program instructions embodied therein, the program instructions being executable by a processor to cause the processor to perform a method, the method comprising: Sensor data is collected from a first set of sensors associated with a first seat inside the vehicle during the first vehicle phase. The outputs of each of the first set of sensors associated with the first seat are aggregated to calculate the probability of survival in the first seat during the first vehicle phase. The aggregation includes, for each of the first set of sensors, weighting the outputs of the sensors based on the output of at least another sensor and based on the vehicle being in the first vehicle phase. Collect feedback on whether there is actually life in the first seat of the vehicle during the first vehicle phase; The feedback is compared with the probability of survival in the first seat during the first vehicle phase; and Adjust the weights of at least one sensor output used to calculate the probability of life in the first seat during the first vehicle phase.

16. The computer program product according to claim 15, wherein, During the first vehicle phase, additional sensor data is collected from each of multiple sets of sensors, each set associated with each of multiple corresponding seats within the vehicle, wherein the output of each sensor in each corresponding sensor set is aggregated to calculate the probability of survival for each seat within the vehicle during the first vehicle phase.

17. The computer program product according to claim 16, wherein, The survival probability of each seat is summed to calculate the survival probability of the entire vehicle during the first vehicle phase.

18. The computer program product according to claim 17, wherein, The method executed by the processor further includes: The probability of survival across at least two phases of the vehicle is calculated by summing the probability of survival of the entire vehicle during the first vehicle phase and the probability of survival of the entire vehicle during at least one additional vehicle phase.

Images