Vehicle matching system and method for matching users with vehicles

Abstract

Vehicle matching system and method for matching a user with a vehicle. The method for matching a vehicle with a user includes receiving a user ride request from a user for a vehicle from a plurality of available vehicles, receiving a threshold vehicle risk score preference of the user, receiving a user risk score of the user, receiving the threshold user risk score preference of a plurality of available vehicles, identifying a subset of the plurality of available vehicles having vehicle risk scores equal to or below the threshold vehicle risk score preference of the user and the threshold user risk score preference equal to or above the user risk score of the user, and presenting ride options to the user for selecting one of the subset of the plurality of available vehicles in the subset of available vehicles for the user ride request.

Description

Technical Field

[0001] The present specification relates generally to vehicle systems for matching users with vehicles, and more particularly to a ride sharing vehicle system that matches a user with a specific vehicle based on a risk score of the user and a risk score of the vehicle. Background Art

[0002] Ride sharing services have become widely available, and are used to pick up users from a specific destination and transport them to the desired destination. Current ride sharing services can assign scores to both drivers and users (i.e., passengers). In some cases, drivers can reject requests from users based on low scores of users. Low scores can indicate poor previous experiences with other drivers. Similarly, users can have the opportunity to reject rides provided from specific drivers based on low scores assigned to drivers. However, these scores are not based on one or more factors associated with potential health risks of drivers and users. In addition, although drivers and users can have the opportunity to reject the rides or passengers provided, current ride sharing services do not match users and drivers based on these scores.

[0003] Therefore, there is a need for improved systems and methods for matching vehicles and users with each other based on a risk score associated with both the user and the vehicle. Summary of the invention

[0004] In one embodiment, a method for matching a vehicle with a user includes: receiving, by a computing device, a user ride request from a user for a vehicle from a plurality of available vehicles, accepting, by the computing device, a threshold vehicle risk score preference of the user, determining, by the computing device, a user risk score of the user, determining, by the computing device, a vehicle risk score of at least one of the plurality of available vehicles, receiving, by the computing device, the threshold user risk score preference for the plurality of available vehicles, identifying, by the computing device, a subset of the plurality of available vehicles having vehicle risk scores equal to or below the threshold vehicle risk score preference of the user and threshold user risk score preference equal to or above the user risk score of the user, and presenting ride options to the user for selecting one of the plurality of available vehicles in the subset of available vehicles for the user ride request.

[0005] In another embodiment, a vehicle matching system includes a computing device including a controller configured to: receive a user ride request from a user for a vehicle from a plurality of available vehicles, receive a threshold vehicle risk score preference from the user, determine a user risk score for the user, determine vehicle risk scores for a plurality of available vehicles, receive the threshold user risk score preference for the plurality of available vehicles, identify a subset of the plurality of available vehicles having vehicle risk scores equal to or below the threshold vehicle risk score preference for the user and the threshold user risk score preference equal to or above the user risk score for the user, and present an option to the user for selecting one of the plurality of available vehicles in the subset of available vehicles for the user ride request.

[0006] In another embodiment, a vehicle matching system includes a computing device including a controller configured to: receive a user ride request from a user for a vehicle from a plurality of available vehicles, identify one or more vehicles within a subset of the plurality of available vehicles, the one or more vehicles having a vehicle risk score equal to or below a threshold vehicle risk score preference of the user and a threshold user risk score preference equal to or above a user risk score of the user, and present one or more ride options to the user for selecting one of the one or more vehicles in the subset of the plurality of available vehicles for the user ride request.

[0007] These and additional features provided by the embodiments described herein will be more fully understood in view of the following detailed description taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The embodiments set forth in the drawings are illustrative and exemplary in nature and are not intended to limit the subject matter defined by the claims. The following detailed description of the illustrative embodiments may be understood when read in conjunction with the following drawings, in which like structures are represented by like reference numerals, and in which:

[0009] Figure 1 schematically depicts a vehicle matching system including a server in communication with a plurality of user devices and a plurality of vehicles according to one or more embodiments shown and described herein;

[0010] Figure 2 Schematically depicts a schematic diagram of a device according to one or more embodiments shown and described herein. Figure 1 The various components of the server, vehicle and user equipment of the vehicle matching system;

[0011] Figure 3 schematically depicts a memory component of a server according to one or more embodiments shown and described herein;

[0012] Figure 4schematically depicts a method for assigning a user risk score to a user according to one or more embodiments shown and described herein;

[0013] Figure 5 schematically depicts a method for assigning a vehicle risk score to a vehicle according to one or more embodiments shown and described herein; and

[0014] Figure 6 A method for matching a vehicle with a user according to one or more embodiments shown and described herein is schematically depicted. DETAILED DESCRIPTION

[0015] Embodiments described herein relate to systems and methods for matching users with available vehicles based on risk scores associated with the users and the vehicles. The vehicle matching system includes a server including a controller configured to: receive a user ride request from a user for a vehicle from a plurality of available vehicles, identify a subset of the plurality of available vehicles having a vehicle risk score equal to or lower than a threshold vehicle risk score preference of the user and a threshold user risk score preference equal to or higher than a user risk score of the user, and present an option to the user for selecting one of the plurality of available vehicles in the subset of available vehicles for the user ride request. Various embodiments of the system and methods and operations of the system are described in greater detail herein. Whenever possible, the same reference numerals are used throughout the drawings to represent the same or similar components.

