Technical Field

The present invention relates to a quote prediction engine for a digital business-to- business marketplace for global ground transportation, and to a quote prediction method for same.

Background

The global business-to-business marketplace for ground-transport is characterised by large consumer brands on the demand-side (for example hotel chains and travel agents) with smaller independent, local vehicle fleets on the supply-side. The marketplace therefore represents a network that connects a large number of demand and supply points.

Each demand-partner (demand side entity) represents a source of demand requests that is much higher than each supply partner (supply side entity) can respond to (both technically and physically). Each supply-partner represents a small fleet operator with specific area of operation, product types and pricing rules, and supply product availability is of a dynamic nature with pricing, vehicle locations and driver status being aspects that change in real-time. The network supports hundreds of demand-partners and many thousands of supply partners. The combinatory effects of this network and the realtime change characteristics preclude static configuration to offer a high enough accuracy level.

To facilitate real-time product search and selection (by each demand side entity and, for each demand-side entity, of a plurality of supply side entities), a method to balance the scale of these participants is required that allows for accurate pricing based on time, distance, availability, capacity, locality and other product characteristics. Summary of the Invention

According to an aspect of the present invention, there is provided a method of providing a digital marketplace for ground transportation, comprising the steps of: receiving, from a demand side entity, a first quote request, the first quote request indicating at least location data and time data relating to a journey; obtaining, using a predictive model, a probable cost for the journey in relation to at least one supply side entity, each of the supply side entities corresponding to a fleet of ground transportation vehicles; providing, to the demand side entity, one or more quote messages based on the obtained probable cost for each of the supply side entities.

In this way, the present technique uses quote prediction to be able to provide a demand-side entity with a quote (per fleet) using a prediction model (preferably trained using machine learning based on historical and/or training data) without the need to send a real request to the respective dispatch management systems (DMS) managing each fleet. As a result, it is possible to generate quotes with low latency and at scale, rather than being limited by the request limits and quote delivery latencies associated with individual respective dispatch management systems (DMSs) for a large number of fleets. Accordingly, it is possible to handle asymmetry of demand and supply in high transaction volume, ground transport marketplaces.

The probable cost may for example be one of a cost value and a cost range, in either case representing the journey being quoted for. Specific cost values may be appropriate where a degree of confidence in the accuracy of the prediction is high, or if the demand-side entity requires a higher degree of cost certainty, while a cost range may be appropriate for a lower degree of confidence, or where a demand-side entity will accept a margin of error between predicted quotes and final prices. The model itself may output a cost per mile, which is then used in conjunction with pick up and drop off locations indicated in the request to compute a cost for the journey.

In other cases the model may output the complete cost for the journey. A demand-side entity seeking to make a booking will see a range of quotes between lowest and highest possible values for any fleet (supply side) in relation to which quote prediction is enabled.

Predicting a quote makes it possible to support demand partners with very high quote-to-book ratios without overloading DMS partners. The nature of the present platform means that for every individual request, numerous supply partners may easily be reached out to.

The system amplifies passenger behaviour, and for some demand partners in the “Mobility as a Service” space, this results in a large number of passengers and a high number of quotes relative to bookings. The use of quote predictions may allow the demand side of the marketplace to scale without crippling the supply side under the resulting load.

The method preferably further comprises the steps of: receiving, from the demand side entity, a first booking request in relation to one of the supply side entities to which the one or more quote messages relate; providing, to the supply side entity corresponding to the first booking request, a second quote request corresponding to the first quote request; receiving, from the supply side entity to which the second quote request was sent, a cost for the journey indicated by the second quote request; comparing the probable cost obtained using the predictive model with the cost received from the supply side entity in response to the second quote request; and in dependence on the result of the comparison, providing a second booking request to the supply side entity to which the second quote request was sent.

In this way, the demand side entity is able to make a booking based on a quote, and the system is able to only then contact the supply side entity to confirm that the predicted quote is accurate/acceptable (and if so to communicate a booking request to the supply side entity). As a result, quotes are only obtained from the supply side entity in the case of an actual intention to book (and in certain other cases, as outlined elsewhere), dramatically reducing the number of quote requests submitted to supply side entities and the number of quotes received from those supply side entities.

The second booking request (made to the supply side entity) may be provided to the supply side entity in the case that a predetermined condition relating to the comparison is met. The predetermined condition may be that the cost received from the supply side entity is within a range indicated by the probable cost. Alternatively, the predetermined condition may be that the probable cost is substantially equal to or less than a cost value received from the supply side entity. In the case that the predetermined condition is not met, the booking is not made, and no booking request is communicated to the supply side entity. Furthermore, if the predetermined condition is not met, a non-booking notification may be communicated to the demand side entity, upon receipt of which the demand-side entity may attempt a new booking based on a different quote.

The method may comprise the steps of: selectively transmitting, to one or more of the at least one supply side entity, a third quote request corresponding to the first quote request; receiving, from the one or more supply side entities to which the third quote request was transmitted, a cost for the journey indicated by the third quote request; and providing, to the demand side entity, one or more quote messages comprising the obtained cost for each of the one or more supply side entities to which the third quote request as transmitted.

In this way, a small proportion (for example 1%, 2%, 5% or 10%) of requested quotes may continue to be obtained from the supply side entities, enabling the predicted quotes (which are obtained in parallel) to be checked for accuracy, and if necessary the model retrained and refined to improve future accuracy. The collection of this data in real time makes it possible to assess the current market situation and improve accuracy of the model based thereon.

