WO2021015663A1

WO2021015663A1 - Delivery route planning apparatus and methods of generating delivery route plans

Info

Publication number: WO2021015663A1
Application number: PCT/SG2019/050353
Authority: WO
Inventors: Lounell Bahoy GUETA; Kazuo Murai
Original assignee: Hitachi, Ltd.
Priority date: 2019-07-23
Filing date: 2019-07-23
Publication date: 2021-01-28

Abstract

A method of generating delivery route plans includes: receiving a job transfer request that indicates a transfer of a delivery task from a transferor vehicle to a transferee vehicle of a plurality of vehicles; identifying candidates for the transferee vehicle, based on at least distances of the plurality of vehicles from the transferor vehicle; selecting possible rendezvous locations from a location database, based on locations of the identified candidates; running an optimization program to select the transferee vehicle and to determine a rendezvous location and a rendezvous time; and updating delivery route plans of the transferor vehicle and the transferee vehicle based on the rendezvous location and rendezvous time. The optimization program optimizes route plans of the transferor vehicle and the transferee vehicle with respect to a plurality of criteria. Inputs to the optimization program includes the possible rendezvous locations and existing delivery route plans of the candidates.

Description

DELIVERY ROUTE PLANNING APPARATUS AND

METHODS OF GENERATING DELIVERY ROUTE PLANS

TECHNICAL FIELD

[0001] Various embodiments relate to delivery route planning apparatuses and methods of generating delivery route plans.

BACKGROUND

[0002] In typical delivery plans, each delivery vehicle may follow a pre-planned delivery route that may include a sequence of static locations where goods are to be delivered. In the delivery of products to multiple destinations, an impending delay at one affected destination may impact deliveries in succeeding destinations. There is a need to avert, if not minimize, delivery delays.

SUMMARY

[0003] According to various embodiments, there may be provided a delivery route planning apparatus. The delivery route planning apparatus may include: a transfer request generator configured to generate a job transfer request, the job transfer request indicating a transfer of a delivery task from a transferor vehicle of a plurality of vehicles to a transferee vehicle of the plurality of vehicles; a candidate identifier configured to identify candidates for the transferee vehicle, based on at least distances of the plurality of vehicles from the transferor vehicle; a rendezvous selector configured to select a plurality of possible rendezvous locations from a location database, based on locations of the identified candidates; an optimization program configured to select the transferee vehicle and to determine each of a rendezvous location and a rendezvous time; and an updater configured to update delivery route plans of the transferor vehicle and the transferee vehicle based on the determined rendezvous location and rendezvous time. The optimization program may optimize route plans of the transferor vehicle and the transferee vehicle with respect to a plurality of criteria stored in the server, wherein inputs to the optimization program may include the plurality of possible rendezvous locations and existing delivery route plans of the candidates. [0004] According to various embodiments, there may be provided a method of generating delivery route plans for a plurality of vehicles. The method may include: receiving a job transfer request in a server, the job transfer request indicating a transfer of a delivery task from a transferor vehicle of the plurality of vehicles to a transferee vehicle of the plurality of vehicles; identifying candidates for the transferee vehicle, based on at least distances of the plurality of vehicles from the transferor vehicle; selecting a plurality of possible rendezvous locations from a location database, based on locations of the identified candidates; running an optimization program to select the transferee vehicle and to determine each of a rendezvous location and a rendezvous time, and updating delivery route plans of the transferor vehicle and the transferee vehicle based on the determined rendezvous location and rendezvous time. The optimization program may optimize route plans of the transferor vehicle and the transferee vehicle with respect to a plurality of criteria stored in the server, wherein inputs to the optimization program may include the plurality of possible rendezvous locations and existing delivery route plans of the candidates.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] In the drawings, like reference characters generally refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the invention. In the following description, various embodiments are described with reference to the following drawings, in which:

[0006] FIG. 1 shows a block diagram of a vehicle deployment system according to various embodiments.

[0007] FIG. 2 shows a block diagram of the modules of the Delivery Transfer Management Device according to various embodiments.

[0008] FIGS. 3A-E show examples of data structures of input data according to various embodiments.

[0009] FIG. 4A shows a flowchart of the generation of an initial dispatch according to various embodiments.

[0010] FIG. 4B shows a flowchart of a process of transfer coordination according to various embodiments.

[0011] FIGS. 4C-4G show flowcharts relating to the process of determining transfer order requirements according to various embodiments. [0012] FIG. 5 shows a diagram that illustrates an example of dispatch plans without transfer coordination.

[0013] FIGS. 6A and 6B show examples of prior art dispatch plans presented in tables, where the vehicles do not transfer delivery jobs.

[0014] FIG. 7 shows a diagram that illustrates an example of dispatch plans with transfer coordination, according to various embodiments.

[0015] FIGS. 8A-8B show the dispatch plans of Vehicles A and B as shown in FIG. 7, which includes a job transfer.

[0016] FIGS. 9A-9D show a method of generating delivery route plans according to various embodiments, as applied to facilitating a virtual warehouse.

[0017] FIG. 10 shows a delivery route planning apparatus according to various embodiments.

[0018] FIG. 11 shows a delivery route planning apparatus according to various embodiments.

[0019] FIG. 12 shows a flow diagram of a method of generating delivery route plans for a plurality of vehicles according to various embodiments.

DESCRIPTION

[0020] Embodiments described below in context of the apparatuses are analogously valid for the respective methods, and vice versa. Furthermore, it will be understood that the embodiments described below may be combined, for example, a part of one embodiment may be combined with a part of another embodiment.

[0021] It will be understood that any property described herein for a specific apparatuses may also hold for any apparatuses described herein. It will be understood that any property described herein for a specific method may also hold for any method described herein. Furthermore, it will be understood that for any apparatus or method described herein, not necessarily all the components or steps described must be enclosed in the device or method, but only some (but not all) components or steps may be enclosed.

[0022] In this context, the apparatus as described in this description may include a memory which is for example used in the processing carried out in the apparatus. A memory used in the embodiments may be a volatile memory, for example a DRAM (Dynamic Random Access Memory) or a non-volatile memory, for example a PROM (Programmable Read Only Memory), an EPROM (Erasable PROM), EEPROM (Electrically Erasable PROM), or a flash memory, e.g., a floating gate memory, a charge trapping memory, an MRAM (Magnetoresistive Random Access Memory) or a PCRAM (Phase Change Random Access Memory).

[0023] The term “coupled” (or“connected”) herein may be understood as electrically coupled or as mechanically coupled, for example attached or fixed, or just in contact without any fixation, and it will be understood that both direct coupling or indirect coupling (in other words: coupling without direct contact) may be provided.

[0024] In order that the invention may be readily understood and put into practical effect, various embodiments will now be described by way of examples and not limitations, and with reference to the figures.

[0025] In the context of various embodiments, the phrase“dispatch plan” may be but is not limited to being interchangeably referred to as a“delivery route” or a“delivery route plan”.

[0026] In the context of various embodiments, the phrase“delivery task” may be but is not limited to being interchangeably referred to as a“delivery job” or“delivery order”.

[0027] In the context of various embodiments, the phrase“transfer coordination” may be but is not limited to being interchangeably referred to as a“job transfer”.

[0028] In the context of various embodiments, the phrase“transferor vehicle” may be but is not limited to being interchangeably referred to as a“transferring vehicle”, and the phrase “transferee vehicle” may be but is not limited to being interchangeably referred to as a “receiving vehicle”.

[0029] According to various embodiments, a delivery route planning apparatus may be provided. The delivery route planning apparatus may generate the dispatch plans of vehicles to fulfil the delivery of items to multiple destinations. The dispatch plans may indicate the time and place of each delivery job. Some delivery jobs may have a specific timing requirement, for example, a timing window during which the item needs to be delivered. The delivery route planning apparatus may update the dispatch plans dynamically, to avoid delays in the delivery jobs. If a first vehicle is unable to complete a delivery job on time, or if the delivery route planning apparatus predicts that the first vehicle may not be able to complete the delivery job on time, the delivery route planning apparatus may modify the dispatch plans of the first vehicle and at least one other vehicle(s), such that the at least one other vehicle may take over one or more delivery orders from the first vehicle. The delivery route planning apparatus may modify the dispatch plans of the first vehicle and the at least one other vehicle(s) to accommodate a transfer event, in other words, to include stopping at a rendezvous location at around the same time for the first vehicle to transfer items of the one or more delivery orders to the at least one other vehicle(s). In this example, the first vehicle may be the“transferor” vehicle that hands over the one or more delivery jobs, whereas the at least one other vehicle(s) may be the“transferee” vehicle(s) that takes over the one or more delivery jobs. The first vehicle may also take over delivery jobs from the at least one other vehicle(s), i.e. swap delivery orders with the at least one other vehicle(s), such that the resulting delivery routes for all of the vehicles are optimized to meet the delivery schedule. By planning the transfer event, the delivery route planning apparatus may avert a cascading effect of delays to the remaining delivery jobs, by delivering the delayed order in parallel to the other delivery jobs of the transferee vehicle.

[0030] According to various embodiments, the delivery route planning apparatus may determine a configuration of the transfer event. The configuration may be referred herein as the transfer configuration. The transfer configuration may include the rendezvous location, the path and routing of vehicles from their originating locations to the rendezvous location, the path and routing of vehicles from the rendezvous location to their respective destinations, the schedule of the transferor vehicle, and the schedule of the transferee vehicle. The“item” of the delivery job may be any physical object, article, device, or persons. For example, the item could be any one of a vehicle part, a repair tool, a printed document such as invoices, delivery clearance, and product certifications, a replacement battery, vehicle fuel, a replacement driver etc.

[0031] According to various embodiments, the delivery route planning apparatus may be informed of, or may detect, an undeliverable order. The delivery order may be undeliverable due to the unavailability of a compatible vehicle for the delivery destination. For example, the delivery destination may be in a small lane which only small vehicles such as a motorcycle or a sedan car may enter, whereas the available vehicles are trucks and vans. The delivery route planning apparatus may generate or modify a dispatch plan of a first vehicle such that the first vehicle may transport the item of the delivery order from a pick-up location to a rendezvous location. The delivery route planning apparatus may identify a second vehicle that fulfils the requirements of the destination, and then generate or modify a dispatch plan of the second vehicle so that the second vehicle may go to the rendezvous location to pick up the item. After that, the second vehicle may deliver the item to the destination.

[0032] According to various embodiments, the delivery route planning apparatus may receive job transfer requests from transferee vehicles. These transferee vehicles may face difficulties in meeting their assigned delivery schedules. Upon receipt of the job transfer request, the delivery route planning apparatus may identify candidate transferor vehicles and may compute possible transfer configurations with respect to these candidate transferor vehicles. The delivery route planning apparatus may broadcast the job transfer requests and/or the transfer configurations to the candidate transferor vehicles. When a candidate transferor vehicle has accepted the job transfer request, the delivery route planning apparatus may update the dispatch plans of the transferor vehicle and the transferee vehicle to include the transfer event.

[0033] According to various embodiments, a job transfer request may involve more than two vehicles. For example, a first vehicle may not be able to complete a first delivery job on time. The delivery route planning apparatus may re-route the first vehicle to a first rendezvous location to transfer a first item of the first delivery job to a second vehicle. The delivery route planning apparatus may re-route the second vehicle to pick up the first item at the first rendezvous location and also transfer a second item of a second delivery job to a third vehicle at a second rendezvous location. The second vehicle may carry out the first delivery job, while the third vehicle may take over the second delivery job from the second vehicle. The second rendezvous location may be the same as the first rendezvous location. Alternatively, the second rendezvous location may be different from the first rendezvous location.

