Generating Dynamic Interfaces Providing Intelligent Multi-Device Selectable Elements for a Transportation Matching System

Abstract

The present disclosure relates to a system, non-transitory computer-readable medium, and method for generating a dynamic graphical user interface that provides intelligent multi-device selectable elements for a transportation matching system. In particular, in one or more embodiments, the disclosed system utilizes a multi-device selection model to compare characteristics associated with multiple transportation requests and characteristics associated with provider devices. Furthermore, the disclosed system can intelligently present a subset of transportation requests in the graphical user interface of each provider device. For example, the disclosed system provides selectable elements within an interactive digital map, thereby enabling provider devices to efficiently and accurately select transportation matches within a unified user interface. Furthermore, in some embodiments, the disclosed system provides individual transportation requests to multiple provider devices and utilizes a provider selection model to intelligently resolve overlapping conditions.

Description

[Background technology]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of and priority to U.S. Patent Application No. 18 / 146,850, filed December 27, 2022. The entire contents of the aforementioned patent application are incorporated herein by reference.

[0002] Recently, significant developments have occurred in transportation matching systems that utilize web and mobile applications to match provider devices with real-time, on-demand transportation requests from requester devices. For example, on-demand transportation matching systems utilize computer networks to match provider devices with requester devices and can provide transportation in a variety of situations. In generating dynamic transportation matches, conventional systems can select and communicate with provider devices to provide transportation services for a particular requester device in a particular geographic area at a particular time. While on-demand transportation matching systems can identify requester devices, select provider devices, dispatch provider devices, and dynamically match requester devices and provider devices, such systems suffer from numerous technical challenges, particularly in terms of the flexibility, efficiency, and accuracy of computer system implementation.

[0003] For example, conventional systems have limited flexibility for matching client devices during transportation requests. To explain, while conventional systems may allow provider devices to select particular driving modes, geographic areas, or time frames for responding to transportation requests, such systems generally assign rigid transportation assignments to provider and requester devices within these parameters. For example, conventional systems typically perform a background analysis of available transportation requests, select transportation matches, and then rigidly present driving instructions to the provider devices.

[0004] Conventional systems are also inefficient. For example, the described rigid approach often leads conventional systems to waste computing resources and utilize excessive bandwidth. For example, a provider device faced with a rigid allocation to a particular transportation request often must review a user interface showing details about the transportation match, change its mobile application to an offline status (or otherwise submit a cancellation notice for the transportation request), switch its mobile application back to an online status, submit additional queries for additional transportation requests, wait for the backend server to identify the additional transportation matches, review additional user interfaces for the additional transportation matches, and reevaluate the additional transportation matches for suitability (or additional interactions to cancel the additional transportation matches). In practice, conventional systems may repeat this process iteratively before the provider device accepts the transportation match. This not only wastes computing resources on the provider device, but also causes the backend server to utilize significant computing resources in iteratively managing transportation matches, processing cancellation requests, and reallocating requests among multiple provider devices. Thus, conventional user interfaces introduce inefficiencies that result in inefficient use of computing resources in managing transportation requests.

[0005] Furthermore, there are several technical barriers to providing multiple transportation options to provider devices. For example, the limited screen space and functional capacity of mobile devices pose significant barriers to providing accurate and sufficient information to provider devices in an efficient manner. This is especially true considering the fact that provider devices are often utilized while operating transportation vehicles. To explain, providing a written list of transportation requests introduces additional inefficiencies as provider devices must navigate to other user interfaces to gather information about each transportation request and compare the written information with transportation details. Similarly, providing multiple transportation requests can potentially introduce overall system inefficiencies as a particular transportation request for a particular requester device is repeatedly presented to various provider devices without completing a transportation match. Similarly, providing multiple transportation requests can cause inefficiencies and conflicts across provider devices selecting to service the same transportation request. Furthermore, the number of available transportation requests for a particular region can exhaust and overwhelm the available space of conventional user interfaces and displays.

[0006] These are in addition to additional problems and challenges that exist with conventional transportation matching systems. Summary of the Invention

[0007] Embodiments of the present disclosure provide benefits related to systems, non-transitory computer-readable media, and methods for generating dynamic graphical user interfaces that provide intelligent multi-device selectable elements for transportation matching systems and / or solve one or more of the aforementioned or other problems in the field. In some embodiments, the disclosed system can utilize a multi-device selection model to compare features associated with multiple transportation requests and features associated with provider devices. Based on this analysis, the disclosed system can intelligently present a subset of transportation requests in the graphical user interface of each provider device. For example, the disclosed system can provide selectable elements in an interactive digital map, allowing provider devices to efficiently and accurately select transportation matches within a unified user interface. Furthermore, in some embodiments, the disclosed system can provide individual transportation requests to multiple provider devices and intelligently resolve conflicting selections using a provider selection model. Thus, the disclosed system can provide an efficient user interface that enables increased flexibility and accuracy in providing multiple transportation requests to provider devices.

[0008] The following description describes additional features and advantages of one or more embodiments of the disclosed methods, non-transitory computer-readable media, and systems. In some cases, such features and advantages will be obvious to one skilled in the art having the benefit of this disclosure, or may be learned by practice of the disclosed embodiments. [Brief explanation of the drawings]

[0009] The detailed description, as briefly described below, uses the accompanying drawings to provide additional specificity and detail to one or more embodiments, and the drawings are not necessarily drawn to scale.

[0010] [Figure 1]1 illustrates a diagram of an environment in which a multi-device selection system can operate, according to one or more embodiments.

[0011] [Figure 2] 1 illustrates an overview of a transportation matching system receiving a set of transportation requests and providing a provider device with a display of selectable elements representing the plurality of transportation requests, according to one or more embodiments.

[0012] [Figure 3A] 1 illustrates a transportation matching system, according to one or more embodiments, that analyzes transportation request characteristics and selects between a multi-device selection system and a single-device selection system. [Figure 3B] 1 illustrates a transportation matching system, according to one or more embodiments, that analyzes transportation request characteristics and selects between a multi-device selection system and a single-device selection system.

[0013] [Figure 4] A multi-request transport model, according to one or more embodiments, illustrates selecting multiple transport requests from a set of transport requests to provide to a provider device.

[0014] [Figure 5A] 1 illustrates an exemplary graphical user interface for displaying selectable elements representing multiple transport requests, according to one or more embodiments. [Figure 5B] 1 illustrates an exemplary graphical user interface for displaying selectable elements representing multiple transport requests, according to one or more embodiments. [Figure 5C] 1 illustrates an exemplary graphical user interface for displaying selectable elements representing multiple transport requests, according to one or more embodiments.

[0015] [Figure 6]1 illustrates a provider selection model, according to one or more embodiments, selecting a provider device from a plurality of provider devices that matches a selected transportation request.

[0016] [Figure 7] 1 illustrates a flowchart of a series of actions in a method for selecting multiple transportation requests and providing an interactive digital map and selectable elements showing the multiple transportation requests, according to one or more embodiments.

[0017] [Figure 8] 1 illustrates a block diagram of an example computing device for implementing one or more embodiments of the present disclosure.

[0018] [Figure 9] 1 illustrates an example environment for a transportation matching system according to one or more embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0019] This disclosure describes one or more embodiments of a multi-device selection system that generates an improved graphical user interface that provides intelligent multi-device selectable options to provider devices within a transportation matching system. For example, the multi-device selection system selects multiple transportation requests and provides a user interface for display on the provider device that shows an interactive map and selectable elements representing the multiple transportation requests. In particular, in one or more embodiments, the multi-device selection system identifies characteristics associated with each transportation request (e.g., destination, type, route, etc.). The disclosed system can utilize a multi-device selection model to analyze these characteristics and characteristics associated with each provider device and select transportation requests to provide to each provider device. Once selected, the multi-device selection system can present a selectable element representing the selected transportation request along with an interactive map. Upon presenting the selectable element representing the transportation request, the multi-device selection system receives a selection of the selectable element from the provider device and transmits navigation instructions for a pickup location associated with the transportation request to the provider device.

[0020] As indicated above, the multi-device selection system receives a set of transport requests and selects a subset of the transport requests to display on the provider device. Upon receiving a transport request, the multi-device selection system identifies characteristics associated with the transport request and utilizes a transport request filter to determine whether to route the transport request to a multi-request transport model, a single-request transport model, or both. For example, in one or more embodiments, the multi-device selection system selects transport requests for the multi-request transport model based on a threshold wait time and / or previous interactions between the provider device and the transport request.

[0021] In addition to selecting transportation requests for the multi-request transportation model, the multi-device selection system can identify characteristics associated with each transportation request and each provider device. Furthermore, the multi-device selection system utilizes a multi-request transportation matching algorithm to compare the characteristics associated with the transportation requests and the characteristics associated with the provider devices. For example, in some embodiments, the multi-request transportation matching algorithm utilizes an optimization model (e.g., a local greedy optimization model or a global optimization model) to analyze these characteristics and select transportation requests to present to different provider devices. In particular, the multi-device selection system can intelligently select which transportation requests (and how many transportation requests) to match to which provider devices (and how many provider devices). For example, the multi-device selection system can present three selectable elements corresponding to three transportation requests along with an interactive map on a first provider device and four selectable elements corresponding to four different transportation requests along with an interactive map on a second provider device.

[0022] The multi-device selection system can present selectable elements within an intelligent user interface that efficiently provides relevant information to provider devices. For example, the multi-device selection system can provide the selectable elements in conjunction with an interactive map. The selectable elements can include information about a transportation request, and the interactive map can display transportation routes and / or other information corresponding to the particular transportation request.

[0023] The multi-device selection system can also dynamically modify the user interface of a provider device. For example, when the multi-device selection system matches a transportation request to a provider device, the multi-device selection system can update the user interface of the other provider devices to remove selectable elements that correspond to the matched transportation request. Furthermore, when the multi-device selection system receives additional transportation requests, the multi-device selection system can intelligently update the user interface to present the additional transportation requests to the selected (e.g., best-suited) provider device.

[0024] As mentioned, in some embodiments, the multi-device selection system provides the same transportation request to multiple provider devices. In fact, to improve efficiency and reduce time and queries for requester devices, the multi-device selection system can select multiple provider devices to receive a single transportation request from a single requester device. Accordingly, in some situations, multiple provider devices may select the same transportation request. In such situations, the multi-device selection system can intelligently select from the provider devices. For example, the multi-device selection system may utilize a provider selection model (e.g., a separate optimization algorithm) to select a provider device (e.g., an optimal provider device) for a particular transportation request.

[0025] The multi-device selection system may also provide various other intelligent features in presenting multiple transport requests from multiple requester devices to a provider device. For example, the multi-device selection system may stagger the provision of transport requests to different provider devices, implement gating based on various factors such as provider device and / or requester device ratings (e.g., providing higher-value transport requests to higher-rated provider devices), and / or implement provider device incentives based on utilization of a multi-request transport matching algorithm (e.g., providing priority matches or other incentives in utilizing the multi-request transport feature).

[0026] The multi-device selection system offers numerous advantages and benefits over conventional systems and methods. For example, by utilizing a multi-request transportation model, the multi-device selection system increases flexibility and computational functionality. In particular, the multi-device selection system can utilize a multi-request transportation matching algorithm to dynamically select transportation requests, allowing a provider device to display and select from multiple transportation match combinations. Additionally, as particular transportation requests become available or unavailable, the multi-device selection system dynamically updates selectable elements associated with transportation requests on the provider device interface. Furthermore, the multi-device selection system can flexibly select from different transportation matching models for different transportation requests. For example, based on characteristics associated with a transportation request, the multi-device selection system can flexibly determine to apply a multi-request transportation model, a single-request transportation model, or both.

[0027] The multi-device selection system also improves the efficiency of device implementation. For example, the multi-device selection system provides provider devices with an improved user interface that reduces user interaction and computing resources. For example, the multi-device selection system provides, via the provider device, a user interface that includes transportation information regarding an intelligently selected subset of transportation requests. Thus, through a single user interface, the multi-device selection system enables the provider device to identify, review, and select from multiple transportation requests. Additionally, by providing transportation requests to multiple provider devices, the multi-device selection system can reduce the amount of time required to identify a provider device and accept a transportation request.

[0028] The multi-device selection system also improves efficiency by reducing processing and bandwidth resources relative to conventional processes. For example, the multi-device selection system allows a provider device to display multiple transportation requests without consuming computational resources in generating an initial match for the provider device, changing the provider to offline mode (or otherwise canceling the initial match), changing to online mode, and running additional algorithms to generate additional matches. Thus, unlike conventional systems, the multi-device selection system provides information about multiple transportation requests from multiple requester devices to the provider device, thus avoiding additional queries, analysis, and computational resources from the provider device and backend server.

