Method and system for determining a driver for a request

Abstract

The present disclosure provides methods and systems for determining a driver for a request. In some examples, there is provided a method comprising: determining, by a processor, a second location that is within proximity from a first location based on a search that starts from a road that is nearest to the first location, the first location being indicated in a request for a driver; and determining, by the processor, a driver for the request based on whether the driver is on the way to the second location.

Description

Method and System for Determining a Driver for a RequestFIELD OF INVENTION

[0001] 1. The present disclosure relates broadly, but not exclusively, to methods and systems for determining a driver for a request.BACKGROUND

[0002] 2. Ride-hailing and delivery platforms often face the challenge of finding a suitable driver to handle a request for a driver. For example, a process for assigning orders to drivers within an area typically involves two steps: first, filtering and selecting a limited pool of driver candidates within the area; and second, utilizing Vehicle Routing Problem (VRP) algorithms to identify an optimal driver, for example based on constraints such as an Estimated Time of Arrival (ETA) to a location.

[0003] 3. At present, the standard candidate selection method is static, and typically involves capturing a static snapshot of driver statuses at a specific moment and then applying radius-based filters to identify drivers in proximity to an order or pickup location that is indicated in a request for a driver. Various vehicle types and business constraints are considered subsequently, all based on this static snapshot. This implementation enables in-transit batching e.g., allocation of requests to drivers already in transit, for example enabling a driver who may be in transit for a delivery or ride request to be selected as a potential candidate for handling another request.

[0004] 4. However, this conventional static candidate selection method has two main drawbacks. Firstly, it is often constrained by the number of driver candidates, because the static snapshot is unable to capture any potential drivers who are located outside the area covered by the static snapshot. This significantly  reduces the efficiency of in-transit batching. Secondly, it includes numerous inefficient drivers who may be passing by but have subsequent pickups that are located far away from the location indicated in the request for a driver, resulting in increased yet unproductive workload for the drivers who may be selected to handle the request. Once again, this may also impact the efficiency of in-transit batching as more requests may be cancelled or rejected by a selected driver. Furthermore, the static snapshot method is complicated and resource-intensive in execution due to numerous configurations and factors to consider, for example managing the static snapshot size based on varying vehicle types, environmental factors such as traffic or weather, and other similar factors.

[0005] 5. A need therefore exists to provide methods and systems that seek to overcome or at least minimize the above mentioned challenges.SUMMARY

[0006] 6. According to a first aspect of the present disclosure, there is provided a method for determining a driver for a request, comprising: determining, by a processor, a second location that is within proximity from a first location based on a search that starts from a road that is nearest to the first location, the first location being indicated in a request for a driver; and determining, by the processor, a driver for the request based on whether the driver is on the way to the second location.

[0007] 7. According to a second aspect of the present disclosure, there is provided a system for determining a driver for a request, comprising: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the system at least to: determine a second location that is within proximity from a first location based on a search that starts from a road that is nearest to the first location, the first location being indicated in a request for a driver; and determine a driver for the request based on whether the driver is on the way to the second location.BRIEF DESCRIPTION OF THE DRAWINGS

[0008] 8. Embodiments and implementations are provided by way of example only, and will be better understood and readily apparent to one of ordinary skill in the art from the following written description, read in conjunction with the drawings, in which:

[0009] 9. Fig. 1 illustrates a system for determining a driver for a request according to various embodiments of the present disclosure.

[0010] 10. Fig. 2 is a schematic diagram of a determination server, according to various embodiments of the present disclosure.

[0011] 11. Fig. 3 depicts an exemplary illustration for determining a driver for a request according to various embodiments of the present disclosure.

[0012] 12. Fig. 4A depicts an exemplary illustration of an edged-based road graph according to various embodiments of the present disclosure.

[0013] 13. Fig. 4B depicts an exemplary illustration of an inverted index according to various embodiments of the present disclosure.

[0014] 14. Fig. 4C depicts an exemplary illustration of a Location Based Service (LBS) according to various embodiments of the present disclosure.

[0015] 15. Fig. 4D depicts an exemplary flowchart for determining a driver for a request according to various embodiments of the present disclosure.

[0016] 16. Fig. 5 illustrates an example flow diagram for determining a driver for a request according to various embodiments.

[0017] 17. Fig. 6 is a schematic block diagram of a general purpose computer system upon which the determination server of Fig. 2 can be practiced.

[0018] 18. Fig. 7 is a schematic block diagram of a general purpose computer system upon which a combined transaction processing and determination server of Fig. 1 can be practiced.

[0019] 19. Fig. 8 shows an example of a computing device to realize the transaction processing server shown in Fig. 1.

[0020] 20. Fig. 9 shows an example of a computing device to realize the determination server shown in Fig. 1.

[0021] 21. Fig. 10 shows an example of a computing device to realize a combined transaction processing and determination server shown in Fig. 1.

[0022] 22. Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been depicted to scale. For example, the dimensions of some of the elements in the illustrations, block diagrams or flowcharts may be exaggerated in respect to other elements to help to improve understanding of the present embodiments.DETAILED DESCRIPTION

[0023] Terms Description

[0024] 23. A platform refers to a set of technologies that is used as a base for facilitating exchanges between two or more interdependent servers, entities and / or devices, for example between a requestor device (e.g., associated with a requestor of a product or service) and a provider device (e.g., associated with a provider of the product or service) . For example, a platform may offer a service offered by a provider such as a ride, delivery, online shopping, insurance, and other similar services to a requestor. A requestor can typically access the platform via a website, an application, or other similar methods using the requestor device. The provider device may be associated with a provider who may provide a ride or delivery that is requested by a requestor. For example, a request from a requestor device may be a request for a driver to provide a ride, a delivery service or other services such as cleaning, repair, plumbing, renovation, medical emergency, and other similar services. In the present disclosure, the requestor  device and the provider device may be referred to herein as a user device, wherein a user associated with the user device may be a requestor or a provider.

[0025] 24. A location may be a merchant outlet or store, a point of interest (POI) , a landmark, a pick-up point, a drop-off point, or other similar place that a driver may be requested to pick up a passenger, drop off a passenger, deliver something, or perform other similar services. Based on a first location indicated in a request (e.g., comprising location information such as an identifier, an address, global positioning system (GPS) information, latitudinal and longitudinal coordinates, geohash information, or other similar information associated with the first location) , a search may be performed by a location based service (LBS) to determine a second location that is within proximity from the first location. The LBS may be any service (e.g., for deliveries, ride-hailing, and other similar services) that performs a search based on location information relating to a user, for example based on a requestor’s or provider’s real-time location, GPS information, latitudinal and longitudinal coordinates, geohash information, or other similar information. In an implementation, the second location may be located within a specified distance from the first location. In an implementation, the second location may be located within a distance from the first location such that it takes less than a specified amount of time for a driver to reach the first location from the second location. In an implementation, the distance and / or the amount of time may be determined based on the type of request (e.g., whether it is a delivery request, a ride request, or a request for other similar services) , weather condition (e.g., the distance and / or amount of time may be adjusted based on whether it is raining or not) , traffic (e.g., the distance and / or amount of time may be adjusted based on an intensity of traffic around the first and second location) , type of area around the first and / or second location (e.g., the distance and / or amount of time may be adjusted based on whether it is an urban or rural area, or based on a density of buildings around the area, or other similar factors) , or other similar factors. The first and second locations may each be represented as, for example, a node in an edge-based road graph, in which each edge in the edge-based road graph represents a road and conveys information regarding a route of a driver who is or will be travelling along the road represented by the edge. The node representing the second location may be one that is within proximity from the node representing the first location. For example, the node  representing the second location may be located within one to a maximum number of edges from the node representing the first location. In an implementation, the maximum number of edges may be determined based on the type of request (e.g., whether it is a delivery request, a ride request, or a request for other similar services) , weather condition (e.g., the maximum number of edges may be adjusted based on whether it is raining or not) , traffic (e.g., the maximum number of edges may be adjusted based on an intensity of traffic around the first and second location) , type of area around the first and / or second location (e.g., the maximum number of edges may be adjusted based on whether it is an urban or rural area, or based on a density of buildings around the area, or other similar factors) , or other similar factors.