[0034] According to various embodiments, the delivery route planning apparatus may monitor the positions of each vehicle in a fleet of vehicles, for example, by receiving information on the positions from the vehicles. Each vehicle may be equipped with a tracker, such as a Global Positioning System (GPS) device, that determines the geographical position of the vehicle. Each vehicle may be equipped with a transmitter that may transmit the tracker readings to the delivery route planning apparatus, or to a server, or network, that is connected to the delivery route planning apparatus.

[0035] According to various embodiments, the delivery route planning apparatus may be part of a logistics controller of a virtual warehouse (also referred herein as virtual factory). The virtual warehouse, as its name suggests, may provide the function or service of storing goods without a physical building. Storage vehicles, such as large capacity vehicles like trucks or lorries, may temporarily store the goods. These storage vehicles may pick up goods at a physical warehouse, and may deliver the goods to various rendezvous locations, referred herein as hubs (for example regional hubs). Each hub may serve a respective region such as a town or a village which may be inaccessible to the storage vehicles. The regions may be inaccessible to the storage vehicles due to reasons such as, poor road connections, loading bay constraints, truck ban at specific locations, maintenance works that limit passage of large vehicles, among others. The delivery route planning apparatus may calculate the transfer configurations for the storage vehicles which may be the transferor vehicles, and small capacity vehicles which may be the transferee vehicles. The small capacity vehicles may pick up the goods from the storage vehicles and may deliver the goods to their destinations within the regions. The storage vehicles, on their own, may be unable to deliver the goods from the warehouse to their destinations, for example due to their incompatibility with the destinations, or the inefficiency of travelling deep into remote regions. The small capacity vehicles, on their own, may also be unable to deliver the goods from the warehouse to their destinations, for example, due to their limited range of travel, or the inefficiency of travelling long distances to transport a small quantity of goods as limited by their small capacities. The delivery route planning apparatus may enable the virtual warehouse to function, by coordinating the routes of the storage vehicles and the small capacity vehicles. Conversely, the delivery route planning apparatus may also coordinate the transfer of goods from the small capacity vehicles to the storage vehicles at the hubs. For example, agricultural produce may be collected from small farms using the small capacity vehicles, and transferred to the storage vehicles.

[0036] According to various embodiments, the delivery route planning apparatus may support iterative planning and coordination of the transfer events by configuring variable rendezvous locations and configurations of the vehicles depending on the order requirement, and the available vehicles.

[0037] According to various embodiments, the delivery route planning apparatus may centrally control a fleet of vehicles, in that the delivery route planning apparatus may initiate job transfers between vehicles. The delivery route planning apparatus may initiate the job transfers when at least one of the vehicles fall behind in its delivery schedule, or when the delivery route planning apparatus receives information that a vehicle is assigned to an incompatible delivery job, or when a delivery job is unassigned to any vehicle. The delivery route planning apparatus may monitor the real-time positions of the fleet of vehicles to determine whether any vehicle is falling behind in its delivery schedule. The delivery route planning apparatus may also plan the delivery routes for each vehicle in the fleet.

[0038] According to various embodiments, control of the fleet of vehicles may be decentralized. In other words, the delivery route planning apparatus may not initiate the job transfers. The delivery route planning apparatus may compute the transfer configurations, only upon receiving a job transfer request from a transferor vehicle that is seeking a transferee vehicle.

[0039] FIG. 1 shows a block diagram 100 of a vehicle deployment system according to various embodiments. The vehicle deployment system may include a plurality of computing devices that may be connected via a network 180. The vehicle deployment system may be developed in a client-server architecture, deployed in a cloud environment or as an on premise solution connected to a public or private network. The block diagram 100 is simplified to highlight the key interfaces between the computing devices. The vehicle deployment system may include applications (APP) referred to as Sender APP 110, Delivery Vehicle APP 120, Driver APP 150, Receiver APP 160 and Delivery Vehicle APP 170. These APPs may be installed and run on a computing device, such as a mobile phone, a tablet, any mobile device, a desktop computer, or a laptop.

[0040] The Sender APP 110 may be an application for customers to send Delivery Order Data 111. The Sender APP 110 may receive Confirmation 112 of the delivery order, as well as Delivery Update 113. The Sender APP 110 may be a mobile, or desktop application or a client-side web application with a user interface to input and send delivery orders to a delivery transfer management device 130. The delivery transfer management device 130 may also be referred herein simply as“Device 130” for brevity. The Device 130 may include, or may be part of, the delivery route planning apparatus. The user interface may accept text input, text file, a selection list, a voice signal and an image file that may be recognized as data related to placing delivery orders. The delivery order may be received through a delivery order management system or a similar system that collects delivery orders. The Delivery Vehicle APP 120 may be an application for receiving a Dispatch Plan 125, and for processing the Dispatch Plan 125 to navigate from one destination to another destination based on the timings indicated in the Dispatch Plan 125. The Delivery Vehicle APP 120 may be installed in a communication device for autonomous or semi-autonomous vehicles with a processor or a set of processors. The communication device may be capable of communicating with the delivery transfer management device 130 through an application program (API) interface. The Driver APP 150 may be a driver application that allows a driver to indicate a status relating to the driver (herein referred to as Driver Status 151) or a status relating to any delivery job (herein referred to as Operation Status 152). The Driver APP 150 may allow the driver to send the Driver Status 151 (e.g., preparing for driving, driving, waiting, reaching destination, resting, completed work), Operation Status 152 (e.g., pick-up, returning to depot, delivering) by manual or automatic means. The Driver APP 150 may also allow the driver to send a Work Transfer Request 153 which is conducted for instance when a maximum driving or working time is about to be reached, or incidents occurred related to delivery status or to driver’s safety. The Work Transfer Request 153 may also be referred herein as a job transfer request. The Driver APP 150 may also receive Work Transfer Confirmation 154, and receive Dispatch Plan 155. The Receiver APP 160 may be utilized by the receiver of a delivery order to receive Delivery Update 161. The Delivery Update 161 may indicate the expected date and time of delivery order, the current operation and associated location, and the identity of the delivery transporter or courier. The Delivery Vehicle APP 170 may automatically collect vehicle environment data (e.g., location, temperature, traffic status). The Delivery Vehicle APP 170 may also allow manual input, for example, from a driver who enters the Delivery Status 171 or a driver assistant who provides or confirms information about the Delivery Status and environment (e.g., completed deliveries, incident, precipitation, etc.). The Delivery Vehicle APP 170 may also transmit the vehicle location, i.e. Location Data 172. Driver APP 150, Delivery Vehicle APP 170, Delivery Vehicle APP 120 may be at least substantially similar. They may be devices, or applications that run on devices, for sending delivery status and job transfer requests. The Driver APP 150 may be customized for the delivery driver’s usage, for example to receive manual inputs from the driver to indicate operation status. The Delivery Vehicle APP 120 may be customized, for example, to receive vehicle statuses automatically generated by the vehicles. The Delivery Vehicle APP 170 may be able to handle both the driver’s manual inputs and the vehicle status. The Delivery Vehicle APP 170 may have the functionality of Delivery Vehicle APP 120 and Driver APP 150. Delivery Status 171 may indicate status of a delivery, for example status of transportation, transfer or loading/unloading. Operation Status 152 may indicate status of operations that take place prior to the delivery, for example status of sorting the items, preparation before loading etc. In various embodiments, the Operation Status 152 and the Delivery Status 171 may include the same information, for example, both the status of the delivery and the status of the operations prior to delivery.

[0041] The Delivery Transfer Management Device 130 may include, or may be part of, the delivery route planning apparatus described above. The Delivery Transfer Management Device 130 may include one or more processors with memory, computer-readable media, input/output interfaces and API interfaces that communicate with the applications 110, 120, 130, 150, 160, and 170 and other applications or systems such as a delivery order management system, transport deliver monitoring system, traffic monitoring system, and event monitoring system. The Delivery Transfer Management Device 130 may receive data from multiple devices with installed applications or multiple systems capable of sending data defined by API interfaces. For instance, the API functions of the Delivery Vehicle APP 120 and the Delivery Vehicle APP 170 may be to send Delivery Status 121, Location Data 122, Transfer Out Request 123 (i.e., when a vehicle or a driver wants to hand-over a transfer item to another vehicle), receive a Transfer Out Confirmation 124, receive a Transfer-in request 173 (when another vehicle wants to transfer an item to a vehicle), send a Transfer In Confirmation 174 (i.e., when a vehicle or a driver accepts to receive a transfer item) and receive a Dispatch Plan 175. The Delivery Transfer Management Device 130 may include a computer-readable medium. The computer-readable medium may be configured to store structures, data table formats for relational databases, semi- structured formats like document database, or store data in NoSQL database. The medium may be store delivery orders and other incoming data such as Customer data 135, Driver Data 136, Vehicle Data 137, Delivery Order Data 138, Delivery Location Data 139, Rendezvous Location Data 140, and Delivery History Data 141. The Delivery Order Data 137 may often be changed depending on the delivery orders from customers. On the other hand, the Customer data 135, the Driver Data 136, the Vehicle Data 137, the Delivery Location Data 139 and the Rendezvous Location Data 140 may not change frequently but may be updated as needed. New data may be stored in the Rendezvous Location Data 140 as a result of the Rendezvous Configuration Discovery 235 sub-module which will be described with respect to FIG. 2. The Delivery History Data 141 may store previous transactions. Customer Data 135 may include profiles of customers who conduct delivery order requests. Customer Data 135 may include customer codes, a name, a customer type (e.g., delivery order sender, receiver or both), and a location code. It may include customer category based on the frequency of sending and receiving delivery orders, which may be used to prioritize transfer requests. The Driver Data 136 may include information on the drivers of the vehicles. The Vehicle Data 137 may include information on the vehicles. The Delivery Location Data 139 may include information on the delivery locations, including the pickup and delivery addresses. The Rendezvous Location Data 140 may include information on locations where vehicles may conduct a transfer of items. Further details of the Delivery Transfer Management Device 130 are described with respect to FIG. 2. [0042] FIG. 2 shows a block diagram 200 of the modules of the Delivery Transfer Management Device 130. The Device 130 may include a Delivery Request and Update Handling Module 131 which may handle incoming data related to delivery orders and delivery request. The Delivery Request and Update Handling Module 131 may include a Delivery Order Handling sub -module 211 which may receive incoming data from a plurality of applications. The incoming data may include Delivery order 111, Driver Status 151, Operation Status 152, Transfer-Out Request 123 and Work Transfer Request 153. The Delivery Request and Update Handling Module 131 may include a Transfer Requirement Analysis sub-module 212 which may conduct a pre-analysis delivery order requirement. For instance, the Transfer Requirement Analysis sub-module 212 may immediately analyze a job transfer request from vehicles or drivers to determine the transfer requirements. The Delivery Request and Update Handling Module 131 may include a Transfer Broadcast sub-module 213 which may broadcast a job transfer request to a plurality of vehicles. The Delivery Request and Update Handling Module 131 may include a Reply and Confirmation sub-module 214 which may coordinate transfer between vehicles and drivers. The Reply and Confirmation sub-module 214 may send transfer-in request (173), transfer out confirmation (124), and a work transfer confirmation (154) after confirming the reception of corresponding requests. The Delivery Request and Update Handling Module 131 may include a Dispatch Update sub- module 215 which may handle dispatch updates for transferor and transferee vehicles. The Dispatch Update sub-module 215 may send updates such as Dispatch Plan 125, 154, and 174. The Delivery Request and Update Handling Module 131 may also send delivery updates 113, 161 to the Sender APP 110 and to the Receiver APP 160, to provide report of ongoing delivery such as confirmation that a transfer coordination is made, a benefit of conducting transfer coordination, change in the delivery time, change delivery courier, vehicle info or driver info as in the case of transfer coordination, respectively.