[0016] Reference now Figure 1, a vehicle matching system 100 according to one or more embodiments described herein is shown. The vehicle matching system 100 is particularly useful for ride sharing applications, in which a user sends a signal including a user ride request via a user device, requesting to pick up at a specific location and be transported to a destination. The vehicle matching system 100 includes a remote computing device 102 that communicates with multiple user devices 104 and multiple vehicles 108 via a network 110, and the multiple user devices 104 are operated by corresponding users 106. The network 110 can be configured as the Internet, a mobile communication network, a satellite-based network, a LAN connection, a Wi-Fi connection, etc. The remote computing device 102 can be configured as any computing device for performing the functions described herein, such as a server, a personal computer, a tablet computer, a mobile computing device, etc. The user device 104 can be any personal computing device, a mobile computing device, a mobile phone, etc. The user device 104 is pre-registered with the remote computing device 102. The user device 104 can be associated with a corresponding user profile stored in the remote computing device 102. Similarly, the vehicle 108 may be pre-registered with the remote computing device 102 and associated with a vehicle profile stored in the remote computing device 102. As described in more detail herein, the user profile and the vehicle profile may include associated risk scores and associated threshold risk score preferences. Specifically, the user profile may include user data including a user risk score and a threshold vehicle risk score preference. Similarly, the vehicle profile may include vehicle data including a vehicle risk score and a threshold user risk score preference. The remote computing device 102 may utilize various risk scores and threshold risk score preferences to match the user device 104, and in particular the user 106 who owns the user device 104, with one of the plurality of vehicles 108 in the manner discussed herein.

[0017] Reference now Figure 2 , depicts a schematic diagram of an embodiment of a vehicle matching system 100 according to one or more embodiments shown and described herein, the vehicle matching system 100 including a user device 104, a vehicle 108, and a network 110. It should be understood that although Figure 2 Only one user device 104 and one vehicle 108 are shown in FIG. 1 , but the vehicle matching system 100 may include any number of user devices 104 and vehicles 108 based on the number of user devices 104 and vehicles 108 that exist.

[0018] In an embodiment, remote computing device 102 includes controller 200, communication path 201, and network interface hardware 206. The various components of remote computing device 102 and their interactions are described in detail below. It should be noted that some embodiments of remote computing device 102 may include additional components not described herein.

[0019] The communication path 201 can be formed by any medium capable of transmitting a signal, such as, for example, a wire, a conductive trace, an optical waveguide, etc. In addition, the communication path 201 can be formed by a combination of media capable of transmitting a signal. In one embodiment, the communication path 201 includes a combination of conductive traces, wires, connectors, and buses that cooperate to allow electrical data signals to be transmitted to components such as processors, memories, sensors, input devices, output devices, and communication devices. Therefore, the communication path 201 may include a bus, such as, for example, a LIN bus, a CAN bus, a VAN bus, etc. In addition, it is noted that the term "signal" refers to a waveform (e.g., electrical, optical, magnetic, mechanical, or electromagnetic) that can propagate through a medium, such as DC, AC, a sine wave, a triangular wave, a square wave, vibration, etc. The communication path 201 communicatively couples various components of the server. As used herein, the term "communicatively coupled" means that the coupled components can exchange data signals with each other, such as, for example, electrical signals via a conductive medium, electromagnetic signals via air, optical signals via an optical waveguide, etc.

[0020] As described above, the remote computing device 102 includes a controller 200, which includes one or more processors 202 and one or more memory components 204. Each of the one or more processors 202 can be any device capable of executing machine-readable instructions. Therefore, each of the one or more processors 202 can be an integrated circuit, a microchip, a computer, or any other computing device. The one or more processors 202 are communicatively coupled to other components of the remote computing device 102 via a communication path 201. Therefore, the communication path 201 can communicatively couple any number of processors to each other and allow modules coupled to the communication path 201 to operate in a distributed computing environment. Specifically, each module can operate as a node that can send and / or receive data.

[0021] Each of the one or more memory components 204 of the remote computing device 102 is coupled to the communication path 201 and is communicatively coupled to the one or more processors 202. The one or more memory components 204 may include RAM, ROM, flash memory, a hard drive, and / or any other hardware or firmware capable of storing machine-readable instructions so that the machine-readable instructions can be accessed and executed by the one or more processors 202. The machine-readable instructions may include logic or algorithms written in any programming language of any generation (e.g., 1GL, 2GL, 3GL, 4GL, or 5GL), such as, for example, a machine language that can be directly executed by a processor, or an assembly language, object-oriented programming (OOP), a scripting language, microcode, etc. that can be compiled or assembled into machine-readable instructions and stored on one or more memory components. In some embodiments, the machine-readable instructions may be written in a hardware description language (HDL), such as logic implemented via a field programmable gate array (FPGA) configuration or an application-specific integrated circuit (ASIC) or its equivalent. Therefore, the methods described herein may be implemented in any conventional computer programming language, implemented as pre-programmed hardware elements, or implemented as a combination of hardware and software components.

[0022] Reference now Figure 3 , depicts an embodiment of one or more memory components 204, including a user database 300, a vehicle database 302, a user risk score update logic 304, a vehicle risk score update logic 306, and a user / vehicle matching logic 308. The user database 300 includes a list of all user devices 104 registered with the vehicle matching system 100. Specifically, the user database 300 includes data collected from the user devices 104, such as location information, previous ride history, etc. The user database 300 also includes a user risk score and a threshold vehicle risk score preference associated with each user device 104. Similarly, the vehicle database 302 includes data collected from the vehicles 108, such as location information, previous ride history, previous passenger history, previous cleaning history, etc. The vehicle database 302 also includes a vehicle risk score and a threshold user risk score preference associated with each vehicle 108.