[0026] 25. A road refers to a stretch of surface built for an entity such as a person, a vehicle or other similar entity to travel along, for example to reach a location such as the first or second location. For example, an edge that branches from the first location represents a road that is nearest to the first location and may be used to reach the first location. In an implementation, the road that is nearest to the first location may be a road that leads to the first location, a road that runs beside the first location, a road that is used to arrive at the first location, or other similar road. The search that is performed to determine the second location may be one that starts from a road that is nearest to the first location. For example, in the edge-based road graph, the search may be a breadth first search (BFS) that is centered at the node representing the first location, and starts from an edge that branches from the node representing the first location (e.g., the edge representing a road that is nearest to the first location) . The search may end at an edge or a 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 configured to end after traversing a maximum distance from the first location, or other similar configuration) . It will be appreciated that there can be a plurality of nodes (each representing a different location) and a plurality of edges (each representing a different road) in the edge-based road graph. Further, it will be appreciated that other representations of roads and locations instead of an edge-based road graph are also possible (e.g., a neural network or other similar structure) .

[0027] 26. Based on the search, a driver for handling the request may be determined based on whether the driver is on the way to the second location. For example, each edge of the edge-based road graph may be mapped to information relating to a route of a driver who is or will be travelling along a road represented by the edge. The information may comprise a next step that is to be taken by a driver associated with the route, an identifier for the driver associated with the route, an attribute of the driver (e.g., the attribute being one of a distance from the first location, a distance from the second location, an estimated time of arrival at the second location, a status of the driver, preference of the driver, or other similar attribute) , a type of vehicle used by the driver for the route, and other similar information relating to the route. The information may be stored in a database.

[0028] 27. The mapping of each edge of the edge-based road graph to information relating to a route of a driver may be implemented, for example, in a form of an inverse index or other similar method that associates an edge with the information relating to a route of a driver (e.g., the route including the road that is represented by the edge) that is stored in the database. When more than one driver are identified for the request, selection may be performed by filtering the drivers based on the attribute of each driver. For example, a threshold for an estimated time of arrival at the second location may be set and the identified drivers may be filtered based on this threshold. In another implementation, a time of arrival of each driver at the first location may be estimated and used for filtering the identified drivers (e.g., one or more drivers that are estimated to arrive at the first location within 5 minutes may be selected) .

[0029] 28. In another implementation, the request may indicate a third location, and a time of arrival of each driver at the third location may be estimated (or an ability of the driver to travel to the third location may be assessed based on the route of the driver) and used for filtering the identified drivers. The third location may be a location at which an item relating to the request (e.g., an item that is to be picked up at the first location) is to be delivered, or at which a passenger relating to the request (e.g., a passenger who is to be picked up at the first location) is to be dropped off, or at which other similar service is required.

[0030] 29. In at least some embodiments, a user may be any suitable type of entity, which may include a person making a request (e.g., a request for a driver) , a consumer looking to purchase a product or service via a transaction processing server, a seller or merchant looking to sell a product or service via the transaction processing server, a motorcycle driver or pillion rider in a case of the user looking to book or provide a motorcycle ride via the transaction processing server, a car driver or passenger in a case of the user looking to book or provide a car ride via the transaction processing server, and other similar entity. A user who is registered to the transaction processing server will be called a registered user. A user who is not registered to the transaction processing server will be called a non-registered user. The term user will be used to collectively refer to both registered and non-registered users. A user may interchangeably be referred to as a requestor (e.g., a person who requests for a product or service) or a provider (e.g., a person who provides the requested product or service to the requestor) .

[0031] 30. In at least some embodiments, a determination server is a server that hosts software application programs for determining a driver for a request. The determination server may be implemented as shown in schematic diagram 200 of Fig. 2 for determining a driver for a request.

[0032] 31. In at least some embodiments, a transaction processing server is a server that hosts software application programs for processing payment transactions for, for example, a request for a service, delivery, a travel-coordination request, purchasing of a good or service by a user, and other similar services. The transaction processing server communicates with any other servers (e.g., a determination server) concerning processing payment transactions relating to the purchasing of the good or service, such as a request for a service (which may be referred to as a request, for example for a ride, delivery, or other similar service that requires a provider to locate and arrive at a location as indicated in the request) . For example, data relating to a request (e.g., information relating to a location at which a driver is required, date, time, and other similar data) may be provided to the determination server, which may then be processed to determine a driver for the request. The transaction processing server may use a variety of  different protocols and procedures in order to process the payment and / or driver requests.

[0033] 32. Transactions that may be performed via a transaction processing server include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Transaction processing servers may be configured to process transactions via cash-substitutes, which may include payment cards, letters of credit, checks, payment accounts, etc.

[0034] 33. In at least some embodiments, the transaction processing server is usually managed by a service provider that may be an entity (e.g., a company or organization) which operates to process transaction requests and / or driver requests e.g., pair a driver to a requestor of the driver request. The transaction processing server may include one or more computing devices that are used for processing transaction requests and / or driver requests.

[0035] 34. In at least some embodiments, a transaction account is an account of a user who is registered at a transaction processing server. The user can be a customer, a merchant providing a product for sale on a platform and / or for onboarding the platform, a ride or delivery provider (e.g., a driver) , or any third parties (e.g., a courier) who want to use the transaction processing server. In certain circumstances, the transaction account is not required to use the transaction processing server. A transaction account includes details (e.g., name, address, vehicle, face image, etc. ) of a user. The transaction processing server manages the transaction.

[0036] 35. Embodiments will be described, by way of example only, with reference to the drawings. Like reference numerals and characters in the drawings refer to like elements or equivalents.

[0037] 36. Some portions of the description which follows are explicitly or implicitly presented in terms of algorithms and functional or symbolic representations of operations on data within a computer memory. These algorithmic descriptions and functional or symbolic representations are the means used by those skilled in the data processing arts to convey most effectively the substance of their work  to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities, such as electrical, magnetic or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated.

[0038] 37. Unless specifically stated otherwise, and as apparent from the following, it will be appreciated that throughout the present specification, discussions utilizing terms such as “identifying” , “detecting” , “recommending” , “determining” , “associating” , “extracting” , “calculating” , “processing” , “storing” , “indicating” , “comparing” , “providing” , “dividing” , or the like, refer to the action and processes of a computer system, or similar electronic device, that 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 devices.

[0039] 38. In addition, the present specification also implicitly discloses a computer program, in that it would be apparent to the person skilled in the art that the individual steps of the method described herein may be put into effect by computer code. The computer program is not intended to be limited to any particular programming language and implementation thereof. It will be appreciated that a variety of programming languages and coding thereof may be used to implement the teachings of the disclosure contained herein. Moreover, the computer program is not intended to be limited to any particular control flow. There are many other variants of the computer program, which can use different control flows without departing from the scope of the specification.

[0040] 39. Furthermore, one or more of the steps of the computer program may be performed in parallel rather than sequentially. Such a computer program may be stored on any computer readable medium. The computer readable medium may include storage devices such as magnetic or optical disks, memory chips, or other storage devices suitable for interfacing with a computer. The computer readable medium may also include a hard-wired medium such as exemplified in the Internet system, or wireless medium such as exemplified in the GSM mobile telephone system. The computer program when loaded and executed on such a  computer effectively results in an apparatus that implements the steps of the preferred method.

[0041] 40. In the present disclosure, a system is proposed for determining a driver for a request, to address the issues of having a limited number of driver candidates to handle a request, and inclusion of inefficient drivers who may happen to pass by a location indicated in the request but are actually unable to handle the request because they are travelling to a destination that is far from the location. For example, a second location that is within proximity from a first location may be determined based on a search that starts from a road that is nearest to the first location, the first location being indicated in a request for a driver. A driver for the request may then be determined based on whether the driver is on the way to the second location. Advantageously, this expands the pool of potential drivers that can be selected for handling a request by incorporating "nearby future" drivers, considering both time and route of a driver rather than solely relying on a static snapshot of driver statuses as implemented by existing methods. As a result of such implementation, only drivers within a configurable radius were deemed eligible. However, with the new proposed system and method of the present disclosure, drivers who are not currently within a radius (of the static snapshot) but are on the way to the second location, and will be near the first location in the near future are also considered. This approach ensures that drivers who can efficiently reach the first location are included, instead of merely including inefficient drivers who may be passing by but have subsequent pickups that are located far away from the location indicated in the request for a driver, as currently implemented in existing methods. Furthermore, implementation of an edge-based graph and mapping application for representing the locations, roads and routes associated with the roads advantageously requires less configuration and resources compared to the static snapshot approach used in the existing methods. For example, for the existing radius-based method, it is necessary to hold many distance configurations (e.g., different values for different vehicle types) . On the other hand, for the present solution, it is possible to use only a single threshold for all vehicle types for determining a driver for a request, resulting is reduced overhead, configuration requirements and cost.

