Computer-implemented method and server

Abstract

The invention relates to a computer implementation method and a server. A system comprising: a communication server; at least one user communication device having an associated user and configured to initiate a reservation including a reserved boarding location; at least one driver communication device having an associated driver vehicle and configured to provide driver vehicle location data; and a communication network facility configured to establish communication with the communication server, the at least one user communication device, and the at least one driver communication device; wherein the communication server comprises at least one processor, at least one memory, the server being configured to: cluster the planned reservation location and the driver vehicle location into a plurality of batches according to an estimated time of arrival between each vehicle and an adjacent planned reservation; if the number of appointments for the respective batch exceeds a predetermined threshold, the respective batch is clustered into more batches, and the planned appointments and available vehicles are individually allocated in each batch.

Description

Technical Field

[0001] This invention generally relates to the field of logistics and / or transportation. One aspect of the invention relates to a computer-implemented method. Another aspect of the invention relates to a server. Background Technology

[0002] In terms of logistics, making full use of available delivery vehicles can be useful for handling a large number of concurrent orders. Optimal allocation may involve assigning multiple pickup locations and delivery points to a single delivery vehicle to ensure the most efficient overall results.

[0003] In terms of transportation, it can be useful to make full use of available transport vehicles for a large number of concurrent passengers. Optimal allocation may involve including a large number of nearby transport vehicles and passengers in a single batch, and then solving for optimal allocation to minimize the waiting time for transport vehicles to reach passengers.

[0004] To achieve optimal allocation, it may be necessary to divide the geographic region into smaller areas to reduce the computational complexity of real-time allocation and minimize any latency in vehicle allocation. There is an inherent trade-off between reducing the size of the candidate pool to form multiple batches to reduce latency and / or computational complexity, compared to optimizing overall efficiency.

[0005] Existing technologies attempt to address this problem by periodically updating, statically partitioning geographic areas into multiple regions for batch processing. This periodic pre-partitioning can be based on historical transaction density so that each region has roughly the same expected transaction volume. The computational requirements for analyzing historical transactions are significant, and inconsistencies between real-time and historical transaction data can introduce significant inefficiencies. For example, during peak hours, areas in a CBD can have transaction volumes far exceeding the average for the time period historically followed.

[0006] The goal is to provide more efficient or effective solutions in certain applications. Summary of the Invention

[0007] Embodiments of the present invention may be presented as in any of the independent claims. Some optional features are defined in the dependent claims.

[0008] The implementation of the technology disclosed in this invention can provide significant technical advantages. One or more aspects of these advantages may include one or more of the following:

[0009] • Reduce the likelihood of racing conditions, which refer to situations where a driver assigns multiple bookings simultaneously. For example, in existing systems, if two nearby bookings are assigned to two different regions through partitioning, each region can be processed in parallel. These regions may share the same candidate drivers, and the two bookings may be assigned to the same driver during the allocation process. This leads to racing conditions because a driver can only accept one booking.

[0010] • Reduce Global Batch Clearing (GBC) rollback. In existing systems, bookings can accumulate over a specific time period, and then all candidate drivers for each booking are retrieved, and an allocation decision is made to achieve global optimality. However, rollback can occur when the number of bookings is high but the sharding depth is low (e.g., we cannot categorize bookings into many smaller groups), which can result in too many bookings in one area after sharding. Existing systems may have a cap on the number of bookings that can be processed in a single request. When this cap is exceeded, existing systems may roll back to a simpler strategy, such as batch clearing (BC), instead of global batch clearing (GBC), which assigns bookings to the nearest driver.

[0011] • Remove GBC-enabled boundaries for new cities. Here, boundaries refer to the geographical area where GBC is activated.

[0012] • Technical solutions to address the issue of inaccurate pre-regioning based on geographic location, and to process orders more quickly.

[0013] • Technical issues related to inaccurate pre-segmentation based on geographic location, and technical solutions to reduce communication volume due to fewer canceled orders.

[0014] • Technical solutions to reduce data center energy demands by addressing the technical challenges of inaccurate pre-partitioning based on geographic location. Specifically, this involves statically dividing geographic regions into multiple areas for batch processing, if periodic updates can be completely avoided.

[0015] • A technological solution to reduce greenhouse gas emissions by addressing the technical challenges of inaccurate pre-zoning based on geographic location. Because orders are restricted to those with the lowest estimated arrival times, drivers may have fewer unnecessary trips, or merchants may have fewer unnecessary sales, thus avoiding greenhouse gas emissions from any unnecessary travel or product manufacturing.