[0043] The Device 130 may include a Delivery Monitoring Module 132 which may handle the incoming data regarding delivery status, vehicle status, traffic condition, incidents, event occurrence, and transfer coordination status. The Delivery Monitoring Module 132 may receive data from the Delivery Vehicle APP 120, 170, for example, current geographical locations of delivery vehicles, as well as delivery status. The Delivery Monitoring Module 132 may receive data from a transport monitoring system about location information of delivery vehicles. The Delivery Monitoring Module 132 may gather the data of any delivery progress such as the Delivery Status 121 and 171, Location Data 122, and Location Data 172. The Delivery Monitoring Module 132 may include a Vehicle Status Monitoring sub-module 221 that may determine vehicle status such as its location at a given time, as well as its condition as to whether it is“broken”,“stalled”, or“moving”. The Delivery Monitoring Module 132 may include an Order Status Monitoring sub-module 222 that determines the order delivery status 262 as“delayed”,“on-time” and“stalled” by determining the vehicle status, and comparing it with a scheduled plan of delivery order.

[0044] The Delivery Monitoring Module 132 may include a Transfer Monitoring sub-module 223 that monitors any on-going transfer instances on whether it is currently active, completed or had failed. The Delivery Monitoring Module 132 may monitor external factors that may affect the delivery and associated transfer, using a Traffic Monitoring sub-module 224 that may monitor traffic congestion, and an Event Monitoring sub-module 225 that may monitor events (such as traditional festivities, political gatherings). The Delivery Monitoring Module 132 may also monitor the weather condition. The Delivery Monitoring Module 132 may transmit a delivery status 226 to a Transfer Coordination Module 133. The delivery status 226 may include vehicle identifier (ID), identification of current orders associated to vehicle, vehicle latitude, vehicle longitude, operation such as“transporting”,“transfer”,“unloading”, and schedule status such as“delayed”,“on-time” and“stalled”, among others. The Delivery Monitoring Module 132 may send the delivery status 226 to the Transfer Coordination Module 133.

[0045] The Device 130 may include the Transfer Coordination Module 133 which may process transfer coordination, calculate transfer configurations, determine rendezvous locations, and generate dispatch plans. The Transfer Coordination Module 133 may also generate the data for confirmations, broadcast, and dispatch updates which may be forwarded to the Delivery Request and Update Handling Module 131 for sending to the applications or multiple systems capable of receiving the data. The Transfer Coordination Module 133 may coordinate job transfers between vehicles in a centralized manner, or in a decentralized manner, or a combination thereof.

[0046] In a centralized manner, the Device 130 may act as a centralized control for transfer coordination wherein it monitors all vehicles, determines transfer requirements and enforces the transfer coordination between vehicles. The transfer requirement may be determined based on delivery orders, and the current status of the vehicles and the drivers. For instance, some orders may be undelivered due to the unavailability of vehicles for the required delivery time windows, or due to the unavailability of compatible vehicles. The vehicle compatibility requirement may arise from the conditions of the roads that lead to the destination. For example, the roads may be underdeveloped, rough, unpaved, narrow, or have a maximum load weight like in the case of a bridge. The vehicle compatibility requirement may also be caused by usage or space constraints at the destination, for example, limited space at the unloading bay, absence of an unloading bay, or use of road-side only. In these aforementioned cases, the Transfer Coordination Module 133 may initiate a job transfer request and may coordinate the transfer of the delivery job from one vehicle to another vehicle that satisfies the delivery time window constraint and/or the requirement of a compatible vehicle. In some cases, the transfer requirement may be determined based on imminent delays of vehicles, traffic condition, incidents, change in delivery orders, among other factors.

[0047] In a decentralized manner, the applications may initiate the job transfer request. For instance, the Driver APP 150 may send a Work Transfer Request Data 153. This request may include requesting a replacement driver to avoid exceeding the current driver’s maximum driving hours, requesting a vehicle part or a repair tool, a transfer of a delivery item due to an incident that prevents a driver or a vehicle to continue after a specific period of time in the future, or a degrading health due to tiredness, or sudden illness of a driver based on the monitoring status of Driver APP 150. The Delivery Vehicle APP 120 may request a job transfer based on its current delivery status, for example, traffic build-up towards a destination, an accident that had just happened, an unexpected road repair, or based on the vehicle status, for example, vehicle breakdown, an impending fuel outage situation without nearby refueling stations, or a failure of the air-conditioning which may be critical in food delivery. The Delivery Vehicle APP 120 may request the job transfer by sending a Transfer Out Request 123. The Transfer Broadcast sub-module 213 may broadcast the Transfer-Out Request 123 to other vehicles. In various embodiments, the Transfer Broadcast sub-module 213 may broadcast the Transfer-Out Request 123 only to candidate vehicles that it has determined to be suitable for taking over the delivery job. Vehicles that are interested to take over the delivery job may confirm acceptance of the Transfer Out Request 123. After receiving a confirmation from one or more vehicles, the Transfer Coordination Module 133 may determine the most appropriate vehicle for order transfer. The candidate vehicles may offer a corresponding transfer fee that may be a selection criterion.

[0048] The Device 130 may include a Reporting and Display Module 134 (shown in FIG. 1) that may provide output and display in the form of texts, charts, tables, graphs, maps to display the computing results of the Transfer Coordination Determination sub-module 233, the Rendezvous Configuration Model sub-module 234, the Rendezvous Configuration Discovery sub-module 235, the Transfer Schedule Planning sub-module 236, and the Delivery Scheduling sub-module 237 as well as data visualizations of the Customer Data 135, Driver Data 136, Vehicle Data 137, Delivery Order Data 138, Delivery Location Data 139, Rendezvous Location Data 140 and the Delivery History Data 141. These output may be presented in a Gantt chart format for schedule -related output such as a dispatch plan output by the Delivery Scheduling sub-module 237. The dispatch plan output may include transfer information as a result of transfer planning such as the rendezvous location, the transfer timings for transferor and transferee vehicles. An output data interface may display a revised dispatch plan in various format such as in tabular form, or in a geographical map showing the location information as well as routing data. These display and outputs may be used in monitoring and planning of the delivery routes.

[0049] The Transfer Coordination Module 133 may include various sub-modules. The sub- modules may include a Transfer Coordination Determination sub-module 233, a Rendezvous Configuration Model sub-module 234 and the Rendezvous Configuration Discovery sub- module 235. These sub-modules may conduct queries to stored data in the Customer Data 135, Driver Data 136, Vehicle Data 137, Delivery Order Data 138, Delivery Location Data 139, Rendezvous Location Data 140 and the Delivery History Data 141. For example, a query function for Vehicle Data 137 may search using a parameter filter such as the date of order placement, customer, product type, dimension, weight, driver skill requirement, origin location, destination location, delivery time, transferable, or by a combination thereof. Another search function may relate data information of at least two data sources. For example, a location in the Delivery Location Data 139 may be used as an input parameter to search for nearby locations in the Rendezvous Location Data 140. Further, the search function may accept queries to find rendezvous locations used in a past transaction by a customer in a specific location using a specific vehicle under a specific traffic and weather condition using the data in the Vehicle Data 137, Delivery Location Data 139, Rendezvous Location Data 140, Customer Data 135 and the Delivery History Data 141. Processed Data 262 may be a result of a query search based on parameter filters. The processed data 262 may include a list of parameter values from a table or a combined list of values of related parameters, a data subset of the Delivery History Data 141 or a single-value measurement. [0050] The Coordination Parameter Setting sub-module 231 may include parameters such as performance index settings, the value of speed parameter per vehicle type, loading time during delivery order pick-up, unloading time during delivery, loading and unloading time during transfer and maximum waiting time during transfer, among others. The performance index settings may include, for example, minimum number of vehicles, number of drivers, delivery cost, delivery time, fuel consumption or a combination of several performance indices. The initial values of these parameters may be manually set. As the data size of the Delivery History Data 141 becomes large, these planning parameters may be estimated by statistical analysis. The Coordination Parameter Setting sub-module 231 may include a coordination mode parameter for selecting the coordination mode from one of centralized control, decentralized control and a combination thereof. The coordination mode parameter may be set for a certain group of vehicles such that some vehicles may be controlled in a centralized or decentralized mode. For critical delivery status such as incidents in vehicles and drivers, a decentralized mode setting may be appropriate so that the job transfers may be carried out timely. The Coordination Parameter Setting sub-module 231 may allow a user to define trigger sources that may activate a transfer coordination, and may define the entities that may be activated by a trigger. A trigger source may be time-based (for example, scheduled at regular time intervals) or event-based (for example, triggered by a certain transfer order requirement automatically or manually). A time-based trigger source may be defined by a value of a predetermined time or cycle, which may be decided by a logistics planning team based on the regular time for generating a dispatch plan on a daily or weekly basis. It may depend on the planning horizon which can be on hourly or daily basis depending on the business process of a company or a provider that conducts the transport delivery service. In a high-priority or highly critical situation, an authorized individual such as a head logistics planner may manually trigger a transfer coordination. The Device 130 may also generate a trigger source, based on, for example, the accumulated number of delivery requests exceeding a threshold value. The threshold value may be user-defined or determined by conducting statistical analysis to determine when transfer coordination has to be made by considering several factors. The factors may include the status of current deliveries monitored through the Delivery Monitoring Module 132, as well as the measurements derived from the Delivery History Data 141. The statistical data analysis may result from analyzing the day of a week and a time of the day when a transfer coordination is executed by relating it to the number of transferor vehicles 248, the number of transferee vehicles 249, the number of transfer requirements 250, the number of completed transfers 251, the number of vehicle trips 252, the number of location per trip per vehicle 253, the peak time of a day 259, the traffic condition 260 and weather condition 261 among other factors.

[0051] The Transfer Coordination Module 133 may include an Entity Profile Setting sub- module 232. The Entity Profile Setting sub-module 232 may include functions to set the parameters relating to items for transfer (also referred herein as entities), such as a product type, a driver type, a vehicle part, or a document. In the Entity Profile Setting sub-module 232, these items may be selected by manual means to indicate item types which may be considered for transfer coordination by defining the application transfer coordination modes and the corresponding criticality or priority. The Transfer Coordination Determination sub- module 233 may determine whether a transfer coordination is required or not, and if required, it may determine the transfer requirements. The transfer requirements may include delivery order requirements for transfer from a transferor vehicle, or the requirement of an item defined in the Entity Profile Setting sub-module 232 that is requesting transfer. The transfer requirements may include a delivery status or a reference to a set of delivery statuses. The delivery status may include a vehicle or a driver carrying the item, the location of a transferor vehicle, the entity status, associated incident if applicable, a current weather condition, a predicted weather condition, a current traffic condition, a predicted traffic condition, change in delivery condition that a driver indicated in Driver APP, among others. Based on the trigger source setting in the Coordination Parameter Setting sub-module 231, the Transfer Coordination Determination sub-module 233 may be activated to determine a transfer requirement, a delivery order associated to a transfer, or an order that is currently being delivered. This delivery order may be retrieved from the Delivery Location Data 138 for processing to be associated to the related data in the Customer Data 135, Driver Data 136, Vehicle Data 137, and Delivery Location Data 139. For example, a delivery order may indicate location codes for the pickup and drop-off locations. The corresponding latitude and longitude of these location codes may be determined by looking up the values at Delivery Location Data 139. Likewise, the same process may apply to other related data. After the Transfer Coordination Determination sub-module 233 has determined a transfer requirement, the Transfer Schedule Planning sub-module 236 may calculate a set of transfer configuration candidates. The transfer configuration may include a rendezvous location, the path and routing of vehicles (transferor and transferee) from an origin location to a rendezvous location, the path and routing from a rendezvous location to a destination location, the timing for transferring or hand-over of a transferor vehicle, and the timing for a transferee vehicle that receives an entity for transfer.