[0023] The user risk score update logic 304 causes the remote computing device 102 to adjust the user risk score of one or more user devices 104 stored in the user database 300. Specifically, the user risk score update logic 304 causes the remote computing device 102 to analyze the data received from the user devices 104 to determine how the user risk score of each user device 104 should be adjusted. Similarly, the vehicle risk score update logic 306 causes the remote computing device 102 to adjust the vehicle risk scores of the vehicles 108 stored in the vehicle database 302. Specifically, the vehicle risk score update logic 306 causes the remote computing device 102 to analyze the data received from the vehicles 108 to determine how the vehicle risk score of each vehicle 108 should be adjusted. The user / vehicle matching logic 308 causes the remote computing device 102 to analyze the user risk score and the threshold vehicle risk score preference of the user device 104 that sent the user ride request to match the user device 104 with an available vehicle 108 based on the vehicle risk score of the available vehicle 108 and the threshold user risk score preference. In some embodiments, the user / vehicle matching logic 308 matches the user device 104 sending the user ride request with multiple vehicles 108 to present one or more ride options to the user 106 of the user device 104 for selecting a particular one of the vehicles 108 .

[0024] Reference again Figure 2 , the vehicle 108 includes a controller 208, a communication path 209, a network interface hardware 214, one or more internal sensors 216, a position sensor 218, a user interface 220, and a cleaning device 222. The various components of the vehicle 108 and their interactions are described in detail below. However, it should be noted that in embodiments, the vehicle 108 may include fewer components than those discussed herein or additional components not discussed herein.

[0025] Components of vehicle 108 may be structurally similar to, and have similar functionality to, corresponding components of remote computing device 102 (e.g., controller 208 corresponds to controller 200, communication path 209 corresponds to communication path 201, and network interface hardware 214 corresponds to network interface hardware 206).

[0026] One or more interior sensors 216 are coupled to the communication path 209 and are communicatively coupled to the one or more processors 210. The one or more interior sensors 216 may include a temperature sensor, an audio detection sensor, and the like. In embodiments where the one or more interior sensors 216 include a temperature sensor, the temperature of an occupant in the vehicle 108 may be detected. The temperature sensor may be a handheld temperature sensor (such as an infrared thermometer) for obtaining temperature readings of an occupant in the vehicle 108. Thus, it may be determined by the temperature sensor itself or by processing the temperature reading detected by the temperature sensor at the controller 208 that an occupant of the vehicle 108 has a temperature above a predetermined temperature. As described herein, the temperature of the occupant detected by the temperature sensor may be used to adjust the vehicle risk score of the vehicle 108.

[0027] In an embodiment, one or more internal sensors 216 may include an audio detection sensor for detecting and identifying or classifying specific noises within the vehicle 108. In an embodiment, the audio detection sensor includes a microphone for detecting the noise level within the vehicle 108, and a noise analyzer for identifying or classifying the type of noise detected by the microphone. In some embodiments, the audio detection sensor may send a signal including audio data related to the detected noise to the controller 208 to analyze the detected noise and identify the type of noise. Specifically, for example, the detected noise may be identified or classified as coughing, sneezing, vomiting, etc. As described herein, the noise detected by the audio detection sensor in the vehicle 108 may be used to adjust the vehicle risk score of the vehicle 108.

[0028] As described above, the vehicle 108 includes a location sensor 218 coupled to the communication path 209 and communicatively coupled to the one or more processors 210. The location sensor 218 can be a satellite-based radio navigation device (such as a GPS device) for tracking the driving behavior of the vehicle 108, such as, for example, the location of the vehicle 108, the distance that the vehicle 108 has traveled, etc. More specifically, the location sensor 218 can track the location of the vehicle 108 to determine when the vehicle 108 enters a geographic area determined to be a high-risk area, such as an area where the population density exceeds a predetermined population density threshold, an area where the infection positivity rate is higher than a predetermined threshold, an area where a super-spreader event has recently been held, etc. The population density can be determined by dividing the size of the geographic area by the population within the geographic area. If the population density is higher than the predetermined population density threshold, the geographic area can be determined to be a high-risk area. In addition, for example, if the size of the geographic area is divided by the infection positivity rate, that is, the number of confirmed new cases of a disease, condition, or symptom is higher than a predetermined threshold, the geographic area can be determined to be a high-risk area, indicating that there is a greater likelihood of exposure to the disease, condition, or symptom within the geographic area. Additionally, the location sensor 218 may determine the length of time that the vehicle 108 is within the geographic area. In an embodiment, the geographic area may be determined to be a high-risk area based on data collected from a remote system that is in communication with the remote computing device 102 and / or the vehicle 108. Thus, the remote system may provide a map in which a plurality of geographic areas are indicated as high-risk areas, and the location sensor 218 of the vehicle 108 detects when the vehicle 108 enters one of the geographic areas based on the location of the vehicle 108 and the known locations of the high-risk geographic areas. As described herein, the location of the vehicle 108 that enters a geographic area determined to be a high-risk area and the duration or length of time that the vehicle 108 is within a particular geographic area may be used to adjust the vehicle risk score of the vehicle 108.