[0029] Furthermore, the multi-device selection system overcomes some technical barriers to providing multiple transportation options to provider devices. For example, the multi-device selection system intelligently utilizes screen space and functionality by adjusting which transportation requests are presented to the provider device. For example, the multi-device selection system can determine how many selectable elements to present in the provider device interface to select transportation requests that offer diverse options (e.g., in terms of distance, proximity, time, or route) that allow for improved display within the user interface. Furthermore, the provider device can present elements on an interactive map that allows the provider device to provide accurate and sufficient information (e.g., previewing routes, destinations, transportation prices, etc.) without requiring the provider device to collect information while comparing transportation requests through multiple interfaces. Thus, the multi-device selection system can provide relevant information within the limited screen space of a mobile device used in conjunction with a transportation matching system.

[0030] The multi-device selection system also overcomes problems associated with providing multiple transportation requests to various provider devices. For example, by presenting personalized transportation request subsets to specific provider devices, the multi-device selection system avoids wasting computational resources. Explained, the multi-device selection system improves computational expenditures by presenting transportation requests to provider devices that are likely to accept the transportation request and avoiding repeated resource expenditures in rejecting and notifying multiple devices. Furthermore, unlike conventional systems, the multi-device selection system intelligently handles conflicts (e.g., overlapping conditions) between provider devices. For example, upon detecting an overlapping condition (e.g., multiple provider devices attempting to accept the same transportation request simultaneously), the multi-device selection system can analyze characteristics associated with each provider device to dynamically determine which provider device provides the most efficient match.

[0031] As indicated by the foregoing discussion, the present disclosure utilizes various terms to describe the features and advantages of a multi-device selection system. For example, as used herein, the term "provider device" refers to a computing device associated with a transportation provider or driver (e.g., a human driver or an autonomous computer system driver) that operates a transportation vehicle. For example, a provider device refers to a mobile device, such as a smartphone or tablet, operated by a provider. Thus, the term "provider device" can include a computing device that issues a query that identifies availability for transporting a requester device from one geographic location to another. Explained, a requester device can include a mobile phone, a tablet, and a computer, any of which can utilize a mobile or web-based application to search for transportation matches.

[0032] As used herein, the term "requester device" refers to a device (corresponding to a requester) that submits a request for transportation services. In particular, the term "requester device" can include a computing device that issues a query identifying the need for transportation from one geographic location to another. Illustratively, requester devices can include mobile phones, tablets, and computers, any of which can issue a request using a mobile or web-based application. After the transportation matching system matches a requester (or requester device) with a provider (or provider device), the requester can wait for pickup by the provider at a predetermined pickup location. Upon pickup, the provider transports the requester to a drop-off location specified in the transportation request. Accordingly, a requester can refer to (i) a person who has requested a request or other form of transportation but is still waiting to be picked up, or (ii) a person who has been picked up by a transportation vehicle and is currently riding in the transportation vehicle to the drop-off location.

[0033] As used herein, the term "transportation request" refers to a query by a requester device seeking transportation services. In particular, a "transportation request" may refer to a request by a requester device to a transportation matching system to match the requester device with a provider device for transportation services. Explained, a transportation request may include information regarding characteristics associated with the transportation request, such as a desired pickup location, a desired drop-off location, a desired pickup time, a desired drop-off time, a wait time, a transportation price, a request type, a requesting device rating, the number of passengers, the transportation route, cargo, and / or special considerations for the transportation.

[0034] As used herein, the term "transportation route" refers to a location, path, segment, or direction from one geographic location to another. Explained, a transportation route may include a pickup location and / or a drop-off location. A transportation route may also include roads, highways, paths, and / or streets utilized to travel from a pickup location to a drop-off location. Additionally, a transportation route may further include travel times, traffic information, travel distances, departure times, or arrival times for travel between locations.

[0035] As used herein, the term "matching probability" refers to the likelihood that a provider device will accept a transportation request. For example, based on characteristics associated with the transportation request, a provider device may be more or less likely to match with the transportation request. Explaining this, the matching probability may be high if the transportation request has a high transportation price, and the matching probability may be low if the transportation request has a low transportation price. Explaining this further, the matching probability may be higher if the transportation request pickup location is close to the provider device, and the matching probability may be lower if the transportation request pickup location is farther away from the provider device.

[0036] As used herein, the term "shipping price" refers to a score, such as a reward or cost, associated with a transportation request. For example, a transportation price may include an estimated revenue or fee associated with a transportation request. Thus, for example, a transportation price may include an amount received by a provider corresponding to a provider device, an amount paid by a requester corresponding to a requester device, or a net price reflecting an analysis of overall benefits and costs corresponding to a transportation request.

[0037] As used herein, the term "multi-request transportation model" refers to a computer-implemented algorithm that identifies multiple transportation requests to provide to a provider device. For example, the multi-request transportation model can analyze features associated with the transportation requests and features associated with the provider devices to generate a matching score. Based on the matching score, the multi-request transportation model selects multiple transportation requests to present to the provider device. Additionally, the multi-request transportation model also includes a computer-implemented algorithm that selects multiple provider devices to provide the same transportation request.

[0038] As used herein, the term "single-request transport model" refers to a computer-implemented algorithm that identifies a single transport request to provide to a provider device (e.g., one transport request at a time to accept or reject). For example, a single-request transport model assigns a single transport request to a single provider device. The single-request transport model can identify characteristics associated with the transport request and characteristics associated with the provider device and determine an optimal match between the single transport request and the provider device.

[0039] Additional details regarding the multi-device selection system will now be provided with reference to the figures. In particular, FIG. 1 illustrates a block diagram of a system environment for implementing a multi-device selection system 102 according to one or more embodiments. As shown in FIG. 1, the environment includes a server 106 that houses the multi-device selection system 102 as part of a transportation matching system 104. The environment of FIG. 1 further includes requester devices 110a-110n, provider devices 108a-108n, and a network 116. The server 106 may include one or more computing devices that implement the multi-device selection system 102. The requester devices 110a-110n and / or provider devices 108a-108n may be or include one or more of various computing devices as described in FIGS. 11-12. Additional description regarding the illustrated computing devices (eg, server 106, requester devices 110a-110n, and / or provider devices 108a-108n) is provided with respect to FIGS. 11-12 below.

[0040] As shown, the multi-device selection system 102 communicates with the requester devices 110a-110n and the provider devices 108a-108n using the network 116. For example, the multi-device selection system 102 communicates with the requester devices 110a-110n and the provider devices 108a-108n to match transportation requests received from the requester devices 110a-110n with the provider devices 108a-108n. In practice, the multi-device selection system 102 may track and communicate the status of the provider device 108a and provide an indicator for the location of the provider device 108a for display on the requester device 110a, for example, as a vehicle icon in a graphical map. In some embodiments, for each device configuration, the multi-device selection system 102 receives device information from the requester devices 110a-110n and provider devices 108a-108n (e.g., via a global positioning system associated with each device), such as location coordinates (e.g., latitude, longitude, and / or altitude) and status regarding the matching request (e.g., currently in a ride, not in a ride, available, or unavailable).

[0041] To facilitate connecting requests with transportation vehicles (e.g., vehicles associated with provider devices), the multi-device selection system 102 communicates with the requester devices 110a-110n (e.g., through a requester application 114) and the provider devices 108a-108n (e.g., through a provider application 112). As illustrated by FIG. 1 , the requester devices 110a-110n include the requester application 114, and the provider devices 108a-108n include the provider application 112. In various embodiments, the multi-device selection system 102 communicates with the requester devices 110a-110n and the provider devices 108a-108n through the requester application 114 and the provider application 112, respectively, to receive and provide information including, for example, transportation request information (e.g., pickup and / or drop-off locations) and provider device information (e.g., provider device locations).

[0042] In some embodiments, the provider application 112 may include multiple transportation matching modes (e.g., a destination transportation matching mode or a high-price transportation mode), each corresponding to a different algorithm or rule set for matching transportation requests with the provider devices 108a. The requester application 114 and the provider application 112 also optionally include computer-executable instructions that, when executed by the requester devices 110a-110n and the provider devices 108a-108n, cause the requester devices 110a-110n and the provider devices 108a-108n to perform certain functions as described herein.

[0043] As indicated above, the multi-device selection system 102 can provide (or cause the provider device 108a to render) a visual indicator regarding a location associated with a transportation request. For example, in some cases, the multi-device selection system 102 selects a provider device 108a to potentially service multiple transportation requests received from various requester devices 1010a-110n based on various factors, such as the location associated with the transportation request, the provider device location, the locations of other provider devices, a direction filter, an arrival time filter, a provider device incentive, a requester device incentive, the time of day, traffic information, and / or other transportation matching considerations. Based on the selection of the provider device 108a to service the transportation request, the multi-device selection system 102 provides a visual indicator for the transportation request for display within a user interface displayed on the provider device 108a (e.g., as part of the provider application 112).

[0044] 1 illustrates an environment having a particular number and configuration of components associated with the multi-device selection system 102, in some embodiments, the environment may include more or fewer components with varying configurations. For example, in some embodiments, the multi-device selection system 102 may communicate directly with the requester devices 110a-110n, bypassing the network 116. In these or other embodiments, the multi-device selection system 102 may be housed in and / or implemented (in whole or in part) by the provider devices 108a-108n. The multi-device selection system 102 may also include or communicate with a database for storing transportation request information, directional filter information, transportation request filter information, arrival time filter information, token information, and / or other information described herein.

[0045] As noted, the multi-device selection system 102 can intelligently present and update a subset of transportation requests within an interactive digital map on the graphical user interface of each provider device. For example, FIG. 2 illustrates a multi-device selection system 102, according to one or more embodiments, selecting and providing multiple transportation requests for display on a provider device. Specifically, FIG. 2 illustrates the multi-device selection system 102 receiving a set of transportation requests from multiple requester devices 202a-202n and identifying information (e.g., availability, location, provider device ratings, etc.) regarding multiple provider devices 210(a)-210b. The multi-device selection system 102 identifies characteristics associated with the requester devices 202a-202n and characteristics associated with the transportation requests and transportation vehicle provider devices 210(a)-210(b). The multi-device selection system 102 utilizes a multi-request transportation model to analyze the identified characteristics and select a subset of transportation requests to present to the provider devices 210a-210b. Once selected, the multi-device selection system 102 displays selectable elements 212a-212e representing the selected transportation request within an interactive map 214 on the provider device 210a-210b interface.

[0046] As mentioned above, the multi-device selection system 102 can receive a set of transportation requests 216 from the requester devices 202a-202n. In some embodiments, the multi-device selection system 102 extracts various characteristics related to the requester devices 202a-202n and corresponding transportation requests. For example, the multi-device selection system 102 can determine characteristics (e.g., information) provided by the requester devices, such as a desired pickup location, a desired pickup time, or a destination. Similarly, the multi-device selection system 102 can determine or infer characteristics related to the requester devices 202a-202n and corresponding transportation requests, such as a measure of ride desirability or a measure of match probability. Similarly, the multi-device selection system 102 can identify stored / historical characteristics associated with the requester devices, such as a requester device rating, previous transportation matches, or cancellation history.

[0047] Additionally, in one or more embodiments, the multi-device selection system 102 can extract characteristics associated with the provider devices 210a-210b. For example, the multi-device selection system 102 can receive from the provider devices 210a-210b (via GPS systems associated with the provider devices) a current location, a ride status, or an online status. Additionally, the multi-device selection system 102 can determine or infer characteristics associated with the provider devices 210a-210b, such as a measure of provider device matching probability or ride acceptance probability. The multi-device selection system 102 can also receive (e.g., from the server 106) stored / historic characteristics associated with the provider devices 210a-210b, such as driver ratings, previous transportation matches, provider device preferences, etc.

[0048] In some embodiments, the multi-device selection system 102 determines characteristics associated with a transport request by monitoring interactions (or lack of interactions) across a network of provider devices related to the transport request. For example, the multi-device selection system 102 can identify whether a transport request was ignored or canceled by one or more provider devices. Similarly, the multi-device selection system 102 can monitor the amount of time a transport request has been pending or the amount of time that has elapsed since cancellation. Additionally, the multi-device selection system 102 can identify the probability that a transport request will be selected to create a transport match after an initial cancellation / denial. Similarly, the multi-device selection system 102 can identify the probability that a provider device will accept the transport request.

[0049] In addition to identifying features associated with the transportation requests and the provider devices 210a-210b, the multi-device selection system 102 can compare the identified features to select transportation requests to present to the provider devices. In particular, in some embodiments, the multi-device selection system 102 can utilize a multi-request transportation model to analyze the identified features and generate a matching score. Based on the determined matching score, the multi-device selection system 102 can select a subset of transportation requests to present to the provider devices 210a-210b. For example, the multi-device selection system 102 can select transportation requests corresponding to the requester devices 202a, 202b, and 202c to present on the provider device 210a. More specifically, the multi-device selection system 102 can present selectable elements 212a, 212b, and 212c representing transportation requests corresponding to the requester devices 202a, 202b, and 202c on an interactive map 214 on the interface of the provider device 210a. Further details regarding the transport request features and provider device features are discussed in FIGS. 3A, 3B, and 4.

