Server and method for determining driver fare for on-demand service

Abstract

Aspects concern a server for facilitating determining a driver fare for an on-demand service, the server comprising: a memory configured to store instructions; a communication interface configured to receive an order for the on-demand service from a computing device; and a processor for executing the stored instructions and configured to: parse information about the order; query one or more first features relating to a real-time supply condition in relation to the order based on the information about the order; input the first features into a deep neural network model; predict an acceptance probability that a delivery service provider will accept the order at a current driver fare, using the deep neural network model that the first features are input; and determine a new driver fare based on the predicted acceptance probability.

Description

SERVER AND METHOD FOR DETERMINING DRIVER FARE FOR ON-DEMANDSERVICETECHNICAL FIELD

[0001] Various embodiments relate to a server and a method for determining a driver fare for an on-demand service.BACKGROUND

[0002] Due to development of information technology, a user (who in some contexts herein may also be referred to as a “requester”, a “consumer” or a “customer”) may request an on- demand service using a computing device. The on-demand service may allow the user to fulfil the user’s demand via an immediate access to goods and / or sendees. The user may request the on-demand service, for example, a delivery service or a transport service (also referred to as an “e-hailing service”), using a user interface presented on the computing device. After a server for the on-demand service receives an order (also referred to as a “booking”) for the on-demand sendee from the user, the server may allocate a delivery service provider (who in some contexts herein may also be referred to as a “driver”, a “driver partner”, a “Dax”, a “delivery partner” or a “delivery agent”) to the received order, and the delivery service provider may perform the on-demand sendee for the received order. For example, the delivery service provider may move to a destination (that in some contexts herein may also be referred to as a “drop-off point”, a “delivery point”, a “delivery location” or a “meeting point”) for the received order.

[0003] However, it may be challenging to establish an optimal pricing model which may cater both the delivery service provider and the user. Traditional methods of balancing supply anddemand may often involve manually implementing surcharges when supply conditions deteriorate. This traditional approach may demand a substantial human intervention and typically respond to market changes at a slower pace.

[0004] Therefore, there is a need to provide a solution for facilitating determining a driver fare for the on-demand service, for example, dynamically at a faster pace.SUMMARY

[0005] Various embodiments may provide an innovative approach to dynamically calculate delivery service provider-side (for example, driver-side) prices that are both sufficient to maintain a healthy supply condition and balanced enough to avoid any overpayment. Various embodiments may consider various factors, such as a real-time market demand, availability of the delivery service provider, booking attractiveness, and location- specific variables. Various embodiments may employ at least one advanced algorithm and / or at least one predictive model for an optimal balance between cost-efficiency and satisfaction of the delivery service provider. Various embodiments may determine appropriate compensations for the delivery service provider in various on-demand services, including, but not limited to, transport, food, mart and express services.

[0006] According to various embodiments, there is a server for facilitating determining a driver fare for an on-demand service, the server comprising: a memory configured to store instructions; a communication interface configured to receive an order for the on-demand sendee from a computing device; and a processor for executing the stored instructions and configured to: parse information about the order; query one or more first features relating to a real-time supply condition in relation to the order based on the information about the order; input the first features into a deep neural network model; predict an acceptance probability thata delivery service provider will accept the order at a current driver fare, using the deep neural network model that the first features arc input; and determine a new driver fare based on the predicted acceptance probability.

[0007] In some embodiments, the processor is further configured to apply at least one of an upper bound and a lower bound to determine the new driver fare.

[0008] In some embodiments, the processor is further configured to: check if the new driver fare is greater than the upper bound or less than the lower bound; and if the new driver fare is greater than the upper bound or less than the lower bound, adjust the new driver fare.

[0009] In some embodiments, the processor is further configured to model a response to a change of the current driver fare from the delivery service provider.

[0010] In some embodiments, the processor is further configured to use a logistic regression model to model the response to the change of the current driver fare from the delivery service provider.

[0011] In some embodiments, the processor is further configured to request the deep neural network model which is trained for an area in relation to the order, to predict the acceptance probability.

[0012] In some embodiments, the processor is further configured to train the deep neural network model based on the area in relation to the order.

[0013] In some embodiments, the processor is further configured to: extract one or more second features relating to a characteristic of the order from the information about the order; input the second features into the deep neural network model; and predict the acceptance probability using the deep neural network model that the first features and the second features are input.

[0014] In some embodiments, the second features include at least one of a pick-up effort of the delivery service provider, a geographical location of the delivery service provider, a deliveryeffort of the delivery service provider, earnings of the delivery service provider, and a timing of the order.

[0015] In some embodiments, the first features include at least one of a Confirmed Allocation Rate (CAR) and an Effective Acceptance Rate (EAR).

[0016] According to various embodiments, there is a method for facilitating determining a driver fare for an on-demand service, the method comprising: receiving an order for the on- demand service from a computing device; parsing information about the order; querying one or more first features relating to a real-time supply condition in relation to the order based on the information about the order; inputting the first features into a deep neural network model; predicting an acceptance probability that a delivery service provider will accept the order at a current driver fare, using the deep neural network model that the first features arc input; and determining a new driver fare based on the predicted acceptance probability.