[0052] The Transfer Configuration Model sub-module 234 may include a model of transfer or rendezvous configurations which includes spatial and temporal information that are representatives of previous successfully completed transfer deliveries in the Delivery History Data 141. The Transfer Configuration Model sub-module 234 may generate the model by conducting statistical analysis such as applying logistic regression, multi-variate regression, and classification methods to determine candidate rendezvous locations for transferor and transferee vehicles. The Transfer Configuration Model sub-module 234 may calculate trends and patterns to determine the applicable values of scheduling parameters. These parameters may include the loading time at a loading location, unloading time at a destination, transfer lead time at a rendezvous location, and driver skill, vehicle speed by road segment location and driver skill. The values may be specifically determined by vehicle type, by product type of delivery order, by specific time of the day, by traffic condition type, by weather condition type, among others. These values may be derived by conducting statistical measurements of Delivery History Data 141 such as the actual lead time measurements in the Load/Unload Lead Times 255, transfer lead times 256, estimating speed based on the delivery lead times 254 and associated delivery distances 257, and considering added distances due to transfer 258. The Transfer Configuration Model sub-module 234 may determine the configuration candidates by taking into consideration the previous successfully completed transfers 251, associated transfer requirements 250, delivery order data 247, transferor vehicles 248 and transferee vehicles 249. The Transfer Configuration Model sub-module 234 may be regularly updated based on the changes of Delivery Historical Data 141. The Transfer Configuration Model sub-module 234 may define a rendezvous location of a transfer configuration based on a predicted rendezvous location from the Rendezvous Configuration Discovery sub-module 235.

[0053] The Rendezvous Location Discovery sub-module 235 may identify rendezvous locations based on a map information and the historical data. The Rendezvous Location Discovery sub-module 235 may use map information to determine parking areas of a marketplace, commercial buildings, centers, and shopping malls with areas for loading and unloading, streets with non-tow away zones on road sides allowing side parking for a limited time, convenience stores with parking areas, among others. These locations may be company- owned or shared warehouses, company-owned or shared distribution centers. The Rendezvous Location Discovery sub-module 235 may consider environmental information of the location such as traffic patterns, safety in terms of incident reports, and weather condition, in identifying suitable rendezvous locations. For example, the Rendezvous Location Discovery sub-module 235 may determine traffic congestion patterns on specific day and specific time by employing statistical methods or deep learning technologies for the purpose of finding rendezvous locations by considering hourly traffic condition variation, and weather condition. The Rendezvous Location Discovery sub-module 235 may determine new locations by analyzing Delivery Historical Data such as finding nearby locations of previous Rendezvous Locations 242. The compatibility of vehicle to a specific rendezvous location may be determined by determining the information about the transferor vehicles 248, transferee vehicles 249 and vehicle data 245. The identified rendezvous locations may then be added to the Rendezvous Location Data 140.

[0054] The Transfer Schedule Planning sub-module 236 may process a transfer order and utilize the Rendezvous Configuration Model sub-module 234 to determine transfer configuration candidates based on the delivery order, the delivery status and constraints of the transferor vehicle or driver, other entity, and the current status of transferee vehicle candidates. The Transfer Schedule Planning sub-module 236 may determine the transferee vehicle candidates by determining the status of vehicles such as the location, current state, current dispatch plan, others. These transferee vehicle candidates may be further analyzed to determine its compatibility with respect to the transfer requirement of a delivery order such as vehicle type, vehicle available capacity, and its time availability with respect to a desired delivery time window of a delivery order for transfer. The rendezvous location of the transferor vehicle and a transferee vehicle candidate may be determined by a“nearness” measurement relative to the locations of transferor and transferee vehicles with respect to a candidate rendezvous location. The candidate rendezvous locations may be determined by using the Rendezvous Location Data 140 that satisfies the order requirements for transfer such as vehicle compatibility of the location, the opening and closing time of the location that must satisfy with the ongoing delivery time period, among others. The proximity measurement may be determined based on the distance, time, imminent delay, delivery cost, transfer cost or a combination thereof. The Transfer Schedule Planning sub-module 236 may be configured to pair each transferor vehicle with one or more transferee vehicles, and associate each transferor vehicle at least one rendezvous location, in order to satisfy the transfer order requirements. [0055] After determining the transferee vehicle candidates, the Transfer Scheduling Planning sub-module 236 may calculate the lead time requirements for the transfer in the dispatch plan, the routing as well as the delivery time from a current location of a vehicle to a rendezvous location, the routing and the delivery time from a rendezvous location to a delivery location. The Transfer Scheduling Planning sub-module 236 may calculate the lead time requirements using the Delivery Routing Solver 238. The Delivery Routing Solver 238 may be capable of finding the route between two locations determined based on a performance index. The performance index may include minimal time, minimal distance, etc. The Delivery Routing Solver 238 may determine the lead times for loading, unloading, transfer, which may be determined based on the delivery order, rendezvous location, delivery location vehicle type, and the time of a day or the day of a week. The Transfer Scheduling Planning sub-module 236 may derive the delivery time from one location to a rendezvous location by considering the route distance and other factors such as traffic condition, weather condition, and vehicle type among others. The Transfer Scheduling Planning sub-module 236 may determine the transfer time window for transferor and transferee vehicles. The transfer time window should not be too long or wide so as to cause a large waiting time for the vehicles, but also should not be too narrow such that the transfer may be difficult to fulfil. By having the transfer time window, a transferee vehicle and a transferor vehicle may not need to arrival and depart at the same time. Ideally, the transferor vehicle may have completed unloading a delivery order when the transferee vehicle arrives. The transferor vehicle may then leave the rendezvous location after the hand-over and need not wait until the transferee vehicle has completed loading the transferred order. In determining the appropriate time window for transfer, the Transfer Scheduling Planning sub-module 236 may analyze the previous transactions based on the Completed Transfers 251, used Transferor vehicles 248, used Transferee vehicles 249, transacted Rendezvous Locations 242, Transfer Lead Times 256, Distances Due to Transfer 258, peak Data and Time of the Day 259, Traffic Condition Data 260, and Weather Condition Data 261, among other measurements.

[0056] The Transfer Schedule Planning sub-module 236 may output a set of candidates for transfer configurations. The Transfer Schedule Planning sub-module 236 may determine the appropriate time values such as loading time, unloading time, and a delivery time period from one location to another location, the transfer time window for transferee and transferor vehicles are determined based on the delivery order requirement. The Transfer Schedule Planning sub-module 236 may not determine the exact timing in the schedule. There may be several transfer configuration candidates such that there may be several possible pairing assignments of one transferor vehicle to one or more transferee vehicles for the delivery order.

[0057] The Delivery Scheduling sub-module 237 may create a dispatch plan based on the delivery order data 138, available vehicle by recognizing unused vehicle from Vehicle Data 137, the Delivery Location Data 139 and the Rendezvous Location Data 140. The Delivery Scheduling sub-module 237 may receive transfer configurations for delivery orders that require transfer coordination. The Delivery Scheduling sub-module 237 may generate a dispatch plan by assigning one or more vehicles to each delivery order. A vehicle may be assigned a time schedule for picking-up an order from a pickup location and for delivering it at a specified location provided that the constraints are satisfied such as opening hours of the pick-up location, the vehicle constraints (e.g., the maximum vehicle capacity, vehicle type), the compatibility of delivery location to a vehicle type, the specified delivery time window, the opening and closing hours at the destination, among other constraints. The Delivery Scheduling sub-module 237 may generate the dispatch plan by running an optimization program. The optimization program may run a mixed integer linear programming. Alternatively, the optimization program may run a constrained optimization search and may solve it by applying heuristics or metaheuristics algorithms. With the transfer coordination, a rendezvous location must be considered as two additional locations for drop-off and pick-up of same delivery order for transfer, thereby requiring additional treatment. For instance, the definition of a delivery job order may be revised so that the delivery order requirement relating to a destination constraint may be relaxed when applying the plan from a pick-up location to a rendezvous location. However, that delivery order requirement must be satisfied for the vehicle assignment from the rendezvous location to the destination location. For instance, a large vehicle may be assigned from pick-up location to a rendezvous location, but a small vehicle may be assigned from the rendezvous location to the destination in order to satisfy a certain destination constraint. In addition, a precedence constraint at a rendezvous location must be imposed such that a delivery order has to be dropped-off at the rendezvous location first before conducting a pick-up of same delivery order. Further, this precedence constraint must be satisfied within the defined transfer time window. The Delivery Scheduling sub-module 237 may handle these additional considerations and constraints.

[0058] After generating the dispatch plans by considering each transfer configuration, the Delivery Scheduling sub-module 237 may select one dispatch plan that is optimal with respect to a specified performance index or a combination of performance indices according to the settings output by the Coordination Parameter Setting sub-module 231 and the Entity Profile Setting module 232. If a solution is calculated by applying an optimization search or improvement-based solution, the Delivery Scheduling sub-module 237 may terminate the calculation based on the number of iterations or based on a time limit. A dispatch plan may include a set of vehicles with a delivery schedule of one or more delivery orders, one or more pick up locations, one or more drop-off destinations, the operations (e.g. pick-up a delivery order from a pick up location, transfer at a rendezvous location of a delivery order, drop off at a destination location of a delivery order), time and date of each operation, one or more rendezvous locations with a transfer configuration which consists of an item for transfer, the transfer location, a pair of one transferor vehicle and one or more transferee vehicles for transfer of an item, a transfer schedule including transfer timing, the paths or routings of transferor and transferee vehicles. The Delivery Request and Update Handling Module 131 may transmit Transfer Requirement 216 to the Transfer Coordination Module 133. The Transfer Coordination Module 133 may reply to the Transfer Requirement 216, with a Transfer Confirmation 240. The Dispatch Plan Updating sub-module 239 may update the dispatch plan. The Dispatch Plan Updating sub-module 239 may copy the output of the optimization of Transfer Coordination Module 133 to Delivery Request and Update Handling Module 131.The Transfer Coordination Module 133 may send the updated dispatch plan 241 to the Delivery Request and Update Handling Module 131.

