COMMUNICATIONS SERVER APPARATUS AND METHOD FOR ALLOCATING RESOURCES TO SERVICE REQUESTS RELATED TO A SHARED ECONOMY ON-DEMAND SERVICE OR ASSET PROVISION

Abstract

A communications server apparatus, and associated method, for allocating resources to service requests related to a shared economy on demand service or asset provision, the communications server apparatus comprising a processor and a memory, and being configured, under the control of the processor, to execute instructions stored in the memory to receive a plurality of service requests, each service request comprising data representative of a service or asset requested and a delivery time at or by which said service or asset is required; determine, in respect of each said service request, a lead time comprising a time period between a time at which a respective service request is received and the associated delivery time; compare each said lead time with a predetermined threshold, and define each respective lead time as high if it is greater than the predetermined threshold and low if it is less than the predetermined threshold; receive resource data comprising data representative of available resources capable of providing said service or asset; generate cost matrix data, each element of said cost matrix being representative of an available resource-service request pair, said cost matrix data assigning, in respect of each available resource-service request pair, a cost value; wherein assigning cost values comprises calculating, for each available resource-service request pair, a cost value, dependent on whether the lead time associated with the respective service request is high or low; and, for each service request, select, from a respective set of available resource-service request pair cost values, a minimum cost value and assign the available resource associated with the selected cost value to the respective service request.

Claims

1.-15. (canceled)

16. A communications server apparatus for allocating resources to service requests related to a shared economy on-demand service or asset provision, the communications server apparatus comprising a processor and a memory, and being configured, under the control of the processor, to execute instructions stored in the memory to: receive a plurality of service requests, each service request comprising data representative of a service or asset requested and a delivery time at or by which said service or asset is required; determine, in respect of each said service request, a lead time comprising a time period between a time at which a respective service request is received and the associated delivery time; compare each said lead time with a predetermined threshold, and define each respective lead time as high if it is greater than the predetermined threshold and low if it is less than the predetermined threshold; receive resource data comprising data representative of available resources capable of providing said service or asset, the available resources including service providers that are currently fulfilling a previous service request, and service providers that are not currently fulfilling a service request; generate cost matrix data, each element of said cost matrix being representative of an available resource-service request pair, said cost matrix data assigning, in respect of each available resource-service request pair, a cost value; wherein said assigning a cost value in respect of each available resource-service pair comprises calculating, for each available resource-service request pair, the cost value, dependent on whether the lead time associated with the respective service request is high or low, wherein a first calculation is performed to calculate the cost value for an available resource-service request pair if the lead time associated with the respective service request is defined as high, and a second, different calculation is performed to calculate the cost value for an available resource-service request pair if the lead time associated with the respective service request is defined as low; for each service request, select, from a respective set of available resource-service request pair cost values, a minimum cost value and assign the available resource associated with the selected cost value to the respective service request.

17. A communications server apparatus according to claim 16, configured for the generation of said cost matrix to comprise applying a linear assignment algorithm to data derived from said service requests and said resource data.

18. A communications server apparatus according to claim 16, configured for only said first calculation to use a parameter representative of service or asset delivery delay time if a respective available resource cannot provide the service or asset by the delivery time specified in the respective service request.

19. A communications server apparatus according to claim 18, configured for said delivery delay time to be weighted according to an estimated time period within which a respective available resource will be able to provide the respective service or asset.

20. A communications server apparatus according to claim 16, configured for said first and second calculations to use a parameter representative of a lag time if a respective available resource is able to provide a respective service or asset earlier than the specified delivery time.

21. A communications server apparatus according to claim 20, configured for said lag time to be weighted according to an estimated time period within which a respective available resource will be able to provide the respective specified service or asset.

22. A communications server apparatus according to claim 16, configured for said first calculation to comprise a sum of a time value representative of a time period within which a respective available resource will be able to provide the respective specified service or asset, a weighted lag time if the respective available resource is able to provide the service or asset earlier than the delivery time specified in the respective service request, and a weighted delivery delay time if a respective available resource cannot provide the service or asset associated with the respective user request by the specified delivery time; and for the second calculation to comprise a sum of a time value representative of a time period within which a respective available resource will be able to provide the respective specified service or asset and a weighted lag time if the respective available resource is able to provide the service or asset earlier than the delivery time specified in the respective service request.