[0042] 41. Fig. 1 illustrates a block diagram of an example system 100 for determining a driver for a request. In some embodiments, the system 100 enables a payment transaction for a good or service, and / or a request e.g., for a ride, or delivery of a physical item (e.g., one or more food items or a parcel) between a requestor (e.g., a user associated with a request) and a provider (e.g., a driver handling the request) , in which a second location within proximity from a first location may be determined based on a search that starts from a road that is nearest to the first location, the first location being indicated in the request, and a driver for handling the request may be determined based on whether the driver is on the way to the second location.

[0043] 42. The system 100 comprises a requestor 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.

[0044] 43. The requestor device 102 is in communication with a provider device 104 via a connection 112, and may be associated with a user. The connection 112 may be wireless (e.g., via NFC communication, Bluetooth, etc. ) or over a network (e.g., the Internet) . The requestor device 102 is also in communication with the determination server 140 via a connection 121, wherein the determination server 140 may be configured to receive information relating to a request (e.g., a request for a service such as a delivery or a ride at a first location, the information including location information relating to the first location, and other similar information) from the requestor device 102. The determination server 140 may also be configured to receive information relating to a third location (e.g., a request for a service such as a delivery or a ride from the first location to the third location, the information including location information relating to the first location and the third location, and other similar information) from the requestor device 102. The location information relating to the first and third location may comprise an identifier, an address, GPS information, latitudinal and longitudinal coordinates, geohash information, or other similar information associated with the first and third location respectively. The requestor device 102 may be configured to communicate with the provider device 104 (e.g., communication relating to the request with the provider device 104) . The connection 121 may be via a network (e.g., the Internet) . The requestor device 102 may also be  connected to a cloud that facilitates the system 100 for determining a driver for a request. For example, the requestor device 102 can send a signal or data to the cloud directly via a wireless connection (e.g., via NFC communication, Bluetooth, etc. ) or over a network (e.g., the Internet) . It will be appreciated that there can be a plurality of requestor devices 102 such that each requestor device 102 is associated with a respective user.

[0045] 44. The provider device 104 is in communication with the requestor device 102 as described above, usually via the transaction processing server 108, and may be associated with a provider of a service or delivery (e.g., a provider responding to a request for a service such as, for example, a delivery or a ride to a location) . The provider device 104 is, in turn, in communication with an acquirer server 106 via a connection 114. The provider device 104 is also in communication with the determination server 140 via a connection 123, wherein the determination server 140 may be configured to receive information relating to a location of the provider device 104 (e.g., an identifier, an address, GPS information, latitudinal and longitudinal coordinates, geohash information, or other similar information associated with the location) , and other similar information from the provider device 104. In an implementation, the information relating to the location of the provider device 104 may be used by the determination server 140 to estimate an expected time of arrival of the driver associated with the provider device 104 at the first, second or third location. When a driver is determined for handling the request, the provider device 104 associated with the driver may be configured to communicate with the requestor device 102 (e.g., communication relating to the request with the requestor device 102) . The connections 114 and 123 may be via a network (e.g., the Internet) . The provider device 104 may also be connected to a cloud that facilitates the system 100 for determining a driver for a request. For example, the provider device 104 can send a signal or data to the cloud directly via a wireless connection (e.g., via NFC communication, Bluetooth, etc. ) or over a network (e.g., the Internet) . It will be appreciated that there can be a plurality of provider devices 104 such that each provider device 104 is associated with a respective user.

[0046] 45. The acquirer server 106, in turn, is in communication with the transaction processing server 108 via a connection 116. The transaction processing server  108, in turn, is in communication with an issuer server 110 via a connection 118. The connections 116 and 118 may be via a network (e.g., the Internet) .

[0047] 46. The transaction processing server 108 is further in communication with the determination server 140 via a connection 120. The connection 120 may be over a network (e.g., a local area network, a wide area network, the Internet, etc. ) . In one arrangement, the transaction processing server 108 and the determination server 140 are combined and the connection 120 may be an interconnected bus.

[0048] 47. The determination server 140, in turn, is in communication with the database 150 via respective connection 122. The connection 122 may be over a network (e.g., the Internet) . The determination server 140 may also be connected to a cloud that facilitates the system 100 for determining a driver for a request. For example, the determination server 140 can send a signal or data to the cloud directly via a wireless connection (e.g., via NFC communication, Bluetooth, etc. ) or over a network (e.g., the Internet) .

[0049] 48. The database 150 may comprise data that is utilized by the determination server 140 for determining a driver for a request. For example, data relating to an attribute of the driver (the attribute being a distance from the first location, a distance from the second location, an estimated time of arrival at the second location, a preference of the driver, or other similar information) , an edge-based road graph, a mapping associating each edge of the edge-based road graph with a route of a driver, and other information and / or data required for determining a driver for a request may be processed and stored in the database 150. In an implementation, the database 150 may be combined with the determination server 140. In an example, the database 150 may be managed by an external entity.

[0050] 49. The determination server 140 may be configured to determine a second location that is within proximity from a first location based on a search that starts from a road that is nearest to the first location, the first location being indicated in a request for a driver. The determination server 140 may be further configured to determine a driver for the request based on whether the driver is on the way to the second location. In an implementation, determining the driver for the request  may further comprise determining a route associated with an edge that branches from a node representing the second location in an edge-based road graph, the edge representing a road that is nearest to the second location; and identifying a driver associated with the route. In an implementation, the determination server 140 may determine the route based on a mapping that associates each edge of the edge-based road graph with a route stored in a database. In an implementation, the determination server 140 may determine whether to select the driver for the request based on an attribute of the driver, the attribute being one of a distance from the first location, a distance from the second location, an estimated time of arrival at the second location, or a preference of the driver.

[0051] 50. In an implementation, determining the second location may further comprise identifying another node that is within proximity from a node representing the first location in an edge-based road graph, the another node representing the second location. In an implementation, determining the second location may further comprise performing the search that starts from an edge that branches from the node representing the first location and ends at a node or edge according to a threshold.

[0052] 51. In an implementation, the determination server 140 may estimate a time required for the driver to arrive at the first location based on a route of the driver, and select the driver based on a determination whether the estimated time exceeds a threshold. In an implementation, the request may further indicate a third location, and the determination server 140 may select the driver based on a determination whether the route of the driver includes the third location. In an implementation, the request may further indicate a third location, and the determination server 140 may estimate a time required for the driver to arrive at the third location based on a route of the driver, and select the driver based on a determination whether the estimated time exceeds a threshold. Advantageously, it is possible to increase the number of drivers that can be selected to handle a request based on whether the driver is heading the third location or whether the driver is able to reach the third location within a time period. In an implementation, the determination server 140 may be further configured to assess whether a route associated with an edge includes the second location, and select a driver associated with the route for handling the request based on the assessment.  Advantageously, it is possible to increase the number of drivers that can be selected to handle a request based on whether the driver is heading to the second location or whether the driver is able to reach the second location within a time period. The above implementations are further explained in Figs. 3 and 4A-4D.

[0053] 52. In an implementation, there may be more than one databases, in which the determination server 140 may be configured to determine which database to use for each step during the process of determining a driver for a request. Alternatively, one or more modules may store the above-mentioned data instead of the database 150, wherein the module may be integrated as part of the determination server 140 or external from the determination server 140.

[0054] 53. In the illustrative embodiment, each of the devices 102, 104, and the 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 APIs may be part of a user interface that may include graphical user interfaces (GUIs) , Web-based interfaces, programmatic interfaces such as application programming interfaces (APIs) and / or sets of remote procedure calls (RPCs) corresponding to interface elements, messaging interfaces in which the interface elements correspond to messages of a communication protocol, and / or suitable combinations thereof. For example, it is possible for the requestor device 102 to send data relating to a request such as information relating to a location at which a driver is required, date, time, and other similar data, and for the provider device 104 to send data relating to a location of an associated provider, in response to an enquiry shown on the GUI running on the respective API.

[0055] 54. Use of the term ‘server’ herein can mean a single computing device or a plurality of interconnected computing devices which operate together to perform a particular function. That is, the server may be contained within a single hardware unit or be distributed among several or many different hardware units.

[0056] 55. The determination server 140 is associated with an entity (e.g., a company or organization or moderator of the service) . In one arrangement, the determination server 140 is owned and operated by the entity operating the transaction processing server 108. In such an arrangement, the determination server 140 may be implemented as a part (e.g., a computer program module, a computing device, etc. ) of the transaction processing server 108.

