Method and system for adaptive identifying optimal route

Abstract

The present disclosure provides methods and systems for adaptively identifying an optimal route. In some examples, a method is provided that includes determining, by a processor, one or more boarding points based on historical data related to a starting location, the starting location being a location indicated in a boarding request from the starting location to a destination location; determining, by the processor, one or more routes between each of the determined one or more boarding points and the destination location indicated in the boarding request; and adaptively identifying, by the processor, an optimal route of the one or more routes based on at least one of the cheapest route, the fastest route, the shortest route, and the shortest walking distance.

Description

Technical Field

[0001] The present disclosure relates broadly, but not exclusively, to methods and systems for adaptively identifying an optimal route. Background Art

[0002] Ride-hailing apps typically require users to select a specific pickup point and the drop-off point they want to go to. In more advanced implementations, some ride-hailing apps can predict the pickup point based on the user's current location.

[0003] Users of ride-hailing platforms often want to get to their destination faster or at the lowest possible cost, but may not be aware of available options. Price is often the most important factor that most users focus on, and users may manually compare prices at different pickup points based on their familiarity with the area. However, performing such a comparison for all possible pickup and drop-off point pairs (e.g., to find the best pair in which the user is picked up by the ride's driver at a pickup point reasonably close to the user's current location and then dropped off at a drop-off point reasonably close to the destination) would not be possible to do manually.

[0004] Therefore, there is a need to provide methods and systems that seek to overcome or at least minimize the above-mentioned challenges. Summary of the invention

[0005] According to a first aspect of the present disclosure, a method for adaptively identifying an optimal route is provided, the method comprising: determining, by a processor, one or more pick-up points based on historical data associated with a starting location, the starting location being a location indicated in a ride request from the starting location to a destination location; determining, by the processor, one or more routes between each of the determined one or more pick-up points and the destination location indicated in the ride request; and adaptively identifying, by the processor, an optimal route from the one or more routes based on at least one of a cheapest route, a fastest route, a shortest route, and a shortest walking distance.

[0006] According to a second aspect of the present disclosure, a system for adaptively identifying an optimal route is provided, the system comprising: at least one processor; and at least one memory comprising computer program code; the at least one memory and the computer program code being configured to, together with the at least one processor, enable the system to at least: determine one or more pickup points based on historical data associated with a starting location, the starting location being a location indicated in a ride request from the starting location to a destination location; determine one or more routes between each of the determined one or more pickup points and the destination location indicated in the ride request; and adaptively identify an optimal route from the one or more routes based on at least one of a cheapest route, a fastest route, a shortest route, and a shortest walking distance. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The 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 accompanying drawings, in which:

[0008] Figure 1 A system for adaptively identifying an optimal route according to various embodiments of the present disclosure is shown.

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

[0010] FIG. 3A to FIG. 3F An example illustration depicting a problem related to hailing a taxi.

[0011] FIG. 4A to FIG. 4B Depicted is an example diagram of a user reservation flow in accordance with various implementations.

[0012] Figure 5 An example illustration of a flow chart for adaptively identifying an optimal route is depicted in accordance with various implementations.

[0013] Figure 6 Depicted are example illustrations of a system that may be implemented for adaptively identifying an optimal route in accordance with various implementations.

[0014] Figure 7 An example flow chart of a method for adaptively identifying an optimal route according to various embodiments is shown.

[0015] Fig. 8A is a schematic block diagram of a general-purpose computer system on which the Figure 2 Route server.

[0016] Figure 8B is a schematic block diagram of a general-purpose computer system on which the Figure 1 A combined transaction processing and routing server.

[0017] Fig. 9 Shown is a method for implementing Figure 1 An example of a computing device of a transaction processing server is shown in .

[0018] Fig.10 Shown is a method for implementing Figure 1 An example of a computing device of a route server is shown in .

[0019] Fig.11 Shown is a method for implementing Figure 1 An example of a computing device that combines transaction processing and routing servers is shown in .

[0020] The skilled person will understand that the elements in the drawings are illustrated for simplicity and clarity and are not necessarily drawn to scale. For example, the size of some elements in the diagrams, block diagrams or flow charts may be exaggerated relative to other elements to help improve the understanding of the embodiments of the present invention. DETAILED DESCRIPTION

[0021] Terminology

[0022] A platform refers to a set of technologies used as a basis for facilitating exchanges between two or more interdependent servers, entities, and / or devices (e.g., exchanges between a requester device (of a product or service) and a provider device (of a product or service)). For example, a platform may provide services provided by a provider to a requester, such as rides, deliveries, online shopping, insurance, and other similar services. A requester may typically access the platform via a website, an application, or other similar methods.

[0023] Points of interest (POIs) are places or locations that users can indicate or search for in a transport or delivery booking service. A POI can be a place where a user may be interested in going to or delivering something. A POI can also be a location where a user wants to be picked up by a driver (e.g., a pickup point), or a location where a delivery person is going to retrieve an item for the user. There may be various drop-off points (e.g., where a user can get off or deliver an item after a ride) or pickup points (e.g., where a user can get on or receive an item to be delivered) associated with a POI, and a user may be able to indicate or search for a POI in a transport or delivery booking service. In a ride or delivery request that can be sent from a user to a transport or delivery booking service, the POI where the user wants to start the ride or start the delivery can be indicated as a starting location, and a POI where the user may be interested in going to or delivering something can be indicated as a destination location. In the case of one or more pickup points near a POI, each of the one or more pickup points may be within walking distance from the POI or located at the POI. Similarly, in the case of one or more drop-off points near a POI, one or more drop-off points may be within walking distance from the POI or located at the POI.

[0024] The ride request may originate from the requester and be transmitted from the requester device to a server or device associated with the platform, and may include location information, such as the starting location where the requested ride should start and the destination location where the requested ride should end. The starting location may be the current location of the requester based on, for example, the GPS location of the requester device, or the starting location may be another location entered by the requester in the ride request. The starting location may have one or more pickup points from which the provider may pick up the requester. One or more pickup points may be determined based on proximity to the starting location, such that the requester may be required to walk a certain distance (e.g., within walking distance) from the starting location to the pickup point. In some embodiments, the starting location itself may be a pickup point. The destination location may have one or more drop-off points, and the provider of the ride may drop the requester off at the drop-off point. One or more drop-off points are typically determined based on proximity to the destination location, such that the requester may be required to walk a certain distance (e.g., within walking distance) from the drop-off point to the destination location. In some embodiments, the destination location itself may be a drop-off point. One or more routes for the requested ride may be determined based on the starting location (or one or more pickup points) and the destination location (or one or more drop-off points), and the best route may be identified based on criteria. The criteria may be at least one of the cheapest route, the fastest route, the shortest route, and the shortest walking distance, and may be set by the platform based on the requester's predicted user preferences, or by the requester.