23. A communications server apparatus according to claim 16, for allocating resources to service requests related to a product delivery service, configured for each said service request to represent a request by a service user for a delivery vehicle to transport a product from a product merchant location specified in said service request to an end user and to comprise data representative of a product delivery order and a collection time at which said product will be ready for collection from the product merchant location by the delivery vehicle; and for said lead time to comprise a time period between t time at which a respective service request is received and the associated collection time, and for said resource data to comprise data representative of available delivery vehicles and their current geographical location.

24. A communications server apparatus according to claim 23, configured for said product delivery service to comprise a food delivery service.

25. A communications server apparatus according to claim 23, comprising a routing engine for estimating, in respect of each available delivery vehicle resource, a time period within which a respective delivery vehicle can travel to the product merchant location specified in a service request at which a product for delivery is to be collected.

26. A method, performed in a communications server apparatus, for allocating resources to service requests related to a shared economy on-demand service or asset provision, the method comprising, under control of a processor of the communications server apparatus: receiving a plurality of service requests, each service request comprising data representative of a service or asset requested and a delivery time at or by which said service or asset is required; determining, in respect of each said service request, a lead time comprising a time period between a time at which a respective service request is received and the associated delivery time; comparing each said lead time with a predetermined threshold, and define each respective lead time as high if it is greater than the predetermined threshold and low if it is less than the predetermined threshold; receiving resource data comprising data representative of available resources capable of providing said service or asset, the available resources including service providers that are currently fulfilling a previous service request, and service providers that are not currently fulfilling a service request; generating cost matrix data, each element of said cost matrix being representative of an available resource-service request pair, said cost matrix data assigning, in respect of each available resource-service request pair, a cost value; wherein said assigning a cost value in respect of each available resource-service pair comprises calculating, for each available resource-service request pair, the cost value, dependent on whether the lead time associated with the respective service request is high or low, wherein a first calculation is performed to calculate the cost value for an available resource-service request pair if the lead time associated with the respective service request is defined as high, and a second, different calculation is performed to calculate the cost value for an available resource-service request pair if the lead time associated with the respective service request is defined as low; for each service request, selecting, from a respective set of available resource-service request pair cost values, a minimum cost value and assign the available resource associated with the selected cost value to the respective service request.

27. A non-transitory storage medium storing instructions which, when executed by a processor of a communications server apparatus, cause the processor to perform a method for allocating resources to service requests related to a shared economy on-demand service or asset provision, the method comprising, under control of a processor of the communications server apparatus: receiving a plurality of service requests, each service request comprising data representative of a service or asset requested and a delivery time at or by which said service or asset is required; determining, in respect of each said service request, a lead time comprising a time period between a time at which a respective service request is received and the associated delivery time; comparing each said lead time with a predetermined threshold, and define each respective lead time as high if it is greater than the predetermined threshold and low if it is less than the predetermined threshold; receiving resource data comprising data representative of available resources capable of providing said service or asset, the available resources including service providers that are currently fulfilling a previous service request, and service providers that are not currently fulfilling a service request; generating cost matrix data, each element of said cost matrix being representative of an available resource-service request pair, said cost matrix data assigning, in respect of each available resource-service request pair, a cost value; wherein said assigning a cost value in respect of each available resource-service pair comprises calculating, for each available resource-service request pair, the cost value, dependent on whether the lead time associated with the respective service request is high or low, wherein a first calculation is performed to calculate the cost value for an available resource-service request pair if the lead time associated with the respective service request is defined as high, and a second, different calculation is performed to calculate the cost value for an available resource-service request pair if the lead time associated with the respective service request is defined as low; for each service request, selecting, from a respective set of available resource-service request pair cost values, a minimum cost value and assign the available resource associated with the selected cost value to the respective service request.