[0016] • Addressing the technical challenges of inaccurate pre-partitioning based on geographic location, and providing technical solutions to reduce data center storage requirements. Specifically, this involves statically dividing geographic regions into multiple areas for batch processing, where periodic updates can be completely avoided.

[0017] • Technical solutions to reduce the estimated time of arrival (ETA) for a given region, addressing the technical problem of inaccurate pre-segmentation based on geographic location.

[0018] • Technical solutions to address the problem of inaccurate training data by allowing drivers to reach passengers in the shortest possible time, thereby avoiding passenger waiting time and / or excessive driver travel time.

[0019] • Technical solutions to improve data quality and accuracy addressing the technical challenges of inaccurate pre-partitioning based on geographic location.

[0020] The technical problem of inaccurate pre-partitioning based on geographic location reduces the server hardware requirements needed to address this issue. Less hardware manufacturing can reduce greenhouse gas emissions.

[0021] • This addresses the technical challenges of imprecise pre-partitioning based on geographic location, and provides a technical solution that reduces bandwidth requirements. Less communication bandwidth can reduce greenhouse gas emissions.

[0022] • Technical solutions that reduce latency address the technical problem of inaccurate pre-partitioning based on geographic location.

[0023] In an exemplary implementation, the functionality of the technology disclosed in this invention can be implemented in software running on a handheld communication device, such as a mobile phone. The software implementing the functionality of the technology disclosed in this invention can be included in an "app"—a computer program or computer program product—which the user downloads from an online store. For example, when running on a user's mobile phone, the phone's hardware features can be used to implement the functions described below, such as establishing a secure communication channel using the phone's transceiver components.

[0024] In an exemplary embodiment, the functionality of the technology disclosed in this invention can be implemented in software running on a server communication device (e.g., one or more servers, one or more virtual machines, one or more processors, or a cloud computing platform), which communicates with applications running on user terminals, driver terminals, and / or merchant terminals (e.g., mobile phones). The software implementing the functionality of the technology disclosed in this invention can be contained in a computer program or computer program product. The server communication device establishes a secure communication channel with the driver, merchant, and / or user terminal for assigning users and / or merchants to drivers. Attached Figure Description

[0025] The present invention will be described by way of example only and with reference to the accompanying drawings, wherein:

[0026] Figure 1 This is a schematic block diagram illustrating an exemplary delivery / transportation service.

[0027] Figure 2 This is a schematic block diagram illustrating an exemplary communication server used for delivery / transportation services.

[0028] Figure 3 It is a map showing the distribution of reservations and available drivers within a set time window.

[0029] Figure 4 This is a schematic diagram of the reservation allocation system used by the Allocation Engine (AE).

[0030] Figure 5 It is a list of fragmented files.

[0031] Figure 6 This is a schematic diagram of the first depth of the segmented map.

[0032] Figure 7 This is a schematic diagram of the third depth of the segmented map.

[0033] Figure 8 This is a schematic diagram of the seventh depth of the segmented map.

[0034] Figure 9 This is a diagram of a file split into segments.

[0035] Figure 10 This is a chart showing the Global Batch Clearing (GBC) rollback overload.

[0036] Figure 11 This is a schematic diagram of a reservation allocation system according to an exemplary embodiment.

[0037] Figure 12 This is a schematic diagram of disconnected clustering.

[0038] Figure 13 This is a schematic diagram of a modified greedy depth-first search based on an exemplary embodiment. Detailed Implementation

[0039] The techniques described in this invention are primarily referenced to their use in vehicle reservation allocation. This can effectively optimize overall efficiency.

[0040] Figure 1 An exemplary structure of system 100 is shown, in which multiple users each have a communication device 104, multiple merchants each have a communication device 109, multiple drivers each have a user interface communication device 106, a server 102 (or a geographically distributed server) of a delivery platform provider, and a communication network 108 connecting each component. Each user communicates with server 102 using a user software application (App) on communication device 104. Similarly, drivers and merchants can use the app on their devices 106, 109.

[0041] Platform providers may use System 100 for logistics or transportation management purposes. This could involve delivery or e-commerce-based transactions where customers book food, products, or other physical items for delivery. It could also involve transportation where multiple nearby users can book a vehicle, which is then shared to transport each customer to multiple nearby destinations, or where each customer has their own vehicle. Typically, System 100 used by platform providers will facilitate transactions between users and goods or service providers (such as drivers or merchants). System 100 can then be used to simultaneously optimize the allocation of available vehicles (including different types of available vehicles) for transporting orders and / or passengers.

