Vehicle allocation systems and procedures for assigning a user to a vehicle

Abstract

Method for assigning a vehicle (108) to a user (106), comprising: Receiving, by a computing device (102), a user ride-sharing request for a vehicle (108) from a plurality of available vehicles (108) from a user (106); Received by the computing device (102), a vehicle risk assessment threshold preference associated with the user (106); Determine, by the computing device (102), a user risk assessment that is associated with the user (106); Determine, by means of the calculating device (102), a vehicle risk assessment that is associated with at least one of the plurality of available vehicles (108); Received, by the computing device (102), a user risk assessment threshold preference associated with each of the plurality of available vehicles (108); Identify, by the computing device (102), one or more vehicles (108) within a subset of the plurality of available vehicles (108) that have an associated vehicle risk rating at or below the vehicle risk rating threshold preference associated with the user (106) and an associated user risk rating threshold preference at or above the user risk rating associated with the user (106); present, to the user (106), one or more ride-sharing options for selecting one of the one or more vehicles (108) from the subset of the plurality of available vehicles (108) for the user ride-sharing request; and Receiving a selection by the user (106) from a user device of one of the one or several vehicles (108).

Description

Technical field

[0001] The present invention relates generally to vehicle systems for assigning a vehicle to a user, and in particular to passenger vehicle systems in which a specific vehicle is assigned to a user based on a risk assessment of the user and a risk assessment of the vehicle. background

[0002] Ride-sharing services are widely used to pick up a user from a specific location and transport them to a desired destination. Current ride-sharing services can assign ratings to both drivers and passengers. In some cases, drivers may decline requests from a user based on a low rating. A low rating could indicate negative past experiences with other drivers. Similarly, a user may have the option to decline a ride offered by a specific driver based on a low rating assigned to that driver. However, these ratings are not based on any factors associated with a potential health risk to the driver or passenger.Furthermore, current ride-sharing services do not match users and drivers based on these ratings, even though both the driver and the user may have the option to decline a ride or passenger. Examples of such systems are addressed in US 2021 / 0 056 477 A1, US 10 152 053 B1, US 2019 / 0 168 711 A1, US 2018 / 0 276 485 A1, US 2022 / 0 018 886 A1, and US 10 593 213 B1.

[0003] Accordingly, there is a need for improved systems and procedures for the mutual matching of vehicles and users based on risk assessments that are associated with both the user and the vehicle. Summary

[0004] In one embodiment, a method for assigning a vehicle to a user comprises: receiving, by a computing device, a user ride-sharing request for a vehicle from a plurality of available vehicles from a user; receiving, by the computing device, a vehicle risk assessment threshold preference associated with the user; determining, by the computing device, a user risk assessment associated with the user; determining, by the computing device, a vehicle risk assessment associated with at least one of the plurality of available vehicles; receiving, by the computing device, a user risk assessment threshold preference associated with each of the plurality of available vehicles; and identifying, by the computing device, one or more vehicles within a subset of the plurality of available vehicles.which have an associated vehicle risk rating at or below the vehicle risk rating threshold preference associated with the user, and an associated user risk rating threshold preference at or above the user risk rating associated with the user, and presenting ride-sharing options to the user to select one from the subset of the plurality of available vehicles from the subset of available vehicles for the user ride-sharing request, and receiving a selection by the user from a user device of the one of the one or more vehicles.

[0005] In another embodiment, a vehicle allocation system comprises a computing device having a controller configured to receive a user ride-sharing request associated with a vehicle from a plurality of available vehicles, to receive a vehicle risk rating threshold preference associated with the user, to determine a user risk rating associated with the user, to determine a vehicle risk rating associated with the plurality of available vehicles, to receive a user risk rating threshold preference associated with the plurality of available vehicles, and to identify one or more vehicles within a subset of the plurality of available vehicles that have an associated vehicle risk rating at or below the vehicle risk rating threshold preference associated with the user.and associated a user risk assessment threshold preference at or above the user risk assessment associated with the user, and to present the user with options to select one from the subset of the plurality of available vehicles from the subset of available vehicles for the user ride-sharing request, and to receive a selection by the user from a user device of the one of the one or more vehicles.

[0006] In another embodiment, a vehicle allocation system comprises a computing device having a controller configured to receive a user ride-sharing request for a vehicle from a plurality of available vehicles from a user, to identify one or more vehicles within a subset of the plurality of available vehicles that have an associated vehicle risk rating at or below a vehicle risk rating threshold preference associated with the user, and an associated user risk rating threshold preference at or above the user risk rating associated with the user, and to present the user with one or more ride-sharing options to select one of the one or more vehicles from the subset of available vehicles for the user ride-sharing request.and to receive a selection by the user from a user device of one of the one or more vehicles.

[0007] These and other features created by the embodiments described herein will be more fully understood in light of the following detailed description together with the drawing. Brief description of the drawing

