Riding sharing lifecycle risk management

Abstract

Systems and methods for ride-sharing risk management determine a passenger risk score based on records of passengers in a database; a driver risk score for each driver in the set of candidate drivers is determined. A pre-ride risk score for each driver is determined based on the driver risk score, the passenger risk score, and the one or more ride request conditions. A driver whose risk score before riding is lower than a first predefined threshold is specified from the candidate driver set. Signals are periodically received from a passenger's computing device or a designated driver's computing device at the start of the ride and an on-the-way risk score associated with the ride is evaluated based on a consistency of the received signals with an expected ride plan.

Description

Technical Field

[0001] The present disclosure generally relates to methods and systems for lifecycle risk management of a ridesharing service platform. Background Art

[0002] This background art is provided for the purpose of generally presenting the background of the present disclosure. The content of this background art section is neither expressly nor implicitly admitted to be prior art relative to the present disclosure.

[0003] With the growth of ridesharing services, platforms enabling ridesharing services have accumulated a large amount of data related to drivers, passengers, and rides taken by passengers. As the coverage of such services increases, the amount of ridesharing-related data continues to grow exponentially. For safety and authentication purposes, the data can include data related to the profile details of users of the ridesharing system. Data related to a rider (passenger) can include data related to the origin, destination, time, and comment data of the ride. The ridesharing platform can also access publicly available data related to individuals who are users of the ridesharing service. The data accumulated by the ridesharing platform provides an opportunity to enhance the experience of passengers and drivers and proactively manage risks that may arise when providing ridesharing services. These risks can include safety risks of passengers or drivers. These risks also include the risk of accidents or adverse events occurring during a ride or future rides.

[0004] There is a desire to address or improve one or more disadvantages or limitations associated with conventional systems and methods for ridesharing risk management, or at least provide a useful alternative. Summary of the Invention

[0005] The present disclosure provides a system for ridesharing risk management, the system comprising: one or more processors ((multiple) processors); a memory accessible by the processors; a database including a plurality of passenger and driver records accessible by the processors; the memory including program code executable by the processors for the following steps: receiving a ride request from a passenger's computing device; determining a passenger risk score based on the passenger's record in the database; determining a driver risk score for each driver in a set of candidate drivers for the ride based on the record of each driver in the database; determining a pre-ride risk score for each driver for the ride based on the driver risk score of the respective driver, the passenger risk score, and one or more ride request conditions; designating a driver whose pre-ride risk score is below a first predefined threshold from the set of candidate drivers; periodically receiving a signal from the passenger's computing device or the designated driver's computing device at the start of the ride; evaluating an in-ride risk score associated with the ride based on the consistency of the received signal with an expected ride plan; and triggering a ride accident event when the in-ride risk score exceeds a second predefined threshold.

[0006] The disclosure also provides a system for ride-sharing risk management, the system including: one or more processors ((multiple) processors); a memory accessible by the processors; a database including multiple passenger and driver records accessible by the processors; the memory including program code executable by the processors for the following steps: receiving a ride request from a passenger's computing device; determining a pre-ride risk score for a ride for each driver based on the multiple passenger and driver records and one or more ride request conditions; designating a driver with a pre-ride risk score lower than a first predefined threshold from a set of candidate drivers; periodically receiving signals from the computing device of the passenger or the designated driver at the start of the ride; evaluating an in-ride risk score associated with the ride based on the consistency of the received signals with an expected ride plan.

[0007] The disclosure also provides a computer-implemented method for ride-sharing risk management, the method including: receiving a ride request from a passenger's computing device; determining a passenger risk score based on the passenger's record in the database; determining a driver risk score for each driver in a set of candidate drivers for the ride based on the record of each driver in the database; determining a pre-ride risk score for each driver for the ride based on the driver risk score, the passenger risk score, and one or more ride request conditions; designating a driver with a pre-ride risk score lower than a first predefined threshold from the set of candidate drivers; periodically receiving signals from the computing device of the passenger or the designated driver at the start of the ride; evaluating an in-ride risk score associated with the ride based on the consistency of the received signals with an expected ride plan; triggering a ride accident event when the in-ride risk score exceeds a second predefined threshold.