28. A communications system for allocating resources to service requests related to a shared economy on-demand service or asset provision, the communications system comprising at least one user communications device and communications network equipment operable for the communications server apparatus and the at least one user communications device to establish communication with each other therethrough, and at least one service or asset provider communications device and communications network equipment operable for the communications server apparatus and the at least one service provider communications device to establish communication with each other therethrough, the communications server apparatus comprising a processor and a memory, and being configured, under the control of the processor, to execute instructions stored in the memory to: receive a plurality of service requests, each service request comprising data representative of a service or asset requested and a delivery time at or by which said service or asset is required; determine, in respect of each said service request, a lead time comprising a time period between a time at which a respective service request is received and the associated delivery time; compare each said lead time with a predetermined threshold, and define each respective lead time as high if it is greater than the predetermined threshold and low if it is less than the predetermined threshold; receive resource data comprising data representative of available resources capable of providing said service or asset, the available resources including service providers that are currently fulfilling a previous service request, and service providers that are not currently fulfilling a service request; generate cost matrix data, each element of said cost matrix being representative of an available resource-service request pair, said cost matrix data assigning, in respect of each available resource-service request pair, a cost value; wherein said assigning a cost value in respect of each available resource-service request pair comprises calculating, for each available resource-service request pair, the cost value, dependent on whether the lead time associated with the respective service request is high or low, wherein a first calculation is performed to calculate the cost value for an available resource-service request pair if the lead time associated with the respective service request is defined as high, and a second, different calculation is performed to calculate the cost value for an available resource-service request pair if the lead time associated with the respective service request is defined as low; for each service request, select, from a respective set of available resource-service request pair cost values, a minimum cost value and assign the available resource associated with the selected cost value to the respective service request.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The invention will now be described by way of example only, and with reference to the accompanying drawings in which:

[0021] FIG. 1 is a schematic block diagram illustrating an exemplary communications system including a communications server apparatus for allocating resources to service requests related to a shared economy on-demand service;

[0022] FIG. 2 is a schematic block diagram illustrating an exemplary communications system including an exemplary communications server apparatus for allocating resources to service requests related to a shared economy on-demand service;

[0023] FIG. 3 is a schematic process diagram illustrating an exemplary method for allocating resources to service requests related to a shared economy service in the form of a food delivery service; and

[0024] FIG. 4 is a schematic illustration of an order-driver cost matrix, stored in a database, for use in allocating orders to drivers related to a food (or other) delivery service.

DETAILED DESCRIPTION

[0025] The techniques described herein are described primarily with reference to use in food (or other perishable or time-sensitive goods) delivery services, but it will be appreciated that these techniques may have a broader reach and cover other types of shared economy services wherein there is at least one unpredictable and highly variable parameter associated with each service request, and in some cases where there may be a need to take into account historical resource behaviour or reliability, when determining a cost associated with a set of available resources in respect of a specified service request.

[0026] Referring first to FIG. 1, a communications system 100 is illustrated. Communications system 100 comprises communications server apparatus 102, user communications device 104 and service provider communications device 106. These devices are connected in the communications network 108 (for example the Internet) through respective communications links 110, 112, 114 implementing, for example, internet communications protocols. Communications devices 104, 106 may be able to communicate through other communications networks, such as public switched telephone networks (PSTN networks), including mobile cellular communications networks, but these are omitted from FIG. 1 for the sake of clarity.

[0027] Communications server apparatus 102 may be a single server as illustrated schematically in FIG. 1, or have the functionality performed by the server apparatus 102 distributed across multiple server components. In the example of FIG. 1, communications server apparatus 102 may comprise a number of individual components including, but not limited to, one or more microprocessors 116, a memory 118 (e.g. a volatile memory such as a RAM) for the loading of executable instructions 120, the executable instructions defining the functionality the server apparatus 102 carries out under control of the processor 116. Communications server apparatus 102 also comprises an input/output module 122 allowing the server to communicate over the communications network 108. User interface 124 is provided for user control and may comprise, for example, computing peripheral devices such as display monitors, computer keyboards and the like. Communications server apparatus 102 also comprises a database 126, the purpose of which will become readily apparent from the following discussion. In this embodiment, database 126 is part of the communications server apparatus 102, however, it should be appreciated that database 126 can be separated from communications server apparatus 102 and database 126 may be connected to the communications server apparatus 102 via communications network 108 or via another communications link (not shown).

[0028] User communications device 104 may comprise a number of individual components including, but not limited to, one or more microprocessors 128, a memory 130 (e.g. a volatile memory such as a RAM) for the loading of executable instructions 132, the executable instructions defining the functionality the user communications device 104 carries out under control of the processor 128. User communications device 104 also comprises an input/output module 134 allowing the user communications device 104 to communicate over the communications network 108. User interface 136 is provided for user control. If the user communications device 104 is, say, a smart phone or tablet device, the user interface 136 will have a touch panel display as is prevalent in many smart phone and other handheld devices. Alternatively, if the user communications device is, say, a desktop or laptop computer, the user interface may have, for example, computing peripheral devices such as display monitors, computer keyboards and the like.