[0057] 56. The transaction processing server 108 may also be configured to manage the registration of users. A registered user has a transaction account (see the discussion above) which includes details of the user. The registration step is called on-boarding. A user may use either the requestor device 102 or the provider device 104 to perform on-boarding to the transaction processing server 108.

[0058] 57. It may not be necessary to have a transaction account at the transaction processing server 108 to access the functionalities of the transaction processing server 108. However, there are functions that are available to a registered user. These additional functions will be discussed below.

[0059] 58. The on-boarding process for a user is performed by the user through one of the requestor device 102 or the provider device 104. In one arrangement, the user downloads an app (which includes the API to interact with the transaction processing server 108) to the requestor device 102 or the provider device 104. In another arrangement, the user accesses a website (which includes the API to interact with the transaction processing server 108) on the requestor device 102 or the provider device 104. The user is then able to interact with the determination server 140. The user may be a requestor or a provider associated with the requestor device 102 or the provider device 104, respectively.

[0060] 59. Details of the registration may include, for example, name of the user, address of the user, emergency contact, blood type or other healthcare information, next-of-kin contact, permissions to retrieve data and information from the requestor device 102 and / or the provider device 104 for determining a driver for a request, such as permission to retrieve location and status information, and other similar data and information from the requestor device 102 and / or the provider device  104. Alternatively, another device (e.g., a mobile device, a laptop computer, a personal digital assistant computer (PDA) , a mobile computer, a tablet computer, or other similar device) may be selected instead of the requestor device 102 and / or the provider device 104 for retrieving the data. Once on-boarded, the user would have a transaction account that stores all the details.

[0061] 60. The requestor device 102 is associated with a user (or requestor) who is a party to a transaction that occurs between the requestor device 102 and the provider device 104, or between the requestor device 102 and the determination server 140. The requestor 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, and the like. The requestor device 102 may be associated with a user who initiates a request for a driver.

[0062] 61. The requestor device 102 includes transaction credentials (e.g., a payment account) of a requestor to enable the requestor device 102 to be a party to a payment transaction. If the requestor has a transaction account, the transaction account may also be included (e.g., stored) in the requestor device 102. For example, a mobile device (which is a requestor device 102) may have the transaction account of the customer stored in the mobile device.

[0063] 62. In one example arrangement, the requestor device 102 is a computing device in a watch or similar wearable and is fitted with a wireless communications interface (e.g., a NFC interface) . The requestor device 102 can then electronically communicate with the provider device 104 regarding a request (e.g., for a delivery, a ride, or other similar service) . The user uses the watch or similar wearable to make the request by pressing a button on the watch or wearable.

[0064] 63. The provider device 104 is associated with a provider who is also a party to the request (e.g., for a delivery, a ride, or other similar service) that occurs between the requestor device 102 and the provider device 104. The provider device 104 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, and the like. The provider device 104 may be associated with a provider of a ride or delivery (e.g., a provider responding to the request) .

[0065] 64. Hereinafter, the term “provider” refers to a service provider and any third party associated with providing a product or service for purchase, or a travel or ride or delivery service via the provider device 104. Therefore, the transaction account of a provider refers to both the transaction account of a provider and the transaction account of a third party (e.g., a driver, travel co-ordinator or merchant) associated with the provider.

[0066] 65. If the provider has a transaction account, the transaction account may also be included (e.g., stored) in the provider device 104. For example, a mobile device (which is a provider device 104) may have the transaction account of the provider stored in the mobile device.

[0067] 66. In one example arrangement, the provider device 104 is a computing device in a watch or similar wearable and is fitted with a wireless communications interface (e.g., a NFC interface) . The provider device 104 can then electronically communicate with the requestor to make the request by pressing a button on the watch or wearable.

[0068] 67. The acquirer server 106 is associated with an acquirer who may be an entity (e.g., a company or organization) which issues (e.g., establishes, manages, administers) a payment account (e.g., a financial bank account) of a merchant. Examples of the acquirer include a bank and / or other financial institution. As discussed above, the acquirer server 106 may include one or more computing devices that are used to establish communication with another server (e.g., the transaction processing server 108) by exchanging messages with and / or passing information to the other server. The acquirer server 106 forwards the payment transaction relating to a transaction request or a request for a delivery or other similar service to the transaction processing server 108.

[0069] 68. The transaction processing server 108 is configured to process processes relating to a transaction by, for example, forwarding data and information  associated with the transaction to the other servers in the system 100 such as the determination server 140. In an example, the transaction processing server 108 may, instead of the requestor device 102 or provider device 104, transmit data relating to a request (e.g., location information relating to a first location, location information relating to a third location, date, time, and other similar data) to the determination server 140 for determining a second location within proximity from the first location. The transaction processing server 108 may use a variety of different protocols and procedures in order to process the payment and / or requests. It will be appreciated that payment for a transaction may be made via a variety of methods such as credit cards, debit cards, digital wallets, buy-first pay-later schemes, and other similar payment methods.

[0070] 69. The issuer server 110 is associated with an issuer and may include one or more computing devices that are used to perform a payment transaction. The issuer may be an entity (e.g., a company or organization) which issues (e.g., establishes, manages, administers) a transaction credential or a payment account (e.g., a financial bank account) associated with the owner of the requestor device 102. As discussed above, the issuer server 110 may include one or more computing devices that are used to establish communication with another server (e.g., the transaction processing server 108) by exchanging messages with and / or passing information to the other server.

[0071] 70. The database 150 is a database or server associated with an entity (e.g., a company or organization) which manages (e.g., establishes, administers) data relating to users, transactions, products, services, and other similar data, for example relating to the entity. In an arrangement, the database 150 may comprise data that is utilized by the determination server 140 for determining a driver for a request. For example, data relating to an attribute of the driver (the attribute being a distance from the first location, a distance from the second location, an estimated time of arrival at the second location, a preference of the driver, or other similar information) , an edge-based road graph, a mapping associating each edge of the edge-based road graph with a route of a driver, and other information and / or data required for determining a driver for a request may be processed and stored in the database 150. In an implementation, the  database 150 may be combined with the determination server 140. In an example, the database 150 may be managed by an external entity.

[0072] 71. Advantageously, the system 100 expands the driver candidate pool by incorporating "nearby future" drivers, considering both time and route of a driver rather than solely relying on a static snapshot of driver statuses as implemented by existing methods. As a result of such implementation, only drivers within a configurable radius were deemed eligible. However, with the new proposed system and method of the present disclosure, drivers who are not currently within a radius (of the static snapshot) but are on the way to the second location, and will be near the first location in the near future are also considered. This approach ensures that drivers who can efficiently reach the first location are included, reducing time required to reach a location at which a driver is required and improving service efficiency. Furthermore, implementation of an edge-based graph and mapping application for representing the locations, roads and routes associated with the roads advantageously requires less configuration and resources compared to the static snapshot approach used in the existing methods.

[0073] 72. Fig. 2 illustrates a schematic diagram of an example determination server 140 according to various embodiments. The determination server 140 may comprise a data module 260 configured to receive data and information from the requestor device 102, provider device 104, transaction processing server 108, database 150, a cloud and other sources of information to determine a driver for a request by the determination server 140. For example, the data module 260 may be configured to receive data and information required for: determining a second location that is within proximity from a first location based on a search that starts from a road that is nearest to the first location, the first location being indicated in a request for a driver; determining a driver for the request based on whether the driver is on the way to the second location; determining a route associated with an edge that branches from a node representing the second location in an edge-based road graph, the edge representing a road that is nearest to the second location, and identifying a driver associated with the route; determining the route based on a mapping that associates each edge of the edge-based road graph with a route stored in a database; determining whether to select the driver for the  request based on an attribute of the driver, the attribute being one of a distance from the first location, a distance from the second location, an estimated time of arrival at the second location, or a preference of the driver; identifying another node that is within proximity from a node representing the first location in an edge-based road graph, the another node representing the second location; performing the search that starts from an edge that branches from the node representing the first location and ends at a node or edge according to a threshold; estimating a time required for the driver to arrive at the first location based on a route of the driver, and selecting the driver based on a determination whether the estimated time exceeds a threshold; wherein the request may further indicate a third location, selecting the driver based on a determination whether the route of the driver includes the third location, or estimating a time required for the driver to arrive at the third location based on a route of the driver, and selecting the driver based on a determination whether the estimated time exceeds a threshold; assessing whether a route associated with an edge includes the second location, and selecting a driver associated with the route for handling the request based on the assessment; and other similar processes from the requestor device 102, the provider device 104, transaction processing server 108, database 150, and / or other sources of information. The data module 260 may be further configured to send information relating to data retrieved in response to a request to the requestor device 102, the provider device 104, the transaction processing server 108, or other destinations where the information is required.