[0008] The disclosure also provides a computer-implemented method for ride-sharing risk management, the method including: receiving a ride request from a passenger's computing device; determining a pre-ride risk score for each driver in a set of candidate drivers for the ride based on the multiple passenger and driver records and one or more ride request conditions; designating a driver with a pre-ride risk score lower than a first predefined threshold from the set of candidate drivers; periodically receiving signals from the computing device of the passenger or the designated driver at the start of the ride; evaluating an in-ride risk score associated with the ride based on the consistency of the received signals with an expected ride plan. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Exemplary embodiments of the invention are illustrated by way of example in the drawings, in which like reference numerals indicate identical or similar elements, and in which:

[0010] Figure 1 A block diagram illustrating a system for ride-sharing lifecycle risk management and its associated components is shown;

[0011] Figure 2 A flowchart of a method for ride-sharing lifecycle risk management is illustrated; and

[0012] Figure 3 and Figure 4 A schematic diagram of assigning a driver to a passenger in combination with the disclosed method and risk management is illustrated. DETAILED DESCRIPTION

[0013] As today's e-hailing services become increasingly popular, one challenge is to ensure the safety of both passengers and drivers, identify events that may have occurred, and provide a data and alert infrastructure to respond quickly to any safety-related event. Safety-related events are driving-related events (such as accidents, drunk driving), harassment-related events (such as in-person harassment or harassment via phone / text), and crime-related events (such as physical assault or sexual assault, theft, etc.).

[0014] The typical lifecycle of a ride through a ride-sharing service includes a customer requesting a ride through their smartphone. A driver is assigned to the customer, and when the driver picks up the passenger, the ride begins. The ride ends when the passenger gets out. Between the ride request and getting out, there can be several computer systems that communicate with each other to facilitate the ride and generate meaningful data. The disclosed systems and methods that use this data utilize it to perform risk management or generate alerts about potential events. In conventional systems, in the event of a safety incident during a ride, assistance can only be provided if the passenger, driver, or a third party reports the event.

[0015] The disclosed systems and methods improve the ride-sharing experience and safety at each stage of the lifecycle. The disclosed systems and methods also process data (both historical and real-time data) to predict the risk of an event occurring and guide decisions regarding driver assignment to mitigate such risks.

[0016] Figure 1 A block diagram of a system for ride-sharing risk management and its associated components is illustrated. The ride-sharing risk management system 100 includes at least one processor 102, a memory 104 accessible to the processor 102, and a network interface 108 that facilitates communication with the computing devices 150 of multiple drivers and the computing device 160 of a user. The program code 106 provided in the memory 104 includes instructions executable by the processor 102 to perform at least part of the methods of the embodiments described herein. It is noted that although Figure 1 a stand-alone computer system is described, without departing from the intended purpose of the present disclosure, any such computer system can be distributed across multiple servers or multiple devices, or some functions can be combined into a single server or device.

[0017] The driver's computing device 150 is associated with a particular vehicle 140 driven by the corresponding driver. The driver's computing device 150 includes at least one processor 150, a memory 154, a GPS device 157, and a network interface 159. The memory 154 includes program code 156 that includes instructions executable by the processor 152 for facilitating interaction with the ridesharing risk management system 100. The user's computing device 160 includes one or more processors 162, a memory 164, a GPS device, and a network interface 169. The memory 164 includes program code 166 that includes instructions executable by the processor 162 for facilitating interaction with the ridesharing risk management system 100. The driver's computing device and the user's computing device may include personal or handheld computing devices such as smartphones or tablets. The network 130 facilitates communication between various devices and may include one or more communication networks, including the Internet, cellular phone networks, etc.