[0017] In some embodiments, the method further comprises: applying at least one of an upper bound and a lower bound to determine the new driver fare.

[0018] In some embodiments, the method further comprises: checking if the new driver fare is greater than the upper bound or less than the lower bound; and if the new driver fare is greater than the upper bound or less than the lower bound, adjusting the new driver fare.

[0019] In some embodiments, the method further comprises: modelling a response to a change of the current driver fare from the delivery service provider.

[0020] In some embodiments, the method further comprises: using a logistic regression model to model the response to the change of the current driver fare from the delivery service provider.

[0021] In some embodiments, the method further comprises: requesting the deep neural network model which is trained for an area in relation to the order, to predict the acceptance probability.

[0022] In some embodiments, the method further comprises: training the deep neural network model based on the area in relation to the order.

[0023] In some embodiments, the method further comprises: extracting one or more second features relating to a characteristic of the order from the information about the order; inputting the second features into the deep neural network model; and predicting the acceptance probability using the deep neural network model that the first features and the second features are input.

[0024] In some embodiments, the second features include at least one of a pick-up effort of the delivery service provider, a geographical location of the delivery service provider, a deliver}' effort of the delivery service provider, earnings of the delivery service provider, and a timing of the order.

[0025] In some embodiments, the first features include at least one of a Confirmed Allocation Rate (CAR) and an Effective Acceptance Rate (EAR).

[0026] According to various embodiments, a data processing apparatus configured to perform the method of any one of the above embodiments is provided.

[0027] According to various embodiments, a computer program element comprising program instructions, which, when executed by one or more processors, cause the one or more processors to perform the method of any one of the above embodiments is provided.

[0028] According to various embodiments, a computer-readable medium comprising program instructions, which, when executed by one or more processors, cause the one or more processors to perform the method of any one of the above embodiments is provided. The computer-readable medium may include a non-transitory computer-readable medium.BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The invention will be better understood with reference to the detailed description when considered in conjunction with the non-limiting examples and the accompanying drawings, in which:- FIGS. 1 and 2 illustrate infrastructures of a system including a server for determining a driver fare for an on-demand service according to various embodiments.- FIG. 3 illustrates a block diagram of a server for determining a driver fare for an on- demand service according to various embodiments.- FIG. 4 illustrates a flowchart for a method for determining a driver fare for an on- demand service according to various embodiments.- FIG. 5 illustrates a data flow diagram of a server for determining a driver fare for an on-demand service according to various embodiments.- FIG. 6 illustrates an exemplary graph showing predicted driver fare elasticity for an on- demand service according to various embodiments.DETAILED DESCRIPTION roo3o] The following detailed description refers to the accompanying drawings that show, by way of illustration, specific details and embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure. Other embodiments may be utilized and structural, and logical changes may be made without departing from the scope of the disclosure. The various embodiments arc not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments.

[0031] Embodiments described in the context of one of a server and a method arc analogously valid for the other server and method. Similarly, embodiments described in the context of a server are analogously valid for a method, and vice-versa.

[0032] Features that are described in the context of an embodiment may correspondingly be applicable to the same or similar features in the other embodiments. Features that are described in the context of an embodiment may correspondingly be applicable to the other embodiments, even if not explicitly described in these other embodiments. Furthermore, additions and / or combinations and / or alternatives as described for a feature in the context of an embodiment may correspondingly be applicable to the same or similar feature in the other embodiments.

[0033] In the context of various embodiments, the articles “a”, “an” and “the” as used with regard to a feature or clement include a reference to one or more of the features or elements.

[0034] As used herein, the term “and / or” includes any and all combinations of one or more of the associated listed items.

[0035] Throughout the description, the term “module” may be understood as an application specific integrated circuit (ASIC), an electronic circuit, a combinational logic circuit, a field programmable gate array (FPGA), a processor which executes code, other suitable hardware components which provide the described functionality, or any combination thereof. The term of “module” may include a memory which stores code executed by the processor.

[0036] In the following, embodiments will be described in detail.

[0037] FIGS. 1 and 2 illustrate infrastructures of a system 200 including a server 100 for determining a driver fare for an on-demand service according to various embodiments.

[0038] As shown in FIG. 1, the system 200 may include, but is not limited to, the server 100, a database system 140, a network 150, a plurality of first computing devices 160 each associated with a plurality of users 161 (who in some contexts herein may also be referred to as a “requester”, a “consumer” or a “customer”), a plurality of second computing devices 170(not shown) each associated with a plurality of delivery service providers 171 (who in some contexts herein may also be referred to as a “driver”, a “driver partner”, a “Dax”, a “delivery partner” or a “delivery agent”), and a plurality of third computing devices 180 (not shown) each associated with a plurality of item providers 181 (who in some contexts herein may also be referred to as a “merchant”, a “Mex”, a “food provider” or a “restaurant”). In some embodiments, the users 161 may include a consumer (who in some contexts herein may also be referred to as an “eater” or a “passenger”) for the on-demand service. For example, a user 161a may be the same as the consumer. As another example, the user 161 a may be different from the consumer and use the on-demand service for and / or on behalf of the consumer.