[0025] In at least some embodiments, a user can be any suitable type of entity, which can include a person, a consumer who wishes to purchase a product or service via a transaction processing server, a seller or merchant who wishes to sell a product or service via a transaction processing server, a motorcycle driver or pillion rider in the case where a user wishes to book or provide a motorcycle ride via a transaction processing server, a car driver or passenger in the case where a user wishes to book or provide a car ride via a transaction processing server, and other similar entities. Users registered with the transaction processing server will be referred to as registered users. Users who are not registered with the transaction processing server will be referred to as unregistered users. The term user will be used to refer to both registered users and unregistered users. Users can be interchangeably referred to as requesters (e.g., people who request products or services) or providers (e.g., people who provide requested products or services to requesters).

[0026] In at least some embodiments, the route server is a server that hosts a software application for adaptively identifying the best route. Figure 2 The route server is implemented as shown in the schematic diagram 200 of , for adaptively identifying the best route.

[0027] In at least some embodiments, a transaction processing server is a server that hosts a software application for processing payment transactions such as travel coordination requests, user purchases of goods or services, and other similar services. The transaction processing server communicates with any other server (e.g., a routing server) involved in processing payment transactions related to the purchase of goods or services, such as travel coordination requests (which may be interchangeably referred to as ride requests). For example, data associated with a request message such as a ride request (e.g., date, time, starting location, destination location, and other similar data) may be provided to the routing server and processed to locate a driver (e.g., a ride provider) near the starting location. The transaction processing server may use a variety of different protocols and procedures in order to process payment and / or travel coordination requests.

[0028] Transactions that may be performed via the transaction processing server include product or service purchases, credit purchases, debit transactions, funds transfers, account withdrawals, etc. The transaction processing server may be configured to process transactions via cash substitutes, which may include payment cards, letters of credit, checks, payment accounts, etc.

[0029] In at least some embodiments, the transaction processing server is typically managed by a service provider, which can be an entity (e.g., a company or organization) that operates to process transaction requests and / or travel coordination requests (e.g., pairing a provider of travel coordination requests with a requester of travel coordination requests). The transaction processing server can include one or more computing devices for processing transaction requests and / or travel coordination requests.

[0030] In at least some embodiments, a transaction account is an account of a user registered at a transaction processing server. A user may be a customer, a merchant offering products for sale and / or loading on the platform, a taxi provider (e.g., a driver), or any third party (e.g., a courier) who wants to use a transaction processing server. In some cases, a transaction account does not require the use of a transaction processing server. A transaction account includes detailed information about the user (e.g., name, address, vehicle, facial image, etc.). The transaction processing server manages transactions.

[0031] Embodiments will be described by way of example only with reference to the accompanying drawings. Like reference numerals and characters in the drawings indicate like elements or equivalents.

[0032] Some portions of the following description are presented explicitly or implicitly 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 art of data processing to most effectively convey 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. Steps are those steps requiring physical manipulation of physical quantities (such as electrical, magnetic or optical signals) that can be stored, transferred, combined, compared and otherwise manipulated.

[0033] Unless otherwise specifically stated, and as will become apparent from the following text, it should be understood that throughout this specification, discussions utilizing terms such as "identify," "determine," "associate," "select," "compute," "process," "store," "indicate," etc., refer to the actions and processes by a computer system or similar electronic device to manipulate and transform data represented as physical quantities within the computer system into other data similarly represented as physical quantities within the computer system or other information storage, transmission, or display device.

[0034] In addition, this specification also implicitly discloses a computer program, because it is obvious to those skilled in the art that the various steps of the method described herein can be implemented by computer code. The computer program is not intended to be limited to any specific programming language and its implementation. It should be understood that various programming languages ​​and their encodings can be used to implement the teachings of the disclosure contained herein. In addition, the computer program is not intended to be limited to any specific control flow. There are multiple other variants of computer programs that can use different control flows without departing from the scope of this specification.

[0035] In addition, 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 a storage device, such as a disk or optical disk, a memory chip, or other storage device suitable for being connected to a computer interface. The computer readable medium may also include a hardwired medium such as exemplified in an Internet system, or a wireless medium such as exemplified in a GSM mobile phone system. The computer program, when loaded and executed on such a computer, effectively produces a device that implements the steps of the preferred method.

[0036] refer to Figure 3A and Figure 3B, the ride booking process typically involves selecting a starting location and a destination location in example menu 302, selecting the desired type of transportation configuration in example menu 304, confirming a pickup point for the ride request in example menu 306, waiting for the application to find a driver for the requested ride as shown in example menu 308, and completing payment for the ride in example menu 310 in the case of a postpaid ride, for example.

[0037] In some ride-hailing applications, pickup points may be suggested based on the starting location indicated in the ride request. Figure 3C The example menu 312 in FIG. 1 suggests two pickup points 314 and 316 to the user based on the starting location. Depending on the pickup point, the route planned for the ride may be different. For example, referring to Figure 3D 318, pickup points 320 and 322 are on opposite sides of the road, thus making different routes for each pickup point have different distances, travel times, ride prices, and distances from the starting location indicated in the ride request. Specifically, it is important to pair the pickup location with the drop-off location because getting on the bus from different sides of the road may result in very different travel times. In this example, users may be picked up from different sides of the road. If the user wishes to go to a location on the left side of the map of illustration 318, getting on the bus from pickup point 320 will result in a shorter travel time because the driver does not need to turn around. The opposite is also applicable when pickup point 322 is selected and heading toward the right side of the map of illustration 318. Depending on the selected pickup point, this difference may cause the user to spend less or more travel time.

[0038] This also applies to different drop-off points for destination locations. Figure 3E In the example illustration 324 of FIG. 3 , drop-off points 326 and 328 are associated with different entrances to the destination location 325, which allows different routes for each drop-off point to have different distances, travel times, ride prices, and may also allow the drop-off points to have different distances from the destination location indicated in the ride request. Many buildings and venues often have the following characteristics, where different pickup / drop-off points of the building may be more efficient to travel to, for example, different parts of a city. For example, any pickup point selected for a ride to the destination location 325 may have a distance difference of more than 1 km in the determined route between the pickup point and each different entrance or drop-off point of the destination location 325.

[0039] also, Figure 3EThe example diagram shows that indicating different pickup points for the same POI may result in different routes with different prices. For example, selecting a pickup point 332 for a POI 330 (e.g., UTown, NUS) results in a trip price between $8.30 and $12.30 (see reference 334), while selecting a pickup point 336 for the same POI 330 results in a trip price between $6.30 and $11.30 (see reference 338).

[0040] In the present disclosure, a method is proposed, wherein one or more pickup points and / or drop-off points may be suggested based on user input in a ride request, and one or more routes may be determined and indicated to the user based on each of the one or more pickup points and / or drop-off points. The user may be able to select from the one or more pickup points and / or drop-off points and one or more routes based on at least one of the cheapest route, the fastest route, the shortest route, and the shortest walking distance. This advantageously enables the user to be better informed of all possible options to the desired destination, and enables the user to reach the desired destination in the fastest and / or cheapest manner according to the selected route.