[0059] The Delivery History Data 141 may be a repository of completed delivery order transactions, and previous dispatch plans. The Delivery History Data 141 may be used to verify planned and actual lead times for delivery, loading, and unloading. The Delivery History Data 141 may be used to search delivery orders with and without transfer coordination and incident reports related to delivery conditions. The Delivery History Data 141 may include past delivery locations 241, past rendezvous locations 242, information of transacted customer sender 243, information of transacted customer receiver 244, data of utilized vehicle 245, data of participating driver 246, data of transacted delivery order 247, the number of transferor vehicles 248, the number of transferee vehicles 249, transfer requirements 250, completed transfers 251, the number of vehicle trips 252, the number of location per trip per vehicle 253, the peak time of a day 259, the delivery lead times 254, the load/unload lead times 255, the transfer lead times 256, delivery distances 257, distances due to transfer 258, traffic condition 260 and weather condition 261. [0060] FIGS. 3A-E show examples of data structures of input data according to various embodiments. It should be understood that the data structures are not limited to including the fields of the examples shown. FIG. 3 A shows an example of a data structure 300A for storing Driver Data 136. The data structure 300A may include a Driver Code column, a Name column, a Driver Skill column, a Maximum Daily Working Hour column, an Earliest Start Working Time column and a Latest End Working Time column. Each row in the data structure 300A may store information of a respective driver. The Driver Code column may store a unique code for representing the driver. The name column may store the name of the driver. The Driver Skill column may information on the driver’s skill, for example, the type of driving license that the driver holds. The Maximum Daily Working Hour column may store information on the maximum hours that the driver is agreeable to work for, which may be used to check if a job transfer is required so as not to exceed the driver’s maximum working works. The Earliest Start Working Time column and the Latest End Working Time column may store the time that the driver starts work, and the time that the driver ends work, respectively.

[0061] FIG. 3B shows an example of a data structure 300B for storing Vehicle Data 137. The data structure 300B may include a Vehicle Code column, a License Number column, a Vehicle Type column, a Maximum Capacity column, a Start Time column, an End Time column, a Location Constraint column, a Product Constraint column and a Driver Skill Requirement column. Each row in the data structure 300B may store information of a respective vehicle. The Vehicle Type column may store a vehicle identifier (e.g., vehicle code, license number). The Vehicle Type column may indicate the vehicle type. The Maximum Capacity column may indicate the maximum load weight capacity and/or the maximum load volume capacity, of the vehicle. The Start Time column and End Time column may indicate the time window that the vehicle is available. The Location Constraint column may indicate the type of locations that the vehicle may not be suited to enter, for example due to the type of wheels being unsuited to the terrain, or the size of the vehicle being too large for the space available at the location. The Product Constraint column may indicate the types of product that the vehicle may not be equipped to handle, for example, due to a lack of freezer compartment for transporting ice. The Driver Skill Requirement column may indicate the minimum driver skill required for driving the vehicle. These data may come from a fleet management system of a company owner, or from an outsourced company providing the vehicles. [0062] FIG. 3C shows an example of a data structure 300C for storing Delivery Order Data 138. The data structure 300C may include a plurality of columns for storing order code, ordering customer, product type, dimensions of the item in the order, order weight, driver skill requirement, pick-up/from location, drop-off/ to location, delivery date and time, and whether the delivery order is transferable to another vehicle, respectively. The transferability can be set manually or can be determined based on the physical properties such as dimension or weight, product sensitivity (e.g. fragile), among other factors. Additionally, by allowing transferability, additional specification may be indicated such as the minimum preferred specification of rendezvous location (e.g. area size, environment condition such as temperature level, etc.). The data structure 300C may further include a column to store other customer’s special requirement such as specific vehicle type, additional packaging, among other things. The Delivery Order Data 138 may be provided by the customer.

[0063] FIG. 3D shows an example of a data structure 300D for storing Delivery Location Data 139. The data structure 300D may include a plurality of columns for storing location code, name, address, customer code, latitude, longitude, opening time which defines the earliest transaction time for loading, unloading, or sending a delivery order, and closing time which defines the latest transaction time for receiving, loading, unloading a delivery order, a road type which may provide a road type information that may affect the selection of proper product packaging, and a vehicle constraint which indicate the type of vehicle that is compatible to a location, respectively.

[0064] FIG. 3E shows an example of a data structure 300E for storing Rendezvous Location Data 140. The data structure 300E may include a plurality of columns for storing location code, location name, latitude, longitude, time availability (e.g., opening time, closing time), area type, area size, height limit, maximum stay time, safety level, cost (e.g., parking fee), and vehicle constraint, respectively. The area size and height limit may be utilized to determine the vehicle type constraints of the rendezvous location. The selection of rendezvous locations can be affected not only by distance but also by safety level, cost and time availability. The Rendezvous Location Data 140 may be initially populated based on map information, and/or based on experiences from conducting past deliveries in a nearby destination. The Rendezvous Location Data 140 may subsequently be updated with the output of the Rendezvous Configuration Discovery sub-module 235.

[0065] FIG. 4A shows a flowchart 400A of the generation of an initial dispatch according to various embodiments. Delivery vehicles may regularly, or periodically send delivery status and location status (411) to the Device 130 via the Delivery Monitoring Module 132. The Device 130 may receive the delivery status and location data (412). A customer may use the Sender APP 110 to enter a delivery order (413). The delivery order data 111 may be sent through the Network 140 to the Device 130. The Delivery Request and Update Handling Module 131 may recognize the delivery order data 111 as a delivery request. In 414, the Device 130 may add the delivery request to the Delivery Order Data 138 that stores the delivery orders coming from various Sender APPs or any delivery order managing system. Consequently, the Device 130 may send Confirmation 112 to Sender APP 110 or related systems stating the reception of the delivery order, which may be conducted by sending a delivery order code that may be used as an identifier of the order for monitoring delivery updates (e.g., 113).

[0066] Later on, the Transfer Coordination Module 133 may be activated, by a time- scheduled trigger based on the setting from the Coordination Parameter Setting 231. The Transfer Coordination Module 133 may retrieve the stored delivery orders from 138. In 415, the Transfer Coordination Determination sub-module 233 may analyze these orders to determine the transfer coordination requirements. In 416, based on the transfer coordination requirements of specific delivery orders, the Transfer Schedule Planning sub-module 236 may plan the transfer schedule by determining transfer configuration candidates. It may be recognized at this stage that a certain delivery order may have specific transfer order requirement and since a delivery vehicle may carry one or more delivery orders, transfer schedule planning may also affect other delivery orders. The transfer configuration candidates may be determined by utilizing the rendezvous configuration model generated in the Rendezvous Configuration Model sub-module 234 and the rendezvous locations discovered by the Rendezvous Configuration Discovery sub-module 235. In 417, a dispatch plan may be computed based on the transfer configuration candidates with applicable lead times for loading, unloading, vehicle speed, routing, transfer lead time. The computation may be conducted by assigning a vehicle and determining the date and timing schedules based on the aforementioned time measurements and taking into consideration that constraints in destination, delivery order, among others are satisfied. In 418, a dispatch plan with the best transfer configuration based on a performance index may be selected. Consequently, the vehicles assigned with a dispatch plan (e.g., 120, 170, 190) may be notified of a new dispatch plan. In 419, after the Device 130 receives the confirmation from the vehicles, the Device 130 may send the corresponding dispatch plans (e.g., 125, 175 and 195 respectively) via Delivery Request and Update Handling Model 131 to the vehicles. In 420, the vehicles may send confirmations upon receiving the dispatch plans. It may not be necessary for all dispatch plans to have transfer coordination.

[0067] FIG. 4B shows a flowchart 400B of a process of transfer coordination according to various embodiments. In 431, delivery Vehicles 120, 170, 190 may send delivery status and location data on a regular basis. In 432, the Device 130 may receive the delivery status and the location data via the Delivery Monitoring Module 132. In 433, the Device 130 may determine the transfer coordination requirement for each vehicle based on at least one of the delivery status and the location data. In 434, the Device 130 may send a confirmation query to the vehicle that requires the job transfer.

[0068] In various embodiments, the Device 130 may operate in a centralized mode to act as a central control that determines which vehicles require job transfers based on output of the Delivery Monitoring Module 132. The Delivery Monitoring Module 132 may watch out for imminent delays, traffic, incidents, and change in order plans. For example, if the Delivery Monitoring Module evaluates a vehicle to require a job transfer, the Device 130 may send a transfer out confirmation 124 to the Delivery Vehicle APP 120 to confirm its evaluation. The Delivery Vehicle APP 120 may confirm the evaluation, i.e. send a transfer-out request in 435 to indicate that it may become a transferor vehicle. In 436, based on the transfer order requirement including the delivery status, vehicle location, and delivery order requirements, the Transfer Schedule Planning sub-module 236 may plan a transfer coordination by determining various transfer configurations. In 437, the Delivery Scheduling sub-module 237 may compute a dispatch plan based on the transfer configuration candidates with applicable lead times for loading, unloading, vehicle speed, routing, transfer lead time. After a dispatch plan with the best transfer configuration is selected based on a performance index in 438, the Device 130 may send a transfer-in request 124 to a designated transferee vehicle in 439. In 440, the designated transferee vehicle may respond to the transfer-in request and may then send a transfer-in request confirmation 125 to the Device 130. In 441, the Device 130 may receive the transfer-in request confirmation. In 442, the Device may check the transfer-in request confirmation 125. If the designated transferee vehicle declined the transfer-in request, the Device 130 may consider another transferee vehicle and repeat 436, 437, 438, 439, and 441 until a transferee vehicle is found within a specific time period determined by Device 130. The specific time period may be set such that a transfer coordination is still appropriate or practical. If the designated transferee vehicle accepted the transfer-in request, the Device 130 may update the dispatch plan of transferor and transferee vehicles in 443 by sending dispatch plans 125 and 175 to the transferor vehicle and the transferee vehicles respectively. Alternatively, the Device 130 may store the updated dispatch plans locally and may inform the vehicle APP of the transferor vehicle and the transferee vehicle to download the updated dispatch plans. After the transferor vehicle and the transferee vehicle have received the updated dispatch plans, they may send a confirmation in 444, for example, through their vehicle APP. In 445, the Device 130 may send delivery updates 113 and 161 to the Sender APP 110 and the Receiver APP 160, respectively.

[0069] According to various embodiments, a rendezvous location may not be a single location but may include a pick-up point and a separate drop-off point. The pick-up point and the drop-off point may be close by, for example, within walking distance. The separation of the pick-up and drop-off into two locations maybe a practical consideration, for example, a particular rendezvous location may only be occupied for a short time. The Device 130 may notify the drivers/vehicles of the separation of the pick-up and drop-off points through delivery updates.

[0070] FIGS. 4C-4G show flowcharts relating to the process of determining transfer order requirements, according to various embodiments. FIG. 4C shows an overall flowchart 400C of the process performed by the Transfer Coordination Determination sub-module 233 according to various embodiments. FIGS. 4D-4G show sub-sections of the flowchart 400C. In 451, the Device 130 may receive the delivery status of vehicles and drivers of on-going deliveries. In 452, the Device 130 may calculate measurements for each vehicle and driver to determine potential job transfers. In 453, there may be a delay in dispatch plan schedule and the process may proceed to Element A, which will be described with respect to FIG. 4D. In 462, there may be a lack of available vehicles and the process may proceed to Element B, which will be described with respect to FIG. 4E. In 467, the driver’s maximum working time may have exceeded and the process may proceed to Element C, which will be described with respect to FIG. 4F. In 474, the delivery vehicles may have a breakdown such that it may require a change of parts, or the vehicle may have run out of fuel. The process may then proceed to Element D, which will be described with respect to FIG. 4G. After any one of Elements A, B, C, or D, the process may proceed to 480. The cases described in 453, 462, 467 and 474 are representative examples. The process may be applied to other scenarios that require job transfers. [0071] FIG. 4D shows a flowchart 400D of the Element A in the flowchart 400C. In Element A, the dispatch plan of a vehicle may be evaluated by calculating current or impending schedule delays. In 454, the current status, including at least one of location and operation, of the vehicle may be determined. In 455, the current status of the vehicle may be compared to that in the dispatch plan to calculate a time difference. In other words, in 455, the Device 130 may determine if the vehicle’s current status is lagging behind the schedule in the dispatch plan. In 457, the Device 130 determines if the time difference exceeds a minimum threshold. If the time difference exceeds the threshold, the Device 130 may use the remaining time or the expected delivery time assuming no transfer coordination, as a baseline measurement in 460. In 461, the Device 130 may set the logic for transfer schedule planning based on the minimum time to reach the delivery station. The logic may be received in the Transfer Schedule Planning sub-module 236. If in 457, the Device 130 determines that the time difference is less than the minimum threshold, the Device 130 may query the vehicle or the driver as to whether there are any incidents that may affect the delivery schedule, in 458. The incident may include any one of traffic congestion, road accident, and onset of poor weather condition. If the driver or the vehicle reports back that there are no incidents, the Device 130 may conclude that there is no need for a transfer coordination. However, if there is any incident, the Device 130 may estimate the consequential delay in 459, and then proceed to 460 and 461.