[0008] The embodiments shown in the drawing 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 exemplary embodiments will be understandable when read together with the following drawing, where similar structures are designated with similar reference numerals, and in which: Fig. 1 schematically represents a vehicle allocation system comprising a server that communicates with a plurality of user devices and a plurality of vehicles, according to one or more embodiments shown and described herein; Fig. 2 schematically individual components of the server, a vehicle and a user device of the vehicle allocation system of Fig. 1 according to one or more embodiments shown and described herein; Fig. 3 schematically represents a storage component of the server according to one or more embodiments shown and described herein; Fig. 4 schematically represents a method for assigning a user risk assessment to a user according to one or more embodiments shown and described herein; Fig. 5 schematically represents a method for assigning a vehicle risk assessment to a vehicle according to one or more embodiments shown and described herein; and Fig. Figure 6 schematically represents a method for assigning a vehicle to a user according to one or more embodiments shown and described herein. Detailed description

[0009] The embodiments described herein relate to systems and methods for assigning available vehicles to users based on risk assessments associated with the users and the vehicles. The vehicle assignment system comprises a server, which includes a controller configured to receive a user ride-sharing request for a vehicle from a plurality of available vehicles, to identify a subset of the plurality of available vehicles that have a vehicle risk assessment at or below the user's vehicle risk assessment threshold preference and a user risk assessment threshold preference at or above the user's user risk assessment, and to present the user with options to select one of the subset of available vehicles for the user ride-sharing request.Various embodiments of the systems, methods, and operation of the system are described in more detail herein. Where possible, the same reference numerals are used throughout the drawing to refer to the same or similar parts.

[0010] It will now be on Fig. Reference is made to a vehicle allocation system 100 according to one or more embodiments described herein. The present vehicle allocation system 100 is particularly useful with ride-sharing applications in which a user, by means of a user device, sends a signal containing a user ride-sharing request, asking to be picked up at a specific location and driven to a destination. The vehicle allocation system 100 comprises a remote computing device 102, which communicates with a plurality of user devices 104, operated by respective users 106, and a plurality of vehicles 108, via a network 110. The network 110 can be configured as an internet, mobile communication network, satellite-based network, LAN connection, Wi-Fi connection, etc.The remote computing device 102 can be configured as any computing device to perform the functionality described herein, such as a server, a personal computer, a tablet, a mobile computing device, etc. The user devices 104 can be any computing device, a mobile computing device, a mobile phone, etc. The user devices 104 are pre-registered with the remote computing device 102. The user devices 104 can be associated with respective user profiles stored in the remote computing device 102. Similarly, the vehicles 108 can 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 profiles and the vehicle profiles can include associated risk assessments and associated risk assessment threshold preferences.In particular, a user profile can include user data, which includes a user risk assessment and a vehicle risk assessment threshold preference. Likewise, a vehicle profile can include vehicle data, which includes a vehicle risk assessment and a user risk assessment threshold preference. The various risk assessments and risk assessment threshold preferences can be used by the remote computing device 102 to assign a user device 104, in particular a user 106 who possesses the user device 104, to one of the plurality of vehicles 108 in the manner described herein.

[0011] It will now be on Fig. 2 Reference is made to a schematic representation of an embodiment of the vehicle allocation system 100, comprising one of the user devices 104, one of the vehicles 108 and the network 110, according to one or more embodiments shown and described herein. It is understood that, although in Fig. 2 where only a user device 104 and a vehicle 108 are shown, the vehicle allocation system 100 can include any number of user devices 104 and vehicles 108 based on the existing number of user devices 104 and devices 108.

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

[0013] The communication path 201 can be formed from any medium capable of transmitting a signal, such as conductive wires, conductor tracks, optical fibers, or the like. Furthermore, the communication path 201 can be formed from a combination of media capable of transmitting signals. In one embodiment, the communication path 201 comprises a combination of conductor tracks, conductive wires, connectors, and buses that cooperate to allow the transmission of electrical data signals to components such as processors, memory, sensors, input devices, output devices, and communication devices. Similarly, the communication path 201 can comprise a bus, such as a LIN bus, a CAN bus, a VAN bus, and the like. It should also be noted that the term "signal" means a waveform (e.g., a waveform).electrical, optical, magnetic, mechanical, or electromagnetic), such as a direct current (DC), an alternating current (AC), a sine wave, a triangle wave, a square wave, a vibration, and the like, capable of traveling through a medium. Communication path 201 connects the various components of the server in a communication-capable manner. As used here, the term "communication-capable connected" means that connected components are able to exchange data signals with each other, such as electrical signals via a conductive medium, electromagnetic signals through the air, optical signals via optical fibers, and the like.

[0014] As noted above, the remote computing device 102 comprises the controller 200, which includes the processor 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. Accordingly, 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 connected to the other components of the remote computing device 102 via the communication path 201. Accordingly, the communication path 201 can communicatively couple any number of processors and allow the modules coupled to the communication path 201 to operate in a distributed computing environment.In particular, each of the modules can be operated as a node that can send and / or receive data.

[0015] Each of the one or more memory components 204 of the remote computing device 102 is coupled to the communication path 201 and communicatively coupled to the one or more processors 202. The one or more memory components 204 may include RAM, ROM, flash memory, hard disks, and / or other hardware or firmware capable of storing machine-readable instructions so that these instructions can be accessed and executed by the one or more processors 202. The machine-readable instructions may include logic or one or more algorithms written in any programming language of any generation (e.g., 1GL, 2GL, 3GL, 4GL, or 5GL), such as machine language that can be executed directly by the processor, or assembly language, object-oriented programming (OOP), scripting languages, microcode, etc., which is 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 either via a field-programmable gate array (FPGA) configuration, an application-specific integrated circuit (ASIC), or equivalent. Similarly, the methods described herein may be implemented in any conventional computer programming language, as pre-programmed hardware elements, or as a combination of hardware and software components.