[0039] In some embodiments, the on-demand service may be a service allowing the user 161a to fulfil the user’s demand via an immediate access to items and / or services. The user 161a may request the on-demand service, such as a transport service or an item delivery service, using a user interface presented on a computing device 160a. The user 161a may make an order for the on-demand service.

[0040] In some embodiments, the user 161a may use an application, for example, a mobile application, provided by a server 100. For example, the server 100 may be controlled and / or managed by an on-demand service platform provider. The application may be installed in the first computing device 160a associated with the user 161a, to interact with the on-demand sendee.

[0041] In some embodiments, the network 150 may include, but is not limited to, a Local Area Network (LAN), a Wide Area Network (WAN), a Global Area Network (GAN), or any combination thereof. The network 150 may provide a wireline communication, a wireless communication, or a combination of the wireline and wireless communication between the server 100 and the plurality of first computing devices 160, between the sener 100 and the plurality of second computing devices 170, and between the server 100 and the plurality ofthird computing devices 180. As shown in FIG. 2, the network 150 may provide the wireline communication, the wireless communication, or the combination of the wireline and wireless communication between the first computing device 160a of the plurality of first computing devices 160 and a second computing device 170a of the plurality of second computing devices 170.

[0042] In some embodiments, the plurality of first computing devices 160 may be connectable to the server 100 via the network 150. In some embodiments, the plurality of first computing devices 160 may be arranged in data or signal communication with the server 100 via the network 150. In some embodiments, the plurality of first computing devices 160 may include, but is not limited to, at least one of the following: a mobile phone, a tablet computer, a laptop computer, a desktop computer, a head-mounted display and a smart watch. In some embodiments, the plurality of first computing devices 160 may be associated with the plurality of users 161 respectively. For example, the plurality of first computing devices 160 may belong to the plurality of users 161 respectively. For example, the first computing device 160a may belong to the user 161a who is the consumer. As another example, the first computing device 160a may belong to the user 161a requesting the delivery of the item to the consumer who is a recipient of the on-demand service.

[0043] In some embodiments, the first computing device 160a may include a location sensor. In some embodiments, the location sensor may communicate with at least one of a global positioning satellite (GPS) server, a network server, and a Wi-Fi server, to detect a location of the first computing device 160a. In some embodiments, the first computing device 160a may generate information about the location of the first computing device 160a.

[0044] In some embodiments, the server 100, for example, implemented by a server computer, may include a communication interface 110, a processor 120, and a memory 130 (as will be described with reference to FIG. 3).

[0045] In some embodiments, the server 100 may communicate with the plurality of first computing devices 160 via the network 150. In some embodiments, the first computing device 160a may receive a request (hereinafter, referred to as an “order”) from the user 161a for the on-demand service. The first computing device 160a may send the order to the server 100 via the network 150. In some embodiments, the first computing device 160a may send the information about the location of the first computing device 160a to the server 100 via the network 150. The location of the first computing device 160a may be considered as a location of the user 161 a. In some embodiments, the location of the user 161 a may be considered as a destination of the on-demand service. In some other embodiments, the first computing device 160a may send information about an address of the user 161a, and the address of the user 161a may be considered as the destination of the on-demand service. In some other embodiments, the first computing device 160a may send information about an address of the recipient of the delivery, and the address of the recipient may be considered as the destination of the on-demand service.

[0046] In some embodiments, the system 200 may further include a database 141. In some embodiments, the database 141 may be apart of the database system 140 which may be external to the server 100. The server 100 may communicate with the database 141. In some other embodiments, although not shown, the database 141 may be implemented locally in the memory' 130 of the server 100.

[0047] In some embodiments, the server 100 may communicate with the plurality of second computing devices 170 via the network 150. In some embodiments, the plurality of second computing devices 170 may be arranged in data or signal communication with the server 100 via the network 150. In some embodiments, the plurality of second computing devices 170 may include, but is not limited to, at least one of the following: a mobile phone, a tablet computer, a laptop computer, a desktop computer, a head-mounted display and a smart watch. In someembodiments, the plurality of second computing devices 170 may be associated with the plurality of delivery service providers 171 respectively. For example, the plurality of second computing devices 170 may belong to the plurality of delivery service providers 171 respectively.

[0048] In some embodiments, the server 100 may receive the order from the first computing device 160a. After the server 100 receives the order from the first computing device 160a, the server 100 may allocate (assign) the order to a suitable delivery service provider 171a. In some embodiments, the second computing device 170a associated with the delivery service provider 171a may send information about a location of the second computing device 170a to the server 100 via the network 150. The location of the second computing device 170a may be considered as a location of the delivery service provider 171a. In some embodiments, the location of the delivery service provider 171a may be considered as a current location of the delivery service provider 171a, and may change while the delivery service provider 171a moves to the destination (en route to the destination). In some embodiments, the server 100 may provide the second computing device 170a with a map relating to a route from the current location of the second computing device 170a (which may be considered as the location of the delivery service, provider 171a) to the destination for providing the on-demand service, en route to the destination.