[0018] One or more databases 120 may also be accessible by the system 100. The database 120 may include historical data and associated information related to rides taken by passengers or rides provided by drivers. The historical data related to rides may include the time, date of the ride, the origin of the ride, the destination, comment data, feedback or ratings related to the ride provided by the passenger and the driver. The database 120 may also include profile details related to the passengers and drivers, including information collected during the authentication of the passenger or driver, payment-related details, etc. The database 120 may also include historical data related to past events that the passenger or driver may have participated in. In some embodiments, the database 120 may also include third-party databases that include identity records or crime / violation notice records.

[0019] The risk management system considers risks during one or more stages of the ridesharing lifecycle to improve the outcome of the overall experience of passengers and drivers. Figure 2 A flowchart of a method 200 for ridesharing lifecycle risk management that may be executed by the system 100 is illustrated. The first stage of risk management involves the pre-ride stage implemented through steps 210, 220, and 230. One goal of the pre-ride stage is to support the assignment of drivers to passengers such that the risk of events during subsequent rides (i.e., rides obtained by a passenger issuing a ride request) is reduced. Depending on the characteristics of the passengers and drivers derived from data related to the passengers and drivers, the method identifies matches between passengers and drivers that can potentially reduce the likelihood of events.

[0020] At step 210, system 100 receives a ride request from the passenger's device 160. The request may be communicated through other components of the ridesharing system or platform. The request includes the origin, destination information, ride time, and the identity of one or more passengers requesting the ride. In other embodiments, depending on the data used in the risk estimation process, more or fewer data points (i.e., destination information, ride time, etc.) may be captured.