[0029] As described above, the vehicle 108 includes a user interface 220 for providing visual output, such as, for example, notifications, entertainment, maps, navigation, information, or a combination thereof. The user interface 220 is coupled to the communication path 209 and is communicatively coupled to one or more processors 210. The user interface 220 may include any medium capable of transmitting an optical output, such as, for example, a cathode ray tube, a light emitting diode, a liquid crystal display, a plasma display, a projection display, a holographic display, an enhanced display, etc. In addition, the user interface 220 may include a tactile operation device capable of converting a mechanical, optical, or electrical signal into a data signal capable of being transmitted using the communication path 209. Specifically, the tactile operation device may include any number of movable objects, such as, for example, buttons, switches, knobs, etc., each of which converts physical motion into a data signal that can be transmitted through the communication path 209. In an embodiment, the tactile operation device may be a touch screen that detects the presence and position of a tactile input in addition to providing optical information. The user interface 220 may request input from a person in the vehicle 108 (such as, for example, a driver or operator of the vehicle 108, or a passenger of the vehicle 108). For example, the user interface 220 may query whether a cleaning event has occurred for the vehicle 108 , when the last cleaning event for the vehicle 108 occurred, where the vehicle 108 has traveled, how long the vehicle 108 has traveled, how many passengers the vehicle 108 has transported, etc. As described in more detail herein, input received at the user interface 220 in response to a query may be used to adjust the vehicle risk score for the vehicle 108 .

[0030] As described above, the vehicle 108 includes a cleaning device 222 for cleaning or disinfecting the vehicle 108, such as, for example, a seat surface in the vehicle 108. The cleaning device 222 is coupled to the communication path 209 and is communicatively coupled to the one or more processors 210. The cleaning device 222 may include any known or undeveloped device for cleaning and / or disinfecting at least a portion of the vehicle 108. For example, the cleaning device 222 may include one or more drying devices (such as ultraviolet or high temperature heating lamps), disinfection nozzles for spraying solutions, ozone sprayers, vacuum cleaners, etc. The cleaning device 222 may be manually operated by a driver or operator of the vehicle 108 and / or may be automatically operated in response to one or more cleaning triggers, such as, for example, after a predetermined time period, after a predetermined number of passengers have been transported, after a predetermined distance has been traveled, etc. When the cleaning device 222 is activated, in response to the manual operation of the cleaning device 222 or the cleaning trigger, the time when the cleaning device 220 is activated, i.e., the cleaning event, is recorded. As described in more detail herein, the time that has passed since a cleaning event occurred may be used to adjust the vehicle risk score of the vehicle 108. In an embodiment, an operator of the vehicle 108 may manually indicate via the user interface 220 that a cleaning event has occurred.

[0031] Still reference Figure 2 , the user device 104 includes a controller 224, a communication path 225, a network interface hardware 230, a location sensor 232, and a user interface 234, the controller 224 including one or more processors 226 and one or more memory components 228. The various components of the user device 104 and their interactions are described in detail below. However, it should be noted that in embodiments, the user device 104 may include fewer components than those discussed herein or additional components not discussed herein.

[0032] Components of user device 104 may be structurally similar to, and have similar functionality to, corresponding components of vehicle 108 (e.g., controller 224 corresponds to controller 208, communication path 225 corresponds to communication path 209, network interface hardware 230 corresponds to network interface hardware 214, position sensor 232 corresponds to position sensor 218, and user interface 234 corresponds to user interface 220).

[0033] Similar to the location sensor 218 of the vehicle 108, the location sensor 232 of the user device 104 is coupled to the communication path 225 and is communicatively coupled to the one or more processors 226. The location sensor 232 can track the location of the user device 104 to determine when the user 106 enters a geographic area determined to be a high-risk area, i.e., an area where the population density exceeds a predetermined population density threshold. The location sensor 232 of the user device 104 detects when the user device 104 enters one of the geographic areas based on the location of the user device 104 and the known locations of the high-risk geographic areas, and when the user device 104 leaves the geographic area. Therefore, the location sensor 232 can determine the length of time that the user device 104 is within the geographic area. It should be understood that the high-risk areas of the user device 104 can be the same or different from those high-risk areas discussed above with respect to the vehicle 108. As described herein, the location of the user device 104 entering the geographic area determined to be a high-risk area and the duration or length of time that the user device 104 is within a particular geographic area can be used to adjust the user risk score of the user 106.

[0034] Similar to the user interface 220 of the vehicle 108, the user interface 234 of the user device 104 is coupled to the communication path 225 and is communicatively coupled to the one or more processors 226. The user interface 234 can request input from the user 106 of the user device 104. For example, the user interface 234 can query the user 106's health data, the user 106's test results, screening questions, vaccination status, previous contact or interaction with other people, etc. to determine the potential risk that the user 106 may pose to other people when in contact or proximity. As described in more detail herein, the input received at the user interface 234 in response to the query can be used to adjust the user risk score of the user 106.

[0035] Reference now Figure 4 , depicts a process 400 for adjusting a user risk score for a user based on one or more user risk score factors collected by monitoring user activity via a user device. Referring to the vehicle matching system 100, in particular Figure 2 The remote computing device 102 and the user device 104 shown in FIG. Figure 3 Process 400 is discussed with reference to memory component 204 of remote computing device 102 as shown in FIG.

[0036] At block 402, the remote computing device 102 assigns a baseline user risk score to each user 106 registered with the remote computing device 102. The baseline user risk score for the user 106 may be assigned during an initial registration process in which a series of queries are presented to the user 106 relating to the user's 106 previous activities and the user's 106 current health status (including vaccination status, test results, etc.). This initial data may be collected by displaying the queries on the user interface 234 of the user device 104 and receiving input from the user 106 via the user interface 234. Thus, a baseline user risk score is associated with the user 106 and stored in the user database 300 of the memory component 204 of the remote computing device 102. As a non-limiting example, the baseline user risk score may be determined by assigning one or more points to each query presented to the user. For each query that provides a response that is determined to be risky, one or more points are added based on the risk level assigned to the response to determine the baseline user risk score.