[0042] For delivery or e-commerce-based transactions, user device 104 can support user input of queries containing keywords for items of interest and delivery addresses. Users can see a list of merchants and / or items offered by merchants and order items from them. Merchants can contact server 102 using merchant device 109, which provides information about their items and receives orders for each confirmed transaction. Drivers contact server 102 using driver device 106. Driver device 106 allows drivers to indicate the availability of delivery jobs they accept, information about their vehicles, and their location. Server 102 can then match drivers and deliveries based on factors such as: merchant and driver geolocation, maximizing revenue, user or driver feedback ratings, weather, driving conditions, traffic levels / accidents, relevant demand, environmental impact, and / or supply levels. A specific delivery cost and an approximate delivery ETA may be offered to the user. If the user accepts the offered proposal, server 102 can initiate a payment authorization process. If authorization is approved, the merchant will then be notified and instructed to provide the goods to the driver for pickup. The selected driver will then be notified and instructed to proceed to the pickup location to collect the goods. Drivers can be optimized to pick up goods from multiple merchants along a single, efficient route and deliver a series of orders. During delivery, user device 104, driver device 106, merchant device 109, and server 102 can update real-time trip information, including the driver's vehicle's real-time location, destination, driver fees, and / or other trip-related information. After the trip, driver device 106 can send a confirmation to server 102 that the trip has ended. Once the transaction is approved and / or the delivery is completed, user device 104, driver device 106, merchant device 109, and server 102 can update the details of the completed financial transaction. This allows for efficient resource allocation, as the available driver team is optimized for user demand in each region.

[0043] For transportation, user device 104 can allow users to input their pick-up location, destination address, one or more service parameters, and / or post-trip information (e.g., reviews). One or more service parameters may include the number of vehicle seats, vehicle type, environmental impact level, and / or desired transportation service. Each driver communicates with server 102 using a driver app on communication device 106. The driver app allows drivers to indicate the availability of jobs they receive, information about their vehicles, their location, and / or post-trip information (e.g., reviews). For example, server 102 can then match drivers and users based on: user and driver geographic location, optimal revenue, user or driver feedback, weather, driving conditions, traffic levels / accidents, relevant demand, environmental impact, and / or supply levels. Specific transportation costs or ranges and approximate ETAs can be offered to users based on different vehicle types. If the user accepts the offered proposal, the system can proceed to the payment authorization process. If authorization is approved, the selected driver will be notified and instructed to pick up the user / passenger at the pick-up location. This can be optimized for multiple passengers wishing to share a vehicle to reduce trip costs, or for a single vehicle. During the trip, user device 104, driver device 106, and / or server 102 can update real-time trip information, including the driver's vehicle's real-time location, destination, trip cost, and / or other trip-related information. At the end of the trip, driver device 106 can send a confirmation to server 102 that the trip has ended. Once the transaction is approved and / or the trip is completed, user device 104, driver device 106, and / or server 102 can update the details of the completed financial transaction. This allows for efficient resource allocation because the available driver team is optimized for user demand in each region.

[0044] refer to Figure 2 , described Figure 2 Further details of the components in the system. Communication device 100 includes a communication server 102, and it may include user communication device 104, merchant communication device 109, and driver communication device 106. These devices are connected to communication network 108 (e.g., the Internet) via their respective communication links 110, 111, 112, and 114, such as Internet Protocol, for example. Communication devices 104, 106, and 109 may communicate via communication networks and / or protocols, including cellular communication networks, local area networks (LANs), wide area networks (WANs), private data networks, virtual private networks (VPNs), fiber optic connections, laser communication, microwave communication, satellite communication, Bluetooth, Wi-Fi, near field communication (NFC), etc., but for clarity, these are not mentioned in the text. Figure 2 The details are explained in the text.

[0045] exist Figure 2 In the illustrated example, the communication server device 102 may include multiple independent components, including but not limited to, one or more microprocessors 116, one or more memories 118 (e.g., volatile memory, such as RAM), and / or long-term, non-volatile, or persistent memory 119 (e.g., solid-state drive (SSD) or hard disk drive (HDD)), for loading executable instructions 120 that define the functions performed by the server device 102 under the control of the microprocessor 116. The communication server device 102 also includes one or more input / output modules 122 that allow the server to communicate over a communication network 108. One or more user interfaces 124 are provided for administrator control, and these interfaces may include, for example, computer peripherals such as a monitor, computer keyboard, etc.