Where obtained, the third quote request may be transmitted instead of the probable cost for the journey from the predictive model for those one or more supply side entities. Alternatively, the third quote request may be transmitted as well as obtaining a probable cost for the journey using the predictive model for those one or more supply side entities, and wherein the probable cost using the predictive model is disregarded by the demand-side entity or the quote prediction engine for the purpose of providing a quote for the journey. In either case, the method may comprise updating the predictive model based on the location data and time data of the journey indicated by the third quote request, and the corresponding cost obtained from the one or more supply side entities.

The method may comprise: a step of determining, in relation to a first booking request, whether the corresponding quote messages are based on a probable cost obtained using the model, or a cost obtained from the supply side entity, and in the case that the quote message is based on the cost obtained from the supply side entity, providing, to the supply side entity, a second booking request without first providing the second quote request.

In this way, the booking process may be streamlined for booking requests made on the basis of actual quotes (provided by the supply-side entity).

The location data may comprise an indication of a pick-up location and drop-off location. The location data may also (or instead) comprise an indication of distance between pick-up and drop-off. The time data may comprise an indication of a day and time for the journey. The first quote request may comprise an indication of a vehicle type for the journey, and the predicted cost may be dependent on vehicle type. The first quote request may comprise an indication of one or more fleets of vehicles, and the predicted cost may be dependent on the indicated fleet.

The method may comprise obtaining, using the predictive model, a probable availability for the journey in relation to the at least one supply side entity, and wherein quote messages are provided to, and/or displayed at, the demand side entity in relation to a supply side entity only if the probable availability of the supply side entity for the journey satisfies a predetermined condition. The predetermined condition may be that the probable availability of the supply side entity for the journey exceeds a predetermined threshold.

In some embodiments, a real-time features store may be provided which stores up to date (real time or recent) information which can be used to improve the accuracy of prices and availability. In this case, the method may comprise modifying the obtained probable cost based on recent and/or real-time data stored in a data store and/or modifying the obtained probable availability based on recent and/or real-time data stored in a data store.

In some embodiments, a journey may be required to take place as soon as possible, rather than at a scheduled future time. In this case, the time data in the quote request comprises an indication that the journey is to be carried out as soon as possible. Then, the one or more quote messages comprise an indication of a probable time before pick-up for each supply side entity.

According to another aspect of the present invention, there is provided a computer program, which when executed on a computer, causes the computer to carry out a method according to the above. The computer program may be stored on a server or other data processing apparatus, or be provided on a computer readable storage medium.

According to another aspect of the present invention, there is provided a quote prediction engine for facilitating a digital marketplace for ground transportation, the quote prediction engine comprising: prediction logic for receiving, from a demand side entity, a first quote request, the first quote request indicating at least location data and time data relating to a journey; a predictive model, accessible by the control logic to provide a probable cost for the journey in relation to at least one supply side entity, each of the supply side entities corresponding to a fleet of ground transportation vehicles; and wherein the control logic is configured to provide, to the demand side entity, one or more quote messages based on the obtained probable cost for each of the supply side entities. The quote prediction engine may further comprise: booking logic, configured: to receive, from the demand side entity, a first booking request in relation to one of the supply side entities to which the one or more quote messages relate, to provide, to the supply side entity corresponding to the first booking request, a second quote request corresponding to the first quote request; to receive, from the supply side entity to which the second quote request was sent, a cost for the journey indicated by the second quote request; to compare the probable cost obtained using the predictive model with the cost received from the supply side entity in response to the second quote request; and in dependence on the result of the comparison, to provide a second booking request to the supply side entity to which the second quote request was sent.

According to yet another aspect, there is provided a method of providing a digital marketplace for ground transportation, comprising the steps of: receiving, from a demand side entity, a first availability request, the first availability request indicating at least location data and time data relating to a journey; obtaining, using a predictive model, a probable availability for the journey in relation to at least one supply side entity, each of the supply side entities corresponding to a fleet of ground transportation vehicles; providing, to the demand side entity, one or more availability messages based on the obtained probable cost for each of the supply side entities.

In this way, if cost is not an issue, or is pre-agreed, a prediction engine can be used simply to streamline the booking process by only making booking requests to supply-side entities for which it is predicted that availability is good/a vehicle is statistically likely to be available for the required journey. A corresponding apparatus (prediction engine) is also envisaged for this aspect. Brief Description of the Drawings

Embodiments of the present invention will now be described by way of example only with reference to the accompanying drawings where like parts are provided with corresponding reference numerals and in which:

Figure 1 schematically illustrates a quote delivery and booking system according to an embodiment of the invention;

Figure 2 is a schematic flow diagram describing an example quote prediction and delivery process according to an embodiment of the invention; and Figure 3 is a schematic flow diagram describing an example booking process according to an embodiment of the invention.

Detailed Description