[0072] FIG. 4E shows a flowchart 400D of the Element B in the flowchart 400C. In Element 463, the Device 130 may check in the Delivery Scheduling sub-module 237, whether there is a delivery order that requires a vehicle type that is unavailable. If there is no such requirement, the Device 130 may conclude that there is no transfer coordination required. Otherwise, in 464, the Device 130 may calculate the minimum time for vehicle availability by estimating the remaining time for delivery of the vehicle. In 465, the Device 130 may use the calculated minimum time to calculate the earliest time to pick-up the delivery order assuming that it will be picked up by the vehicle after completing its current dispatch plan. The earliest time to pick up may be the baseline value for delivery without transfer coordination. Then, in 466, the transfer logic may be set to be vehicle compatibility.

[0073] FIG. 4F shows a flowchart 400D of the Element C in the flowchart 400C. In Element C, the working time of a driver, or an individual involved in a transport delivery, may be evaluated to determine if it exceeds a maximum limit. In 468, the current vehicle status of the driver may be determined. The Device 130 may calculate the remaining delivery time by considering delay, the return time to the driver’s base office and other factors, in 469. The Device 130 may calculate the remaining working time of the driver (assuming he completes the current dispatch plan) in 470. The Device 130 may then compare the calculated remaining working time with the remaining delivery time, in 471. In 472, the Device 130 may determine whether the remaining delivery time is longer than the remaining working time, and whether the difference between the remaining delivery time and the remaining working time exceeds a maximum threshold. If the difference exceeds the maximum threshold, the Device 130 may set the transfer logic based on the minimum time to obtain a driver replacement.

[0074] FIG. 4G shows a flowchart 400D of the Element D in the flowchart 400C. The scenarios of replacement of parts and fuel shortage are shown as a combined scenario in the flowcharts for conciseness, although in reality, these may be separate scenarios with different requirements. In 475, the Device 130 may determine the current vehicle status. In 476, the Device 130 may search for the nearest car repair shop or gasoline station, relative to the current vehicle location. In 477, the Device 130 may calculate the predicted delivery time that includes repair or refueling time. In 478, the Device 130 may check if the predicted delivery time is still within the delivery time window of the delivery order. If the Device 130 finds that the predicted delivery time may be outside of the delivery time window, the Device 130 may set the transfer logic based on minimum time to repair/refuel, in 479.

[0075] Referring back to FIG. 4C, in 480, the transfer logic may be stored in a transfer logic list. In 481, the Device 130 may determine if there are other cases to be checked. If the Device 130 determines that there are other cases to be checked, the process may repeat 452. If the Device 130 determines that there is no more case to be checked, in 483, the process may proceed to transfer schedule planning.

[0076] According to various embodiments, a key parameter in determining the transfer configuration may be the rendezvous location. The rendezvous location refers to the location where an item of a delivery order is transferred from the transferor vehicle to the transferee vehicle. The rendezvous location may be selected based on the location of the transferee vehicle, the locations of transferee vehicle candidates, and the transfer logic list stored in 480. Each vehicle may be associated with a respective list of transfer logic that defines how the rendezvous locations may be selected. For example, the logic corresponding to a schedule delay (Case_l shown in Element A) may require that the rendezvous location minimize the travel time to a destination location. For the following example, the transferor vehicle is denoted as vT and the transferee vehicle is denoted as vR. The location of the transferor vehicle is denoted as dT while the location of the transferee vehicle is denoted as dR. The location of a rendezvous candidate is denoted as dM while the destination location is denoted as dD. A function time(a,b,v) is defined as the travel time spent from a to b using vehicle v. The objective function for selecting the rendezvous location may be expressed as:

Casel_Function = minimize { MAX(time(dT, dM, vT), time(dR, dM, vR)) +

transferTime(dM, vT, vR) + time(dM, dD, vR)}, where MAX(·) returns the maximum value, and transferTime(·) is the time for transfer considering the rendezvous location and the vehicles, and delivery order. In the function (from left to right), the first addend corresponds to the meeting time of the vehicles from their current locations to a rendezvous location, the second addend takes into account the transfer time from receiving to transferring vehicle considering the rendezvous location, and other factors, the last addend is the delivery time of the transferee vehicle from the rendezvous location to the delivery location.

[0077] For the logic corresponding to unavailable compatible vehicle (Case_2 shown in Element B), the delivery order may originate at a pick-up location (e.g., customer sender location, warehouse, distribution center) denoted as dP. The vehicle location at the time of availability is denoted as dA. The rendezvous location may be selected based on where a compatible vehicle may be available within the shortest amount of time. The objective function may be expressed as:

Case2_Function = minimize {MAX(T1, T2)+ transferTime(dM, vT, vR) + time(dM, dD,

vR)},

where T1 = time(dT, dP, vT)+ time(dP, dM, vT) and T2 = time(dR, dA, vR)+ time(dA, dM, vR).

[0078] T1 may take into account the travel time of a transferor vehicle from its current location to a pick up location of the delivery order requiring a compatible vehicle at the destination, and then to the rendezvous location. T2 may take into account the availability of compatible transferee vehicle from the location point of availability (e.g., right after the completion of its current dispatch plan, assuming no other deliveries is schedules) to the rendezvous location and then to the rendezvous location.

[0079] For the logic corresponding to exceeding the maximum working time (Case_3 shown in Element C), the objective may be to find a rendezvous location that minimizes the excess working time of a driver while at the same time minimizing the possible delay in delivery time. Suppose a driver replacement is available at location dRep and utilizes vehicle vRep, which may be a public transport like bus, taxi, etc. The objective function may be expressed as:

Case3_Function = minimize { al * (MAX (time(dRep, dM, vRep), time(dT, dM, vT))+ jobShiftTime(dM)) + (1-al)* time(dM, dD, vT’)} where al is a coefficient with value e[0, 1], jobShiftTime (·) is the time duration to shift a driver to a driver replacement at the rendezvous location dM, and vT’ is the transferor vehicle after the shifting to the driver replacement, whose driving skill is different to the driver and may impact the delivery to the destination. The coefficient al may be a control factor corresponding to the severity of replacing driver. In some conditions, a driver may be agreeable to extend his/her working hours by a short time so that the delivery may be completed. In such a case, al may be a value less than 0.5. On the other hand, if extending working hours may pose health or safety risk, then al must be close to, or equal to 1.0.

[0080] For the logic corresponding to parts necessity or fuel shortage (Case_4 shown in Element D), the objective may be to find a rendezvous location that minimizes the delivery disruption due to part failure or fuel shortage. Suppose a mobile repair or refueling station vS is located at dS. The objective function may be expressed as:

Case4_Function = minimize {MAX (time(dS, dM, vS), time(dT, dM, vT))+ repairTime(dM, jobType)} + time(dM, dD, vT)},

where repairTime (dM, jobType) determines the time duration to conduct repair based on the location dM and the type of repair job jobType, which may be recognized to be applicable for refueling job.

[0081] With the objective function, a rendezvous location may be determined for a pair of transferor and transferee vehicle. It is possible that several cases may apply for a vehicle, or that the transfer logic list has more than one item. The rendezvous locations may be evaluated for all applicable objective functions. Then, an aggregation function with weighted factors may be used to calculate a single optimization value and then to select the rendezvous location.

[0082] FIG. 5 shows a diagram 500 that illustrates an example of dispatch plans without transfer coordination. Vehicle A 501 and vehicle B 507 may each follow an order of destinations for delivering products. Vehicle A 501 may be assigned to the sequence Location (T) 502 - Location @ 504 -> Location @ 506. Vehicle B 507 may be assigned to the sequence Location (4) 508 and Location (5) 510. One problem in assigning static dispatch plans to the vehicles is that a delay in the delivery at one location may result in delays of successive deliveries. For example, Vehicle A may run into delays when travelling between Location (T) 502 to location @ 504. This delay may cause Vehicle A to be also late in its delivery to location @ 506. Meanwhile, Vehicle B may deliver products from location (?) 508 to location (5) 510 without delay. The delays may be caused by, for example, a change in delivery order requirement (such as a change in the delivery time window, delivery order volume, or other new order requirements), change in driver (such as exceeding maximum working time limit, sudden illness, etc.), or due to environmental conditions (such as traffic congestion, road closure, incidence requiring unscheduled repair of vehicles). Re-routing Vehicle A 501 to avoid delay may not be possible, for example, in cases where the Vehicle A has technical failures, or if only one route is available to reach a delivery destination. The delivery sequence of Vehicle A may be rearranged to (T)->(3)->(2) to avoid further delay at location @. However, the delay at location @ would be increased.

[0083] FIGS. 6A and 6B show examples of prior art dispatch plans presented in tables, where the vehicles do not transfer delivery jobs. The fields in the tables are merely illustrative and do not limit the type of data stored in dispatch plans. FIG. 6A shows a dispatch plan table 600A of Vehicle A 501 while FIG. 6B shows a dispatch plan table 600B of Vehicle B 507. Each of the dispatch plan table 600A and 600B includes a Record Number column 602, a Vehicle column 604, an Operation column 606, a Location identifier column 608, a product code column 610, a planned arrival time column 612, an actual arrival time column 614, and a difference time column 616. The Record Number column 602 stores an identifier for each journey undertaken by the vehicles. The Vehicle column 604 stores the identifier of the vehicle that undertook the journey. The Operation column 606 stores a descriptor of the journey type, for example, delivery, or job transfer. The Location identifier column 608 stores an identifier of the destination location. The product code column 610 stores an identifier of the product that was delivered. The planned arrival time column 612 indicates the planned arrival time, while the actual arrival time column 614 indicates the actual arrival time. The difference time column 616 indicates the difference in time between the planned arrival time and the actual arrival time. The dispatch plans of Vehicle A 501 and Vehicle B 507 are independent of each other. The independent dispatch plans may have shortcoming, explained in the following. Take for example, a delivery order that requires a compatible vehicle with respect to a road network with narrow road segments, or an unloading area at a destination. A compatible vehicle has to be assigned to complete a job from pick-up to drop- off at the destination. With a limited number of compatible vehicles and conflicting times constraints such as required delivery time window, driver time availability, vehicle time availability, destination time opening and closing, a delivery order may not be scheduled for delivery with a compatible vehicle assigned from pickup to drop-off of delivery order.