[0041] To support the above operations, the nearest pickup point and / or drop-off point that the user can reach can be determined based on the starting location. This can include using a walking map to estimate the walking time required to travel from the starting location to each of the one or more pickup points and / or from each of the one or more drop-off points to the destination location. The starting location and the destination location can be indicated by the user in the ride request. In one implementation, the starting location can be the user's current location.

[0042] In the next step, one or more routes may be determined for each pair of pickup and drop-off points. The corresponding price and distance for each of the one or more routes may also be determined. These paired combinations may be ranked based on criteria such as cost savings, driving time, walking time, ease of walking, and other similar criteria. The ranked list of suggested routes may then be provided to the user for final selection.

[0043] By automating the above process, information for users to weigh between price, time, and walking can be presented in a way that advantageously maximizes both the revenue of the ride-hailing platform and the savings of the user, depending on the user's selection, which can be in the form of paying more for the driver providing the ride to pick up the user at the nearest possible location without any walking,

[0044] Or offering a trade-off between walking to the pickup point but then taking a faster and cheaper route to the destination location.

[0045] Figure 1A block diagram of an example system 100 for adaptively identifying an optimal route is shown. In some implementations, the system 100 enables payment transactions for goods or services between a requester and a provider, and / or requests for rides or delivery of physical items (e.g., one or more groceries or packages).

[0046] The system 100 includes a requester device 102 , a provider device 104 , an acquirer server 106 , a transaction processing server 108 , an issuer server 110 , a routing server 140 , and a reference database 150 .

[0047] The requesting device 102 communicates with the providing 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 through a network (e.g., the Internet). The requesting device 102 also communicates with the route server 140 via a connection 121, wherein the route server 140 may be configured to receive a ride request indicating information related to a starting location and a destination location from the requesting device 102. The connection 121 may be via a network (e.g., the Internet). The requesting device 102 may also be connected to a cloud that facilitates the system 100 to adaptively identify an optimal route. For example, the requesting device 102 may send a signal or data directly to the cloud via a wireless connection (e.g., via NFC communication, Bluetooth, etc.) or through a network (e.g., the Internet).

[0048] As described above, the provider device 104 typically communicates with the requester device 102 via the transaction processing server 108 and may be associated with the provider of the ride (e.g., the driver who responds to the ride request). The provider device 104 in turn communicates with the acquirer server 106 via connection 114. The provider device 104 also communicates with the route server 140 via connection 123, wherein the route server 140 may be configured to receive location information of the provider device 104, such as determining whether the provider device 104 is close to the starting location and whether to provide the ride request to the provider device 104. 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 to adaptively identify the best route. For example, the provider device 104 may send a signal or data directly to the cloud via a wireless connection (e.g., via NFC communication, Bluetooth, etc.) or over a network (e.g., the Internet).

[0049] The acquirer server 106, in turn, communicates with the transaction processing server 108 via a connection 116. The transaction processing server 108, in turn, communicates with the issuer server 110 via a connection 118. The connections 116 and 118 may be via a network (eg, the Internet).

[0050] The transaction processing server 108 also communicates with the route server 140 via a connection 120. The connection 120 may be through 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 route server 140 are combined, and the connection 120 may be an interconnect bus.

[0051] The route server 140 in turn communicates with the reference database 150 via a corresponding connection 122. The connection 122 may be through a network (e.g., the Internet). The route server 140 may also be connected to a cloud that facilitates the system 100 to adaptively identify the best route. For example, the route server 140 may send signals or data directly to the cloud via a wireless connection (e.g., via NFC communication, Bluetooth, etc.) or through a network (e.g., the Internet).

[0052] The reference database 150 may include data used by the route server 140 to adaptively identify optimal routes. For example, historical data related to a starting location and a destination location may be stored in the reference database 150. The historical data may indicate a plurality of POIs, which may include one or more pickup points for the starting location and one or more drop-off points for the destination location. The historical data may also indicate location information for each of the one or more pickup points and drop-off points. Data related to user information, such as selections during past and current transactions, user preferences, and other similar data may also be stored in the reference database 150. In addition, data related to pricing information (e.g., data used to calculate the price of each route that may be determined by the route server 140) may also be stored in the reference database 150. In addition, data related to maps (e.g., Karta Map TM ) related data may also be stored in the reference database 150. In an implementation, the reference database 150 may be combined with the route server 140. In an example, the reference database 150 may be managed by an external entity.

[0053] The route server 140 may be configured to determine one or more pickup points based on historical data associated with a starting location, which is a location indicated in a ride request for a ride from the starting location to a destination location. The route server 140 may then be configured to determine one or more routes between each of the determined one or more pickup points and the destination location indicated in the ride request, and adaptively identify an optimal route from the one or more routes based on at least one of the cheapest route, the fastest route, the shortest route, and the shortest walking distance.

[0054] The historical data may indicate a plurality of pickup points and location information of each of the plurality of pickup points, and determining the one or more pickup points further comprises: selecting one or more pickup points close to the starting location from the plurality of pickup points based on the location information.

[0055] In an implementation, there may be more than one reference database, wherein the route server 140 may be configured to determine which database to use at each step during processing of a ride request. Alternatively, one or more modules may store the above data instead of the reference database 150, wherein the module may be integrated as part of the route server 140 or external to the route server 140.

[0056] In an illustrative embodiment, each of the devices 102, 104 and servers 106, 108, 110, 140 and / or reference database 150 provides an interface to enable communication with the other devices 102, 104 and servers 106, 108, 110, 140 and / or reference database 150 connected. Such communication is facilitated by an application programming interface ("API"). Such an API can be part of a user interface, which can include a graphical user interface (GUI), a web-based interface, a programming interface (such as an application programming interface (API)) and / or a remote procedure call (RPC) set corresponding to an interface element, a messaging interface in which the interface element corresponds to a message of a communication protocol, and / or a suitable combination thereof. For example, in response to a query displayed on a GUI running on a corresponding API, the requesting device 102 can send data related to the route selection of the requested ride, and the providing device 104 can send data related to the acceptance or rejection of the ride request.

[0057] The term "server" used herein may refer to a single computing device or multiple interconnected computing devices that operate together to perform a specific function. That is, a server may be contained within a single hardware unit or distributed among several or more different hardware units.

[0058] The route server 140 is associated with an entity (e.g., a company or organization or an arbitrator of services). In one arrangement, the route server 140 is owned and operated by the entity that operates the transaction processing server 108. In such an arrangement, the route server 140 can be implemented as part of the transaction processing server 108 (e.g., a computer program module, a computing device, etc.).

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

[0060] It is not necessary to have a transaction account at the transaction processing server 108 to access the functions of the transaction processing server 108. However, there are functions that registered users can use. These additional functions will be discussed below.

[0061] The joining process of the user is performed by the user through one of the requester device 102 or the provider device 104. In one arrangement, the user downloads an application (which includes an API to interact with the transaction processing server 108) to the requester device 102 or the provider device 104. In another arrangement, the user visits a website (which includes an API to interact with the transaction processing server 108) on the requester device 102 or the provider device 104. The user is then able to interact with the route server 140. The user can be a requester or a provider associated with the requester device 102 or the provider device 104, respectively.