[0049] In some embodiments, the server 100 may communicate with the plurality of third computing devices 180 via the network 150. In some embodiments, the plurality of third computing devices 180 may be arranged in data or signal communication with the server 100 via the network 150. In some embodiments, the plurality of third computing devices 180 may include, but is not limited to, at least one of the following: a mobile phone, a tablet computer, a laptop computer, a desktop computer, a head-mounted display and a smart watch. In some embodiments, the plurality of third computing devices 180 may be associated with the pluralityof item providers 181 respectively. For example, the plurality of third computing devices 180 may belong to the plurality of item providers 181 respectively.

[0050] FIG. 3 illustrates a block diagram of a server 100 for determining a driver fare for an on-demand service according to various embodiments.

[0051] As shown in FIG. 3, the server 100, for example, implemented by a server computer, may include a communication interface 110, a processor 120, and a memory 130.

[0052] In some embodiments, the memory 130 (also referred to as a “database”) may store input data and / or output data temporarily or permanently. In some embodiments, the memory 130 may be configured to store instructions. In some embodiments, the memory 130 may store program code which allows the server 100 to perform a method 300 (as will be described with reference to FIG. 4). In some embodiments, the program code may be embedded in a Software Development Kit (SDK). The memory 130 may include an internal memory of the server 100 and / or an external memory. The external memory may include, but is not limited to, an external storage medium, for example, a memory card, a flash drive, and a web storage.

[0053] In some embodiments, the communication interface 110 may allow a plurality of first computing devices 160 to communicate with the processor 120 of the server 100 via the network 150, as shown in FIGS. 1 and 2. As shown in FIGS. 1 and 2, each of the plurality of first computing devices 160 may belong to each of users 161 who want to make an order for an on-demand service. In some embodiments, the communication interface 110 may transmit signals to the plurality of first computing devices 160, and / or receive signals from the plurality of first computing devices 160, via the network 150. For example, as shown in FIGS. 1 and 2, a first computing device 160a may belong to a user 161a who wants to make an order for an on-demand service, and the communication interface 110 may transmit signals to the first computing device 160a, and / or receive signals from the first computing device 160a via the network 150.

[0054] In some embodiments, the communication interface 110 may allow a plurality of second computing devices 170 to communicate with the processor 120 of the server 100 via the network 150, as shown in FIGS. 1 and 2. As shown in FIGS. 1 and 2, each of the plurality of second computing devices 170 may belong to each of a plurality of delivery service providers 171 who may pick up an item from an item service provider 181a and deliver the item to the consumer (i.e. a destination) and / or who may transport the consumer to the destination. In some embodiments, the communication interface 110 may transmit signals to the plurality of second computing devices 170, and / or receive signals from the plurality of second computing devices 170, via the network 150.

[0055] In some embodiments, the communication interface 110 may allow a plurality of third computing devices 180 to communicate with the processor 120 of the server 100 via the network 150, as shown in FIG. 1. As shown in FIG. 1, each of the plurahty of third computing devices 180 may belong to each of a plurality of item providers 181 who may prepare an item, for example, food, for the order. In some embodiments, the communication interface 110 may transmit signals to the plurality of third computing devices 180, and / or receive signals from the plurality of third computing devices 180, via the network 150.

[0056] The processor 120 may include, but is not limited to, a microprocessor, an analogue circuit, a digital circuit, a mixed-signal circuit, a logic circuit, an integrated circuit, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), or any combination thereof. Any other kind of implementation of the respective functions, which will be described below in further detail, may also be understood as the processor 120.

[0057] In some embodiments, the processor 120 may be connectable to the communication interface 110. In some embodiments, the processor 120 may be arranged in data or signal communication with the communication interface 110 to transmit / receive the signals.

[0058] In some embodiments, the communication interface 110 may receive a plurality of requests (also referred to as “a plurality of orders”) for the on-demand sendee from the plurality of first computing devices 160 each associated with the plurality of users 161 (who in some contexts herein may also be referred to as “consumers 161” or “requesters 161”). In some embodiments, the processor 120 may receive the plurality of orders for the on-demand service from the communication interface 110. For example, the communication interface 110 may receive a request (also referred to as an “order”) for the on-demand service from the first computing device 160a associated with the user 161 a (who in some contexts herein may also be referred to as a “consumer 161a” or a “requester 161a”), and the processor 120 may receive the order for the on-demand service from the communication interface 110.

[0059] In some embodiments, for each order of the plurality of orders, for example, the order received from the computing device 160a, the processor 120 may parse information about the order. In some embodiments, the processor 120 may analyse the information about the order. In some embodiments, the information about the order may include metadata relating to a characteristic (also referred to as a “property”) of the order.

[0060] In some embodiments, the processor 120 may query one or more features (hereinafter, referred to as “first features”) relating to a real-time supply condition in relation to the order. In some embodiments, the processor 120 may query the first features relating to the real-time supply condition in relation to the order based on the parsed information about the order. In some embodiments, the processor 120 may query the first features relating to the real-time supply condition in relation to the order to the memory 130 and / or a database 141 of a database system 140 (as described with reference to FIGS. 1 and 2). Thereafter, the processor 120 may obtain the first features relating to the real-time supply condition in relation to the order from the memory 130 and / or the database 141. In some embodiments, the first features may include at least one of a Confirmed Allocation Rate (CAR) and an Effective Acceptance Rate (EAR).