[0029] Service provider communications device 106 may be, for example, a smart phone or tablet device with the same or a similar hardware architecture to that of user communications device 104. Service provider communications device 106 may comprise a number of individual components including, but not limited to, one or more microprocessors 138, a memory 140 (e.g. a volatile memory such as a RAM) for the loading of executable instructions 142, the executable instructions defining the functionality the service provider communications device 106 carries out under control of the processor 138. Service provider communications device 106 also comprises an input/output module (which may be or include a transmitter module/receiver module) 144 allowing the service provider communications device 106 to communicate over the communications network 108. User interface 146 is provided for user control. If the service provider communications device 106 is, say, a smart phone or tablet device, the user interface 146 will have a touch panel display as is prevalent in many smart phone and other handheld devices. Alternatively, if the user communications device is, say, a desktop or laptop computer, the user interface may have, for example, computing peripheral devices such as display monitors, computer keyboards and the like.

[0030] In one embodiment, the service provider communications device 106 is configured to push data representative of the service provider (e.g. service provider identity, location and so on) regularly to the communications server apparatus 102 over communications network 108. In another, the communications server apparatus 102 polls the service provider communications device 106 for information. In either case, the data from the service provider communications device 106 (also referred to herein as ‘available data’ or ‘supply’ data) are communicated to the communications server apparatus 102 and at least some parameters or characteristics thereof stored in relevant locations in the database 126 as historical data. Such supply data stored in the database 126 may be used to generate historical resource availability and reliability data that could include any one or more of, numbers of available service providers in a particular area or region, times of day associated with the service provider availability, service provider ‘ignore’ or ‘reject’ rate (resource reliability data), and even idle times associated with available service providers, so that supply distribution data can be generated and used to predict likely available resources for a particular region, depending on characteristics such as day of the week, time of day, season, etc.

[0031] In one embodiment, the user communications device 104 is configured to push data representative of the user (e.g. merchant identity, location, food preparation times or required pick-up times, customer details, and so on) regularly to the communications server apparatus 102 over communications network 108. In another, the communications server apparatus 102 polls the service provider communications device 104 for information. In either case, the data from the user communications device 104 (also referred to herein as ‘service requests’) are communicated to the communications server apparatus 102 and at least some parameters or characteristics thereof stored in relevant locations in the database 126 as historical data, such that demand distribution data can be generated and used to predict likely demand for a particular region, depending on characteristics such as day of the week, time of day, season, etc. As described above, in known shared economy services, such as food delivery services, for example, the nearest available or ‘idle’ resource, e.g. driver, tends to be allocated to a service request, irrespective of any other parameters or characteristics associated with that service request. As a result, there can be a significant under-utilisation of resources. For example, in a known food delivery service of this type, drivers often have to wait at the food merchant premises whilst the food preparation is still underway, and represents further ‘idle’ time which is a waste of the available resources, that could otherwise be utilised to fulfil other service requests. Moreover, the early arrival of drivers results in unnecessary occupation of the merchant's waiting/parking areas to the extent that some merchants may even have to temporarily halt their delivery service availability during peak periods, in order to manage the number of drivers waiting at their premises. Even in solutions that allow the allocation of in-use resources, e.g. in-transit drivers, to further service requests and then only apply (e.g. dispatch) them to the further service requests just in time to commence their fulfilment, i.e., in this example, pick up the orders, those resources remain allocated to those service requests for the intervening period of time between completing the last service request and starting the next one, i.e. they remain unavailable for allocation to other service requests for that period of time, which again represents a waste of (otherwise) available resources, and does not increase the number of service requests that can be fulfilled by the available supply pool at any one time. This is especially wasteful where the lead time is relatively long. In some shared economy type services, the above-mentioned intervening time can be highly variable between service requests, and therefore has a highly variable effect on resource under utilisation. Another drawback of this approach, especially in the food delivery service example described, is a high risk of late delivery if, after delaying the dispatch of the driver to pick up the order, they then decide to reject the job. In other words, no account is taken of historical resource behaviour or reliability during resource allocation in respect of a specified service request, which may be particularly pertinent in a shared economy type service.

