CN111052158B

CN111052158B - System and method for distributing service requests

Info

Publication number: CN111052158B
Application number: CN201880048507.0A
Authority: CN
Inventors: 陈学文; 郑新光; 王洋
Original assignee: Beijing Didi Infinity Technology and Development Co Ltd
Current assignee: Beijing Didi Infinity Technology and Development Co Ltd
Priority date: 2017-07-20
Filing date: 2018-07-20
Publication date: 2023-09-22
Anticipated expiration: 2038-07-20
Also published as: EP3642769A4; TWI690867B; EP3642769A1; WO2019015661A1; CN109284881A; CN111052158A; US20200151640A1; TW201909055A

Abstract

Systems and methods for distributing service requests are provided. The method may include receiving a service request, determining a predicted value of the service request, and determining at least one candidate service provider for the service request. The method may further comprise: for each of the at least one candidate service provider, obtaining historical order parameters for the candidate service provider, receiving expected order parameters for the candidate service provider, and determining an order allocation weight for the service request based on the estimated value of the service request, the historical order parameters for the candidate service provider, and the expected order parameters. The method may further comprise: the target service provider is determined based on at least one order allocation weight for the service request for the at least one candidate service provider.

Description

System and method for distributing service requests

Cross reference

The present application claims priority from chinese application No. 201710597338.3 filed on 7, 20, 2017, the entire contents of which are incorporated herein by reference.

Technical Field

The present application relates generally to online-to-offline services, and more particularly, to a system and method for distributing service requests from service requesters to service providers.

Background

On-line to off-line (O2O) services (e.g., food delivery services, taxi taking services, etc.) are becoming increasingly popular in everyday life. The online-to-offline service typically sends a service request by a service requester to an online-to-offline service system. The online-to-offline service system may identify a plurality of candidate service providers and assign service requests to the service providers. Typically, one service request can only be assigned to one service provider, and one service provider can only accept one service request. The conditions (e.g., value, time, location, content) of the service request may be different for multiple service requests and multiple service providers, and the conditions (e.g., experience of providing the service, level of service provided, time and place available to provide the service) of the service provider may be different. In addition, service providers typically have their preferences for certain types of service requests. For example, some service providers may prefer simple but low value service requests, while other service providers may prefer difficult but high value service requests. Accordingly, it is desirable to provide systems and methods that automatically distribute service requests from service providers to service requesters based on a number of factors, including, but not limited to, the condition of the service request, the condition of the service provider (and/or the service requester), the preferences of the service provider (and/or the service requester), etc.

Disclosure of Invention

According to one aspect of the present application, a system is provided. The system may include a storage device and at least one processor in communication with the storage device. The storage device includes a set of instructions for assigning a service request to a service provider. The at least one processor, when executing the set of instructions, may be configured to cause the system to receive a first service request, determine a predicted value of the first service request, and determine at least one candidate server provider for the first service request. The at least one processor may be further configured to, for each of the at least one candidate service provider, obtain one or more historical order parameters for the candidate service provider, receive one or more expected order parameters for the candidate service provider. An order allocation weight for the first service request for a candidate service provider is determined based on the estimated value of the first service request, one or more historical order parameters and one or more expected order parameters for the service provider. The at least one processor may be further configured to determine a target service provider of the first service request determined from the at least one candidate service provider based on at least one order allocation weight for the first service request for the at least one candidate service provider.

In some embodiments, the one or more historical order parameters of the candidate service provider may include a historical online time period of the candidate service provider and a total value of the candidate service provider's historical orders, and the one or more expected order parameters include expected revenue per unit time.

In some embodiments, to determine an order allocation weight for a first service request for a candidate service provider, the at least one processor may be configured to cause the system to determine an expected revenue for the candidate service provider based on a historical online time period for the candidate service provider and the expected revenue per unit time, and to determine an order allocation weight for the first service request for the candidate service provider based on the expected revenue, a total value of the historical orders, and an estimated value of the first service request.

In some embodiments, to determine an order allocation weight for a first service request of a candidate service provider, the at least one processor may be further configured to determine a revenue bias for the candidate service provider based on a historical online time length of the candidate service provider, an expected revenue per unit time, and a total value of the historical orders for the candidate service provider; comparing the revenue bias of the candidate service provider to at least one revenue threshold; determining a ranking of the candidate service provider based on a comparison between the revenue bias and the at least one revenue threshold; an order allocation weight for the first service request for the candidate service provider is determined based on the ranking of the candidate service provider, the estimated value of the first service request, the historical order parameters, and the expected order parameters.

In some embodiments, the at least one revenue threshold may include a first threshold and a second threshold, the second threshold being greater than or equal to the first threshold. In order to determine a ranking of the candidate service provider based on the comparison between the revenue deviation and the revenue threshold, the at least one processor may be configured to cause the system to determine the ranking of the candidate service provider as a first ranking based on the comparison that the revenue deviation of the candidate service provider is less than the first threshold; determining the level of the candidate service provider as a second level according to a comparison result that the income deviation of the candidate service provider is larger than or equal to the first critical value and smaller than the second critical value; and determining the grade of the candidate service provider as a third grade according to the result of the comparison that the income deviation of the candidate service provider is larger than or equal to the second critical value.

In some embodiments, the ranking of candidate service providers may be determined as a first ranking. To determine an order allocation weight for a first service request with respect to the candidate service provider, the at least one processor may be configured to cause the system to determine at least two value classes, one value range for each of the at least two value classes, compare a predicted value of the first service request with the value ranges of the at least two value classes to determine a first value class for the first service request, determine a first historical proportion corresponding to the first value class based on a number of historical orders belonging to the first value class and a number of historical orders of the candidate service provider, obtain a first expected proportion corresponding to the first value class based on one or more expected order parameters, and determine an order allocation weight for the first service request with respect to the candidate service provider based on the first historical proportion corresponding to the first value class, the first expected proportion corresponding to the first value class, a value of the first service request, a historical order parameter of the candidate historical service provider, and an expected order parameter.

In some embodiments, the ranking of the candidate service provider is a second ranking. To determine an order allocation weight for the first service request relative to the candidate service provider, the at least one processor is configured to cause the system to determine at least two value classes, one value range for each of the at least two value classes, compare the estimated value of the first service request to the value ranges of the at least two value classes to determine a first value class for the first service request, determine at least one second value class from the at least two value classes, wherein the range of values associated with the at least one second value class is greater than the range of values associated with the first value class, determine a first historical proportion based on the number of historical orders belonging to the first value class and the number of historical orders of the candidate service provider, and obtain a first expected proportion corresponding to the first value class based on one or more expected order parameters. The at least one processor is further configured to cause the system to determine, for each of the at least one second price level, a second historical proportion corresponding to the second price level based on the number of historical orders belonging to the second price level and the number of at least two historical orders, obtain a second expected proportion corresponding to the second price level based on one or more expected order parameters. The at least one processor is further configured to cause the system to determine an order allocation weight for the first service request for the candidate service provider based on a first historical scale corresponding to a first price level, a second historical scale corresponding to at least one second price level, a first expected scale corresponding to the first price level, a second expected scale corresponding to at least one second price level, an estimated value of the first service request, a historical order parameter and an expected order parameter of the candidate service provider.

In some embodiments, the candidate service provider is ranked at a third ranking, and to determine that the first service request is weighted against the candidate service provider's order, the at least one processor is configured to cause the system to determine at least two value rankings, each value ranking corresponding to a range of values. The at least one processor may be further configured to cause the system to determine, for each of the at least two value classes, a historical proportion corresponding to the value class based on the number of historical orders belonging to the value class and the number of historical orders of the candidate service provider. The desired proportion corresponding to the value rank is obtained based on one or more desired order parameters. The at least one processor may be further configured to cause the system to determine an order allocation weight for the first service request for the candidate service provider based on at least two historical and expected proportions corresponding to at least two value classes, the estimated value of the first service request, the historical order parameters and the expected order parameters of the candidate service provider.

In some embodiments, the target service provider of the first service request is determined from the at least one candidate service provider based on at least one order allocation weight for the first order service request for the at least one candidate service provider. The at least one processor may be further configured to cause the system to receive a second service request for each of the at least one second user device and determine at least one order allocation weight for the second service request for the at least one candidate service provider. The at least one processor may be further configured to cause the system to construct a bipartite graph of at least one candidate service provider relating the first service request and the at least one second service request, perform a bipartite graph matching algorithm on the bipartite graph based on at least one order allocation weight for each of the first service request and the at least one second service request for the at least one candidate service provider to generate a matched bipartite graph, and determine a target service provider of the first service request from the at least one candidate service provider according to the matched bipartite graph.

In some embodiments, the bipartite graph matching algorithm is at least one of a Hungarian algorithm, a Hopcroft-Karp algorithm, or a Kuhn-Munkres algorithm.

According to another aspect of the application, a method is provided. The method may be implemented on a computing device having at least one storage device storing a set of instructions for distributing service requests to service providers and at least one processor in communication with the at least one storage device. The method may include receiving a first service request, determining a predicted value of the first service request, and determining at least one candidate service provider for the first service request. The method may further comprise: for each of the at least one candidate service provider, obtaining one or more historical order parameters for the candidate service provider, receiving one or more expected order parameters for the candidate service provider, and determining an order allocation weight for the first service request relative to the candidate service provider based on the first service request for the service provider, the estimated value of the one or more historical order parameters, and the one or more expected order parameters. The method may further comprise: the target service provider of the first service request is determined from the at least one candidate service provider based on at least one order allocation weight for the first service request with respect to the at least one candidate service provider.

According to another aspect of the present application, a non-transitory computer readable medium is provided. The non-transitory computer readable medium may include at least one set of instructions for assigning a service request to a service provider. The at least one set of instructions, when executed by the at least one processor of the electronic terminal, instruct the at least one processor to perform the act of receiving the first service request and determine at least one candidate service provider, determining a predicted value of the first service request. The at least one set of instructions may also instruct the at least one processor to perform the actions of each of the at least one candidate service provider, obtain one or more historical order parameters for the candidate service provider, receive order parameters for one or more prospective candidate service providers, and determine an order allocation weight for each of the service requests for the at least one candidate service provider based on the one or more historical order parameters, the one or more prospective order parameters, and the predictive value. The at least one set of instructions may also instruct the at least one processor to perform an action based on the at least one order assignment of order assignment weights for service requests based on each of the at least one candidate service provider to assign the service request to one of the at least one candidate service provider.

According to another aspect of the present application, a system is provided. The system may be implemented on a computing device having at least one storage device storing a set of instructions for distributing service requests to service providers, and at least one processor in communication with the at least one storage device. The system may include an acquisition module, a predictive value determination module, a service provider determination module, a parameter acquisition module, a processing engine, and an order allocation module. The acquisition module may be configured to receive a first service request. The predictive value determination module may be configured to determine a predictive value of the first service request. The service provider determination module may be configured to determine at least one candidate service provider for the first service request. The parameter acquisition module may be configured to, for each of the at least one candidate service provider, obtain one or more historical order parameters for the candidate service provider, and receive one or more expected order parameters for the candidate service provider. The processing engine may be configured to determine an order allocation weight for the first service request relative to the candidate service provider based on the estimated value of the first service request, one or more historical order parameters of the service provider, and one or more expected order parameters. The order assignment module may be configured to determine a target service provider of the first service request from the at least one candidate service provider based on at least one order assignment weight for the first service request for the at least one candidate service provider.

Additional features will be set forth in part in the description which follows and in part will become apparent to those having ordinary skill in the art upon examination of the following and the accompanying drawings or may be learned by practice of the examples. The features of the present application may be implemented and obtained by practicing or using the various aspects of the methods, instrumentalities and combinations set forth in the detailed examples discussed below.

Drawings

The application is further described by way of exemplary embodiments. These exemplary embodiments will be described in detail with reference to the accompanying drawings. These embodiments are not limiting, wherein like reference numerals represent similar structure throughout the several views of the drawings, and wherein:

FIG. 1 is a schematic diagram of an exemplary online-to-offline service system, shown in accordance with some embodiments of the present application;

FIG. 2 is a schematic diagram of hardware and software components of an exemplary computing device shown according to some embodiments of the application;

FIG. 3 is a schematic diagram of hardware and/or software components of an exemplary mobile device shown in accordance with some embodiments of the application;

FIG. 4 is a block diagram of an exemplary processing engine shown in accordance with some embodiments of the present application;