[0050] As shown, the multi-device selection system 102 selects and presents selectable elements 212a-212c and interactive map 214 via the interface of provider device 210a. The multi-device selection system 102 can also dynamically update selectable elements 212a-212e and interactive map 214. For example, if provider device 210b matches the transportation request, the multi-device selection system can remove selectable element 212a corresponding to the transportation request from the interface of another provider device. More information regarding the presentation and updating of selectable elements is discussed below (e.g., in connection with FIGS. 5A-5C).

[0051] As discussed above, the multi-device selection system 102 determines whether to apply a multi-request transportation model, a single-request transportation model, or both in response to a transportation request. For example, Figures 3A-3B show that the multi-device selection system 102 utilizes a transportation request filter 304 and features 306 (e.g., transportation request features) to determine whether to route a transportation request for a requester device 302a-302n to a multi-request transportation model 308, a single-request transportation model 310, or both.

[0052] 3A, the multi-device selection system 102 receives a set of transport requests 322 corresponding to requester devices 302a-302n and analyzes the transport requests utilizing a transport request filter 304. The transport request filter 304 can identify features 306 and apply various computer-implemented algorithms to determine whether to apply a multi-request transport model 308, a single-request transport model 310, or both models to the transport request.

[0053] As previously mentioned, the multi-device selection system 102 can identify features 306. The features 306 can include information about the transportation request corresponding to the requester device 302a. For example, the features 306 can include, but are not limited to, transportation route, transportation route distance, desired pickup location, desired drop-off location, desired drop-off time, desired pickup time, travel time, traffic information, cancellation / rejection history, time elapsed since cancellation / rejection, request type (e.g., group ride, multi-destination ride, specific vehicle type ride, etc.), match wait time, number of available provider devices, transportation price, desirability, match probability, and requester device rating. The multi-device selection system 102 can identify various combinations of the features 306.

[0054] As indicated above, the multi-device selection system 102 can identify characteristics 306 associated with a transportation route. More specifically, the multi-device selection system 102 can identify factors related to route distance, pickup locations and / or times, drop-off locations and / or times, travel time, and / or traffic information. For example, in some embodiments, the multi-device selection system 102 can identify that a transportation route encounters heavy traffic, increasing travel time for a transportation request by 5 minutes. In other embodiments, the multi-device selection system 102 can identify the ease or difficulty of traveling to a desired pickup location. The multi-device selection system 102 can select a particular model to analyze a transportation request based on these transportation route characteristics.

[0055] The multi-device selection system 102 can also identify characteristics related to the rejection history of a transportation request. For example, the multi-device selection system 102 can determine whether a transportation request corresponding to the requester device 302a was matched using different transportation matching models and whether a provider device in that transportation model rejected the transportation request. In practice, the multi-device selection system 102 can identify when a rejection occurred and determine how much time has passed since the rejection. For example, the multi-device selection system 102 can determine that a transportation request was rejected in a single-request transportation model and exceeded a threshold amount of time (e.g., 15 seconds). In response to these determinations, the multi-device selection system 102 can select the multi-request transportation model 308.

[0056] As previously mentioned, the multi-device selection system 102 can identify characteristics related to the request type. For example, the multi-device selection system 102 can determine whether the transportation request corresponding to the requester device 302a includes a standard transportation request (requesting a ride for one requester device), a shared transportation request (e.g., sharing a transportation route with other requester devices), a luxury transportation request (e.g., transporting the requester device in a luxury vehicle), an extra-seat transportation request (e.g., transporting the requester device in a larger vehicle), and / or a luxury extra-seat transportation request (e.g., transporting the requester device in a larger luxury vehicle). In some embodiments, the multi-device selection system 102 can determine the request type based on receiving an indication from the requester device. For example, in one or more embodiments, the multi-device selection system 102 can receive a transportation request in which the requester device selects a luxury ride element. The multi-device selection system 102 can select a particular model based on the transportation request type (e.g., to ensure that different modes are available across different models).

[0057] The multi-device selection system 102 can also identify characteristics associated with the request type by determining whether the transportation request is requesting transportation to or from a transportation hub (e.g., an airport, train station, bus station, etc.), an event (e.g., a concert, professional sporting event, tournament, etc.), or an accommodation (e.g., a hotel, motel, etc.). For example, in some embodiments, the multi-device selection system 102 can determine that the transportation request type is an event pickup based on the requester device indicating that the transportation request is to pick up the requester device from a basketball game. In other embodiments, the multi-device selection system 102 can determine the type of transportation request based on a desired pickup location. For example, the multi-device selection system 102 can determine that the transportation request is an airport transportation request based on a desired pickup location that corresponds to an airport terminal address. The multi-device selection system 102 can select a particular model based on these characteristics (e.g., to ensure that different models have a variety of different destinations / locations and / or to determine the likelihood of various ride acceptances).

[0058] As discussed above, the multi-device selection system 102 can identify factors associated with transportation request wait times and provider device availability. For example, the multi-device selection system 102 can identify wait times for similar transportation requests, average wait times for active transportation requests, wait times for withdrawn transportation requests, wait times for transportation requests within a geographic region, and / or wait times for a particular time of day. In some embodiments, the multi-device selection system 102 identifies and / or averages wait times in a single-request transportation model and / or across multiple transportation request matching models (e.g., the multi-request transportation model 308 and the single-request transportation model 310). The multi-device selection system 102 can select a particular model based on wait times (e.g., to ensure that different models have similar wait times and access to ride quality options and / or to reduce overall wait times by selecting a particular model).

[0059] The multi-device selection system 102 can also determine the number of available provider devices (and / or the number of requester devices). More specifically, the multi-device selection system 102 can determine how many provider devices can provide transportation services in a geographic area and / or the number of requester devices in the geographic area (e.g., within a threshold distance or geohash). In some embodiments, the multi-device selection system 102 determines a balance metric between the number of provider devices and the number of requester devices. The multi-device selection system 102 can utilize the number of available provider devices / requester devices to select a particular model (e.g., to provide additional options for provider devices in redressing device imbalances).

[0060] As previously mentioned, the multi-device selection system 102 may identify features 306 associated with a shipping price. As previously described, a shipping price refers to a score, such as a reward or cost, associated with a shipping request. Accordingly, the multi-device selection system 102 may identify potential revenue, bonuses, and / or losses. To illustrate, in some embodiments, the multi-device selection system 102 can estimate revenue for completing a shipping request corresponding to the requester device 302a. In other embodiments, the multi-device selection system 102 can display an estimated tip. The multi-device selection system 102 can use the shipping price to select from models (e.g., to ensure that similarly priced models are available across different models).

[0061] As indicated above, the multi-device selection system 102 may identify a desirability measure (e.g., ride desirability) corresponding to a transportation request. In particular, the multi-device selection system 102 may determine a provider device desirability measure associated with the transportation request, such as a predicted interaction rate, a predicted price to the provider, or a predicted cancellation / rejection rate. For example, the multi-device selection system 102 may analyze historical data to identify characteristics indicative of the desirability of transportation request features (e.g., transportation route or destination). Illustratively, transportation requests from requester devices with high requester device ratings (e.g., passenger ratings), high transportation prices (e.g., large estimated revenues), and preferred drop-off locations are highly desirable. Conversely, the multi-device selection system 102 may analyze historical data to identify undesirable characteristics. For example, in some embodiments, transportation requests with inconvenient pickup times and undesirable drop-off locations are less desirable. Additionally, in some embodiments, the multi-device selection system 102 may determine desirability based on various combinations of transport request characteristics described herein. The multi-device selection system 102 may select a model for a particular transport request based on a measure of desirability (e.g., to ensure that different models have access to desirable transport requests).

[0062] As previously discussed, the multi-device selection system 102 can determine a match probability for a transportation request. More specifically, the multi-device selection system 102 may determine the likelihood that a provider device will match the transportation request. For example, the multi-device selection system 102 can identify features associated with the transportation request, and based on a combination of features, the multi-device selection system 102 can determine the probability that the transportation request will result in a transportation match. For example, in some embodiments, the multi-device selection system 102 can determine, based on historical and / or contemporaneous data, that a transportation request with a pickup location from an airport to a nearby hotel in the evening has a high match probability. Conversely, the multi-device selection system 102 can determine that a transportation request with a long travel time and a low transportation price has a lower match probability. The multi-device selection system 102 can select a model based on match probability (or revocation probability). Illustratively, the multi-device selection system 102 can select transportation requests with a revocation probability or acceptance rate of 25-75% for the multi-request transportation model 308.

[0063] As indicated above, the multi-device selection system 102 can identify characteristics 306 related to a requestor device rating. In particular, the multi-device selection system 102 can identify a grade, ranking, and / or feedback related to previous transportation matches associated with the requestor device. Illustratively, the requestor device rating can be a rating on a scale of 1 to 5 or a selection on a scale from very dissatisfied to very satisfied. Additionally, in one or more embodiments, feedback (e.g., written communication) regarding the requestor device can influence the rating of the requestor device. For example, the requestor device rating can be an average of previous ratings for the requestor device. The multi-device selection system 102 can select a model based on the requestor device rating (e.g., to ensure that the model has a certain number or percentage of transportation requests with a threshold requestor device rating).

[0064] As previously mentioned, the multi-device selection system 102 may utilize a transportation request filter 304 to determine whether to utilize a multi-request transportation model 308 and / or a single-request transportation model 310 in analyzing the transportation request. As used herein, the term “transportation request filter” refers to a computer-implemented algorithm that selects, identifies, and / or filters transportation requests (e.g., for a particular matching model). For example, in one or more embodiments, the multi-device selection system 102 utilizes a transportation request filter to select transportation requests corresponding to the requester devices 302a-302n for the multi-request transportation model 308 based on the characteristics 306 identified by the multi-device selection system 102.

[0065] To illustrate, in one or more embodiments, the multi-device selection system 102 monitors transport requests to determine when they are denied by one or more provider devices. For example, the multi-device selection system 102 can determine an initial match with a provider device and detect that the provider device causes the transport to lapse (e.g., not be granted within a certain time frame) or that the provider device / requester device has canceled the transport request. In response to determining that the transport request is denied, the transport request filter 304 can assign the transport request corresponding to the requester device 302a to the multi-request transport model 308.

[0066] Additionally, in some embodiments, the multi-device selection system 102 may utilize a transport request filter 304 to assign transport requests corresponding to the requester devices 302a-302n based on a combination of rejected transport requests and / or an elapsed time frame (e.g., a threshold time frame). For example, in one or more embodiments, the transport request filter 304 may select a multi-request transport model 308 based on a threshold time frame (e.g., 5 seconds) being exceeded without any additional matches after a provider device rejected a transport request.

[0067] In other embodiments, the transportation request filter 304 can feed a specific number and / or percentage (e.g., a percentage) of highly desirable transportation requests into the multi-request transportation model 308. For example, the multi-device selection system 102 can determine a desirability score for the transportation requests and apply an initial threshold to determine the desirable transportation requests. The multi-device selection system 102 can then select a threshold amount of desirable transportation requests for a particular model. For example, the multi-device selection system 102 can employ a ride desirability threshold where 15% of all transportation requests in the multi-request transportation model 308 are desirable / desirable transportation requests.

[0068] As indicated above, the transportation request filter 304 can utilize various mechanisms to filter transportation requests into various transportation matching models. For example, the transportation request filter 304 can utilize a random classification model to filter trips into the multi-request transportation model 308. For example, in some embodiments, the transportation request filter 304 can randomly select and allocate 10 percent of all transportation requests into the multi-request transportation model 308.

[0069] Additionally, the multi-device selection system 102 can select a matching transportation model for the transportation request based on an optimization model (e.g., a local greedy optimization model or a global optimization model). For example, the multi-device selection system 102 can analyze the characteristics 306 identified by the multi-device selection system 102 and direct the corresponding transportation request into a multi-request transportation model 308 or a single-request transportation model 310 to optimize a particular outcome or goal.

[0070] To illustrate, the multi-device selection system 102 can determine a cost / reward score corresponding to the features 306. To illustrate, the multi-device selection system 102 can determine a cost / reward price for distance traveled for a transportation request between the multi-request transportation model 308 and the single-request transportation model 310 (e.g., to ensure that requests assigned to one model are not biased according to distance). Similarly, the multi-device selection system 102 can determine a cost / reward price for wait time, transportation price, elapsed time, and destination.

[0071] Additionally, the multi-device selection system 102 can determine the price difference corresponding to selecting the multi-request transportation model 308 and the single-request transportation model 310. For example, utilizing the multi-request transportation model 308 allows time for provider devices to select transportation requests, which may slightly increase overall elapsed time. However, utilizing the multi-request transportation model 308 may also increase the overall number of provider devices (and driver experience) by providing an improved user interface and options. The multi-device selection system 102 can utilize an optimization model to balance these competing factors.