[0046] The communication server device 102 can be as follows: Figure 2 A single server is schematically shown. Alternatively, the functions performed by server device 102 may be distributed among multiple physically or logically independent server components. In the context of this specification, "server," "the server," or "the server" refers to a computer program running on suitable hardware that can receive requests (e.g., requests from electronic devices) over a network, and execute or cause such requests to be executed. This hardware may be implemented as one or more physical computers, a physical computer system, one or more virtual machines, or a cloud-based server network. In this context, the use of the term "server" does not imply that every task (e.g., received instructions or requests) or any particular task is received, executed, or caused to be executed by the same server (i.e., the same software and / or hardware). It means that any number of software elements or hardware devices may be involved in receiving / sending, executing, or causing the execution of any task or request, or the consequences of any task or request; and all such software and hardware may be one server or multiple servers. References to other systems, software or hardware components, such as processors, memory, storage, etc., are also made in this manner.

[0047] The transactions mentioned in this article can be payments made for any service offered by a platform provider, such as ride-hailing, carpooling, food delivery, e-commerce delivery, and so on. A transaction can include any interaction involving a user, driver, or merchant requesting transportation, receiving orders or deliveries, or other communications with a platform provider to pay fees to the platform provider for their services or products.

[0048] Server device 102 may also include one or more databases 126, which are stored in volatile memory 118 and / or non-volatile memory 119 for storing data, including merchant behavior, geographic information, images, products, points of interest, users, drivers, merchants, transaction data, aggregated data or parameters, payment data, and other relevant data. The data may be stored in data structures as needed by the application, or in further details as described below. Database 126 may be replicated, distributed, sharded, or otherwise optimized as needed by the application.

[0049] User communication device 104 may include multiple independent components, including but not limited to one or more microprocessors 128 for loading executable instructions 132, memory 130 (e.g., volatile memory, such as RAM), and / or long-term memory (e.g., flash memory or solid-state drive (SSD)), which, under the control of microprocessor 128, define the functions performed by user communication device 104. User communication device 104 also includes an input / output module 134 that allows user communication device 104 to communicate on communication network 108. A user interface 136 is provided for user control. For example, if user communication device 104 is a smartphone or tablet device, user interface 136 will have a touch panel screen, a common configuration in many smartphones and other handheld devices. Alternatively, for example, if user communication device 104 is a desktop or laptop computer, user interface 136 may have, for example, computer peripherals such as a monitor display, computer keyboard, etc.

[0050] For example, merchant communication device 109 may be a smartphone or tablet device with the same or similar hardware structure as user communication device 104.

[0051] For example, the driver communication device 106 can be a smartphone or tablet device with the same or similar hardware structure as the user communication device 104. Alternatively, its functionality can be integrated into customized devices, such as taxi fleet management terminals or other logistics terminals.

[0052] The aforementioned drivers can also be remote or autonomous drivers. Examples include self-driving vehicles, drones (UAVs), and unmanned aerial vehicles. In this case, the merchant may be responsible for loading orders into the delivery vehicle, or this task may be automated.

[0053] Therefore, it is understandable that Figure 1 and Figure 2 The foregoing description illustrates and describes a system 100, which includes:

[0054] One communication server 102;

[0055] At least one user communication device 104, having an associated vehicle location; and

[0056] At least one driver communication device 106, having an associated reservation location and / or boarding location;

[0057] Communication network facility 108 is configured to establish communication with communication server 102, at least one user communication device 104 and at least one driver communication device 106;

[0058] The communication server 102 includes at least one processor and at least one memory 118. The server is configured to execute instructions stored in the at least one memory 118 under the control of one or more of the at least one processor 116, to:

[0059] Based on the estimated arrival time between each available vehicle location and the neighboring planned reservation locations, the planned reservation locations and available vehicle locations are clustered into multiple batches;

[0060] If the number of reservations for a given batch exceeds a predetermined threshold, then that batch will be clustered into more batches, and

[0061] The planned reservations and available vehicles are allocated separately within each batch.

[0062] Furthermore, it is understandable that Figure 11 A method executed in a communication server device 102, under the control of a microprocessor 116 of the communication server device 102, is shown and described, comprising:

[0063] Receive real-time data related to the planned reservation location and the location of available vehicles within the geographic area;

[0064] Based on the estimated arrival time between each available vehicle location and the nearest planned reservation location, the planned reservation locations and available vehicle locations are clustered into multiple batches;