[0037] Thereafter, as discussed in greater detail herein, one or more user risk score factors are identified for adjusting the user risk score. Thus, the user risk score may be adjusted on a continuous basis to provide an adjusted user risk score for the user 106 based on the activity of the user 106. In an embodiment, the one or more user risk score factors may be based on updated health data or risk data collected from the user 106 via the user device 104. Similar to the manner in which a baseline user risk score is determined, one or more points may be assigned to the user risk score factors based on the acquired data, and then applied to the baseline user risk score to provide an increased user risk score.

[0038] For example, at box 404, the remote computing device 102 sends a signal to the user device 104 requesting information related to the user's risk. As described above, the request may include querying the user's 106 health data, the user's 106 test results, screening questions, vaccination status, previous contact or interaction with other people, etc., to determine the potential risk that the user 106 may cause to other people when in contact or close. At box 406, the user 106 operates the user interface 234 of the user device 104 to respond to the query in any suitable manner and provide feedback on the query, such as, for example, selecting a predetermined response, entering a custom response, submitting an image, etc. As a non-limiting example, the user can submit an answer, and in some embodiments, include a document for proof of the test results or vaccination status. At box 408, the remote computing device 102 can perform verification on the feedback received from the user 106 via the user device 104. For example, the verification may include confirming the feedback from the user 109 by verifying the accuracy of the provided document.

[0039] Another example of how health data or risk data may be collected from the user 106 for the purpose of adjusting the user's risk score is to receive user-specific information from a publicly available source. For example, at block 410, the remote computing device 102 may request health data from a publicly available health database (e.g., a state, county, or other public health department) that collects health data about enrolled participants. By identifying the user 106 among those participants in the publicly available health database, the remote computing device 102 may collect health data related to the user 106.

[0040] Another example of health data or risk data that can be collected is to determine whether the user 106 has entered a high-risk area by tracking the location of the user device 104. As described above, the user device 104 includes a location sensor 232 for tracking the location of the user device 104. Therefore, at box 412, the location of the user device 104 is monitored using the location sensor 232 of the user device 104. At box 414, the remote computing device 102 or the user device 104 itself determines whether the location of the user device 104 tracked by the location sensor 232 is within a geographic area determined to be a high-risk area. As described above, the geographic area can be determined as a high-risk area based on the population density within a specific geographic area. The geographic area can also be determined as a high-risk area based on health data related to people in the geographic area (such as, for example, detected illnesses, etc.). In an embodiment, at box 416, the location sensor 232 of the user device 104 detects the duration or length of time that the user 106 is in the high-risk area. Thus, location sensor 232 may indicate the time when user 106 enters the high risk area and the time when user 106 leaves the high risk area to determine the total length of time within the high risk area.

[0041] At box 418, the remote computing device 102, in particular the user risk score update logic 304, updates the user risk score stored in the user database 300 based on one or more user risk score factors discussed herein. Specifically, the user risk score is updated by increasing or decreasing the baseline user risk score in response to one or more user risk score factors that indicate an increase in risk or a decrease in risk, respectively. For example, if the user risk-related information collected in boxes 404-408 indicates an increase in risk, the user risk score update logic 304 will increase the user risk score. In some embodiments, if the user risk-related information collected in boxes 404-408 indicates no risk or low risk, such as the user 106 has received all vaccinations, the user risk score update logic 304 will decrease the user risk score. Similarly, the user risk score update logic 304 can cause the remote computing device 102 to increase or decrease the user risk score based on the user-specific information collected from publicly available sources in box 410. The user risk score update logic 304 may also increase or decrease the user risk score based on whether the user device 104 enters a geographic area determined to be a high-risk area, and increase the user risk score in proportion to the length of time the user device 104 is in a particular geographic area. Once the user risk score is adjusted at block 418, the adjusted user risk score is stored in the user database. Blocks 404-416 may be repeated at any given time to update the user risk score based on updated information collected from the user device 104.

[0042] Reference now Figure 5 , depicts a process 500 for adjusting a vehicle risk score of a vehicle 108 based on one or more vehicle risk score factors collected by monitoring the activity of the vehicle 108. Referring to the vehicle matching system 100, in particular Figure 2 The remote computing device 102 shown in FIG. 1 is in communication with the vehicle 108 and Figure 3 The process 500 is discussed with reference to the memory component 204 of the remote computing device 102 shown in FIG.

[0043] At box 502, the remote computing device 102 assigns a baseline vehicle risk score to a vehicle 108 that was previously registered with the remote computing device 102. As described above, the baseline vehicle risk score may be assigned during an initial registration process in which an operator of the vehicle 108 is presented with a series of queries related to previous activity of the vehicle 108, such as, for example, when the last cleaning event occurred. This initial data may be collected by displaying the queries on the user interface 220 of the vehicle 108 and receiving input from the operator of the vehicle 108 via the user interface 220 and assigning a score to the input from the operator. Thus, the baseline vehicle risk score is associated with the vehicle 108 and stored in the vehicle database 302 of the memory component 204 of the remote computing device 102.