[0016] It will now be on Fig. Reference is made to an embodiment of one or more storage components 204, comprising a user database 300, a vehicle database 302, a user risk assessment update logic 304, a vehicle risk assessment update logic 306, and a user / vehicle assignment logic 308. The user database 300 includes a list of all user devices 104 registered in the vehicle assignment system 100. In particular, the user database 300 includes data collected from the user devices 104, such as location information, history of previous rides, and the like. The user database 300 also includes a user risk assessment and a vehicle risk assessment threshold preference, which are associated with each user device 104.In particular, the vehicle database 302 includes data collected from the vehicles 108, such as location information, history of previous rides, history of previous occupants, history of previous cleanings, and the like. The vehicle database 302 also includes a vehicle risk assessment and a user risk assessment threshold preference, which are associated with each vehicle 108.

[0017] The user risk assessment update logic 304 causes the remote computing device 102 to adjust the user risk assessment of one or more of the user devices 104 stored in the user database 300. Specifically, the user risk assessment 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 assessment of each user device 104 should be adjusted. Similarly, the vehicle risk assessment update logic 306 causes the remote computing device 102 to adjust the vehicle risk assessment of vehicles 108 stored in the vehicle database 302.In particular, the vehicle risk assessment update logic 306 can cause the remote computing device 102 to analyze the data received from the vehicles 108 to determine how the vehicle risk assessment of each vehicle 108 should be adjusted. The user / vehicle assignment logic 308 causes the remote computing device 102 to analyze the user risk assessment and the vehicle risk assessment threshold preference of a user device 104 transmitting a user ride-sharing request, in order to assign an available vehicle 108 to the user device 104 based on the vehicle risk assessment and the user risk assessment threshold preference of the available vehicles 108.In some embodiments, the user / vehicle assignment logic 308 of the user device 104, which transmits the user ride-sharing request, can assign a plurality of vehicles 108 in order to present the user 106 of the user device 104 with one or more ride-sharing options in order to select a specific one of the vehicles 108.

[0018] It will be revisited Fig. 2 Referenced, where the vehicle 108 comprises a controller 208, comprising one or more processors 210 and one or more memory components 212, a communication path 209, network interface hardware 214, one or more interior sensors 216, a location sensor 218, a user interface 220, and a cleaning device 222. The various components of the vehicle 108 and their interaction are described in detail below. However, it should be noted that in embodiments, the vehicle 108 may comprise fewer components than those described herein, or additional components not described herein.

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

[0020] The one or more interior sensors 216 are coupled to the communication path 209 and are capable of communication with the one or more processors 210. The one or more sensors 216 can 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 can be detected. The temperature sensor can be a handheld temperature sensor, such as an infrared thermometer, to measure the temperature of an occupant in the vehicle 108. Accordingly, either by the temperature sensor itself or by processing in the controller 208, it can be determined from temperature readings detected by the temperature sensor that an occupant of the vehicle 108 has a temperature above a predetermined temperature.As described in the present, the occupant's temperature, as detected by the temperature sensor, can be used to adjust the vehicle risk assessment of vehicle 108.

[0021] In embodiments, one or more of the interior sensors 216 may include an audio detection sensor to detect and identify or classify specific sounds within the vehicle 108. In embodiments, the audio detection sensor includes a microphone to detect noise levels within the vehicle 108 and a noise analysis device to identify or classify the type of sound detected by the microphone. In some embodiments, the audio detection sensor may transmit a signal, including audio data relating to the detected sound, to the controller 208 to analyze the detected sound and identify its type. In particular, the detected sound may be identified or classified as, for example, coughing, sneezing, vomiting, or the like.As described in the present, the noise detected inside the vehicle 108 by the audio detection sensor can be used to adjust the vehicle risk assessment of the vehicle 108.

[0022] As noted above, the vehicle 108 includes a location sensor 218, which is coupled to the communication path 209 and is communicatively paired with the one or more processors 210. The location sensor 218 can be a satellite-based radio navigation device, such as a GPS device, to track the driving behavior of the vehicle 108, such as its location, the distance traveled, and the like. In particular, the location sensor 218 can track the location of the vehicle 108 to determine when the vehicle 108 is traveling into a geographic region that has been identified as a high-risk area, such as an area with a population density above a predetermined population density threshold, an area with an infection rate above a predetermined threshold, an area where a superspreader event recently occurred, etc.Population density can be determined by dividing the size of the geographic area by the population within that area. If the population density exceeds a predetermined threshold, the geographic area can be classified as a high-risk area. For example, a geographic area can also be classified as a high-risk area if the size of the geographic area divided by the infection rate (i.e., the number of confirmed new cases of an illness, disease, or symptoms) exceeds a predetermined threshold indicating a greater likelihood of exposure to an illness, disease, or symptoms within the geographic area. Additionally, location sensor 218 can determine how long vehicle 108 remains in the geographic region.In embodiments, it can be determined, based on data collected by a remote system connected to the remote computing device 102 and / or the vehicle 108, that the geographic region is a high-risk area. The remote system can thus provide a map indicating multiple geographic regions as high-risk areas, and the vehicle 108's location sensor 218 detects, based on the vehicle 108's location and a known location of the geographic high-risk regions, when the vehicle 108 enters one of these regions. As described herein, the location of the vehicle 108 entering a geographic area determined to be a high-risk area, as well as the duration or length of time the vehicle 108 spends in that specific geographic area, can be used to adjust the vehicle 108's risk assessment.

