Method and system for determining a requesting driver

Abstract

The present disclosure provides methods and systems for determining a requested driver. In some examples, a method is provided that includes determining, by a processor, a second location proximate to a first location based on a search starting from a road closest to the first location, the first location indicated in a request for a driver, and determining, by the processor, the requested driver based on whether the driver is en route to the second location.

Description

Technical Field

[0001] This disclosure relates broadly, but not exclusively, to methods and systems for identifying a requesting driver. Background Technology

[0002] Ride-hailing and delivery platforms often face the challenge of finding suitable drivers to handle driver requests. For example, the process of assigning orders to drivers within a region typically involves two steps: first, filtering and selecting from a limited pool of driver candidates within the region; and second, using Vehicle Routing Problem (VRP) algorithms to identify the optimal driver, based on constraints such as the estimated time of arrival (ETA) to a location.

[0003] Currently, the standard candidate selection method is static and typically involves capturing a static snapshot of the driver's state at a specific moment, then applying a radius-based filter to identify drivers close to the order or pick-up location indicated in the driver's request. Various vehicle types and business constraints are then considered, all based on this static snapshot. This implementation supports in-trip batching, such as assigning requests to drivers already in a trip, allowing drivers who may be in a trip for a delivery or ride request to be selected as potential candidates for handling another request.

[0004] However, this traditional static candidate selection method has two main drawbacks. First, it is typically limited by the number of driver candidates because static snapshots cannot capture any potential drivers located outside the static snapshot coverage area. This significantly reduces the efficiency of in-trip batching. Second, it includes many inefficient drivers who may simply be passing through, but whose subsequent pick-up locations are far from the location indicated in the driver's request, resulting in increased workload for drivers who might be selected to process the request but with no output. Third, this can also affect the efficiency of in-trip batching, as more requests may be canceled or rejected by the selected drivers. Furthermore, the static snapshot method is complex and resource-intensive in execution because it needs to consider many configurations and factors, such as varying vehicle types, environmental factors such as traffic or weather, and other similar factors, to manage the static snapshot size.

[0005] Therefore, there is a need to provide methods and systems for overcoming or at least minimizing the challenges mentioned above. Summary of the Invention

[0006] According to a first aspect of this disclosure, a method for determining a requesting driver is provided, comprising: determining, by a processor, a second location adjacent to the first location based on a search starting from the road closest to the first location, the first location being indicated in the request to the driver; and determining, by the processor, the requesting driver based on whether the driver is en route to the second location.

[0007] According to a second aspect of this disclosure, a system for determining a requesting driver is provided, comprising: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code being configured, together with the at least one processor, to cause the system to at least: determine a second location adjacent to the first location based on a search starting from the road closest to the first location, the first location being indicated in the request to the driver; and determine the requesting driver based on whether the driver is en route to the second location. Attached Figure Description

[0008] The embodiments and implementations are provided by way of example only, and those skilled in the art will better understand and readily grasp the embodiments and implementations from the following written description, which is read in conjunction with the accompanying drawings, in which: Figure 1 A system for determining a requesting driver is shown according to various embodiments of the present disclosure.

[0009] Figure 2 This is a schematic diagram of a server determined according to various embodiments of the present disclosure.

[0010] Figure 3 Exemplary illustrations depict various embodiments of the present disclosure for determining a requesting driver.

[0011] Figure 4A Exemplary illustrations depicting edge-based road graphs according to various embodiments of the present disclosure are provided.

[0012] Figure 4B Exemplary illustrations depict inverted indexes according to various embodiments of the present disclosure.

[0013] Figure 4C Exemplary illustrations depict various embodiments of location-based services (LBS) according to this disclosure.

[0014] Figure 4D Exemplary flowcharts for determining a requesting driver according to various embodiments of the present disclosure are depicted.

[0015] Figure 5 An exemplary flowchart for determining the requesting driver is shown according to various embodiments.

[0016] Figure 6 It can be practiced on it. Figure 2 A schematic block diagram of a general computer system for determining the server.

[0017] Figure 7 It can be practiced on it. Figure 1 A schematic block diagram of a general-purpose computer system that combines transaction processing and server determination.

[0018] Figure 8 The following diagram illustrates the implementation. Figure 1 An example of a computing device for a transaction processing server is shown.

[0019] Figure 9 The following diagram illustrates the implementation. Figure 1 An example of a computing device for determining a server is shown.

[0020] Figure 10 The following diagram illustrates the implementation. Figure 1 The example shown is a combination of transaction processing and determination server computing device.

[0021] Those skilled in the art will understand that the elements in the accompanying drawings are illustrated for simplicity and clarity and are not necessarily depicted to scale. For example, the dimensions of some elements in the illustrations, block diagrams, or flowcharts may be exaggerated relative to other elements to aid in understanding embodiments of the invention. Detailed Implementation

[0022] Terminology Explanation

[0023] A platform refers to a set of technologies that serve as the basis for facilitating exchange between two or more interdependent servers, entities, and / or devices (e.g., an exchange between a requester device (associated with a requester of a product or service) and a provider device (associated with a provider of a product or service)). For example, a platform may provide a requester with services offered by a provider, such as rides, delivery, online shopping, insurance, and other similar services. A requester may typically access the platform via a requester device through a website, application, or other similar method. A provider device may be associated with a provider that can provide rides or delivery requested by the requester. For example, a request from a requester device may be a request for a driver to provide rides, delivery services, or other services (such as cleaning, repair, plumbing, refurbishment, emergency medical services, and other similar services). In this disclosure, requester devices and provider devices may be referred to herein as user devices, wherein a user associated with a user device may be either a requester or a provider.

[0024] Locations can be business outlets or stores, points of interest (POIs), landmarks, pick-up points, delivery points, or other similar locations where a driver can be requested to pick up or drop off passengers, deliver goods, or perform other similar services. Based on a first location indicated in the request (e.g., including location information such as identifiers, addresses, Global Positioning System (GPS) information, latitude and longitude coordinates, geohash information, or other similar information associated with the first location), a location-based service (LBS) can perform a search to determine a second location adjacent to the first location. LBS can be any service that performs a search based on location information associated with the user (e.g., based on the requester's or provider's real-time location, GPS information, latitude and longitude coordinates, geohash information, or other similar information) (e.g., for delivery, ride-hailing, and other similar services). In one implementation, the second location can be located within a specified distance from the first location. In another implementation, the second location can be located within a distance from the first location such that the time required for a driver to travel from the second location to the first location is less than a specified amount of time. In one implementation, the distance and / or time may be determined based on the request type (e.g., whether it is a delivery request, a ride request, or a request for other similar services), weather conditions (e.g., the distance and / or time may be adjusted based on whether it is raining), traffic conditions (e.g., the distance and / or time may be adjusted based on traffic intensity around the first and second locations), the area type around the first and / or second locations (e.g., whether it is an urban or rural area, or based on building density around the area, or other similar factors), or other similar factors. For example, the first and second locations may each be represented as nodes in an edge-based road graph, where each edge in the edge-based road graph represents a road and conveys information about the route taken by a driver traveling or about to travel along the road represented by that edge. The node representing the second location may be a node adjacent to the node representing the first location. For example, the node representing the second location may be located within a range of one to a maximum number of edges from the node representing the first location. In one implementation, the maximum number of edges can be determined based on the request type (e.g., whether it is a delivery request, a ride request, or a request for other similar services), weather conditions (e.g., the maximum number of edges can be adjusted based on whether it is raining), traffic conditions (e.g., the maximum number of edges can be adjusted based on the traffic intensity around the first and second locations), the area type around the first and / or second locations (e.g., whether it is an urban area or a rural area, or based on the building density around the area, or other similar factors) or other similar factors.

[0025] A road refers to a section of surface constructed for the movement of entities (such as people, vehicles, or other similar entities), for example, for reaching a location such as a first location or a second location. For example, an edge branching from a first location represents the road closest to the first location and can be used to reach the first location. In one implementation, the road closest to the first location can be a road leading to the first location, a road extending alongside the first location, a road used to reach the first location, or another similar road. The search performed to determine the second location can be a search that starts with the road closest to the first location. For example, in an edge-based road graph, the search can be a breadth-first search (BFS) centered on the node representing the first location and starting with an edge branching from the node representing the first location (e.g., an edge representing the road closest to the first location). The search can end at an edge or node based on a threshold (e.g., the search can be configured to end after traversing a maximum number of nodes and / or edges, or after traversing a maximum distance from the first location, or other similar configurations). It should be understood that in an edge-based road graph, there can be multiple nodes (each node representing a different location) and multiple edges (each edge representing a different road). Furthermore, it should be understood that other representations of roads and locations besides edge-based road graphs are also possible (e.g., neural networks or other similar structures).