[0072] Additionally, the multi-device selection system 102 can determine a cost / reward price related to the number of available provider devices and / or the number of available requester devices. For example, the transportation matching system 104 may operate inefficiently when there is an imbalance between provider devices and requester devices within a geographic region. Furthermore, utilizing the multi-request transportation model 308 and / or the single-request transportation model 310 can exacerbate or correct these inefficiencies. For example, submitting additional transportation requests via the multi-request transportation model 308 can provide additional options to provider devices and increase the number of provider devices operating within the transportation matching system. Thus, the multi-device selection system 102 can route additional transportation requests to the multi-request transportation model 308 when a device imbalance exists, such that there are too many provider devices relative to the requester devices. Conversely, when a device imbalance exists, such that there are too many requester devices relative to the provider devices, the multi-device selection system 102 can route additional transportation requests to the single-request transportation model 310. If the balance is relatively balanced, the multi-device selection system 102 may route the transport request to both the multi-request transport model 308 and the single-request transport model 310 .

[0073] The multi-device selection system 102 may also determine cost / reward prices, desirability, request type, transportation price, and / or match probability for requester ratings. For example, providing a multi-request transportation model 308 and / or a single-request transportation model 310 with an imbalance of difficult requesters, low transportation price requests, shared rides, and / or low match probability requests may impact the number of provider devices attempting to provide transportation requests or receive transportation matches via one of the models. Accordingly, the multi-device selection system 102 may consider and balance these factors in selecting transportation requests to utilize via each model.

[0074] For example, in one or more embodiments, the multi-device selection system 102 selects an overall goal (e.g., total number of rides, total number of provider devices, or overall transportation price efficiency). The multi-device selection system 102 then determines how each of the features 306 contributes to the overall goal by assigning a corresponding score / reward to the feature. The multi-device selection system 102 then utilizes an optimization algorithm to assign transportation requests to specific models to optimize the overall goal.

[0075] The multi-device selection system 102 may utilize a local greedy optimization model that determines scores for the transportation requests and iteratively allocates the transportation requests based on the highest remaining scores. The multi-device selection system 102 may also utilize a global optimization model that analyzes the transportation requests as a whole to determine an optimal combination of allocations to improve the overall goal.

[0076] In some embodiments, the transport request filter 304 utilizes a machine learning model to analyze the features 306 identified by the multi-device selection system 102. In particular, the term “machine learning model” includes a computer algorithm or collection of computer algorithms that can be trained and / or adjusted based on input for approximate unknown functions. As another example, a machine learning model can include a computer algorithm with branches, weights, or parameters that change based on training data to improve for a particular task. Thus, a machine learning model can utilize one or more learning techniques to improve accuracy and / or efficiency. Exemplary machine learning models include various types of decision trees, support vector machines, Bayesian networks, random forest models, or neural networks (e.g., deep neural networks).

[0077] In one or more embodiments, the transport request filter 304 can utilize a machine learning model to assign transport requests to the multi-request transport model 308 or the single-request transport model 310. For example, in some embodiments, the machine learning model can encode the features 306 and feed the encoded features into channels of a neural network, a decision tree, or other machine learning model. The machine learning model can process the encoded features (e.g., through layers of a neural network or branches of a decision tree) to generate a predictive model to assign to the transport request. Thus, the multi-device selection system 102 can utilize a machine learning model to assign transport requests to the multi-request transport model 308 and / or the single-request transport model 310. In some embodiments, the machine learning model generates a predicted outcome or state change (e.g., likelihood of reduced wait time, likelihood of improved provider-device interaction, etc.) and selects a model based on the predicted outcome or state change.

[0078] Additionally, in certain embodiments, the multi-device selection system 102 trains or adjusts a machine learning model. In particular, the multi-device selection system 102 utilizes an iterative training process to adapt the transport request filter machine learning model by adjusting or adding decision trees or learning parameters that result in accurately filtering transport requests into the multi-request transport model 308. For example, the multi-device selection system 102 can generate a predicted outcome or state change (e.g., a predicted wait time or a predicted amount of provider device engagement based on a selected model). The multi-device selection system 102 then compares the prediction to measured ground truth. The multi-device selection system 102 can utilize a loss function to determine a measure of loss between the predicted outcome and the ground truth and modify the parameters of the machine learning model based on the predicted outcome.

[0079] In some embodiments, the multi-device selection system 102 utilizes a reinforcement learning model, such as a Markov decision process. For example, the multi-device selection system 102 can utilize a transport request filter 304 (or selection model) that includes a learner model and a decision-making (i.e., agent) model. The agent model selects an action for a given state, to which the environment responds by transitioning to a new state with a corresponding reward. Based on past patterns reflected in the above features, the multi-device selection system 102 can learn the probabilities of state changes and rewards associated with particular actions. Thus, in one or more embodiments, the multi-device selection system 102 learns the probabilities of different state transitions and rewards by analyzing the past features described above. Furthermore, the transport request filter 304 can then determine the current state and select a particular action (e.g., model) to move to an improved state and corresponding reward. Thus, the multi-device selection system 102 can include a reinforcement learning model that is utilized to select a model that improves (e.g., maximizes) the probability of a particular reward or outcome (e.g., improved efficiency, reduced wait time, improved provider device utilization, or improved number of rides).

[0080] 3A, the multi-device selection system 102 assigns the transportation requests corresponding to the requester devices 302a-302c to the multi-request transportation model 308. Additionally, the multi-device selection system 102 assigns the transportation requests corresponding to the requester devices 302d and 302e to the single-request transportation model 310.

[0081] In practice, the multi-device selection system 102 utilizes a multi-request transportation model 308 to generate potential transportation matches between transportation requests corresponding to the requester device 302a and several provider devices. As previously mentioned, the multi-request transportation model 308 can further identify characteristics associated with the transportation requests and analyze these characteristics by utilizing an optimization model (e.g., a local greedy optimization model or a global optimization model) or a machine learning model. Based on the analysis, the multi-device selection system can select which transportation requests (and how many transportation requests) to present to which provider devices (and how many provider devices). Further details regarding the multi-request transportation model 308 are provided below (e.g., with respect to FIG. 4).

[0082] 3A, the multi-device selection system 102 creates a transportation match between a transportation request and a provider device using a single-request transportation model 310. As discussed above, the single-request transportation model 310 can identify characteristics related to the transportation request and analyze these characteristics to determine an optimal transportation match between the transportation request and a single provider device.

[0083] While FIG. 3A illustrates the multi-device selection system 102 selecting the multi-request transportation model 308 or the single-request transportation model 310, the multi-device selection system 102 can utilize both models to determine a match for a particular transportation request. Indeed, as shown in FIG. 3B, the multi-device selection system 102 utilizes the transportation request filter 304 and the features 306 to select both the multi-request transportation model 308 and the single-request transportation model 310 for a particular transportation request. As discussed above, the multi-device selection system 102 can identify features associated with the transportation request. As discussed above, the transportation request filter 304 can analyze various combinations of the features 306 to determine a match for the transportation request using the multi-request transportation model 308 and the single-request transportation model 310.

[0084] To illustrate, in one or more embodiments, based on transportation request desirability and drop-off location, the multi-device selection system 102 can analyze the transportation request corresponding to the requester device 302a using a single-request transportation model 310 and a multi-request transportation model 308. In one or more embodiments, if the transportation request corresponding to the requester device 302a is entered into both transportation matching models, the multi-request transportation model 308 can present the transportation request to multiple provider devices, and the single-request transportation model 310 can offer the transportation request to one provider device.

[0085] In some embodiments, the multi-request transport model 308 draws from a pool of participating multi-request provider devices, and the single-request transport model 310 draws from a separate pool of participating single-request provider devices. Illustratively, in one or more embodiments, the multi-device selection system 102 can present a transport request to a set of provider devices from the pool of participating multi-request provider devices in the multi-request transport model 308 and simultaneously present a transport request to a provider device from the pool of single-request provider devices. The multi-device selection system 102 can then finalize a match based on which provider device will most quickly select, accept, or confirm the transport request.

[0086] In some embodiments, the multi-device selection system 102 can utilize a time buffer to provide a transport request via a first model before utilizing a second model. For example, the multi-device selection system 102 can provide a transport request to a selected provider device via the multi-request transport model 308 for a time buffer (e.g., 10 seconds) before providing a transport request to a selected provider device via the single-request transport model 310.

[0087] As noted, the multi-device selection system 102 can utilize the multi-request transport model 308 and features to select which transport requests to present to each provider device. In particular, Figure 4 illustrates the multi-device selection system 102 evaluating transport requests from requester devices 402a-402n by utilizing the multi-request transport model 404 to analyze features 406 associated with the transport requests.

[0088] As shown in FIG. 4, the multi-request transportation model 404 can receive a set of transportation requests 412 from several requester devices 402a-402n. Upon receiving the transportation requests, the multi-device selection system 102 identifies and utilizes features 406 associated with the set of transportation requests 412 and the provider devices 410a-410b. The features 406 can include various types of information (including that discussed above with respect to FIG. 3) regarding the transportation requests from the requester devices 402a-402n. For example, the features 406 associated with the transportation request corresponding to the requester device 402a can include, but are not limited to, a transportation route, a transportation route distance, a pickup location, a drop-off location, a drop-off time, a pickup time, a travel time, traffic information, a rejection history, time elapsed since rejection, a request type, a match wait time, a number of available provider devices, a transportation price, a desirability / preferability measure, a match probability, a requester device rating, and / or a route distinction.

[0089] As previously mentioned, the multi-device selection system 102 can identify and utilize route-differentiating features. In particular, in some embodiments, the multi-device selection system 102 can identify, compare, and / or quantify features between transportation requests. For example, in one or more embodiments, the multi-device selection system 102 can compare the transportation routes of three transportation requests to determine differences between pickup locations, drop-off locations, and / or travel distances. Based on these differences, the multi-device selection system 102 can determine route-differentiating prices (e.g., scores, labels, etc.) between the transportation routes. For example, the multi-device selection system 102 can present transportation requests based on (e.g., increasing) route differentiation. For example, the multi-device selection system 102 can offer a mix of locations, routes, and durations for any particular provider device. This allows the multi-device selection system 102 to offer transportation requests with various options to improve driver engagement and utilization. The multi-device selection system 102 can identify, compare, and / or determine differences between any combination of features 406.

[0090] As indicated above, the multi-device selection system 102 can identify characteristics associated with the provider devices 410a-410b. For example, in one or more embodiments, the characteristics 406 associated with the provider devices can include, but are not limited to, provider device proximity, provider device direction, provider device rating, match probability, provider device overlap condition, provider device interface congestion, and / or provider device availability.

[0091] For example, in one or more embodiments, the multi-device selection system 102 can identify characteristics related to the proximity of provider devices to a desired pickup location. For example, in one or more embodiments, the multi-device selection system 102 can identify a driving distance or time (e.g., ETA) between the location of the provider device and the desired pickup location. The multi-device selection system 102 can use the proximity to select provider devices (e.g., select provider devices that are close to the transportation request). In some implementations, the multi-device selection system 102 provides ETAs for provider devices within a threshold for all transportation requests.

[0092] As indicated above, the multi-device selection system 102 can identify provider device rating characteristics. In particular, the multi-device selection system 102 may identify grades, rankings, and / or feedback regarding previous transportation matches (e.g., from requester devices) associated with the provider device. For example, in one or more embodiments, the ratings may be on a scale (e.g., rating provider device services on a scale of 1 to 5). The multi-device selection system 102 can utilize the ratings to select provider devices. In some implementations, the multi-device selection system 102 ranks provider devices and presents transportation requests to a certain number of the highest-scoring provider devices (e.g., highest-rating or highest-match-scoring provider devices). In some embodiments, the multi-device selection system 102 ranks requester devices and presents a certain number of the highest-rated requester devices / transportation requests to a particular provider device. In some embodiments, the multi-device selection system 102 only presents a threshold number of transportation requests (e.g., the 5 closest rides or the 5 highest-rated rides).

[0093] The multi-device selection system 102 can also determine the number of provider devices (e.g., the capacity of the provider devices). The multi-device selection system 102 can select provider devices based on this available capacity. For example, the multi-device selection system 102 can select the provider device with the highest score / rating, subject to capacity constraints. For example, if each provider can have at most m rides and each transportation request can be represented by at most n rides, then for each ride, the multi-device selection system 102 can assign it to the highest-scoring driver who has not exceeded capacity (until either the transportation request does not have n drivers or there are no more drivers left).

[0094] As previously discussed, the multi-device selection system 102 can identify a match probability. For example, as mentioned above, the match probability comprises the likelihood that a provider device will accept a transportation request. In particular, in one or more embodiments, based on characteristics associated with the transportation request and / or historical data corresponding to previous transportation matches, the multi-device selection system 102 can calculate the likelihood that a provider device will accept a transportation request. For example, in one or more embodiments, based on the desired pickup location, travel distance, and / or ride price and acceptance history, the multi-device selection system 102 can determine that there is a 50% likelihood that a provider device will accept a transportation request. The multi-device selection system 102 can utilize the match probability to select provider devices (e.g., select provider devices that increase the match probability and / or stay within the total combined match probability).