[0023] As mentioned above, the vehicle 108 includes the user interface 220 to provide a visual output, such as 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 the one or more processors 210. The user interface 220 can include any medium capable of transmitting an optical output, such as a cathode ray tube, light-emitting diodes, a liquid crystal display, a plasma display, a projection display, a holographic display, an augmented or enhanced display, or the like. Furthermore, the user interface 220 can include a haptic actuator capable of converting mechanical, optical, or electrical signals into a data signal that can be transmitted via the communication path 209.In particular, the haptic actuation device can comprise any number of movable objects, each of which converts a physical movement into a data signal that can be transmitted via the communication path 209, such as a button, a switch, a rotary knob, or the like. In embodiments, a haptic actuation device can be a touchscreen which, in addition to providing visual information, detects the presence and location of a haptic input. The user interface 220 can request input from a person inside the vehicle 108, such as a driver or operator of the vehicle 108 or an occupant of the vehicle 108.The user interface 220 can, for example, query whether a cleaning process of vehicle 108 has taken place, when the last cleaning process of vehicle 108 took place, where vehicle 108 has been traveling, how long vehicle 108 has been traveling, how many passengers vehicle 108 has been carrying, and similar information. As described in detail below, the input received at the user interface 220 can be used to respond to the queries in order to adjust the vehicle risk assessment of vehicle 108.

[0024] As mentioned above, the vehicle 108 includes the cleaning device 222 for cleaning or disinfecting the vehicle 108, such as seating surfaces and the like. 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 can include any known or yet-to-be-developed device for cleaning and / or disinfecting at least sections of the vehicle 108. For example, the cleaning device 222 can include one or more drying devices, such as an ultraviolet or high-temperature heat lamp, a disinfectant spray nozzle for ejecting a solution, an ozone generator, a vacuum cleaner, and the like.The cleaning device 222 can be manually operated by a driver or operator of the vehicle 108 and / or automatically activated in response to one or more cleaning triggers, such as after a predetermined time period, after a predetermined number of occupants have been transported, after a predetermined distance has been traveled, or the like. When the cleaning device 222 is activated, either in response to manual operation or a cleaning trigger, a time is recorded indicating the activation of the cleaning device 222, i.e., a cleaning operation. As described in more detail below, the elapsed time since a cleaning operation can be used to adjust the vehicle risk assessment of the vehicle 108. In some embodiments, the operator of the vehicle 108 can manually indicate via the user interface 220 that a cleaning operation has taken place.

[0025] Further with reference to Fig. 2. The user device 104 comprises a controller 224 including one or more processors 226 and one or more memory components 228, a communication path 225, network interface hardware 230, a location sensor 232, and a user interface 234. The various components of the user device 104 and their interaction are described in detail below. However, it should be noted that in embodiments, the user device 104 may comprise fewer components than those described herein, or additional components not described herein.

[0026] The components of the user device 104 can be structurally similar to the corresponding components of the vehicle 108 and have similar functions to them (e.g., the controller 224 corresponds to the controller 208, the communication path 225 corresponds to the communication path 209, the network interface hardware 230 corresponds to the network interface hardware 214, the location sensor 232 corresponds to the location sensor 218, and the user interface 234 corresponds to the user interface 220).

[0027] 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 104 enters a geographic region that has been determined to be a high-risk area, i.e., an area with a population density above a predetermined population density threshold. Based on the location of the user device 104 and a known location of the geographic high-risk regions, the location sensor 232 of the user device 104 detects when the user device 104 enters one of the geographic regions, as well as when the user device 104 leaves the geographic region.Accordingly, the location sensor 232 can determine how long the user device 104 remains in the geographic region. It is understood that high-risk areas for the user device 104 may be the same as the high-risk areas described above with reference to the vehicle 108, or others. As described above, the location of the user device 104 entering a geographic area designated as high-risk, as well as the duration or length of time the user device 104 remains in that specific geographic area, can be used to adjust the user risk assessment of the user 106.

[0028] 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 connected 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, test results, multiple-choice questions, vaccination status, previous contact or interaction with others, and the like, in order to determine a potential risk that the user 106 may pose to others upon contact or in close proximity. As described in detail below, the input received at the user interface 234 can be used to respond to the queries and adjust the user risk assessment of the user 106.

[0029] It will now be on Fig. Reference is made to a process 400, which is described for adjusting a user risk assessment of a user based on one or more user risk assessment factors collected by monitoring user activity via a user device. Process 400 is explained with reference to the vehicle assignment system 100 and, in particular, the remote computing device 102, which communicates with the user device 104, which is located in Fig. 2 is shown, and the memory component 204 of the remote computing device 102, which is in Fig. 3 is shown.