[0032] Implementations of the techniques disclosed herein seek to address at least some of these issues by utilising a logic processing method that enables resource allocation to be performed which additionally takes account of a highly variable parameter, such as a ‘lead time’, associated with each service request. In a food delivery service, this lead time might comprise the food preparation time or, more accurately, the remaining period of time between the time at which a service request is received and the pick-up time provided by the merchant in the service request. More generally, the ‘lead time’ can be defined as the time between receipt by the communications server apparatus 102 of a service request from the service provider communications device 106 and the time (provided in the service request) at which the resource is required to be available to commence fulfilment of the service request. This lead time can be largely unpredictable prior to receipt of a respective service request and it can be highly variable between service requests, even those from the same service request originator. However, and irrespective of the nature of the shared economy service, the larger this lead time is, the greater its potential adverse effect on the effective utilisation of available resources.

[0033] Although the lead time could, in theory at least, be incorporated into each ‘cost’ calculation for each available resource in respect of each service request, the processing overhead and time that this would require makes it prohibitive in a system required to operate in (near) real-time, such as a food (or other type of on-demand) delivery service. Therefore, instead, the logic processing method referred to above acts to distinguish between ‘high’ and ‘low’ lead times, defined by whether a particular lead time is greater or less than a predefined threshold.

[0034] Referring to FIG. 2 of the drawings, in an implementation, the communications system is configured to operate in a shared economy food delivery service. The communications server apparatus 102 is configured to receive service request data in the form of food delivery orders, O, from the service provider (merchant) communications device 106 and resource (i.e. driver) data, D, from the service provider (driver) communications device 104. The food delivery order data and the driver data may be stored in the database 126. Each item of food delivery order data comprises (at least) data representative of the merchant (for example, identity, location, and so on), data representative of the customer (for example, name, address, etc.) and data representative of a time at which the order will be ready to be collected for delivery. Each item of driver data will include (at least) data representative of the identity of the driver, their location and current status (idle/in-transit). The database 126 may also store data representative of the time/date associated with each item of food delivery order data and each item of driver data to enable the above-referenced demand and supply distribution data to be generated. It will be appreciated that various elements of the communications server apparatus 102, the user communications device 104 and the service provider communications device 106 are omitted from FIG. 2 to aid clarity.

[0035] The communications server apparatus 102 comprises a comparator 202 that is configured to receive data representative of a (remaining) food preparation time t.sub.f based on the time given by the merchant (in the respective food delivery order data) for when the order will be ready for collection and extracted from the food delivery order data. This “lead time” t.sub.f is calculated by a microprocessor 116 as being the time period between the current time and the collection time provided by the merchant. The comparator 102 compares the value for t.sub.f with a predetermined threshold t.sub.threshold. The threshold t.sub.threshold can be defined, for example, using the median value of the time taken for a driver to reach a merchant location, and can be updated accordingly based on this statistical value. However, other methods of deriving a threshold time for this purpose will be apparent to a person skilled in the art, and the invention is not necessarily intended to be limited in this regard.

[0036] If t.sub.f is greater than t.sub.threshold, the comparator 202 outputs data indicating that t.sub.f is ‘high’. If t.sub.f is less than or equal to t.sub.threshold, the comparator outputs data indicating that t.sub.f is ‘low’. The ‘high’/‘low’ indicator data is provided to a cost calculation processor 203.

[0037] The value for t.sub.f is also applied to a first weight (13) calculator 204, which calculates a value for a first weight, β, wherein

[00001]$\beta =\frac{t_f}{t_{\mathrm{threshold}}}.$

The first weight, β, is used in the cost calculation processor 203 to try to avoid the late arrival of drivers to the merchants' premises, i.e. a period of time after the food has been prepared, because such late arrival will increase the overall customer waiting time and may also affect the quality of the food at the time of delivery, thereby adversely impacting the overall customer experience. If t.sub.f is high, β is high to avoid delay, whereas if t.sub.f is low, β is lower to ensure that a resource can still be allocated to an order even if there is no current available driver that can reach the merchant's premises before the food preparation time has elapsed.

[0038] Referring back to FIG. 2 of the drawings, the communications server apparatus 102 also comprises a routing engine 205, that is configured to receive (at least) merchant location data extracted from the food delivery order data received from the user communications device 104, and also driver data from the service provider communications device 106. The driver data will include, for each driver, (at least) current location, current status (idle or in-transit) and, if in transit, location of drop-off point for current order. Using this driver data, the routing engine 205 is configured to calculate, for each driver and at the point in time when a new food delivery order is received, an estimated first time value t.sub.2 which is the estimated travel time from current location (idle status) or drop-off point (in-transit status) to the merchant location. The routing engine 205 is also configured to calculate, for each in-transit driver, an estimated second time value t.sub.1 which is the estimated travel time from their current location to the drop-off point for the previous order. These estimated travel times t.sub.1, t.sub.2 can be estimated using any known techniques, such as those used in satellite navigation systems and the like.