FIG. 5 is a flow chart illustrating an exemplary flow for distributing service requests to target service providers, according to some embodiments of the application;

FIG. 6 is a flowchart illustrating an exemplary process for determining order allocation weights associated with a service provider according to some embodiments of the application;

FIG. 7 is a flowchart illustrating an exemplary process for determining a level of a service provider according to some embodiments of the application;

FIG. 8 is a flowchart illustrating an exemplary process for determining order allocation weights associated with a service provider having a first tier according to some embodiments of the application;

FIG. 9 is a flowchart illustrating an exemplary process for determining order allocation weights associated with service providers having a second tier according to some embodiments of the application;

FIG. 10 is a flowchart illustrating an exemplary process for determining order allocation weights associated with service providers having a third tier according to some embodiments of the present application;

FIG. 11 is a bipartite graph of an exemplary mismatch associated with a service request and a service provider; and

FIG. 12 is a bipartite graph of exemplary matches associated with service requests and service providers.

Detailed Description

The following description is presented to enable one of ordinary skill in the art to make and use the application and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the generic terms defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the application. Thus, the present application is not limited to the embodiments shown, but is to be accorded the widest scope consistent with the claims.

It will be appreciated that the terms "system," "engine," "unit," "module," and/or "module" as used herein

A "block" is a method of distinguishing between different components, assemblies, parts, portions, or groups. However, other expressions which achieve the same purpose may be used instead of the above terms.

The terminology used herein is for the purpose of describing particular illustrative embodiments only and is not intended to be limiting. As used in the specification and in the claims, the terms "a," "an," "the," and/or "the" are not specific to a singular, but may include a plurality, unless the context clearly dictates otherwise. It will be understood that the terms "comprises" and "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

The described and other features, characteristics, and functions of related elements of structure and methods of operation, as well as economies of manufacture and combinations of parts, will become more apparent upon consideration of the following description of the drawings, all of which form a part of this specification. It is to be understood, however, that the drawings are designed solely for the purposes of illustration and description and are not intended as a definition of the limits of the application. It should be understood that the figures are not to scale.

A flowchart is used in the present application to describe the operations performed by a system according to embodiments of the present application. It should be understood that the operations of the flow diagrams are not necessarily performed in order. Rather, the various steps may be performed in reverse order or concurrently. Further, one or more other operations may be added to these flowcharts. One or more operations are removed from these flowcharts.

The system or method of the present application may be applied to on-line to off-line systems in different environments, including terrestrial, marine, aerospace, and the like, or any combination thereof. The vehicles of the on-line to off-line system may include taxis, private cars, windmills, buses, trains, motor cars, high-speed rails, subways, ships, airplanes, spacecraft, hot air balloons, unmanned vehicles, etc., or any combination thereof.

The terms "passenger," "requestor," "service requestor," and "customer" in this disclosure may be used to refer to an individual, entity, or tool that requests or subscribes to a service, and are used interchangeably. Likewise, the terms "driver," "provider," "service provider," "server," "service party," and the like are also interchangeable and refer to a person, entity, or tool that provides or assists in providing a service. In addition, the "user" described in the present application may be a party who needs or subscribes to a service, or may be a party who provides a service or assists in providing a service. For example, the user may be a passenger, driver, operator, etc., or any combination thereof. In the present application, the terms "passenger" and "passenger terminal" are used interchangeably, and the terms "driver" and "driver terminal" are used interchangeably.

The term "service request" in the present application refers to a request initiated by a passenger, requester, service requester, customer, driver, provider, service provider, etc., or any combination thereof. The service request may be accepted by any of a passenger, a requester, a service requester, a customer, a driver, a provider, a service provider, or a provider. The service request may be either fee-based or free.

The present application relates to a system and method for distributing service requests in an online-to-offline service system. For example, the online-to-offline service system may be a car-calling service system for a car-calling service. The passenger (or service requester) may send a taxi service request to the taxi service system. The taxi service system may determine at least two service providers. For example, the system may determine at least two service providers that are capable of taking in and/or approaching a passenger. The taxi calling service system may also determine an order allocation weight corresponding to each of the at least two service providers. The service provider with the highest order allocation weight may be selected as the target service provider and the call request may be sent to a user terminal (e.g., smart mobile phone) associated with the target service provider. In some embodiments, multiple call service requests may be distributed to multiple service providers. For example, an order allocation weight between a call request and a service provider may be determined, and a bipartite graph may be constructed based on the service request, the service provider, and the order allocation weight. A match (e.g., a full match) of the bipartite graph may be searched, and a target service provider corresponding to each of the plurality of service requests may be determined based on the match of the bipartite graph. The service requests may each be sent to a corresponding service provider.

Fig. 1 is a schematic diagram of an exemplary online-to-offline service system 100, shown according to some embodiments of the present application. The online-to-offline service system 100 may include a server 110, a network 120, a service requester terminal 130, a service provider terminal 140, and a memory 150.

For example, the online-to-offline service system 100 may be an online transportation service platform for transportation services. The transportation service may include, but is not limited to, a car call service, a driver service, a express service, a carpool service, a bus service, a driver rental service, or a class service. In some embodiments, the online-to-offline service system 100 may provide other types of services including, but not limited to, a delivery service, a navigation service, a subscription service, a shopping service, a query service, and the like, or a combination thereof.

In some embodiments, the server 110 may be a single server or a group of servers. The server farm may be centralized or distributed (e.g., server 110 may be a distributed system). In some embodiments, server 110 may be local or remote. For example, server 110 may access information and/or data stored in service requester terminal 130, service provider terminal 140, and/or memory 150 via network 120. As another example, server 110 may be directly connected to service requester terminal 130, service provider terminal 140, and/or memory 150 to access stored information and/or data. In some embodiments, server 110 may execute on a cloud platform. For example only, the cloud platform may include a private cloud, a public cloud, a hybrid cloud, a cell cloud, a distributed cloud, an internal cloud, a multi-layer cloud, or the like, or any combination thereof. In some embodiments, the server 110 may be implemented on a computing device 200 as shown in FIG. 2 in the present application, the computing device 200 having one or more components.