[0044] Thereafter, as discussed in greater detail herein, one or more vehicle risk score factors are identified for adjusting the vehicle risk score. Thus, the vehicle risk score may be adjusted on a continuous basis to provide an updated vehicle risk score for the vehicle 108. In an embodiment, the one or more vehicle risk score factors may be based on the activity of the vehicle 108.

[0045] For example, at box 504, the remote computing device 102 sends a signal to the vehicle 108 requesting vehicle risk-related information. As described above, the request may include querying the health data of the operator of the vehicle 108, such as, for example, the operator's test results, screening questions, vaccination status, previous contact or interaction with other people, etc., to determine the potential risk that the operator of the vehicle 108 may pose to other people when in contact or proximity. At box 506, the operator operates the user interface 220 of the vehicle 108 to respond to the query in any suitable manner and provide feedback to the query, such as, for example, selecting a predetermined response, entering a customized response, submitting an image, etc. Similar to box 408 discussed above, some embodiments may be configured so that verification can be provided so that the feedback received from the operator of the vehicle 108 can be verified. In an embodiment, the vehicle risk-related information may include temperature readings or noises detected by one or more interior sensors 216 of the vehicle as described herein to determine, for example, whether a passenger is at a temperature above a predetermined temperature threshold or is vomiting in the vehicle 108.

[0046] Another example of how risk data may be collected is by identifying user risk scores of previous passengers of the vehicle 108. Thus, at block 508, the remote computing device 102 identifies which passengers were previously transported by the vehicle 108, and more specifically, the user risk scores of those passengers registered with the remote computing device 102 that have been assigned user risk scores. As described in more detail herein, the user risk scores of those passengers of the vehicle 108 may be utilized to adjust the vehicle risk score of the vehicle 108.

[0047] Another example of where risk data may be collected is to determine whether the vehicle 108 enters a high-risk area by tracking the location of the vehicle. As described above, the vehicle 108 includes a location sensor 218 for tracking the location of the vehicle 108. Therefore, at box 510, the location of the vehicle 108 is monitored using the location sensor 218 of the vehicle 108. At box 512, the remote computing device 102 or the vehicle 108 itself determines whether the location of the vehicle 108 tracked by the location sensor 218 enters a geographic area determined to be a high-risk area. The manner in which a geographic area may be determined to be a high-risk area may be the same as described above with respect to the high-risk geographic area of ​​the user device 104. Therefore, the high-risk geographic area may be the same or different from those geographic areas determined to be high-risk for the user device 104. In an embodiment, at box 514, the location sensor 218 of the vehicle 108 detects the duration or length of time that the vehicle 108 is within the high-risk area. Therefore, the location sensor 218 may indicate the time when the vehicle 108 enters the high-risk area and the time when the vehicle 108 leaves the high-risk area to determine the total length of time within the high-risk area.

[0048] Another example of where risk data may be collected is by determining whether a cleaning event has occurred. In an embodiment, as described above, the vehicle 108 may be equipped with a cleaning device 222 for disinfecting the vehicle 108. At box 516, the remote computing device 102 detects whether the cleaning device 222 has been activated, i.e., whether a triggering event has occurred to clean the vehicle 108, and thus a cleaning event has occurred. In addition to detecting whether a cleaning event has occurred in the vehicle 108, the remote computing device 102 also determines the time that has passed since the cleaning event occurred. It should be understood that the time that has passed since the cleaning event may be received by input from an operator of the vehicle 108 via the user interface 220 of the vehicle 108.

[0049] Finally, at box 518, the remote computing device 102 updates the vehicle risk score stored in the vehicle database 302 via the vehicle risk score update logic 306 based on one or more vehicle risk score factors discussed herein. Specifically, the vehicle risk score can be updated by increasing or decreasing the baseline vehicle risk score in response to one or more vehicle risk score factors that indicate an increase in risk or a decrease in risk, respectively. For example, if the vehicle risk-related information collected in boxes 504-506 indicates an increase in risk, the vehicle risk score update logic 306 will increase the vehicle risk score. In some embodiments, if the vehicle risk-related information collected in boxes 504-506 indicates no risk or low risk, such as the operator of the vehicle 108 has received all vaccinations, the vehicle risk score update logic 306 will decrease the vehicle risk score. Similarly, the vehicle risk score update logic 306 can cause the remote computing device 102 to increase or decrease the vehicle risk score based on the user risk score of the passenger previously transported by the vehicle 108 as determined in box 508 (if provided). The vehicle risk score update logic 306 will also increase or decrease the vehicle risk score based on whether the vehicle 108 has entered a geographic area determined to be a high risk area as determined in blocks 510-514, and increase the vehicle risk score in proportion to the length of time the vehicle 108 has been in a particular geographic area. In addition, the vehicle risk score update logic 306 may cause the remote computing device 102 to decrease the vehicle risk score based on whether a cleaning event has occurred as determined in block 516. In particular, the vehicle risk score may be decreased in proportion to the time that has passed since the last cleaning event occurred. In other words, as the time that has passed since the last cleaning event increases, the impact of the occurrence of a cleaning event on the vehicle risk score decreases. Once the vehicle risk score is adjusted at block 518, the adjusted vehicle risk score is stored in the vehicle database 302. Blocks 504-516 may be repeated at any given time to update the vehicle risk score based on updated information collected from the vehicle 108.

[0050] Reference now Figure 6 , depicts a process 600 for matching users with vehicles based on a user risk score and a threshold vehicle risk score preference assigned to each user, and a vehicle risk score and a threshold user risk score preference assigned to each vehicle. Thus, the vehicle matching system 100 matches each user with a particular vehicle such that the vehicle satisfies the user's threshold vehicle risk score preference based on the vehicle's vehicle risk score, and the user satisfies the threshold user risk score preference for the vehicle. Figure 1-Figure 5 Let's discuss processing 600.