[0039] The values t.sub.2 (and, where applicable, t.sub.1) for each driver are fed to the cost calculation processor 203. The values (t.sub.1 and) t.sub.2 for each driver are also fed to first and second time calculation processes 206, 207. In a first calculation process 206, a value t.sub.d can be calculated to represent an estimated food collection delay in the case where the driver will reach the merchant after the food has been prepared, wherein t.sub.d=max(0, t.sub.1+t.sub.2−t.sub.f).

[0040] In a second calculation process 207, a value t.sub.w can be calculated to represent an estimated driver waiting time in the case where the driver will reach the merchant before the food preparation has been completed, wherein t.sub.w=max(0,t.sub.f−t.sub.1−t.sub.2).

[0041] The values for t.sub.d and t.sub.w for each driver are fed to the cost calculation processor 203. A second weight, a, calculator 208 is configured to receive data representative of (t.sub.1 and) t.sub.2 and also t.sub.w and is configured to calculate a second weight α. When cancelling an order, a driver will state their reason for cancellation, and this data enables the second weight α to be calculated. The second weight α is used in the resource allocation method described hereinafter to control the importance of t.sub.2 over t.sub.w. One way to define a is by using the ratio between “driver cancellation rate due to long distance” (high t.sub.2) and “driver cancellation rate due to long waiting time at restaurant” (high t.sub.w) with the input data for this calculation coming from the above-referenced reasons for cancellation received from the drivers, and a can also be updated as required, based on this ratio value. The second weight α can be used in the resource allocation method described hereinafter to control the importance of waiting time during allocation. For example, in a shared economy food delivery service, a driver's historical cancellation and ignore behaviour can be utilised to determine whether they prefer long traveling times or long waiting times in merchants in a city, and the weights associated with those drivers can be set or adjusted accordingly. Furthermore, in some cities, merchants prefer drivers not to wait inside/surrounding their places, and the weight can be set and adjusted in relation to service requests from specific merchants to accommodate these requirements.

[0042] The cost calculation processor 203 is configured to calculate a cost value c.sub.ij for each order-driver pair and populate a cost matrix [C.sub.ij] accordingly. The cost matrix [C.sub.ij] is fed back to the microprocessor 116, which is configured to allocate orders to drivers based on the cost matrix data, as described in more detail below, and transmit dispatch data D.sub.allocate to the service provider communications device(s) 106 of driver(s) to provide them with the food delivery order data and enable them to proceed and service the delivery.

[0043] In order to aid clarity, FIG. 2 illustrates the comparator 202, the cost calculation processor 203, the routing engine 205 and the process modules 204, 206, 207 and 208 for calculating β, t.sub.w, t.sub.d and a respectively as physically separate modules. However, all of those processes or modules may be facilitated by a single processing component 116 or by multiple distributed processing components configured to facilitate the functional modules illustrated in FIG. 2 of the drawings, and the present invention is not necessarily intended to be limited in this regard.

[0044] Referring additionally to FIG. 3 of the drawings, a resource allocation method will now be described in more detail. As explained above, in an implementation, a cost calculation processor may be used to facilitate the resource allocation method. The cost calculation processor is configured, in respect of each order o, to receive the inputs t.sub.1, t.sub.2, t.sub.w and t.sub.d calculated for each available driver d. The cost calculation processor 203 is also configured to receive data representative of whether the food preparation time t.sub.f is deemed to be ‘high’ or ‘low’. The weight values α and β may be stored or received by the cost calculation processor 203, depending on whether they are re-calculated and updated for each order, or whether a fixed value is used for each unless and until it is updated (either periodically or when there is a change of conditions and, optionally, based on the historical demand and supply distributions stored in the database 126).

[0045] The cost calculation processor is configured to utilise allocation and prioritisation logic to allocate resources based on costs, taking into account the various variables and parameters discussed above. An implementation of the allocation and prioritisation logic is described in more detail below.

[0046] Allocation & Prioritisation Logic:

[0047] The problem of allocating orders to drivers (or vice versa) is formulated as a general assignment problem as follows, which may be solved by any known assignment algorithm such as, for example, the Kuhn-Munkres algorithm: [0048] Given an n×n cost matrix [c.sub.ij], to assign each row (order) to a different column (driver) in such a way that the sum of the selected costs is minimum, i.e.:

[00002]$\underset{x}{\min }\underset{j}{\overset{n}{.Math.}}\underset{i}{\overset{n}{.Math.}}{c}_{\mathrm{ij}}{x}_{\mathrm{ij}}$$s.t.\underset{j}{\overset{n}{.Math.}}{x}_{\mathrm{ij}}=1,\mathrm{for}i=1,.Math.,n,$$\underset{i}{\overset{n}{.Math.}}{x}_{\mathrm{ij}}=1,\mathrm{for}j=1,.Math.,n,$$x_{\mathrm{ij}}\in \left\{0,1\right\}.$$x_{\mathrm{ij}}=1,\mathrm{if}\mathrm{order}i\mathrm{is}\mathrm{allocated}\mathrm{to}\mathrm{driver}j$$=0,\mathrm{otherwise}$

[0049] If the number of orders o is not equal to the number of drivers d, we the cost matrix [c.sub.ij] can be extended to be a square matrix by adding large numbers into rows or columns.

[0050] The cost calculation for each order-driver pair is based on:

c.sub.ij=t.sub.2+αt.sub.w+βt.sub.d, if t.sub.f>t.sub.threshold

c.sub.ij=t.sub.1+t.sub.2+αt.sub.w, If t.sub.f<t.sub.threshold

[0051] The notations inside the formula are as follows: [0052] t.sub.2: estimated time spent from current driver location (idle driver)/previous order drop-off location (in-transit driver) to merchant location—estimated by routing engine 205, as described above [0053] t.sub.w: estimated driver waiting time at the merchant premises in the case that a subject driver would reach merchant earlier than the time of completion of the food preparation—calculated, as described above, based on the formula:

t.sub.w=max(0,t.sub.f−t.sub.1−t.sub.2) [0054] t.sub.d: estimated food collection delay in the case where a subject driver would reach the merchant premises after completion of food preparation—calculated based on formulae of t.sub.d=max(0, t.sub.1+t.sub.2−t.sub.f), as described above. [0055] t.sub.f: estimated (remaining) food preparation time—provided by merchant or estimated based on historical data and real-time signal, as described above. [0056] t.sub.1: estimated time spent from current driver location (in-transit driver) to previous order drop-off location—estimated by routing engine 205, as described above. [0057] t.sub.threshold: a predefined time to distinguish orders having shorter and longer food preparation times, as described above. [0058] α: the weightage of waiting time in merchant compared with pickup routing time (t.sub.1 and t.sub.2), as described above. [0059] β: the weightage of delay time (driver reaches merchant after food is prepared) compared to pickup routing time (t.sub.1 and t.sub.2), as described above.

[0060] It is worth noting that, whilst a high t.sub.2 will increase likelihood of a driver to ignoring/rejecting an order, high t.sub.1 will not, because the driver is already on the way to complete the previous order