[0084] FIG. 7 shows a diagram 700 that illustrates an example of dispatch plans with transfer coordination, according to various embodiments. Upon detecting, or receiving notice that Vehicle A 501 is delayed in its delivery to Location @ 504, the Device 130 may identify Vehicle B as a suitable transferee vehicle candidate. The Device 130 may direct Vehicle A 501 to transfer or hand-over the delivery order for Location @ 504 to Vehicle B 507, at a rendezvous location 702. The Device 130 may select the rendezvous location 702 based on the locations of both Vehicles A and B. Vehicle A 501 may then proceed to Location @ 506 from the rendezvous location 702. Vehicle B 507 may proceed to Location @ 504 from the rendezvous location 702, before making its way to Location (5) 510. By coordinating the job transfer between Vehicle A 501 and Vehicle B 507, the Device 130 has successfully recovered the delivery schedule for all of the remaining locations.

[0085] FIGS. 8A-8B show the dispatch plans of Vehicles A and B as shown in FIG. 7, which includes a job transfer. The fields in the tables are merely illustrative and do not limit the type of data stored in dispatch plans. FIG. 8A shows the dispatch plan table 800A of Vehicle A 501 while FIG. 8B shows a dispatch plan table 800B of Vehicle B 507. The dispatch plan table 800A includes a row 802 with information on the job transfer. The operation column 606 for the row 802 indicates that the operation at the rendezvous location 702 is a“transfer-out” for Vehicle A, i.e. a handover of a delivery order. Unlike in the table 600A, the time difference column 616 in the table 800A shows no time difference. In other words, there is no delivery delay incurred by Vehicle A. In FIG. 8B, the table 800B includes a row 804 with information on the job transfer. The operation column 606 for the row 804 indicates that the operation at the rendezvous location 702 is a“transfer-in” for Vehicle B, i.e. a takeover of a delivery order. Unlike in the table 600B, the time difference column 616 in the table 800B shows no time difference, except for a short time difference of 5 minutes for the delivery to Location @ 504. Therefore, the delays in the delivery schedules of all the locations are minimized with the job transfer.

[0086] In the example shown in FIGS. 7 and 8A-8B, the transfer configuration may include the rendezvous location (R) 702, the routing of Vehicle A 501 from 502 to 702, the path of vehicle B from 508 to 702, the timing of Vehicle A 501 for the handover, the timing of Vehicle 507 for the takeover, and the product for transfer AY. After the vehicles reach the rendezvous location ® 702, the item to be delivered to Location @ 504 may be transferred from Vehicle A 501 to Vehicle B 507. Then, Vehicle A 501 may proceed from location ® 702 to location @ 506 via the routing 703, without going to location @ 504. On the other hand, vehicle B upon taking in product AY, may deliver it to location @ 504, and then proceed to location (5) 510 to deliver another order. A delay may be avoided assuming that the performance index is delivery time. However, the method of planning dispatch route as described is not limited to the performance index of delivery time, and may be applied to other performance indices such as delivery cost, number of vehicles, fuel usage, mileage coverage, or a combination of several performance indices, among other things.

[0087] In another example, a large amount of delivery orders may have to be transported from an origin such as a warehouse or a production facility to several outlets or distribution centers. These deliveries may take a large amount of delivery time considering the distance between the various locations and the varying operating hours and other specific requirements at the various destinations. While prior art methods of planning the dispatch routes may generate fixed dispatch plans for each vehicle, such prior art methods may be inefficient as it may not be possible to use the vehicles at full capacity due to the constraints of each delivery location. The constraints may include delivery time constraint, location constraint and other operational constraints. As such, a large number of vehicles may be required to transport the delivery orders to their destinations.

[0088] FIGS. 9A-9D show a method of generating delivery route plans according to various embodiments, as applied to facilitating a virtual warehouse. The method may solve the problem in the abovementioned example. FIG. 9A shows a diagram 910. The diagram 910 shows that Items 912 may be loaded from a Warehouse 911 to a large vehicle 913. The Items 912 may need to be delivered to destinations 917, 918 and 919 which may be close to one another. However, the distance between the Warehouse 911 and these destinations 917, 918 and 919 may be far. The roads leading to the destinations 917, 918 and 919 may also be narrow. These destinations may have constraints such as being accessible only to small vehicles, such as small vehicles 914, 915, 916, due to the narrow road connections, loading bay constraints, truck ban at specific location over a period of time, on-going maintenance works that limits passage of specific vehicles, among others. For this reason, specific vehicle types may be used to deliver goods to these destinations. [0089] FIG. 9B shows a diagram 920. The diagram 920 shows that the method may include planning a rendezvous location 925 where the large vehicle 913 and the small vehicles 914, 915, and 916 may meet. The rendezvous location 925 may be treated as a virtual warehouse. The rendezvous location 925 may be determined based on the routes 921, 922, 923 and 924 of each vehicle, and other factors such as vehicle compatibility to destination, and time constraints. The rendezvous location 925 may be changed depending on the destinations, order amount, among others.

[0090] FIG. 9C shows a diagram 930. The diagram 930 shows that the method may include using the large vehicle 913 to transfer the Items 912 to the small vehicles 914, 915 and 916.

[0091] FIG. 9D shows a diagram 940. The diagram 940 shows that the large vehicle 913 may return to the warehouse 911 to load another round of items. The small vehicles 914, 915 and 916 may deliver the items 912 to their respective destinations 917, 918 and 919.

[0092] According to various embodiments, the delivery route planning apparatus may support the iterative application of job transfer coordination by configuring variable rendezvous locations and transfer configurations of the vehicles depending on the order requirement, and available vehicles. About the aforementioned virtual factory concept, the delivery route planning apparatus may further be configured so that the delivery orders that come from several locations may be picked up by multiple vehicles. At a certain rendezvous location, these orders may be collected or transferred to a large capacity vehicle. The large capacity vehicle may then deliver these orders to another location for another job transfer.

[0093] According to various embodiments, the delivery route planning apparatus may generate original dispatch plan with transfer coordination to fulfil delivery order requirements. On the other hand, the delivery route planning apparatus may be utilized to modify an existing dispatch plan to conduct transfer coordination to minimize delays in the delivery or optimize a certain performance index.

[0094] FIG. 10 shows a delivery route planning apparatus 1000 according to various embodiments. The delivery route planning apparatus 1000, also referred herein simply as route planner, may include a transfer request generator 1002, a candidate identifier 1004, a rendezvous selector 1006, an optimization program 1008, and an updater 1010. The delivery route planner may include, or may be part of, the Device 130. The transfer request generator 1002 may be configured to generate a job transfer request. The job transfer request may indicate a transfer of a delivery task from a transferor vehicle of a plurality of vehicles to a transferee vehicle of the plurality of vehicles. The delivery task, also referred to as a delivery job, may include delivering an item to a predefined destination within a predefined delivery time window. The item may be any physical object, article, device, or person. The job transfer request may be for example, the transfer out request 123, or the work transfer request 153 shown in FIG. 1. The candidate identifier 1004 may be configured to identify candidates for the transferee vehicle based on at least distances of the plurality of vehicles from the transferor vehicle. The candidate identifier 1004 may include, or may be part of, the transfer schedule planning sub-module 236. The rendezvous selector 1006 may be configured to select a plurality of possible rendezvous locations from a location database based on locations of the identified candidates. The rendezvous selector 1006 may include, or may be part of, the rendezvous configuration discovery sub-module 235. The optimization program 1008 may be configured to select the transferee vehicle and to determine each of a rendezvous location and a rendezvous time. The optimization program 1008 may optimize route plans of the transferor vehicle and the transferee vehicle with respect to a plurality of criteria stored in the server. Inputs to the optimization program 1008 may include the plurality of possible rendezvous locations and existing delivery route plans of the candidates. The optimization program 1008 may be part of the Delivery Scheduling sub-module 237 and/or the Delivery Routing Solver 238. An updater 1010 may be configured to update delivery route plans of the transferor vehicle and the transferee vehicle based on the determined rendezvous location and rendezvous time. The updater 1010 may include, or may be part of, the Dispatch Plan Updating sub-module 239. The transfer request generator 1002, the candidate identifier 1004, the rendezvous selector 1006, the optimization program 1008, and the updater 1010 may be coupled with each other, like indicated by lines 1110, for example electrically coupled, for example using a line or a cable, and/or mechanically coupled and/or communicatively coupled.

[0095] FIG. 11 shows a delivery route planning apparatus 1100 according to various embodiments. The delivery route planning apparatus 1100, may include the delivery route planning apparatus 1000, and may further include a delay detector 1112 and a receiver 1114. The receiver 1114 may be configured to receive geographical positions of the plurality of vehicles in the server, from respective wireless transmitters coupled to the plurality of vehicles. The candidate identifier 1004 may be configured to determine the distances of the plurality of vehicles from the transferor vehicle based on the received geographical positions. The candidate identifier 1004 may be configured to identify the candidates for the transferee vehicle based on the determined distances. The delay detector 1112 may be configured to detect delays in any delivery tasks based on the geographical positions of the plurality of vehicles received by the receiver 1114. Alternatively, or additionally, the delay detector 1112 may detect the delays in any delivery tasks based on at least one of driver status (for example: tiredness of the driver, or illness of the driver) and vehicle status (for example: degradation of the vehicle or fuel shortage). The delay detector 1112 may include, or may be part of, the Transfer Coordination Determination sub-module 233. The transfer request generator 1002 may be configured to generate the job transfer request upon the delay detector detecting a delay in the delivery task of the transferor vehicle. The transfer request generator 1002, the candidate identifier 1004, the rendezvous selector 1006, the optimization program 1008, the updater 1010, the delay detector 1112 and the receiver 1114 may be coupled with each other, like indicated by lines 1111, for example electrically coupled, for example using a line or a cable, and/or mechanically coupled and/or communicatively coupled.

[0096] FIG. 12 shows a flow diagram 1200 of a method of generating delivery route plans for a plurality of vehicles according to various embodiments. The method may include receiving a job transfer request in a server, in 1202. The job transfer request may indicate a transfer of a delivery task from a transferor vehicle of the plurality of vehicles to a transferee vehicle of the plurality of vehicles. The method may include identifying candidates for the transferee vehicle, in 1204. The identification may be based on at least distances of the plurality of vehicles from the transferor vehicle. The method may include selecting a plurality of possible rendezvous locations, in 1206. The selection may be based on locations of the identified candidates. The method may include running an optimization program, in 1208. The optimization program may be run to select the transferee vehicle and to determine each of a rendezvous location and a rendezvous time. The optimization program may optimize route plans of the transferor vehicle and the transferee vehicle with respect to a plurality of criteria stored in the server. Inputs to the optimization program may include the plurality of possible rendezvous locations and existing delivery route plans of the candidates. The optimization program may be configured to run one of a mixed integer linear programming and a constrained optimization search. The method may include updating delivery route plans of the transferor vehicle and the transferee vehicle, in 1201. The updating may be based on the determined rendezvous location and the rendezvous time.