[0051] At block 602, the remote computing device 102 receives a user ride request from the user 106 via the user device 104. The user ride request includes a pick up location, which may be the current location of the user device 104 as determined by the location sensor 232 of the user device 104, and a drop off location or destination. The user ride request may include additional information such as, for example, a preferred vehicle, the number of passengers, and a pick up or drop off time.

[0052] Upon receiving the user ride request, the remote computing device 102 receives a user risk score assigned to the user 106 of the user device 104 at block 604. The user risk score is retrieved from the user database 300 of the remote computing device 102. As described above in process 400, the user risk score for each user 106 is continuously adjusted based on one or more user risk score factors, and the adjusted user risk score is stored in the user database 300 associated with the particular user 106.

[0053] In addition to receiving the user risk score for the user 106, the remote computing device 102 also receives a threshold vehicle risk score preference assigned to the user 106 at block 606. The threshold vehicle risk score preference is also retrieved from the user database 300 of the remote computing device 102. The threshold vehicle risk score preference indicates which vehicles may be matched with the user. In particular, those vehicles 108 having a vehicle risk score above the threshold vehicle risk score preference will not be matched with the user. It should be understood that the threshold vehicle risk score preference may be initially set and adjusted by the user via a user device or any other device in communication with a server.

[0054] Before matching a vehicle 108 with the user 106 who sent the user ride request, the remote computing device 102 identifies which of the vehicles 108 registered with the remote computing device 102 are available. As used herein, the term "available" refers to those vehicles 108 that can be selected to match with the user 106. For example, these available vehicles 108 may be vehicles 108 that are not currently transporting any passengers or are in the process of having current passengers being dropped off so that the user 106 can pick up the vehicle within the requested pickup time. Thereafter, at box 608, the user / vehicle matching logic 308 of the remote computing device 102 identifies a subset of available vehicles 108 having a vehicle risk score that is equal to or lower than the threshold vehicle risk score preference of the user 106 who sent the user ride request. As described herein with respect to the process 500, the vehicle risk score of each vehicle 108 is continuously adjusted based on one or more vehicle risk score factors, and the adjusted vehicle risk score is stored in the vehicle database 302 associated with the particular vehicle 108.

[0055] At box 610, the remote computing device 102 identifies a threshold user risk score preference for each vehicle 108 in the subset of available vehicles 108. As described herein, the threshold user risk score preference for each vehicle 108 is stored in the vehicle database 302 of the remote computing device 102. The remote computing device 102 limits the subset of available vehicles 108 to those vehicles 108 that are willing to accept the particular user 106 that sent the user ride request. At box 612, the user / vehicle matching logic 308 may cause the remote computing device 102 to limit the subset of available vehicles 108 to those vehicles 108 that have a threshold user risk score preference that is equal to or higher than the user risk score of the user 106 that sent the user ride request. Thus, the vehicles 108 within the subset of available vehicles 108 will each have a vehicle risk score that is equal to or lower than the threshold vehicle risk score preference of the user 106 that sent the user ride request and a threshold user risk score preference that is equal to or higher than the user risk score of the user 106 that sent the user ride request.

[0056] After limiting the subset of available vehicles 108 to those vehicles 108 that meet the above parameters, one or more ride options are presented to the user 106 at box 614 for selecting one of the vehicles 108 in the subset of available vehicles 108 for the user's ride request. In particular, the ride options are presented to the user 106 by displaying the ride options on the user interface 234 of the user device 104. It should be understood that in an embodiment, only one option of the available vehicle 108 may be presented to the user. However, when multiple ride options of the available vehicles 108 are presented, the user 106 may select one of the vehicles 108 that matches therewith. In an embodiment, the remote computing device 102 may organize the presentation of the ride options of the available vehicles 108 based on one or more characteristics. For example, the ride options of the available vehicles 108 may be ranked based on the vehicle risk score, so that the user 106 can quickly determine which vehicles 108 have a lower or higher vehicle risk score. In an embodiment, the ride options of the available vehicles 108 may be ranked based on price. For example, if the user risk score of the user 106 is closer to the threshold user risk score preference for a particular vehicle 108, certain ride options for the available vehicles 108 may have higher prices. This may therefore inhibit the user 106 from selecting certain available vehicles 108. Once the user 106 selects one of the presented ride options, the user / vehicle matching logic 308 of the remote computing device 102 will assign the selected vehicle 108 to the user ride request and send instructions to the selected vehicle 108 to pick up the user 106.

[0057] It should be appreciated from the above that what is defined herein is a vehicle matching system in which a user sending a user ride request is matched with an available vehicle having a vehicle risk score equal to or below a threshold vehicle risk score preference of the requesting user. In addition, the user may be matched with a vehicle having a threshold user risk score preference equal to or above the user risk score of the requesting vehicle. This ensures that the user is matched with a vehicle that the user feels comfortable riding in, and in addition, the operator of the matched vehicle feels comfortable transporting the requesting user.

[0058] Although specific embodiments have been illustrated and described herein, it will be appreciated that various other modifications and variations may be made without departing from the scope of the claimed subject matter. In addition, although various aspects of the claimed subject matter are described herein, such aspects need not be used in combination. Therefore, the appended claims are intended to cover all such modifications and variations within the scope of the claimed subject matter.