[0065] If the number of reservations for a given batch exceeds a predetermined threshold, the batch will be clustered into more batches, and

[0066] The planned reservations and available vehicles are allocated separately within each batch.

[0067] Divide geographical areas to allocate reservations

[0068] Sharding or partitioning can be used to divide a large number of appointment-driver pairs across geographic regions for logistics. For example, this geographic region could be a city. Making optimizations in real-time across the entire system would typically be computationally prohibitive. Therefore, partitioning the geographic regions first allows the allocation within each partition to be reduced to chunks that are more manageable for optimization algorithms. This avoids overloading the allocation engine (AE) and causing latency, errors, higher necessary hardware requirements, or reduced network efficiency.

[0069] For example, during peak hours, platform providers may have millions of bookings available within a set time window, and they need to match or assign these bookings to vehicles. This can be illustrated by map 300, which shows the... Figure 3 Within a defined time window, reservations and available drivers are distributed across a geographical area. For example, if the window is a 5-second time period:

[0070] • An AE with reasonable resources cannot handle such a large batch that includes all appointments and drivers.

[0071] • The appointment-driver needs are divided into multiple batches, allowing AE to process each one simultaneously within reasonable resource constraints.

[0072] Each reservation can involve a user who wants to be transported from a pick-up location to a destination. Alternatively, or additionally, each reservation can involve a user or merchant who wants their order transported from a pickup location to a destination.

[0073] Figure 4 Example processing 400 using AE402 is shown. This processing 400 is based on periodically updated, statically partitioned geographic regions or pre-partitioned regions for batch processing. This pre-partitioning can be updated every two weeks using historical appointment data, which statistically divides the region into two areas with an equal number of appointments. For each region or city, multiple statically partitioned files with different depths can be used to process appointments. Figure 5 The document shows an example list of shard files, where each shard file is a JSON file with a key that is the index of the shard and a value that is a geohash6 included in the index.

[0074] The reservation system (BS) 404 starts with the shallowest fragment file to separate reservation-driver pairs and 405 assesses whether the number of reservations-drivers in the current batch exceeds the capacity of the AE (Appointment Authorization Unit). This AE capacity can be manually determined, and for example, can be set to 100 reservations per batch. If this condition is met, BS 404 will gradually move to deeper fragment files to further segment reservations within the target area. The different levels of fragmentation are as follows: Figures 6 to 8As shown. This design allows the number of reservations within each segment to be "usually" evenly distributed.

[0075] Once the partitioning hierarchy 405 is determined within a given time window, each partition, region, or division will be processed by an independent partitioning worker 902, such as... Figure 9 The diagram 900 illustrates this. Each shard worker is a different processor (computation unit) in parallel computing and can be processed simultaneously in AE 402. Each shard worker 902 implements a filtering process 406 (per shard) to select driver candidates based on a specific set of criteria, such that only qualified drivers are included in the assignment. Examples of qualified criteria include drivers close to completing their work, drivers with sufficient cash for a particular type of work (e.g., drivers with cars are better suited for long-distance work than drivers with bicycles), and drivers with faster vehicles for jobs involving long-distance travel. Furthermore, clustering 408 is performed within each shard to partition the graph based on the number of connected components it contains. The end result is that each pre-partitioned shard is segmented into clusters for each set time window in real time. Each cluster is then sent to AE 402 to independently assign appointments to drivers within that cluster. This allows all concurrent appointments to be assigned within an acceptable timeframe, utilizing reasonable computational resources.

[0076] However, this can still lead to one or more of the following problems, including:

[0077] Generating static fragmented files can require a huge amount of computation.

[0078] A single run may take approximately 24 hours to complete.

[0079] After the files are generated, they are used to prepare eligible appointments – the candidate system for driver allocation may still need 2 days to load these changes.

[0080] Static sharding files, because they do not consider actual booking-driver links, can lead to race conditions. For example, in two adjacent batches, a driver might be assigned to two bookings simply because that driver happens to be on the edge of a shard boundary.

[0081] Static fragmented files cannot capture dynamic changes in online supply and demand.

[0082] This will cause Global Batch Clearing (GBC) to revert to Batch Clearing (BC) and allocation.

[0083] Because it has reached its maximum depth, such as Figure 10 The GBC rollback overload diagram is shown in Figure 1000.

[0084] • Static fragment files cannot fully maximize network efficiency in Global Batch Clearing (GBC) because they are hard-segmented without considering connectivity.