[0097] According to various embodiments, in the method shown in FIG. 12, the plurality of criteria may include fulfilling at least one of predefined delivery schedules, maximizing fuel efficiency and the working hours of drivers of the transferee vehicle and the transferor vehicle. The plurality of criteria may differ depending on the scenario or case that necessitates the job transfer, for example, as described with respect to FIGS. 4C to 4G, for example, described with respect to Elements A, B, C and D. The candidates for the transferee vehicle may be identified further based on physical characteristics of the plurality of vehicles retrieved from a vehicle database, for example Vehicle Data 137. The physical characteristics may include at least one of vehicle type, load capacity and vehicle dimensions. The candidates for the transferee vehicle may be identified further based on whether the physical characteristics of the vehicles fulfill vehicle requirements associated with the delivery task. The vehicle requirements may be retrieved from the delivery order data 138. Alternatively, or additionally, the job transfer request may include the vehicle requirements. The vehicle requirements may include at least one of volume of an item to be delivered, weight of the item to be delivered, and accessibility at the delivery location. The accessibility may, for example, refer to whether the roads leading to the destination are wide or narrow, or whether it includes a loading/unloading bay. The candidates for the transferee vehicle may be identified further based on the job requirements associated with the delivery task and existing delivery route plans of the vehicles. The job requirements may include at least one of delivery location, agreed delivery time, and unloading time of an item to be delivered. The job requirements may be retrieved from the delivery order data 138. Alternatively, or additionally, the job transfer request may include the job requirements.

[0098] According to various embodiments, the method shown in FIG. 12 may further include receiving geographical positions of the plurality of vehicles in the server, from respective wireless transmitters coupled to the plurality of vehicles. Identifying candidates for the transferee vehicle from the plurality of vehicles may include determining the distances of the plurality of vehicles from the transferor vehicle based on the received geographical positions. The method may further include, for example, in a centralized embodiment or operation mode, generating the job transfer request, upon detecting a delay in the delivery task of the transferor vehicle. The delay may be detected by comparing the received geographical positions of the plurality of vehicles to their respective delivery route plans. Alternatively, or additionally, the delay may be detected by assessing availability of the driver.

[0099] The method may further include, distributing a plurality of delivery tasks among the plurality of vehicles based on matching physical characteristics of the plurality of vehicles to vehicle requirements associated with the delivery tasks and matching job requirements associated with the delivery tasks to existing route plans of the plurality of vehicles. The method may further include generating delivery route plans of each vehicle of the plurality of vehicles based on the distribution of the delivery tasks. The physical characteristics may include at least one of vehicle type, load capacity and vehicle dimensions. Information on the physical characteristics may include, or may be part of, the Vehicle Data 137. The vehicle requirements may include at least one of volume of an item to be delivered, weight of the item to be delivered, and accessibility at the delivery location. The job requirements may include at least one of delivery location, agreed delivery time, and unloading time of an item to be delivered. Information on the vehicle requirements and the job requirements may include, or may be part of, the Delivery Order Data 138 and the Delivery Location Data 139.

[00100] According to various embodiments, the method may further include identifying a delivery task that is unassigned to any vehicle of the plurality of vehicles due to at least one of a mismatch between the vehicle requirements and the physical characteristics, and a mismatch between the job requirements and the existing route plans of the vehicles. The method may further include assigning the identified delivery task to a vehicle selected from the plurality of vehicles based on at least one of partial matching between the vehicle requirements and the physical characteristics, and partial matching between the job requirements and the existing route plans of the vehicles. The method may further include generating the job transfer request for transferring the identified delivery task from the selected vehicle to another vehicle at a rendezvous location. For example, in the virtual warehouse concept, the vehicle requirements for the delivery order may not entirely match the physical characteristics of the large capacity vehicles that retrieve the delivery goods from the physical warehouse. The method may include planning job transfers between the large capacity vehicles and the small capacity vehicles to bridge the mismatch.

[00101] According to various embodiments, the method may further include broadcasting the job transfer request to the plurality of vehicles through a wireless network, and receiving job acceptance requests from vehicles that are interested to take over the delivery task through the wireless network, for example, in a decentralized embodiment or operation mode. Each vehicle of the plurality of vehicles may be coupled to a wireless transceiver. Receiving the job transfer request may include receiving via the wireless network. The job transfer request may be transmitted by the transferor vehicle using its wireless transceiver. Identifying candidates for the transferee vehicle may include identifying the candidates further based on the received job acceptance requests. For example, the candidates may be identified from only a pool of vehicles that received the job acceptance requests.

[00102] While embodiments of the invention have been particularly shown and described with reference to specific embodiments, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. The scope of the invention is thus indicated by the appended claims and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced. It will be appreciated that common numerals, used in the relevant drawings, refer to components that serve a similar or the same purpose.

[00103] It will be appreciated to a person skilled in the art that the terminology used herein is for the purpose of describing various embodiments only and is not intended to be limiting of the present invention. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

[00104] It is understood that the specific order or hierarchy of blocks in the processes / flowcharts disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the processes / flowcharts may be rearranged. Further, some blocks may be combined or omitted. The accompanying method claims present elements of the various blocks in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

[00105] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean“one and only one” unless specifically so stated, but rather“one or more.” The word“exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects. Unless specifically stated otherwise, the term “some” refers to one or more. Combinations such as“at least one of A, B, or C,”“one or more of A, B, or C,”“at least one of A, B, and C,”“one or more of A, B, and C,” and“A, B, C, or any combination thereof’ include any combination of A, B, and/or C, and may include multiples of A, multiples of B, or multiples of C. Specifically, combinations such as“at least one of A, B, or C,”“one or more of A, B, or C,”“at least one of A, B, and C,”“one or more of A, B, and C,” and“A, B, C, or any combination thereof’ may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, where any such combinations may contain one or more member or members of A, B, or C. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. The words“module,”“mechanism,”“element,”“device,” and the like may not be a substitute for the word“means.” As such, no claim element is to be construed as a means plus function unless the element is expressly recited using the phrase“means for.”

Claims

1. A method of generating delivery route plans for a plurality of vehicles, the method comprising:

receiving a job transfer request in a server, the job transfer request indicating a transfer of a delivery task from a transferor vehicle of the plurality of vehicles to a transferee vehicle of the plurality of vehicles;

identifying candidates for the transferee vehicle, based on at least distances of the plurality of vehicles from the transferor vehicle;

selecting a plurality of possible rendezvous locations from a location database, based on locations of the identified candidates;

running an optimization program to select the transferee vehicle and to determine each of a rendezvous location and a rendezvous time,

wherein the optimization program optimizes route plans of the transferor vehicle and the transferee vehicle with respect to a plurality of criteria stored in the server, wherein inputs to the optimization program comprises the plurality of possible rendezvous locations and existing delivery route plans of the candidates; and

updating delivery route plans of the transferor vehicle and the transferee vehicle based on the determined rendezvous location and rendezvous time.

2. The method of claim 1, wherein the plurality of criteria comprises at least one of fulfilling predefined delivery schedules, maximizing fuel efficiency and working hours of drivers of the transferee vehicle and the transferor vehicle.

3. The method of claim 1, wherein the candidates for the transferee vehicle are identified further based on physical characteristics of the plurality of vehicles retrieved from a vehicle database, the physical characteristics comprising at least one of vehicle type, load capacity and vehicle dimensions.

4. The method of claim 3, wherein the candidates for the transferee vehicle are identified further based on whether the physical characteristics of the vehicles fulfill vehicle requirements associated with the delivery task, the vehicle requirements comprising at least one of volume of an item to be delivered, weight of the item to be delivered, and accessibility at the delivery location.

5. The method of claim 4, wherein the job transfer request comprises the vehicle requirements associated with the delivery task.

6. The method of claim 1, wherein the candidates for the transferee vehicle are identified further based on the job requirements associated with the delivery task and existing delivery route plans of the vehicles, the job requirements comprising at least one of delivery location, agreed delivery time, and unloading time of an item to be delivered.

7. The method of claim 6, wherein the job transfer request comprises the job requirements associated with the delivery task.

8. The method of claim 1, further comprising:

selecting the plurality of possible rendezvous locations further based on statistical analysis of spatial and temporal information of completed job transfers.

9. The method of claim 1, further comprising:

receiving geographical positions of the plurality of vehicles in the server, from respective wireless transmitters coupled to the plurality of vehicles.

10. The method of claim 9, wherein identifying candidates for the transferee vehicle from the plurality of vehicles comprises determining the distances of the plurality of vehicles from the transferor vehicle based on the received geographical positions.

11. The method of claim 9, further comprising:

generating the job transfer request, upon detecting a delay in the delivery task of the transferor vehicle; wherein detecting the delay comprises at least one of comparing the received geographical positions of the plurality of vehicles to their respective delivery route plans, and assessing availability of the driver.

12. The method of claim 1, further comprising:

distributing a plurality of delivery tasks among the plurality of vehicles, based on matching physical characteristics of the plurality of vehicles to vehicle requirements associated with the delivery tasks and matching job requirements associated with the delivery tasks to existing route plans of the plurality of vehicles; and

generating delivery route plans of each vehicle of the plurality of vehicles, based on the distribution of the delivery tasks;

wherein the physical characteristics comprises at least one of vehicle type, load capacity and vehicle dimensions;

wherein the vehicle requirements comprises at least one of volume of an item to be delivered, weight of the item to be delivered, and accessibility at the delivery location; and wherein the job requirements comprises at least one of delivery location, agreed delivery time, and unloading time of an item to be delivered.

13. The method of claim 1, further comprising:

identifying a delivery task that is unassigned to any vehicle of the plurality of vehicles, due to at least one of a mismatch between the vehicle requirements and the physical characteristics and a mismatch between the job requirements and the existing route plans of the vehicles; and

assigning the identified delivery task to a vehicle selected from the plurality of vehicles based on at least one of partial matching between the vehicle requirements and the physical characteristics and partial matching between the job requirements and the existing route plans of the vehicles; and

generating the job transfer request for transferring the identified delivery task from the selected vehicle to another vehicle at a rendezvous location.

14. The method of claim 1, wherein each vehicle of the plurality of vehicles is coupled to a wireless transceiver, wherein receiving the job transfer request comprises receiving via a wireless network, the job transfer request transmitted by the transferor vehicle using its wireless transceiver.

15. The method of claim 14, further comprising:

broadcasting the job transfer request to the plurality of vehicles through the wireless network; and

receiving job acceptance requests from vehicles that are interested to take over the delivery task through the wireless network.

16. The method of claim 15, wherein identifying candidates for the transferee vehicle comprises identifying the candidates further based on the received job acceptance requests.

17. A delivery route planning apparatus comprising:

a transfer request generator configured to generate a job transfer request, the job transfer request indicating a transfer of a delivery task from a transferor vehicle of a plurality of vehicles to a transferee vehicle of the plurality of vehicles;

a candidate identifier configured to identify candidates for the transferee vehicle, based on at least distances of the plurality of vehicles from the transferor vehicle;

a rendezvous selector configured to select a plurality of possible rendezvous locations from a location database, based on locations of the identified candidates;

an optimization program configured to select the transferee vehicle and to determine each of a rendezvous location and a rendezvous time,

an updater configured to update delivery route plans of the transferor vehicle and the transferee vehicle based on the determined rendezvous location and rendezvous time.

18. The delivery route planning apparatus of claim 17, further comprising: a receiver configured to receive geographical positions of the plurality of vehicles in the server, from respective wireless transmitters coupled to the plurality of vehicles.

19. The delivery route planning apparatus of claim 18, wherein the candidate identifier is configured to determine the distances of the plurality of vehicles from the transferor vehicle based on the received geographical positions, wherein the candidate identifier is configured to identify the candidates for the transferee vehicle based on the determined distances.

20. The delivery route planning apparatus of claim 18, further comprising:

a delay detector configured to detect delays in any delivery tasks based on the received geographical positions of the plurality of vehicles;

wherein the transfer request generator is configured to generate the job transfer request upon the delay detector detecting a delay in the delivery task of the transferor vehicle.