[0030] At block 402, the remote computing device 102 assigns an initial user risk score to each user 106 registered with the remote computing device 102. A user 106's initial user risk score can be assigned during an initial registration process, in which the user 106 is asked a series of questions regarding their previous activities and current health, including vaccination status, test results, and the like. This initial data can be collected by displaying queries on the user interface 234 of the remote computing device 104 and receiving input from the user 106 via the user interface 234. The initial user risk score is then associated with the user 106 and stored in the user database 300 of the storage component 204 of the remote computing device 102.As a non-restrictive example, the initial user risk score can be determined by assigning one or more points to each query presented to the user. For each query that elicits a response determined to pose a risk, one or more points are added based on the risk level assigned to the response to determine the initial user risk score.

[0031] Subsequently, one or more user risk assessment factors are identified that are used to adjust the user risk assessment factor, as detailed herein. This allows the user risk assessment to be adjusted on a continuous basis to provide a customized user risk score for user 106 based on user 106's activity. In embodiments, the one or more user risk assessment factors may be based on updated health or risk data collected from user 106 via the user device 104. Similar to how the initial user risk score is determined, one or more points may be assigned to the user risk assessment factors based on the related data, and these one or more points are then applied to the initial user risk score to provide an increased user risk score.

[0032] For example, at block 404, the remote computing device 102 sends a signal to the user device 104 to request user-risk-related information. As noted above, the request might include, for example, queries regarding the user's health data, test results, multiple-choice questions, vaccination status, previous contact or interaction with others, and the like, to determine a potential risk that the user 106 may pose to others through contact or close proximity. At block 406, the user 106 activates the user interface 234 of the user device 104 to answer the queries in any appropriate manner and provide feedback, for example, by selecting predefined answers, entering custom answers, submitting images, or the like.As a non-restrictive example, a user can submit answers and, in some embodiments, may include documentation as evidence regarding test results or vaccination status. In Block 408, the remote computing device 102 can perform a verification of the feedback received from user 106 via user device 104. This verification may, for example, include confirming feedback from user 109 by verifying the authenticity of provided documentation.

[0033] Another example where health or risk data can be collected from User 106 for the purpose of customizing the user risk assessment is to receive user-specific information from a publicly available source. For example, Remote Computing Device 102 at Block 410 can request health data from publicly available health databases, such as those of a state, regional, or other public health agency that collects health data on registered participants. By identifying User 106 from among these participants in a publicly available health database, Remote Computing Device 102 can collect health data relating to that User 106.

[0034] Another example where health or risk data can be collected is by tracking the location of user device 104 to determine whether user 106 has entered a high-risk area. As explained above, user device 104 includes location sensor 232 to track its location. Thus, at Block 412, the location of user device 104 is monitored using location sensor 232. At Block 414, either remote computing device 102 or user device 104 itself determines whether the location of user device 104, tracked by location sensor 232, is within a geographic area designated as high-risk. As explained above, a geographic area can be designated as high-risk based on population density within that specific geographic area.It can also be determined that a geographic area is a high-risk area based on health data concerning individuals within that geographic area, for example, recorded diseases and the like. In embodiments, the location sensor 232 of the user device 104 at block 416 records a duration or time span during which the user 106 is within the high-risk area. Accordingly, the location sensor 232 can indicate a time at which the user 106 enters the high-risk area and a time at which the user 106 leaves the high-risk area in order to determine the total length of time spent within the high-risk area.

[0035] At block 418, the remote computing device 102, specifically the user risk assessment update logic 304, updates the user risk assessment stored in the user database 300 based on the one or more user risk assessment factors discussed herein. Specifically, the user risk assessment is updated by either increasing or decreasing the initial user risk assessment in response to one or more user risk assessment factors indicating an increased or decreased risk. For example, if the user risk-related information collected in blocks 404-408 indicates an increased risk, the user risk assessment update logic 304 will increase the user risk assessment.In some embodiments, the user risk assessment update logic 304 will decrease the user risk assessment if the user risk-related information collected in blocks 404-408 indicates no risk or a low risk, such as that user 106 has received all vaccinations. Similarly, the user risk assessment update logic 304 can cause the remote computing device 102 to increase or decrease the user risk assessment based on the user-specific information collected from the publicly available source in block 410.User risk assessment update logic 304 can also cause the user risk assessment to be increased or decreased based on whether or not user device 104 has entered a geographic area designated as high-risk, as well as increasing the user risk assessment proportionally to the length of time user device 104 remains in that specific geographic area. Once the user risk assessment has been adjusted at block 418, the adjusted user risk assessment is stored in the user database. Blocks 404-416 can be repeated at any given time to update the user risk assessment based on updated information collected by user device 104.

[0036] It will now be on Fig. 5 Referenced; a process 500 is shown for adjusting a vehicle risk assessment of a vehicle 108 based on one or more vehicle risk assessment factors that are collected by monitoring an activity of the vehicle 108. The process 500 is explained with reference to the vehicle assignment system 100 and, in particular, the remote computing device 102 that communicates with the vehicle 108, which is located in Fig. 2 are shown, and the memory component 204 of the remote computing device 102, which is in Fig. 3 is shown.

[0037] At block 502, the remote computer 102 assigns an initial vehicle risk score to the vehicle 108, which was previously registered in the remote computer 102. As explained above, the initial vehicle risk score can be assigned during an initial registration process in which an operator of the vehicle 108 is presented with a series of queries relating to a previous activity of the vehicle 108, such as when a last cleaning operation took place. This initial data can be collected by displaying 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 point values ​​to the input from the operator.The initial vehicle risk assessment is accordingly associated with vehicle 108 and stored in the vehicle database 302 of the storage component 204 of the remote computing device 102.