[0085] Modified sub-batch processing

[0086] To develop an online method for dynamically separating large numbers of booking-driver pairs within a region without affecting existing booking-driver connections, according to an example implementation, in Figure 4 In this process, static sharding or pre-partitioning can be removed from BS 404 processing. This could involve obtaining information for each candidate appointment and filtering it before any batch processing or clustering. Alternatively, it could involve online clustering methods to dynamically generate disconnected batches.

[0087] Now for reference Figure 11 The example process 1100, utilized by the allocation engine (AE) 1102, is shown. In this case, a first-in-first-out (FIFO) queue 1104 is used to allocate each reservation to a BS worker 1106. Each BS worker performs the following:

[0088] 1. Based on the boarding location and the driver's distance from that boarding location, find nearby candidates.

[0089] 2. Utilize various services to collect information about the booked driver, such as estimated arrival time (eta), commission, and driver's preferred location.

[0090] 3. Summarize the reserved driver information into a batch processing request and send it to AE 1102 for allocation.

[0091] The number of BS workers 1106 is determined by the number of reservations in the queue. Computational resources are dynamic. For example, the number of workers can be increased during peak hours. A large batch 1108 is formed from all reservations within a set time window. This large batch is then clustered into sub-batches using a modified depth-first search (DFS) described below, and these sub-batches are subsequently sent to AE 1102 for optimized allocation.

[0092] This could involve:

[0093] • A modified depth-first search (DFS) is used to form the initial batches or clusters. Computation time can increase linearly with the number of appointment-driver pairs.

[0094] The modified DFS method receives a large batch of reservations and bookings containing all reservation-driver pairs within a region, with the parameter specifying the maximum number of reservations in each batch.

[0095] If the size exceeds the predetermined parameter, the modified DFS will break any batch into smaller sub-batches 1202, 1204, 1206 to minimize the impact on the overall connectivity of the sub-batches 1208, such as... Figure 12 A schematic diagram of the interrupted clustering is shown in 1200.

[0096] Initially modified Depth-First Search (DFS)

[0097] The following list provides symbol qualifiers that will be used in the examples described below:

[0098] • B: Represents the set of nodes that have made reservations.

[0099] • D: Represents the set of nodes for drivers

[0100] • E: Represents the edge set connecting appointment-driver pairs (i.e., drivers are qualified candidates for appointments).

[0101] • G(B, D, E): A graph consisting of node sets B and D and edge set E.

[0102] • G_s(B_s, D_s, E_s): Represents the graph of sub-batch s, where s = 1, 2, 3…

[0103] • B_s: Represents the set of nodes reserved in sub-batch s, where s = 1, 2, 3...

[0104] • D_s: Represents the set of driver nodes in sub-batch s, where s = 1, 2, 3...

[0105] • E_s: Represents the edge set of connecting appointment-driver pairs in sub-batch s, where s = 1, 2, 3…

[0106] • n: The maximum number of reservations allowed in a single subgraph (size (B))

[0107] • b_i: Represents the i-th reserved node in B, where i = 1, 2, 3...

[0108] ·d_j: Represents the node of the j-th driver in D, where j = 1, 2, 3…

[0109] • c_i: Represents the number of drivers connected to reservation b_i, where i = 1, 2, 3…

[0110] ·p_j: Represents the number of appointments connected to driver d_j, where j = 1, 2, 3…

[0111] •eta_ij: Represents the estimated arrival time (eta) between booking b_i and driver d_j.

[0112] We use a modified greedy depth-first search (DFS) to obtain a feasible solution (not guaranteed to be optimal). Given a bipartite graph G(B, D, E), where B represents the set of appointments, D represents the set of drivers, and E represents eligible appointment-driver pairs, with each edge having a weight of eta. We then optimize to find the minimum number of edges that partition E to form a new graph G'(B, D, E') where the size of the largest connected component is n.

[0113] For example:

[0114] 1. For each b_i in B, compute index c_i, and for each d_j in D, compute index p_j.

[0115] 2. Traverse the graph and collect subgraphs G_s(B_s, D_s, E_s):

[0116] a. Start the search from b_i with the smallest c_i, and then collect b_i into B_s.

[0117] b. Check all drivers connected to b_i, and turn to d_j in D-D_s with the smallest p_i, then collect d_j into D_s.

[0118] c. Check all reservations connected to d_j, and turn to the b_i in B-B_s with the smallest b_i, then collect b_i into B_s. Repeat step 2b until the stopping condition is met.