[0095] The multi-device selection system 102 may utilize and / or analyze any number of features 406 to calculate a match probability. For example, in one or more embodiments, based on time, location, requester device, rating, and / or drop-off location, the multi-device selection system 102 may identify that a provider device has a 20% chance of accepting the transportation request. As another example, in one or more embodiments, the multi-device selection system 102 may determine a match probability for a single transportation request for multiple provider devices. For example, in one or more embodiments, based on the features 406, one provider device may have a 30% chance of accepting the transportation request, while a different provider device may have a 70% chance of accepting the same transportation request.

[0096] The multi-device selection system 102 may also identify, calculate, and / or determine a match probability for provider devices related to multiple transport requests. The multi-device selection system 102 may also identify potential provider device overlap conditions (e.g., tiebreakers). A provider device overlap condition may include one or more provider devices attempting to grant the same transport request. Illustratively, in one or more embodiments, if one provider device has an 80% chance of granting the transport request and a second provider device has a 75% chance of granting the same transport request, the multi-device selection system 102 may determine that an overlap condition likely exists between the provider devices. Based on the high likelihood of the overlap condition, the multi-device selection system 102 may avoid the overlap condition by avoiding submitting the transport request to both devices.

[0097] Additionally, in one or more embodiments, the multi-device selection system 102 can determine the likelihood of an overlap condition between two or more provider devices. In particular, in one or more embodiments, the multi-device selection system 102 can determine a potential provider device overlap condition based on the characteristics 406 and past transportation match data. Illustratively, in one or more embodiments, based on the desired drop-off location, transportation route, and past characteristics associated with previous transportation matches, the multi-device selection system 102 can determine the likelihood that both provider devices 410a-410b will accept the transportation request. In one or more embodiments, the multi-device selection system 102 can predict an overlap condition for any transportation request between any of the provider devices 410a-410b.

[0098] As mentioned above, the multi-device selection system 102 can identify provider device interface congestion characteristics. For example, the multi-device selection system 102 can determine the number of transport requests to present on the available space within the interface to avoid overcrowding. As previously discussed, the multi-device selection system 102 can efficiently present transport requests, thereby allowing the provider device interface to quickly and accurately display the transport requests. In one or more embodiments, the multi-device selection system 102 can identify the model, screen size, clarity, and / or components of the provider device. For example, in one or more embodiments, based on a provider device having a large graphical user interface, the multi-device selection system 102 can determine to present four transport requests on the provider device.

[0099] 4 and as previously discussed, the multi-device selection system 102 can utilize a multi-request transportation model 404. In particular, the multi-device selection system 102 can utilize the multi-request transportation model 404 to select the number of provider devices to receive a transportation request, the number of transportation requests to present to the provider devices, and the particular provider device to receive the particular transportation request. Similar to the transportation request filter 304, the multi-device selection system 102 can utilize a variety of computer-implemented models, including heuristic models, optimization (goal) models, and / or machine learning models (e.g., neural networks or reinforcement learning).

[0100] For example, the multi-device selection system 102 may utilize a heuristic model. To illustrate, in one or more embodiments, the multi-device selection system 102 may present transportation requests within a geographic region to provider devices that are within a certain distance and / or time to a pickup location for the transportation request. The multi-device selection system 102 may utilize various trigger rules or thresholds for presenting transportation requests. For example, the multi-device selection system 102 may present a threshold number of recent transportation requests, a number of high-rated requests, or a number of transportation requests that meet a route diversity threshold (or other trigger / rule variations as described herein).

[0101] In some embodiments, the multi-device selection system 102 can present transportation requests based on match probabilities. Illustratively, in one or more embodiments, the multi-device selection system 102 can present transportation requests to provider devices whose aggregate match probabilities do not exceed a threshold (e.g., 100%). For example, the multi-device selection system 102 can present transportation requests to five provider devices if the sum of their match probabilities is less than 1 (or 100%).

[0102] In some embodiments, the multi-device selection system 102 can stagger the presentation of transportation requests to provider devices based on match probability, overlapping condition likelihood, and / or other characteristics. For example, the multi-device selection system 102 can present the transportation request to a first provider device a first time (e.g., based on a higher score or rating). The multi-device selection system 102 can wait a period of time (e.g., 10 seconds) and then present the transportation request to a second provider device a second time.

[0103] As another example, in one or more embodiments, the multi-device selection system 102 may select a provider device such that a particular number or ratio (or percentage) of transportation requests presented to the provider device are desirable and / or have a high transportation price.

[0104] In other embodiments, the multi-device selection system 102 may utilize a scoring system to present a transportation request to a provider device. The scoring system may be based on one or more identified features and / or a combination of features associated with the transportation request. For example, in one or more embodiments, the multi-device selection system 102 may present a transportation request based on a requester device rating. Illustratively, in one or more embodiments, the multi-device selection system 102 may present a transportation request for requester devices with a requester device rating above a certain threshold. In other embodiments, the multi-device selection system 102 may present a transportation request based on a composite score of the combined features. The multi-device selection system 102 may also generate a composite score for any combination of features. For example, the multi-device selection system 102 may calculate a composite score for a transportation request based on the requester device rating and the transportation price. For example, in one or more embodiments, the multi-device selection system 102 may present a transportation request with a composite score above a specified threshold.

[0105] Relatedly, the multi-device selection system 102 can utilize a scoring system to determine which transport requests to present to provider devices. For example, in some embodiments, the multi-device selection system 102 can present transport requests to provider devices that have provider device ratings similar to the requester device rating. Additionally, the multi-device selection system 102 can present transport requests to provider devices that have provider device ratings above a particular threshold.

[0106] As previously indicated, the multi-request transportation model 404 can include an optimization model. In particular, the multi-device selection system 102 can utilize the optimization model to select which (and how many) transportation requests to present to which (and how many) provider devices. For example, the multi-device selection system 102 can determine costs / rewards corresponding to the features 406 and utilize the optimization model to distribute transportation requests to the provider devices in a manner that improves (e.g., maximizes or optimizes) an overall objective function.

[0107] Thus, for example, the multi-device selection system 102 may utilize an objective function with costs / rewards for reducing wait time / ETA, reducing travel time for the requester device, increasing route distinction, meeting requester needs / requests (such as quick matches), meeting provider needs / requests (access to high-quality, high-value rides with low downtime), increasing rating distinction, increasing match probability (probability of acceptance), increasing the total number of rides, reducing cancellations, reducing screen congestion, or increasing provider device utilization. For example, the multi-device selection system 102 may allocate transportation requests to provider devices in a manner that increases the total value associated with these various characteristics / factors / goals.

[0108] As discussed above, in some embodiments, the multi-device selection system 102 utilizes a local greedy optimization algorithm. For example, the multi-device selection system 102 can determine scores for allocating various transportation requests to various provider devices. The multi-device selection system 102 can allocate transportation requests based on the scores (e.g., in descending order). This approach can result in intelligent allocation of requests (and can be computationally efficient), but may not provide a globally optimal solution.

[0109] Accordingly, in some embodiments, the multi-device selection system 102 utilizes a global optimization model. For example, the multi-device selection system 102 can determine the overall combination of transportation requests and provider devices that provides an improved (e.g., optimal) solution across all requests. Thus, the multi-device selection system 102 can analyze multiple combinations of transportation requests across multiple provider devices and select the combination that yields the optimal overall result.

[0110] In some embodiments, the multi-device selection system 102 utilizes an optimized score with a capacity constraint depending on the individual revocation probabilities. Let p_ij be the probability that provider device i will accept transport request j, and let x_ij be an indicator variable for whether transport request j is presented to provider device i. The fixed capacity constraint may have the form sum_i x_ij <= n. The multi-device selection system 102 may utilize a formulation such as sum_i p_ij x_ij <= n. Using this formulation, the expected number of provider devices that will accept a transport request is at most n. A natural value for n may be 1.

[0111] In addition to the optimization model (e.g., objective function), the multi-device selection system 102 may also utilize and train machine learning models to determine which transportation requests to present on provider devices. For example, a multi-request transportation matching machine learning model may generate an encoding of the features 406 and utilize a machine learning model to analyze the features to determine where to present the transportation request. For example, the machine learning model may predict one or more performance metrics, outcomes, or outcomes associated with providing the transportation request to the provider device (e.g., interaction probability, transportation price, number of rides, overall transportation price). The multi-device selection system 102 may utilize the predicted performance metrics to present the transportation request to the provider device. For example, the machine learning model may generate a predicted probability of a particular outcome. The multi-device selection system 102 may present the transportation request based on the predicted probability (e.g., the transportation request with the highest probability and / or the transportation request that meets a threshold probability). Thus, as shown in FIG. 4, the multi-device selection system 102 may present multiple transportation requests 408b (e.g., three different transportation requests) to a provider device 410b while presenting another multiple transportation requests 408a (e.g., two different transportation requests) to another provider device 410a.

[0112] As indicated above, in certain embodiments, the multi-device selection system 102 trains or adjusts a machine learning model. In particular, the multi-device selection system 102 uses an iterative training process to adapt the machine learning model to past training data. For example, the multi-device selection system 102 can use the machine learning model to generate predicted results and use a loss function to compare the predicted results to ground truth results. The multi-device selection system 102 can then modify the parameters of the machine learning model based on the loss measure generated from using the loss function. In this manner, the multi-device selection system 102 can train the machine learning model to accurately match transportation requests and provider devices.

[0113] 3, the multi-device selection system 102 may also utilize a reinforcement learning model, such as a Markov decision process, to select transportation requests to present to provider devices. In particular, the multi-device selection system 102 may determine a current state and select transportation requests to present to provider devices that will move to a subsequent state that improves a particular reward.

[0114] In some embodiments, the multi-request transport model 404 is combined with the transport request filter 304. In fact, as described in connection with FIG. 3, the multi-device selection system 102 can utilize similar models to select between the multi-request transport model 308 and the single-request transport model 310. In some embodiments, the multi-device selection system 102 utilizes the combined models to assign transport requests to the multi-request transport model 308 and also to select which provider devices receive a subset of the transport requests. Thus, the descriptions of the features and algorithms discussed in connection with the transport request filter 304 of FIG. 3 can also apply to the multi-request transport model 404.

[0115] As mentioned above, the multi-device selection system 102 can dynamically modify the user interface of a provider device. In particular, in one or more embodiments, the multi-device selection system 102 can update selectable elements associated with a transportation request on a provider device based on various events. For example, in one or more embodiments, the multi-device selection system 102 may update the user interface of a provider device when a transportation request is matched with another provider device (or when a transportation request is canceled). In some embodiments, the multi-device selection system 102 can update the provider device interface when a new and / or more optimal transportation request becomes available. Additionally, in other embodiments, the multi-device selection system 102 can update selectable elements on the user interface based on changes in the location of the provider device and / or the passage of time.

[0116] 3 and 4 repeatedly over time to present and modify transport requests at provider devices. For example, the multi-device selection system 102 may repeatedly analyze transport requests at a particular frequency (e.g., every 4 seconds or every 10 seconds) and assign transport requests to provider devices. In some embodiments, the multi-device selection system 102 includes a threshold display time for transport requests at provider devices (e.g., to avoid confusion due to options changing too quickly). Thus, for example, the multi-device selection system 102 displays transport requests for at least 15 seconds before removing them from the display.

[0117] As discussed above, the multi-device selection system 102 may intelligently present multiple transport requests to provider device interfaces. In particular, the multi-device selection system 102 may present multiple customized transport requests to each provider device interface. Figures 5A-5C illustrate various examples of provider device interfaces displaying selectable elements representing multiple transport requests, according to one or more embodiments.

[0118] 5A , the multi-device selection system 102 displays, on a provider device interface 524, an interactive map 504, selectable elements 508a-508c representing multiple transportation requests, and transportation routes 506a-506b associated with the transportation requests. In one or more embodiments, the selectable element 508a representing the transportation request can include information about the transportation request, such as the transportation route 506a overlaid on the interactive map 504, a transportation price 512a, an estimated arrival time at a pickup location 516a, a travel distance to a pickup location 520a, an estimated arrival time at a drop-off location 518a, a travel distance to a drop-off location 522a, and / or a requester device rating 514a. The multi-device selection system 102 can also display a ride acceptance element 510 for the provider device to accept the transportation request. In some embodiments, the multi-device selection system 102 can display any number and / or combination of multiple request features (e.g., information) associated with the transportation request within the selectable element 508a representing the transportation request.

[0119] 5A , the multi-device selection system 102 receives a selection (e.g., a swipe, tap, double-tap, press, etc.) via the provider device 502. For example, the multi-device selection system 102 may receive an input indicating a horizontal (e.g., from left to right or right to left), vertical (e.g., up and down), or diagonal (e.g., corner to corner) swipe motion on the provider device interface 524. In response to receiving the horizontal swipe motion, the multi-device selection system 102 may further display a second selectable element 508b indicating a second (e.g., different) transportation request. In one or more embodiments, the second selectable element 508b may include information associated with the second transportation request, such as a transportation route 506b overlaid on the interactive map 504, a transportation price 512b, an estimated arrival time at a pickup location 516b, a travel distance to a pickup location 520b, an estimated arrival time at a drop-off location 518b, a travel distance to a drop-off location 522b, and / or a requester device rating 514b. In some embodiments, the provider device 502 may navigate (e.g., swipe) through any number of selectable elements representing transportation requests.