[0038] Subsequently, one or more vehicle risk assessment factors are identified that are used to adjust the vehicle risk assessment factor, as explained in detail herein. This allows the vehicle risk assessment to be continuously adjusted to provide an updated vehicle risk assessment for vehicle 108. In embodiments, the one or more vehicle risk assessment factors can be based on an activity of vehicle 108.

[0039] For example, at block 504, the remote computing device 102 sends a signal to the vehicle 108 to request vehicle risk-related information. As noted above, the request might include, for example, queries regarding health data for an operator of the vehicle 108, such as the operator's test results, multiple-choice questions, vaccination status, previous contact or interaction with others, and the like, to determine a potential risk that the operator of the vehicle 108 may pose to others through contact or close proximity. At block 506, the operator uses the user interface 220 of the vehicle 108 to answer the queries in any appropriate manner and provide feedback, for example, by selecting predefined answers, entering user-defined answers, submitting images, or the like.Similar to Block 408 described above, some embodiments may be configured to provide verification so that the feedback received from the operator of the vehicle 108 can be verified. In embodiments, the vehicle risk-related information may include a temperature reading or a sound detected by the one or more interior sensors 216 of the vehicle, as explained herein, to determine, for example, whether an occupant has a temperature above a predetermined temperature threshold or has vomited in the vehicle 108.

[0040] Another example where risk data can be collected is by identifying a user risk rating of previous occupants of vehicle 108. Thus, the remote computing device 102 at block 508 identifies which occupants were previously transported by vehicle 108 and, in particular, identifies a user risk rating for those occupants registered with the remote computing device 102 for whom a user risk rating has been assigned. As described in more detail below, the user risk rating of these occupants of vehicle 108 can be used to adjust the vehicle risk rating of vehicle 108.

[0041] Another example where risk data can be collected is by tracking the vehicle's location to determine whether the vehicle 108 is entering a high-risk area. As explained above, the vehicle 108 includes the location sensor 218 for tracking its location. Thus, at Block 510, the location of the vehicle 108 is monitored using the vehicle 108's location sensor 218. At Block 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, is entering a geographic area that has been determined to be a high-risk area. The method for determining whether a geographic area is a high-risk area can be the same as explained above regarding the geographic high-risk areas for the user device 104.Accordingly, the high-risk geographical areas can be the same as or different from those geographical areas designated as high-risk for the user device 104. In embodiments, the vehicle 108's location sensor 218 at block 514 detects a duration or time span during which the vehicle 108 is within the high-risk area. The location sensor 218 can thus indicate a time at which the vehicle 108 enters the high-risk area and a time at which the vehicle 108 leaves the high-risk area to determine the total length of time spent within the high-risk area.

[0042] Another example where risk data can be collected is by determining whether a cleaning process has taken place. As explained above, in embodiments, the vehicle 108 can be equipped with the cleaning device 222 to disinfect the vehicle 108. In block 516, the remote computing device 102 detects whether the cleaning device 222 has been activated, i.e., whether a triggering process has occurred to clean the vehicle 108, and thus whether a cleaning process has taken place. In addition to detecting whether a cleaning process has taken place in the vehicle 108, the remote computing device 102 also determines the elapsed time since the cleaning process took place. It is understood that the elapsed time since a cleaning process can be received by input from the operator of the vehicle 108 via the user interface 220 of the vehicle 108.

[0043] Finally, at block 518, the remote computing device 102, via the vehicle risk assessment update logic 306, updates the vehicle risk assessment stored in the vehicle database 302 based on one or more vehicle risk assessment factors described herein. Specifically, the vehicle risk assessment can be updated by either increasing or decreasing the initial vehicle risk assessment in response to one or more vehicle risk assessment factors indicating an increased or decreased risk. For example, if the vehicle risk-related information collected in blocks 504-506 indicates an increased risk, the vehicle risk assessment update logic 306 will increase the vehicle risk assessment.In some embodiments, the vehicle risk assessment update logic 306 will increase the vehicle risk assessment if the vehicle risk-related information collected in blocks 504-506 indicates no risk or a low risk, such as that the operator of the vehicle 108 has received all vaccinations. Similarly, the vehicle risk assessment update logic 306 can cause the remote computing device 102 to increase or decrease the vehicle risk assessment based on the user risk assessment, as determined in block 508, of occupants who were previously transported by the vehicle 108, if such an assessment is provided.Vehicle Risk Assessment Update Logic 306 will also increase or decrease the vehicle risk assessment based on whether or not the vehicle 108 has entered a geographic area determined to be a high-risk area, and will increase the vehicle risk assessment proportionally to the length of time the vehicle 108 remains in that specific geographic area, as determined in blocks 510-514. Furthermore, Vehicle Risk Assessment Update Logic 306 can cause the remote computing device 102 to decrease the vehicle risk assessment based on whether a cleaning operation has taken place, as determined in block 516. Specifically, the vehicle risk assessment can be decreased proportionally to the time elapsed since the last cleaning operation.In other words, the longer the time elapsed since the last cleaning process, the less effect the cleaning process has on the vehicle risk assessment. Once the vehicle risk assessment has been adjusted at block 518, the adjusted vehicle risk assessment is stored in vehicle database 302. Blocks 504-516 can be repeated at any given time to update the vehicle risk assessment based on updated information collected from vehicle 108.