[0062] The registered details may include, for example, the user's name, the user's address, emergency contacts, blood type or other healthcare information, next of kin contacts, permission to retrieve data and information from the requester device 102 and / or provider device 104 to adaptively identify the best route, such as permission to retrieve location information of the requester device 102 and / or provider device 104. Alternatively, another mobile device may be selected to retrieve data instead of the requester device 102 and / or provider device 104. Once joined, the user will have a transaction account where all details are stored.

[0063] The requester device 102 is associated with a customer (or requester) who is a party to a transaction that occurs between the requester device 102 and the provider device 104, or between the requester device 102 and the route server 140. The requester device 102 may be a computing device, such as a desktop computer, an interactive voice response (IVR) system, a smart phone, a laptop computer, a personal digital assistant computer (PDA), a mobile computer, a tablet computer, etc. The requester device 102 may be associated with a user who initiates a ride request.

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

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

[0066] The provider device 104 is associated with a provider that is also a party to the transaction request that occurs between the requester 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 smart phone, a laptop computer, a personal digital assistant computer (PDA), a mobile computer, a tablet computer, etc. The provider device 104 may be associated with a provider of the ride (e.g., a driver who responds to the ride request).

[0067] Hereinafter, the term "provider" refers to a service provider and any third party associated with providing products or services for purchase or rides or delivery services via the provider device 104. Thus, a provider's transaction account refers to both the provider's transaction account and the transaction accounts of third parties associated with the provider (e.g., ride coordinators or merchants).

[0068] If the provider has a transaction account, the transaction account may also be included (ie, stored) in the provider device 104. For example, a mobile device (as the provider device 104) may store the provider's transaction account in the mobile device.

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

[0070] The acquirer server 106 is associated with an acquirer, which may be an entity (e.g., a company or organization) that issues (e.g., establishes, manages, governs) a merchant's payment account (e.g., a financial bank account). Examples of acquirers include banks and / or other financial institutions. As discussed above, the acquirer server 106 may include one or more computing devices for establishing communication with another server (e.g., a transaction processing server 108) by exchanging messages with the other servers and / or passing information to the other servers. The acquirer server 106 forwards the payment transaction associated with the transaction request or ride request to the transaction processing server 108.

[0071] The transaction processing server 108 is configured to handle processes related to transaction accounts by, for example, forwarding data and information associated with the transaction to other servers in the system 100, such as the route server 140. In an example, instead of the requester device 102, the transaction processing server 108 can transmit data related to a request message such as a ride request (e.g., date, time, starting location, destination location, and other similar data) to the route server 104. The transaction processing server 108 can use a variety of different protocols and procedures in order to process payment and / or ride coordination requests. It should be understood that payment for the transaction can be made via a variety of methods, such as credit cards, debit cards, digital wallets, buy now, pay later schemes, and other similar payment methods.

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

[0073] The reference database 150 is a database or server associated with an entity (e.g., a company or organization) that manages (e.g., establishes, governs) data related to users, transactions, products, services, and other similar data related to the entity, for example. In an arrangement, the reference database 150 may include data used by the route server 140 to adaptively identify the best route. For example, historical data related to the starting location and the destination location may be stored in the reference database 150. The historical data may indicate a plurality of POIs, which may include one or more pickup points at the starting location and one or more drop-off points at the destination location. The historical data may also indicate location information for each of the one or more pickup points and drop-off points. Data related to user information, such as selections during past and current transactions, user preferences, and other similar data may also be stored in the reference database 150. In addition, data related to pricing information (e.g., data used to calculate the price of each route that may be determined by the route server 140) may also be stored in the reference database 150. In addition, data related to maps (e.g., Karta Map TM ) related data may also be stored in the reference database 150. In an implementation, the reference database 150 may be combined with the route server 140. In an example, the reference database 150 may be managed by an external entity.

[0074] Advantageously, the system 100 advantageously enables the user to be better informed of all possible options to a desired destination, and enables the user to reach the desired destination in the fastest and / or cheapest manner according to the selected route. In addition, information for the user to weigh between price, time, and walking can be presented in a manner that advantageously maximizes both the revenue of the ride-hailing platform and the savings of the user, depending on the user selection, which can provide a trade-off between paying more for the driver providing the ride to pick up the user at the nearest possible location without any walking, or walking to the pick-up point but then reaching the destination location via a faster and cheaper route.

[0075] Figure 2A schematic diagram of an example route server 140 according to various embodiments is shown. The route server 140 may include a data module 260 configured to receive data and information from the requester device 102, the provider device 104, the transaction processing server 108, the reference database 150, the cloud, and other information sources to adaptively identify the best route by the route server 140. For example, the data module 260 may be configured to receive data and information required to process a ride request and adaptively identify the best route from the requester device 102, the provider device 104, the transaction processing server 108, the reference database 150, and / or other information sources. The data module 260 may also be configured to send information related to the data retrieved in response to the ride request to the requester device 102, the provider device 104, the transaction processing server 108, or other destinations where the information is needed.

[0076] The route server 140 may include a POI module 262 configured to determine one or more pickup points based on historical data associated with a starting location, which is a location indicated in a ride request from the starting location to the destination location. Figure 5 to Figure 6 The POI determination process is further explained in .

[0077] The route server 140 may also include a route module 264 configured to determine one or more routes between each of the determined one or more pickup points and the destination location indicated in the ride request. Figure 5 to Figure 6 The route determination process is further explained in .

[0078] The route server 140 may also include a pricing module 266 configured to calculate an estimated price for a ride from each of the one or more pickup points to the destination location. The route server 140 may also include an identification module 268 configured to adaptively identify an optimal route from the one or more routes based on at least one of the cheapest route, the fastest route, the shortest route, and the shortest walking distance. Figure 5 to Figure 6 The calculation and identification process is further explained in .

[0079] In an implementation, the historical data may be stored in the reference database 150. The historical data may indicate multiple pickup points and location information of each of the multiple pickup points, and the POI module 262 may be further configured to select one or more pickup points close to the starting location from the multiple pickup points based on the location information.

[0080] In an implementation, determining one or more routes by the route module 264 may also include calculating a first set of estimated times and distances for walking from a starting location to each of one or more pickup points, and a second set of estimated times and distances for riding from each of the one or more pickup points to a destination location.

[0081] In an implementation, the historical data may also indicate a plurality of drop-off points and location information of each of the plurality of drop-off points, and the POI module 262 may also be configured to determine one or more drop-off points close to the destination location based on the location information. The route module 264 may also be configured to determine one or more routes including one or more routes between each of the determined one or more pickup points and each of the determined one or more drop-off points, and calculate a second set of estimated times and distances based on a ride from each of the one or more pickup points to each of the one or more drop-off points.

[0082] In an implementation, identifying the best route by the identification module 268 may also include identifying a route with the shortest time or distance as the best route from one or more routes based on the first set of estimated time and distance and / or the second set of estimated time and distance.