In some embodiments, server 110 may contain a processing engine 112. The processing engine 112 may process information and/or data related to the service request to perform one or more of the functions disclosed herein. For example, the processing engine 112 may receive a service request from the service requester terminal 130 and determine at least one candidate service provider based on the service request. The processing engine 112 may also select a target service provider from the at least one candidate service provider and send a service request to the target service provider terminal 140 associated with the target service provider. As another example, the processing engine 112 may receive at least two service requests from at least two service requester terminals 130. The processing engine 112 may also determine at least two service providers and assign at least two service requests to at least two service provider terminals 140 associated with the at least two service providers on a one-to-one, one-to-many, or many-to-one basis. In some embodiments, processing engine 112 may include one or more processing engines (e.g., a single core processing engine or a multi-core processor). By way of example only, the processing engine 112 may include a Central Processing Unit (CPU), an Application Specific Integrated Circuit (ASIC), a special instruction set processor (ASIP), an image processor (GPU), a physical arithmetic processing unit (PPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a controller, a microcontroller unit, a Reduced Instruction Set Computer (RISC), a microprocessor, or the like, or any combination thereof. In some embodiments, processing engine 112 may implement one or more of the functions described in this disclosure via its logic circuitry.

The network 120 may facilitate the exchange of information and/or data. In some embodiments, one or more components of the online-to-offline service system 100 (e.g., the server 110, the service requester terminal 130, the service provider terminal 140, and the memory 150) may send information and/or data to other components of the online-to-offline service system 100 via the network 120. For example, processing engine 112 may receive a service request from service requester terminal 130 via network 120. As another example, the processing engine 112 may send a service request to the service provider terminal 140 via the network 120. In some embodiments, network 120 may be any form of wired or wireless network, or any combination thereof. By way of example only, the network 120 may include a cable network, a wired network, a fiber optic network, a telecommunications network, an internal network, the internet, a Local Area Network (LAN), a Wide Area Network (WAN), a Wireless Local Area Network (WLAN), a Metropolitan Area Network (MAN), a Public Switched Telephone Network (PSTN), a bluetooth network, a ZigBee network, near Field Communication (NFC), and the like, or any combination thereof. In some embodiments, network 120 may include one or more network access points. For example, the network 120 may include wired or wireless network access points, such as base stations and/or Internet switching points 120-1, 120-2, …, through which one or more components of the online-to-offline service system 100 may connect to the network 120 to exchange information and/or data.

In some embodiments, the passenger may be the owner of the service requester terminal 130. In some embodiments, the owner of the service requester terminal 130 may be a person other than a passenger. For example, the owner a of the service requester terminal 130 may use the service requester terminal 130 to send a service request for the passenger B or to receive service confirmation and/or information or instructions from the server 110. In some embodiments, the service provider may be a user of the service provider terminal 140. In some embodiments, the user of the service provider terminal 140 may be a person other than the service provider. For example, user C of service provider terminal 140 may use service provider terminal 140 to receive a service request for user D and/or to receive information or instructions from server 110. In some embodiments, "requestor" and "requestor terminal" are used interchangeably, and "provider" and "provider terminal" are used interchangeably.

In some embodiments, the service requester terminal 130 may include a mobile device 130-1, a tablet computer 130-2, a laptop computer 130-3, a vehicle-mounted device 130-4, or the like, or any combination thereof. In some embodiments, the mobile device 130-1 may include a smart home device, a wearable device, a smart mobile device, a virtual reality device, an augmented reality device, or the like, or any combination thereof. In some embodiments, the smart home devices may include smart lighting devices, smart appliance control devices, smart monitoring devices, smart televisions, smart video cameras, interphones, and the like, or any combination thereof. In some embodiments, the wearable device may include a smart wristband, a smart foot pedal, smart glasses, a smart helmet, a smart watch, a smart garment, a smart backpack, a smart accessory, etc., or any combination thereof. In some embodiments, the smart mobile device may include a smart phone, a Personal Digital Assistant (PDA), a gaming apparatus, a navigation device, a point of sale (POS) device, or the like, or any combination thereof. In some embodiments, the virtual reality device and/or augmented reality device may include a virtual reality helmet, virtual reality glasses, virtual reality eyepieces, augmented reality helmet, augmented reality glasses, augmented reality eyepieces, and the like, or any combination thereof. For example, the virtual reality device and/or the augmented reality device may include Google ^TM Glass, oculus lift, holoLens, gear VR, etc. In some embodiments, the in-vehicle device 130-4 may include an on-board computer, an on-board television, or the like. In some embodiments, service requester terminal 130May be a device with positioning technology (e.g., via a Global Positioning System (GPS) chipset) for locating the position of the passenger and/or service requester terminal 130.

The service provider terminal 140 may include a plurality of service provider terminals 140-1, 140-2. In some embodiments, service provider terminal 140 may be similar to or the same as service requester terminal 130. In some embodiments, the service provider terminal 140 may be customized to enable on-line to off-line transport services. In some embodiments, the service provider terminal 140 may be a device with positioning technology (e.g., through a Global Positioning System (GPS) chipset) for locating the service provider and/or the service provider terminal 140. In some embodiments, service requester terminal 130 and/or service provider terminal 140 may communicate with another location device to determine the location of the passenger, service requester terminal 130, service provider, and/or service provider terminal 140. In some embodiments, the service requester terminal 130 and/or the service provider terminal 140 may periodically send the positioning information to the server 110. In some embodiments, the service provider terminal 140 may also periodically send the availability status to the server 110. The availability status may indicate whether the service provider terminal 140 is available to accept the service request. For example, the service requester terminal 130 and/or the service provider terminal 140 may transmit the location information and the available status to the server 110 every 30 minutes. As another example, the service requester terminal 130 and/or the service provider terminal 140 may send the location information and the availability status to the server 110 each time the user logs into a mobile application related to an online-to-offline transport service. In some embodiments, the server 110 may send a connection request to a terminal (e.g., service requester terminal 130 and/or service provider terminal 140) that is available to accept the service request and establish a connection with the terminal after the terminal accepts the connection request. In some embodiments, the terminal may send a connection request to the server and establish a connection with the server after the server accepts the connection request. It should be noted that communication between a server and a terminal may refer to direct communication between them or communication between applications installed on them.

Memory 150 may store data and/or instructions. In some embodiments, the memory 150 may store material obtained from the service requester terminal 130 and/or the service provider terminal 140. In some embodiments, the memory 150 may store data and/or instructions for execution or use by the server 110 to perform the exemplary methods of the present disclosure. In some embodiments, memory 150 may include mass storage, removable storage, volatile read-write memory, read-only memory (ROM), and the like, or any combination thereof. Exemplary mass storage devices may include magnetic disks, optical disks, solid state disks, and the like. Exemplary removable memory may include flash drives, floppy disks, optical disks, memory cards, compact disks, magnetic tape, and the like. Exemplary volatile read-write memory can include Random Access Memory (RAM). Exemplary RAM may include Dynamic RAM (DRAM), double rate synchronous dynamic RAM (DDR SDRAM), static RAM (SRAM), thyristor RAM (T-RAM), zero capacitance RAM (Z-RAM), and the like. Exemplary ROMs may include Mask ROM (MROM), programmable ROM (PROM), erasable programmable ROM (PEROM), electrically Erasable Programmable ROM (EEPROM), compact disk ROM (CD-ROM), and digital versatile disk ROM, among others. In some embodiments, the memory 150 may be implemented on a cloud platform. For example only, the cloud platform may include a private cloud, a public cloud, a hybrid cloud, a cell cloud, a distributed cloud, an internal cloud, a multi-layer cloud, or the like, or any combination thereof.

In some embodiments, the memory 150 may be connected to the network 120 to communicate with one or more components of the online-to-offline service system 100 (e.g., the server 110, the service requester terminal 130, or the service provider terminal 140). One or more components of the online-to-offline service system 100 may access data or instructions stored in the memory 150 via the network 120. In some embodiments, the memory 150 may be directly connected or in communication with one or more components of the online-to-offline service system 100 (e.g., the server 110, the service requester terminal 130, the service provider terminal 140). In some embodiments, memory 150 may be part of server 110.

In some embodiments, one or more components of the online-to-offline service system 100 (e.g., server 110, service requester terminal 130, service provider terminal 140) may have permission to access memory 150. In some embodiments, one or more components of the online-to-offline service system 100 may read and/or modify information related to passengers, service providers, and/or the public when one or more conditions are met. For example, after the service is completed, server 110 may read and/or modify information of one or more passengers. For another example, after the service is completed, server 110 may read and/or modify information for one or more service providers.

In some embodiments, the exchange of information of one or more components of the online-to-offline service system 100 may be initiated by a request service. The object of the service request may be any product. In some embodiments, the product may include food, medicine, merchandise, chemical products, appliances, clothing, cars, houses, luxury goods, etc., or any combination of the foregoing examples. In some embodiments, the product may include a service product, a financial product, a knowledge product, an internet product, or the like, or any combination thereof. The internet products may include personal host products, web products, mobile internet products, business host products, embedded products, and the like, or any combination thereof. The mobile internet product may be software, a program, a system, etc. applied on the mobile terminal, or any combination thereof. The mobile terminal may include a tablet computer, notebook computer, mobile phone, personal Digital Assistant (PDA), smart watch, point of sale (POS) device, in-vehicle computer, in-vehicle television, wearable device, etc., or any combination thereof. For example, the product may be any software and/or application used on a computer or mobile phone. The software and/or applications may be related to social, shopping, transportation, entertainment, learning, investment, etc., or any combination thereof. In some embodiments, the transportation related software and/or applications may include travel software and/or applications, transportation scheduling software and/or applications, map software and/or applications, and the like. For the vehicle scheduling software and/or applications, the vehicle may be a horse, a carriage, a human powered vehicle (e.g., a wheelbarrow, a bicycle, a tricycle, etc.), an automobile (e.g., a taxi, a bus, a private car, etc.), a train, a subway, a watercraft, an aircraft (e.g., an airplane, a helicopter, a space plane, a rocket, a hot air balloon, etc.), or any combination thereof.

Those of ordinary skill in the art will understand that when performed by an element (or component) of the online-to-offline service system 100, the element may be performed by an electrical signal and/or an electromagnetic signal. For example, when the service requester terminal 130 transmits a service request to the server 110, the processor of the service requester terminal 130 may generate an electrical signal encoding the request. The processor of the service requester terminal 130 may then send the electrical signal to the output port. If the service requester terminal 130 communicates with the server 110 via a wired network, the output port may be physically connected to a cable that may further transmit the electrical signal to an input port of the server 110. If the service requester terminal 130 communicates with the server 110 over a wireless network, the output port of the service requester terminal 130 may be one or more antennas that may convert the electrical signals into electromagnetic signals. Similarly, the service provider terminal 140 may accept instructions and/or service requests from the server 110 by accepting electrical or electromagnetic signals. In an electronic device, such as service requester terminal 130, service provider terminal 140, and/or server 110, when its processor processes instructions, issues instructions, and/or performs operations, the instructions and/or the operations are performed by electrical signals. For example, when the processor retrieves or acquires data from the storage device, an electrical signal may be sent to a read/write device of the storage device that may read or write structured data in the storage device. The structured data may be transmitted to the processor in the form of electrical signals via a bus of the electronic device. Further, an electrical signal may refer to an electrical signal, a series of electrical signals, and/or a plurality of discrete electrical signals.

Fig. 2 is a schematic diagram of exemplary computing device 200 hardware and software components shown in accordance with some embodiments of the present application, on which computing device 200 server 110, service requester terminal 130, and/or service provider terminal 140 may be implemented. For example, the processing engine 112 may be implemented on the computing device 200 and perform the functions of the processing engine 112 disclosed herein.

In some embodiments, computing device 200 may be a special purpose computer. The computing device 200 may be used to implement an online-to-offline service system of the present application. Computing device 200 may implement any of the components of the online-to-offline service described above. In fig. 1 to 2, only one such computer device is shown for convenience. Those of ordinary skill in the art will appreciate that the computer functions associated with the online-to-offline services described herein may be implemented in a distributed fashion across a number of similar platforms to distribute processing load.

For example, computing device 200 may include a network interface 240 to connect to or with a network (e.g., network 120) to facilitate data communications. The computing device 200 may also include a central processing unit (CPU or processor) 220 for executing program instructions in the form of one or more processors. An exemplary computer platform may include an internal communication bus 210, a program storage device, and memory 260. Memory 260 may take different forms, such as a disk, read Only Memory (ROM), or Random Access Memory (RAM), for example, for various data files processed and/or transferred by computing device 200. Computing device 200 may also include program instructions stored in ROM, RAM, and/or other types of non-transitory storage media that are executed by CPU/processor 220. The methods and/or processes of the present application may be implemented as program instructions. Computing device 200 may also include input/output components 250 that support input/output between the computer and other components therein. Computing device 200 may also receive programming and data over a network communication.

For illustration only, only one CPU/processor 220 is depicted in computing device 200. It should be noted, however, that the computing device 200 of the present application may also include multiple CPUs/processors. Thus, operations and/or method steps described in the present application as being performed by one CPU/processor 220 may also be performed by multiple CPUs/processors in combination or separately. For example, if in the present application, the processor of computing device 200 performs steps a and B, it should be understood that steps a and B may also be performed jointly or independently by two different processors of computing device 200 (e.g., a first processor performing step a, a second processor performing step B, or both the first and second processors jointly performing steps a and B). The power supply 230 may provide power to components of the computing device 200.

Fig. 3 is a schematic diagram of exemplary hardware and/or software components of an exemplary mobile device 300 on which a user terminal may be implemented, according to some embodiments of the application. As shown in FIG. 3, mobile device 300 may include a communication platform 310, a display 320, a Graphics Processing Unit (GPU) 330, a Central Processing Unit (CPU) 340, I/O350, memory 360, and storage 390. In some embodiments, any other suitable component, including but not limited to a system bus or controller (not shown), may also be included in the mobile device 300. In some embodiments, mobile operating system 370 (e.g., iOS ^TM 、Android ^TM Windows Phone, etc.) and one or more application programs 380 may be loaded from the storage 390 to the memory 360 and executed by the CPU 340. Application 380 may include a browser or any other suitable mobile application for receiving and presenting information related to online-to-offline services or other information from processing engine 112. User interaction with the information stream may be accomplished through I/O350 and provided to processing engine 112 and/or other components of online-to-offline service system 100 through network 120. In some embodiments, the mobile device 300 may send (or receive) a connection request to the server 110 via the network 120 and establish a connection with the server 110 after the server 110 (or the mobile device 300) accepts the connection request. After establishing a connection between the server 110 and the mobile device 300, the server 110 may communicate with an application 380 installed on the mobile device 300 to send or receive information or data (e.g., information of a service request, a service provider, or a service requester).

FIG. 4 is a block diagram of an exemplary processing engine shown in accordance with some embodiments of the present application. The processing engine 112 may include a service provider determination module 410, a pre-estimated value determination module 420, a parameter acquisition module 430, a first order allocation weight determination module 440, an order allocation module 450, and a second order allocation weight determination module 460. Each of the modules described above may be a hardware circuit designed to perform certain actions, for example, according to a set of instructions stored in one or more storage media, and/or any combination of hardware circuits and one or more storage media.

The service provider determination module 410 may be configured to determine at least one candidate service provider (also referred to as a service provider) associated with a service request received from a service requester. The service request may include a call service request, a food delivery service request, and the like. In some embodiments, the service provider determination module 410 may determine at least one candidate service provider based on the location of the service requester. For example, the service provider determination module 410 may determine some or all of the service providers in the area around the location of the service requester as candidate service providers. The area may be a circular area centered on the location of the service requester and having a radius of a predetermined distance. Alternatively, the area may be a rectangular or square area having the location of the service requester as its center.

The predictive value determination module 420 may be configured to determine a predictive value of a service request from a service requester. In some embodiments, the predictive value determination module 420 may determine the predictive value of the service request based on the predictive price of the service request. Alternatively, the predictive value determination module 420 may determine the predictive value of the service request based on various parameters.

Take the service of calling a car as an example. Parameters used to determine the estimated value of the service request may include an estimated price of the service request, an estimated length of time to complete the service request, an increase in price of the service request, traffic conditions (e.g., congestion level) corresponding to a route of the service request, a response probability of the service provider (e.g., a ratio between the number of service providers responding to the service request and the number of service providers receiving the service request), a cancellation probability of the service provider after responding to the service request, or an estimated length of time before receiving the service request (i.e., a time taken for the service provider to reach a boarding location of the service requester), etc.

The parameter acquisition module 430 may be configured to acquire one or more historical order parameters and one or more expected order parameters associated with each of the at least one candidate service provider. In some embodiments, one or more historical order parameters may be determined based on historical orders that were completed by the candidate service provider in the past, stored in a storage device (e.g., memory 150) or database. One or more of the expected order parameters may be set automatically by the online-to-offline service system 100 or manually by at least one candidate service provider.

The first order allocation weight determination module 440 may be configured to determine the order allocation weight based on the revenue bias of the candidate service provider, one or more historical order parameters, one or more anticipated order parameters, and/or the estimated value of the service request. In some embodiments, when the historical online time period T of the candidate service provider is greater than or equal to the online time threshold, the first order allocation weight determination module 440 may be used to determine an order allocation weight associated with the candidate service provider. However, when the historical online time period T of the candidate service provider is less than the online time threshold, the second order allocation weight determination module 460 may be employed to determine an order allocation weight associated with the candidate service provider.

In some embodiments, the first order allocation weight determination module 440 may include a deviation determination unit 442, a comparison unit 444, and a determination unit 446. Each unit may be a hardware circuit designed to perform certain actions, for example, according to a set of instructions stored in one or more storage media and/or any combination of hardware circuits and one or more storage media.

The deviation determination unit 442 may be configured to determine a revenue deviation for each of the at least one candidate service provider based on the one or more historical order parameters and the one or more expected order parameters. The revenue deviation may represent a deviation or difference between the actual revenue and the expected revenue of the candidate service provider. A higher revenue bias may represent a larger difference between the actual revenue and the expected revenue of the candidate service provider.

In some embodiments, the deviation judging unit 442 may include a judging subunit and a first determining subunit (not shown in the figure). The determination subunit may be configured to determine whether the historical online time duration T is greater than or equal to an online time threshold. When the historical online time period T is greater than or equal to the online time threshold, the first determination subunit may be configured to determine a revenue bias for the candidate service provider based on one or more historical order parameters and/or one or more expected order parameters.

When the historical online time period T of the candidate service provider is greater than or equal to the online time threshold, the deviation determination unit 442 may determine a revenue deviation for the service based on one or more historical order parameters and/or one or more expected order parameters.

The comparison unit 444 may be configured to compare the revenue deviation of each of the at least one candidate service provider with at least one preset revenue threshold.

The determination unit 446 may be configured to determine an order allocation weight for the service request based on the comparison, one or more historical order parameters, one or more expected order parameters, and/or a predicted value of the service request.

In some embodiments, the determining unit 446 may include a first price level determining subunit, a first acquisition subunit, and a second determining subunit (not shown in the figures). The first value class determination subunit may be configured to determine which value class the service request belongs to based on the estimated value V of the service request and two or more value ranges corresponding to the two or more value classes. The first acquisition subunit may be configured to acquire the history proportion R and the expected proportion R corresponding to the value class to which the service request belongs. The second determination subunit may be configured to determine an order allocation weight for the service request for each of the at least one candidate service provider based on the historical scale R, the expected scale R, the one or more historical order parameters, the one or more expected order parameters, and/or the estimated value V.

In some embodiments, the determining unit 446 may include a second value level determining subunit, a second acquisition subunit, and a third determining subunit (not shown in the figures). When the revenue deviation is not less than the first revenue threshold and is less than the second revenue threshold, the second value level determination subunit may be configured to determine which value level the service request belongs to based on the estimated value V of the service request. The second obtaining subunit may be configured to obtain the history proportion R and the expected proportion R corresponding to the value level to which the service request belongs, and obtain the history proportion R 'and the expected proportion R' corresponding to at least one value level higher than the value level to which the service request belongs. The third determination subunit may be configured to determine an order allocation weight for the order for each of the at least one candidate service provider based on the historical scale R, the expected scale R, the historical scale R ', the expected scale R', the one or more historical order parameters, the one or more expected order parameters, and the predicted value V.

In some embodiments, the determination unit 446 may include a third acquisition subunit and a fourth determination subunit (not shown in the figures). The third acquisition subunit may be configured to acquire a history proportion { r }, corresponding to each value level ₁ ,…,r _n Sum of expected proportions { R } ₁ ,…,R _n }. The fourth determination subunit may be configured to be based on the history proportion { r ₁ ,…,r _n Desired ratio { R } ₁ ,…,R _n The method may include determining an order allocation weight for an order for each of the at least one candidate service provider, determining one or more historical order parameters, one or more expected order parameters, and/or a predicted value V of the service request.

The order assignment module 450 may be configured to assign a service request to a target service provider of the at least one candidate service provider. In some embodiments, order allocation module 450 may be configured to allocate two or more service requests to two or more service providers. In some embodiments, the order allocation module 450 may further include a construction unit 451, an initialization unit 452, a matching unit 453, a processing unit 454, and an allocation unit 455. Each element may be a hardware circuit designed to perform certain actions, for example, according to a set of instructions stored in one or more storage media, and/or any combination of hardware circuits and one or more storage media.

The construction unit 451 may be configured to construct a bipartite graph based on at least one service requester, at least one candidate service provider, and at least one order allocation weight.

The initialization unit 452 may be configured to initialize values of one or more vertices in the bipartite graph.

The matching unit 453 may be configured to find a match (e.g., a complete match) of the bipartite graph using a hungarian algorithm.

The processing unit 454 may be configured to modify the values of one or more vertices in the bipartite graph if no match is found, and to continuously find matches of the bipartite graph using the hungarian algorithm until a match is found. The matching may satisfy at least one of the following conditions: each service request corresponds to only one service provider; each service provider corresponds to only one service request; as many service requests as possible find matching service providers; and assigning weights corresponding to the matched service requests and orders of the service providers as high as possible.

The allocation unit 455 may be configured to allocate a service request of the service requester to a target service provider of the at least one candidate service provider based on at least one order allocation weight of the at least one candidate service provider. The allocation unit 455 may also be configured to allocate at least two service requests to at least two service providers based on the matching (e.g., perfect matching) of the bipartite graph.

The second order allocation weight determination module 460 may be configured to determine an order allocation weight for the service request for each of the at least one candidate service provider based on one or more historical order parameters, one or more anticipated order parameters, and/or a predicted value of the service request when the historical online time period T of the service provider of the at least one candidate service provider is less than the online time threshold.

It should be noted that the above description of processing engine 112 is provided for illustrative purposes and is not intended to limit the scope of the present application. Various modifications and changes in form and detail of the application of the above-described methods and systems may be made by those skilled in the art without departing from the principles of the present application. However, such variations and modifications are also within the scope of the present application. In some embodiments, the processing engine 112 may include one or more other modules. For example, the processing engine 112 may include a storage module for storing data generated by modules in the processing engine 112. In some embodiments, any two modules may be combined into a single module, and any one module may be split into two or more units.

Fig. 5 is a flow chart of an exemplary flow for distributing service requests to target service providers, according to some embodiments of the application. In some embodiments, flow 500 may be implemented as a set of instructions (e.g., an application) stored in memory 150, memory 260, or memory 390. The CPU 210, CPU 340, processing engine 112, and/or the modules in fig. 4 may execute the set of instructions, and when executing the instructions, the CPU 210, CPU 340, processing engine 112, and/or the modules in fig. 4 may be configured to perform the flow 500. The steps of the illustrated flow presented below are intended to be illustrative. In some embodiments, the process 500 may be accomplished by one or more additional operations not described and/or omitting one or more of the operations discussed herein. In addition, the order of the operations of the flow as shown in fig. 5 and described below is not intended to be limiting.

In step 510, the processing engine 112 may receive a service request. The service request may include a call service request, a food delivery service request, and the like. In some embodiments, after the server 110 is connected to the service requester terminal 130, the processing engine 112 may receive a service request from the service requester terminal 130. The service requester terminal 130 may send a connection request to the server 110, and if the server accepts the connection request, a connection may be established with the service requester terminal 130. The communication between the server and the terminal may be a direct communication between them or a communication between applications thereof.

In step 520, the processing engine 112 (e.g., the service provider determination module 410) may determine at least one candidate service provider for the service request. In some embodiments, the processing engine 112 may determine at least one candidate service provider based on the location of the service requester. For example, the processing engine 112 may determine some or all of the service providers in the area around the location of the service requester as candidate service providers. The area may be a circular area centered on the location of the service requester and having a radius of a predetermined distance. Alternatively, the area may be a rectangular or square area having the location of the service requester as its center. The above description of determining the region of one or more candidate service requesters is for illustrative purposes only, and the shape and/or size of the region is not limiting of the application.

In step 530, the processing engine 112 (e.g., the predictive value determination module 420) may determine the predictive value of the service request. In some embodiments, the processing engine 112 (e.g., the predictive value determination module 420) may determine the predicted value of the service request based on the predicted price of the service request. In some embodiments, the processing engine 112 (e.g., the predictive value determination module 420) may determine the predictive value of the service request based on various parameters.

Take the service of calling a car as an example. Parameters used to determine the estimated value of a service request may include an estimated price of the service request, an estimated length of time to complete the service request, an increase in price of the service request (e.g., price rise in peak hours, small fee), traffic conditions (e.g., congestion level) corresponding to a route of the service request, a response probability of the service provider (e.g., a ratio between the number of service providers responding to the service request and the number of service providers receiving the service request), a cancellation probability of the service provider after responding to the service request, or an estimated length of time before receiving the service request (i.e., a length of time for the service provider to reach a service requester boarding location), etc.

For example, the processing engine 112 may determine the predicted value of the service request as: the response probability of the driver is w1, the estimated price of the service request is +w2, the cancellation probability of the driver after the service request is responded is +w3, wherein w1 is the weight of the response probability of the driver, w2 is the weight of the estimated price of the service request, and w3 is the weight of the cancellation probability of the service provider after the service request is responded. For another example, the processing engine 112 (e.g., the predictive value determination module 420) may determine the predictive value of the service request by dividing the predictive value of the service request by a sum of the predicted length of time before receiving the service request and the predicted length of time of the service request. It should be noted that the above description of determining the estimated value of a service request is for illustrative purposes only and is not intended to limit the scope of the present application.

In step 540, the processing engine 112 (e.g., the parameter acquisition module 430) may obtain one or more historical order parameters associated with each of the at least one candidate service provider. In some embodiments, one or more historical order parameters may be determined based on historical orders that were completed by the candidate service provider in the past, stored in a storage device (e.g., memory 150) or database.

Take the service of calling a car as an example. The one or more historical order parameters may include a historical online time period T, a total value S of the historical orders (all of the historical orders completed by the service provider, or the historical orders completed within a period), a value structure of the historical orders, or the like, or any combination thereof. In some embodiments, the historical online time period T may include only the length of time for the service provider (e.g., driver) that performed the historical service request. Alternatively, the historical online time period T may include a length of time to wait for the historical service request and a length of time to execute the historical service request. The total value S of the historical orders may represent the total value of all historical orders completed by the service provider (e.g., the driver), or the total revenue earned by the service provider. The value structure of the historical order may represent a historical proportion of the different values of the historical order and may be determined based on the value of the historical order. For example, the value structure of a historical order may include n value classes and a ratio r, each ratio corresponding to one of the n value classes. Each of the n value classes may include a value range. The value ranges corresponding to the n value classes may or may not overlap. If the value of the historical order falls within a value range corresponding to a value class, the historical order may be divided into one of n value classes. The history proportion r corresponding to each of the n value classes may be determined by dividing the number of history orders belonging to the value class by the total number of history orders. For example, the value structure of a historical order may include three value ranks, namely value ranks A, B and C. The historical orders may be categorized into one of three categories according to the range of values within which the values of the historical orders fall. For example, the processing engine 112 may specify a first value threshold and a second value threshold. The second threshold value may be greater than the first threshold value, and both threshold values may be greater than zero. Historical orders having a value below a first value threshold may be classified as a first value level (e.g., value level C). Historical orders having a value greater than or equal to the first value threshold and less than the second value threshold may be classified as a second value tier (e.g., value tier B). Historical orders having a value greater than or equal to the second value threshold may be classified as a third value level (e.g., value level a). The historical proportion r corresponding to each of the three value classes may be determined by dividing the number of historical orders belonging to the value class by the total number of historical orders. For example, the value structure of the historical order may include a historical proportion r of the first price level of 20%, a historical proportion r of the second price level of 60%, and/or a historical proportion r of the third price level of 20%.

In step 550, the processing engine 112 (e.g., the parameter acquisition module 430) may obtain one or more expected order parameters associated with each of the at least one candidate service provider. Taking a taxi taking service as an example. The one or more expected order parameters may include expected revenue per unit time P, a value structure of the expected order, or the like, or any combination thereof. The expected revenue per unit time P may represent the expected revenue per unit time (e.g., per hour) of the service provider (e.g., driver). The value structure of the expected order may represent an expected value structure of a service provider (e.g., driver). The value structure of the prospective order may include a value for n value classes and n prospective proportions R corresponding to the n value classes. For example, the value structure of the service provider's intended order may include an intended proportion R of the first value level of 30%, an intended proportion R of the second value level of 60%, and an intended proportion of the third value level of 10%.

In some embodiments, one or more of the intended order parameters may be set automatically by the online-to-offline service system 100 or manually by the service provider. For example, a questionnaire related to the expected order parameters may be provided to two or more service providers and statistically analyzed to obtain one or more expected order parameters. In some embodiments, the online-to-offline service system 100 may determine a higher expected revenue per unit time for service providers having higher service levels.

In step 560, the processing engine 112 may determine an order allocation weight for the service request for each of the at least one candidate service provider based on the estimated value of the service request, one or more historical order parameters of the service provider, and/or one or more expected order parameters. In some embodiments, when the service provider's historical online time period T is greater than or equal to the online time threshold, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine the order allocation weight based on the service provider's revenue bias, one or more historical order parameters, one or more anticipated order parameters, and/or the estimated value of the service request. In some embodiments, when the service provider's historical online time period T is less than the online time threshold, the processing engine 112 (e.g., the second order allocation weight determination module 460) may determine the order allocation weight based on one or more historical order parameters, one or more anticipated order parameters, and/or the estimated value of the service request. A detailed description of determining order allocation weights may be found elsewhere in the present application (e.g., fig. 6 and 8-10 and descriptions thereof).

In step 570, the processing engine 112 (e.g., the order assignment module 450) may determine a target service provider of the service request from the at least one candidate service provider based on the at least one order assignment weight for the service request for the at least one candidate service provider. In some embodiments, the processing engine 112 (e.g., order assignment module 450) may determine the candidate service provider with the highest order assignment weight as the target service provider for the service request. In some embodiments, the processing engine 112 (e.g., order assignment module 450) may determine the target service provider of the service request by looking for a match (e.g., a perfect match) of the bipartite graph related to the service request, the service provider, and the order assignment weights of the service request related to the service provider. A detailed description of a search for bipartite graph matches may be found elsewhere in the present application (e.g., fig. 11 and 12, and descriptions thereof).

In step 580, the processing engine 112 may send the service request to the target service provider. In some embodiments, the processing engine 112 may send a service request to a terminal of a target service provider (e.g., the service provider terminal 140). For example, the processing engine 112 may communicate with a service providing application executing on the terminal through a port of the terminal of the target service provider, displaying at least a portion of the information related to the service request on a Graphical User Interface (GUI) of the terminal of the target service provider. Taking the call service as an example, the information related to the service request may include a boarding location of the service requester, a departure time of the service request, a destination of the service request, and the like.

FIG. 6 is a flowchart illustrating an exemplary process for determining order allocation weights associated with a service provider according to some embodiments of the application. In some embodiments, flow 600 may be implemented as a set of instructions (e.g., an application) stored in memory 150, memory 260, or memory 390. The CPU210, CPU 340, processing engine 112, and/or the modules in fig. 4 may execute the set of instructions, and when executing the instructions, the CPU210, CPU 340, processing engine 112, and/or the modules in fig. 4 may be configured to execute the flow 600. The operations of the illustrated flow presented below are intended to be illustrative. In some embodiments, flow 600 may be accomplished by one or more of the above additional operations not described and/or omitting one or more of the operations discussed herein. In addition, the order of the operations of the flow shown in fig. 6 and described below is not intended to be limiting. In some embodiments, step 560 of flowchart 500 may be performed according to flowchart 600.

In step 610, the processing engine 112 (e.g., the parameter acquisition module 430) may obtain the historical online time period T of the service provider (e.g., the candidate service provider). In some embodiments, the historical online time period T may include only the length of time for the service provider (e.g., driver) that performed the historical service request. Alternatively, the historical online time period T may include a length of time to wait for the historical service request and a length of time to execute the historical service request.

In step 620, the processing engine 112 may obtain an online time threshold. In some embodiments, the online time threshold may be a default threshold set by server 110 or retrieved from network 120 or memory 150. The on-line time threshold may be 100 hours, 200 hours, 500 hours, 1000 hours, etc.

In step 630, the processing engine 112 may determine whether the service provider's historical online time duration T is less than an online time threshold. In response to determining that the service provider's historical online time period T is less than the online time threshold, flow 600 may proceed to step 640; otherwise, flow 600 may proceed to step 660.

In step 640, the processing engine 112 (e.g., the second order allocation weight determination module 460) may determine the expected revenue for the service provider. In some embodiments, the processing engine 112 (e.g., the second order allocation weight determination module 460) may determine the expected revenue of the service provider by multiplying the expected revenue per unit time P of the service provider by the expected time T of the service request.

In step 650, the processing engine 112 (e.g., the second order allocation weight determination module 460) may determine an order allocation weight for the service request of the service provider based on the expected revenue, the total value S of the historical orders, and the predicted value V of the service request. In some embodiments, the processing engine 112 (e.g., the second order allocation weight determination module 460) may determine an order allocation weight for the service request of the service provider based on a fourth weight determination algorithm. The fourth weight determination algorithm may be expressed as follows:

Where P represents the expected revenue per unit time of the service provider; t represents the historical online time of the service provider; s represents the total value of all historical orders of the service provider; v represents the estimated value of the service request.

In step 660, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine a revenue bias for the service provider based on the service provider' S historical online time period T, the expected revenue per unit time P, and the total value of the historical orders S. The revenue deviation may represent a deviation or difference between the actual revenue and the expected revenue of the service provider. Higher revenue deviations may represent a larger difference between actual and expected revenue for the service provider.

In some embodiments, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine the revenue bias for the service provider based on the service provider' S historical online time period T, the expected revenue per unit time P, and/or the total value S of the historical orders using a predetermined revenue bias algorithm. The predetermined revenue deviation algorithm may be expressed as follows:

where P represents the expected revenue per unit time for the service provider; t represents the historical online time of the service provider; s represents the total value of all historical orders for the service provider.

In step 670, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine a ranking of the service provider based on the revenue deviation and the at least one revenue threshold. A detailed description of the determination of the level of service provider may be found elsewhere in the present application (e.g., fig. 7 and its description).

In step 680, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine order allocation weights for service requests for the service provider based on the grade of the service provider, the estimated value V of the service request, historical order parameters of the service provider, and/or expected order parameters. A detailed description of the determination of order allocation weights for different levels of service providers may be found elsewhere in the present application (e.g., fig. 8-10 and descriptions thereof).

It should be noted that the above description of flow 600 is for illustrative purposes only and is not intended to limit the scope of the present application. Various modifications and changes in form and detail of the application of the above-described methods and systems may be made by those skilled in the art without departing from the principles of the present application. However, such variations and modifications are also within the scope of the present application. For example, step 630 may be omitted and steps 640-650 or steps 660-680 may be performed regardless of whether the service provider's historical online time period is less than, equal to, or greater than an online time threshold.

Fig. 7 is a flow chart illustrating an exemplary process for determining a level of a service provider according to some embodiments of the application. In some embodiments, flow 700 may be implemented as a set of instructions (e.g., an application) stored in memory 150, memory 260, or memory 390. CPU 210, CPU 340, processing engine 112, and/or the modules in fig. 4 may execute a set of instructions, and when executing instructions, CPU 210, CPU 340, processing engine 112, and/or the modules in fig. 4 may be configured to perform flow 700. The operations of the illustrated flow presented below are intended to be illustrative. In some embodiments, flow 700 may be accomplished by one or more of the above additional operations not described and/or omitting one or more of the operations discussed herein. In addition, the order of the flow operations shown in fig. 7 and described below is not limiting. In some embodiments, steps 660 and 670 of flow 600 may be performed according to flow 700.

In step 710, the processing engine 112 may obtain revenue bias for the service provider (e.g., candidate service provider). The revenue bias for the service provider may be determined according to step 660 of flow 600 in fig. 6.

In step 720, the processing engine 112 may obtain a first revenue threshold and a second revenue threshold. In some embodiments, the first revenue threshold and the second revenue threshold may be set by the server 110, and the first revenue threshold may be lower than the second revenue threshold.

In step 730, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine whether the revenue deviation for the service provider is less than a first revenue threshold. If the processing engine 112 determines that the revenue deviation is less than the first revenue threshold, the flow 700 may proceed to step 740; otherwise, flow 700 may proceed to step 750. In step 740, the processing engine 112 may determine that the service provider has a first tier. If the service provider is determined to have a first ranking, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine the order allocation weight of the service provider according to the flow 800 depicted in FIG. 8.

In step 750, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine whether the revenue deviation is less than a second revenue threshold. If the processing engine 112 determines that the revenue deviation is less than the second revenue threshold, the flow 700 may proceed to step 760; otherwise, flow 700 may proceed to step 770.

In step 760, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine that the service provider has a second tier. Processing engine 112 may also determine the order allocation weights for the service provider according to flow 900 depicted in fig. 9 of the present application.

In step 770, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine that the service provider has a third tier. Processing engine 112 may also determine the order allocation weights for the service provider according to flow 1000 depicted in FIG. 10 of the present application.

In some embodiments, the order allocation weight for a similar service provider is greatest when determined to be of the third tier, intermediate when determined to be of the second tier, and smallest when determined to be of the first tier. In some embodiments, the service provider is also determined to have the first rating if the revenue deviation for the service provider is negative or zero. Alternatively, if the revenue bias of the service provider is negative or zero, the service provider may be determined to have a fourth tier (not shown), and the order allocation weight of the service provider at the fourth tier may be lower than the order allocation weight of a similar service provider at the first, second, or third tier.

It should be noted that the above description of flow 700 is for illustrative purposes only and is not intended to limit the scope of the present application. Various modifications and changes in form and detail of the application of the above-described methods and systems may be made by those skilled in the art without departing from the principles of the present application. However, such variations and modifications are also within the scope of the present application. For example, one or more revenue thresholds may be added or omitted, and the number of levels of service providers associated with the one or more revenue thresholds may be increased or decreased accordingly. For another example, the value of one or more revenue thresholds may be adjusted.

FIG. 8 is a flowchart of an exemplary process for determining order allocation weights associated with service providers having a first tier according to some embodiments of the application. In some embodiments, flow 800 may be implemented as a set of instructions (e.g., an application) stored in memory 150, memory 260, or memory 390. The CPU 210, CPU 340, processing engine 112, and/or the modules in fig. 4 may execute the set of instructions, and when executing the instructions, the CPU 210, CPU 340, processing engine 112, and/or the modules in fig. 4 may be configured to execute the flow 800. The operations of the illustrated flow presented below are intended to be illustrative. In some embodiments, the process 800 may be accomplished by one or more of the above additional operations not described and/or omitting one or more of the operations discussed herein. In addition, the order of the flow operations shown in fig. 8 and described below is not limiting.

When a service provider (e.g., a candidate service provider) is determined to have a first rating, the revenue bias for the service provider may be less than a first revenue threshold, which may indicate that the actual revenue is slightly less than the expected revenue. To determine the order allocation weights for the service provider, the processing engine 112 (e.g., the first order allocation weight determination module 440) may consider only the estimated value, the historical order parameters, and the expected order parameters of the service request relative to the value class to which the service request pertains.

In step 810, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine at least two value classes. Each value class may correspond to a range of values (or referred to as a value range). For example, the at least two value ranks may include three value ranks, namely value ranks A, B and C. For example, the value ranges may be ordered according to their values as a2> a1> b2> b1> c2> c1. It should be noted that the description of the value levels above is for illustrative purposes only, and that one or more value levels may be added or omitted.

In step 820, the processing engine 112 (e.g., the first order allocation weight determination module 440) may compare the predicted value of the service request with a value range of at least two value classes to determine a first value class of the service request. For example, if the predicted value of the service request belongs to (a 1, a 2) of value class a, the first value class of the service request may be determined to have value class a.

In step 830, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine a first historical proportion corresponding to the first price level based on the number of historical orders belonging to the first price level and the number of at least two historical orders. In some embodiments, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine the first historical proportion corresponding to the first price level by dividing the number of historical orders belonging to the first price level by the number of at least two historical orders.

In step 840, the processing engine 112 (e.g., the first order allocation weight determination module 440) may obtain a first expected proportion corresponding to the first price level based on one or more expected order parameters. In some embodiments, one or more expected order parameters may be set automatically by the online-to-offline service system 100 or manually by the service provider, and the first expected proportion may be extracted from the one or more expected order parameters.

In step 850, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine an order allocation weight for the first service request for the candidate service provider based on the first historical proportion corresponding to the first price level, the first expected proportion corresponding to the first price level, the estimated value of the service request, the historical order parameters and the expected order parameters of the candidate service provider. In some embodiments, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine order allocation weights for orders for service providers based on a preset first weight determination algorithm. The first weight determination algorithm may be expressed as follows:

where P represents the expected revenue per unit time for the service provider, T represents the historical online time of the service provider, S represents the total value of all historical orders for the service provider, V represents the estimated value of the service request, R represents the historical proportion corresponding to the value level to which the service request belongs, and R represents the expected proportion corresponding to the value level to which the service request belongs.

FIG. 9 is a flowchart illustrating an exemplary process for determining order allocation weights associated with service providers having a second tier (e.g., candidate service providers) according to some embodiments of the application. In some embodiments, flow 900 may be implemented as a set of instructions (e.g., an application) stored in memory 150, memory 260, or memory 390. CPU 210, CPU 340, processing engine 112, and/or the modules in fig. 4 may execute a set of instructions, and when executing instructions, CPU 210, CPU 340, processing engine 112, and/or the modules in fig. 4 may be configured to perform process 900. The operations of the illustrated flow presented below are intended to be illustrative. In some embodiments, flow 900 may be accomplished by one or more additional operations not described and/or omitting one or more of the operations discussed herein. In addition, the order of the flow operations shown in fig. 9 and described below is not limiting.

When a service provider (e.g., a candidate service provider) is determined to have a second level, the revenue bias for the service provider may be greater than or equal to the first revenue threshold and less than the second revenue threshold, which may indicate that the difference between the historical revenue and the expected revenue is at a moderate level. The processing engine 112 (e.g., the first order allocation weight determination module 440) may consider the estimated value of the service request, historical order parameters and expected order parameters associated with a first price level to which the service request belongs and a second price level higher than the first price level to determine the order allocation weight of the service provider.

In step 910, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine at least two value classes. Each value class may correspond to a range of values (or referred to as a value range). For example, the at least two value ranks may include three value ranks, namely value ranks A, B and C. The three value classes may correspond to three value ranges (e.g., value range (a 1, a 2), value range (b 1, b 2), value range (c 1, c 2)). The three value ranges may or may not overlap each other. For example, the value ranges may be ordered according to their value as: a2> a1> b2> b1> c2> c1. It should be noted that the above description of value classes is for illustrative purposes only, and one or more value classes may be added or omitted.

In step 920, the processing engine 112 (e.g., the first order allocation weight determination module 440) may compare the predicted value of the service request with a value range of at least two value classes to determine a first value class of the service request. For example, if the predicted value of the service request belongs to (C1, C2) of the value class C, the first value class of the service request may be determined to belong to the value class C.

In step 930, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine at least one second price level from the at least two price levels, wherein a range of values associated with the at least one second price level is greater than a range of values associated with the first price level. For example, if the predicted value of the service request belongs to value class C, at least one second value class may be determined as value classes A and/or B, the value range of which is higher than the value range of C.

In step 940, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine a first historical proportion corresponding to the first price level based on the number of historical orders belonging to the first price level and the number of at least two historical orders. In some embodiments, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine the first historical proportion corresponding to the first price level by dividing the number of historical orders belonging to the first price level by the number of at least two historical orders. For example, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine a first historical proportion corresponding to the value class C by dividing the number of historical orders belonging to the value class C by the number of at least two historical orders.

In step 950, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine a second historical proportion corresponding to each of the at least one second price level based on the number of historical orders belonging to the second price level and the number of at least two historical orders. In some embodiments, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine a second historical proportion corresponding to each of the at least one second price level (e.g., the value level a, the value level B) by dividing the number of historical orders belonging to the second price level by the number of at least two historical orders.

In step 960, the processing engine 112 (e.g., the first order allocation weight determination module 440) may obtain a first expected proportion corresponding to the first price level based on one or more expected order parameters. In some embodiments, the first expected proportion corresponding to the first price level may be set automatically by the online-to-offline service system 100 or manually by the service provider. If the estimated value of the service request belongs to the value class C, a first expected proportion corresponding to the value class C can be obtained.

In step 970, the processing engine 112 (e.g., the first order allocation weight determination module 440) may obtain a second expected proportion corresponding to each of the at least one second price level based on the one or more expected order parameters. In some embodiments, the second expected proportion corresponding to each of the at least one second value level may be set automatically by the online-to-offline service system 100 or manually by the service provider. For example, a second expected proportion corresponding to value class A and/or value class B may be obtained.

In step 980, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine the order allocation weight for the service request of the service provider based on the first historical scale corresponding to the first price level, the first expected scale corresponding to the first price level, the at least one second historical scale corresponding to the at least one second price level, the at least one second expected scale corresponding to the at least one second price level, the estimated value of the service request, the historical order parameters and/or the expected order parameters of the service provider. In some embodiments, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine order allocation weights for service requests of the service provider using a second weight determination algorithm. The second weight determination algorithm may be represented as follows:

Where P represents the expected revenue per unit time for the service provider, T represents the historical online time of the service provider, S represents the total value of all historical orders for the service provider, V represents the estimated value of the service request, R represents the historical proportion corresponding to the value level to which the service request belongs, R 'represents the historical proportion corresponding to the value level above the value level to which the service request belongs, R represents the expected proportion corresponding to the value level to which the service request belongs, and R' represents the expected proportion corresponding to the value level above the value level to which the service request belongs.

FIG. 10 is a flowchart illustrating an exemplary process for determining order allocation weights associated with service providers having a third tier according to some embodiments of the application. In some embodiments, flow 1000 may be implemented as a set of instructions (e.g., an application) stored in memory 150, memory 260, or memory 390. The CPU 210, CPU 340, processing engine 112, and/or the modules in fig. 4 may execute the set of instructions, and when executing the instructions, the CPU 210, CPU 340, processing engine 112, and/or the modules in fig. 4 may be configured to execute the flow 1000. The operations of the illustrated flow presented below are intended to be illustrative. In some embodiments, flow 1000 may be accomplished by one or more of the above additional operations not described and/or omitting one or more of the operations discussed herein. In addition, the order of the flow operations shown in fig. 10 and described below is not limiting.

When a service provider (e.g., a candidate service provider) is determined to have a third level, the revenue deviation for the service provider may be greater than a second revenue threshold, which may indicate that the difference between actual revenue and expected revenue is very large. The processing engine 112 (e.g., the first order allocation weight determination module 440) may consider all the value classes and calculate order allocation weights based thereon and select the highest order allocation weight from the order allocation weights, regardless of the value class to which the service request belongs.

In step 1010, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine at least two value classes. Each value class may correspond to a range of values. For example, the at least two value ranks may include three value ranks, namely value ranks A, B and C. The three value classes may correspond to three value ranges (e.g., value range (a 1, a 2), value range (b 1, b 2), value range (c 1, c 2)). The three value ranges may or may not overlap each other. For example, the value ranges may be ordered according to their value as: a2> a1> b2> b1> c2> c1. It should be noted that the above description of value classes is for illustrative purposes only, and one or more value classes may be added or omitted.

In step 1020, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine a historical proportion corresponding to each of the at least two value classes based on the number of historical orders belonging to the value class and the number of the at least two historical orders. In some embodiments, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine a historical proportion corresponding to each of the at least two value classes by dividing the number of historical orders belonging to the value class by the number of at least two historical orders.

In step 1030, the processing engine 112 (e.g., the first order allocation weight determination module 440) may obtain an expected proportion corresponding to each value level based on one or more expected order parameters. In some embodiments, the desired proportion for each value level may be set automatically by the online-to-offline service system 100 or manually by the service provider.

In step 1040, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine order allocation weights for service requests of the service provider based on at least two historical and expected proportions corresponding to at least two value classes, the estimated value of the service request, historical order parameters of the service provider, and/or expected order parameters. In some embodiments, the processing engine 112 (e.g., the first order allocation weight determination module 440) may determine order allocation weights for service requests of the service provider using a third weight determination algorithm. The third weight determination algorithm may be expressed as follows:

Where P represents the expected revenue per unit time for the service provider, T represents the historical online time of the service provider, S represents the total value of all historical orders for the service provider, V represents the estimated value of the service request, { r ₁ ,…,r _n The } represents a historical proportion corresponding to each of the n value classes, { R ₁ ,…,R _n And represents the expected proportion corresponding to each of the n value classes.

FIG. 11 is a bipartite graph of an exemplary mismatch associated with a service request and a service provider. As shown in fig. 11, three service requests 1111, 1112, and 1113 will be assigned to three candidate service providers 1121, 1122, and 1123. The processing engine 112 (e.g., the first order allocation weight determination module 440, the second order allocation weight determination module 460) may determine at least two order allocation weights (shown as a straight line connecting the service provider and the service request) for the service providers of these service requests. For example, the order allocation weight 1131 for the service provider 1121 of the service request 1111 may be 3 and the order allocation weight 1132 for the service provider 1121 of the service request 1112 may be 2. In some embodiments, the processing engine 112 may search for matches (e.g., perfect matches) of the bipartite graph based on, for example, a Hungarian algorithm, a hoparoft-Karp algorithm, or a Kuhn-Munkres algorithm. Specifically, in the huntarian algorithm, the values of one or more vertices in the bipartite graph, typically on the left, are initialized. The huntarian algorithm is used to search for matches to the bipartite graph. If no match is found for the bipartite graph, the values of one or more vertices may be modified and the bipartite graph may be searched for a match using the Hungarian algorithm (or a different algorithm) until a match is found for the bipartite graph. The service request of the service requester may be assigned to one of the candidate service providers based on the matching of the bipartite graph. The matching may satisfy at least one of the following conditions: each service request corresponds to only one service provider; each service provider corresponds to only one service request; as many service requests as possible find matching service providers; and assigning weights corresponding to the matched service requests and orders of the service providers as high as possible.

FIG. 12 is a bipartite graph of exemplary matches associated with service requests and service providers. As shown in fig. 12, a match (e.g., a perfect match) of the bipartite graph is found. For example, each of service requests 1111, 1112, and 1113 is assigned to a service provider (e.g., service provider 1121, 1122, or 1123), all service requests find matching service providers, all service providers find matching service requests, and the sum of the order assignment weights corresponding to the matching service requests and service providers is the largest of all possible matches of the bipartite graph.

While the basic concepts have been described above, it will be apparent to those of ordinary skill in the art after reading this application that the above disclosure is by way of example only and is not intended to be limiting. Although not explicitly described herein, various alterations, improvements, and modifications will occur to those skilled in the art. Such modifications, improvements, and modifications are intended to be suggested within the present disclosure, and therefore, such modifications, improvements, and adaptations are intended to be within the spirit and scope of the example embodiments of the present disclosure.

Meanwhile, the present application uses specific terms to describe embodiments of the present application. Reference to "one embodiment," "an embodiment," and/or "some embodiments" means that a particular feature, structure, or characteristic is associated with at least one embodiment of the application. Thus, it should be emphasized and should be appreciated that two or more references to "an embodiment" or "one embodiment" or "an alternative embodiment" in various positions in this specification are not necessarily referring to the same embodiment. Furthermore, some features, structures, or characteristics of one or at least two embodiments of the application may be combined as suitable.

Furthermore, those of ordinary skill in the art will appreciate that the various aspects of the application are illustrated and described in the context of a number of patentable categories or conditions, including any novel and useful processes, machines, products, or materials, or any novel and useful modifications thereof. Thus, aspects of the application may be implemented entirely in hardware, entirely in software (including firmware, resident software, micro-code, etc.) or in combination software and hardware that may all generally be referred to herein as a "block," module, "" engine, "" unit, "" component "or" system. Furthermore, aspects of the application may take the form of a computer product, comprising computer-readable program code embodied in one or at least two computer-readable media.

The computer readable signal medium may comprise a propagated data signal with computer program code embodied therein, for example, on a baseband or as part of a carrier wave. The propagated signal may take any of a variety of forms, including electro-magnetic, optical, etc., or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code located on a computer readable signal medium may be propagated through any suitable medium including radio, cable, fiber optic cable, RF, etc., or any combination of the foregoing.

Computer program code required for operation of aspects of the present application may be written in any combination of one or more programming languages, including an object oriented programming such as Java, scala, smalltalk, eiffel, JADE, emerald, C ++, c#, vb net, python and the like, conventional programming languages such as the "C" programming language, visual Basic, fortran, perl, COBOL, PHP, ABAP, dynamic programming languages such as Python, ruby and Groovy or other programming languages. The program code may execute entirely on the user's computer or as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any form of network, such as a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet), or the use of services such as software as a service (SaaS) in a cloud computing environment.

Furthermore, the order in which the elements and sequences are presented, the use of numerical letters, or other designations are used in the application is not intended to limit the sequence of the processes and methods unless specifically recited in the claims. While in the foregoing disclosure there has been discussed, by way of various examples, some embodiments of the application which are presently considered to be useful, it is to be understood that such details are for the purpose of illustration only and that the scope of the appended claims is not limited to the embodiments disclosed, but, on the contrary, is intended to cover all modifications and equivalent combinations as fall within the spirit and scope of the embodiments of the application. For example, while the system components described above may be implemented by hardware devices, they may also be implemented solely by software solutions, such as installing the described system on an existing server or mobile device.

Likewise, it should be noted that in order to simplify the presentation of the disclosure, and thereby aid in understanding one or at least two inventive embodiments, various features are sometimes grouped together in a single embodiment, figure, or description thereof. This method of disclosure, however, is not intended to imply that more features than are in the claims are required for this application. Indeed, less than all of the features of a single embodiment disclosed above.

In some embodiments, numbers describing the components, number of attributes are used, it being understood that such numbers being used in the description of embodiments are modified in some examples by the modifier "about," approximately, "or" substantially. For example, unless otherwise indicated, "about," "approximately," or "substantially" may mean a ±20% change in the value it describes. Accordingly, in some embodiments, numerical parameters set forth in the specification and claims are approximations that may vary depending upon the desired properties sought to be obtained by the individual embodiments. In some embodiments, the numerical parameters should take into account the specified significant digits and employ a method for preserving the general number of digits. Although the numerical ranges and parameters set forth herein are approximations in some embodiments for use in determining the breadth of the range, in particular embodiments, the numerical values set forth herein are as precisely as possible.

All patents, patent applications, patent application publications, and other materials (e.g., articles, books, specifications, publications, records, things, and/or the like) mentioned herein are hereby incorporated herein by reference in their entirety for all purposes except for any prosecution document record associated with the above documents, any such document inconsistent or conflicting with the present document or any such document which has a limiting effect on the broad scope of claims sooner or later associated with the present document. For example, if there is any inconsistency or conflict between the use of any of the incorporated material's descriptions, definitions and/or terms associated with the present document, the use of the descriptions, definitions and/or terms in the present document shall prevail.

Finally, it should be understood that the embodiments described herein are merely illustrative of the principles of the embodiments of the present application. Other variations are also possible within the scope of the application. Thus, by way of example, and not limitation, alternative configurations of embodiments of the application may be considered in keeping with the teachings of the application. Accordingly, the embodiments of the present application are not limited to the embodiments explicitly described and depicted herein.

Claims

1. A system, comprising:

A storage device comprising a set of instructions for assigning a service request to a service provider;

at least one processor in communication with the storage device, wherein the at least one processor, when executing the instructions, is configured to cause the system to:

receiving a first service request;

determining a predicted value of the first service request;

determining at least one candidate service provider for the first service request;

for each of the at least one candidate service provider,

obtaining one or more historical order parameters for the candidate service provider;

receiving one or more expected order parameters for the candidate service provider; and

determining an order allocation weight for the first service request for a candidate service provider based on the estimated value of the first service request, one or more historical order parameters and one or more expected order parameters for the service provider; and

determining a target service provider of the first service request from the at least one candidate service provider according to at least one order allocation weight of the first service request with respect to the at least one candidate service provider; the method comprises the following steps:

For each of the at least one second user device,

receiving a second service request;

determining at least one order allocation weight for the second service request for the at least one candidate service provider;

constructing a bipartite graph linking the first service request and the at least one second service request with the at least one candidate service provider;

performing a bipartite graph matching algorithm on the bipartite graph to generate a matched bipartite graph according to at least one order allocation weight for each of the first service request and the at least one second service request for the at least one candidate service provider; the bipartite graph matching algorithm is at least one of a Hungarian algorithm, a Hopcroft-Karp algorithm or a Kuhn-Munkres algorithm; and

determining the target service provider of the first service request from the at least one candidate service provider according to the matched bipartite graph; wherein the matching satisfies a condition including at least one of:

each service request corresponds to only one service provider;

each service provider corresponds to only one service request;

all service requests find the matching service provider; and

The sum of the order assignment weights corresponding to the matched service requests and service providers is the largest of all possible matches for the bipartite graph.

2. The system according to claim 1, wherein:

the one or more historical order parameters of the candidate service provider include a historical online time length of the candidate service provider and a total value of the candidate service provider's historical orders; and

the one or more expected order parameters include expected revenue per unit time.

3. The system of claim 2, wherein to determine an order allocation weight for the first service request for the candidate service provider, the at least one processor is configured to cause the system to:

determining expected revenue for the candidate service provider based on the historical online time length of the candidate service provider and the expected revenue per unit time; and

an order allocation weight for the first service request is determined for the candidate service provider based on the expected revenue, the total value of the historical orders, and the estimated value of the first service request.

4. The system of claim 2, wherein to determine an order allocation weight for the first service request for the candidate service provider, the at least one processor is further configured to cause the system to:

Determining a revenue bias for the candidate service provider based on the historical online time period of the candidate service provider, the expected revenue per unit time, and the total value of the historical orders for the candidate service provider;

comparing the revenue bias of the candidate service provider to at least one revenue threshold;

determining a ranking of the candidate service provider based on a comparison between the revenue bias and the at least one revenue threshold; and

an order allocation weight for the first service request for the candidate service provider is determined based on the ranking of the candidate service provider, the estimated value of the first service request, the historical order parameters, and the prospective order parameters.

5. The system according to claim 4, wherein:

the at least one revenue threshold includes a first threshold and a second threshold, the second threshold being greater than or equal to the first threshold; and

determining a ranking of the candidate service provider based on a comparison between the revenue deviation and the revenue threshold, the at least one processor configured to cause the system to:

Determining the grade of the candidate service provider as a first grade according to the comparison result that the income deviation of the candidate service provider is smaller than the first critical value;

determining the level of the candidate service provider as a second level according to a comparison result that the income deviation of the candidate service provider is larger than or equal to the first critical value and smaller than the second critical value; and

and determining the grade of the candidate service provider as a third grade according to the comparison result that the income deviation of the candidate service provider is larger than or equal to the second critical value.

6. The system according to claim 5, wherein:

the level of the candidate service provider is determined as a first level; and

to determine that the first service request is of an order allocation weight for the candidate service provider, the at least one processor is configured to cause the system to:

determining at least two value classes, each of the at least two value classes corresponding to a value range;

comparing the estimated value of the first service request with the value ranges of the at least two value classes to determine a first value class of the first service request;

Determining a first historical proportion corresponding to the first price class according to the number of historical orders belonging to the first price class and the number of historical orders of the candidate service provider;

obtaining a first expected proportion corresponding to the first price class according to the one or more expected order parameters; and

an order allocation weight for the first service request for the candidate service provider is determined based on the first historical proportion corresponding to the first price level, the first expected proportion corresponding to the first price level, the estimated value of the first service request, the historical order parameters and the expected order parameters of the candidate service provider.

7. The system of claim 5, wherein the ranking of the candidate service provider is a second ranking, and wherein to determine an order assignment weight for the first service request for the candidate service provider, the at least one processor is configured to cause the system to:

Determining at least one second value level from the at least two value levels, wherein a value range associated with the at least one second value level is greater than a value range associated with the first value level;

acquiring a first expected proportion corresponding to the first price class according to the one or more expected order parameters;

for each of the at least one second value class,

determining a second historical proportion corresponding to the second value level according to the number of the historical orders belonging to the second value level and the number of the at least two historical orders; and

acquiring a second expected proportion corresponding to the second value level according to the one or more expected order parameters; and

determining an order allocation weight for the first service request for the candidate service provider based on a first historical scale corresponding to the first price level, a second historical scale corresponding to the at least one second price level, a first expected scale corresponding to the first price level, a second expected scale corresponding to the at least one second price level, an estimated value of the first service request, a historical order parameter and an expected order parameter of the candidate service provider.

8. The system of claim 5, wherein the ranking of each of the at least one candidate service provider is a third ranking, and wherein determining an order allocation weight for the first service request for the candidate service provider, the at least one processor is configured to cause the system to:

determining at least two value grades, each value grade corresponding to a value range;

for each of the at least two value classes,

determining a history proportion corresponding to the value grade according to the number of the history orders belonging to the value grade and the number of the history orders of the candidate service provider; and

obtaining an expected proportion corresponding to the value grade according to the one or more expected order parameters; and

an order allocation weight for the first service request for the candidate service provider is determined based on at least two historical and expected proportions corresponding to the at least two value classes, the estimated value of the first service request, the historical order parameters and the expected order parameters of the candidate service provider.

9. A method implemented on a computing device having at least one storage device for storing a set of instructions for assigning a service request to a service provider, and at least one processor in communication with the at least one storage device, the method comprising:

Receiving a first service request;

determining a predicted value of the first service request;

for each of the at least one candidate service provider,

for each of the at least one second user device,

receiving a second service request;

each service request corresponds to only one service provider;

each service provider corresponds to only one service request;

all service requests find a matching service provider; and

10. The method according to claim 9, wherein:

11. The method of claim 10, wherein determining an order allocation weight for the first service request for the candidate service provider comprises:

12. The method of claim 10, wherein determining an order allocation weight for the first service request for the candidate service provider comprises:

an order allocation weight for the first service request for the candidate service provider is determined based on the ranking of the candidate service provider, the estimated value of the first service request, the historical order parameters and the expected order parameters of the candidate service provider.

13. The method according to claim 12, wherein:

determining a ranking of the candidate service provider based on a comparison between the revenue bias and the revenue threshold, comprising:

14. The method according to claim 13, wherein:

the ranking of the candidate service provider is a first ranking; and

determining an order allocation weight for the first service request for the candidate service provider comprises:

an order allocation weight for the first service request for the candidate service provider is determined based on the first historical proportion corresponding to the first price level, the first expected proportion corresponding to the first price level, the estimated value of the first service request, the historical order parameters and expected order parameters of the candidate service provider.

15. The method of claim 13, wherein the ranking of the candidate service provider is a second ranking and determining an order allocation weight for the first service request for the candidate service provider comprises:

for each of the at least one second value class,

determining an order allocation weight for the first service request for the candidate service provider based on the first historical scale corresponding to the first price level, a second historical scale corresponding to the at least one second price level, the first expected scale corresponding to the first price level, the second expected scale corresponding to the second price level, the estimated value of the first service request, a historical order parameter and an expected order parameter of the candidate service provider.

16. The method of claim 13, wherein the ranking of each of the at least one candidate service provider is a third ranking, and determining an order allocation weight for the first service request for the candidate service provider comprises:

For each of the at least two value classes,

an order allocation weight for the first service request for the candidate service provider is determined based on at least two historical and expected proportions corresponding to at least two value classes, the estimated value of the first service request, historical order parameters and expected order parameters of the candidate service provider.

17. A non-transitory computer readable medium comprising at least one set of instructions for assigning a service request to a service provider, characterized in that when executed by at least one processor of an electronic terminal, the at least one set of instructions instruct the at least one processor to perform the acts of:

receiving a first service request;

determining a predicted value of the first service request;

For each of the at least one candidate service provider,

determining an order allocation weight for the first service request for the candidate service provider based on the estimated value of the first service request, one or more historical order parameters and one or more expected order parameters of the service provider; and

for each of the at least one second user device,

receiving a second service request;

each service request corresponds to only one service provider;

each service provider corresponds to only one service request;

all service requests find a matching service provider; and

18. A system implemented on a computing device having at least one storage device for storing a set of instructions for assigning service requests to service providers, and at least one processor in communication with the at least one storage device, the system comprising:

an acquisition module configured to receive a first service request;

the estimated value determining module is configured to determine the estimated value of the first service request;

a service provider determination module configured to determine at least one candidate service provider for the first service request;

the parameter acquisition module is configured to:

For each of the at least one candidate service provider,

obtaining one or more historical order parameters for the candidate service provider; and

receiving one or more expected order parameters for the candidate service provider;

a processing engine configured to determine an order allocation weight for the first service request with respect to the candidate service provider based on the estimated value of the first service request, one or more historical order parameters and one or more expected order parameters of the service provider; and

an order allocation module configured to determine a target service provider of the first service request from the at least one candidate service provider according to at least one order allocation weight for the first service request for the at least one candidate service provider; the method comprises the following steps:

for each of the at least one second user device,

receiving a second service request;

each service request corresponds to only one service provider;

each service provider corresponds to only one service request;

all service requests find a matching service provider; and

19. An order allocation method, comprising:

determining at least one candidate service provider based on a service request received from a service requester;

determining the estimated value V of the service request;

Obtaining one or more historical order parameters and one or more prospective order parameters associated with each of the at least one candidate service provider;

determining an order allocation weight for the service request for each of the at least one candidate service provider based on the one or more historical order parameters, the one or more prospective order parameters, and the predictive value V; and

assigning a service request to one of the at least one candidate service provider based on an order assignment weight for the service request for each of the at least one candidate service provider; the method comprises the following steps:

constructing a bipartite graph according to the service requester, the at least one candidate service provider, and an order allocation weight for each of the at least one candidate service provider;

initializing values of one or more vertices in the bipartite graph;

searching for a complete match of the bipartite graph using a hungarian algorithm;

if a full match of the bipartite graph cannot be found, modifying the values of the one or more vertices and searching for a full match of the bipartite graph using the hungarian algorithm until a full match of the bipartite graph is found; and

Assigning a service request of the service requester to one of the at least one candidate service provider based on the perfect match of the bipartite graph; wherein the matching satisfies a condition including at least one of:

each service request corresponds to only one service provider;

each service provider corresponds to only one service request;

all service requests find a matching service provider; and

20. The method of claim 19, wherein determining an order allocation weight for the service request for each of the at least one candidate service provider based on the one or more historical order parameters, the one or more prospective order parameters, and the predictive value V, further comprises:

determining a revenue bias for each of the at least one candidate service provider based on the one or more historical order parameters and the one or more expected order parameters;

comparing the revenue deviation to at least one revenue threshold; and

An order allocation weight for the service request for each of at least one candidate service provider is determined based on the comparison, the one or more historical order parameters, the one or more prospective order parameters, and the predictive value V.

21. The method according to claim 20, wherein:

the one or more historical parameters include a historical online time period T; and

determining a revenue bias for each of the at least one candidate service provider based on the one or more historical order parameters and the one or more expected order parameters, further comprising:

for each of the at least one candidate service provider,

judging whether the historical online time length T is greater than or equal to an online time critical value or not; and

responsive to determining that the historical online time period T is greater than or equal to the online time threshold, a revenue bias for each of the at least one candidate service provider is determined based on the one or more historical order parameters and the one or more expected order parameters.

22. The method according to claim 20, wherein:

the one or more historical order parameters include a value structure of the historical order, the value structure of the historical order including n value classes and n historical proportions corresponding to the n value classes, respectively;

The one or more prospective order parameters comprise a value structure of the prospective order, the value structure of the prospective order comprising n value classes and n prospective proportions corresponding to the n value classes, respectively;

n is an integer greater than or equal to 2; and

determining an order allocation weight for the service request for each of the at least one candidate service provider based on the comparison, the one or more historical order parameters, the one or more prospective order parameters, and the predictive value V, further comprising:

responsive to determining that the revenue deviation is less than a first revenue threshold, determining a value tier to which the service request belongs from the n value tiers based on the estimated value V;

acquiring a historical proportion R corresponding to the value grade of the service request according to the value structure of the historical order and acquiring an expected proportion R corresponding to the value grade of the service request according to the value structure of the expected order; and

determining an order allocation weight for the service request for each of the at least one candidate service provider based on the historical proportion R, the prospective proportion R, the one or more historical order parameters, the one or more prospective order parameters, and the predicted value V.

23. The method according to claim 20, wherein:

n is an integer greater than or equal to 2; and

responsive to determining that the revenue deviation is greater than or equal to a first revenue threshold and less than a second revenue threshold, determining, from the n value levels, a value level to which the service request belongs based on the predicted value V, the first revenue threshold being less than the second revenue threshold;

acquiring a historical proportion R corresponding to the value grade to which the service request belongs according to the value structure of the historical order and acquiring an expected proportion R corresponding to the value grade to which the service request belongs according to the value structure of the expected order;

Acquiring a historical proportion R 'corresponding to a value grade greater than the value grade to which the service request belongs according to the value structure of the historical order and acquiring an expected proportion R' corresponding to a value grade greater than the value grade to which the service request belongs according to the value structure of the expected order; and

determining an order allocation weight for the service request for each of the at least one candidate service provider based on the historical scale R, the expected scale R, the historical scale R ', the expected scale R', the one or more historical order parameters, the one or more expected order parameters, and the estimated value V.

24. The method according to claim 20, wherein:

n is an integer greater than or equal to 2; and

responsive to determining that the revenue deviation is greater than or equal to a second revenue threshold, obtaining historical proportions corresponding to the n value classes based on a value structure of the historical ordersTo->Acquiring an expected proportion corresponding to the n value classes based on the value structure of the expected order>To->The method comprises the steps of carrying out a first treatment on the surface of the And

according to the history proportionTo->The desired ratio->To->The one or more historical order parameters, the one or more prospective order parameters, and the predictive value V determine an order allocation weight for the service request for each of the at least one candidate service provider.

25. The method as claimed in claim 22, wherein:

the one or more historical order parameters include a historical online time period T and a total value S of the historical order;

the one or more expected order parameters include an expected revenue per unit time P; and

Determining an order allocation weight for the service request for each of the at least one candidate service provider based on the historical proportion R, the prospective proportion R, the one or more historical order parameters, the one or more prospective order parameters, and the predicted value V, further comprising:

determining an order allocation weight for the service request for each of the at least one candidate service provider according to a first weight determination algorithm, the first weight determination algorithm expressed as:

order allocation weight =。

26. The method according to claim 23, wherein:

determining an order allocation weight for the service request for each of the at least one candidate service provider based on the historical scale R, the expected scale R, the historical scale R ', the expected scale R', the one or more historical order parameters, the one or more expected order parameters, and the estimated value V, further comprising:

Determining an order allocation weight for the service request for each of the at least one candidate service provider according to a second weight determination algorithm, the second weight determination algorithm expressed as:

order allocation weight = max。

27. The method according to claim 24, wherein:

according to the history proportionTo->The desired ratio->To->Determining an order allocation weight for the service request for each of the at least one candidate service provider, the one or more historical order parameters, the one or more prospective order parameters, and the predictive value V, further comprising:

determining an order allocation weight for the service request for each of the at least one candidate service provider according to a third weight determination algorithm, the third weight determination algorithm expressed as:

order allocation weight = max。

28. The method according to claim 21, wherein the method further comprises:

In response to determining that the historical online time duration T is less than the online time threshold, an order allocation weight for the service request for each of the at least one candidate service provider is determined based on the one or more historical order parameters, the one or more prospective order parameters, and the predictive value V.

29. The method according to claim 28, wherein:

the one or more historical order parameters comprise a historical online time length T and a total value S of a historical order;

determining an order allocation weight for the service request for each of the at least one candidate service provider based on the one or more historical order parameters, the one or more prospective order parameters, and the predictive value V, further comprising:

determining an order allocation weight for each of the at least one candidate service provider according to a fourth weight determination algorithm, the fourth weight determination algorithm expressed as:

order allocation weight =。

30. An order distribution device, comprising:

the service provider determination module is configured to determine at least one candidate service provider based on a service request received from a service requester;

The value determining module is configured to determine an estimated value V of the service request;

the parameter acquisition module is configured to acquire one or more historical order parameters and one or more expected order parameters associated with each of the at least one candidate service provider;

a first order allocation weight determination module configured to determine an order allocation weight for the service request for each of the at least one candidate service provider based on the one or more historical order parameters, the one or more prospective order parameters, and the predicted value V; and

the allocation module is configured to allocate a service request to one of the at least one candidate service provider based on an order allocation weight for the service request for each of the at least one candidate service provider; the distribution module further comprises:

a construction unit configured to construct a bipartite graph according to the service requester, the at least one candidate service provider, and an order allocation weight for each of the at least one candidate service provider;

an initialization unit configured to initialize values of one or more vertices in the bipartite graph;

A matching unit configured to search for a complete match of the bipartite graph using a hungarian algorithm;

a processing unit configured to modify values of the one or more vertices if a full match of the bipartite graph is not found, and search for a full match of the bipartite graph using the hungarian algorithm until a full match of the bipartite graph is found; and

an allocation unit configured to allocate a service request of the service requester to one of the at least one candidate service provider according to a complete match of the bipartite graph; wherein the matching satisfies a condition including at least one of:

each service request corresponds to only one service provider;

each service provider corresponds to only one service request;

all service requests find a matching service provider; and

31. The order distribution device of claim 30 wherein the first order distribution weight determination module further comprises:

a deviation determination unit configured to determine a revenue deviation for each of the at least one candidate service provider based on the one or more historical order parameters and the one or more expected order parameters;

A comparison unit configured to compare the revenue deviation with at least one revenue threshold; and

a determining unit configured to determine an order allocation weight for the above-mentioned service request for each of the at least one candidate service provider based on the comparison result, the one or more historical order parameters, the one or more expected order parameters and the estimated value V.

32. The order dispensing device of claim 31, wherein:

the deviation judging unit further includes:

a judging subunit configured to judge, for each of the at least one candidate service provider, whether the historical online time period T is greater than or equal to an online time threshold; and

the first determination subunit is configured to determine, in response to a determination that the historical online time duration T is greater than or equal to the online time threshold, a revenue bias for each of the at least one candidate service provider based on the one or more historical order parameters and the one or more expected order parameters.

33. The order dispensing device of claim 31, wherein:

n is an integer greater than or equal to 2; and

the determination unit further includes:

a first value class determination subunit configured to determine, in response to determining that the revenue deviation is less than a first revenue threshold, a value class to which the service request belongs from the n value classes based on the estimated value V;

a first obtaining subunit configured to obtain, based on a value structure of the historical order, a historical proportion R corresponding to a value class to which the service request belongs and obtain, based on a value structure of the expected order, an expected proportion R corresponding to the value class to which the service request belongs; and

a second determination subunit configured to determine an order allocation weight for the service request for each of the at least one candidate service provider based on the historical scale R, the expected scale R, the one or more historical order parameters, the one or more expected order parameters, and the predicted value V.

34. The order dispensing device of claim 31, wherein:

n is an integer greater than or equal to 2; and

the determination unit further includes:

a second value level determination subunit configured to determine, from the n value levels, a value level to which the service request belongs based on the estimated value V, in response to determining that the revenue deviation is greater than or equal to a first revenue threshold value and less than a second revenue threshold value, the first revenue threshold value being less than the second revenue threshold value;

a second acquisition subunit configured to:

acquiring a historical proportion R corresponding to a value grade to which the service request belongs according to the value structure of the historical order and acquiring an expected proportion R corresponding to the value grade to which the service request belongs according to the value structure of the expected order; and

a third determination subunit configured to determine an order allocation weight for the service request for each of the at least one candidate service provider based on the historical scale R, the expected scale R, the historical scale R ', the expected scale R', the one or more historical order parameters, the one or more expected order parameters, and the estimated value V.

35. The order dispensing device of claim 31, wherein:

n is an integer greater than or equal to 2; and

the judging unit further includes:

a third acquisition subunit configured to acquire, based on the value structure of the historical orders, historical proportions corresponding to the n value classes in response to determining that the revenue deviation is greater than or equal to a second revenue thresholdTo->Acquiring an expected proportion corresponding to the n value classes based on the value structure of the expected order>To->The method comprises the steps of carrying out a first treatment on the surface of the And->

A fourth determination subunit configured to, according to the history proportionTo->The desired ratio->To->The one or more historical order parameters, the one or more prospective order parameters, and the predictive value V determine an order allocation weight for the service request for each of the at least one candidate service provider.

36. The order dispensing device of claim 33, wherein:

the first order allocation weight determination module is further configured to:

Order allocation weight =。

37. The order dispensing device of claim 34, wherein:

the third determination subunit is further configured to:

order allocation weight = max。

38. The order dispensing device of claim 35, wherein:

the fourth determination subunit is further configured to:

order allocation weight = max 。

39. The order dispensing device of claim 32, further comprising:

the second order allocation weight determination module is configured to determine an order allocation weight for the service request for each of the at least one candidate service provider based on the one or more historical order parameters, the one or more prospective order parameters, and the predictive value V in response to determining that the historical online time duration T is less than the online time threshold.

40. The order distribution device as set forth in claim 39 wherein:

the one or more historical order parameters comprise a historical online time length T and a historical order S of total value;

the second order allocation weight determination module is further configured to:

determining individual assigned weights for each of the at least one candidate service provider according to a fourth weight determination algorithm, the fourth weight determination algorithm expressed as:

order allocation weight= =。

41. A computer-readable storage medium comprising at least one set of instructions, which when executed by at least one processor, direct the at least one processor to perform the actions of:

determining the estimated value V of the service request;

initializing values of one or more vertices in the bipartite graph;

each service request corresponds to only one service provider;

each service provider corresponds to only one service request;

all service requests find a matching service provider; and

42. An electronic device, comprising:

the processor is configured to implement at least one set of instructions; and

the storage device is configured to store the at least one set of instructions, wherein the at least one set of instructions, when loaded and executed by the processor, instruct the processor to perform:

determining the estimated value V of the service request;

initializing values of one or more vertices in the bipartite graph;

Each service request corresponds to only one service provider;

each service provider corresponds to only one service request;

all service requests find a matching service provider; and