[0074] 73. The determination server 140 may comprise a search module 262 that is configured for determining a second location that is within proximity from a first location based on a search that starts from a road that is nearest to the first location, the first location being indicated in a request for a driver. In an implementation, the search module 262 may be configured to identify another node that is within proximity from a node representing the first location in an edge-based road graph, the another node representing the second location. In an implementation, the search module 262 may be configured to perform the search that starts from an edge that branches from the node representing the first location and ends at a node or edge according to a threshold. The above process is further explained in Figs. 4A-4D.

[0075] 74. The determination server 140 may also comprise a determination module 264 that is configured for determining a driver for the request based on whether the driver is on the way to the second location (e.g., determined by the search module 262) . In an implementation, the determination module 264 may be configured to determine a route associated with an edge that branches from a node representing the second location in an edge-based road graph, the edge representing a road that is nearest to the second location; and identify a driver associated with the route. In an implementation, the determination module 264 may be configured to determine the route based on a mapping associating each edge of the edge-based road graph with a route stored in a database. In an implementation, the determination module 264 may be configured to determine whether to select the driver for the request based on an attribute of the driver, the attribute being one of a distance from the first location, a distance from the second location, an estimated time of arrival at the second location, or a preference of the driver. In an implementation, the determination module 264 may be configured to estimate a time required for the driver to arrive at the first location based on a route of the driver, and select the driver based on a determination whether the estimated time exceeds a threshold. In an implementation wherein the request further indicates a third location, the determination module 264 may be configured to select the driver based on a determination whether the route of the driver includes the third location, or estimate a time required for the driver to arrive at the third location based on a route of the driver, and selecting the driver based on a determination whether the estimated time exceeds a threshold. In an implementation wherein the request further indicates a third location, the determination module 264 may be configured to estimate a time required for the driver to arrive at the third location based on a route of the driver, and select the driver based on a determination whether the estimated time exceeds a threshold. Advantageously, it is possible to increase the number of drivers that can be selected to handle a request based on whether the driver is heading to the third location or whether the driver is able to reach the third location within a time period. In an implementation, the determination module 264 may be further configured to assess whether a route associated with an edge includes the second location, and select a driver associated with the route for handling the request based on the assessment.  Advantageously, it is possible to increase the number of drivers that can be selected to handle a request based on whether the driver is heading to the second location or whether the driver is able to reach the second location within a time period. The above process is further explained in Figs. 3 and 4A-4D.

[0076] 75. Each of the data module 260, search module 262 and determination module 264 may further be in communication with a processing module (not shown) of the determination server 140, for example for coordination of respective tasks and functions during the process. The data module 260 may be further configured to communicate with and store data and information for each of the processing module, search module 262 and determination module 264. Alternatively, all the tasks and functions required for adaptively determining a driver for a request may be performed by a single processor of the determination server 140.

[0077] 76. Fig. 3 depicts an exemplary illustration 300 for determining a driver for a request according to various embodiments of the present disclosure. In illustration 300, the system is trying to assign an order with a Merchant A 304 as the pickup location (e.g., a first location indicated in a request associated with the order) , the static method according to existing methods would only consider Driver 1 308 which is on the way to a Merchant B 304 and is captured in a static snapshot with a radius 310. However, if the system recognizes that Driver 2 310 is on the way to a Merchant C 306, which is close to Merchant A 302 (e.g., within proximity from Merchant A 302, Driver 2 310 can also be included in the candidate pool of drivers who can be assigned to handle the request, despite not being within the radius 310 at that moment, thus expanding the driver candidate pool for handling the request.

[0078] 77. Thus, in the presently proposed solution, introduction of new driver candidates who were previously excluded due to proximity distance limitations are now possible. This increases the possibility of in-transit batching and yields a higher average in-transit batch quality. Further, it is possible to identify higher quality driver candidates by filtering drivers who may need to take a detour (thus wasting time) to reach the new order pickup location (e.g., the first location) . This substantially reduces workload for downstream processes with minimal impact on in-transit batching possibilities. Furthermore, the proposed solution requires less configuration and maintenance costs compared to existing solutions which may  require management of static snapshot radius, varying vehicle types, and environmental factors such as traffic, weather, and other similar factors.

[0079] 78. The present solution generally comprises the following steps. A pickup location of, for example, a delivery order, a passenger, or other similar entity may be identified from an order (e.g., a first location indicated in a request associated with the order may be identified) . Based on the first location, a second location within proximity from the first location may be determined. In an implementation, a location-based service (LBS) may be utilized to determine the second location (e.g., a nearby location such as a merchant establishment, a POI, a landmark, or other similar entities) within, for example, a predefined line or a distance from the first location. Accordingly, one or more second locations may be determined based on the search. Further, a route of a driver who are in-transit may be checked to see if the second location is part of the route. It will be appreciated that routes of one or more drivers may be checked. In an implementation, information relating to the route and the driver (e.g., a next step that is to be taken by a driver associated with the route, an identifier for the driver associated with the route, an attribute of the driver such as a distance from the first location, a distance from the second location, an estimated time of arrival at the second location, a status of the driver, preference of the driver, or other similar attribute, a type of vehicle used by the driver for the route, and other similar information relating to the route) may be checked to determine whether the driver is able to handle the request. In an implementation wherein a third location is indicated in the request (e.g., the third location being a drop-off location for an item, passenger or similar entity indicated in the request) , the driver may be selected for handling the request based on whether the route of the driver includes the third location. In an implementation, an estimated time for the driver to reach the third location may be used to determine whether to select the driver for handling the request. Advantageously, it is possible to increase the number of drivers that can be selected to handle a request based on whether the driver is heading the third location or whether the driver is able to reach the third location within a time period In an implementation, a route associated with an edge may be assessed whether it includes the second location, and a driver associated with the route may be selected for handling the request based on the assessment. Advantageously, it is possible to increase the number of drivers that can be  selected to handle a request based on whether the driver is heading to the second location or whether the driver is able to reach the second location within a time period.

[0080] 79. In an implementation, each location may be represented as a node and each road may be represented as an edge in an edge-based road graph. Referring to illustration 400 of Fig. 4A depicting an edge-based road graph, node 402 may represent the first location indicated in the request for a driver, and each of nodes 404, 406, 408, 410 and 412 may represent a second location that is within proximity from the first location. Each of edges 414, 416, 418, 420 and 422 represent a road. In particular, each of edges 414, 418 and 420 represent a road that is nearest to the first location. Further, each edge may be associated with a route of a driver who is or will be travelling along the road. Human figures 401, 403, 405, 407 and 409 represent a location (e.g., a current GPS location) of a driver 1, driver 2, driver 3, driver 4 and driver 5 respectively. For example, human figure 401 being located at edge 422 may indicate that the driver 1 is currently located on a road represented by the edge 422. Boxes 411, 413 and 415 represent a next step of a route of a driver. For example, box 411 represents a next step of a booking 1 handled by a driver 2 (e.g., a current location represented by human figure 403) in which the driver 2 has to drop off a passenger or a delivery (e.g., an item to be delivered) at, for example, a location represented by node 402. Further, box 413 represents a next step of a booking 1 handled by a driver 3 (e.g., a current location represented by human figure 405) in which the driver 3 has to pick up a passenger or a delivery at, for example, a location represented by node 402. Even further, box 415 represents a further step of the booking 1, in which the driver 3 has to drop off the passenger or the delivery at, for example, a location represented by node 408.

[0081] 80. The association between an edge and a route of a driver may be based on a mapping. In an implementation, the mapping may be based on an inverted index, for example as shown in inverted index 430 of Fig. 4B. For example, the inverted index 430 may indicate an association between edge 414 and a route of driver 2 who will be dropping off a passenger or a delivery for booking 1, an association between edge 420 and a route of driver 3 who will be picking up a passenger or  a delivery for a booking 2, and an association between edge 418 and the route of driver 3 who will be dropping off the passenger or delivery for booking 2. A search for a second location may be performed starting from a road that is nearest to the first location. In an implementation, the search may be a BFS centred on node 402 (representing the first location) and starting from one or more of edges 414, 418 and 420 that are nearest the node 402. The BFS may be configured to end at an edge or a 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 configured to end after traversing a maximum distance from the first location, or other similar configuration) . Based on the inverted index, each edge that is within proximity to a node representing a second location may be checked for an associated route of a driver to assess whether the driver may be selected for handling the request. Advantageously, through the implementation of the edge-based road graph and the inverted index, it is possible to efficiently check in-transit route plans of each driver who is or will be travelling on a given road, rather than naively traversing globally. It will be appreciated that the location of each driver (e.g., represented by human figures 401, 403, 405, 407 and 409 in figure 4A) may be updated at a certain frequency (e.g., a set duration of one or a few milliseconds, seconds, minutes, or other similar duration) , and steps of a route (e.g., boxes 411, 413 and 415 in figures 4A and 4B) may be added, updated or removed as a driver’s task change (e.g., a current booking is cancelled, and / or a new booking is received, or other similar circumstances) .