[0083] In an implementation, determining one or more routes by route module 264 may also include calculating a third set of estimated times and distances for walking from each of the one or more drop-off points to the destination location, and identifying the best route by identification module 268 may also include identifying a route with the shortest time or distance as the best route from the one or more routes based on the first set of estimated times and distances, the second set of estimated times and distances, and / or the third set of estimated times and distances.

[0084] In an implementation, determining one or more routes by the route module 264 may also include: calculating an estimated price of a ride from each of one or more pickup points to a destination location by the pricing module 266, and identifying the best route by the identification module 268 may also include: identifying the cheapest route from the one or more routes as the best route based on the estimated prices.

[0085] Each of the data module 260, POI module 262, route module 264, pricing module 266, and identification module 268 may also communicate with a processing module (not connected) of the route server 140, for example, to coordinate the functions during the corresponding tasks and processes. The data module 260 may also be configured to communicate and store data and information with each of the processing module, POI module 262, route module 264, pricing module 266, and identification module 268. Alternatively, all tasks and functions required to adaptively identify the best route may be performed by a single processor of the route server 140.

[0086] In the present disclosure, the proposed solution may include determining the nearest pickup and drop-off points that the user can feasibly reach from a starting location. The starting location may be the user's current location based on GPS, or another location entered by the user in the ride request. This may include using a walking map to estimate the walking time required from the starting location to different pickup points or from the drop-off point to the user's original intended destination (e.g., the destination location entered by the user in the ride request). The corresponding price of each pair of pickup and drop-off points may be calculated, and these paired combinations may be sorted based on criteria such as cost savings, travel time, walking time, convenience of walking, and other similar criteria. Based on these combinations, a suggested sorted list may be provided to the user for final selection.

[0087] By automating the above process, information for users to weigh between price, time, and walking distance can be presented in a way that maximizes both the ride-hailing platform's revenue and the user's savings, depending on the user's choice between paying more for a vehicle to come to them or walking to their destination faster and / or at a cheaper rate.

[0088] FIG. 4A to FIG. 4B An example illustration of a user booking process according to various embodiments is depicted. In this example, the user can indicate his current location 402 (e.g., automatically detected by GPS) as the starting location in the ride request. The user can also indicate the destination location in the menu 400. As shown in the menu 404, based on the starting location, one or more pickup points (e.g., determined by the route server 140) can be provided for the user to select. In addition, one or more pickup points can have corresponding text 406, which notifies the estimated cost savings that the user can enjoy if the corresponding pickup point is selected. The cost savings can be based on a comparison of the estimated prices of one or more routes from each pickup point to the destination location determined by the route server 140. In an implementation, text indicating other factors, such as the amount of time saved, walking distance, and other similar factors, can also be displayed based on, for example, user preferences.

[0089] In the next menu 408, the user can select a pickup point 410 that can save the user $2 as notified by the displayed text 406, and then confirm the pickup point. In the next menu 412, the user can check the displayed route 414 and the corresponding ride price before confirming the ride reservation.

[0090] Advantageously, the proposed solution can generate greater user favorability, leading to better passenger net promoter scores (PAX NPS) and platform retention. Consumers can also trust the platform providing rides more, and lower prices or faster rides can also lead to higher levels of conversion, where more people can use the platform instead of other competing platforms to book rides. In addition, by prompting users to use more efficient pickup and drop-off points, the overall capacity of the platform can also be improved, resulting in more revenue due to the increased capacity to complete more rides in less time.

[0091] To implement the proposed solution, a new step can be introduced into the typical booking process. At the beginning of the booking process, the user is usually asked to indicate their intended destination location. Given the selected destination location, the system will predict the user's most likely pickup location. Today, the prediction is usually based on the user's GPS location and historical knowledge of the user's frequently used pickup points.

[0092] The proposed solution aims to predict not only the most likely pickup location, but also compute feasible nearby pickup locations that the user could potentially reach on foot, as well as estimated prices and times for each of these candidate pickup points that the user would choose if these alternative options were selected (e.g., estimated prices and times for each of one or more routes from the pickup point to the destination location).

[0093] The set of feasible pickup locations can be determined by, for example, looking at an internal geo-fence database that provides geometric boundaries of a building such as a shopping mall or an area such as Gardens by the Bay. For example, such data can be stored in the reference database 150. Pickup points within these geometric boundaries are likely to be feasible for a user who books a ride from another pickup point within the same boundaries. This may be best if these venues are indoors, as user location via GPS tends to be less accurate. However, where the user's location can be known more precisely, the estimated walking time to nearby pickup points can be calculated in a more liberal manner to determine pickup points that are likely to be within a reasonable walking distance (e.g., a distance that requires an estimated walking time of 3 minutes).

[0094] Figure 5An example illustration of a flowchart 500 for adaptively identifying an optimal route according to various embodiments is depicted. At step 502, one or more pickup points are determined (e.g., by the route server 140) based on the starting location indicated in the ride request. The starting location may also be the user's current GPS location. The POI memory 504 may be an internal memory of the POI module 262 or the route server 140, or the POI memory may be part of a reference database 150 or other similar form of data storage. The POI memory 504 may be configured to store a plurality of all possible pickup points and drop-off points, including one or more pickup points that are close to the starting location. Thus, the system may query for relevant pickup points based on the starting location and the geometric information mentioned above with reference to the POI memory 504. A geometric indexing technique may be used to establish a relationship between the starting location and the candidate pickup points.

[0095] At step 506, the estimated walking time and distance from the starting location to each pickup point can be calculated. At step 508, the alternative pickup points can be filtered, for example, by using a maximum walking time and / or distance threshold. The threshold can be determined based on user preferences or default settings (e.g., a maximum walking time of 10 minutes). At step 510, the estimated driving time and distance from each pickup point to the destination location can be calculated. Steps 506 to 510 can be performed with reference to a route planning component 512. The route planning component 512 can be a route module 264 or a part of a route module 264, and / or can be a part of a route server 140. The route planning component 512 can be configured to calculate the estimated time and distance of walking and driving based on the road network geometry. The shortest path technique can be used to obtain the best route and the distance on the route, and then the corresponding driving time of each route can be estimated using a machine learning model based on real-time traffic speed.

[0096] At step 514, an estimated price for traveling from each pickup point to the destination location may be calculated. The calculation may be based on predefined travel time and distance factors for each determined route from each pickup point to the destination location, and may take into account factors such as road taxes or tolls, such as when passing through an electronic road pricing (ERP) gantry. The calculation may be performed by a pricing calculator 516. The pricing calculator 516 may be a pricing module 266 or a part of the pricing module 266, and / or may be a part of the route server 140. At step 518, the optimal pickup point may be marked (e.g., by displaying text that informs of potential cost savings based on the calculation of the estimated price, potential time savings based on the estimated travel time and / or distance, shortest travel distance, shortest walking distance, and other similar factors). How the optimal pickup point is defined may depend on user preferences, and the settings for how the optimal pickup point is defined may be changed and configured by the user.