[0044] It will now be on Fig. Reference is made to a process 600, which is described to assign users to vehicles based on the user risk rating and vehicle risk rating threshold preference assigned to each user, as well as the vehicle risk rating and user risk rating threshold preference assigned to each vehicle. Accordingly, the vehicle assignment system 100 assigns a specific vehicle to each user such that the vehicle meets the user's vehicle risk rating threshold preference based on the vehicle's risk rating and the user meets the vehicle's user risk rating threshold preference. The process 600 is described with reference to the Fig. 1, Fig. 2, Fig. 3, Fig. 4 to Fig. 5 explained.

[0045] At block 602, the remote computing device 102 receives a user ride request from a user 106 via a user device 104. The user ride request includes a pickup location, which can 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 or destination location. The user ride request can include additional information, such as a preferred vehicle, a number of passengers, and a pickup or drop-off time.

[0046] As soon as the user ride-sharing request is received, remote computing device 102 at block 604 receives the user risk score assigned to user 106 of user device 104. The user risk score is retrieved from user database 300 of remote computing device 102. As explained above in relation to process 400, the user risk score of each user 106 is continuously adjusted based on one or more user risk assessment factors, and the adjusted user risk score is stored in user database 300 associated with that specific user 106.

[0047] In addition to the user risk rating of user 106 at block 606, remote computing device 102 also receives the vehicle risk rating threshold preference assigned to user 106. The vehicle risk rating threshold preference is also retrieved from the user database 300 of remote computing device 102. The vehicle risk rating threshold preference specifies which vehicles can be assigned to the user. In particular, those vehicles 108 with a vehicle risk rating above the vehicle risk rating threshold preference are not assigned to the user. It is understood that the vehicle risk rating threshold preference can be initially set and adjusted by the user via the user device or any other device connected to the server.

[0048] Before a vehicle 108 is assigned to the user 106 who sends the ride-sharing request, the remote computing device 102 identifies which of the vehicles 108 registered in the remote computing device 102 are available. As used here, the term "available" refers to those vehicles 108 that can be selected to be assigned to a user 106. These available vehicles 108 may, for example, be vehicles 108 that are not currently carrying passengers or from which current passengers are about to disembark, so that the user 106 can be picked up at the requested pickup time. Subsequently, the user / vehicle assignment logic 308 of the remote computing device 102 at block 608 identifies a subset of the available vehicles 108 that have a vehicle risk rating at or below the vehicle risk rating threshold preference of the user 106 who sends the user ride-sharing request.As explained above with regard to process 500, the vehicle risk assessment of each vehicle 108 is continuously adjusted based on one or more vehicle risk assessment factors, and the adjusted vehicle risk assessment associated with the specific vehicle 108 is stored in the vehicle database 302.

[0049] At block 610, the remote computing device 102 identifies a user risk assessment threshold preference for each vehicle 108 in the subset of available vehicles 108. As explained above, the user risk assessment threshold preference of each vehicle 108 is stored in the vehicle database 302 of the remote computing device 102. The remote computing device 102 restricts the subset of available vehicles 108 to those vehicles 108 that are willing to accept the specific user 106 who sends the user ride-sharing request. At block 612, the user / vehicle assignment logic 308 can cause the remote computing device 102 to restrict the subset of available vehicles 108 to those vehicles 108 that have a user risk assessment threshold preference at or above the user risk assessment of the user 106 who is sending the user ride-sharing request.Accordingly, within the subset of available vehicles 108, each vehicle 108 will have a vehicle risk rating at or below the vehicle risk rating threshold preference of user 106 who sends the user ride-sharing request, and a user risk rating threshold preference at or above the user risk rating of user 106 who sends the user ride-sharing request.

[0050] After the subset of available vehicles 108 has been restricted to those vehicles 108 that meet the parameters explained above, one or more ride-sharing options are presented to the user 106 at block 614 to select one of the vehicles 108 from the subset of available vehicles 108 for the user's ride-sharing request. Specifically, the ride-sharing options are presented to the user 106 by displaying them on the user interface 234 of the user device 104. It is understood that in embodiments, only one option for an available vehicle 108 can be presented to the user. However, if multiple ride-sharing options for available vehicles 108 are presented, the user 106 can select one of the vehicles 108 to be assigned to.In embodiments, the remote computing device 102 can organize the presentation of ride-sharing options for available vehicles 108 based on one or more attributes. For example, the ride-sharing options for available vehicles 108 can be ranked based on a vehicle risk rating, allowing the user 106 to quickly determine which vehicles 108 have a lower or higher vehicle risk rating. In embodiments, the ride-sharing options for available vehicles 108 can be sorted based on price. For example, certain ride-sharing options for available vehicles 108 can have a higher price if the user's risk rating 106 is closer to the user's risk rating threshold preference for a specific vehicle 108.

[0051] Accordingly, this can prevent a user 106 from selecting certain available vehicles 108. Once the user 106 selects one of the presented ride-sharing options, the user / vehicle assignment logic 308 of the remote computing device 102 will assign the user's ride-sharing request to the selected vehicle 108 and send instructions to the selected vehicle 108 to pick up the user 106.