[0082] 81. Fig. 4C depicts an exemplary illustration of a Location Based Service (LBS) 440 according to various embodiments of the present disclosure. As shown above, each edge of the edge-based road graph of illustration 400 may be mapped to information relating to a route of a driver who is or will be travelling along a road represented by the edge. The information may comprise a next step that is to be taken by a driver associated with the route, an identifier for the driver associated with the route, an attribute of the driver (e.g., the attribute being one of a distance from the first location, a distance from the second location, an estimated time of arrival at the second location, a status of the driver, preference of the driver, or other similar attribute) , a type of vehicle used by the driver for the route, and  other similar information relating to the route. This information may be stored in a database.

[0083] 82. In an implementation, attributes of the driver may be passed to an access layer 442 of the LBS 440 service host. The access layer 442 may be configured to map a location attribute of a driver object to a road network (for example, {latitude, longitude} converted to {edgeID, percentage offset} ) . For properties that are not related to location information, the attributes may be sent directly to a next layer. The driver object may comprise two types of location attributes: GPS location and a driver plan (e.g., which consists of one or more ordered steps that a driver takes when handling a request) . The attributes may then be distributed to all hosts in the LBS 440 (e.g., via distribution layer 444) to update the memory storage in storage layer 448. The distribution layer 444 may be used to broadcast properties to all hosts. In addition, the LBS service may consist of one or more servers. In an implementation, the LBS service may comprise 10 servers, in which each server may only handle 1 / 10 of the property update requests, and the distribution layer of each server may broadcast the data of the current server to the other 9 servers and get the other 9 / 10 property updates from the other 9 servers. This advantageously enables each server to obtain 100%of the driver's latest attributes.