[0120] Additionally, in one or more embodiments, as the provider device 502 navigates (e.g., swipes, taps, double-tap, presses, etc.) through the selectable elements 508a-508c indicating the transportation request, the interactive map 504 can change (e.g., zoom in, zoom out, rotate, display a different geographic area, view angle, etc.) based on the presented transportation route. As indicated above, in some embodiments, if the multi-device selection system 102 receives a selection of the ride-acceptance element 510 and makes a transportation match, the multi-device selection system 102 can send navigation instructions to the provider device to a pickup location.

[0121] As indicated above, FIG. 5B provides an alternative example of a provider device interface 524 displaying selectable elements 526, 528a, 530 representing multiple transportation requests on the interactive map 504. For example, FIG. 5B illustrates an embodiment having selectable elements 526, 528a, and 530 representing three different transportation requests on the interactive map 504. Additionally, FIG. 5B further displays provider device information 532 (e.g., ride streak, online status, and / or challenge standing). In one or more embodiments, the selectable elements can include various characteristics. For example, in some embodiments, the selectable elements can include a requester device rating and / or a travel distance to a desired pickup location.

[0122] As previously mentioned, in one or more embodiments, the multi-device selection system 102 can receive a selection (e.g., a swipe, tap, double-tap, press, etc.) from a provider device 502. As further shown in FIG. 5B , the multi-device selection system 102 can receive a selection (e.g., a tap) of a selectable element 528a indicating a transportation request. In some embodiments, based on the selection (e.g., a tap), the multi-device selection system 102 can present and / or overlay additional information regarding the transportation request on the interactive map 504. In particular, the multi-device selection system 102 can display a transportation route 546, a selectable acceptance element 540, and an information element 528b with information about the transportation request. For example, the multi-device selection system 102 can display a transportation price 534, an estimated arrival time at a pickup location 536, a travel distance to a pickup location 548, an estimated arrival time to a drop-off location 538, a travel distance to a drop-off location 550, a requester device rating 542, and / or an expected tip 544.

[0123] In one or more embodiments, when the multi-device selection system 102 receives input that the provider device 502 has selected a selectable consent element, the multi-device selection system 102 can provide navigation instructions to a pickup location.

[0124] As discussed above, the multi-device selection system 102 can dynamically update selectable elements associated with a transportation request. Figure 5C illustrates the multi-device selection system 102 updating selectable elements 552a-552e on the provider device interface 524, according to one or more embodiments.

[0125] For example, as shown in FIG. 5C , the multi-device selection system 102 can update selectable elements corresponding to transportation requests. To illustrate, the multi-device selection system 102 can maintain, remove, update, and / or replace selectable elements based on changing circumstances. For example, based on a first provider device accepting a transportation request corresponding to selectable element 552a and a requester device withdrawing a transportation request associated with selectable element 552c, the multi-device selection system 102 can remove selectable elements 552a and 552c and replace them with selectable elements 552d and 552e, each corresponding to an additional transportation request. As further shown in FIG. 5C , the multi-device selection system 102 can remove and / or replace selectable elements 552a, 552c-552e while maintaining selectable element 552b. Additionally, the multi-device selection system 102 can maintain, remove, update, and / or replace selectable elements 552a-552e based on any combination of changed circumstances.

[0126] Additionally, in one or more embodiments, the multi-device selection system 102 can update several provider device interfaces based on changes to the transport request (e.g., acceptance, withdrawal, modification). Illustratively, in one or more embodiments, the multi-device selection system 102 presents a selectable element 552a corresponding to the transport request to five provider devices. If one of the five provider devices accepts the transport request, the multi-device selection system 102 can remove the selectable element 552a from the interfaces of four additional provider devices. Furthermore, based on the identified multi-request characteristics, the multi-device selection system 102 can determine to replace the selectable element 552a with one or more additional selectable elements corresponding to the additional transport requests.

[0127] As indicated above, the multi-device selection system 102 can avoid and / or resolve overlapping conditions between multiple provider devices (e.g., two or more provider devices accepting the same transportation request). Figure 6 illustrates the multi-device selection system 102 resolving overlapping conditions between provider devices, according to one or more embodiments.

[0128] 6, the multi-device selection system 102 can utilize the provider selection model 604 and the features 606 to resolve overlapping conditions between two or more provider devices. In particular, in one or more embodiments, if a provider device 610a and an additional provider device 610b select and / or accept the same selectable element 602a corresponding to the transport request, the multi-device selection system 102 can determine which provider devices 610a-610b match the transport request. In one or more embodiments, the multi-device selection system 102 can determine which provider devices 610a-610b match the transport request by identifying the features 606 in the provider selection model 604 and analyzing the features 606.

[0129] As mentioned above, the multi-device selection system 102 can identify characteristics 606 (e.g., characteristics 306, 406 as described above). In one or more embodiments, the provider selection characteristics can include, but are not limited to, provider device rating, match probability, transportation price, estimated arrival time to pickup location, provider device proximity, selection speed, provider device activity, provider device mode, and / or provider device incentive. As previously indicated, the multi-device selection system 102 can identify characteristics associated with provider device selection speed. In particular, in one or more embodiments, the multi-device selection system 102 can identify when the provider device 610a selects and / or accepts a selectable element corresponding to a transportation request. For example, in some embodiments, the multi-device selection system 102 can determine which provider device first accepts the transportation request. Additionally, the multi-device selection system 102 can select provider devices based on the order or speed at which they selected the transportation request.

[0130] As indicated above, the multi-device selection system 102 can identify characteristics 606 associated with provider device activity. For example, in one or more embodiments, the identification of provider device activity can include identification of previous transportation matches, time spent on previous transportation services, online and / or offline status, and / or a period during which the provider device is most active (e.g., a range of times during which the provider device has the most transportation matches). For example, in one or more embodiments, the multi-device selection system 102 can identify whether the provider device 610a is increasing or decreasing its use of the multi-device selection system 102. In particular, in some embodiments, the multi-device selection system 102 can determine whether the provider device 610a is spending more time in a multi-request transportation model and / or a single-request transportation model. The multi-device selection system 102 can also identify and / or determine trends associated with provider device activity. For example, in some embodiments, the multi-device selection system 102 can determine that the provider device 610a consistently spends more time providing transportation services on the transportation matching system at a particular time of day. The multi-device selection system 102 can select a provider device to receive a transportation request to further improve utilization of the multi-device selection system 102 (e.g., based on the provider device being a new user of the multi-request feature or a declining trend in utilization of the multi-request feature).

[0131] As previously mentioned, the multi-device selection system 102 can identify characteristics associated with a provider device mode. For example, in one or more embodiments, the multi-device selection system 102 can determine whether the provider device 610a offers standard transportation service (e.g., providing transportation service for one requester device), shared transportation service (e.g., providing transportation service for requester devices that share transportation service), premium transportation service (e.g., providing transportation service in a luxury vehicle), extra-seat transportation service (e.g., providing transportation service in a larger vehicle), and / or premium extra-seat transportation service (e.g., providing transportation service in a larger luxury vehicle). In some embodiments, the multi-device selection system 102 can determine the provider device mode based on receiving an indication from the provider device 610a. For example, in one or more embodiments, the requester device can notify the multi-device selection system 102 that it only offers premium transportation service. The multi-device selection system 102 can select a provider device based on whether the current transportation mode matches the selected transportation request. In some embodiments, the multi-device selection system 102 selects a provider device with a transportation mode that does not match the characteristics of the transportation request (e.g., to encourage the provider device to provide transportation services beyond its current limited eligibility transportation modes).

[0132] The multi-device selection system 102 can also identify characteristics associated with provider device incentives. For example, in some embodiments, the incentives can include, but are not limited to, priority in the provider selection model 604 (e.g., preference and / or higher likelihood of receiving a high-priced transportation request when overlapping conditions occur), bonuses (e.g., ride streaks, bonus zones, streak zones, etc.), revenue guarantees (e.g., guaranteed revenue for completing a transportation match), and / or prepaid tips (e.g., confirmed tips from requester devices). Furthermore, in one or more embodiments, based on characteristics associated with the provider device, the multi-device selection system 102 can determine when and / or how to incentivize the provider device. For example, in one or more embodiments, if the provider device is not utilizing a multi-request transportation model, the multi-device selection system 102 can guarantee the provider device revenue for transportation requests within the multi-request transportation model. Additionally, the multi-device selection system 102 can select provider devices according to preferences or other incentives selected for the provider device.

[0133] As previously discussed, the multi-device selection system 102 can identify characteristics 606 and utilize the provider selection model 604 to analyze these characteristics when a conflict condition occurs between provider devices. In one or more embodiments, when a conflict condition occurs, the multi-device selection system 102 can utilize various algorithms to determine whether the provider device matches the transport request.

[0134] In some embodiments, the multi-device selection system 102 utilizes heuristic models and / or rule sets to resolve and / or avoid overlapping conditions. For example, in one or more embodiments, the multi-device selection system 102 may make a transportation match 608 based on selection speed. Illustratively, in one or more embodiments, the provider device with the fastest selection speed is matched with the transportation request. In other embodiments, the provider device with the highest provider device rating that accepts the transportation request within a specified time is matched with the transportation request. As another example, in one or more embodiments, the multi-device selection system 102 may resolve overlapping conditions based on the proximity of the provider device to the transportation request. For example, if an overlapping condition occurs, the provider device closest to the pickup location is matched with the transportation request.

[0135] In other embodiments, the multi-device selection system 102 may resolve overlapping conditions by analyzing the identified provider selection characteristics using an optimization method (e.g., a local greedy optimization model or a global optimization model). For example, in one or more embodiments, the provider selection algorithm may analyze provider device ratings, match probabilities, and / or provider device incentives to generate a provider selection price. Based on the provider selection price, the multi-device selection system 102 may match the provider device 610a with the transportation request.

[0136] As another example, in one or more embodiments, the multi-device selection system 102 can utilize a provider selection machine learning model to analyze the identified features. For example, in one or more embodiments, the provider selection machine learning model can analyze shipping price, provider device proximity, and / or provider device mode to determine which provider device should be matched with the shipping request. As previously indicated, the multi-device selection system 102 can train the provider selection machine learning model. In particular, the multi-device selection system 102 utilizes an iterative training process to adapt the provider selection machine learning model by adjusting or adding decision trees or learning parameters that result in efficient resolution of provider device overlap conditions.

[0137] In one or more embodiments, when an overlap condition occurs, the provider selection algorithm and / or provider selection machine learning model can analyze any number and / or combination of features 606 to determine which provider devices 610a-610b match the transportation request.

[0138] 1-6, corresponding text, and examples provide several different methods, systems, devices, and non-transitory computer-readable media for multi-device selection system 102. In addition to the foregoing, one or more embodiments can also be described in terms of a flowchart that includes acts for achieving a particular result, such as that shown in FIG. 7. FIG. 7 may be performed with more or fewer acts. Furthermore, the acts may be performed in a different order. Also, acts described herein may be repeated or performed in parallel with each other or with different instances of the same or similar acts.

[0139] As shown in FIG. 7, a series of acts 700 includes acts 702-710, or receiving a set of transportation requests; selecting a plurality of transportation requests; providing an interactive digital map and selectable elements showing the plurality of transportation requests; and transmitting navigation instructions to a provider device.

[0140] For example, in one or more embodiments, acts 702-710 include, in a transportation matching system, receiving a set of transportation requests from a requester device 702; selecting and providing a plurality of transportation requests from the set of transportation requests to the provider computing device 706 by comparing transportation routes for the set of transportation requests with the location of the provider computing device 706; providing an interactive digital map and selectable elements representing the plurality of transportation requests 708 for display on the provider computing device; and, in response to receiving a selection of a selectable element among the selectable elements, sending navigation instructions to the provider computing device to a pickup location for the transportation request corresponding to the selectable element 710.

[0141] For example, in some embodiments, the series of acts 700 further includes selecting a set of provider computing devices to receive the transport request, where the set of provider computing devices includes the provider computing device and an additional provider computing device.

[0142] Further, in some embodiments, the sequence of actions 700 further includes providing a selectable element indicating the transportation request for display via a provider computing device; and providing an additional selectable element indicating the transportation request for display via an additional provider computing device.

[0143] In some embodiments, the series of acts 700 further includes providing the additional selectable element representing the transportation request for display via an additional provider computing device along with an additional interactive digital map and additional selectable elements representing additional transportation requests.

[0144] Further, in one or more embodiments, the series of acts 700 further includes determining a matching probability for the provider computing devices; and selecting, based on the matching probability, multiple provider devices in the set of provider computing devices to receive the transportation request.

[0145] Additionally, in some embodiments, the series of acts 700 further includes, in response to receiving a selection of the selectable element via the provider computing device, removing an additional selectable element indicating a transportation request from the additional provider computing device.