[0061] In some embodiments, the first features may include the Confirmed Allocation Rate (CAR) for a plurality of orders which arc received within a certain time slot and made in a certain area (region), for example, in the same area. In some embodiments, the Confirmed Allocation Rate (CAR) may give a real-time overview of allocation health (fulfilment) of a given space and time, by evaluating allocated orders with respect to outstanding orders. For example, the Confirmed Allocation Rate (CAR) may be calculated by dividing the number of the allocated orders into the number of all the orders which are geographically relevant, for example, in the same area, and received within the certain time slot (for example, 10 minutes). As an example, if the order received from the user 161a is received at 11:00 a.m. and made in an area A, the processor 120 may obtain the Confirmed Allocation Rate (CAR) calculated by dividing the number of the allocated orders into the number of all the orders received from 10:50 a.m. to 10:59 a.m. and made in the area A. As another example, a merchant (item provider) related Confirmed Allocation Rate (CAR) may be used. If the order received from the user 161a is received at 11:00 a.m. and relates to a merchant (item provider) M, the processor 120 may obtain the Confirmed Allocation Rate (CAR) calculated by dividing the number of the allocated orders into the number of all the orders received from 10:50 a.m. to 10:59 a.m. and relates to the merchant M.

[0062] In some embodiments, the first features may include the Effective Acceptance Rate (EAR) which may be a metric in assessing market supply. In some embodiments, the Effective Acceptance Rate (EAR) may account for factors such as order acceptance and rejection rates, and may further incorporate potential cancellations from both the plurality of delivery service providers 171 and the plurality of users 161. For example, the processor 120 may obtain the Effective Acceptance Rate (EAR) calculated by dividing the number of the accepted and noncancelled orders into the number of all the orders received from 10:50 a.m. to 10:59 a.m. and made in the area A.

[0063] In some embodiments, the processor 120 may input the first features into a deep neural network model. In some embodiments, the deep neural network model may include a machine learning model to automate prediction and an adjustment of supply levels. For example, the processor 120 may feed the at least one of a Confirmed Allocation Rate (CAR) and an Effective Acceptance Rate (EAR) into the deep neural network model.

[0064] In some embodiments, the deep neural network model may process the input, for example, the at least one of a Confirmed Allocation Rate (CAR) and an Effective Acceptance Rate (EAR), to output data relating to prediction of an acceptance probability. Tn some embodiments, the processor 120 may select a suitable delivery service provider 171a to accept the order to provide the on-demand service. Throughout the description, a term of a “driver fare” may refer to a delivery service provider 171a side fare. For example, the driver fare may be an amount that the delivery service provider 171a may receive in return for performing the on-demand service. As an example, the user 161a may pay a fare including the driver fare for the delivery service provider 171a and commissions for the on-demand service platform. In some embodiments, the processor 120 may obtain a cunent driver fare (also referred to as a “cunent delivery driver fare” or an “original driver fare”) for the order which is previously determined, for example, using a traditional pricing model (for example, calculated purely based on distance and time). In some embodiments, the processor 120 may predict an acceptance probability that the delivery service provider 171a will accept the order at the current driver fare, using the deep neural network model that the first features are input.

[0065] In some embodiments, the processor 120 may determine a new driver fare (also referred to as a “new delivery driver fare”) based on the predicted acceptance probability. For example, if the predicted acceptance probability is greater than a predetermined first probability, the processor 120 may determine the new driver fare to be lower than the current driver fare. As another example, if the predicted acceptance probability is less than a predetermined secondprobability, the processor 120 may determine the new driver fare to be greater than the current driver fare. As another example, if the predicted acceptance probability is less than the predetermined first probability and greater than the predetermined second probability, the processor 120 may determine the new driver fare to be the same as the current driver fare.

[0066] In some embodiments, the processor 120 may apply at least one of an upper bound and a lower bound to determine the new driver fare. In some embodiments, the processor 120 may apply the at least one of the upper bound and the lower bound to limit a range of the new driver fare. In some embodiments, the processor 120 may check if the new driver fare is greater than the upper bound or less than the lower bound. In some embodiments, if the new driver fare is greater than the upper bound or less than the lower bound, the processor 120 may adjust the new driver fare. For example, where the predicted acceptance probability is greater than the predetermined first probability, the processor 120 may determine the new driver fare to be lower than the current driver fare, check if the new driver fare is less than the lower bound, and adjust the new driver fare not to be less than the lower bound if the new driver fare is less than the lower bound. As another example, where the predicted acceptance probability is less than the predetermined second probability, the processor 120 may determine the new driver fare to be greater than the current driver fare, check if the new driver fare is greater than the upper bound, and adjust the new driver fare not to be greater than the upper bound if the new driver fare is greater than the upper bound.