[0061] Referring back to FIG. 3 of the drawings, for each of a plurality of pending food delivery orders received, and the various values and parameters described above, the cost calculation processor 203 calculates the cost c.sub.ij (at step 401) associated with each and every order-driver pair using the appropriate cost equation (according to whether the food preparation time for the subject order is deemed to be ‘high’ or ‘low’, and populates a database 126 configured in the form of the cost matrix defined above, as illustrated in FIG. 4 of the drawings.

[0062] For each order, once the cost calculation for a driver has been performed, a driver ID D.sub.n is incremented by 1 (at step 402) and the process moves to the next driver to perform a cost calculation in respect of the next order-driver pair. Once the cost calculations for all of the order-driver pairs have been performed (D.sub.n=D.sub.j at step 403), and the results stored in the database 126, each of the orders is allocated to the driver in respect of which the cost calculation is the lowest (step 404), and the resource allocation, thus completed, is output (at step 405). Dispatch communications are configured and output to the respective service provider communications devices, providing the respective drivers with details (D.sub.allocate) of the respective food delivery order allocated to them. By using a linear assignment process, the method described above can continue, and be expanded, for all new orders received and is adaptable to accommodate the supply (available driver) distribution as it changes over time. As new drivers become available, new respective columns are added to the cost matrix and as new orders are received, new respective rows are added to the cost matrix stored in the database 126. Equally, as drivers become unavailable, the respective columns ‘drop out’ of the cost matrix and, as orders are assigned and completed, the respective rows ‘drop out’ of the cost matrix. The process is eminently scalable, and can be used to accommodate any number of orders and any number of available drivers in any number of specified regions at any one time. By distinguishing between high and low food preparation times, account can be taken of this highly variable parameter within the cost calculations, without undue processing burden, thereby enabling the resource allocation process to be performed in (near) real time, as orders are received and as the available driver pool changes over time.

WORKED EXAMPLES

[0063] The following represent simplified worked examples, simply to illustrate the cost calculation and resource allocation principles described above. It will be appreciated that, in practice, there are likely to be a far larger number of pending orders and available drivers, and that these will be subject to constant change, as resources are allocated, new orders are received, orders are completed and drivers become available or not available.

Example 1

[0064] There is one food order: [0065] O1, in which t.sub.f=1200 secs [0066] There are three driver candidates: [0067] D1, in which t.sub.1=500 secs; t.sub.2=300 secs; t.sub.w=400 secs; t.sub.d=0 secs [0068] D2, in which t.sub.1=1000 secs; t.sub.2=500 secs; t.sub.w=0 secs; t.sub.d=300 secs [0069] D3, in which t.sub.1=0 secs; t.sub.2=100 secs; t.sub.w=1100 secs; t.sub.d=0 secs [0070] Assume:

[00003]$\alpha =0.4;\beta =\frac{t_f}{t_{\mathrm{threshold}}};t_{\mathrm{threshold}}=300\mathrm{secs}$ [0071] Cost calculation for each driver-order pair based on c.sub.ij=t.sub.2+αt.sub.w+βt.sub.d formulae as t.sub.f>t.sub.threshold:

[00004]$D1-O1:c_{11}=300+\left(0.4\right)\left(400\right)+\frac{1200}{300}\left(0\right)=460$$D2-O1:c_{21}=500+\left(0.4\right)\left(0\right)+\frac{1200}{300}\left(300\right)=1700$$D3-O1:c_{31}=100+\left(0.4\right)\left(1100\right)+\frac{1200}{300}\left(0\right)=540$ [0072] In this case, order O1 will be allocated to driver D1; as D1 has shorter waiting time than D3, and not causing any delay as for the case for D2.

Example 2

[0073] There is one food order: [0074] O2, in which t.sub.f=290 secs [0075] There are two driver candidates: [0076] D4, in which t.sub.1=200 secs; t.sub.2=100 secs; t.sub.w=0 secs; t.sub.d=10 secs [0077] D5, in which t.sub.1=0 secs; t.sub.2=100 secs; t.sub.w=190 secs; t.sub.d=0 secs [0078] Assume:

[00005]$\alpha =0.4;\beta =\frac{t_f}{t_{\mathrm{threshold}}};t_{\mathrm{threshold}}=300\mathrm{secs}$ [0079] Cost calculation for each driver-order pair based on c.sub.ij=t.sub.1+t.sub.2+αt.sub.w formulae as t.sub.f<=t.sub.threshold: [0080] D4-O2: c.sub.42=200+100+(0.4)(0)=300 [0081] D5-O2: c.sub.52=0+100+(0.4)(190)=176 [0082] As food preparation time is rather short in this case (t.sub.f<=t.sub.threshold), the logic will put more focus on finding nearest driver; which in this case driver D5.

[0083] It will be appreciated that the techniques described herein can be adapted for use in other shared economy services, including delivery of other (particularly time-sensitive) goods and documents. The described techniques can, potentially, be further adapted and extended for use in other resource allocation methods to reduced resource under-utilisation related to other shared economy services, wherein the service requests include at least one highly variable and largely unpredictable parameter that impacts significantly on the cost associated with each service request—available resource pair, to provide an efficient resource allocation solution that can be applied in substantially real time and is eminently saleable. Furthermore, because under-utilisation of resources can be reduced compared with known techniques by taking into account a key supply variable, the supply and demand distributions can be smoothed, thereby to avoid or at least mitigate issues associated with extreme discrepancies in supply-demand imbalance and potentially reducing both lag times (e.g. customer waiting times) and idle times (i.e. periods of time when an available resource is not being utilised or allocated to a service request) which are also technical effects applicable to, for example, electrical supply-load balancing or computer processing load balancing.

[0084] It will be appreciated that the invention has been described by way of example only. Various modifications may be made to the techniques described herein without departing from the spirit and scope of the appended claims. The disclosed techniques comprise techniques which may be provided in a stand-alone manner, or in combination with one another. Therefore, features described with respect to one technique may also be presented in combination with another technique.