[0146] For example, in some embodiments, the series of actions 700 further includes selecting between a multi-request transportation model and a single-request transportation model based on elapsed times corresponding to the transportation requests; and selecting multiple transportation requests to provide to the provider computing device using the multi-request transportation model.

[0147] In some embodiments, the series of actions 700 further includes providing a selectable element for display on the provider computing device by providing a plurality of pickup location indicators and a plurality of shipping prices corresponding to the plurality of shipping requests.

[0148] In another embodiment, the series of actions 700 further includes providing a first route corresponding to a first transport request of the plurality of transport requests for display via the interactive digital map; and, in response to selection of the selectable element, providing a second transport route corresponding to the transport request for display via the interactive digital map.

[0149] Embodiments of the present disclosure may include or utilize special-purpose or general-purpose computers including computer hardware, such as, for example, one or more processors and system memory, as discussed in more detail below. Embodiments within the scope of the present disclosure also include physical and other computer-readable media for holding or storing computer-executable instructions and / or data structures. In particular, one or more of the processes described herein may be implemented at least in part as instructions embodied in a non-transitory computer-readable medium and executable by one or more computing devices (e.g., any of the media content access devices described herein). Generally, a processor (e.g., a microprocessor) receives instructions from a non-transitory computer-readable medium (e.g., a memory) and executes these instructions, thereby performing one or more processes, including one or more of the processes described herein.

[0150] Computer-readable media may be any available media that can be accessed by a general-purpose or special-purpose computer system. Computer-readable media that store computer-executable instructions are non-transitory computer-readable storage media (devices). Computer-readable media that carry computer-executable instructions are transmission media. Thus, by way of example, and not limitation, embodiments of the present disclosure can include at least two distinctly different kinds of computer-readable media: non-transitory computer-readable storage media (devices) and transmission media.

[0151] Non-transitory computer-readable storage media (devices) include RAM, ROM, EEPROM, CD-ROM, solid-state drives ("SSD") (e.g., RAM-based), flash memory, phase-change memory ("PCM"), other types of memory, other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code means in the form of computer-executable instructions or data structures and that can be accessed by a general-purpose or special-purpose computer.

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

[0153] Furthermore, upon reaching various computer system components, program code means in the form of computer-executable instructions or data structures may be automatically transferred from transmission media to non-transitory computer-readable storage media (devices) (or vice versa). For example, computer-executable instructions or data structures received over a network or data link may be buffered in RAM within a network interface generator (e.g., a "NIC") and then eventually transferred to computer system RAM and / or less volatile computer storage media (devices) within the computer system. Thus, it should be understood that non-transitory computer-readable storage media (devices) may be included in computer system components that also (or even primarily) utilize transmission media.

[0154] Computer-executable instructions include, for example, instructions and data that, when executed on a processor, cause a general-purpose computer, a special-purpose computer, or a special-purpose processing device to perform a particular function or group of functions. In one or more embodiments, computer-executable instructions are executed on a general-purpose computer to transform the general-purpose computer into a special-purpose computer that implements elements of the present disclosure. Computer-executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code. Although the subject matter has been described in terms specific to structural features and / or methodological acts, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the above-described features or acts. Rather, the described features and acts are disclosed as example forms of implementing the claims.

[0155] Those skilled in the art will appreciate that the disclosure may be practiced in networked computing environments having many types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, tablets, pagers, routers, switches, and the like. The disclosure may also be practiced in distributed system environments where tasks are performed by both local and remote computer systems that are linked through a network (by hardwired data links, wireless data links, or a combination of hardwired and wireless data links). In a distributed system environment, program generators may be located in both local and remote memory storage devices.

[0156] Embodiments of the present disclosure may also be implemented in a cloud computing environment. As used herein, "cloud computing" is defined as a subscription model for enabling on-demand network access to a shared pool of configurable computing resources. For example, cloud computing can be adopted in the market to offer ubiquitous, convenient, on-demand access to a shared pool of configurable computing resources that can be rapidly provisioned through virtualization, released with little management effort or service provider interaction, and then scaled accordingly.

[0157] Cloud computing subscription models can consist of various characteristics, such as, for example, on-demand self-service, extensive network access, resource pooling, fast elasticity, metered service, etc. Cloud computing subscription models can also expose various service subscription models, such as, for example, Software as a Service ("SaaS"), Web Services, Platform as a Service ("PaaS"), and Infrastructure as a Service ("IaaS"). Cloud computing subscription models can also be deployed using different deployment subscription models, such as private cloud, community cloud, public cloud, hybrid cloud, etc. As used herein and in the claims, a "cloud computing environment" is an environment in which cloud computing is employed.

[0158] 8 shows a block diagram of an exemplary computing device 800 that may be configured to perform one or more of the processes described above. It is understood that one or more computing devices, such as computing device 800, may represent the computing devices described above (e.g., server 106, provider devices 108a-108b, or requester devices 110a-110n). In one or more embodiments, computing device 800 may be a mobile device (e.g., a mobile phone, a smartphone, a PDA, a tablet, a laptop, a camera, a tracker, a watch, a wearable device, etc.). In some embodiments, computing device 800 may be a non-mobile device (e.g., a desktop computer or another type of client device). Additionally, computing device 800 may be a server device with cloud-based processing and storage capabilities.

[0159] As shown in FIG. 8, computing device 800 may include one or more processors 802, memory 804, storage device 806, input / output interface 808 (or "I / O interface 808"), and communication interface 810, which may be communicatively coupled by a communication infrastructure (e.g., bus 812). Although computing device 800 is shown in FIG. 8, the components shown in FIG. 8 are not intended to be limiting. Additional or alternative components may be used in other embodiments. Moreover, in certain embodiments, computing device 800 includes fewer components than those shown in FIG. 8. The components of computing device 800 shown in FIG. 8 are now described in further detail.

[0160] In particular embodiments, processor 802 includes hardware for executing instructions, such as those making up a computer program. By way of example, and not limitation, to execute instructions, processor 802 may retrieve (or fetch) instructions from an internal register, an internal cache, memory 804, or storage device 806, decode them, and execute them.

[0161] The computing device 800 includes a memory 804 coupled to the processor 802. The memory 804 may be used to store data, metadata, and programs for execution by the processor. The memory 804 may include one or more of volatile and non-volatile memory, such as random access memory (“RAM”), read-only memory (“ROM”), solid-state disk (“SSD”), flash, phase-change memory (“PCM”), or other types of data storage. The memory 804 may be internal or distributed memory.

[0162] Computing device 800 includes a storage device 806 for storing data or instructions. By way of example, and not limitation, storage device 806 may include the non-transitory storage media described above. Storage device 806 may include a hard disk drive ("HDD"), flash memory, a universal serial bus ("USB") drive, or a combination of these or other storage devices.

[0163] As shown, computing device 800 includes one or more I / O interfaces 808 that are provided to enable a user to provide input (such as user strokes), receive output from, and otherwise transfer data to / from computing device 800. These I / O interfaces 808 may include a mouse, a keypad or keyboard, a touchscreen, a camera, an optical scanner, a network interface, a modem, other known I / O devices, or a combination of such I / O interfaces 808. A touchscreen may be activated with a stylus or a finger.

[0164] I / O interface 808 may include one or more devices for presenting output to a user, including, but not limited to, a graphics engine, a display (e.g., a display screen), one or more output drivers (e.g., a display driver), one or more audio speakers, and one or more audio drivers. In particular embodiments, I / O interface 808 is configured to provide graphical data to a display for presentation to a user. The graphical data may represent one or more graphical user interfaces and / or any other graphical content that may be useful in a particular implementation.

[0165] Computing device 800 may further include a communication interface 810. The communication interface 810 may include hardware, software, or both. The communication interface 810 provides one or more interfaces for communication (e.g., packet-based communication, etc.) between the computing device and one or more other computing devices or one or more networks. By way of example, and not limitation, the communication interface 810 may include a network interface controller (“NIC”) or network adapter for communicating with an Ethernet or other wired-based network, or a wireless NIC (“WNIC”) or wireless adapter for communicating with a wireless network, such as WI-FI. Computing device 800 may further include a bus 812. The bus 812 may include hardware, software, or both that couple the components of computing device 800 to one another.

[0166] Each of the components of the multi-device selection system 102 may include software, hardware, or both. For example, a component may include one or more instructions stored on a computer-readable storage medium and executable by a processor of one or more computing devices, such as a client device or a server device. When executed by one or more processors, the computer-executable instructions of the multi-device selection system 102 cause the computing devices to perform the methods described herein. Alternatively, a component may include hardware, such as a special-purpose processing device, for performing a particular function or group of functions. Alternatively, a component of the multi-device selection system 102 may include a combination of computer-executable instructions and hardware.

[0167] Additionally, the components of the multi-device selection system 102 may be implemented, for example, as one or more operating systems, one or more standalone applications, one or more modules of an application, one or more plug-ins, one or more library functions or functions that can be called from other applications, and / or as a cloud computing model. Thus, the components may be implemented as standalone applications, such as desktop or mobile applications. Additionally, the components may be implemented as one or more web-based applications hosted on a remote server. The components may also be implemented as a suite of mobile device applications or "apps."

[0168] FIG. 9 illustrates an exemplary network environment 900 of a transportation matching system (e.g., transportation matching system 104). Network environment 900 includes a client device 906, a transportation matching system 104, and a vehicle subsystem 908, connected to each other by a network 904. While FIG. 9 illustrates a particular configuration of client device 906, transportation matching system 104, vehicle subsystem 908, and network 904, this disclosure contemplates any suitable configuration of client device 906, transportation matching system 104, vehicle subsystem 908, and network 904. By way of example, and without limitation, two or more of client device 906, transportation matching system 104, and vehicle subsystem 908 communicate directly, bypassing network 904. As another example, two or more of client device 906, transportation matching system 104, and vehicle subsystem 908 may be physically or logically co-located, in whole or in part, with one another. 9 depicts a particular number of client devices 906, transportation matching systems 104, vehicle subsystems 908, and networks 904, this disclosure contemplates any suitable number of client devices 906, transportation matching systems 104, vehicle subsystems 908, and networks 904. By way of example, and not limitation, network environment 900 may include multiple client devices 906, transportation matching systems 104, multiple vehicle subsystems 908, and multiple networks 904.

[0169] This disclosure contemplates any suitable network 904. By way of example, and not limitation, one or more portions of network 904 may include an ad-hoc network, an intranet, an extranet, a virtual private network ("VPN"), a local area network ("LAN"), a wireless LAN ("WLAN"), a wide area network ("WAN"), a wireless WAN ("WWAN"), a metropolitan area network ("MAN"), a portion of the Internet, a portion of the public switched telephone network ("PSTN"), a cellular telephone network, or a combination of two or more thereof. Network 904 may include one or more networks 904.