[0067] In some embodiments, the processor 120 may model a response to a change of the current driver fare from the delivery service provider 171a. For example, the response may be a predicted response of the delivery service provider 171a, given the new driver fare. A prediction machine learning model which may be based on previous behaviours of the delivery service provider 171a may be used to output the predicted response. The predicted response which may be the output of the prediction machine learning model may be a predictedprobability of an acceptance of the delivery service provider 171a. In some embodiments, the processor 120 may use a logistic regression model to model the response to the change of the current driver fare (i.e. supply elasticity) from the delivery service provider 171a, from which the processor 120 may know how to vary the current driver fare to achieve the goal of the healthy Effective Acceptance Rate (EAR). In some embodiments, the logistic regression model may be a statistical model for binary classification, and model a relationship between a dependent binary variable (for example, yes or no) and one or more independent variables (for example, the change of the current driver fare) by estimating the probability of the binary outcome.

[0068] In some embodiments, the processor 120 may request the deep neural network model which is trained for an area in relation to the order (for example, the same area (for example, the same city) that the order is made), to predict the acceptance probability. In some embodiments, there may be a plurality of deep neural network models trained for a plurality of areas respectively, in the memory 130 and / or the database 141. In some embodiments, the processor 120 may select the deep neural network model which is trained for the same area that the order is made, and request the deep neural network model to predict the acceptance probability.

[0069] In some embodiments, the processor 120 may train the deep neural network model based on the area in relation to the order. In some embodiments, the processor 120 may train the selected deep neural network model based on the input, for example, the first features in relation to the order, and the output, for example, the determined new driver fare.

[0070] In some embodiments, the processor 120 may extract one or more second features relating to the characteristic of the order from the information about the order. In some embodiments, the second features may include, but are not limited to, at least one of a pick-up effort of the delivery service provider 171a (for example, whether a pick-up point is easy toaccess), a geographical location of the delivery service provider 171a (for example, a current geographical location of the delivery service provider 171a), a delivery effort of the delivery service provider 171a (for example, whether a delivery point is easy to access), earnings of the delivery service provider 171a (for example, a compensation to be given to the delivery service provider 171 after completion of the order), and a timing of the order (for example, whether the order was made at peak hours). In some embodiments, the processor 120 may input the second features into the deep neural network model. In some embodiments, the processor 120 may feed the second features along with the first features including the at least one of the Confirmed Allocation Rate (CAR) and the Effective Acceptance Rate (EAR) into the deep neural network model. In some embodiments, the deep neural network model may process the input, for example, the first features and the second features, to output data relating to prediction of the acceptance probability. In some embodiments, the processor 120 may select the suitable delivery service provider 171a to accept the order to provide the on-demand service. In some embodiments, the processor 120 may obtain the current driver fare for the order which is previously determined, for example, using the traditional pricing model without using the deep neural network model. In some embodiments, the processor 120 may predict the acceptance probability that the delivery service provider 171a will accept the order at the current driver fare, using the deep neural network model that the first features and the second features are input.

[0071] In some embodiments, the processor 120 may allocate the order to the suitable deliver}' service provider 171a among the plurality of the deliver}' service providers 171. In some embodiments, the processor 120 may control a second computing device 170a associated with the delivery service provider 171a to display a map relating to a route from a location of the second computing device 170a (which may be considered as the location of the delivery service provider 171a) to a destination for providing the on-demand service, while the delivery serviceprovider 171a moves to the destination (cn route to the destination). In some embodiments, the destination may be a location of the first computing device 160a (which may be considered as the location of the consumer 161a (i.e. the user 161a)). In some other embodiments, the destination may be a location of a recipient (i.e. the consumer) of the on-demand service that the requester 161a (i.e. the user 161a) has designated.

[0072] The various embodiments may use a model for pricing based on an Effective Acceptance Rate (EAR) (also referred to as a “EAR-based Dax pricing model”). Conventionally, there has been a need to establish an optimal pricing model which may cater both the plurality of delivery service providers 171 and the plurality of users 161. The EAR- based Dax pricing model may be designed to address this requirement by offering a fair and reasonable fare structure, by accounting for supply elasticity and real-time market conditions. From the perspective of the plurality of delivery service providers 171, in scenarios of a high demand such as peak hours and popular shopping malls, it may be imperative that they would receive fair compensation. This may be particularly relevant when there is a surge on the user’s side. The EAR-based Dax pricing model may also help define the driver fare that assist the delivery service provider in identifying which orders they would prefer to fulfil. The EAR- based Dax pricing model may be expected to help balance supply during times of shortage in the plurality of delivery service providers 171, by maintaining a healthy Effective Acceptance Rate (EAR). This may ensure a balanced marketplace where the driver fare is dynamically adjusted based on real-time supply and demand conditions, leading to increased efficiency, an optimal resource allocation, and an improved overall user experience for both the plurality of delivery sendee providers 171 and the plurality of users 161.

[0073] The various embodiments may employ a machine learning model to automate the prediction and the adjustment of the supply levels. The integration of the real-time supply condition signals may enable rapid detection and adaptation to market fluctuations.Furthermore, the Effective Acceptance Rate (EAR) may be an innovative metric in assessing the market supply. The Effective Acceptance Rate (EAR) may account for the factors such as the order acceptance and rejection rates, and may further incorporate the potential cancellations from both the plurality of delivery service providers 171 and the plurality of users 161. This comprehensive approach may provide more accurate reflection of the supply conditions, thereby enhancing efficiency of supply-demand management efforts.