[0026] Based on this search, the driver who will process the request can be determined based on whether the driver is en route to the second location. For example, each edge of an edge-based road graph can be mapped to information related to the route of a driver who is currently or will be traveling along the road represented by that edge. This information may include: the next step the driver associated with the route will take, the driver's identifier associated with the route, the driver's attributes (e.g., distance to the first location, distance to the second location, estimated time to reach the second location, driver's state, driver preferences, or other similar attributes), the type of vehicle the driver uses for the route, and other similar information related to the route. This information can be stored in a database.

[0027] The mapping of each edge in an edge-based road graph to information related to a driver's route can be implemented, for example, using an inverted index or other similar method that associates edges with information stored in a database related to the driver's route (e.g., the route includes the road represented by the edge). When more than one driver is identified for a request, selection can be performed by filtering drivers based on attributes of each driver. For example, a threshold for the estimated time to reach the second location can be set, and identified drivers can be filtered based on this threshold. In another implementation, the time for each driver to reach the first location can be estimated and used to filter identified drivers (e.g., one or more drivers estimated to arrive at the first location within 5 minutes can be selected).

[0028] In another implementation, the request may indicate a third location, and the time it takes for each driver to reach the third location may be estimated (or the driver's ability to travel to the third location may be assessed based on the driver's route) and used to filter the identified drivers. The third location may be the location where the requested item (e.g., an item to be picked up at the first location) is to be delivered, or the location where the requested passenger (e.g., a passenger to be picked up at the first location) is to be delivered, or a location where other similar services are required.

[0029] In at least some implementations, a user can be any suitable type of entity, which may include a person making a request (e.g., a request for a driver), a consumer wishing to purchase a product or service through the transaction processing server, a seller or merchant wishing to sell a product or service through the transaction processing server, a motorcycle driver or rider in the case of a user wishing to book or provide a motorcycle ride through the transaction processing server, a car driver or passenger in the case of a user wishing to book or provide a car ride through the transaction processing server, and other similar entities. Users who register with the transaction processing server will be referred to as registered users. Users who do not register with the transaction processing server will be referred to as unregistered users. The term "user" will be used collectively to refer to both registered and unregistered users. Users can be interchangeably referred to as a requester (e.g., a person requesting a product or service) or a provider (e.g., a person providing the requested product or service to the requester).

[0030] In at least some implementations, the determining server is a server that hosts a software application used to determine the requesting driver. The determining server can be implemented as follows: Figure 2 As shown in schematic diagram 200, it is used to determine the requesting driver.

[0031] In at least some implementations, the transaction processing server is a server that hosts software applications for processing payment transactions such as requests for services, delivery, ride coordination requests, user purchases of goods or services, and other similar services. The transaction processing server communicates with any other server (e.g., a determination server) to process payment transactions related to the purchase of goods or services, such as service requests (which may be referred to as requests, such as for rides, deliveries, or other similar services requiring a provider to locate and arrive at the location indicated in the request). For example, data related to the request (e.g., information related to the required driver's location, date, time, and other similar data) may be provided to the determination server, which can then process this data to determine the driver for the request. The transaction processing server may use various different protocols and procedures to process payment and / or driver requests.

[0032] Transactions that can be executed via a transaction processing server include product or service purchases, credit purchases, debit transactions, fund transfers, and account withdrawals. The transaction processing server can be configured to process transactions via cash substitutes, which may include payment cards, letters of credit, checks, payment accounts, etc.

[0033] In at least some embodiments, the transaction processing server is typically managed by a service provider, which may be an entity (e.g., a company or organization) that operates to process transaction requests and / or driver requests (e.g., matching drivers with requesters of driver requests). The transaction processing server may include one or more computing devices for processing transaction requests and / or driver requests.

[0034] In at least some implementations, a transaction account is a user account registered with the transaction processing server. The user can be a customer, a merchant offering products sold and / or added to the platform, a ride or delivery provider (e.g., a driver), or any third party wishing to use the transaction processing server (e.g., a courier). In some cases, the transaction account does not require access to the transaction processing server. A transaction account includes the user's details (e.g., name, address, vehicle, facial image, etc.). The transaction processing server manages transactions.

[0035] The embodiments will be described by way of example only with reference to the accompanying drawings. The same reference numerals and characters in the drawings refer to the same elements or equivalents.

[0036] Some parts of the following description are presented, explicitly or implicitly, based on algorithms and functional or symbolic representations of operations on data within computer memory. These algorithmic descriptions and functional or symbolic representations are the means by which those skilled in the art of data processing most effectively communicate the substance of their work to others skilled in the art. An algorithm herein and generally is conceived as a self-consistent sequence of steps that produces a desired result. A step is one that requires physical manipulation of a physical quantity (such as an electrical, magnetic, or optical signal) that can be stored, transmitted, combined, compared, and otherwise manipulated.

[0037] Unless otherwise specifically stated and apparent from below, it should be understood that throughout this specification, the use of terms such as “identify,” “detect,” “recommend,” “determine,” “associate,” “extract,” “calculate,” “process,” “store,” “instruct,” “compare,” “provide,” “divide,” etc., refers to the actions and processes by which a computer system or similar electronic device manipulates and transforms data represented as physical quantities within the computer system into other data similarly represented as physical quantities within the computer system or other information storage, transmission, or display device.

[0038] Furthermore, this specification also implicitly discloses a computer program, as it will be apparent to those skilled in the art that the various steps of the methods described herein can be implemented by computer code. The computer program is not intended to be limited to any particular programming language or implementation thereof. It should be understood that the teachings of the disclosure contained herein can be implemented using various programming languages ​​and their coding. Moreover, the computer program is not intended to be limited to any particular control flow. Numerous other variations of the computer program with different control flows exist without departing from the scope of this specification.

[0039] Furthermore, one or more steps of a computer program may be executed in parallel rather than sequentially. Such a computer program can be stored on any computer-readable medium. Computer-readable media may include storage devices such as magnetic disks or optical disks, memory chips, or other storage devices suitable for interface connection with a computer. Computer-readable media may also include hardwired media, such as those exemplified in Internet systems, or wireless media, such as those exemplified in GSM mobile phone systems. When a computer program is loaded and executed on such a computer, it effectively provides a means for implementing the steps of the preferred method.

[0040] This disclosure proposes a system for determining a requesting driver to address the problem of a limited number of driver candidates available to process the request, and the problem of including inefficient drivers who might happen to pass by the location indicated in the request but are actually unable to process the request because they are heading to a destination far from that location. For example, a second location adjacent to the first location, indicated in the driver's request, can be determined based on a search starting from the road closest to the first location. The requesting driver can then be determined based on whether the driver is en route to the second location. Advantageously, this expands the pool of potential drivers available to process the request by incorporating "near future" drivers, taking into account the driver's time and route, rather than relying solely on a static snapshot of driver states implemented by existing methods. As a result of this implementation, only drivers within a configurable radius are considered eligible. However, with the new system and method proposed in this disclosure, drivers who are not currently within the (static snapshot) radius but are en route to the second location and will approach the first location in the near future are also considered. This method ensures that drivers who can efficiently reach the first location are included, rather than, as in existing methods, only including inefficient drivers who might pass by but whose subsequent pick-up locations are far from the location indicated in the driver's request. Furthermore, compared to the static snapshot methods used in existing methods, implementing an edge-based graph and application for representing locations, roads, and routes associated with roads advantageously requires less configuration and resources. For example, existing radius-based methods require holding many distance configurations (e.g., different values ​​for different vehicle types). On the other hand, with this solution, only a single threshold can be used for all vehicle types to determine the requesting driver, thereby reducing overhead, configuration requirements, and costs.

[0041] Figure 1 A block diagram of an example system 100 for determining a driver for a request is shown. In some embodiments, system 100 enables payment transactions for goods or services and / or requests (e.g., rides or delivery of physical items, such as one or more food items or packages) between a requester (e.g., a user associated with the request) and a provider (e.g., a driver processing the request), wherein a second location adjacent to the first location, indicated in the request, can be determined based on a search starting from the road closest to the first location, and the driver for processing the request can be determined based on whether the driver is en route to the second location.

[0042] System 100 includes a requester device 102, a provider device 104, an acquirer server 106, a transaction processing server 108, an issuer server 110, a determination server 140, and a database 150.

[0043] The requesting device 102 communicates with the providing device 104 via connection 112 and may be associated with a user. Connection 112 may be wireless (e.g., via NFC communication, Bluetooth, etc.) or via a network (e.g., the Internet). The requesting device 102 also communicates with a determining server 140 via connection 121, wherein the determining server 140 may be configured to receive request-related information from the requesting device 102 (e.g., a request for a service such as delivery or ride-hailing at a first location, the information including location information associated with the first location and other similar information). The determining server 140 may also be configured to receive information related to a third location from the requesting device 102 (e.g., a request for a service such as delivery or ride-hailing from the first location to the third location, the information including location information associated with both the first and third locations and other similar information). The location information associated with the first and third locations may include identifiers, addresses, GPS information, latitude and longitude coordinates, geohash information, or other similar information associated with the first and third locations respectively. The requesting device 102 may be configured to communicate with the providing device 104 (e.g., to conduct request-related communication with the providing device 104). Connection 121 may be via a network (e.g., the Internet). The requesting device 102 may also be connected to a cloud that facilitates the system 100 for determining the driver of the request. For example, the requesting device 102 may send signals or data directly to the cloud via a wireless connection (e.g., via NFC communication, Bluetooth, etc.) or via a network (e.g., the Internet). It should be understood that multiple requesting devices 102 may exist, such that each requesting device 102 is associated with a corresponding user.

[0044] Provider device 104, as described above, typically communicates with requesting device 102 via transaction processing server 108 and may be associated with a service or delivery provider (e.g., a provider responding to a service request such as delivery or ride to a location). Provider device 104 further communicates with acquiring server 106 via connection 114. Provider device 104 also communicates with determining server 140 via connection 123, wherein determining server 140 may be configured to receive location-related information (e.g., identifier, address, GPS information, latitude and longitude coordinates, geohash information, or other similar information associated with the location) and other similar information from provider device 104. In one implementation, determining server 140 may use the location-related information of provider device 104 to estimate the expected time for a driver associated with provider device 104 to arrive at a first, second, or third location. Once a driver is identified to process the request, the provider device 104 associated with the driver can be configured to communicate with the requesting device 102 (e.g., to conduct request-related communication with the requesting device 102). Connections 114 and 123 can be via a network (e.g., the Internet). The provider device 104 can also be connected to a cloud that facilitates the system 100 for identifying the requesting driver. For example, the provider device 104 can send signals or data directly to the cloud via a wireless connection (e.g., via NFC communication, Bluetooth, etc.) or via a network (e.g., the Internet). It should be understood that multiple provider devices 104 can exist, such that each provider device 104 is associated with a corresponding user.

[0045] The acquiring server 106 then communicates with the transaction processing server 108 via connection 116. The transaction processing server 108 then communicates with the issuing server 110 via connection 118. Connections 116 and 118 can be via a network (e.g., the Internet).

[0046] Transaction processing server 108 also communicates with determination server 140 via connection 120. Connection 120 can be via a network (e.g., local area network, wide area network, Internet, etc.). In one arrangement, transaction processing server 108 and determination server 140 are combined, and connection 120 can be an interconnect bus.

[0047] The determination server 140 then communicates with the database 150 via a corresponding connection 122. Connection 122 can be via a network (e.g., the Internet). The determination server 140 can also connect to a cloud that facilitates the system 100 for determining the requesting driver. For example, the determination server 140 can send signals or data directly to the cloud via a wireless connection (e.g., via NFC communication, Bluetooth, etc.) or via a network (e.g., the Internet).

[0048] Database 150 may include data used by determining server 140 to determine the requesting driver. For example, data related to driver attributes (such as distance to a first location, distance to a second location, estimated time to reach the second location, driver preferences, or other similar information), an edge-based road map, a mapping that associates each edge of the edge-based road map with the driver's route, and other information and / or data required to determine the requesting driver may be processed and stored in database 150. In one implementation, database 150 may be combined with determining server 140. In one example, database 150 may be managed by an external entity.

[0049] The determining server 140 can be configured to: determine a second location adjacent to the first location based on a search starting from the road closest to the first location, the first location being indicated in the driver request. The determining server 140 can also be configured to: determine the requesting driver based on whether the driver is en route to the second location. In one implementation, determining the requesting driver may further include: determining a route associated with an edge branching from the node representing the second location in an edge-based road graph, the edge representing the road closest to the second location; and identifying the driver associated with the route. In one implementation, the determining server 140 can determine the route based on a mapping that associates each edge of the edge-based road graph with routes stored in a database. In one implementation, the determining server 140 can determine whether to select the requesting driver based on one of the following: distance to the first location, distance to the second location, estimated time to reach the second location, or driver preferences.

[0050] In one implementation, determining the second location may further include: identifying another node in the edge-based road graph that is adjacent to the node representing the first location, the other node representing the second location. In another implementation, determining the second location may further include: performing a search that starts from an edge branching off from the node representing the first location and ends at a node or edge based on a threshold.

[0051] In one implementation, the determining server 140 can estimate the time required for a driver to reach a first location based on the driver's route, and select a driver based on whether the estimated time exceeds a threshold. In one implementation, the request can also indicate a third location, and the determining server 140 can select a driver based on whether the driver's route includes the third location. In another implementation, the request can also indicate a third location, and the determining server 140 can estimate the time required for a driver to reach the third location based on the driver's route, and select a driver based on whether the estimated time exceeds a threshold. Advantageously, the number of drivers that can be selected to handle the request can be increased based on whether the driver is heading to the third location or whether the driver can reach the third location within a time period. In one implementation, the determining server 140 can also be configured to: evaluate whether the route associated with the edge includes a second location, and select a driver associated with the route to handle the request based on the evaluation. Advantageously, the number of drivers that can be selected to handle the request can be increased based on whether the driver is heading to the second location or whether the driver can reach the second location within a time period. The above implementations in Figure 3 and Figures 4A to 4D The text provides further explanation.

[0052] In one implementation, more than one database may exist, wherein the determination server 140 may be configured to determine which database to use for each step during the process of determining the requesting driver. Alternatively, one or more modules, instead of database 150, may store the aforementioned data, wherein the module may be integrated as part of the determination server 140 or external to the determination server 140.

[0053] In the illustrative embodiment, each of devices 102, 104 and servers 106, 108, 110, 140 and / or database 150 provides an interface to enable communication with other connected devices 102, 104 and / or servers 106, 108, 110, 140 and / or database 150. Such communication is facilitated by an application programming interface (“API”). Such an API may be part of a user interface, which may include a graphical user interface (GUI), a web-based interface, a programming interface (such as an application programming interface (API)) and / or a set of remote procedure calls (RPCs) corresponding to interface elements, a messaging interface where interface elements correspond to messages of a communication protocol, and / or suitable combinations thereof. For example, requesting device 102 may send request-related data, such as information related to the location, date, and time of the required driver, and other similar data, and providing device 104 may send location-related data related to the associated provider in response to a query displayed on a GUI running on the corresponding API.

[0054] As used in this article, the term 'server' can refer to a single computing device or multiple interconnected computing devices that operate together to perform a specific function. That is, a server can be contained within a single hardware unit or distributed across several or more different hardware units.

[0055] Server 140 is identified as being associated with an entity (e.g., a company, organization, or regulator of a service). In one arrangement, server 140 is owned and operated by an entity that operates transaction processing server 108. In such an arrangement, server 140 may be implemented as part of transaction processing server 108 (e.g., a computer program module, computing device, etc.).

[0056] Transaction processing server 108 can also be configured to manage user registration. Registered users have a trading account (see discussion above) which includes the user's details. The registration process is called on-boarding. Users can use either requesting device 102 or providing device 104 to onboard the transaction processing server 108.

[0057] A trading account that does not need to have access to the trading server 108 is not required. However, features are available to registered users. These additional features will be discussed below.

[0058] User onboarding is performed by the user via either requester device 102 or provider device 104. In one arrangement, the user downloads an application (which includes an API to interact with transaction processing server 108) to requester device 102 or provider device 104. In another arrangement, the user accesses a website (which includes an API to interact with transaction processing server 108) on requester device 102 or provider device 104. The user can then interact with determination server 140. The user can be a requester or provider associated with requester device 102 or provider device 104, respectively.

[0059] Registration details may include, for example, the user's name, address, emergency contact, blood type or other healthcare information, close relatives, permission to retrieve data and information from requesting device 102 and / or providing device 104 to determine the requesting driver's permissions, such as permission to retrieve location and status information and other similar data and information from requesting device 102 and / or providing device 104. Alternatively, another device (e.g., a mobile device, laptop computer, personal digital assistant computer (PDA), mobile computer, tablet computer, or other similar device) may be selected to retrieve data instead of requesting device 102 and / or providing device 104. Once registered, the user will have a transaction account storing all detailed information.

[0060] The requesting device 102 is associated with a user (or requester) who is a party to a transaction occurring between the requesting device 102 and the providing device 104, or between the requesting device 102 and the determining server 140. The requesting device 102 may be a computing device, such as a desktop computer, an interactive voice response (IVR) system, a smartphone, a laptop computer, a personal digital assistant computer (PDA), a mobile computer, a tablet computer, etc. The requesting device 102 may be associated with the user who initiated the request for a driver.

[0061] The requesting device 102 includes a transaction credential (e.g., a transaction account) of the requesting party that enables it to be a party to a payment transaction. If the requesting party has a transaction account, that account may also be included (e.g., stored) in the requesting device 102. For example, a mobile device (as the requesting device 102) may store a customer's transaction account in the mobile device.

[0062] In one exemplary arrangement, the requesting device 102 is a computing device in a watch or similar wearable and is equipped with a wireless communication interface (e.g., an NFC interface). The requesting device 102 can then communicate electronically with the providing device 104 regarding a request (e.g., for delivery, ride-hailing, or other similar services). The user makes the request using the watch or similar wearable by pressing a button on the watch or wearable.

[0063] Provider device 104 is associated with a provider who is also a party to a request (e.g., for delivery, ride-hailing, or other similar services) occurring between requesting device 102 and provider device 104. Provider device 104 may be a computing device, such as a desktop computer, interactive voice response (IVR) system, smartphone, laptop computer, personal digital assistant computer (PDA), mobile computer, tablet computer, etc. Provider device 104 may be associated with a provider of ride-hailing or delivery services (e.g., a provider responding to a request).

[0064] In the following text, the term "provider" refers to the service provider and any third party associated with the provision of products or services or driving, riding, or delivery services for purchase via provider device 104. Therefore, the provider's transaction account refers to both the provider's transaction account and the transaction accounts of third parties associated with the provider (e.g., drivers, ride coordinators, or merchants).

[0065] If the provider has a trading account, the trading account may also be included (e.g., stored) in the provider device 104. For example, a mobile device (as provider device 104) may store the provider's trading account in the mobile device.

[0066] In one exemplary arrangement, the provider device 104 is a computing device in a watch or similar wearable device and is equipped with a wireless communication interface (e.g., an NFC interface). The provider device 104 can then communicate electronically with the requester to make a request by pressing a button on the watch or wearable device.

[0067] Acquiring server 106 is associated with an acquiring party, which can be an entity (e.g., a company or organization) that issues (e.g., establishes, manages, or administers) a merchant's payment account (e.g., a financial bank account). Examples of acquiring parties include banks and / or other financial institutions. As discussed above, acquiring server 106 may include one or more computing devices for establishing communication with another server (e.g., transaction processing server 108) by exchanging messages with other servers and / or transmitting information to other servers. Acquiring server 106 forwards payment transactions related to transaction requests or requests for delivery or other similar services to transaction processing server 108.

[0068] Transaction processing server 108 is configured to process transaction-related processes by, for example, forwarding transaction-related data and information to other servers in system 100, such as determination server 140. In one example, transaction processing server 108 may, instead of requesting device 102 or providing device 104, send request-related data (e.g., location information related to a first location, location information related to a third location, date, time, and other similar data) to determination server 140 to determine a second location adjacent to the first location. Transaction processing server 108 may use various different protocols and procedures to process payments and / or requests. It should be understood that payments for transactions can be made via various methods, such as credit cards, debit cards, digital wallets, buy-now-pay-later schemes, and other similar payment methods.

[0069] Issuer server 110 is associated with an issuer and may include one or more computing devices for executing payment transactions. The issuer may be an entity (e.g., a company or organization) associated with the owner of requester device 102 that issues (e.g., establishes, manages, or operates) transaction credentials or payment accounts (e.g., financial bank accounts). As discussed above, issuer server 110 may include one or more computing devices for establishing communication with another server (e.g., transaction processing server 108) by exchanging messages with other servers and / or transmitting information to other servers.

[0070] Database 150 is a database or server associated with an entity (e.g., a company or organization) that manages (e.g., establishes, operates) data related to users, transactions, products, services, and other similar data associated with that entity. In an arrangement, database 150 may include data used by determining server 140 to determine a requesting driver. For example, data related to driver attributes (such as distance to a first location, distance to a second location, estimated time to reach the second location, driver preferences, or other similar information), an edge-based road map, a mapping that associates each edge of the edge-based road map with the driver's route, and other information and / or data required to determine the requesting driver may be processed and stored in database 150. In one implementation, database 150 may be combined with determining server 140. In one example, database 150 may be managed by an external entity.

[0071] Advantageously, system 100 expands the driver candidate pool by incorporating "near future" drivers, considering both the driver's time and route, rather than relying solely on static snapshots of driver states as implemented in existing methods. As a result of this implementation, only drivers within a configurable radius are considered eligible. However, with the novel system and method proposed in this disclosure, drivers who are not currently within the (static snapshot) radius but are en route to a second location and will approach the first location in the near future are also considered. This method ensures that drivers who can efficiently reach the first location are included, thereby reducing the time required to reach locations requiring drivers and improving service efficiency. Furthermore, compared to the static snapshot approach used in existing methods, implementing an edge-based graph and application for representing locations, roads, and routes associated with roads advantageously requires less configuration and resources.

[0072] Figure 2A schematic diagram of a determination server 140 according to various embodiments is shown. The determination server 140 may include a data module 260 configured to receive data and information from requesting device 102, providing device 104, transaction processing server 108, database 150, cloud, and other information sources to determine the requesting driver by the determination server 140. For example, data module 260 may be configured to receive data and information required for the following operations: determining a second location adjacent to the first location based on a search starting from the road closest to the first location, the first location indicated in the driver request; determining the requesting driver based on whether the driver is en route to the second location; determining a route associated with an edge branching from the node representing the second location in the edge-based road graph, the edge representing the road closest to the second location; and identifying the driver associated with the route; determining the route based on a mapping that associates each edge of the edge-based road graph with routes stored in a database; determining whether to select the requesting driver based on the driver's attributes, which are one of: distance from the first location, distance from the second location, estimated time to reach the second location, or driver preference; and identifying the node adjacent to the first location in the edge-based road graph. Another node, representing a second location; performing a search that begins with an edge branching from the node representing the first location and ends at a node or edge based on a threshold; estimating the time required for the driver to reach the first location based on the driver's route; and selecting a driver based on a determination that the estimated time exceeds a threshold; wherein the request may also indicate a third location; selecting a driver based on a determination that the driver's route includes the third location, or estimating the time required for the driver to reach the third location based on the driver's route and a determination that the estimated time exceeds a threshold; evaluating whether the route associated with the edge includes the second location; and selecting a driver associated with the route used to process the request based on this evaluation; and other similar processes from the requesting device 102, the providing device 104, the transaction processing server 108, the database 150, and / or other information sources. The data module 260 may also be configured to send the information to the requesting device 102, the providing device 104, the transaction processing server 108, or other destinations that require information related to the data retrieved in response to the request.

[0073] The server 140 may include a search module 262 configured to determine a second location adjacent to the first location based on a search starting from the road closest to the first location, the first location indicated in a request to the driver. In one implementation, the search module 262 may be configured to identify another node in an edge-based road graph adjacent to the node representing the first location, the other node representing the second location. In one implementation, the search module 262 may be configured to perform a search starting from an edge branching from the node representing the first location and ending at the node or edge based on a threshold. The above process in Figures 4A to 4D The text provides further explanation.

[0074] The determining server 140 may further include a determining module 264 configured to determine the requesting driver based on whether the driver is en route to a second location (e.g., as determined by the search module 262). In one implementation, the determining module 264 may be configured to: determine a route associated with an edge branching from a node representing the second location in an edge-based road graph, the edge representing the road closest to the second location; and identify the driver associated with the route. In one implementation, the determining module 264 may be configured to: determine a route based on a mapping that associates each edge of the edge-based road graph with routes stored in a database. In one implementation, the determining module 264 may be configured to: determine whether to select the requesting driver based on driver attributes, which are one of: distance from the first location, distance from the second location, estimated time to reach the second location, or driver preferences. In one implementation, the determining module 264 may be configured to: estimate the time required for the driver to reach the first location based on the driver's route, and select the driver based on a determination that the estimated time exceeds a threshold. In an implementation where the request also indicates a third location, the determining module 264 can be configured to: select a driver based on whether the driver's route includes the third location, or estimate the time required for the driver to reach the third location based on the driver's route, and select a driver based on whether the estimated time exceeds a threshold. In another implementation where the request also indicates a third location, the determining module 264 can be configured to: estimate the time required for the driver to reach the third location based on the driver's route, and select a driver based on whether the estimated time exceeds a threshold. Advantageously, the number of drivers that can be selected to handle the request can be increased based on whether the driver travels to the third location or whether the driver can reach the third location within a time period. In one implementation, the determining module 264 can also be configured to: evaluate whether the route associated with the edge includes a second location, and select a driver associated with the route to handle the request based on the evaluation. Advantageously, the number of drivers that can be selected to handle the request can be increased based on whether the driver travels to the second location or whether the driver can reach the second location within a time period. The above process in Figure 3 and Figures 4A to 4D The text provides further explanation.

[0075] Each of the data module 260, search module 262, and determination module 264 can also communicate with the processing module (not shown) of the determination server 140, for example, to coordinate corresponding tasks and functions during the process. The data module 260 can also be configured to communicate with each of the processing module, search module 262, and determination module 264 and store data and information for each of the processing module, search module, and determination module. Alternatively, all tasks and functions required for adaptively determining the requesting driver can be performed by a single processor of the determination server 140.

[0076] Figure 3 An exemplary illustration 300 depicts various embodiments of the present disclosure for determining a driver for a request. In illustration 300, the system is attempting to assign an order with merchant A 304 as the pick-up location (e.g., the first location indicated in the request associated with the order). A static approach according to existing methods would only consider driver 1 308 who is en route to merchant B 304 and is captured in a static snapshot with a radius of 310. However, if the system identifies driver 2 310 as being en route to merchant C 306, which is close to merchant A 302 (e.g., within the vicinity of merchant A 302), driver 2 310 can also be included in a candidate pool of drivers who can be assigned to handle the request, even though the driver is not within the radius of 310 at that time, thereby expanding the candidate pool of drivers for handling the request.

[0077] Therefore, in the proposed solution, it is now possible to introduce new driver candidates previously excluded due to proximity limitations. This increases the likelihood of in-trip batch processing and results in higher average in-trip batch processing quality. Furthermore, higher-quality driver candidates can be identified by filtering drivers who may need to take detours (thus wasting time) to reach the new order pick-up location (e.g., the first location). This significantly reduces the workload of downstream processes while minimizing the impact on the likelihood of in-trip batch processing. Moreover, the proposed solution requires less configuration and maintenance costs compared to existing solutions that may require managing static snapshot radii, varying vehicle types, and environmental factors such as traffic, weather, and others.

[0078] This solution typically includes the following steps. Pick-up locations, such as delivery orders, passengers, or other similar entities, can be identified from the order (e.g., a first location indicated in the request associated with the order can be identified). Based on the first location, a second location within the vicinity of the first location can be determined. In one implementation, location-based services (LBS) can be used to determine, for example, a second location within a predefined route or at a distance from the first location (e.g., a nearby location such as a business location, POI, landmark, or other similar entity). Thus, one or more second locations can be determined based on a search. Furthermore, the driver's route in the trip can be examined to see if the second location is part of the route. It should be understood that the routes of one or more drivers can be examined. In one implementation, information related to the route and the driver (e.g., the next steps the driver will take associated with the route, the driver's identifier associated with the route, driver attributes such as distance from the first location, distance from the second location, estimated time to reach the second location, driver status, driver preferences or other similar attributes, the type of vehicle the driver used for the route, and other similar information related to the route) can be examined to determine if the driver is capable of handling the request. In an implementation where a third location is indicated in the request (e.g., the third location is the delivery location of the item, passenger, or similar entity indicated in the request), a driver can be selected to handle the request based on whether the driver's route includes the third location. In one implementation, the estimated time for the driver to reach the third location can be used to determine whether to select that driver to handle the request. Advantageously, the number of drivers that can be selected to handle the request can be increased based on whether the driver travels to the third location or whether the driver can reach the third location within a time period. In one implementation, whether the route associated with the edge includes a second location can be evaluated, and a driver associated with the route can be selected to handle the request based on the evaluation. Advantageously, the number of drivers that can be selected to handle the request can be increased based on whether the driver travels to the second location or whether the driver can reach the second location within a time period.

[0079] In one implementation, each location can be represented as a node, and each road can be represented as an edge in an edge-based road graph. A reference depicts an edge-based road graph. Figure 4AIn diagram 400, node 402 may represent a first location indicated in the driver's request, and each of nodes 404, 406, 408, 410, and 412 may represent a second location within the vicinity of the first location. Each of edges 414, 416, 418, 420, and 422 represents a road. Specifically, each of edges 414, 418, and 420 represents the road closest to the first location. Furthermore, each edge may be associated with the route of a driver who is currently or will be traveling along the road. Human figures 401, 403, 405, 407, and 409 represent the locations (e.g., current GPS locations) of driver 1, driver 2, driver 3, driver 4, and driver 5, respectively. For example, human figure 401 located at edge 422 may indicate that driver 1 is currently located on the road represented by edge 422. Boxes 411, 413, and 415 indicate the next step in the driver's route. For example, box 411 represents the next step in booking 1 processed by driver 2 (e.g., the current location represented by human figure 403), where driver 2 needs to deliver the passenger or delivery item (e.g., the item to be delivered) at a location, for example, represented by node 402. Furthermore, box 413 represents the next step in booking 1 processed by driver 3 (e.g., the current location represented by human figure 405), where driver 3 needs to pick up the passenger or delivery item at a location, for example, represented by node 402. Further still, box 415 represents an additional step in booking 1, where driver 3 needs to deliver the passenger or delivery item at a location, for example, represented by node 408.

[0080] The association between edges and the driver's route can be based on a mapping. In one implementation, the mapping can be based on an inverted index, for example, such as... Figure 4BThe inverted index 430 is shown. For example, the inverted index 430 may indicate the association between edge 414 and the route of driver 2 who will deliver the passenger or delivery for booking 1, the association between edge 420 and the route of driver 3 who will pick up the passenger or delivery for booking 2, and the association between edge 418 and the route of driver 3 who will deliver the passenger or delivery for booking 2. A search for the second location can be performed starting from the road closest to the first location. In one implementation, the search may be a BFS centered on node 402 (representing the first location) and starting from one or more of the edges 414, 418, and 420 closest to node 402. The BFS may be configured to end at an edge or node based on a threshold (e.g., the search may be configured to end after traversing a maximum number of nodes and / or edges, or after traversing a maximum distance from the first location, or other similar configurations). Based on the inverted index, each edge within the neighborhood of the node representing the second location may be checked for an associated driver route to assess whether the driver can be selected to handle the request. Advantageously, by implementing an edge-based road graph and inverted index, it is possible to efficiently examine the route plans of each driver currently traveling or about to travel on a given road, rather than simply performing a global traversal. It should be understood that the location of each driver (e.g., determined by...) is determined by... Figure 4A The locations represented by the human figures 401, 403, 405, 407, and 409 in the diagram can be updated at a specific frequency (e.g., for a set duration of one or several milliseconds, one or several seconds, one minute or several minutes, or other similar durations), and the steps of the route (e.g., Figure 4A and Figure 4B Boxes 411, 413 and 415 in the table can be added, updated or removed as the driver’s task changes (e.g., the current booking is cancelled and / or a new booking is received, or other similar situations).

[0081] Figure 4C Exemplary illustrations of location-based services (LBS) 440 according to various embodiments of the present disclosure are depicted. As shown above, each edge of the edge-based road map of Figure 400 can be mapped to information related to a route traveled by a driver who is currently or will be traveling along the road represented by that edge. This information may include: the next step the driver will take associated with the route, the identifier of the driver associated with the route, the driver's attributes (e.g., one of the following: distance from a first location, distance from a second location, estimated time to reach the second location, driver's state, driver's preferences, or other similar attributes), the type of vehicle the driver uses for the route, and other similar information related to the route. This information may be stored in a database.

[0082] In one implementation, driver attributes can be passed to the access layer 442 of the LBS 440 service host. Access layer 442 can be configured to map the driver object's location attributes to the road network (e.g., converting {latitude, longitude} to {edge ID, percentage offset}). For properties unrelated to location information, these attributes can be sent directly to the next layer. The driver object can include two types of location attributes: GPS location and driver plan (e.g., consisting of one or more ordered steps taken by the driver while processing a request). These attributes can then be distributed to all hosts in the LBS 440 (e.g., via distribution layer 444) to update memory storage in storage layer 448. Distribution layer 444 can be used to broadcast properties to all hosts. Additionally, the LBS service can consist of one or more servers. In one implementation, the LBS service can include 10 servers, where each server can handle only 1 / 10 of the property update requests, and each server's distribution layer can broadcast the current server's data to the other 9 servers and retrieve the other 9 / 10 of the property updates from the other 9 servers. This advantageously allows each server to obtain 100% of the driver's latest attributes.

[0083] Specifically, information related to the driver's route (e.g., the next step in the route the driver might take) can be used to update the inverted index (e.g., inverted index 430) via the index layer 446 of the LBS 440 service host. Index layer 446 can be configured to refresh the inverted index with the latest location properties of the driver object. Using the driver's location attributes (e.g., the driver's GPS location), one or more indexes associated with the driver's route can be constructed and updated (e.g., the edge-driver GPS index can be updated based on the driver's GPS location, and the edge-step index and edge-last step index associated with the driver can be constructed and updated using one or more steps in the driver's driver plan). It should be understood that other forms of processing information related to the route and the driver associated with that route are also possible.

[0084] Figure 4DAn exemplary flowchart 450 for determining a requesting driver according to various embodiments of the present disclosure is depicted. At step 452, a request (e.g., a request for a driver) may be received. At step 454, the request may be parsed into several search processes. This process may include a search based on the driver's GPS location, starting at step 455, where the driver is determined based on whether the driver's GPS location is close to the pick-up location indicated in the request. This search can be traversed using an edge-GPS index and can be used in batching scenarios, where one or more requests are grouped together for driver processing. The process may also include a search starting at step 457 based on finding a driver who will reach their final step (e.g., the final step of the driver's route) close to the pick-up location indicated in the request. This search can be traversed using an edge-final step index. For this solution, the process may be configured to have only one branch: the pick-up neighboring pick-up step in step 456. From step 456, the process proceeds to step 458, where a BFS can be performed, for example, on an edge-based road graph 400 centered at node 402 (e.g., the node representing the first location indicated in the request), to determine a second location (represented by nodes 404, 406, 408, 410, and 412) and neighboring roads (e.g., represented by edges 414, 416, 418, 420, and 422 in graph 400). Furthermore, an inverted index 446 can be used to traverse neighboring edges, obtaining delivery steps for the route associated with each traversed edge, and identifying the driver associated with the route (e.g., based on the identifier of the driver associated with the route). In one implementation, a corresponding index can be selected based on the requirements indicated in the driver's request (e.g., distance or time requirements indicated in the request, such as corresponding to the shortest estimated distance or shortest estimated time to complete the request, respectively), and edges can be traversed via BFS based on the selected corresponding index. At step 448, information related to the route of a driver who is currently or will be traveling along the road represented by traversed edges is retrieved from a database (e.g., database 150). At step 450, one or more filters may be applied to select a driver to process the request based on one or more attributes of the driver (e.g., distance to a first location, distance to a second location, estimated time to reach the second location, driver status, driver preferences, and / or other similar attributes). For example, multi-level filtering may be performed, where each filter may be based on driver attributes and appropriate local and remote storage. By implementing these steps and updating the system, eligible driver candidates can be efficiently identified based on the driver's route and proximity to neighboring locations, ultimately improving the batch processing in the trip.

[0085] Figure 5An exemplary flowchart of a method 500 for determining a requesting driver according to various embodiments is shown. In step 502, a second location adjacent to the first location, indicated in the request to the driver, may be determined based on a search starting from the road closest to the first location. In step 504, the requesting driver may be determined based on whether the driver is en route to the second location.

[0086] Figure 6 An example computer system 1400 is depicted, and a server 140 can be determined according to the practice described in this example computer system description. Computer system 1400 includes computer module 1401. An external modem transceiver device 1416 can be used by computer module 1401 to communicate to and from a communication network 1420 via connection 1421. Communication network 1420 can be a wide area network (WAN), such as the Internet, a cellular telecommunications network, or a dedicated WAN. If connection 1421 is a telephone line, modem 1416 can be a conventional "dial-up" modem. Alternatively, if connection 1421 is a high-capacity (e.g., cable) connection, modem 1416 can be a broadband modem. A wireless modem can also be used for wireless connection to communication network 1420.

[0087] Computer module 1401 typically includes at least one processor unit 1405 and a memory unit 1406. For example, memory unit 1406 may have semiconductor random access memory (RAM) and semiconductor read-only memory (ROM). Computer module 1401 also includes an interface 1408 for an external modem 1416. In some implementations, modem 1416 may be incorporated into computer module 1401, for example, into interface 1408. Computer module 1401 also has a local network interface 1411, which allows computer system 1400 to be coupled to a local area communication network 1422, known as a local area network (LAN), via connection 1423. Figure 6 As illustrated in Figure A, the local communication network 1422 can also be coupled to the wide area network 1420 via connection 1424, which will typically include a so-called "firewall" device or a device with similar functionality. The local network interface 1411 may include an Ethernet circuit card, a Bluetooth® wireless device, or an IEEE 802.11 wireless device; however, a variety of other types of interfaces may be used for interface 1411.

[0088] I / O interface 1408 can provide either or both serial and parallel connections, the former typically implemented according to the Universal Serial Bus (USB) standard and having a corresponding USB connector (not shown). Storage device 1409 is provided, and this storage device typically includes a hard disk drive (HDD) 1410. Other storage devices, such as floppy disk drives and magnetic tape drives (not shown), may also be used. Optical disk drive 1412 is typically provided to serve as a non-volatile data source. For example, portable storage devices such as optical disks, USB-RAM, portable external hard disk drives, and floppy disks can be used as a suitable data source for system 1400.

[0089] Components 1405 to 1412 of computer module 1401 typically communicate via interconnect bus 1304 in a manner consistent with the conventional operating mode of computer system 1400 known to those skilled in the art. For example, processor 1405 is coupled to system bus 1404 via connection 1418. Similarly, memory 1406 and optical disc drive 1412 are coupled to system bus 1404 via connection 1419. Examples of computers on which the described apparatus may be practiced include IBM-PCs and compatibles, SunSparcstations, Apple, or similar computer systems.

[0090] The method 500 executed by the server 140 can be implemented using the computer system 1400. These processes can be implemented as one or more software applications 1433 executable within the computer system 1400. Specifically, the method 500 is implemented through instructions in the software 1433 practiced within the computer system 1400. The software instructions can be formed as one or more code modules, each code module performing one or more specific tasks. The software can also be divided into two separate parts, where a first part and its corresponding code modules execute the method 500, and a second part and its corresponding code modules manage the user interface between the first part and the user.

[0091] Software can be stored in a computer-readable medium, including storage devices such as those described below. The software is loaded from the computer-readable medium into computer system 1400 and then executed by computer system 1400. A computer-readable medium having such software or a computer program recorded on it is a computer program product. The use of the computer program product in computer system 1400 preferably implements advantageous means for determining server 140.

[0092] Software 1433 is typically stored in HDD 1410 or memory 1406. The software is loaded from a computer-readable medium into computer system 1400 and executed by computer system 1400. Therefore, for example, software 1433 may be stored on an optically readable disk storage medium (e.g., CD-ROM) 1425 read by optical disk drive 1412. A computer-readable medium having such software or a computer program recorded on it is a computer program product. The use of the computer program product in computer system 1400 preferably implements a device for determining server 140.

[0093] In some instances, application 1433 may be encoded on one or more CD-ROMs 1425 and supplied to a user and read via a corresponding drive 1412, or alternatively, may be read by the user from networks 1420 or 1422. Furthermore, the software may also be loaded into computer system 1400 from other computer-readable media. Computer-readable storage media are any non-transitory tangible storage media that provides recorded instructions and / or data to computer system 1400 for execution and / or processing. Examples of such storage media include floppy disks, magnetic tapes, optical discs, hard disk drives, ROMs or integrated circuits, USB storage devices, magneto-optical discs, or computer-readable cards (such as PCMCIA cards), whether such devices are internal or external to computer module 1401. Examples of temporary or non-tangible computer-readable transmission media that may also participate in providing software, applications, instructions, and / or data to computer module 1401 include radio or infrared transmission channels to another computer or networked device, network connections, and the Internet or intranets, including information recorded on email transmissions and websites.

[0094] The second part of application 1433 and the corresponding code modules mentioned above can be executed to implement one or more graphical user interfaces (GUIs) to be displayed on a monitor or otherwise represented. By typically manipulating the keyboard and mouse, users and applications of computer system 1400 can manipulate the interface in a functionally adaptable manner to provide control commands and / or input to applications associated with the GUI. Other forms of functionally adaptable user interfaces can also be implemented, such as audio interfaces utilizing voice prompts output via speakers and user voice commands input via microphones.

[0095] It should be understood that the structural background of computer system 1400 (i.e., determining server 140) is presented only by way of example. Therefore, in some arrangements, one or more features of computer system 1400 may be omitted. Furthermore, in some arrangements, one or more features of computer system 1400 may be combined together. Additionally, in some devices, one or more features of computer system 1400 may be divided into one or more component parts.

[0096] Figure 7 An implementation of a transaction processing server 108 (i.e., computer system 1300) is illustrated. In this implementation, the transaction processing server 108 can generally be described as a physical device including at least one processor 802 and at least one memory 804 including computer program code. The at least one memory 804 and the computer program code are configured, together with the at least one processor 802, to enable the transaction processing server 108 to facilitate the operation described in method 500. The transaction processing server 108 may also include a transaction processing module 806. The memory 804 stores the computer program code, which the processor 802 compiles to cause the transaction processing module 806 to perform corresponding functions.

[0097] refer to Figure 1 The transaction processing module 806 performs functions that communicate with the requesting device 102 and the providing device 104, as well as the acquiring server 106 and the issuing server 110, to receive and send transactions, service requests, delivery, trip coordination requests, user purchases of goods or services, and other similar services, respectively. The transaction processing module 806 can be configured to process transaction-related processes by, for example, forwarding transaction-related data and information to other servers in system 100, such as determination server 140. In one example, the transaction processing server 108 may, instead of the requesting device 102 or the providing device 104, send request-related data (e.g., location information related to a first location, location information related to a third location, date, time, and other similar data) to determination server 140 to determine a second location adjacent to the first location. The transaction processing module 806 can use various different protocols and procedures to process payments and / or requests. It should be understood that payments for transactions can be made via various methods, such as credit cards, debit cards, digital wallets, buy-now-pay-later schemes, and other similar payment methods.

[0098] Figure 10Alternative implementations of a determination server 140 (e.g., computer system 1400) are illustrated. In these alternative implementations, the determination server 140 can generally be described as a physical device including at least one processor 902 and at least one memory 904 including computer program code. The at least one memory 904 and the computer program code are configured, together with the at least one processor 902, to cause the determination server 140 to perform the operations described in method 500. The determination server 140 may also include a data module 906, a search module 908, and a determination module 910. The memory 904 stores the computer program code, which the processor 902 compiles to cause each of the modules 906 through 910 to perform its respective function.

[0099] refer to Figures 1 to 5 The search module 908 performs the function of determining a second location adjacent to the first location based on a search starting from the road closest to the first location, the first location being indicated in the request to the driver. In one implementation, the search module 908 may be configured to identify another node in the edge-based road map that is adjacent to the node representing the first location, the other node representing the second location. In one implementation, the search module 908 may be configured to perform a search starting from an edge branching from the node representing the first location and ending at the node or edge based on a threshold.

[0100] refer to Figures 1 to 5The determining module 910 performs the function of determining the requesting driver based on whether the driver is en route to the second location (e.g., determined by the search module 908). In one implementation, the determining module 910 may be configured to: determine a route associated with an edge branching from the node representing the second location in an edge-based road graph, the edge representing the road closest to the second location; and identify the driver associated with the route. In one implementation, the determining module 910 may be configured to: determine a route based on a mapping that associates each edge of the edge-based road graph with routes stored in a database. In one implementation, the determining module 910 may be configured to: determine whether to select the requesting driver based on driver attributes, which are one of the following: distance from the first location, distance from the second location, estimated time to reach the second location, or driver preferences. In one implementation, the determining module 910 may be configured to: estimate the time required for the driver to reach the first location based on the driver's route, and select the driver based on a determination that the estimated time exceeds a threshold. In an implementation where the request also indicates a third location, the determining module 910 can be configured to: select a driver based on whether the driver's route includes the third location, or estimate the time required for the driver to reach the third location based on the driver's route and select a driver based on whether the estimated time exceeds a threshold. In another implementation where the request also indicates a third location, the determining module 910 can be configured to: estimate the time required for the driver to reach the third location based on the driver's route and select a driver based on whether the estimated time exceeds a threshold. In one implementation, the determining module 910 can also be configured to: evaluate whether the route associated with the edge includes a second location and select a driver associated with the route to process the request based on the evaluation.

[0101] refer to Figures 1 to 5The data module 906 performs the function of receiving data and information from the requesting device 102, the providing device 104, the transaction processing server 108, the database 150, the cloud, and other information sources, so that the determining server 140 can determine the requesting driver. For example, the data module 906 may be configured to receive data and information required for the following operations: determining a second location adjacent to the first location based on a search starting from the road closest to the first location, the first location indicated in the driver request; determining the requesting driver based on whether the driver is en route to the second location; determining a route associated with an edge branching from the node representing the second location in the edge-based road graph, the edge representing the road closest to the second location; and identifying the driver associated with the route; determining a route based on a mapping that associates each edge of the edge-based road graph with routes stored in the database; determining whether to select the requesting driver based on the driver's attributes, which are one of the following: distance from the first location, distance from the second location, estimated time to reach the second location, or driver preferences; and identifying another adjacent node representing the first location in the edge-based road graph. One node represents a second location; a search is performed, starting from an edge branching off from the node representing the first location and ending at a node or edge based on a threshold; the time required for the driver to reach the first location is estimated based on the driver's route; and a driver is selected based on a determination that the estimated time exceeds a threshold; wherein the request may also indicate a third location; a driver is selected based on a determination that the driver's route includes the third location, or a driver is selected based on an estimate of the time required for the driver to reach the third location and a determination that the estimated time exceeds a threshold; the route associated with an edge is evaluated to determine whether it includes the second location; and a driver is selected based on this evaluation and associated with the route used to process the request; and other similar processes from the requesting device 102, the providing device 104, the transaction processing server 108, the database 150, and / or other information sources. The data module 260 may also be configured to send the information to the requesting device 102, the providing device 104, the transaction processing server 108, or other destinations that require information related to the data retrieved in response to the request.

[0102] Figure 8B describes a general-purpose computer system 1500 on which the described combination of transaction processing server 108 and determination server 140 can be implemented. Computer system 1500 includes computer module 1501. An external modem transceiver device 1516 can be used by computer module 1501 to communicate to and from a communication network 1520 via connection 1521. Communication network 1520 can be a wide area network (WAN), such as the Internet, a cellular telecommunications network, or a dedicated WAN. If connection 1521 is a telephone line, modem 1516 can be a conventional "dial-up" modem. Alternatively, if connection 1521 is a high-capacity (e.g., cable) connection, modem 1516 can be a broadband modem. A wireless modem can also be used for wireless connectivity to communication network 1520.

[0103] Computer module 1501 typically includes at least one processor unit 1505 and a memory unit 1506. For example, memory unit 1506 may have semiconductor random access memory (RAM) and semiconductor read-only memory (ROM). Computer module 1501 also includes an interface 1508 for an external modem 1516. In some implementations, modem 1516 may be incorporated into computer module 1501, for example, into interface 1508. Computer module 1501 also has a local network interface 1511, which allows computer system 1500 to be coupled to a local area communication network 1522, known as a local area network (LAN), via connection 1523. Figure 8 As illustrated in Figure D, the local communication network 1522 can also be coupled to the wide area network 1520 via connection 1524, which will typically include a so-called "firewall" device or a device with similar functionality. The local network interface 1511 may include an Ethernet circuit card, a Bluetooth® wireless device, or an IEEE 802.11 wireless device; however, a variety of other types of interfaces may be used for interface 1511.

[0104] I / O interface 1508 can provide either or both serial and parallel connections, the former typically implemented according to the Universal Serial Bus (USB) standard and having a corresponding USB connector (not shown). Storage device 1509 is provided, and this storage device typically includes a hard disk drive (HDD) 1510. Other storage devices, such as floppy disk drives and tape drives (not shown), may also be used. Optical disk drive 1512 is typically provided to serve as a non-volatile data source. For example, portable storage devices such as optical disks, USB-RAM, portable external hard disk drives, and floppy disks can be used as a suitable data source for system 1500.

[0105] Components 1505 to 1512 of computer module 1501 typically communicate via interconnect bus 1504 in a manner consistent with the conventional operating mode of computer system 1500 known to those skilled in the art. For example, processor 1505 is coupled to system bus 1504 via connection 1518. Similarly, memory 1506 and optical disc drive 1512 are coupled to system bus 1504 via connection 1519. Examples of computers on which the described apparatus may be practiced include IBM-PCs and compatibles, SunSparcstations, Apple, or similar computer systems.

[0106] The steps of method 500, executed by the determining server 140 and facilitated by the transaction processing server 108, can be implemented using computer system 1500. For example, the steps of method 500 executed by the determining server 140 can be implemented as one or more software applications 1533 executable within computer system 1500. Specifically, the steps of method 500 are influenced by instructions in the software 1533 executing within computer system 1500. These software instructions can be formed as one or more code modules, each for performing one or more specific tasks. The software can also be divided into two separate parts, where a first part and its corresponding code modules execute the steps of method 500, and a second part and its corresponding code modules manage the user interface between the first part and the user.

[0107] Software can be stored in a computer-readable medium, including storage devices such as those described below. The software is loaded from the computer-readable medium into computer system 1500 and then executed by computer system 1500. A computer-readable medium having such software or a computer program recorded on it is a computer program product. The use of the computer program product in computer system 1500 preferably implements advantageous means for combining transaction processing and determining servers.

[0108] Software 1533 is typically stored in HDD 1510 or memory 1506. The software is loaded from a computer-readable medium into computer system 1500 and executed by computer system 1500. Therefore, for example, software 1533 may be stored on an optically readable disk storage medium (e.g., CD-ROM) 1525 read by optical disk drive 1512. A computer-readable medium having such software or a computer program recorded on it is a computer program product. The use of the computer program product in computer system 1500 preferably implements a device for combining transaction processing and determining a server.

[0109] In some instances, application 1533 may be encoded on one or more CD-ROMs 1525 and supplied to a user and read via a corresponding drive 1512, or alternatively, may be read by the user from networks 1520 or 1522. Furthermore, the software may also be loaded into computer system 1500 from other computer-readable media. Computer-readable storage media are any non-transitory tangible storage media that provides recorded instructions and / or data to computer system 1500 for execution and / or processing. Examples of such storage media include floppy disks, magnetic tapes, optical discs, hard disk drives, ROMs or integrated circuits, USB storage devices, magneto-optical discs, or computer-readable cards (such as PCMCIA cards), whether such devices are internal or external to computer module 1501. Examples of temporary or non-tangible computer-readable transmission media that may also participate in providing software, applications, instructions, and / or data to computer module 1501 include radio or infrared transmission channels to another computer or networked device, network connections, and the Internet or intranets, including information recorded on email transmissions and websites.

[0110] The second part of application 1533 and the corresponding code modules mentioned above can be executed to implement one or more graphical user interfaces (GUIs) to be displayed on a monitor or otherwise represented. By typically manipulating the keyboard and mouse, users and applications of computer system 1500 can manipulate the interface in a functionally adaptable manner to provide control commands and / or input to applications associated with the GUI. Other forms of functionally adaptable user interfaces can also be implemented, such as audio interfaces utilizing voice prompts output via speakers and user voice commands input via microphones.

[0111] It should be understood that the structural background of the computer system 1500 (e.g., the combined transaction processing and determination server 1500) is presented merely as an example. Therefore, in some arrangements, one or more features of the server 1500 may be omitted. Furthermore, in some arrangements, one or more features of the server 1500 may be combined together. Additionally, in some arrangements, one or more features of the server 1500 may be divided into one or more component parts.

[0112] Figure 10An alternative implementation of a combined transaction processing and determination server (i.e., computer system 1500) is shown. In this alternative implementation, the combined transaction processing and determination server can generally be described as a physical device including at least one processor 1002 and at least one memory 904 including computer program code. The at least one memory 1004 and the computer program code are configured, together with the at least one processor 1002, to cause the combined transaction processing and determination server to perform the operations described in the steps of method 500. The combined transaction processing and determination server may further include a transaction processing module 806, a data module 906, a search module 908, and a determination module 910. The memory 1004 stores the computer program code, which the processor 1002 compiles to cause each of modules 806 to 910 to perform its respective function. Transaction processing module 806 performs operations related to... Figure 8 The same transaction processing modules describe the same functions. Data module 906, search module 908, and determination module 910 perform the same operations as described in the previous section. Figure 9 The same function described in the corresponding module.

[0113] Those skilled in the art will understand that various variations and / or modifications can be made to the present disclosure shown in particular embodiments without departing from the scope of the broadly described specification. Therefore, the embodiments of the present invention are to be considered illustrative rather than restrictive in all respects.

Claims

1. A method for determining a requesting driver, comprising: The processor determines a second location adjacent to the first location based on a search starting from the road closest to the first location, which is indicated in the request to the driver; as well as The processor determines the requesting driver based on whether the driver is en route to the second location.

2. The method according to claim 1, wherein, Determining the driver of the request further includes: determining a route associated with an edge branching from the node representing the second location in an edge-based road graph, the edge representing the road closest to the second location; and identifying the driver associated with the route.

3. The method according to claim 2, further comprising: The route is determined based on a mapping that associates each edge of the edge-based road graph with routes stored in a database.

4. The method according to claim 2, further comprising: The driver is selected for the request based on the driver's attributes, which are one of the following: distance from the first location, distance from the second location, estimated time to reach the second location, or the driver's preference.

5. The method according to claim 1, wherein, Determining the second location further includes: identifying another node in the edge-based road graph that is adjacent to the node representing the first location, the other node representing the second location.

6. The method according to claim 5, wherein, Determining the second position further includes performing the search, which begins with an edge branching off from the node representing the first position and ends at the node or edge based on a threshold.

7. The method according to claim 1, further comprising: The driver is selected based on the driver's route to estimate the time required for the driver to reach the first location, and based on whether the estimated time exceeds a threshold.

8. The method according to claim 1, wherein, The request also indicates a third location, and the method further includes selecting the driver based on a determination of whether the driver's route includes the third location.

9. The method according to claim 8, further comprising: The driver is selected based on the driver's route to estimate the time required for the driver to reach the third location, and based on whether the estimated time exceeds a threshold.

10. A system for determining a requesting driver, comprising: At least one processor; And at least one memory, including computer program code; The at least one memory and the computer program code are configured, together with the at least one processor, to enable the system to perform at least the following operations: A second location adjacent to the first location is determined based on a search starting from the road closest to the first location, which is indicated in the request to the driver; as well as The driver making the request is determined based on whether the driver is en route to the second location.

11. The system according to claim 10, wherein, Determining the driver of the request further includes: determining a route associated with an edge branching from the node representing the second location in an edge-based road graph, the edge representing the road closest to the second location; and identifying the driver associated with the route.

12. The system of claim 11 is further configured to: determine the route based on a mapping that associates each edge of the edge-based road graph with routes stored in a database.

13. The system of claim 11 is further configured to: determine whether to select the driver for the request based on the driver's attributes, said attributes being one of: distance from the first location, distance from the second location, estimated time to reach the second location, or the driver's preference.

14. The system according to claim 10, wherein, Determining the second location further includes: in an edge-based road map, identifying another node adjacent to the node representing the first location, the other node representing the second location, and determining whether the driver's route includes the road.

15. The system according to claim 14, wherein, Determining the second position further includes performing the search, which begins with an edge branching off from the node representing the first position and ends at the node or edge based on a threshold.

16. The system of claim 10 is further configured to: estimate the time required for the driver to reach the first location based on the driver's route, and select the driver based on a determination that the estimated time exceeds a threshold.

17. The system according to claim 10, wherein, The request also indicates a third location, and the system is further configured to select the driver based on whether the driver's route includes the third location.

18. The system of claim 17 is further configured to: estimate the time required for the driver to reach the third location based on the driver's route, and select the driver based on a determination that the estimated time exceeds a threshold.

Images