[0097] Figure 6 An example diagram of a system 600 that can be implemented to adaptively identify an optimal route according to various embodiments is depicted. In general, the system 600 can have multiple services including: a POI service 604 for handling the selection of POIs (e.g., pickup points and drop-off points) based on a starting location and a destination location; a route engine service 606 for handling the determination of a route between the starting location (or each pickup point) and the destination location (or each drop-off point) and then selecting the optimal route; and a price service 608 for handling price selection and calculation. The system can also include map sources 610, such as Karta. TM Maps are provided to provide POI data and route information to POI service 604 and route engine service 606. User selections (e.g., input from user device 602), user preferences (e.g., stored in customer POI preference stream 612), and price savings information (e.g., stored in price information stream 616) can be saved to data lake 614 for reference, thereby ensuring that the determination of the best route is consistent with the user's indicated preferences.

[0098] The system 600 may be configured to list a set of feasible pickup points based on defined optimization criteria, such as distance to the starting location, price and / or time required to get from the pickup point to the starting location, price and / or time from the pickup point to the user's selected destination location and / or drop-off point, and other similar criteria. In order to minimize inconvenience to the user, but also to suggest cheaper or faster pickup point alternatives, the system 600 may arrange the most likely selection (selected by the user) and the best pickup point and / or the best drop-off point next to each other and visually display these options on the screen for the user to consider and make a selection. Additional tags may be added to the pickup points (e.g., Figure 4A 406) to provide the user with additional information (such as, for example, "Save -$2") to help the user make a more informed decision.

[0099] Figure 7 An example flow chart of a method for adaptively identifying an optimal route according to various embodiments is shown. In step 702, one or more pickup points are determined based on historical data related to a starting location, the starting location being a location indicated in a ride request from the starting location to a destination location. In step 704, one or more routes are determined between each of the determined one or more pickup points and the destination location indicated in the ride request. In step 706, an optimal route is identified from the one or more routes based on at least one of the fastest route, the cheapest route, the shortest route, and the shortest walking distance.

[0100] Fig. 8AAn example computer system 1400 is depicted, according to which the described route server 140 can be practiced. The computer system 1400 includes a computer module 1401. An external modulator-demodulator (modem) transceiver device 1416 can be used by the computer module 1401 to communicate to and from a communication network 1420 via a connection 1421. The communication network 1420 can be a wide area network (WAN), such as the Internet, a cellular telecommunications network, or a dedicated WAN. In the case where the connection 1421 is a telephone line, the modem 1416 can be a traditional "dial-up" modem. Alternatively, in the case where the connection 1421 is a high-capacity (e.g., cable) connection, the modem 1416 can be a broadband modem. A wireless modem can also be used for wireless connection to the communication network 1420.

[0101] 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 a semiconductor random access memory (RAM) and a semiconductor read-only memory (ROM). The computer module 1401 also includes an interface 1408 for an external modem 1416. In some implementations, the modem 1416 may be incorporated into the computer module 1401, for example, into the interface 1408. The computer module 1401 also has a local network interface 1411 that permits the computer system 1400 to be coupled to a local area communication network 1422, known as a local area network (LAN), via a connection 1423. As shown in FIG. Fig. 8A As shown in FIG. 1 , the local communication network 1422 may also be coupled to the wide area network 1420 via a connection 1424, which typically includes a so-called "firewall" device or a device with similar functions. The local network interface 1411 may include an Ethernet circuit card, wireless device or IEEE 802.11 wireless device; however, for interface 1411, various other types of interfaces may be practiced.

[0102] The I / O interface 1408 may provide either or both of a serial and parallel connection, the former typically being implemented in accordance with the Universal Serial Bus (USB) standard and having a corresponding USB connector (not shown). A storage device 1409 is provided and typically includes a hard disk drive (HDD) 1410. Other storage devices, such as floppy disk drives and tape drives (not shown) may also be used. An optical disk drive 1412 is typically provided to act as a non-volatile data source. For example, portable memory devices (such as optical disks, USB-RAM, portable external hard disk drives, and floppy disks) may be used as appropriate data sources for the system 1400.

[0103] The components 1405 to 1412 of the computer module 1401 typically communicate via the interconnection bus 1304 and in a manner that enables conventional operating modes of the computer system 1400 known to those skilled in the relevant art. For example, the processor 1405 is coupled to the system bus 1404 using connection 1418. Likewise, the memory 1406 and the optical drive 1412 are coupled to the system bus 1404 via connection 1419. Examples of computers on which the described apparatus may be practiced include IBM-PC and compatible machines, Sun Sparcstation, Apple or similar computer systems.

[0104] The method 700 performed by the route server 140 can be implemented using the computer system 1400. These processes can be implemented as one or more software applications 1433 that can be executed within the computer system 1400. Specifically, the sub-processes 400, 500 and 600 are affected by instructions in the software 1433 executed within the computer system 1400. The software instructions can be formed into one or more code modules, each code module for performing one or more specific tasks. The software can also be divided into two separate parts, where the first part and the corresponding code module perform the method 700, and the second part and the corresponding code module manage the user interface between the first part and the user.

[0105] The software may be stored in a computer readable medium, including, for example, the storage device described below. The software is loaded from the computer readable medium into the computer system 1400 and then executed by the computer system 1400. A computer readable medium with such software or a computer program recorded on a computer readable medium is a computer program product. The use of a computer program product in the computer system 1400 preferably implements an advantageous device for the route server 140.

[0106] 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., a CD-ROM) 1425 read by the optical disk drive 1412. A computer readable medium with such software or a computer program recorded on a computer readable medium is a computer program product. The use of the computer program product in the computer system 1400 preferably implements a device for the route server 140.

[0107] In some examples, the application 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 network 1420 or 1422. Further, the software may also be loaded into the computer system 1400 from other computer-readable media. A computer-readable storage medium is 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 tapes, optical disks, hard disk drives, ROMs or integrated circuits, USB memories, magneto-optical disks, or computer-readable cards (such as PCMCIA cards), etc., whether such devices are internal or external to the computer module 1401. Examples of transient or non-tangible computer-readable transmission media that may also be involved in providing software, application programs, instructions and / or data to the computer module 1401 include radio or infrared transmission channels and network connections to another computer or networked device, as well as the Internet or intranet including information recorded on email transmissions and websites, etc.

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

[0109] It should be understood that the structural background of computer system 1400 (i.e., route server 140) is presented by way of example only. Therefore, in some arrangements, one or more features of computer system 1400 may be omitted. In addition, in some arrangements, one or more features of computer system 1400 may be combined together. In addition, in some arrangements, one or more features of computer system 1400 may be separated into one or more component parts.

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

[0111] refer to Figure 1 , the transaction processing module 806 performs the function of communicating with the requester device 102 and the provider device 104; and the acquirer server 106 and the issuer server 110 receive and send transactions, ride requests, or other similar messages, respectively. The transaction processing module 806 can be configured to handle processes related to transaction accounts by, for example, forwarding data and information associated with the transaction to other servers in the system 100 (such as the route server 140). In an example, instead of the requester device 102, the transaction processing module 806 can transmit data related to a request message such as a ride request (e.g., date, time, starting location, destination location, and other similar data) to the route server 104. The transaction processing module 806 can use a variety of different protocols and procedures in order to process payment and / or travel coordination requests.