[0052] It follows from the above that the present document defines a vehicle allocation system in which a user who sends a ride-sharing request is assigned to an available vehicle whose vehicle risk rating is at or below the requesting user's vehicle risk rating threshold. Furthermore, the user can be assigned to a vehicle whose vehicle risk rating is at or above the requesting vehicle's user risk rating threshold. This ensures that users are assigned to a vehicle in which they feel comfortable during the ride, and that the operator of the assigned vehicle also feels comfortable transporting the requesting user.

[0053] While specific embodiments have been presented and described herein, it is understood that various other modifications and adaptations can be made without deviating from the scope of the claimed subject matter. Although various aspects of the claimed subject matter have been described herein, such aspects need not be used in combination. It is therefore desired that the appended claims cover all such modifications and adaptations that fall within the scope of the claimed subject matter.

Claims

[1] Method for assigning a vehicle (108) to a user (106), comprising: Receiving, by a computing device (102), a user ride-sharing request for a vehicle (108) from a plurality of available vehicles (108) from a user (106); Received by the computing device (102), a vehicle risk assessment threshold preference associated with the user (106); Determine, by the computing device (102), a user risk assessment that is associated with the user (106); Determine, by means of the calculating device (102), a vehicle risk assessment that is associated with at least one of the plurality of available vehicles (108); Received, by the computing device (102), a user risk assessment threshold preference associated with each of the plurality of available vehicles (108); Identify, by the computing device (102), one or more vehicles (108) within a subset of the plurality of available vehicles (108) that have an associated vehicle risk rating at or below the vehicle risk rating threshold preference associated with the user (106) and an associated user risk rating threshold preference at or above the user risk rating associated with the user (106); present, to the user (106), one or more ride-sharing options for selecting one of the one or more vehicles (108) from the subset of the plurality of available vehicles (108) for the user ride-sharing request; and Receiving a selection by the user (106) from a user device of one of the one or several vehicles (108). [2] Method according to claim 1, further comprising an adjustment of the vehicle risk assessment associated with a vehicle (108) of the plurality of available vehicles (108) based on one or more vehicle risk assessment factors. [3] Method according to claim 2, wherein the one or more vehicle risk assessment factors comprise a location of the vehicle (108) from the plurality of available vehicles (108) within a geographical region which is determined to be a high-risk area, and a duration during which the vehicle (108) is located within the geographical region from the plurality of available vehicles (108). [4] Method according to claim 2 or 3, wherein the one or more vehicle risk assessment factors comprise elapsed time and / or distance traveled since a cleaning process has taken place in the vehicle (108) out of the plurality of available vehicles (108). [5] Method according to claim 4, further comprising a detection of the occurrence of the cleaning process responding to a triggering process of a cleaning device in the vehicle (108) of the plurality of available vehicles (108). [6] Method according to claim 2 or 3, wherein the one or more vehicle risk assessment factors comprise a number of previous occupants of the vehicle (108) from the plurality of available vehicles (108) and an associated user risk assessment of the previous occupants. [7] Method according to claim 2 or 3, further comprising an adjustment of the user risk assessment associated with the user (106) based on one or more user risk assessment factors, wherein the one or more user risk assessment factors comprise a location of the user (106) within a geographic region which has been determined to be a high-risk area and a duration during which the user (106) is within the geographic region. [8] Method according to claim 2 or 3, wherein the one or more ride-sharing options presented to the user (106) are assigned prices corresponding to the vehicle risk assessment associated with the vehicles (108) of the subset of the plurality of available vehicles (108). [9] Vehicle allocation system (100), comprising: a computing device (102) comprising a controller (200) which is set up: to receive a user ride-sharing request associated with a vehicle (108) from a plurality of available vehicles (108) from a user (106); to receive a vehicle risk assessment threshold preference associated with the user (106); to determine a user risk assessment associated with the user (106); to determine a vehicle risk assessment associated with the majority of available vehicles (108); to receive a user risk assessment threshold preference associated with the majority of available vehicles (108); to identify one or more vehicles (108) within a subset of the plurality of available vehicles (108) that have an associated vehicle risk rating at or below the vehicle risk rating threshold preference associated with the user (106) and an associated user risk rating threshold preference at or above the user risk rating associated with the user (106); to present the user (106) with one or more ride-sharing options in order to select one of the one or more vehicles (108) from the subset of the plurality of available vehicles (108) for the user's ride-sharing request; and to receive a selection by the user (106) from a user device of one of the one or several vehicles (108). [10] Vehicle allocation system (100), comprising: a computing device (102) comprising a controller (200) which is set up: to receive a user ride-sharing request for a vehicle (108) from a plurality of available vehicles (108) from a user (106); to identify one or more vehicles (108) within a subset of the plurality of available vehicles (108) that have an associated vehicle risk rating at or below a vehicle risk rating threshold preference associated with the user (106) and an associated user risk rating threshold preference at or above the user risk rating associated with the user (106); to present the user (106) with one or more ride-sharing options in order to select one of the one or more vehicles (108) from the subset of the plurality of available vehicles (108) for the user's ride-sharing request; and to receive a selection by the user (106) from a user device of one of the one or several vehicles (108).

Images