[0119] d. Assume that the two appointments b_1 and b_2 connected to driver d_1 have the same index value, i.e., c_1 = c_2. Then, choose the one with the smaller eta, for example, if eta_1 < 1 / 2.

[0120] If eta_21, then we collect b_1.

[0121] e. In other words, at the beginning, we book appointments based on the connectivity of the appointment (eta is measured by eta, but can be adjusted according to the needs of the application), and the allocation starts from the minimum eta.

[0122] 3. There are two stopping conditions:

[0123] a. If we haven't completed DFS and have already collected n reservations, we need to disconnect some connections between nodes within the sub-batch and the remaining nodes in the main batch:

[0124] i. After collecting the last reservation, use DFS to find all drivers at the end of the D-D_s path, including drivers within D_s. Disconnect these drivers from reservations outside the sub-batch.

[0125] ii. For each driver connected to the last appointment (we have recorded all appointments that have been put into smaller batches, so the last appointment is the last appointment that has not been processed in the larger batch), if the appointment connected to this driver is not connected to any other driver, and this driver is not yet included in D_s, remove this driver from the currently collected D_s.

[0126] b. If we have completed DFS but have not yet reached the maximum number of reservations n, stop directly without disconnecting the connection.

[0127] 4. Once the stopping condition is met, collect B_s and D_s into a batch. Delete all appointments in B_s and D_s, and disconnect all other appointments and drivers in the remaining batches, as well as these in sub-batches. Set B = B - B_s, D = D_s, E = E', where E' is the edge set connecting the remaining appointments and drivers. Repeat from step 3 until all b_i in B have been processed.

[0128] The output of the adjusted greedy depth-first search (DFS) is a sequence of partitioned batches, each containing a set of {sub_batch_id:sub_batch}.

[0129] This exemplary implementation can be Figure 13 As shown in the example, we have a chart containing 6 appointments and 6 drivers. The maximum number of appointments in a batch is set to 3 (n=3). We can divide this chart into 2 sub-batches using an algorithm.

[0130] The eta table in seconds is shown below:

[0131] eta_ij d_1 d_2 d_3 d_4 d_5 d_6 b_1 100 NA 150 NA NA NA b_2 200 100 NA NA 150 NA b_3 NA NA 100 200 NA NA b_4 NA NA NA NA 100 200 b_5 NA NA NA NA 200 100 b_6 NA NA NA NA 250 NA

[0132] For each reservation and driver, calculate c_i for each b_i and p_j for each d_j.

[0133] Traversing the graph based on index values:

[0134] a. Starting with b_6, which has the lowest c_6 = 1, collect b_6 into the first sub-batch B_1.

[0135] b. Move to d_5 connected to b_6 and collect d_5 into D_1.

[0136] c. There are 4 reservations connected to d_5, namely b_2, b_4, b_5, b_6. Since b_6 is already in B_1, we will only check b_2, b_4, b_5. The minimum index is 2, and c_4 = c_5 = 2. Since there are 2 reservations with the same minimum index value, we will select the reservation with a smaller eta for the driver. Because eta_45 = 100 < eta_55 = 200, we select b_4 as the next reservation and thus collect b_4 into B_1.

[0137] d. Reservation b_4 is connected to d_5 and d_6, but only d_6 is not in D_1. Therefore, d_6 is collected into D_1.

[0138] e. There are 2 reservations b_4 and b_5 connected to d_6, but only b_5 is not in B_1. Therefore, b_5 is collected into B_1.

[0139] The stop criterion is satisfied. We have collected 3 reservations into B_1, namely b_6, b_5, b_4. Using DFS, we find that all drivers are connected to d_5 and d_6. Therefore, the first sub-batch collection will stop by cutting the connection between d_5 and b_2.

[0140] After removing G_1 (B_1, D_1, E_1) from the large batch G, we can start from step 2 and repeat the above steps to find the next sub-batch G_2 (B_2, D_2, E_2). After completion, we will achieve 2 sub-batches by disconnecting d_5 and b_2. This is also shown in Figure 13 where the disconnection between d_5 and b_2 is represented by a dashed line.

[0141] Test Results: Comparison of Static Sharding and Online Sharding

[0142] To compare the effects between static sharding ( Figure 4 ) and online sharding ( Figure 11 ), we conducted a comparative test using historical carpool reservation data from Bangkok (BKK) and Singapore (SG).

[0143] The following table shows the comparative test results of static sharding and online sharding:

[0144]