[0112] Fig.10 An alternative implementation of the route server 140 (i.e., computer system 1400) is shown. In an alternative implementation, the route server 140 can be generally described as a physical device including at least one processor 902 and at least one memory 904 including computer program code. The at least one memory 904 and the computer program code are configured to, together with the at least one processor 902, cause the route server 140 to perform the operations described in the method 700. The route server 140 may also include a data module 906, a POI module 908, a route module 910, a pricing module 912, and an identification module 914. The memory 904 stores the computer program code, which the processor 902 compiles to cause each of the modules 906 to 914 to perform their respective functions.

[0113] refer to Figures 1 to 7 , the POI module 908 performs the function of determining one or more pickup points based on historical data associated with a starting location, which is a location indicated in a ride request from the starting location to the destination location.

[0114] refer to Figures 1 to 7, the route module 910 performs the function of determining one or more routes between each of the determined one or more pickup points and the destination location indicated in the ride request.

[0115] refer to Figures 1 to 7 , the pricing module 912 performs the function of calculating an estimated price for a ride from each of one or more pickup points to a destination location.

[0116] refer to Figures 1 to 7 The identification module 914 performs a function of adaptively identifying an optimal route from one or more routes based on at least one of the cheapest route, the fastest route, the shortest route, and the shortest walking distance.

[0117] In an implementation, the historical data may be stored in the reference database 150. The historical data may indicate multiple pickup points and location information of each of the multiple pickup points, and the POI module 908 may also be configured to select one or more pickup points close to the starting location from the multiple pickup points based on the location information.

[0118] In an implementation, determining one or more routes by the route module 910 may also include calculating a first set of estimated times and distances for walking from a starting location to each of one or more pickup points, and a second set of estimated times and distances for riding from each of the one or more pickup points to a destination location.

[0119] In an implementation, the historical data may also indicate a plurality of drop-off points and location information of each of the plurality of drop-off points, and the POI module 908 may also be configured to determine one or more drop-off points close to the destination location based on the location information. The route module 910 may also be configured to determine one or more routes including one or more routes between each of the determined one or more pickup points and each of the determined one or more drop-off points, and calculate a second set of estimated times and distances based on riding from each of the one or more pickup points to each of the one or more drop-off points.

[0120] In an implementation, identifying the best route by the identification module 914 may also include identifying a route with the shortest time or distance as the best route from one or more routes based on the first set of estimated time and distance and / or the second set of estimated time and distance.

[0121] In an implementation, determining one or more routes by the route module 910 may also include: calculating a third set of estimated times and distances for walking from each of the one or more drop-off points to the destination location, and identifying the best route by the identification module 914 may also include: identifying a route with the shortest time or distance as the best route from the one or more routes based on the first set of estimated times and distances, the second set of estimated times and distances, and / or the third set of estimated times and distances.

[0122] In an implementation, determining one or more routes by the route module 910 may also include: calculating an estimated price for riding from each of one or more pickup points to a destination location by the pricing module 912, and identifying the best route by the identification module 914 may also include: identifying the cheapest route from one or more routes as the best route based on the estimated price.

[0123] refer to Figures 1 to 7 , the data module 906 performs the function of receiving data and information from the requester device 102, the provider device 104, the transaction processing server 108, the reference database 150, the cloud, and other information sources to facilitate the method 700. For example, the data module 906 can be configured to receive data and information required to process the request to adaptively identify the best route from the requester device 102, the provider device 104, the transaction processing server 108, the reference database 150, and / or other information sources. The data module 906 can also be configured to retrieve the data required for the request from the reference database 150, other databases that can be specified by the data request, and / or other information sources. The data module 906 can also be configured to send the information related to the data retrieved in response to the request to the requester device 102, the provider device 104, the transaction processing server 108, or other destinations where the information is needed. The data module 906 can also be configured to communicate with each of the POI module 908, the route module 910, the pricing module 912, and the identification module 914 and store data and information. Alternatively, all tasks and functions required to facilitate method 700 may be performed by a single processor 902 of route server 140 .

[0124] Figure 8BA general purpose computer system 1500 is depicted on which the described combined transaction processing server 108 and route server 140 can be implemented. The computer system 1500 includes a computer module 1501. An external modulator-demodulator (modem) transceiver device 1516 can be used by the computer module 1501 to communicate to and from a communication network 1520 via a connection 1521. The communication network 1520 can be a wide area network (WAN) such as the Internet, a cellular telecommunications network, or a dedicated WAN. In the case where the connection 1521 is a telephone line, the modem 1516 can be a traditional "dial-up" modem. Alternatively, in the case where the connection 1521 is a high capacity (e.g., cable) connection, the modem 1516 can be a broadband modem. A wireless modem can also be used for wireless connection to the communication network 1520.

[0125] 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 a semiconductor random access memory (RAM) and a semiconductor read-only memory (ROM). The computer module 1501 also includes an interface 1508 for an external modem 1516. In some implementations, the modem 1516 may be incorporated into the computer module 1501, for example, into the interface 1508. The computer module 1501 also has a local network interface 1511 that permits the computer system 1500 to be coupled to a local area communication network 1522, known as a local area network (LAN), via connection 1523. As shown in FIG. 8D , the local communication network 1522 may also be coupled to a wide area network 1520 via connection 1524, which will typically include a so-called "firewall" device or a device of similar functionality. The local network interface 1511 may include an Ethernet circuit card, wireless device or IEEE 802.11 wireless device; however, for interface 1511, various other types of interfaces may be practiced.

[0126] The I / O interface 1508 may provide either or both of a serial and parallel connection, the former typically being implemented in accordance with the Universal Serial Bus (USB) standard and having a corresponding USB connector (not shown). A storage device 1509 is provided and typically includes a hard disk drive (HDD) 1510. Other storage devices, such as floppy disk drives and tape drives (not shown) may also be used. An optical disk drive 1512 is typically provided to act as a non-volatile data source. For example, portable memory devices (such as optical disks, USB-RAM, portable external hard disk drives, and floppy disks) may be used as appropriate data sources for the system 1500.

[0127] The components 1505 to 1512 of the computer module 1501 typically communicate via an interconnection bus 1504 and in a manner that enables conventional operating modes of the computer system 1500 known to those skilled in the relevant art. For example, the processor 1505 is coupled to the system bus 1504 using connection 1518. Likewise, the memory 1506 and the optical drive 1512 are coupled to the system bus 1504 via connection 1519. Examples of computers on which the described apparatus may be practiced include IBM-PC and compatible machines, Sun Sparcstation, Apple or similar computer systems.

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

[0129] The software may be stored in a computer readable medium, including, for example, the storage device described below. The software is loaded from the computer readable medium into the computer system 1500 and then executed by the computer system 1500. A computer readable medium having such software or a computer program recorded on a computer readable medium is a computer program product. The use of the computer program product in the computer system 1500 preferably implements an advantageous apparatus for combining transaction processing and route servers.