Referring to Figure 1 , a quote delivery and booking system comprises a plurality of demand side entities 10, a quote prediction and booking entity 20, a plurality of dispatch management systems (DMSs) 30 and a plurality of supply partners (vehicle fleets) 40. While two demand side entities 10 are shown in Figure 1 (Demandl and Demand2), in practice many demand side entities 10 may seek to make bookings for journeys. Similarly, while two DMSs 30 are shown in Figure 1 (DMS1 and DMS2), in practice many DMSs 30 may be accessed for quotes and bookings. Similarly, while supply partners (fleets) 40 are shown in Figure 1 (Fleet 1 , Fleet 2 and Fleet 3), in practice many (often small) supply partners may provide journeys booked via the system. Each supply partner 40 is managed via a DMS 30, and one DMS 30 may manage one or a plurality of supply partners 40. Together, a supply partner 40 and its corresponding DMS 30 represent a supply-side entity. The DMS 30 tracks vehicle assets of the vehicle fleet, and manages quotes and bookings, including vehicle availability. Conventionally, a demand-side entity 10 requests the supply partner 40 (via the DMS 30) to provide a quote for a particular journey (from a start position to an end position, and at a particular date and time, and optionally for a particular vehicle type - such as number of seats, accessibility, and vehicle standard (premium or luxury), and subsequently may accept the quote by requesting a booking based on the quote. With the present technique, the quote prediction and booking entity 20 acts as an intelligent bridge between a large number of demand-side entities 10 and an even larger number of supply side entities 30, 40, and utilises quote prediction to address the scaling and responsiveness issues which arise as a result. With the present technique, each of the demand side entities 10 is independently able to make a quote request of the quote prediction and booking entity 20 for a particular journey by communicating a quote request message QR1 to the quote prediction and booking entity 20, to receive a quote response message Q3 from the quote prediction and booking entity 20 indicating costs and/or availability for a particular supply side entity or entities to carry out the journey (that is, a range of quotes relating to different supple side entities/fleets), and to subsequently make booking requests by communicating booking request messages BR1 to the quote prediction and booking entity 20 in relation to received quotes. A booking confirmation message or a non-booking error message Conf/Err may then be received at the demand-side entity 10 from the quote prediction and booking entity 20.

The quote prediction and booking entity 20 comprises a quote prediction engine 22 and a booking engine 26. These may be provided in a single device, or separate devices. The quote prediction engine 22 comprises quote logic 23 for receiving, actioning and replying to quote request messages QR1 from demand side entities 10, and a predictive model (or models) 24 for modelling the likely costs (and preferably availability) of (at least some of) the supply side entities 30, 40. The quote logic 23 and the predictive model 24 may be provided in the same device, or separate devices. It will be appreciated that a single model may be provided which models cost (and preferably availability) for a plurality of fleets (supply side entities), or alternatively plural models may be provided - one for each (or a group of) the fleets/supply side entities 30, 40. In some cases, a single model 24 may be considered to have multiple instances, for example once instance for each supply side entity. Further, a combined model or separate models may be provided to handle cost and availability.

Each demand side entity 10 communicates (via the Internet, in the form of a message) quote request messages QR1 to the quote prediction engine 22. Each quote request message QR1 includes information on at least a journey location (for example a pick-up location and a drop-off location) and a journey date and time, as well as optionally other information such as a vehicle type (for example number of seats, wheelchair accessibility or vehicle class). The quote logic 23 receives a quote request message QR1 from a particular demand-side entity and obtains one or more quotes (either predictively using the model 24, or from a DMS 30) in relation to particular fleets (supply side entities 30, 40). The obtained quotes are then (potentially after filtering) communicated to the demand-side entity in a quote response message Q3. Separate quote response messages Q3 may be provided for each DMS 30 or fleet 40, or a single quote response message Q3 may amalgamate quotes from a plurality of DMSs 30/fleets 40. In either case, quotes from (generally multiple) supply side entities 30, 40 are made available to the demand side entity 10 which originated the quote request.

To obtain the quotes, the quote logic 23 is able to identify appropriate supply-side partners 30, 40 in relation to which quotes are to be provided for example based on a coverage area or location for each supply side partner (which can be compared with the journey location to determine suitability based on proximity), based on an indication of fleet provided in the quote request message QR1 , and/or based on an internal list of approved fleets for the demand-side entity 10 issuing the quote request. For each supply-side entity 30, 40 in relation to which a quote is to be obtained, the quote logic 23 either obtains an actual quote from the relevant DMS 30, or obtains a predicted quote from the model 24, or in some cases obtain both.

In a case where an actual quote is to be obtained, the quote logic 23 communicates a specific quote request message QR2 to the relevant DMS 30 via the Internet, which responds with an actual quote response message Q1 , indicating the actual cost of fulfilling the journey. The actual quote comprises an indication of a cost for the journey, computed by the DMS 30 using the information obtained from the quote request message QR2 (which may be the same as, or based on, the quote request message QR1 ), and based on an internal pricing model specific to the fleet. If the DMS 30 determines that the supply partner does not have availability to carry out the journey, the DMS 30 may instead respond to the quote request message QR2 with a “not available” response message. In this case, no quote will be provided by the quote prediction and booking entity 20 (to the demand side entity 10) in relation to that supply side entity 30, 40.

In a case where a predicted quote is to be obtained in relation to a supply side entity, the booking logic 27 accesses the model 24 using information extracted from the quote request message QR1 (provided to the model 24 in the form of a quote request message QR3), and obtains at least a cost of the journey, and preferably a probable availability for the supply partner to carry out the journey, in the form of a predicted quote Q2. It will be appreciated that in the case where a quote request QR1 requires multiple quotes (in relation to different supply side entities 30, 40) to be obtained from the model 24, separate quote request messages QR3 may be used to interrogate the model 24, or alternatively a single quote request message QR3 may be used to obtain quotes in relation to the plural supply side entities 30, 40.

Similarly, a single predicted quote message Q2 may be provided including quotes for plural supply side entities, or separate quote messages Q2 may be issued from the model 24 in relation to each supply side entity 30, 40. Where probable availability is being modelled, the probable availability may be compared by the quote logic 23 with a threshold value, and the quote may only be passed on to the demand-side entity 10 if the probable availability exceeds the threshold value.

The quote logic 23 communicates a quote response message Q3 to the demand- side entity 10, based on the actual quote message Q1 and/or predicted quote message Q2. A single quote response message Q3 may be communicated which includes information on all quotes (in relation to all relevant supply partners), or separate quote messages Q3 may be provided for each. The quote message Q3 bears cost information which is based on either the quote response message Q1 (in the case of an actual quote) or the cost information obtained from the model 24. It will be appreciated that the cost information provided in the quote response message Q3 (to the demand-side entity 10) may not be the same as the cost information in the messages Q1 or Q2, since a mark-up, discount or other modification may be applied to those costs before providing them to the demand-side entity 10. It will be understood that the quote response message Q3 may aggregate cost (and availability, and other information) for a plurality of supply-side entities, providing a range of quotes and fleets for the demand-side entity to select from. A predicted quote may comprise a predicted value (cost) along with a prediction confidence for cost (this may be a confidence level for the fleet, or for the area in which the journey takes place, or for a more specific characteristic or characteristics of the quote), a predicted availability along with a prediction confidence for availability (again, for the fleet, area or other quote characteristics), and quote information such a journey origin, journey destination, fleet and demand partner.

Quote prediction can be enabled on a per fleet, per city basis. In other words, quote prediction may only be available for some fleets, and not others, and for some cities/geographical regions and not others. This may for example be because certain fleets are unable or unwilling to accept predictive quoting, or because there is inadequate data at present to train the predictive model 24 reliably in relation to that fleet or geographical area.

The main purpose of the quote prediction engine 22 is to efficiently match, in real time, the demand requirements (of the demand-side entities making requests for a desired journey) to the available product supply (the supply-side entities capable of fulfilling the required journey) in this high transaction volume and asymmetric market. Accordingly, instead of calling the DMSs 30 for every quote request, the quote prediction engine 22 predicts the quote for each fleet and vehicle class of that request (for which quote prediction is enabled) and presents the predicted quote(s) to users (the demand side entity 10). This prediction service takes into consideration the latest pricing of the fleet and their availability to take that trip, both reflected in the model 24 (or in separate models, for each DMS 30 and/or fleet 40). The quote prices may therefore be predicted with high accuracy while minimizing the booking failure rate due to the fleet non-availability. The quote prediction engine 22 permits a fast response to a quote request (because it is faster to access information from the model 24 than to obtain quotes from multiple DMSs) and provides the ability to scale based on demand.

It will be appreciated that it is much faster to obtain predicted cost and/or availability information from the model 24, than from (multiple) external entities (the DMS/fleet). A response rate from the model 24 of less than 0.1s per request is viable, which is orders of magnitude faster than obtaining actual quote information from DMSs 30. The use of predicted costs via the model 24 also provides the ability to scale with the increase of demand, since obtaining multiple instances of cost and availability (for example in relation to the same journey but provided by different fleets) is much faster than obtaining cost and availability from separate fleets (in part because in this case delivery of cost and availability information has a bottleneck of the slowest DMS).

The quote request message QR1 identifies the demand-side entity making the request. It may also include other information relevant to obtaining a suitable quote for a journey. The identification of the demand-side entity, the target city/cities to which the quote request relates, and target fleet/fleets (supply side entities) may be used in prediction (as well as filtering data to form the model) to route the request to the correct model(s) based on the request organization/city/fleet.

A machine learning algorithm is used to form the model 24 (or models) to predict both quote values (costs) and vehicle availability. The model(s) 24 may be trained initially using actual quote information, or other pricing information (training or test data) received from, published by, or observed in relation to, the supply side entities 30, 40. This training may take place offline (without the quote prediction engine 22 being operated “live” and providing predictions to demand-side entities 10).

However, once the quote prediction engine 22 is live and providing predicted quotes to demand-side entities 10, actual quotes may be sampled (for example 1%, 2%, 5% or 10%) of the quote request messages QR1 may result in quote request messages QR2 being communicated to the DMSs, and used to further train and refine the model 24. In particular, actual cost values, prediction error and availability are actively monitored (with respect to predicted cost values and availability) in this way to detect any drift (change over time) in the pricing or the availability of the fleets for retraining. It is expected that such an algorithm will be able to predict availability with 5% error which would reduce the failure of booking, and able to predict the quote (cost) with less than 10% percent error. Where precise cost values cannot be predicted, the system may instead deliver a predicted cost range. In some cases (for example for certain fleets or geographical areas), the model 24 may have a less than acceptable level of accuracy. It is possible to measure the likely accuracy of the model in relation to a particular fleet or geographical area (for example) by comparing, for that fleet or area (or other feature), actual cost values with corresponding predicted cost values. In this way, confidence levels can be provided (obtained from the model 24) along with the cost value. The logic 22 may decide to disregard (not pass on to the demand-side entity) a quote if the confidence level for that quote falls below a predetermined threshold. In this case, an actual quote may need to be obtained instead (which can be used both to deliver a quote, and to further train the model 24).

The predicted availability obtained from the model 24 (in parallel with cost) is used to control whether a predicted quote is to be provided to a demand-side partner (displayed). If the availability model predicts that a supply side entity has availability to service the quoted journey, then the quote can be provided to the demand-side partner, whereas if the availability model predicts that the supply side entity will not have availability (or is unlikely to have availability) to service the quoted journey, then the quote may not be provided to the demand-side partner. As with the cost model, the predicted availability may be accompanied by a confidence level for the prediction (based on how accurate the model is for past data or training data having similar parameters). If the confidence level for availability is lower than a predetermined threshold (which may be the same or different to the predetermined threshold used for cost value confidence), the quote may not be passed on to the demand-side entity. In this case, the quote logic 23 may request availability information from the relevant DMS 30 (or request an actual quote from the DMS 30).

It will be appreciated that availability predictions may in some cases be incorrect, and not reflect actual availability. It is highly desirable to reduce both false positives (the supply side entity 40 is predicted to be available, but is in fact not available) and false negatives (the supply side entity 40 is predicted not to be available, but is in fact available). False positives will give rise to failed bookings, resulting in inconvenience to the demand-side entity, whereas false negatives will cause missed opportunities for supply-side fleets and reduce choice for the demand-side. The use of a machine-learning based availability model is believed to be capable of delivering false positives and false negatives at low levels. The model 24 relates cost (preferably per unit distance) to a combination of parameters, including fleet (identifier of supply-side entity 40), location, day/time, vehicle class and capacity (for example). The cost model may comprise the following features:

Metadata: Fleet ID, Vehicle Type

Temporal Information: Hour, Minute, Day of week, Day of Month, Month, Peak time

Spatial Information: Pick-up latitude, Pick-up longitude, Drop-off latitude, Drop-off longitude, Distance between pick-up and Drop-off, Distance between pick-up and closest coverage area, Distance between Drop-off and closest coverage area, Distance between pick-up and Drop-off coverage area, Distance between Drop-off and pick-up coverage area, City name

The model will produce an output (cost per mile or km, or other unit distance, or alternatively absolute cost for the journey) based on any given input data populating the above feature parameters. It will be appreciated that a simpler model may use fewer parameters, and a more complex model may utilise the above and additional parameters.

A quote request message may contain some or all of the following information: Fleet ID, Hour, Minute, Day of week, Day of Month, Month, Pick-up latitude, Pick-up longitude, Drop-off latitude, Drop-off longitude. This information (or a subset of the information) is input to the corresponding feature inputs of the model. The quote logic 23 (or the model 24) contains pre-stored information relating to coverage areas for each fleet (id), and cities/regions serviced by particular fleets. Accordingly, when the quote logic 23 accesses the model for a particular quote request, it determines which supply side entities 40 to run a query for (for example based on the fleet ID(s) if specified in the quote request, or based on a preferred supplier list corresponding to the demand side entity 10 and/or based on which supply side entities 40 cover the location(s) indicated by the Pickup and Drop-off latitudes and longitudes provided in the quote request), and then runs a query for each of those supply side entities, by inputting the information from the quote request (for example hour, minute, day of week, day of month, month, pickup and Drop-off latitudes and longitudes), and deriving the remaining information (for example peak time, distance between pick-up and Drop-off, distance between pick-up and closest coverage area, distance between Drop-off and closest coverage area, distance between pick-up and Drop-off coverage area, distance between Drop-off and pick-up coverage area, and city name), for example by computing distances between the pick-up and Drop-off locations indicated in the quote request and the coverage areas associated with the supply side entity in relation to which the query is being run. The model will then output a corresponding cost value (or range), as well as optionally a confidence level based on discrepancies between predicted and actual values of test data (or previous live data).

Explaining further, it will be appreciated that the cost of a journey (for a given fleet) may vary as a function of day and time of day (for example peak hours, antisocial hours, and weekdays, weekends or bank holiday). This date/time dependent variation is reflected in the model, and so an output of the model (for example cost per unit distance) depends on the time and date related information (hour, minute, day of week, day of month) input to the model from the quote request. It will be appreciated that in some embodiments conversion may take place (carried out by the quote logic 23) between the time related information in the quote request and the input to the model, for example converting a specific hour and minute time to a time band such as “morning rush hour”, “daytime”, “afternoon rush hour”, “evening” and “night-time”, with the time bands being used to model cost per unit distance. In other embodiments, the time and date related values of the quote request are instead used as raw inputs into the model.

Similarly, the cost of a journey (for a given fleet) may vary as a function of location (city, or a wider or narrower geographical area). This location dependent variation is reflected in the model, and so an output of the model (for example cost per unit distance) depends on the location information input to the model from the quote request. Again, some form of conversion may take place, for example to convert specific latitudes and longitudes to geographical areas such as cities, districts and so on, with these being used to model cost per unit distance. In other cases, the location related values of the quote request are entered raw into the model. Where the model 24 outputs a cost per mile, the quote logic 23 may convert this to an actual cost for the journey using the pick-up and Drop-off locations combined with (for example) route finding software. It will be appreciated that, in other cases, the actual cost may also be influenced by distances between pick-up and Drop-off areas and coverage areas of the fleets.

Similar considerations apply for the availability model, which relates the following features:

Metadata: Fleet ID, Vehicle Type

Temporal Information: Hour, Minute, Day of week, Day of Month, Month, Peak time

Spatial Information: Pick-up latitude, Pick-up longitude, Drop-off latitude, Drop-off longitude, Distance between pick-up and Drop-off, Pick-up coverage area index, Drop-off coverage area index, City name

The model 24 will produce an output (Likelihood of availability) based on any given input data populating the above feature parameters. It will be appreciated that a simpler model may use fewer parameters, and a more complex model may utilise the above and additional parameters.

A quote request may contain the following information: Fleet ID, Hour, Minute, Day of week, Day of Month, Month, Pick-up latitude, Pick-up longitude, Drop-off latitude, Drop-off longitude. This information is input to the corresponding feature inputs of the model. As mentioned above in relation to the cost model, the quote logic 23 (or the model 24) contains pre-stored information relating to coverage areas for each fleet (id), and cities/regions serviced by particular fleets. Accordingly, when the quote logic 23 runs a query for each of the supply side entities 40 (selected as above - since both the cost and availability models are queried in relation to the same supply side entities 40), by inputting the information from the quote request, and deriving the remaining information, for example by obtaining the pick-up and Drop-off coverage areas associated with the supply side entity 40 in relation to which the query is being run. The model will then output a corresponding likely availability, as well as optionally a confidence level based on discrepancies between predicted and actual values of test data (or previous live data). The availability could be represented as either a binary (available or not available), or as a continuum or set of discrete values (e.g. 0%, 25%, 50%, 75%, 100%) representing the likelihood of the fleet having availability to service that journey.

It will be appreciated that the more detailed discussions of using inputs from a quote request to the cost model are equally applicable to the availability model.

As would be understood by the person skilled in the art, it is possible for a model using machine learning to take test (or live) data comprising an output parameter (in this case cost (per unit distance)) and input parameters (in this case location, day/time, vehicle class and capacity information for example), and to vary weights and biases applied to each input parameter to minimise (across the data set) errors between actual and predicted output values (cost per unit distance). Once the model has been trained to maximise accuracy for the test data used in its training, similar levels of accuracy can be expected to be achieved based on new data of the same type and origin. The same principles apply to the modelling of vehicle availability, instead of cost, with substantially the same parameters being utilised in both training the model, and deriving predictions from the model. Referring back to the above discussion of the makeup of the models for cost and availability, when training the model the training inputs include (a) inputs which correspond to the information contained in quote request messages, (b) inputs which are derived from the information in quote request messages coupled with information on the fleet/supply side entity, and (c) the actual cost value (per mile, km or other unit distance, or for the journey) associated with the journey and/or the actual availability of the fleet to service the journey.

The quote prediction engine 22 also comprises a real-time features store 25. This stores recent and/or real-time information pertinent to quote prediction, to account for factors for which the model 24 has not been trained (either because the model has not recently been refined, or because the changes are one-off or temporary). The specific features indexed by the real-time features store 25 depend on the specifics of the model 24, and can be used either as an input to the model or as compensation to the model predicted value (or both). Most features in the real-time features store 25 are derived from the DMS quote responses (based on real user requests or simulated) but can also index information obtained from other sources such as: public holidays, mass events, strikes, weather information, etc. In some examples the real-time features store 25 stores information regarding recent marketplace activity such as recent availability per fleet in a specific area, recent price changes per fleet, recent quotes grouped by area and direction of travel, representative quote results, recent cancellation rates, etc. These features may be stored in a time-series, allowing the detection of changes in Fleet behaviour in response to real-time events and at the same time making it possible to adjust the predictive models incrementally thus avoiding (or reducing the need for) full model retraining.

Accordingly, the real-time features store 25 may be considered to have two main purposes. The first purpose is to enable the quote logic 23 to correct predicted quotes obtained from the model in the case where information in the real-time features store indicates or suggests that the quote is likely to be inaccurate. In this case, the quote logic 23 is configured, when obtaining a quote from the model 24, to check if the real-time features store 25 contains information pertinent to the obtained quote. If so, the quote logic 23 is configured to modify the quote having regard to the pertinent information in the real-time features store 25. For example, if the real-time features store contains information, regarding the fleet to which the quote relates, indicating that the prices for that fleet have recently increased by X%, an X% uplift (for example) may be applied to the pricing information in the obtained quote. Similarly, if the real-time features store contains information, regarding the fleet to which the quote relates, indicating that their availability has recently worsened (either across the board, or for the date/time profile of the obtained quote) or improved, the availability information obtained from the model may be revised accordingly (thus influencing the likelihood of a quote from that fleet being provided to or displayed at the demand side entity. The second purpose of the real-time features store 25 is to accumulate information which can be used by the quote logic 23 to monitor the reliability of the model, decommission the model if it becomes too unreliable, trigger updates to the model (either incremental or bulk), and provide inputs to the updating of the model. For example, obtained quotes can be compared with recent quotes (stored in the real-time features store), and if there are significant differences (for example the quotes in the real-time features store are consistently higher) then this may trigger the quote logic 23 to decommission the model (for the relevant fleet) and/or update the model using the recent quotes. The real-time features store 25 may exist as a separate component (to the model 24) or be tightly coupled with the specific model 24. The combination of the model 24 and the real-time features store 25 allow the quote prediction engine 22 to deliver predicted quotes with improved accuracy and respond quickly to changes on the supply side of the marketplace.

In some cases, rather than a time and date for a desired journey being scheduled (pre-booked) sometime in the future, the journey may be booked for “as soon as possible”. In this case, the quote request may indicate either a current time and date, or simply an indication that the journey is to be undertaken as soon as possible. In this case, the cost and availability information obtained from the model 24 will be based on the current time and date (or shortly in the future). The main difference with ASAP bookings is a requirement for additional predictive capability to determine the “time of arrival” at the pick-up location for the journey. Unlike pre-book services, a key deciding factor on whether to book an ASAP service is how quickly the service can be delivered. Within the Pre-Book domain, services are scheduled and drivers allocated to ensure pick-up times are secured. For ASAP, arrival time is based on the real-time availability of drivers and vehicles within a radius of the customers pick-up location. In order to determine a probable time of arrival, the quote prediction engine may determine a distance between the pick up location and a vehicle location, coverage area or fleet HQ for the fleet (the latter to may be known in advance for each fleet (id), and calculate a probable time to reach the pick-up location, with the time of arrival at the pick-up location being based on that. The time of arrival (or wait time) may be delivered in the quotes provided to the demand side entity 10 by the quote prediction engine 22.

Each demand-side entity 10 is connected to the booking entity (system) 20 through a standard demand-api providing access to location, product search and booking services. Similarly, each supply-side entity (DMS part 30) is connected through a supply-api providing access to product pricing, availability and booking services. It will be appreciated that different participants may demand and supply products of different characteristics, including location, vehicle type and class, capacity and availability.

Preferably, each quote request is first routed only to a set of high-probability supply partners. For each combination of demand-supply request the system checks for the availability of a suitable insulating model (that is, a model (or instance of a model) of cost and/or availability for the relevant supply side entity). Each insulating model provides a statistically generated product-search function that covers vehicle availability and pricing that is further refined by characteristics such as vehicle type, time of day, service quality, for example. For every supply point with an available insulating model, the quote request is diverted to the model whilst also, on an infrequent basis, being forwarded directly to the supply point (DMS 30) for monitoring purposes. The objective of the main flow, when an insulating model is available, is to return product search requests directly back to the demand point without causing traffic at the supply point (DMS). Infrequent monitoring traffic (occasional quote requests made to the DMS) tests to ensure that the insulating model remains in tolerance (reliable/accurate). If the test fails, the model may be marked as invalid and the system disabled and repaired.

The booking engine 26 comprises booking logic 27 which receives booking requests from the demand-side entities 10, coordinates with DMSs 30 to make the bookings, and returns booking confirmations and/or error/not-bookable messages to the demand-side entity 10. In use, the booking engine 26 receives from the demand side entity 10 a booking request message BR1 which is based on one of the (actual or predicted) quotes contained within message(s) Q3 provided by the quote prediction engine 22. In some cases (for example if the quote upon which the booking request BR1 was made was an actual quote, or if the supply side entity is willing to accept bookings based on a predicted quote) the booking logic 27 is responsive to the booking request BR1 to make the booking via the appropriate DMS 30, by issuing booking request message BR2 (which includes details obtained from BR1 ). In other cases, the booking engine 26 is required to first transmit a quote request QR4 to the relevant DMS 30, and to check that an actual quote Q3 (responsive to the quote request QR4) substantially matches the predicted quote Q2 provided by the model 24. In the case of a match, the booking logic 27 makes the booking with the DMS using a booking request message BR2 and communicates a confirmation message Conf to the demand-side entity 10. In the case of a non match, the booking logic 27 communicates an error/non-booking message to the demand-side entity 10, requiring the demand-side entity 10 to make a new booking request in relation to a different quote.

Optionally, the booking logic 27 may be configured to communicate the quote Q3 to the quote prediction engine 22 in order that the model 24 be refined based thereon - particularly if the quote Q3 differs from the corresponding predicted quote Q2. Alternatively, the booking logic 27 may itself have direct access to the model 24, and be able to input information from the quote Q3 in order to update the model 24.

Within Figure 1, it will be appreciated that, for clarity, DMS1 and corresponding Fleet 1 are shown twice, once at the top in communication with the quote prediction engine 22, and once at the bottom in communication with the booking engine 26.

Referring to Figure 2, a flow diagram illustrates the steps involved in quote prediction and delivery. These are the steps carried out, in one embodiment, by the quote prediction engine 22. At a step S1 , a quote request is received from the demand side entity 10. It is then determined at a step S2 whether quote prediction is enabled for the demand side entity and/or journey and/or supply side entity (or entities) corresponding to the quote request. If quote prediction is not enabled for the demand side entity, or for the journey, quote prediction will not be carried out in relation to the quote request, and at a step S3 a quote for the journey (at the time and location, and optionally in relation to a particular vehicle type) is obtained (directly) from each of the supply side entities, in this case by a DMS associated with one or more of those entities. The actual quote is then delivered to the demand side entity at a step S4, after which the process ends at the step S5 (following which the booking process, detailed separately with respect to Figure 3, may begin). It will be appreciated that, for a given quote request, certain supply side entities corresponding to the quote may have prediction enabled, while others may not. In this case (and assuming that the quote prediction is enabled for the demand side entity and the journey), quote prediction will be carried out only in relation to supply side entities for which quote prediction is enabled. In this case, for each of the supply side entities for which quote prediction is not enabled, quotes are obtained directly from their respective DMSs as per the steps S3 to S5 described above. In relation to quotes obtained from a DMS, the predictive model may be refined at a step S6 (at least in relation to quotes obtained in relation to supply-side entities for which quote prediction is enabled, or planned to be enabled).

In practice, quote prediction may be enabled for a number of different fleets in various countries and regions. Other fleets may not be eligible for quote prediction, for example where these have not met a certain confidence threshold in the latest data models. Similarly, other fleets which have not (yet) been (adequately) trained may therefore not have quote prediction enabled.

In the case where quote prediction is determined to be enabled (or enabled for certain supply side entities), then at a step S7 a predicted quote is obtained from the predictive model 24 (at the time and location, and optionally in relation to a particular vehicle type) for the journey indicated in the quote request. At a step S8, it is determined whether the predicted quote is reliable, based for example on the confidence level for the model discussed above, and/or information present in the real-time features store 25. If the predicted quote is determined not to be reliable, it is disregarded and not delivered to the demand side entity. In this case, it is determined whether quote request can be made in order to improve the reliability of the model (to improve the likelihood of the model being reliable for future predictions). In order not to overwhelm the respective DMS 30, a rate limit is applied to limit the number of requests made in this way. In particular, at a step S9 it is determined whether a rate limit for the supply side entity DMS 30 has already been reached (for example for a current time period). If so, the process ends at the step S5 without any quote being delivered. If the rate limit has not yet been reached, the process returns to the step S3, where a quote is obtained from the DMS 30, and used to update the model 24 at the step S6. The quote obtained in this way may also be delivered to the demand-side entity at the step S4.

If, at the step S8, the predicted quote is determined to be reliable, the predicted quote is delivered at the step S4. In the case of the real-time features store 25 being provided, and containing information which can be used to improve the accuracy of the predicted quote, the predicted quote may be modified using the information in the real-time features store 25 before being delivered a the step S4.

In parallel, in order to continually refine the model, and deal automatically with any changes in pricing or availability with the supply-side entities, a quote request may be made to the DMS 30 of the supply-side entity. However, in order not to overwhelm the respective DMS 30, a rate limit is applied to limit the number of requests made in this way, similarly to the rate limit applied at the step S9. The same rate limit could be applied to both (and consumed by both types of quote request made to the DMS 30), or alternatively separate rate limits could be applied to, and consumed by, each type of quote request. In particular, at a step S10 it is determined whether a rate limit for the supply side entity DMS 30 has already been reached. If so, the process ends at the step S5 without any quote being delivered. If the rate limit has not yet been reached, the process returns to the step S3, where a quote is obtained from the DMS 30, and used to update the model 24 at the step S6. The quote obtained in this way may also be delivered to the demand-side entity at the step S4. In this case both predicted and actual quotes will have been prepared for the journey (with the predicted quote generally being delivered first due to speed of processing), and the actual quote will then take precedence, with the predicted quote being disregarded by the demand side entity 10 (or not being sent in the quote message Q3 if the quote logic waits before supplying it to the demand side entity 10).

Preferably, quotes are only delivered in the case that the corresponding supply-side entity has availability of the journey. In the case of an actual quote, the DMS 30 may return an “unavailable” quote if it determines that the supply-side entity is unable to service the requested journey. In this case, the step S4 of Figure 2 will not deliver a quote in relation to that supply-side entity. In the case of a predicted quote, the model (or a separate model handling availably) is preferably capable of modelling not only the cost, but also the probable availability of the respective supply-side entity for the journey. In this case, at the step S4 a decision will be made, based on modelled availability for the supply-side entity, of whether to deliver the predicted quote to the demand side availability. In particular, if the probable availability (for example as a likelihood value) is below a predetermined threshold value, then the predicted quote will not be delivered/displayed (at the step S4), whereas if the probable availability is at or above the threshold value, then the predicted quote will be delivered/displayed (at the step S4).

Once the predicted and/or actual quotes (note that the quotes delivered may include a combination of actual and predicted quotes, or may comprise only actual quotes, or only predicted quotes) has been received at the demand-side entity 10, the demand-side entity 10 is able to make a booking based on their preferred quote.

The booking process is explained using the flow diagram of Figure 3. These are the steps carried out by the booking engine 26. At a step S11 , a booking request is received from the demand-side entity 10. At a step S12 it is determined whether the booking request is in relation to an actual quote or a predicted quote. If the booking request is in relation to an actual quote, then at a step S13 the booking is made via the appropriate DMS 30, whereupon the booking process ends at a step S14. If at the step S12 the booking request is determined to have been made in relation to a predicted quote, then at a step S15 it is determined whether an actual (DMS sourced) quote is required by the supply-side entity 40 corresponding to the booking, in order to make the booking. If an actual quote is not required then the booking is made at the step S13. If an actual quote is required then at a step S16 an actual quote is obtained from the relevant DMS 30. Then, at a step S17 the actual quote is compared with the predicted quote. In the case of a match (discussed above) then the booking is made at the step S13. In the case a no-match then an error/non booking code is returned at the step S18, requiring a different booking to be made. As discussed above, the actual quote may also be used to train the model to improve its accuracy for future predictions.

From the above, it will be understood that a quote prediction engine for a digital business-to-business marketplace for global ground transportation can be provided. The engine is able to provide a dynamic method for handling demand and supply asymmetry to reduce transaction volumes on supply-points without compromising supply content (price and availability) so that (relatively small) local suppliers can participate with high-volume demand partners. This is achieved, in part, by the preparation and validity monitoring of an insulating model to use as the source of availability and pricing for a supply-point, and in part by providing dynamic routing to use a combination of models and real supply-point activity to provide demand partners with consistent high quality supply content.

Even if quote predictions are enabled and the accuracy is adequate, it is still beneficial to make some requests to the DMSs 30, and to use the resulting quotes to refine the model and keep it up to date. This makes it possible to check the quality of the predicted quotes. In this case, if a DMS-sourced quote is received it will override the predicted one. The DMS will therefore be called if the predicted quote cannot be trusted (prediction confidence too low), and in any case for a small proportion of quotes, to confirm accuracy and keep the model current/better trained.

While the use of predicted quotes and availability have significant advantages, as discussed above, there are some risks, such as that the delivered quote indicates availability for booking for the journey whereas the subsequent booking fails due to a lack of (actual) availability, and/or that the predicted quote obtained from the DMS is higher/lower than the predicted quote. Where one or both of these occur, it is desirable that this be flagged with an alert so that retraining of the model can be carried out. In some cases, when such an alert is raised, quote prediction may be disabled for the supply side entity (fleet).

It will be understood that model refinement, using actual quotes obtained during the course of live operation of the model, may be carried out in substantially the same way as the initial training of the model, but using the new quote data from the DMSs in addition to the existing data used to train the model initially. In some cases, “old” data may be discarded in favour of newly collected data, with the model eventually being based only on data collected during the course of the model’s operation (with the original data all having been discarded in favour of newer data. This enables the model to account for slow trends, such as yearly (for example) price changes and increases or decreases in fleet capacity over time. As discussed above, model refinement may be carried out on the basis of information stored in the real-time features store 25.

It will be appreciated that the present technique has been described in relation to ground-based passenger transportation. However, with some modification the technique could also be applied to ground-based freight transportation, or to air or sea based passenger or freight transportation.