Claims

1. A method for matching a vehicle with a user, comprising: receiving, by a computing device, a user ride request from a user for a vehicle among a plurality of available vehicles; receiving, by the computing device, a threshold vehicle risk score preference associated with the user; determining, by the computing device, a user risk score associated with the user; determining, by the computing device, a vehicle risk score associated with at least one available vehicle of the plurality of available vehicles; receiving, by the computing device, a threshold user risk score preference associated with each available vehicle of the plurality of available vehicles; identifying, by the computing device, one or more vehicles within the subset of the plurality of available vehicles, the one or more vehicles having an associated vehicle risk score equal to or below the threshold vehicle risk score preference associated with the user and an associated threshold user risk score preference equal to or above the user risk score associated with the user; presenting one or more ride options to the user for selecting one of the one or more vehicles in the subset of the plurality of available vehicles for the user ride request; as well as A selection of the one of the one or more vehicles by the user is received from a user device.

2. The method according to claim 1, further comprising: The vehicle risk score associated with a vehicle in the plurality of available vehicles is adjusted based on one or more vehicle risk score factors.

3. The method according to claim 2, wherein: The one or more vehicle risk score factors include a location of the vehicle of the plurality of available vehicles within a geographic area determined to be a high risk area and a duration of time the vehicle of the plurality of available vehicles has been within the geographic area.

4. The method according to claim 2, wherein: The one or more vehicle risk score factors include one or more of time elapsed and distance traveled since an occurrence of a cleaning event in the vehicle of the plurality of available vehicles.

5. The method according to claim 4, further comprising: In response to detecting a triggering event from a cleaning device in a vehicle of the plurality of available vehicles, an occurrence of the cleaning event is detected.

6. The method according to claim 2, wherein: The one or more vehicle risk score factors include a number of previous occupants of the vehicle in the plurality of available vehicles and associated user risk scores of the previous occupants.

7. The method according to claim 1, further comprising: A user risk score associated with the user is adjusted based on one or more user risk score factors.

8. The method according to claim 7, wherein: The one or more user risk score factors include the location of the user within a geographic area determined to be a high-risk area and a duration of time the user was in the geographic area.

9. The method according to claim 7, wherein: The one or more user risk score factors include health data collected from the user.

10. The method according to claim 1, wherein: The one or more ride options presented to the user are assigned a price corresponding to a vehicle risk score associated with a vehicle in the subset of the plurality of available vehicles.

11. A vehicle matching system, comprising: A computing device, the computing device comprising a controller, the controller being configured to: receiving a user ride request from a user associated with a vehicle from a plurality of available vehicles; receiving a threshold vehicle risk score preference associated with the user; determining a user risk score associated with the user; determining a vehicle risk score associated with the plurality of available vehicles; receiving a threshold user risk score preference associated with the plurality of available vehicles; identifying one or more vehicles within the subset of the plurality of available vehicles, the one or more vehicles having an associated vehicle risk score equal to or below the threshold vehicle risk score preference associated with the user and an associated threshold user risk score preference equal to or above the user risk score associated with the user; presenting one or more ride options to the user for selecting one of the one or more vehicles in the subset of the plurality of available vehicles for the user ride request; as well as A selection of the one of the one or more vehicles by the user is received from a user device.

12. The vehicle matching system according to claim 11, wherein the computing device further comprises: a user database including user data for a plurality of users, the user data including user risk scores and threshold user risk score preferences associated with the plurality of users; as well as A vehicle database includes vehicle data associated with the plurality of available vehicles, the vehicle database including vehicle risk scores and threshold vehicle risk score preferences associated with the plurality of available vehicles.

13. The vehicle matching system according to claim 12, wherein: The computing device receives user data from a user device of the user; and The computing device receives vehicle data from the plurality of available vehicles.

14. The vehicle matching system according to claim 13, wherein: The vehicle risk score associated with a vehicle in the plurality of available vehicles is adjusted based on one or more vehicle risk score factors.

15. The vehicle matching system according to claim 14, wherein: The one or more vehicle risk score factors include a location of the vehicle of the plurality of available vehicles within a geographic area determined to be a high risk area and a duration of time the vehicle of the plurality of available vehicles has been within the geographic area.

16. The vehicle matching system according to claim 14, wherein: The one or more vehicle risk score factors include an elapsed time or a distance traveled since an occurrence of a cleaning event in the vehicle of the plurality of available vehicles.

17. The vehicle matching system according to claim 14, wherein: The one or more vehicle risk score factors include a number of previous occupants of the vehicle in the plurality of available vehicles and associated user risk scores of the previous occupants.

18. The vehicle matching system according to claim 13, wherein: The user risk score associated with the user is adjusted based on one or more user risk score factors.

19. The vehicle matching system according to claim 18, wherein: The one or more user risk score factors include the location of the user within a geographic area determined to be a high-risk area and a duration of time the user was in the geographic area.

20. A vehicle matching system, comprising: A computing device, the computing device comprising a controller, the controller being configured to: receiving a user ride request from a user for a vehicle from a plurality of available vehicles; identifying one or more vehicles within the subset of the plurality of available vehicles, the one or more vehicles having an associated vehicle risk score equal to or below a threshold vehicle risk score preference associated with the user and an associated threshold user risk score preference equal to or above a user risk score associated with the user; presenting one or more ride options to the user for selecting one of the one or more vehicles in the subset of the plurality of available vehicles for the user ride request; as well as A selection of the one of the one or more vehicles by the user is received from a user device.

Images