[0074] It may be appreciated that the various embodiments may be applied across various industries processing pricing autonomy. For example, the various embodiments may be applied to an airline industry, primarily in a domain of ticket booking services. By employing the EAR- based Dax pricing model, the processor 120 may determine an optimal price point that simultaneously appeals to customers, and thereby ensuring a sufficient likelihood of purchase while also safeguarding the platform’ s / company’s profit margins.

[0075] FIG. 4 illustrates a flowchart for a method 300 for determining a driver fare for an on- demand service according to various embodiments. According to various embodiments, the method 300 for determining the driver fare for the on-demand service may be provided.

[0076] In some embodiments, the method 300 may include a step 301 of receiving an order for the on-demand service from a computing device.

[0077] In some embodiments, the method 300 may include a step 302 of parsing information about the order.

[0078] In some embodiments, the method 300 may include a step 303 of querying one or more first features relating to a real-time supply condition in relation to the order based on the information about the order.

[0079] In some embodiments, the method 300 may include a step 304 of inputting the first features into a deep neural network model.

[0080] In some embodiments, the method 300 may include a step 305 of predicting an acceptance probability that a delivery sendee provider will accept the order at a current driver fare, using the deep neural network model that the first features are input.

[0081] In some embodiments, the method 300 may include a step 306 of determining a new driver fare based on the predicted acceptance probability.

[0082] FIG. 5 illustrates a data flow diagram of a server for determining a driver fare for an on-demand service according to various embodiments. FIG. 6 illustrates an exemplary graph showing predicted driver fare elasticity for an on-demand service according to various embodiments.

[0083] As shown in FIG. 5, a model for pricing based on an Effective Acceptance Rate (EAR) 220 (also referred to as a “EAR-based Dax pricing model”) may be provided. In some embodiments, a processor 120 of a server 100 (as described with reference to FIGS. 1 to 3) may include the EAR-based Dax pricing model 220. Upon receipt of an order broadcast request (221) from a user 161a, the EAR-based Dax pricing model 220 may parse the request (222), and query real-time signals (also referred to as “first features”) in relation to the request (223). The EAR-based Dax pricing model 220 may then process the first features (224), and request a relevant city model (225). In some embodiments, the EAR-based Dax pricing model 220 may include a plurality of (sub) EAR-based Dax pricing models based on each city, and the (sub) EAR-based Dax pricing model relevant to the city relating to the request may be used to compute the optimal delivery (Dax) driver fare (also referred to as a “new driver fare”) and log data (226). For example, the log data may include, but is not limited to, city average EAR and CAR values, an average predicted EAR, an average optimal driver fare output, etc., for the purpose of monitoring. Thereafter, the EAR-based Dax pricing model 220 may return the optimal delivery driver fare, and the optimal delivery driver fare may be used as a deliver}' driver fare for the request for the on-demand service.

[0084] As shown in FIGS. 5 and 6, on a broadcasted booking level, the EAR-based Dax pricing model 220 may be called and return the optimal delivery driver fare. To achieve this, there may be two steps in the EAR-based Dax pricing model 220, as follows:Step 1) For each booking broadcast, the processor 120 may use a deep neural network to predict a probability of acceptance with the current delivery (Dax) driver fare (also referred to as a “current driver fare” or an “original driver fare”).Step 2) Then, the processor 120 may use a logistic regression model to model delivery service providers’ (for example, drivers’) responses to driver fare changes (i.e. supply elasticity), from which the processor 120 may know how to vary the current delivery (Dax) driver fare to achieve a goal of a healthy Effective Acceptance Rate (EAR).

[0085] For the first step (Step 1), one or more features (also referred to as “second features”) may be included to predict whether a certain broadcasted booking will be effectively accepted. These may encompass factors including, but not limited to, at least one of a pick-up effort of the delivery service provider 171a, a geographical location of the delivery service provider 171a, a delivery effort of the delivery service provider 171a, earnings of the delivery service provider 171a, and a timing of the order. A distinguishing hallmark of this approach may be the integration of one or more real-time features (also referred to as “first features”) including, but not limited to, Confirmed Allocation Rate (CAR) and Effective Acceptance Rate (EAR) signals. These input signals may serve as accurate barometers of real-time market dynamics. Consequently, the model according to various embodiments may be equipped with an ability to detect supply constraints with enhanced precision and timeliness. In some embodiments, all these features may be fed to the deep neural network, and the model may be trained on every city.

[0086] For the second step (Step 2), a logistic regression function (also referred to as a “logistic regression model”) may be used to capture the delivery service providers’ 171 sensitivity tothe driver fare change, and determine the pricing aggressiveness. Specifically, knowing the predicted acceptance probability from the first step, the optimal delivery driver fare (i.c. new driver fare) may be calculated as follows:where ptdaxis an optimal delivery (Dax) driver fare output, p, is an optimal delivery (Dax) driver fare, EARtar0etis a desirable EAR level determined by a company’s (for example, on- demand service platform provider’s) strategy, and EAR, is a predicted EAR probability.For the logistic regression function 0 =* the optimal delivery driver fare may be solved explicitly as follows: where p.driver fare, EARtar0etis a desirable EAR level determined by a company’s (for example, on- demand service platform provider’s) strategy, and EARtis a predicted EAR probability.