[0021] At step 220, system 100 determines a pre-ride risk score associated with the pairing of the passenger with each driver in the pool of available candidate drivers. The pool of candidate drivers may be determined based on drivers who are available (i.e., not currently on a trip), near their drop-off point (e.g., within 5 minutes of the current passenger's drop-off), have a drop-off point near the passenger making the ride request, within a predetermined distance or time of the origin (e.g., 5 kilometers or 10 minutes), etc. The pre-ride risk score serves as a quantitative measure of the risk associated with a particular pairing of a passenger and a driver. As part of step 220, at step 222, historical information related to the passenger is used to calculate a passenger risk score to assign a risk score to the customer. The historical information related to the passenger is obtained from a database. Passengers with a risk score above a threshold may be flagged by system 100 as passengers requiring a higher degree of risk management, depending on the nature of the flagged risk.

[0022] The passenger risk score is determined based on a plurality of risk metrics generated based on passenger records accessible to system 100. The risk metrics are numerical representations of various dimensions of risk-related data available to system 100. The risk metrics may include: a passenger profile record accuracy metric, a passenger profile record freshness metric, a passenger interaction comment metric, or a passenger historical event metric.

[0023] The passenger profile record accuracy metric is a measure of the accuracy or completeness of the passenger's profile record for the ridesharing service. The accuracy or completeness may be evaluated by comparing these records with third-party sources of profile information (such as identity verification service providers, etc.). The last update time of the passenger profile record may contribute to the passenger profile record freshness metric. For example, a profile record with no recent updates may be assigned a lower freshness score, and a lower freshness score will correspond to a higher risk score. A passenger with a recent updated photo may be assigned a higher freshness score, and a higher freshness score will correspond to a lower risk score.

[0024] The passenger interaction review metrics relate to reviews that a passenger may have received from a driver during their past use of the ride-sharing service. Low or poor reviews are used as an indicator of higher risk. High or good reviews are used as an indicator of lower risk. The passenger incident metrics relate to records of any incidents that a passenger may have been involved in previously or records of criminal or negative behavior from internal sources. Internal sources can include incidents recorded by the company providing the service. For example, internal sources can include a program or algorithmic model that is capable of tracking text or ratings in reviews of an abusive or harassing nature on the platform. The number or frequency of passenger cancellations can contribute to the passenger risk score.

[0025] Each of the metrics is represented numerically, and its corresponding value indicates the degree of potential risk associated with the passenger. For example, the accuracy of the profile information can be represented by a number that indicates the degree of match between the passenger's self-declared profile and a true third-party source of the profile information. Similarly, the passenger profile record freshness metric can indicate the number of days since the last selfie provided by the passenger. Each of the metrics can be assigned a specific weight, reflecting the degree to which they meaningfully represent the risk associated with the passenger.

[0026] A logarithmic normalization can be applied to the sum of the metric values to transform the overall passenger risk value into a value within a predefined range. The predefined range can be a range of values from 1 to 10. The passenger risk score can be calculated as follows:

[0027]

[0028] As part of step 222, if it is determined that a person's risk score is higher than an acceptable threshold, the passenger can be prompted to provide further information or verify their identity before proceeding with their ride request.

[0029] Step 224 includes determining the driver risk scores for all or a subset of the candidate drivers near the passenger. The subset can be determined by referring to any metrics or parameters (such as the top 20 drivers closest to the origin), or by matching only female drivers with female passengers who request a match only with female drivers. Similar to the calculation of the passenger risk score, the driver risk score is based on multiple measurable metrics related to the driver. These metrics include: driver profile record accuracy metric, driver profile record freshness metric, driver interaction review metric, driver incident metric. The metrics related to the driver can be calculated in the same way as the metrics related to the passenger. The measurable metrics related to the driver can be obtained from a database.

[0030] Driver event metrics can additionally illustrate a driver's compliance with traffic rules and safety driving expectations or standards. Driver event metrics can consider data from third-party databases (such as traffic violation databases) to extract data related to a driver's traffic violations. As an example, the more traffic violation records there are, the higher the driver's driver risk score may be.

[0031] For computational efficiency, passenger and driver risk scores can be pre-computed and accessible by system 100. Passenger and driver risk scores can be calculated using a supervised machine learning model that receives raw data related to various risk metrics as input and generates a risk score as output. The supervised learning model can be trained using historical event data and can be used to represent the common statistical relationship between passenger / driver metric-related data and the associated risk of an event. The supervised learning model can define weights associated with specific metrics, reflecting their relative importance to the risk score or risk score estimate.

[0032] After calculating or obtaining passenger and driver risk scores, an overall pre-ride risk score is calculated for each expected combination of passengers and drivers. The pre-ride risk score takes into account one or more ride conditions. These ride conditions include: the time of day of the ride, the origin of the ride, or the destination of the ride, or the duration of the ride. The pre-ride risk score can increase or decrease based on the ride conditions. The pre-ride risk score is then used as a benchmark for assigning a driver to a passenger at step 230. A passenger-driver combination with a pre-ride risk score above a threshold can represent a risk that can be avoided by removing such a driver from the available driver pool.

[0033] As an example, the pre-ride risk score can illustrate the gender difference between a passenger and a driver. A combination of a female passenger and a male driver can be assigned a higher pre-ride risk score. Similarly, a combination of a male passenger and a female driver can be assigned a higher risk score. A ride request at a certain time of day (such as late at night) can be assigned a higher or increased pre-ride risk score.

[0034] These thresholds are determined based on historical events. A retrospective analysis of historical event data as well as historical data on drivers and passengers allows for the determination of thresholds for the purpose of mitigating future risks. System 100 limits the candidate driver pool to drivers with an associated pre-ride risk score below the threshold to manage any event-related risks even before the ride begins.

[0035] In some embodiments, the pre-ride risk score can be calculated as follows:

[0036]

[0037] The late-night rating is a value attributed to a late-night ride request. The late-night rating value can vary depending on the time of day. For example, a ride request at 12:00 midnight can be assigned a higher value than a ride request at 8:00 PM. The different gender rating indicates the gender difference between the driver and the passenger. The payment method change is a rating indicating the most recent payment method change by the driver or the passenger. The determination of the pre-ride risk rating can be performed independently of the determination of the in-ride risk rating. Some implementations can involve the execution of steps 220 and 230 independent of steps 240 and 250 of the method Figure 2

[0038] Figure 3 An exemplary scenario is illustrated where a female passenger books a ride during the day. She has 3 candidate drivers with risk ratings ranging from X to X + 2, where for each candidate driver, her pre-ride risk rating is within the acceptable risk threshold (i.e., below the threshold). Figure 4 Another exemplary scenario is illustrated where the same female passenger in scenario 1 books a ride late at night. In Figure 4 this scenario, she now has 2 candidate drivers because when considering the increase in the pre-ride risk rating due to the late-night ride request, Figure 3 the candidate driver with a risk rating of X + 2 now exceeds the predefined threshold. Due to the increase in the pre-ride risk rating, the same passenger has a smaller number of candidate drivers. This reduced set of candidate drivers helps mitigate the potential risks associated with the ride conditions. At step 230, a driver is assigned to the passenger. The driver is assigned from the set of candidate drivers with a pre-ride risk rating below the first predefined threshold. This selective assignment of the driver helps mitigate the risks associated with the event even before the ride begins.

[0039] Steps 240, 250, and 260 relate to in-ride risk management after the ride has started (the ride phase). After the ride has started, the respective computing devices of the passenger and the driver intermittently send signals that system 100 receives at step 240. The signals sent include location information. At the start of the ride, the origin and destination information is known. Based on the origin and destination information, the expected ride plan is also available to system 100. The ride plan can include the expected route or path between the origin and the destination. The ride plan can also include the expected ride duration.

[0040] ​At step 250, system 100 evaluates an in - transit risk score based on the signals received at step 240. This evaluation is done by estimating the consistency of the received signals with the expected ride plan. The consistency can be estimated by checking whether the location information received from the driver's / passenger's device is consistent with an acceptable path between the origin and the destination. An unexpected stop or a long - term stop indicated by the static location information in the signal can also be estimated as inconsistent with the expected ride plan. The in - transit risk score is evaluated dynamically / iteratively when the signal is received at step 240. As the ride progresses, the in - transit risk score can increase when an inconsistency with the ride plan is detected. Other indicators of inconsistency include an abnormal termination of the ride midway through the planned route or exceeding the estimated time of arrival (ETA).

[0041] The inconsistency with the expected ride plan can be numerically represented based on the degree of change relative to the expected ride plan. For example, if a minor deviation from the expected route is detected (e.g., a minor route change indicating that the destination remains the same), the in - transit risk score can be increased by a small value. However, if a significant deviation is detected (e.g., a deviation from the main route indicating that the driver is no longer going to the original destination), the in - transit risk score can be increased to a greater extent. If the passenger or the driver changes the destination on their respective computing devices during the ride phase, the risk score can also be increased.

[0042] Additionally, the in - transit risk score can be sensitive to the specific location of the vehicle. For example, a route change in an urban area can cause a smaller increase in the score compared to a route change in a more remote area. Thus, the in - transit risk score can be a function of the absolute location information and the location - associated risk information. Certain risk - prone areas (such as areas with more hazardous driving conditions or areas more prone to crime) can be assigned a greater in - transit risk score. However, a minor inconsistency during a ride in such a risk - prone area can be flagged as a significant risk by increasing the in - transit risk score, thereby allowing for more effective risk mitigation or a more proactive response to potential events.

[0043] If the in-transit risk score evaluated at step 250 exceeds a predefined second threshold, a potential ride event alert is triggered at step 260. The ride event alert can be sent to a rapid response team to further evaluate the ride status and check on the passenger and / or driver. Alternatively, an active notification or alert can be sent to the computing device of the driver and / or passenger, requesting information about their health or asking if they need any assistance due to the potential event. Alternatively, the passenger and / or driver can be called actively to assess their health and evaluate if an event has occurred. The response to the active notification can also be used to further improve the accuracy of the overall method 200 by adjusting the evaluation of the risk score or the values of the first and second thresholds. The determination of the in-transit risk score can be performed independently of the determination of the pre-ride risk score. Some embodiments can involve steps 240 and 250 independent of steps 220 and 230 of the method independent of Figure 4 the execution.

[0044] The use combination of the pre-ride score and the in-transit score calculated by some embodiments enables risk mitigation before the risk occurs and supports an active response to an event that may ultimately occur.

[0045] Some embodiments involve: calculating a pre-ride risk score by determining a passenger risk score based on the records of the passenger in a database; determining a driver risk score for each driver in a set of candidate drivers for a ride based on the records of each driver in the database; and determining a pre-ride risk score for each driver in the set of drivers for the ride based on the driver risk score of the respective driver, the passenger risk score, and one or more ride request conditions. Then, a driver can be designated (i.e., a driver is assigned to the passenger), where the pre-ride risk score of the driver is below a predefined threshold. The designation can be the driver closest to the origin where the passenger will be picked up among all drivers with a pre-ride risk score below the predefined threshold.

[0046] Some embodiments involve calculating an in-transit risk score by periodically receiving signals from the computing device of the passenger or the designated driver at the start of the ride and evaluating the in-transit risk score associated with the ride based on the consistency of the received signals with the expected ride plan. When the in-transit risk score exceeds a second predefined threshold, a ride accident event can be triggered. Additionally, the in-ride risk score can be used to update the risk score of one or both of the passenger and the driver, or can be used to update one or both scores if a ride event is triggered. Further, if a passenger or driver experiences a small number (e.g., less than 5) of ride events or no ride events within a predefined time period (e.g., 3 months), the risk score of the passenger or driver can be reduced.

[0047] Any reference in this specification to any prior publication (or information derived therefrom) or to any matter which is known is not, and should not be taken to be, an acknowledgment or admission or any form of suggestion that the prior publication (or information derived therefrom) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates.

[0048] Throughout this specification and the following claims, unless the context requires otherwise, the words "comprise" and "including" and variations such as "comprises" and "comprising" will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps.

[0049] The scope of the present disclosure covers all alterations, substitutions, variations, changes and modifications of the example embodiments described or illustrated herein that would be understood by a person of ordinary skill in the art. The scope of the present disclosure is not limited to the example embodiments described or illustrated herein. Further, although the present disclosure describes and illustrates the corresponding embodiments herein as including particular components, elements, features, functions, operations or steps, any one of these embodiments may include any combination or arrangement of any of the components, elements, features, functions, operations or steps described or illustrated anywhere herein that would be understood by a person of ordinary skill in the art. Although the present disclosure describes or illustrates particular embodiments as providing particular advantages, a particular embodiment may not provide these advantages, may provide some of these advantages or all of these advantages.

Claims

1. A system for ridesharing risk management, the system comprising: One or more processors; A memory accessible by the processor; A database including a plurality of passenger records and driver records accessible by the processor; The memory includes program code executable by the processor for the following steps: Receiving a request for a ride from a passenger's computing device; Determining a passenger risk score based on the passenger's record in the database; Determining a driver risk score for each driver in a set of candidate drivers for the ride based on the record of each driver in the database; Determining a pre-ride risk score for each driver for the ride based on the driver risk score of the corresponding driver, the passenger risk score, and one or more ride request conditions; Designating a driver from the set of candidate drivers whose pre-ride risk score is below a first predefined threshold; Periodically receiving signals from the passenger's computing device or the designated driver's computing device at the start of the ride; Evaluating an in-ride risk score associated with the ride based on the consistency of the received signals with an expected ride plan; And Triggering a ride accident event when the in-ride risk score exceeds a second predefined threshold.

2. The system according to claim 1, wherein, The received signals include real-time or near-real-time location information, and Determining the consistency of the received signals with the expected ride plan is based on one or both of the following: The duration of stops during the ride, and The consistency of the ride path between the origin and destination with the location information.

3. The system according to claim 1 or claim 2, wherein The ride request conditions include one or more of the following: the time of day of the ride, the ride origin, the ride destination, the ride duration.

4. The system according to any one of claims 1 to 3, wherein, The passenger risk score is determined based on a plurality of risk metrics generated based on the passenger's record. Optionally, wherein the risk metrics include one or more of the following: A passenger profile record accuracy metric, A passenger profile record freshness metric, A passenger interaction comment metric, and A passenger accident metric.

5. The system according to any one of claims 1 to 4, wherein, The driver risk score is determined based on a plurality of risk metrics generated based on the driver's record. Optionally, wherein the risk metrics include one or more of the following: A driver profile record accuracy metric, A driver profile record freshness metric, A driver interaction comment metric, and A driver accident metric.

6. The system according to claim 4 or claim 5, wherein Each metric is assigned a relative weight, and the pre-ride risk score is determined based on the metrics and the relative weights.

7. The system according to any one of claims 1 to 6, wherein, Triggering a potential ride accident event includes sending a notification requesting a health status update to the passenger's computing device or the designated driver's computing device.

8. A system for ridesharing risk management, the system comprising: One or more processors; A memory accessible by the processor; A database including a plurality of passenger records and driver records accessible by the processor; The memory includes program code executable by the processor for the following steps: Receiving a request for a ride from a passenger's computing device; Determine a pre-ride risk score for each driver for the ride based on the multiple passenger records and driver records and one or more ride request conditions; Designate a driver from the set of candidate drivers whose pre-ride risk score is below a first predefined threshold; Periodically receive signals from the computing device of the passenger or the designated driver at the start of the ride; Evaluate an in-ride risk score associated with the ride based on the consistency of the received signals with the expected ride plan.

9. A computer-implemented method for ridesharing risk management, the method comprising: Receive a request for a ride from a passenger's computing device; Determine a passenger risk score based on the passenger's records in a database; Determine a driver risk score for each driver in the set of candidate drivers for the ride based on the records of each driver in the database; Determine a pre-ride risk score for each driver for the ride based on the driver risk score, the passenger risk score, and one or more ride request conditions; Designate a driver from the set of candidate drivers whose pre-ride risk score is below a first predefined threshold; Periodically receive signals from the computing device of the passenger or the designated driver at the start of the ride; Evaluate an in-ride risk score associated with the ride based on the consistency of the received signals with the expected ride plan; Trigger a potential ride accident event when the in-ride risk score exceeds a second predefined threshold.

10. The method according to claim 9, wherein, The received signals include real-time or near-real-time location information, and Determining the consistency of the received signals with the expected ride plan is based on one or both of the following: The duration of stops during the ride, and The consistency of the ride path between the origin and destination with the location information.

11. The method according to claim 9 or claim 10, wherein The ride request conditions include one or more of the following: the time of day of the ride, the ride origin, the ride destination, the ride duration.

12. The method according to any one of claims 9 to 11, wherein The passenger risk score is determined based on a plurality of risk metrics generated based on the passenger's records. Optionally, wherein the risk metrics include one or more of the following: A passenger profile record accuracy metric, A passenger profile record freshness metric, A passenger interaction comment metric, A passenger accident metric.

13. The method according to any one of claims 9 to 12, wherein, The driver risk score is determined based on a plurality of risk metrics generated based on the driver's records. Optionally, wherein the risk metrics include one or more of the following: A driver profile record accuracy metric, A driver profile record freshness metric, A driver interaction comment metric, A driver accident metric.

14. The method according to claim 12 or claim 13, wherein Each metric is assigned a relative weight, and the pre-ride risk score is determined based on the metrics and the relative weights.

15. The method according to any one of claims 9 to 14, wherein Triggering a potential ride accident event includes sending a notification requesting a health status update to the passenger's computing device or the designated driver's computing device.

16. A computer-implemented method for ridesharing risk management, the method comprising: Receive a ride request from a passenger's computing device; Determine a pre-ride risk score for each driver in a set of candidate drivers for the ride based on multiple passenger records and driver records and one or more ride request conditions; Designate drivers from the set of candidate drivers whose pre-ride risk scores are below a first predefined threshold; Periodically receive signals from a computing device of the passenger or the designated driver at the start of the ride; Evaluate an in-ride risk score associated with the ride based on the consistency of the received signals with an expected ride plan.

17. One or more non-transitory computer-readable storage media storing instructions that, when executed by one or more processors, cause the one or more processors to perform the method according to any one of claims 9 to 16.

Images