[0130] 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., a CD-ROM) 1525 read by the optical disk drive 1512. A computer readable medium having such software or a computer program recorded on a computer readable medium is a computer program product. The use of the computer program product in the computer system 1500 preferably implements an apparatus for a combined transaction processing and route server.

[0131] In some examples, the application 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 network 1520 or 1522. Further, the software may also be loaded into the computer system 1500 from other computer-readable media. A computer-readable storage medium is 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 tapes, optical disks, hard disk drives, ROMs or integrated circuits, USB memories, magneto-optical disks, or computer-readable cards (such as PCMCIA cards), etc., whether such devices are internal or external to the computer module 1501. Examples of transient or non-tangible computer-readable transmission media that may also be involved in providing software, application programs, instructions and / or data to the computer module 1501 include radio or infrared transmission channels and network connections to another computer or networked device, as well as the Internet or intranet including information recorded on email transmissions and websites, etc.

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

[0133] It should be understood that the architectural context of computer system 1500 (i.e., combined transaction processing and routing server 1500) is presented merely as an example. Thus, in some arrangements, one or more features of server 1500 may be omitted. Additionally, in some arrangements, one or more features of server 1500 may be combined together. Additionally, in some arrangements, one or more features of server 1500 may be separated into one or more component parts.

[0134] Fig.11An alternative implementation of a combined transaction processing and route server (i.e., computer system 1500) is shown. In an alternative implementation, the combined transaction processing and route server can be generally described as a physical device including at least one processor 1002 and at least one memory 904 including computer program code. The at least one memory 1004 and the computer program code are configured to, together with the at least one processor 1002, cause the combined transaction processing and route server to perform the operations described in the steps of method 700. The combined transaction processing and route server can also include a transaction processing module 806, a data module 906, a POI module 908, a route module 910, a pricing module 912, and an identification module 914. The memory 1004 stores computer program code, which the processor 1002 compiles to cause each of the modules 806 to 912 to perform their respective functions. The transaction processing module 806 performs operations related to Fig. 9 The data module 906, POI module 908, route module 910, pricing module 912 and identification module 914 perform the same functions as those described for the same transaction processing module in FIG. Fig.10 The same functions are described in the same corresponding modules.

[0135] It will be appreciated by those skilled in the art that various variations and / or modifications may be made to the disclosure shown in the specific embodiments without departing from the scope of the broadly described specification. Therefore, the present embodiments are to be considered in all aspects as illustrative and not restrictive.

Claims

1. A method for adaptively identifying an optimal route, comprising: determining, by a processor, one or more pickup points based on historical data associated with a starting location, the starting location being a location indicated in a ride request from the starting location to a destination location; determining, by the processor, one or more routes between each of the determined one or more pickup points and the destination location indicated in the ride request; as well as An optimal route is adaptively identified, by the processor, from the one or more routes based on at least one of a cheapest route, a quickest route, a shortest route, and a shortest walking distance.

2. The method according to claim 1, wherein: The historical data indicates a plurality of pickup points and location information of each of the plurality of pickup points, and determining the one or more pickup points further comprises: selecting one or more pickup points close to the starting location from the plurality of pickup points based on the location information.

3. The method according to claim 1, wherein: Determining the one or more routes also includes calculating a first set of estimated times and distances for walking from the starting location to each of the one or more pickup points, and a second set of estimated times and distances for riding from each of the one or more pickup points to the destination location.

4. The method according to claim 3, wherein: The historical data indicates a plurality of drop-off points and location information of each of the plurality of drop-off points, and determining the one or more routes further comprises: determining one or more drop-off points near the destination location based on the location information, determining the one or more routes, the one or more routes comprising one or more routes between each of the determined one or more pickup points and each of the determined one or more drop-off points; and The second set of estimated times and distances is calculated based on riding from each of the one or more pickup points to each of the determined one or more drop-off points.

5. The method according to claim 3 or 4, wherein: Identifying the best route further comprises identifying a route with the shortest time or distance from the one or more routes as the best route based on the first set of estimated times and distances and / or the second set of estimated times and distances.

6. The method according to claim 4, wherein: Determining the one or more routes also includes: calculating a third set of estimated times and distances for walking from each of the one or more drop-off points to the destination location, and identifying the best route also includes: identifying a route with the shortest time or distance from the one or more routes as the best route based on the first set of estimated times and distances, the second set of estimated times and distances, and / or the third set of estimated times and distances.

7. The method according to claim 1, wherein: Determining the one or more routes also includes: calculating an estimated price of riding from each of the one or more pickup points to the destination location, and identifying the best route also includes: identifying the cheapest route from the one or more routes as the best route based on the estimated price.

8. A system for adaptively identifying an optimal route, the system comprising: at least one processor; as well as at least one memory including computer program code; The at least one memory and the computer program code are configured to, with the at least one processor, cause the system to at least: determining one or more pickup points based on historical data associated with a starting location, the starting location being a location indicated in a ride request from the starting location to a destination location; determining one or more routes between each of the determined one or more pickup points and the destination location indicated in the ride request; as well as An optimal route is adaptively identified from the one or more routes based on at least one of a cheapest route, a quickest route, a shortest route, and a shortest walking distance.

9. The system according to claim 8, wherein: The historical data indicates a plurality of pickup points and location information of each of the plurality of pickup points, and determining the one or more pickup points further comprises: selecting one or more pickup points close to the starting location from the plurality of pickup points based on the location information.

10. The system according to claim 8, wherein: Determining the one or more routes also includes calculating a first set of estimated times and distances for walking from the starting location to each of the one or more pickup points, and a second set of estimated times and distances for riding from each of the one or more pickup points to the destination location.

11. The system according to claim 10, wherein: The historical data indicates a plurality of drop-off points and location information of each of the plurality of drop-off points, and determining the one or more routes further comprises: determining one or more drop-off points near the destination location based on the location information, determining the one or more routes, the one or more routes comprising one or more routes between each of the determined one or more pickup points and each of the determined one or more drop-off points; and The second set of estimated times and distances is calculated based on riding from each of the one or more pickup points to each of the determined one or more drop-off points.

12. The system according to claim 10 or 11, wherein: Identifying the best route further comprises identifying a route with the shortest time or distance from the one or more routes as the best route based on the first set of estimated times and distances and / or the second set of estimated times and distances.

13. The system according to claim 11, wherein: Determining the one or more routes also includes: calculating a third set of estimated times and distances for walking from each of the one or more drop-off points to the destination location, and identifying the best route also includes: identifying a route with the shortest time or distance from the one or more routes as the best route based on the first set of estimated times and distances, the second set of estimated times and distances, and / or the third set of estimated times and distances.

14. The system according to claim 8, wherein: Determining the one or more routes also includes: calculating an estimated price of riding from each of the one or more pickup points to the destination location, and identifying the best route also includes: identifying the cheapest route from the one or more routes as the best route based on the estimated price.

Images