[0087] Finally, the processor 120 may apply at least one of an upper bound and a lower bound to determine the optimal delivery driver fare. For example, a min-max bounding may be applied to prevent the optimal delivery driver fare which may deviate too much from the current delivery driver fare. This mechanism may play a crucial role in maintaining a consistent and robust supply of the delivery service providers 171. It may intuitively adjust for situations indicative of supply shortages, such as peak hours or adverse weather conditions like heavy rainfall. During these periods, the delivery service providers 171 may expect increased earnings as compensation for the additional demand and higher effort required on their services. By dynamically calibrating delivery driver fares to account for these fluctuations, the various embodiments may ensure that the delivery service providers 171 remain motivated to fulfil their roles, thereby sustaining a healthy supply-demand equilibrium.

[0088] FIG. 6 shows a curve of the predicted driver price (driver fare) elasticity. For a broadcast, the processor 120 may get the predicted EAR given the current driver fare, and adjust it accordingly so that the predicted EAR reaches the target EAR on the curve.

[0089] While the disclosure has been particularly shown and described with reference to specific embodiments, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. The scope of the invention is thus indicated by the appended claims and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced.

Claims

CLAIMS1. A server for facilitating determining a driver fare for an on-demand service, the server comprising: a memory configured to store instructions; a communication interface configured to receive an order for the on-demand service from a computing device; and a processor for executing the stored instructions and configured to: parse information about the order; query one or more first features relating to a real-time supply condition in relation to the order based on the information about the order; input the first features into a deep neural network model; predict an acceptance probability that a delivery service provider will accept the order at a current driver fare, using the deep neural network model that the first features are input; and determine a new driver fare based on the predicted acceptance probability.

2. The server according to claim 1, wherein the processor is further configured to apply at least one of an upper bound and a lower bound to determine the new driver fare.

3. The server according to claim 2, wherein the processor is further configured to: check if the new driver fare is greater than the upper bound or less than the lower bound; and if the new driver fare is greater than the upper bound or less than the lower bound, adjust the new driver fare.

4. The server according to any one of claims 1 to 3, wherein the processor is further configured to model a response to a change of the current driver fare from the delivery service provider.

5. The server according to claim 4, wherein the processor is further configured to use a logistic regression model to model tire response to the change of the current driver fare from the delivery service provider.

6. The server according to any one of claims 1 to 5, wherein the processor is further configured to request the deep neural network model which is trained for an area in relation to the order, to predict the acceptance probability.

7. The server according to claim 6, wherein the processor is further configured to train the deep neural network model based on the area in relation to the order.

8. The server according to any one of claims 1 to 7, wherein the processor is further configured to: extract one or more second features relating to a characteristic of the order from the information about the order; input the second features into the deep neural network model; and predict the acceptance probability using the deep neural network model that the first features and the second features are input.

9. The server according to claim 8, wherein the second features include at least one of a pick-up effort of the delivery service provider, a geographical location of the delivery service provider, a delivery effort of the delivery service provider, earnings of the delivery service provider, and a timing of the order.

10. The server according to any one of claims 1 to 9, wherein the first features include at least one of a Confirmed Allocation Rate (CAR) and an Effective Acceptance Rate (EAR).

11. A method for facilitating determining a driver fare for an on-demand service, the method comprising: receiving an order for the on-demand service from a computing device; parsing information about the order; querying one or more first features relating to a real-time supply condition in relation to the order based on the information about the order; inputting the first features into a deep neural network model; predicting an acceptance probability that a delivery service provider will accept the order at a current driver fare, using the deep neural network model that the first features are input; and determining a new driver fare based on the predicted acceptance probability.

12. The method according to claim 11 , further comprising: applying at least one of an upper bound and a lower bound to determine the new driver fare.

13. The method according to claim 12, further comprising:checking if the new driver fare is greater than the upper bound or less than the lower bound; and if the new driver fare is greater than the upper bound or less than the lower bound, adjusting the new driver fare.

14. The method according to any one of claims 11 to 13, further comprising: modelling a response to a change of the current driver fare from the delivery service provider.

15. The method according to claim 14, further comprising: using a logistic regression model to model the response to the change of the current driver fare from the delivery service provider.

16. The method according to any one of claims 11 to 15, further comprising: requesting the deep neural network model which is trained for an area in relation to the order, to predict the acceptance probability.

17. The method according to claim 16, further comprising: training the deep neural network model based on the area in relation to the order.

18. The method according to any one of claims 11 to 17, further comprising: extracting one or more second features relating to a characteristic of the order from the information about the order; inputting the second features into the deep neural network model; andpredicting the acceptance probability using the deep neural network model that the first features and the second features arc input.

19. The method according to claim 18, wherein the second features include at least one of a pick-up effort of the delivery service provider, a geographical location of the delivery service provider, a delivery effort of the delivery sendee provider, earnings of the delivery service provider, and a timing of the order.

20. The method according to any one of claims 11 to 19, wherein the first features include at least one of a Confirmed Allocation Rate (CAR) and an Effective Acceptance Rate (EAR).

Images