[0145]

[0146] Comparative test results show that online sharding leads to an increase in the number of batches formed. The average number of reservation-driver pairs formed is calculated by averaging the number of reservation-driver pairs before sharding and then dividing by the number of batches formed under static sharding and online sharding, respectively. In some cases, for static sharding, the number of reservation-driver pairs exceeds the number of available reservation drivers due to the possibility of drivers being assigned to multiple reservations simultaneously in a competitive situation. Overall, in online sharding, the average number of reservation-driver pairs formed per shard is reduced.

[0147] This will, in turn, significantly reduce the time required for static fragmentation >1 second (see...). Figure 4 ) to online sharding <10 milliseconds (see Figure 11 The latency of the allocation engine (AE) is reduced because multiple batch requests can be computed in parallel, allowing smaller batches of AEs to react more quickly. Therefore, AE latency is linearly related to the number of appointment-driver pairs formed in each slice.

[0148] The allocation rate represents the number of drivers assigned to more than one booking at the same time, calculated by dividing the number of assigned bookings by the total number of bookings. Therefore, online sharding results in an increased allocation rate compared to static sharding because it takes into account bookings and drivers across the entire geographic network.

[0149] Compared to static sharding, online sharding also eliminates race conditions. In other words, online sharding ensures that a driver is not available for two different batches at the same time, preventing any driver from being assigned to multiple appointments simultaneously.

Claims

1. A computer-implemented method, executed in a communication server apparatus for a platform provider, the method comprising, under the control of a processor of the communication server apparatus: Receive real-time data related to planned reservations and available vehicles within a geographic region; Based on the estimated arrival time between each vehicle and its neighboring planned appointments, the planned appointments and the available vehicles are clustered into multiple batches; If the number of reservations for a given batch exceeds a predetermined threshold, then that batch will be clustered into more batches, and The proposed reservations and available vehicles are allocated separately within each batch.

2. The method according to claim 1, wherein, The clustering of the proposed reservations and the available vehicles into batches is done across the entire geographic region.

3. The method according to claim 1 or 2, wherein, The clustering of the proposed reservations and the available vehicles into multiple batches was accomplished using the Depth-First Search (DFS) algorithm.

4. The method according to claim 1, wherein, Clustering the corresponding batch into more batches also includes: breaking the corresponding batch into more batches based on the connection level between each vehicle in the corresponding batch and the pick-up point for each proposed reservation.

5. The method according to claim 1, wherein, Clustering is performed without dividing the region based on historical transactions and / or geographically pre-partitioning the region.

6. A computer program product comprising computer-executable instructions that, when executed on a programmable computer device, cause the programmable computer to perform the method according to any one of claims 1 to 5.

7. A computer program medium carrying the computer program product according to claim 6, wherein, The computer program medium is one of electrical signals, optical signals, radio signals, and non-transitory tangible computer-readable storage media.

8. A system for allocating appointments, the system comprising: Communication server; At least one user communication device, having an associated user and configured to initiate a reservation including a reserved pick-up location; At least one driver communication device, having an associated driver vehicle and configured to provide driver vehicle location data; as well as The communication network facility is configured to establish communication with the communication server, the at least one user communication device, and the at least one driver communication device; The communication server includes at least one processor and at least one memory, and is configured to execute, under the control of one or more of the at least one processor, one or more instructions stored in the at least one memory to: Based on the estimated arrival time between each vehicle and its neighboring planned appointments, the planned appointment locations and driver vehicle locations are clustered into multiple batches. If the number of reservations for a given batch exceeds a predetermined threshold, then that batch will be clustered into more batches, and The proposed reservations and available vehicles are allocated separately within each batch.

9. A communication server apparatus for a delivery platform provider, the communication server comprising at least one processor, the communication server apparatus being configured to execute instructions under the control of one or more of the at least one processor to: Receive real-time data related to planned reservations and available vehicles within a geographic region; Based on the estimated arrival time between each vehicle and its neighboring planned appointments, the planned appointments and the available vehicles are clustered into multiple batches; If the number of reservations for a given batch exceeds a predetermined threshold, then that batch will be clustered into more batches, and The proposed reservations and available vehicles are allocated separately within each batch.

10. A user communication device, driver communication device, or merchant communication device for a platform provider, the user communication device, the driver communication device, or the merchant communication device comprising a processor and a memory, the user communication device, the driver communication device being configured to: execute instructions stored in the memory under the control of the processor to perform the method according to any one of claims 1 to 5.

Images