[0170] Links may connect client devices 906, transportation matching system 104, and vehicle subsystems 908 to network 904 or to each other. This disclosure contemplates any suitable links. In particular embodiments, one or more links include one or more wired (e.g., Digital Subscriber Line (“DSL”) or Data Over Cable Service Interface Specification (“DOCSIS”), wireless (e.g., Wi-Fi or Worldwide Interoperability for Microwave Access (“WiMAX”)), or optical (e.g., Synchronous Optical Network (“SONET”) or Synchronous Digital Hierarchy (“SDH”)) links. In particular embodiments, one or more links may each include an ad hoc network, an intranet, an extranet, a VPN, a LAN, a WLAN, a WAN, a WWAN, a MAN, a portion of the Internet, a portion of the PSTN, a network based on cellular technology, a network based on satellite communication technology, another link, or a combination of two or more such links. Links need not necessarily be the same throughout network environment 900. One or more first links may differ in one or more respects from one or more second links.

[0171] In particular embodiments, client device 906 may be an electronic device capable of performing appropriate functions implemented or supported by client device 906, including hardware, software, or embedded logic components, or a combination of two or more of such components. By way of example, and without limitation, client device 906 may include any of the computing devices discussed above in connection with FIG. 8. Client device 906 may enable a network user at client device 906 to access a network. Client device 906 may enable that user to communicate with other users at other client devices 906.

[0172] In particular embodiments, client device 906 may include a transportation service application or a web browser such as MICROSOFT INTERNET EXPLORER, GOOGLE CHROME, or MOZILLA FIREFOX, and may include one or more add-ons, plug-ins, or other extensions, such as TOOLBAR or YAHOO TOOLBAR. A user at client device 906 may enter a uniform resource locator ("URL") or other address to point the web browser to a particular server (such as server 106), and the web browser may generate a HyperText Transfer Protocol ("HTTP") request and communicate the HTTP request to the server. The server may accept the HTTP request and, in response to the HTTP request, communicate one or more HyperText Markup Language ("HTML") files to client device 906. Client device 906 may render a web page based on the HTML files from the server for presentation to the user. This disclosure contemplates any suitable web page file. By way of example, and not limitation, a web page may be rendered from an HTML file, an Extensible HyperText Markup Language ("XHTML") file, or an Extensible Markup Language ("XML") file, depending on particular needs. Such pages may execute scripts, such as those written in markup language and script combinations such as, for example, but not limited to, JAVASCRIPT, JAVA, MICROSOFT SILVERLIGHT, AJAX (Asynchronous JAVASCRIPT and XML), and the like. References herein to a web page are intended to encompass, where appropriate, one or more corresponding web page files (that may be used by a browser to render the web page), and vice versa.

[0173] In particular embodiments, the transportation matching system 104 may be a network-addressable computing system capable of hosting a rideshare transportation network. The transportation matching system 104 may generate, store, receive, and transmit data related to the rideshare transportation network, such as user profile data, concept profile data, text data, ride request data, GPS location data, provider data, requester data, vehicle data, or other suitable data. This may include authenticating the identity of providers and / or vehicles authorized to provide ride services through the transportation matching system 104. Additionally, the transportation service system may manage the identity of service requesters, such as users / requesters. In particular, the transportation service system may maintain requester data, such as driving / ride history, personal data, or other user data, in addition to navigation and / or traffic management services or other location services (e.g., GPS services).

[0174] In particular embodiments, the transportation matching system 104 may manage a ride matching service to connect users / requesters with vehicles and / or providers. By managing the ride matching service, the transportation matching system 104 can manage the distribution and allocation of vehicle subsystem resources and user resources, such as GPS locations and availability indicators, as described herein.

[0175] The transportation matching system 104 may be accessed by other components of the network environment 900 either directly or via the network 904. In particular embodiments, the transportation matching system 104 may comprise one or more servers. Each server may be a unitary server or a distributed server spanning multiple computers or multiple data centers. The servers may be of various types, such as, but not limited to, a web server, a news server, a mail server, a message server, an advertisement server, a file server, an application server, an exchange server, a database server, a proxy server, another server suitable for performing the functions or processes described herein, or any combination thereof. In particular embodiments, each server may include hardware, software, or embedded logic components, or a combination of two or more such components, to perform the appropriate functions implemented or supported by the server. In particular embodiments, the transportation matching system 104 may include one or more data stores. A data store may be used to store various types of information. In particular embodiments, the information stored in a data store may be organized according to a particular data structure. In particular embodiments, each data store may be a relational, columnar, correlation, or other suitable database. While this disclosure describes or illustrates particular types of databases, this disclosure contemplates any suitable type of database. Particular embodiments may provide an interface that allows a client device 906 or transportation matching system 104 to manage, retrieve, modify, add, or delete information stored in the data storage.

[0176] In particular embodiments, transportation matching system 104 may provide users with the ability to perform actions on various types of items or objects supported by transportation matching system 104. By way of example, and without limitation, these items and objects may include rideshare networks to which a user of transportation matching system 104 may belong, vehicles that a user may request, location designators, computer-based applications that a user may use, transactions that allow a user to buy or sell items via a service, interactions with advertisements that a user may perform, or other suitable items or objects. A user may interact with anything that can be represented in transportation matching system 104 or by an external system, either in transportation matching system 104 or a third-party system that is separate from transportation matching system 104 and coupled to transportation matching system 104 via network 904.

[0177] In certain embodiments, the transportation matching system 104 may be capable of linking various entities. By way of example, and not limitation, the transportation matching system 104 may allow users to interact with each other or other entities, or may allow users to interact with these entities through an application programming interface (“API”) or other communication channel.

[0178] In particular embodiments, the transportation matching system 104 may include various servers, subsystems, programs, modules, logs, and data stores. In particular embodiments, the transportation matching system 104 may include one or more of the following: a web server, an action logger, an API request server, a relevance and ranking engine, a content object classifier, a notification controller, an action log, a third-party content object exposure log, an inference module, an authorization / privacy server, a search module, an ad targeting module, a user interface module, a user profile store, a connectivity store, a third-party content store, or a location store. The transportation matching system 104 may also include suitable components such as network interfaces, security mechanisms, load balancers, failover servers, an administration and network operations console, other suitable components, or any suitable combination thereof. In particular embodiments, the transportation matching system 104 may include one or more user profile stores for storing user profiles. A user profile may include, for example, biographical information, demographic information, behavioral information, social information, or other types of descriptive information, such as work history, educational history, hobbies or preferences, interests, affinities, or location.

[0179] The web server may include a mail server or other messaging functionality for receiving and routing messages between the transportation matching system 104 and one or more client devices 906. An action logger may be used to receive communications from the web server regarding user actions on or outside of the transportation matching system 104. In conjunction with the action log, a third-party content object log of user exposure to third-party content objects may be maintained. A notification controller may provide information about content objects to the client device 906. The information may be pushed to the client device 906 as a notification, or the information may be pulled from the client device 906 in response to a request received from the client device 906. An authorization server may be used to enforce one or more privacy settings of a user of the transportation matching system 104. A user's privacy settings determine how certain information associated with the user can be shared. The authorization server may allow a user to opt in or out of having their actions logged by the transportation matching system 104 or shared with other systems, for example, by setting appropriate privacy settings. The third-party content object store may be used to store content objects received from third parties. The location store may be used to store location information received from a client device 906 associated with a user.

[0180] Additionally, vehicle subsystem 908 can include a human-operated vehicle or an autonomous vehicle. A provider of a human-operated vehicle can perform a maneuver to pick up, transport, and drop off one or more requesters in accordance with embodiments described herein. In certain embodiments, vehicle subsystem 908 can include an autonomous vehicle, e.g., a vehicle that does not require human operation. In these embodiments, vehicle subsystem 908 can perform, communicate, and otherwise function without the assistance of a human provider in accordance with available technology.

[0181] In certain embodiments, vehicle subsystem 908 may include one or more sensors embedded within or associated with it. For example, sensors may be mounted on top of vehicle subsystem 908 or may be located inside vehicle subsystem 908. In certain embodiments, sensors may be located in multiple areas at once, i.e., divided throughout vehicle subsystem 908, allowing different components of the sensor to be installed in different locations according to their optimal operation. In these embodiments, the sensors may include a LIDAR sensor and an inertial measurement unit (“IMU”) including one or more accelerometers, one or more gyroscopes, and one or more magnetometers. This sensor suite may additionally or alternatively include a wireless IMU (“WIMU”), one or more cameras, one or more microphones, or other sensors or data input devices capable of receiving and / or recording information regarding navigating a route for picking up, transporting, and / or dropping off a requester.

[0182] In particular embodiments, vehicle subsystem 908 may include a communication device capable of communicating with client device 906 and / or transportation matching system 104. For example, vehicle subsystem 908 may include an on-board computing device communicatively linked to network 904 for sending and receiving data such as GPS location information, sensor-related information, requester location information, or other related information.

[0183] In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. Various embodiments and aspects of the invention will be described with reference to the details discussed herein, and the accompanying drawings illustrate these various embodiments. The above description and drawings are illustrative of the invention and should not be construed as limiting the invention. Numerous specific details have been set forth to provide a thorough understanding of various embodiments of the invention. The invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are in all respects merely illustrative and should not be considered as limiting. For example, methods described herein may be performed with fewer or more steps / acts, or the steps / acts may be performed in a different order. Furthermore, steps / acts described herein may be repeated or performed in parallel with each other or with different instances of the same or similar steps / acts. The scope of the invention is therefore indicated by the appended claims, rather than by the foregoing description. All changes that come within the meaning and range of equivalents of the claims are intended to be embraced within their scope.

Claims

1. receiving, at a transportation matching system, a set of transportation requests from a requester device; selecting between a multi-request transportation model and a single-request transportation model based on elapsed times corresponding to the set of transportation requests; selecting a plurality of transportation requests to provide to the provider computing device from the set of transportation requests by utilizing the multi-request transportation model and comparing transportation routes for the set of transportation requests with the location of a provider computing device; providing an interactive digital map and selectable elements representing the plurality of transportation requests for display on the provider computing device; and In response to receiving a selection of a selectable element of the selectable elements, transmitting navigation instructions to the provider computing device to a pickup location of a transportation request corresponding to the selectable element. A method for providing the above.

2. selecting, for the transportation request, a set of provider computing devices to receive the transportation request, the set of provider computing devices including the provider computing device and an additional provider computing device. The method of claim 1 further comprising:

3. providing the selectable element indicative of the transportation request for display via the provider computing device; and providing an additional selectable element indicative of the transportation request for display via the additional provider computing device. The method of claim 2 further comprising:

4. providing, via the additional provider computing device, an additional interactive digital map and additional selectable elements indicative of an additional plurality of transportation requests for displaying the additional selectable elements indicative of the transportation requests. The method of claim 3 further comprising:

5. determining a matching probability for the provider computing device; and selecting a number of provider devices in the set of provider computing devices to receive the transportation request based on the matching probability; The method of claim 3 further comprising:

6. removing the additional selectable element indicative of the transportation request from the additional provider computing device in response to receiving the selection of the selectable element via the provider computing device. The method of claim 4 further comprising:

7. selecting, for the transport request, between a multi-request transport model and a single-request transport model based on an elapsed time corresponding to the transport request; and selecting the plurality of transportation requests to provide to the provider computing device utilizing the multi-request transportation model; The method of claim 1 further comprising:

8. The method of claim 1 , wherein providing the selectable elements for display on the provider computing device comprises providing a plurality of pickup location indicators and a plurality of shipping prices corresponding to the plurality of shipping requests.

9. providing a first route corresponding to a first transportation request of the plurality of transportation requests for display via the interactive digital map; and providing, in response to selection of the selectable element, for display via the interactive digital map, a second transportation route corresponding to the first transportation request. The method of claim 1 further comprising:

10. A computer system comprising: In a transportation matching system, receiving a set of transportation requests from a requester device; selecting between a multi-request transportation model and a single-request transportation model based on elapsed times corresponding to the set of transportation requests; utilizing the multi-request transportation model to select a plurality of transportation requests from the set of transportation requests to provide to the provider computing device by comparing transportation routes for the set of transportation requests with the location of a provider computing device; providing an interactive digital map and selectable elements representing the plurality of transportation requests for display on the provider computing device; in response to receiving a selection of a selectable element of the selectable elements, transmitting to the provider computing device navigation instructions to a pickup location of a transportation request corresponding to the selectable element; A computer program for executing

11. The computer system, selecting a set of provider computing devices to receive the transportation request, the set of provider computing devices including the provider computing device and an additional provider computing device; The computer program of claim 10 , further comprising:

12. The computer system, providing the selectable element representing the transportation request for display via the provider computing device; providing an additional selectable element indicative of the transportation request for display via the additional provider computing device; The computer program of claim 11 , further comprising:

13. The computer system, providing the additional selectable elements representing the transportation requests for display via the additional provider computing device along with an additional interactive digital map and additional selectable elements representing the transportation requests. The computer program of claim 12 , further comprising:

14. The computer system, determining a matching probability for the provider computing device; selecting a number of provider devices in the set of provider computing devices to receive the transportation request based on the matching probability; The computer program of claim 12 , further comprising:

15. The computer system, selecting between a multi-request transportation model and a single-request transportation model based on elapsed times corresponding to the transportation requests; utilizing the multi-request transportation model to select the plurality of transportation requests to provide to the provider computing device; The computer program of claim 10 , further comprising:

16. 1. A system comprising: at least one processor; and At least one non-transitory computer-readable storage medium that, when executed by the at least one processor, provides the system with: receiving, in a transportation matching system, a set of transportation requests from a requester device; selecting between a multi-request transportation model and a single-request transportation model based on elapsed times corresponding to the set of transportation requests; selecting a plurality of transportation requests to provide to the provider computing device from the set of transportation requests by utilizing the multi-request transportation model and comparing transportation routes for the set of transportation requests with the location of the provider computing device; providing an interactive digital map and selectable elements indicative of the plurality of transportation requests for display on the provider computing device; In response to receiving a selection of a selectable element of the selectable elements, transmitting navigation instructions to the provider computing device to a pickup location of a transportation request corresponding to the selectable element. At least one non-transitory computer-readable storage medium having instructions stored thereon A system comprising:

17. When executed by the at least one processor, the system: selecting a set of provider computing devices to receive the transportation request, the set of provider computing devices including the provider computing device and an additional provider computing device; The system of claim 16 further comprising instructions.

18. When executed by the at least one processor, the system: providing the selectable element indicative of the transportation request for display via the provider computing device; providing an additional selectable element indicative of the transportation request for display via the additional provider computing device. The system of claim 17 further comprising instructions.

19. When executed by the at least one processor, the system: providing, via the additional provider computing device, an additional selectable element indicative of the transportation requests for display along with an additional interactive digital map and additional selectable elements indicative of the transportation requests; 20. The system of claim 18, further comprising instructions.

20. When executed by the at least one processor, the system: determining a matching probability for the provider computing device; Selecting a number of provider devices in the set of provider computing devices to receive the transportation request based on the matching probability.

20. The system of claim 18, further comprising instructions.

Images