[0084] 83. In particular, information relating to a route of a driver (e.g., a next step in a route that may be taken by a driver) may be used to update the inverted index (e.g., inverted index 430) via index layer 446 of the LBS 440 service host. The index layer 446 may be configured to refresh the reverse index with the latest location property of the driver object. Using a location attribute of a driver (e.g., a driver's GPS location) , it is possible to build and update one or more indexes associated with a route of a driver (e.g., an Edge-Driver GPS index may be updated based on a driver’s GPS location, and using one or more steps in a driver plan of the driver, it is possible to build and update an Edge-Step index, and Edge-LastStep index associated with the driver) . It will be appreciated that other forms of handling the information relating to a route and a driver associated with the route may also be possible.

[0085] 84. Fig. 4D depicts an exemplary flowchart 450 for determining a driver for a request according to various embodiments of the present disclosure. 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. The process may comprise a search based on a driver’s GPS location that begins from step 455, in which a driver is determined based on whether the driver’s GPS location is near a pickup location indicated in a request. This search may use an Edge-GPS index to traverse, and may be used for batching scenarios in which one or more requests are grouped together for a driver to handle. The process may also comprise a search that begins at step 457 based on finding drivers who will arrive at his / her last step (e.g., of a route of the driver) which is near to a pickup location indicated in the request. This search may use an Edge-LastStep index to traverse. For the present solution, the process may be configured to have only one branch: Pickup's Nearby Pickup Step in step 456. From step 456, the process proceeds to step 458 in which a BFS may be performed on, for example, edge-based road graph 400 centred from node 402 (e.g., the node representing a first location indicated in the request) to determine a second location (represented by nodes 404, 406, 408, 410 and 412) and nearby roads (e.g., represented by edges 414, 416, 418, 420 and 422 in the graph 400) . Further, inverted index 446 may be utilized to traverse the nearby edges, obtain delivery steps for a route that is associated with each traversed edge, and identify a driver associated with the route (e.g., based on an identifier of the driver that is associated with the route) . In an implementation, a corresponding index may be selected based on a requirement indicated in the request for a driver (e.g., a distance or time requirement indicated in the request, for example corresponding to a shortest estimated distance or shortest estimated time respectively to complete the request) and the edges may be traversed via a BFS based on the selected corresponding index. At step 448, information relating to a route of a driver who is or will be travelling along a road represented by a traversed edge is retrieved from a database (e.g., database 150) . At step 450, one or more filters may be applied against one or more attributes of the driver (e.g., the attribute being one of a distance from the first location, a distance from the second location, an estimated time of arrival at the second location, a status of the driver, preference of the driver, and / or other similar attribute) to select a driver for handling the request. For example, a multi-layer filtering may be performed in which each filter may be based on an attribute of the driver, and based on an appropriate local and remote storage. By implementing these steps and updating the system, it is  possible to efficiently identify eligible driver candidates based on their routes and proximity to nearby locations, ultimately improving the in-transit batching process.

[0086] 85. Fig. 5 illustrates an example flow diagram for a method 500 for determining a driver for a request according to various embodiments. In a step 502, a second location that is within proximity from a first location may be determined based on a search that starts from a road that is nearest to the first location, the first location being indicated in a request for a driver. In a step 504, a driver may be determined for the request based on whether the driver is on the way to the second location.

[0087] 86. Fig. 6 depict an example computer system 1400, in accordance with which the determination server 140 described can be practiced. The computer system 1400 includes a computer module 1401. An external Modulator-Demodulator (Modem) transceiver device 1416 may be used by the computer module 1401 for communicating to and from a communications network 1420 via a connection 1421. The communications network 1420 may be a wide-area network (WAN) , such as the Internet, a cellular telecommunications network, or a private WAN. Where the connection 1421 is a telephone line, the modem 1416 may be a traditional “dial-up” modem. Alternatively, where the connection 1421 is a high capacity (e.g., cable) connection, the modem 1416 may be a broadband modem. A wireless modem may also be used for wireless connection to the communications network 1420.

[0088] 87. The computer module 1401 typically includes at least one processor unit 1405, and a memory unit 1406. For example, the memory unit 1406 may have semiconductor random access memory (RAM) and semiconductor read only memory (ROM) . The computer module 1401 also includes an interface 1408 for the external modem 1416. In some implementations, the modem 1416 may be incorporated within the computer module 1401, for example within the interface 1408. The computer module 1401 also has a local network interface 1411, which permits coupling of the computer system 1400 via a connection 1423 to a local-area communications network 1422, known as a Local Area Network (LAN) . As illustrated in Fig. 6A, the local communications  network 1422 may also couple to the wide network 1420 via a connection 1424, which would typically include a so-called “firewall” device or device of similar functionality. The local network interface 1411 may comprise an Ethernet circuit card, a wireless arrangement or an IEEE 802.11 wireless arrangement; however, numerous other types of interfaces may be practiced for the interface 1411.

[0089] 88. The I / O interfaces 1408 may afford either or both of serial and parallel connectivity, the former typically being implemented according to the Universal Serial Bus (USB) standards and having corresponding USB connectors (not illustrated) . Storage devices 1409 are provided and typically include a hard disk drive (HDD) 1410. Other storage devices such as a floppy disk drive and a magnetic tape drive (not illustrated) may also be used. An optical disk drive 1412 is typically provided to act as a non-volatile source of data. Portable memory devices, such optical disks, USB-RAM, portable, external hard drives, and floppy disks, for example, may be used as appropriate sources of data to the system 1400.

[0090] 89. The components 1405 to 1412 of the computer module 1401 typically communicate via an interconnected bus 1304 and in a manner that results in a conventional mode of operation of the computer system 1400 known to those in the relevant art. For example, the processor 1405 is coupled to the system bus 1404 using a connection 1418. Likewise, the memory 1406 and optical disk drive 1412 are coupled to the system bus 1404 by connections 1419. Examples of computers on which the described arrangements can be practised include IBM-PC’s and compatibles, Sun Sparcstations, Apple or like computer systems.

[0091] 90. The method 500, where performed by the determination server 140 may be implemented using the computer system 1400. The processes may be implemented as one or more software application programs 1433 executable within the computer system 1400. In particular, the method 500 is effected by instructions in the software 1433 that are carried out within the computer system 1400. The software instructions may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part and the  corresponding code modules performs the method 500 and a second part and the corresponding code modules manage a user interface between the first part and the user.

[0092] 91. The software may be stored in a computer readable medium, including the storage devices described below, for example. The software is loaded into the computer system 1400 from the computer readable medium, and then executed by the computer system 1400. A computer readable medium having such software or computer program recorded on the computer readable medium is a computer program product. The use of the computer program product in the computer system 1400 preferably effects an advantageous apparatus for a determination server 140.

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

[0094] 93. In some instances, the application programs 1433 may be supplied to the user encoded on one or more CD-ROMs 1425 and read via the corresponding drive 1412, or alternatively may be read by the user from the networks 1420 or 1422. Still further, the software can also be loaded into the computer system 1400 from other computer readable media. Computer readable storage media refers to any non-transitory tangible storage medium that provides recorded instructions and / or data to the computer system 1400 for execution and / or processing. Examples of such storage media include floppy disks, magnetic tape, optical disc, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module 1401. Examples of transitory or non-tangible computer  readable transmission media that may also participate in the provision of software, application programs, instructions and / or data to the computer module 1401 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.

[0095] 94. The second part of the application programs 1433 and the corresponding code modules mentioned above may be executed to implement one or more graphical user interfaces (GUIs) to be rendered or otherwise represented upon a display. Through manipulation of typically a keyboard and a mouse, a user of the computer system 1400 and the application may manipulate the interface in a functionally adaptable manner to provide controlling commands and / or input to the applications associated with the GUI (s) . Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing speech prompts output via loudspeakers and user voice commands input via a microphone.

[0096] 95. It is to be understood that the structural context of the computer system 1400 (i.e., the determination server 140) is presented merely by way of example. Therefore, in some arrangements, one or more features of the computer system 1400 may be omitted. Also, in some arrangements, one or more features of the computer system 1400 may be combined together. Additionally, in some arrangements, one or more features of the computer system 1400 may be split into one or more component parts.

[0097] 96. Fig. 7 shows an implementation of the transaction processing server 108 (i.e., the computer system 1300) . In this implementation, the transaction processing 108 may be generally described as a physical device comprising at least one processor 802 and at least one memory 804 including computer program codes. The at least one memory 804 and the computer program codes are configured to, with the at least one processor 802, cause the transaction processing server 108 to facilitate the operations described in method 500. The transaction processing server 108 may also include a transaction processing module 806. The memory 804 stores computer program code that the processor 802  compiles to have transaction processing module 806 perform the respective functions.

[0098] 97. With reference to Fig. 1, the transaction processing module 806 performs the function of communicating with the requestor device 102 and the provider device 104, and the acquirer server 106 and the issuer server 110 to respectively receive and transmit a transaction, a request for a service, delivery, a travel-coordination request, purchasing of a good or service by a user, and other similar services. The transaction processing module 806 may be configured to process processes relating to a transaction by, for example, forwarding data and information associated with the transaction to the other servers in the system 100 such as the determination server 140. In an example, the transaction processing server 108 may, instead of the requestor device 102 or provider device 104, transmit data relating to a request (e.g., location information relating to a first location, location information relating to a third location, date, time, and other similar data) to the determination server 140 for determining a second location within proximity from the first location. The transaction processing module 806 may use a variety of different protocols and procedures in order to process the payment and / or requests. It will be appreciated that payment for a transaction may be made via a variety of methods such as credit cards, debit cards, digital wallets, buy-first pay-later schemes, and other similar payment methods.

[0099] 98. Fig. 10 shows an alternative implementation of the determination server 140 (e.g., the computer system 1400) . In the alternative implementation, determination server 140 may be generally described as a physical device comprising at least one processor 902 and at least one memory 904 including computer program codes. The at least one memory 904 and the computer program codes are configured to, with the at least one processor 902, cause the determination server 140 to perform the operations described in the method 500. The determination server 140 may also include a data module 906, an search module 908 and a determination module 910. The memory 904 stores computer program code that the processor 902 compiles to have each of the modules 906 to 910 performs their respective functions.

[0100] 99. With reference to Figs. 1 to 5, the search module 908 performs the function of determining a second location that is within proximity from a first location based on a search that starts from a road that is nearest to the first location, the first location being indicated in a request for a driver. In an implementation, the search module 908 may be configured to identify another node that is within proximity from a node representing the first location in an edge-based road graph, the another node representing the second location. In an implementation, the search module 908 may be configured to perform the search that starts from an edge that branches from the node representing the first location and ends at a node or edge according to a threshold.

[0101] 100. With reference to Figs. 1 to 5, the determination module 910 performs the function of determining a driver for the request based on whether the driver is on the way to the second location (e.g., determined by the search module 908) . In an implementation, the determination module 910 may be configured to determine a route associated with an edge that branches from a node representing the second location in an edge-based road graph, the edge representing a road that is nearest to the second location; and identify a driver associated with the route. In an implementation, the determination module 910 may be configured to determine the route based on a mapping associating each edge of the edge-based road graph with a route stored in a database. In an implementation, the determination module 910 may be configured to determine whether to select the driver for the request based on an attribute of the driver, the attribute being one of a distance from the first location, a distance from the second location, an estimated time of arrival at the second location, or a preference of the driver. In an implementation, the determination module 910 may be configured to estimate a time required for the driver to arrive at the first location based on a route of the driver, and select the driver based on a determination whether the estimated time exceeds a threshold. In an implementation wherein the request further indicates a third location, the determination module 910 may be configured to select the driver based on a determination whether the route of the driver includes the third location, or estimate a time required for the driver to arrive at the third location based on a route of the driver, and selecting the driver based on a determination whether the estimated time exceeds a threshold. In an implementation wherein the  request further indicates a third location, the determination module 910 may be configured to estimate a time required for the driver to arrive at the third location based on a route of the driver, and select the driver based on a determination whether the estimated time exceeds a threshold. In an implementation, the determination module 910 may be further configured to assess whether a route associated with an edge includes the second location, and select a driver associated with the route for handling the request based on the assessment.

[0102] 101. With reference to Figs. 1 to 5, the data module 906 performs the functions of receiving data and information from the requestor device 102, provider device 104, transaction processing server 108, database 150, a cloud and other sources of information to determine a driver for a request by the determination server 140. For example, the data module 906 may be configured to receive data and information required for: determining a second location that is within proximity from a first location based on a search that starts from a road that is nearest to the first location, the first location being indicated in a request for a driver; determining a driver for the request based on whether the driver is on the way to the second location; determining a route associated with an edge that branches from a node representing the second location in an edge-based road graph, the edge representing a road that is nearest to the second location, and identifying a driver associated with the route; determining the route based on a mapping that associates each edge of the edge-based road graph with a route stored in a database; determining whether to select the driver for the request based on an attribute of the driver, the attribute being one of a distance from the first location, a distance from the second location, an estimated time of arrival at the second location, or a preference of the driver; identifying another node that is within proximity from a node representing the first location in an edge-based road graph, the another node representing the second location; performing the search that starts from an edge that branches from the node representing the first location and ends at a node or edge according to a threshold; estimating a time required for the driver to arrive at the first location based on a route of the driver, and selecting the driver based on a determination whether the estimated time exceeds a threshold; wherein the request may further indicate a third location, selecting the driver based on a determination whether the route of the driver includes the third location, or estimating a time required for the driver to  arrive at the third location based on a route of the driver, and selecting the driver based on a determination whether the estimated time exceeds a threshold; assessing whether a route associated with an edge includes the second location, and selecting a driver associated with the route for handling the request based on the assessment; and other similar processes from the requestor device 102, the provider device 104, transaction processing server 108, database 150, and / or other sources of information. The data module 260 may be further configured to send information relating to data retrieved in response to a request to the requestor device 102, the provider device 104, the transaction processing server 108, or other destinations where the information is required.

[0103] 102. Fig. 8B depicts a general-purpose computer system 1500, upon which a combined transaction processing server 108 and determination server 140 described can be practiced. The computer system 1500 includes a computer module 1501. An external Modulator-Demodulator (Modem) transceiver device 1516 may be used by the computer module 1501 for communicating to and from a communications network 1520 via a connection 1521. The communications network 1520 may be a wide-area network (WAN) , such as the Internet, a cellular telecommunications network, or a private WAN. Where the connection 1521 is a telephone line, the modem 1516 may be a traditional “dial-up”modem. Alternatively, where the connection 1521 is a high capacity (e.g., cable) connection, the modem 1516 may be a broadband modem. A wireless modem may also be used for wireless connection to the communications network 1520.

[0104] 103. The computer module 1501 typically includes at least one processor unit 1505, and a memory unit 1506. For example, the memory unit 1506 may have semiconductor random access memory (RAM) and semiconductor read only memory (ROM) . The computer module 1501 also includes an interface 1508 for the external modem 1516. In some implementations, the modem 1516 may be incorporated within the computer module 1501, for example within the interface 1508. The computer module 1501 also has a local network interface 1511, which permits coupling of the computer system 1500 via a connection 1523 to a local-area communications network 1522, known as a Local Area Network (LAN) . As illustrated in Fig. 8D, the local communications  network 1522 may also couple to the wide network 1520 via a connection 1524, which would typically include a so-called “firewall” device or device of similar functionality. The local network interface 1511 may comprise an Ethernet circuit card, a wireless arrangement or an IEEE 802.11 wireless arrangement; however, numerous other types of interfaces may be practiced for the interface 1511.

[0105] 104. The I / O interfaces 1508 may afford either or both of serial and parallel connectivity, the former typically being implemented according to the Universal Serial Bus (USB) standards and having corresponding USB connectors (not illustrated) . Storage devices 1509 are provided and typically include a hard disk drive (HDD) 1510. Other storage devices such as a floppy disk drive and a magnetic tape drive (not illustrated) may also be used. An optical disk drive 1512 is typically provided to act as a non-volatile source of data. Portable memory devices, such optical disks, USB-RAM, portable, external hard drives, and floppy disks, for example, may be used as appropriate sources of data to the system 1500.

[0106] 105. The components 1505 to 1512 of the computer module 1501 typically communicate via an interconnected bus 1504 and in a manner that results in a conventional mode of operation of the computer system 1500 known to those in the relevant art. For example, the processor 1505 is coupled to the system bus 1504 using a connection 1518. Likewise, the memory 1506 and optical disk drive 1512 are coupled to the system bus 1504 by connections 1519. Examples of computers on which the described arrangements can be practised include IBM-PC’s and compatibles, Sun Sparcstations, Apple or like computer systems.

[0107] 106. The steps of the method 500 performed by the determination server 140 and facilitated by the transaction processing server 108 may be implemented using the computer system 1500. For example, the steps of the method 500 as performed by the determination server 140 may be implemented as one or more software application programs 1533 executable within the computer system 1500. In particular, the steps of the method 500 are effected by instructions in the software 1533 that are carried out within the computer system 1500. The software instructions may be formed as one or more code  modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part and the corresponding code modules performs the steps of the method 500 and a second part and the corresponding code modules manage a user interface between the first part and the user.

[0108] 107. The software may be stored in a computer readable medium, including the storage devices described below, for example. The software is loaded into the computer system 1500 from the computer readable medium, and then executed by the computer system 1500. A computer readable medium having such software or computer program recorded on the computer readable medium is a computer program product. The use of the computer program product in the computer system 1500 preferably effects an advantageous apparatus for a combined transaction processing and determination server.

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

[0110] 109. In some instances, the application programs 1533 may be supplied to the user encoded on one or more CD-ROMs 1525 and read via the corresponding drive 1512, or alternatively may be read by the user from the networks 1520 or 1522. Still further, the software can also be loaded into the computer system 1500 from other computer readable media. Computer readable storage media refers to any non-transitory tangible storage medium that provides recorded instructions and / or data to the computer system 1500 for execution and / or processing. Examples of such storage media include floppy disks, magnetic tape, optical disc, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, or a computer readable card such as a  PCMCIA card and the like, whether or not such devices are internal or external of the computer module 1501. Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and / or data to the computer module 1501 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.

[0111] 110. The second part of the application programs 1533 and the corresponding code modules mentioned above may be executed to implement one or more graphical user interfaces (GUIs) to be rendered or otherwise represented upon a display. Through manipulation of typically a keyboard and a mouse, a user of the computer system 1500 and the application may manipulate the interface in a functionally adaptable manner to provide controlling commands and / or input to the applications associated with the GUI (s) . Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing speech prompts output via loudspeakers and user voice commands input via a microphone.

[0112] 111. It is to be understood that the structural context of the computer system 1500 (e.g., combined transaction processing and determination server 1500) is presented merely by way of example. Therefore, in some arrangements, one or more features of the server 1500 may be omitted. Also, 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 split into one or more component parts.

[0113] 112. Fig. 10 shows an alternative implementation of combined transaction processing and determination server (i.e., the computer system 1500) . In the alternative implementation, the combined transaction processing and determination server may be generally described as a physical device comprising at least one processor 1002 and at least one memory 904 including computer program codes. The at least one memory 1004 and the computer program codes are configured to, with the at least one processor 1002, cause the combined  transaction processing and determination server to perform the operations described in the steps of the method 500. The combined transaction processing and determination server may also include a transaction processing module 806, a data module 906, an search module 908 and a determination module 910. The memory 1004 stores computer program code that the processor 1002 compiles to have each of the modules 806 to 910 performs their respective functions. The transaction processing module 806 performs the same functions as described for the same transaction processing module in Fig. 8. The data module 906, search module 908 and determination module 910 perform the same functions as described for the same corresponding modules in Fig. 9.

[0114] 113. It will be appreciated by a person skilled in the art that numerous variations and / or modifications may be made to the present disclosure as shown in the specific embodiments without departing from the scope of the specification as broadly described. The present embodiments are, therefore, to be considered in all respects to be illustrative and not restrictive.

Claims

1.A method for determining a driver for a request, comprising:determining, by a processor, a second location that is within proximity from a first location based on a search that starts from a road that is nearest to the first location, the first location being indicated in a request for a driver; anddetermining, by the processor, a driver for the request based on whether the driver is on the way to the second location.2.The method of claim 1, wherein determining the driver for the request further comprises determining a route associated with an edge that branches from a node representing the second location in an edge-based road graph, the edge representing a road that is nearest to the second location; and identifying a driver associated with the route.3.The method of claim 2, further comprising determining the route based on a mapping associating each edge of the edge-based road graph with a route stored in a database.4.The method of claim 2, further comprising determining whether to select the driver for the request based on an attribute of the driver, the attribute being one of a distance from the first location, a distance from the second location, an estimated time of arrival at the second location, or a preference of the driver.5.The method of claim 1, wherein determining the second location further comprises identifying another node that is within proximity from a node representing the first location in an edge-based road graph, the another node representing the second location.6.The method of claim 5, wherein determining the second location further comprises performing the search that starts from an edge that branches from the node representing the first location and ends at a node or edge according to a threshold.7.The method of claim 1, further comprising estimating a time required for the driver to arrive at the first location based on a route of the driver, and selecting the driver based on a determination whether the estimated time exceeds a threshold.8.The method of claim 1, wherein the request further indicates a third location, and the method further comprises selecting the driver based on a determination whether a route of the driver includes the third location.9.The method of claim 8, further comprising: estimating a time required for the driver to arrive at the third location based on the route of the driver, and selecting the driver based on a determination whether the estimated time exceeds a threshold.10.A system for determining a driver for a request, comprising:at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the system at least to:determine a second location that is within proximity from a first location based on a search that starts from a road that is nearest to the first location, the first location being indicated in a request for a driver; anddetermine a driver for the request based on whether the driver is on the way to the second location.11.The system of claim 10, wherein determining the driver for the request further comprises determining a route associated with an edge that branches from a node representing the second location in an edge-based road graph, the edge representing a road that is nearest to the second location; and identifying a driver associated with the route.12.The system of claim 11, further configured to determine the route based on a mapping associating each edge of the edge-based road graph with a route stored in a database.13.The system of claim 11, further configured to determine whether to select the driver for the request based on an attribute of the driver, the attribute being one  of a distance from the first location, a distance from the second location, an estimated time of arrival at the second location, or a preference of the driver.14.The system of claim 10, wherein determining the second location further comprises identifying another node that is within proximity from a node representing the first location in an edge-based road graph, the another node representing the second location, and determining whether a route of the driver includes the road.15.The system of claim 14, wherein determining the second location further comprises performing the search that starts from an edge that branches from the node representing the first location and ends at a node or edge according to a threshold.16.The system of claim 10, further configured to estimate a time required for the driver to arrive at the first location based on a route of the driver, and select the driver based on a determination whether the estimated time exceeds a threshold.17.The system of claim 10, wherein the request further indicates a third location, and the system is further configured to select the driver based on a determination whether a route of the driver includes the third location.18.The system of claim 17, further configured to estimate a time required for the driver to arrive at the third location based on the route of the driver, and select the driver based on a determination whether the estimated time exceeds a threshold.

Images