WO2020093420A1

WO2020093420A1 - Systems and methods for emergency order request identification

Info

Publication number: WO2020093420A1
Application number: PCT/CN2018/115138
Authority: WO
Inventors: Haibo Li; Hui QIU; Menghua JIANG; Yuhao QIN
Original assignee: Beijing Didi Infinity Technology And Development Co., Ltd.
Priority date: 2018-11-09
Filing date: 2018-11-13
Publication date: 2020-05-14
Also published as: CN110766505A

Abstract

A method for identifying an emergency order request is provided. The method may include receiving an order request from a mobile device of a service requester. The method may include determining whether the order request is an emergency order request by processing the features of the order request. If the order request is determined as the emergency order request, the method further includes generating an order by preferentially allocating the order request to a service provider, adjusting a service charge of the order dynamically and transmitting signals to the mobile device of the service requester.

Description

SYSTEMS AND METHODS FOR EMERGENCY ORDER REQUEST IDENTIFICATION

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority of Chinese Patent Application No. 201811334228.9 filed on November 9, 2018, the entire contents of which are hereby incorporated by reference.

TECHNICAL FIELD

This disclosure generally relates to systems and methods for identifying an emergency order request based on a machine-learning identification model.

BACKGROUND

Online to offline services (e.g., car-hailing services) have become more and more popular. Through an online service platform, a user can request an online to offline service by an application installed in his/her mobile device (e.g., a smart phone) . Taking the car-hailing service as an example, the online service platform may schedule a service vehicle after receiving an order request including a pick-up location and a drop-off location. In some occasions, unlike some non-urgent matters (e.g., shopping) , the user may desire to obtain the requested service as soon as possible, so as to attend to some urgent or important matters (e.g., seeing a doctor or catching a flight) . Therefore, in some occasions, it is desirable to develop systems and methods for identifying an emergency order request indicating an urgent matter so as to provide suitable service to the user and improve user experience.

SUMMARY

According to one aspect of the present disclosure, a system is provided. The system may include at least one storage device, at least one processor in communication with the information exchange port system and the at least one storage device. The at least one storage device may include one or more sets of instructions. When executing the one or more sets of instructions, the at least one processor may receive an order request from a mobile device of a service requester, the order request including features that include at least a pick-up location, a pick-up time, and a drop-off location. The at least one processor determine whether the order request is an emergency order request by processing the features of the order request. In response to the determination that the order request is the emergency order request, the at least one processor may generate an order by preferentially allocating the order request to a service provider, dynamically adjust a service charge of the order and transmit signals to the mobile device of the service requester, the signals prompting the mobile device to display the order including the adjusted service charge.

In some embodiments, the signals may further prompt the mobile device to display an inquiry to the service requester as to whether to accept the order.

In some embodiments, the at least one processor may select a target service provider that is available and has a shortest estimated time of arrival (ETA) from the target service provider’s current location to the pick-up location, and allocate the order request to the target service provider.

In some embodiments, the at least one processor may bypass other service requests in a same queue with the service request from the service requester.

In some embodiments, the at least one processor may process the features of the order request with a trained identification model. The trained identification model may be generated by training an original machine-learning identification model with training data, the training data comprising a plurality of labelled historical orders.

In some embodiments, the at least one processor may obtain one or more features associated with each labelled historical order. The at least one processor may apply the one or more features of the plurality of labelled historical orders to train the original machine-learning identification model, and update one or more parameters associated with the original machine-learning identification model by minimizing an objective function to obtain the trained identification model, the objective function including a loss function.

In some embodiments, the one or more features associated with the plurality of labelled historical orders may include an order time, a pick-up time, a pick-up location, a drop-off location, a Point of Interest (POI) type of the drop-off location, a user portrait, a trip mode, a weather condition, and a waiting time period.

In some embodiments, the user portrait may include travel habits of one or more classes of service requesters.

In some embodiments, the order may include a planned route that has a shortest ETA from the pick-up location to the drop-off location.

According to an aspect of the present disclosure, a method is provided. The method may include one or more of the following operations. At least one processor may receive an order request from a mobile device of a service requester, the order request including features that include at least a pick-up location, a pick-up time, and a drop-off location. The at least one processor determine whether the order request is an emergency order request by processing the features of the order request. In response to the determination that the order request is the emergency order request, the at least one processor may generate an order by preferentially allocating the order request to a service provider, dynamically adjust a service charge of the order and transmit signals to the mobile device of the service requester via the information exchange port system, the signals prompting the mobile device to display the order including the adjusted service charge.

According to another aspect of the present disclosure, a non-transitory computer readable medium is provided. The non-transitory computer readable medium may comprise executable instructions that cause at least one processor to effectuate a method. The method may include one or more of the following operations. At least one processor may receive an order request from a mobile device of a service requester, the order request including features that include at least a pick-up location, a pick-up time, and a drop-off location. The at least one processor determine whether the order request is an emergency order request by processing the features of the order request. In response to the determination that the order request is the emergency order request, the at least one processor may generate an order by preferentially allocating the order request to a service provider, dynamically adjust a service charge of the order and transmit signals to the mobile device of the service requester via the information exchange port system, the signals prompting the mobile device to display the order including the adjusted service charge.

Additional features will be set forth in part in the description which follows, and in part will become apparent to those skilled in the art upon examination of the following and the accompanying drawings or may be learned by production or operation of the examples. The features of the present disclosure may be realized and attained by practice or use of various aspects of the methodologies, instrumentalities and combinations set forth in the detailed examples discussed below.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure is further described in terms of exemplary embodiments. These exemplary embodiments are described in detail with reference to the drawings. The drawings are not to scale. These embodiments are non-limiting exemplary embodiments, in which like reference numerals represent similar structures throughout the several views of the drawings, and wherein:

FIG. 1 is a schematic diagram illustrating an exemplary online to offline (O2O) service system according to some embodiments of the present disclosure;

FIG. 2 is a schematic diagram illustrating exemplary components of a computing device according to some embodiments of the present disclosure;

FIG. 3 is a schematic diagram illustrating exemplary hardware and/or software components of an exemplary mobile device according to some embodiments of the present disclosure;

FIG. 4 is a block diagram illustrating an exemplary processing device according to some embodiments of the present disclosure;

FIG. 5 is a flowchart illustrating an exemplary process for identifying an emergency order request according to some embodiments of the present disclosure;

FIG. 6 is a flowchart illustrating an exemplary process for training a machine-learning identification model according to some embodiments of the present disclosure;

FIGs. 7A and 7B are schematic diagrams illustrating exemplary machine-learning identification model according to some embodiments of the present disclosure; and

FIG. 8 is a schematic diagram illustrating an exemplary user interface presenting a service request according to some embodiments of the present disclosure.

DETAILED DESCRIPTION

The following description is presented to enable any person skilled in the art to make and use the present disclosure, 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 general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present disclosure. Thus, the present disclosure is not limited to the embodiments shown, but is to be accorded the widest scope consistent with the claims.

The terminology used herein is to describe particular example embodiments only and is not intended to be limiting. As used herein, the singular forms "a, " "an, " and "the" may be intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprise, " "comprises, " and/or "comprising, " "include, " "includes, " and/or "including, " 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.

These and other features, and characteristics of the present disclosure, as well as the methods of operation and functions of the related elements of structure and the combination of parts and economies of manufacture, may become more apparent upon consideration of the following description with reference to the accompanying drawings, all of which form a part of this disclosure. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended to limit the scope of the present disclosure. It is understood that the drawings are not to scale.

The flowcharts used in the present disclosure illustrate operations that systems implement according to some embodiments in the present disclosure. It is to be expressly understood, the operations of the flowchart may be implemented not in order. Conversely, the operations may be implemented in inverted order, or simultaneously. Moreover, one or more other operations may be added to the flowcharts. One or more operations may be removed from the flowcharts.

Moreover, while the system and method in the present disclosure is described primarily in regard to distributing a request for a transportation service, it should also be understood that the present disclosure is not intended to be limiting. The system or method of the present disclosure may be applied to any other kind of online to offline (O2O) service. For example, the system or method of the present disclosure may be applied to transportation systems of different environments including land, ocean, aerospace, or the like, or any combination thereof. The vehicle of the transportation systems may include a taxi, a private car, a hitch, a bus, a train, a bullet train, a high speed rail, a subway, a vessel, an aircraft, a spaceship, a hot-air balloon, a driverless vehicle, or the like, or any combination thereof. The transportation system may also include any transportation system for management and/or distribution, for example, a system for transmitting and/or receiving an express. The application of the system or method of the present disclosure may be implemented on a user device and include a webpage, a plug-in of a browser, a client terminal, a custom system, an internal analysis system, an artificial intelligence robot, or the like, or any combination thereof.

The term "passenger, " "requester, " "service requester, " and "customer" in the present disclosure are used interchangeably to refer to an individual, an entity, or a tool that may request or order a service. Also, the term "driver, " "provider, " and "service provider" in the present disclosure are used interchangeably to refer to an individual, an entity, or a tool that may provide a service or facilitate the providing of the service.

The term "service request, " "request for a service, " "requests, " and "order" in the present disclosure are used interchangeably to refer to a request that may be initiated by a passenger, a service requester, a customer, a driver, a provider, a service provider, or the like, or any combination thereof. The service request may be accepted by any one of a passenger, a service requester, a customer, a driver, a provider, or a service provider. The service request may be chargeable or free.

The term "service provider terminal" and "driver terminal" in the present disclosure are used interchangeably to refer to a mobile terminal that is used by a service provider to provide a service or facilitate the providing of the service. The term "service requester terminal" and "passenger terminal" in the present disclosure are used interchangeably to refer to a mobile terminal that is used by a service requester to request or order a service.

The positioning technology used in the present disclosure may be based on a global positioning system (GPS) , a global navigation satellite system (GLONASS) , a compass navigation system (COMPASS) , a Galileo positioning system, a quasi-zenith satellite system (QZSS) , a wireless fidelity (WiFi) positioning technology, or the like, or any combination thereof. One or more of the above positioning systems may be used interchangeably in the present disclosure.

In an aspect, the present disclosure is directed to systems (e.g., AI systems) and methods for identifying specific type (s) of order requests. For example, the systems and methods of the present disclosure may be used to identify whether a received order request is an emergency order request. The descriptions below use emergency order request as an example; it should be noted, however, that other types of order requests may also be identified with the systems and methods herein disclosure –for example, by adjusting the parameters of a machine-learning identification model.

The system may identify the emergency order request by using a machine-learning identification model to process the received order request. The machine-learning identification model may be trained based on features of a plurality of historical orders. The features of the plurality of historical orders may include an order time, a pick-up time, a pick-up location, a drop-off location, a Point of Interest (POI) type of the drop-off location, a user portrait, a trip mode, a weather condition, a waiting time period, or the like, or any combination thereof. If the received order request is identified as the emergency order request, the system may perform an order allocation preferentially for the identified emergency order request, and dynamically adjust a service charge of the order.

FIG. 1 is a schematic diagram illustrating an exemplary online to offline (O2O) service system according to some embodiments of the present disclosure. The O2O service system 100 may be a platform for data and/or information processing, for example, processing an order request from a service requester. In some embodiments, the O2O service system 100 may include a system (e.g., an artificial intelligent (AI) system) for processing the order request, for example, to identify whether a real-time order request is an emergency order request. In some embodiments, the service may be a transportation service, such as a car hailing service, a chauffeur service, a delivery vehicle service, a carpool service, a bus service, a driver hiring service, and a shuttle service. In some embodiment, the service may be any online service, such as booking a meal, shopping, or the like, or any combination thereof.

The O2O service system 100 may include an information exchange port system including a first information exchange port 101 and a second information exchange port 102, a server 110, a storage device 120, a requester terminal 130, a provider terminal 140. The server 110 may also include a processing device 112. In some embodiments, the O2O service system 100 may communicate with one or more service requesters and one or more service providers via the first information exchange port 101 and the second information exchange port 102, respectively. For example, the server 110 of the O2O service system 100 may receive information and/or data related to an order request from a mobile device of a service requester via the first information exchange port 101. As another example, the server 110 of the O2O service system 100 may access information and/or data from a mobile device of a service provider via the second information exchange port 102. As still an example, the server 110 of the O2O service system 100 may transmit information and/or data to the mobile device of a service requester or a service provider via the information exchange port system. In some embodiments, the information exchange port system (i.e. the first information exchange port 101 and the second information exchange port 102) may be integrated into a single device. In some embodiments, the first information exchange port 101 and the second information exchange port 102 may be separated and be part of different devices. For example, the first information exchange port 101 may be a part of the requester terminal 130, and the second information exchange port 102 may be part of the provider terminal 140.

In some embodiments, the server 110 may be a single server, or a server group. The server group may be centralized, or distributed (e.g., the server 110 may be a distributed system) . In some embodiments, the server 110 may be implemented on a cloud platform. Merely by way of example, the cloud platform may include a private cloud, a public cloud, a hybrid cloud, a community cloud, a distributed cloud, an inter-cloud, a multi-cloud, or the like, or any combination thereof. In some embodiments, the server 110 may be implemented on a computing device having one or more components illustrated in FIG. 2 in the present disclosure.

In some embodiments, the server 110 may include a processing device 112. The processing device 112 may process information and/or data relating to an order request to perform one or more functions described in the present disclosure. For example, the processing device 112 may obtain an order request from a mobile device of a service requester via the first information exchange port 101, and determine whether the order request is an emergency order request by processing features of the order request. As another example, the processing device 112 may preferentially allocate the order request to a service provider if the order request is identified as the emergency order request. In some embodiments, the processing device 112 may include one or more processors (e.g., single-core processor (s) or multi-core processor (s) ) . Merely by way of example, the processing device 112 may include a central processing unit (CPU) , an application-specific integrated circuit (ASIC) , an application-specific instruction-set processor (ASIP) , a graphics processing unit (GPU) , a physics 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.

The storage device 120 may store data and/or instructions. In some embodiments, the storage device 120 may store data obtained/acquired from requester terminal 130 and/or provider terminal 140. In some embodiments, the storage device 120 may store data and/or instructions that the server 110 may execute or use to perform exemplary methods and/or processes described in the present disclosure. In some embodiments, the storage device 120 may include a mass storage, a removable storage, a volatile read-and-write memory, a read-only memory (ROM) , or the like, or any combination thereof. Exemplary mass storage may include a magnetic disk, an optical disk, a solid-state drive, etc. Exemplary removable storage may include a flash drive, a floppy disk, an optical disk, a memory card, a zip disk, a magnetic tape, etc. Exemplary volatile read-and-write memory may include a random-access memory (RAM) . Exemplary RAM may include a dynamic RAM (DRAM) , a double date rate synchronous dynamic RAM (DDR SDRAM) , a static RAM (SRAM) , a thyristor RAM (T-RAM) , and a zero-capacitor RAM (Z-RAM) , etc. Exemplary ROM may include a mask ROM (MROM) , a programmable ROM (PROM) , an erasable programmable ROM (PEROM) , an electrically erasable programmable ROM (EEPROM) , a compact disk ROM (CD-ROM) , and a digital versatile disk ROM, etc. In some embodiments, the storage device 120 may be implemented on a cloud platform. Merely by way of example, the cloud platform may include a private cloud, a public cloud, a hybrid cloud, a community cloud, a distributed cloud, an inter-cloud, a multi-cloud, or the like, or any combination thereof.

In some embodiments, the storage device 120 may be connected to or communicate with the server 110. The server 110 may access data or instructions stored in the storage device 120 directly or via a network. In some embodiments, the storage device 120 may be a part of the server 110.

In some embodiments, a service requester may be a user of the requester terminal 130. In some embodiments, the user of the requester terminal 130 may be someone other than the requester. For example, a user A of the requester terminal 130 may use the requester terminal 130 to send a service request for a user B, or receive service and/or information or instructions from the server 110. In some embodiments, a service provider may be a user of the provider terminal 140. In some embodiments, the user of the provider terminal 140 may be someone other than the provider. For example, a user C of the provider terminal 140 may use the provider terminal 140 to receive an order request for a user D, and/or information or instructions from the server 110. In some embodiments, “requester” and “requester terminal” may be used interchangeably, “user” and “user terminal” may be used interchangeably, and “provider” and “provider terminal” may be used interchangeably. For an on-demand transportation service, a requester may be a passenger, a provider may be a driver.

In some embodiments, the requester terminal 130 may include a mobile device 130-1, a tablet computer 130-2, a laptop computer 130-3, a built-in device in a motor vehicle 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 device may include a smart lighting device, a control device of an intelligent electrical apparatus, a smart monitoring device, a smart television, a smart video camera, an interphone, or the like, or any combination thereof. In some embodiments, the wearable device may include a smart bracelet, a smart footgear, smart glasses, a smart helmet, a smart watch, smart clothing, a smart backpack, a smart accessory, or the like, or any combination thereof. In some embodiments, the smart mobile device may include a smartphone, a personal digital assistance (PDA) , a gaming device, 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 the augmented reality device may include a virtual reality helmet, a virtual reality glass, a virtual reality patch, an augmented reality helmet, augmented reality glasses, an augmented reality patch, or the like, or any combination thereof. For example, the virtual reality device and/or the augmented reality device may include a Google ^TM Glass, an Oculus Rift, a HoloLens, a Gear VR, etc. In some embodiments, the built-in device in the vehicle 130-4 may include an onboard computer, an onboard television, etc. In some embodiments, the requester terminal 130 may be a device with positioning technology (e.g., GPS) for locating the position of the requester and/or the requester terminal 130.

In some embodiments, the provider terminal 140 may be a device that is similar to, or the same as the requester terminal 130. In some embodiments, the provider terminal 140 may be a device utilizing positioning technology for locating the position of a user of the provider terminal 140 (e.g., a service provider) and/or the provider terminal 140. In some embodiments, the requester terminal 130 and/or the provider terminal 140 may communicate with one or more other positioning devices to determine the position of the requester, the requester terminal 130, the provider, and/or the provider terminal 140. In some embodiments, the requester terminal 130 and/or the provider terminal 140 may send positioning information to the server 110. In some embodiments, the requester terminal 130 and/or the provider terminal 140 may display information related with an order request (e.g., a pick-up location, a drop-off location, a route) .

In some embodiments, each service provider may correspond to the vehicle 150. The vehicle 150 may carry the passenger and travel to the destination. The vehicle 150 may include a plurality of vehicles 150-1, 150-2, 150-3, …, etc. One vehicle may correspond to one type of services (e.g., a car hailing service, a chauffeur service, an express car service, a carpool service, a bus service, a driver hire service, or a shuttle service) .

A positioning system 160 may determine information associated with an object or a target, for example, one or more service requesters, one or more service providers, one or more vehicles. In some embodiments, the positioning system 160 may be a global positioning system (GPS) , a global navigation satellite system (GLONASS) , a compass navigation system (COMPASS) , a BeiDou navigation satellite system, a Galileo positioning system, a quasi-zenith satellite system (QZSS) , etc. The information may include a location, an elevation, a velocity, or an acceleration of the object, or a current time. The positioning system 160 may include one or more satellites, for example, a satellite 160-1, a satellite 160-2, and a satellite 160-3. The satellites 160-1 through 160-3 may determine the information mentioned above independently or jointly. The positioning system 160 may transmit the information mentioned above to the requester terminal 130, the provider terminal 140, or the vehicle 150 via wireless connections. In some embodiments, the positioning system 170 may transmit the information to the server 110 directly.

Networks 170-1 through 170-3 may facilitate exchange of information and/or data. In some embodiments, one or more components in the O2O service system 100 (e.g., the server 110 and/or the storage device 120) may transmit and/or receive information and/or data to/from the requester terminal 130 and/or the provider terminal 140 via the networks 170-1 through 170-3. For example, the server 110 may obtain data relating to a service request via the network 170-1. As another example, the server 110 may obtain availability status of a service provider via the network 170-2. In some embodiments, the networks 170-1 through 170-3 may be any type of wired or wireless networks, or combination thereof. Merely by way of example, the networks 170 may include a cable network, a wireline network, an optical fiber network, a telecommunications network, an intranet, an Internet, a local area network (LAN) , a wide area network (WAN) , a wireless local area network (WLAN) , a metropolitan area network (MAN) , a wide area network (WAN) , a public telephone switched network (PSTN) , a Bluetooth ^TM network, a ZigBee ^TM network, a near field communication (NFC) network, a global system for mobile communications (GSM) network, a code-division multiple access (CDMA) network, a time-division multiple access (TDMA) network, a general packet radio service (GPRS) network, an enhanced data rate for GSM evolution (EDGE) network, a wideband code division multiple access (WCDMA) network, a high speed downlink packet access (HSDPA) network, a long term evolution (LTE) network, a user datagram protocol (UDP) network, a transmission control protocol/Internet protocol (TCP/IP) network, a short message service (SMS) network, a wireless application protocol (WAP) network, a ultra wide band (UWB) network, an infrared ray, or the like, or any combination thereof.

FIG. 2 is a schematic diagram illustrating exemplary components of a computing device according to some embodiments of the present disclosure. The server 110, the storage device 120, the requester terminal 130, and/or the provider terminal 140 may be implemented on the computing device 200 according to some embodiments of the present disclosure. The particular system may use a functional block diagram to explain the hardware platform containing one or more user interfaces. The computer may be a computer with general or specific functions. Both types of the computers may be configured to implement any particular system according to some embodiments of the present disclosure. The computing device 200 may be configured to implement any components that perform one or more functions disclosed in the present disclosure. For example, the computing device 200 may implement any component of the O2O service system 100 as described herein. In FIGs. 1-2, only one such computer device is shown purely for convenience purposes. One of ordinary skill in the art would understood at the time of filing of this application that the computer functions relating to the service as described herein may be implemented in a distributed fashion on a number of similar platforms, to distribute the processing load.

The computing device 200, for example, may include COM ports 250 connected to and from a network connected thereto to facilitate data communications. The computing device 200 may also include a processor (e.g., the processor 220) , in the form of one or more processors (e.g., logic circuits) , for executing program instructions. For example, the processor may include interface circuits and processing circuits therein. The interface circuits may be configured to receive electronic signals from a bus 210, wherein the electronic signals encode structured data and/or instructions for the processing circuits to process. The processing circuits may conduct logic calculations, and then determine a conclusion, a result, and/or an instruction encoded as electronic signals. Then the interface circuits may transmit out the electronic signals from the processing circuits via the bus 210.

The exemplary computing device may include the internal communication bus 210, program storage and data storage of different forms including, for example, a disk 270, and a read-only memory (ROM) 230, or a random-access memory (RAM) 240, for various data files to be processed and/or transmitted by the computing device. The exemplary computing device may also include program instructions stored in the ROM 230, RAM 240, and/or other type of non-transitory storage medium to be executed by the processor 220. The methods and/or processes of the present disclosure may be implemented as the program instructions. The computing device 200 also includes an I/O component 260, supporting input/output between the computer and other components. The computing device 200 may also receive programming and data via network communications.

Merely for illustration, only one processor and/or processor is illustrated in FIG. 2. Multiple CPUs and/or processors are also contemplated; thus operations and/or method steps performed by one CPU and/or processor as described in the present disclosure may also be jointly or separately performed by the multiple CPUs and/or processors. For example, if in the present disclosure the CPU and/or processor of the computing device 200 executes both operation A and operation B, it should be understood that operation A and operation B may also be performed by two different CPUs and/or processors jointly or separately in the computing device 200 (e.g., the first processor executes operation A and the second processor executes operation B, or the first and second processors jointly execute operations A and B) .

FIG. 3 is a block diagram illustrating exemplary hardware and/or software components of an exemplary mobile terminal according to some embodiments of the present disclosure. The requester terminal 130 or the provider terminal 140 may be implemented on the mobile device 300 according to some embodiments of the present disclosure. As illustrated in FIG. 3, the mobile device 300 may include a communication module 310, a display 320, a graphic processing unit (GPU) 330, a central processing unit (CPU) 340, an I/O 350, a memory 360, and a storage 390. The CPU 340 may include interface circuits and processing circuits similar to the processor 220. In some embodiments, any other suitable component, including but not limited to a system bus or a controller (not shown) , may also be included in the mobile device 300. In some embodiments, a mobile operating system 370 (e.g., iOS ^TM, Android ^TM, Windows Phone ^TM, etc. ) and one or more applications 380 may be loaded into the memory 360 from the storage 390 in order to be executed by the CPU 340. The applications 380 may include a browser or any other suitable mobile apps for receiving and rendering information relating to a service request or other information from the O2O service system 100 on the mobile device 300. User interactions with the information stream may be achieved via the I/O devices 350 and provided to the processing device 112 and/or other components of the O2O service system 100 via the network (e.g., the network 170-1, 170-2 or 170-3) .

In order to implement various modules, units and their functions described above, a computer hardware platform may be used as hardware platforms of one or more elements (e.g., a component of the sever 110 described in FIG. 1) . Since these hardware elements, operating systems, and program languages are common, it may be assumed that persons skilled in the art may be familiar with these techniques and they may be able to provide information required in the order request identification according to the techniques described in the present disclosure. A computer with user interface may be used as a personal computer (PC) , or other types of workstations or terminal devices. After being properly programmed, a computer with user interface may be used as a server. It may be considered that those skilled in the art may also be familiar with such structures, programs, or general operations of this type of computer device. Thus, extra explanations are not described for the figures.

FIG. 4 is a block diagram illustrating an exemplary processing device according to some embodiments of the present disclosure. The processing device 112 may include an acquisition module 410, a model determination module 420, an order identification module 430, an order allocation module 440, a charge determination module 450, and a transmitting module 460. The modules may be hardware circuits of at least part of the processing device 112. The modules may also be implemented as an application or set of instructions read and executed by the processing device 112. Further, the modules may be any combination of the hardware circuits and the application/instructions. For example, the modules may be the part of the processing device 112 when the processing device 112 is executing the application/set of instructions.

The acquisition module 410 may receive an order request from a mobile device (e.g., the requester terminal 130) of a service requester via the information exchange port system (e.g., the first information exchange port 101) . The order request may include a real-time request, or an appointment request. The acquisition module 410 may extract features of the received order request, and transmit the features to the order identification module 430 for identifying whether the received order request is an emergency order request. The emergency order request may refer to an order request indicating urgent demand for a service (e.g., a car-hailing service) in some emergency or urgent cases. In some embodiments, the emergency order request may refer to an order request that has specific deadline for reaching the destination; in some embodiments, the emergency order request may refer to an order request that is associated with an important matter to the requester. For example, for seeing a doctor as soon as possible, a patient sends out a car-hailing service request that is from his/her home to a hospital. In this case, the car-hailing service request may be designated as an emergency order request, which indicates that the service requester (i.e., the patient) may have an urgent demand for the car-hailing service.

The acquisition module 410 may obtain a plurality of labelled historical orders. The plurality of labelled historical orders may include a first portion of emergency orders and a second portion of non-emergency orders. In some embodiments, the emergency order may be labelled by “1” , and the non-emergency order may be labelled by “0” . The plurality of labelled historical orders may include orders in a certain time period in the past, for example, three days, one week, one month, half year, one year, etc. The acquisition module 410 may further extract one or more features of each labelled historical order. In some embodiments, the one or more features may include but not limited to an order time, a pick-up time, a pick-up location, a drop-off location, a Point of Interest (POI) type of the drop-off location, a user portrait, a trip mode, a weather condition, a waiting time period, etc.

The model determination module 420 may apply the one or more features of the plurality of labelled historical orders to train the original machine-learning identification model. The original machine-learning identification model may be preset based on different training goals. For example, the original machine-learning identification model may be a category-based model or a regression-based model. In preferred embodiments, the original machine-learning identification model may be the category-based model. For the original machine-learning model, the parameters of the model need be trained/optimized based on the one or more features. Exemplary machine-learning identification model may include an Extreme Gradient Boosting (Xgboost) model, a decision tree model, a Gradient Boosted Decision Tree (GBDT) model, a neural network model, or the like, or any combination thereof. In some embodiments, the machine-learning identification model may be the Xgboost model. The Xgboost model may include one or more trees. Each tree may include a plurality of nodes, such as the root node and the leaf node.

During training, the model determination module 420 may generate one or more trees (e.g., a tree 710 shown in FIG. 7A or a tree 720 shown in FIG. 7B) based on the features. For each of the one or more trees, the model determination module 420 may firstly determine a root node corresponding to a first feature (e.g., the root node 711 shown in FIG. 7A or the root node 721 shown in FIG. 7B) . The model determination module 420 may further split the root node into a plurality of leaf nodes based on different features (e.g., the leaf nodes 712-1 and 712-2) . The model determination module 420 may generate a whole tree by further splitting the one or more leaf nodes. The model determination module 420 may update one or more parameters associated with the original machine-learning identification model by minimizing an objective function to obtain the trained identification model. In some embodiments, for the Xgboost model, the one or more parameters may include a structure of each tree and predicted score of each leaf node (also be called “leaf weight” ) . The objective function may include a loss function and a regularization term, for example, Equation (1) . The model determination module 420 may minimize the objective function based on an additive training (e.g., a boosting method) . More details about how to train the identification model may be found elsewhere in the present disclosure (e.g., FIG. 6, or FIGs. 7A-7B, and the descriptions thereof) .

The order identification module 430 may determine whether the order request is an emergency order request. More specifically, the order identification module 430 may process the features of the received order request with a trained identification model to determine whether the order request is the emergency request. The order identification module 430 may extract a plurality of features of the received order request, for example, a pick-up time, a pick-up location or a drop-off location, and input the plurality of features into the trained identification model. The trained identification model may output a predicted probability that indicates the order request is an emergency order request. The order identification module 430 may further determine whether the order request is the emergency order request based on the predicted probability. For example, if the predicted probability is equal to or greater than a predetermined threshold (e.g., 0.5, 0.6, 0.7, 0.8, 0.9 etc. ) , the order identification module 430 may identify the order request as the emergency order request. Otherwise, the order request may be identified as a non-emergency order request.

In some embodiments, if the order request is determined as an emergency order request, the order allocation module 440 may generate an order by preferentially allocating the order request to a service provider (i.e. pairing the order request with a service provider) . In contrast with a non-emergency order request, the emergency order request may be allocated preferentially to the service provider. For example, if the emergency order request and other non-emergency order requests are queuing up for order allocations by the processor, the order allocation module 440 may directly bypass the non-emergency order requests in a same queue with the emergency order request and perform the order allocation of the emergency order request preferentially. As another example, there may be more than one emergency requests in the queue, and the order allocation module 440 may bring all the emergency requests to the front of the queue and rank them based on their predicted probability. In some embodiments, the order may include a planned route that has a shortest ETA from the pick-up location to the drop-off location.

In some embodiments, if the order request is determined as an emergency order request, the charge determination module 450 may adjust a service charge of the order dynamically. In some embodiments, the service charge will not be adjusted. In some embodiments, the service charge of the order may be adjusted higher in contrast with a non-emergency order that is from a same pick-up location to a same drop-off location. In some embodiments, the service charge of the order may be adjusted higher only when other order requests are bypassed. In some embodiments, rise of the service charge may depend on predicted probability of the emergency order request.

The transmitting module 460 may transmit signals to the mobile device of the service requester (e.g., the requester terminal 130) via the information exchange port system (e.g., the first information exchange port 101) , the signals prompting the mobile device to display the order including adjusted service charge. For example, the order may be displayed on a user interface of the requester terminal 130 (e.g., a user interface 800 illustrated in FIG. 8) . In some embodiments, the signals may prompt the requester terminal 130 to display an inquiry to the service requester as to whether to the order request is truly an emergency order request. In some embodiments, the signals may further prompt the requester terminal 130 to display an inquiry to the service requester as to whether to accept the order. It should be understood that the order and/or the inquiry information may be displayed in various forms, for example, a message, an audio, a video, an image, etc. The service requester may confirm the order and/or the inquiry information in various forms, for example, a message, an audio, a video, an image, etc.

In some embodiments, the transmitting module 460 may transmit the signals according to any suitable communication protocol. The suitable communication protocol may include but not limited to Hypertext Transfer Protocol (HTTP) , Address Resolution Protocol (ARP) , Dynamic Host Configuration Protocol (DHCP) , File Transfer Protocol (FTP) , etc. It should be noted that the signal may include any wired signal and/or wireless signal.

It should be noted that the above description of the processing device 112 is merely provided for the purposes of illustration, and not intended to limit the scope of the present disclosure. For persons having ordinary skills in the art, multiple variations and modifications may be made under the teachings of the present disclosure. For example, the processing device 112 may further include a storage module facilitating data storage. However, those variations and modifications do not depart from the scope of the present disclosure.

FIG. 5 is a flowchart illustrating an exemplary process for identifying an emergency order request according to some embodiments of the present disclosure. In some embodiments, process 500 may be implemented in the O2O service system 100. For example, the process 500 may be stored in the storage device 120 and/or the storage (e.g., the ROM 230, the RAM 240, or the storage 390) in the form of instructions, and invoked and/or executed by the server 110 (e.g., the processing device 112 of the server 110, or the processor 220 of the computing device 200) .

In 502, the processor (e.g., the acquisition module 410 of the processing device 112) may receive an order request from a mobile device (e.g., the requester terminal 130) of a service requester. The order request may include a real-time request, or an appointment request. For example, the real-time request may be a request that requires a service provider to carry out the service immediately or at a defined time period reasonably close to the request time (e.g., 1 minute, 2 minutes, 3 minutes, etc. ) –real-time request. The appointment request may be a request that requires the service provider to carry out the service in an appointed time point (e.g., a certain moment in one hour later) –appointment request.

In some embodiments, the service requester sends out an order request for a transportation service with an application installed in the requester terminal 130, and the processor may receive the order request through the first information exchange port 101 in communication with the requester terminal 130. The order request may include a plurality of features, such as a pick-up location, a pick-up time and a drop-off location. The acquisition module 410 may extract the plurality of features of the order request, and transmit the plurality of features to the order identification module 430 for identifying whether the order request is an emergency order request. The emergency order request may refer to an order request indicating urgent demand for a service (e.g., a car-hailing service) in some emergency or urgent cases. In some embodiments, the emergency order request may refer to an order request that has specific deadline for reaching the destination; in some embodiments, the emergency order request may refer to an order request that is associated with an important matter to the requestor. For example, for seeing a doctor as soon as possible, a patient sends out a car-hailing service request that is from his/her home to a hospital. In this case, the car-hailing service request may be designated as an emergency order request, which indicates that the service requester (i.e., the patient) may have an urgent demand for the car-hailing service.

In some embodiments, the application (e.g., a car-hailing application) installed in the requester’s mobile device (e.g., the requester terminal 130) may detect a user input. In certain embodiments, the order request may be in the form of a partially-entered request that is not sent or a complete request that is not sent. In certain embodiments, such kind of yet-to-be sent order requests may also trigger the process as illustrated in the present disclosure (e.g., the process 500 illustrated in FIG. 5) .

In 504, the processor (e.g., the order identification module 430 of the processing device 112) may determine whether the order request is an emergency order request. More specifically, the processor may determine whether the order request is the emergency request by processing the features of the received order request. In some embodiments, the processor may process the features with a trained identification model.

In some embodiments, the processor may extract a plurality of features of the received order request, and input the plurality of features into the trained identification model. The trained identification model may output a predicted probability that indicates the order request is an emergency order request. The processor may further determine whether the order request is the emergency order request based on the predicted probability. For example, if the predicted probability is equal to or greater than a predetermined threshold (e.g., 0.5, 0.6, 0.7, 0.8, 0.9 etc. ) , the processor may identify the order request as the emergency order request. Otherwise, the order request may be identified as a non-emergency order request. In some embodiments, the predetermined threshold may be adjusted according to different scenarios and different goals. For example, if the processor detects that the drop-off location is a frequently visited place for the service requester (e.g., a work place) , the predetermined threshold may be adjusted higher. As another example, if the processor detects that the drop-off location is a place not often visited by the service requester, the predetermined threshold may be adjusted lower. For those skilled in the art, the predetermined threshold may be various, and such variations may be within the protect scope of the present disclosure.

The trained identification model may be generated by training an original machine-learning identification model with training data. The training data may include a plurality of labelled historical orders. The plurality of labelled historical orders may include a first portion of emergency orders and a second portion of non-emergency orders. In some embodiments, the emergency order and the non-emergency order may be labelled with a binary value respectively. For example, the emergency order may be labelled by “1” , the non-emergency order may be labelled by “0” .

In some embodiments, the machine-learning identification model may include an Extreme Gradient Boosting (Xgboost) model, a decision tree model, a Gradient Boosted Decision Tree (GBDT) model, a neural network model, and so on. In some embodiments, the machine-learning model may be the Xgboost model including one or more trees (e.g., a tree illustrated in FIG. 7A or FIG. 7B) . The one or more trees may be trained based on one or more features associated with the plurality of historical orders. Each tree may include one or more nodes, such as a root rode, a leaf node. During training, one or more parameters of the model may be updated by minimizing an objective function. The objective function may be constructed based on a loss function and/or a regularization term. In some embodiments, the one or more parameters may include a structure of each tree, a predicted score of each leaf node, and so on. When the objective function is minimized, the updated one or more parameters may be optimal for the identification model. The training process may be completed until the objective function is minimized. More details about how to train the identification model may be found elsewhere in the present disclosure (e.g., FIG. 6, or FIGs. 7A-7B, and the descriptions thereof) .

In 506, if the order request is determined as an emergency order request, the processor (e.g., the order allocation module 440 of the processing device 112) may generate an order by preferentially allocating the order request to a service provider (i.e. pairing the order request with a service provider) . In contrast with a non-emergency order request, the emergency order request may be allocated preferentially to the service provider. For example, if the emergency order request and other non-emergency order requests are queuing up for order allocations by the processor, the order allocation module 440 may directly bypass the non-emergency order requests in a same queue with the emergency order request and perform the order allocation of the emergency order request preferentially. As another example, there may be more than one emergency requests in the queue, and the order allocation module 440 may bring all the emergency requests to the front of the queue and rank them based on their predicted probability.

In some embodiments, the processor may allocate the emergency order request to a target service provider. More specifically, the processor may search one or more available service providers that are capable of providing transportation service within a first distance threshold. The first distance threshold may be any predetermined distance, for example, 3 kilometers, 4 kilometers, 5 kilometers, etc. In preferred embodiments, the first distance threshold is 3 kilometers. The processor may obtain an estimated time of arrival (ETA) from each available service provider’s current location to the pick-up location. The processor may select an available service provider having a shortest ETA as the target service provider. In some embodiments, if there are no available service providers within the first distance threshold, the processor may dynamically adjust the first distance threshold to a second distance threshold. The second distance threshold is larger than the first distance threshold. The processor may select a target service provider within the second distance threshold. In some embodiments, the processor may dynamically adjust the distance threshold in different scenarios, for example, in rainy weather, in rush hours (e.g., 7: 00 a.m. -9: 30 a.m., or 5: 00 p.m. -7: 00 p.m. ) .

In some embodiments, the order may include a planned route that has a shortest ETA from the pick-up location to the drop-off location. The processor may plan one or more routes from the pick-up location to the drop-off location, and obtain the ETA corresponding to each of the one or more routes. The processor may designate the route that has the shortest ETA as the route to be presented.

In 508, if the order request is determined as an emergency order request, the processor (e.g., the charge determination module 450 of the processing device 112) may adjust a service charge of the order dynamically. In some embodiments, the service charge will not be adjusted. In some embodiments, the service charge of the order may be adjusted higher in contrast with a non-emergency order that is from a same pick-up location to a same drop-off location. In some embodiments, the service charge of the order may be adjusted higher only when other order requests are bypassed. In some embodiments, rise of the service charge may depend on predicted probability of the emergency order request. For example, if the predetermined threshold is 0.5, a range of the predicted probability that is greater than or equal to 0.5 and less than 0.75 may be classified as a “low emergency” level, a range of the predicted probability that is greater than or equal to 0.75 and less than 0.90 may be classified as a “middle emergency” level, a range of the predicted probability that is greater than or equal to 0.90 may be classified as a “top emergency” level. In some embodiments, the service charge of an order corresponding to the “low emergency” level may rise by 30%, the service charge of an order corresponding to the “middle emergency” level may rise by 40%, and the service charge of an order corresponding to the “top emergency” level may rise by 50%. It should be noted that the emergency level does not reflect how urgent the matter is; the emergency level here reflects the likelihood that the order request is actually an emergency. Note that the classification of the emergency level and rise rule of the service charge may vary, and such variations are within the scope of the present disclosure.

In 510, the processor (e.g., the transmitting module 460 of the processing device 112) may transmit signals to the mobile device of the service requester (e.g., the requester terminal 130) via the information exchange port system (e.g., the first information exchange port 101) , the signals prompting the mobile device to display the order including adjusted service charge. In some embodiments, the order may be displayed on a user interface of the requester terminal 130 (e.g., a user interface 800 illustrated in FIG. 8) . In some embodiments, the signals may prompt the requester terminal 130 to display an inquiry to the service requester as to whether to the order request is truly an emergency order request. For example, the signals may direct the requester terminal 130 to display the inquiry information as a yes-or-no question, which allow the user to choose. In response to the user’s choice that the order request is not an emergency, the processing device 112 may revert to regular arrangement for order allocation. In response to the user’s choice that the order request is an emergency, the processing device 112 may proceed with preferential order allocation, along with other associated arrangements (e.g., dynamic service charge) , with or without prompting the user terminal to display further inquiry to the requestor.

In some embodiments, either after confirmation that the order request is an emergency or by omitting the step of inquiring the requestor, the signals from the processing device 112 may further prompt the requester terminal 130 to display an inquiry to the service requester as to whether to accept the order. For example, as shown in FIG. 8, the signals may direct the requester terminal 130 to display the inquiry information in a form of pop-up box on the user interface (e.g., the pop-up box 802) . Merely for illustration, the displayed inquiry information is “Dynamic Price Mode Open? ” . The dynamic price mode means that the processor may dynamically adjust the service charge of the order request. If the service requester accepts this mode, he/she may confirm the inquiry information by pressing/touching an “Accept” icon 804. Otherwise, the service requester may reject this mode by pressing/touching a “Reject” icon 806. It should be understood that the order and/or the inquiry information may be displayed in various forms, for example, a message, an audio, a video, an image, etc. The service requester may confirm the order and/or the inquiry information in various forms, for example, a message, an audio, a video, an image, etc.

In some embodiments, after receiving an answer from the service requester, the processor may transmit the answer information to the service provider through the information exchange port system (e.g., the second information exchange port 102) , then the service provider may take actions about the order through the provider terminal 140. For example, the service provider may send information about the order to service requester by a phone call, a message, or a dialog box in an application of the car-hailing service.

In some embodiments, the processor may transmit the signals according to any suitable communication protocol. The suitable communication protocol may include but not limited to Hypertext Transfer Protocol (HTTP) , Address Resolution Protocol (ARP) , Dynamic Host Configuration Protocol (DHCP) , File Transfer Protocol (FTP) , etc. It should be noted that the signal may include any wired signal and/or wireless signal.

It should be noted that the above description of the process 500 is merely provided for the purposes of illustration, and not intended to limit the scope of the present disclosure. For persons having ordinary skills in the art, multiple variations and modifications may be made under the teachings of the present disclosure. For example, operation 506 and operation 508 may be integrated into a single operation. As another example, operation 508 may be omitted, the processor may not send an inquiry information about dynamic adjustment of service charge of the emergency order request. However, these variations and modifications still remain in the scope of the present disclosure.

FIG. 6 is a flowchart illustrating an exemplary process for training a machine-learning identification model according to some embodiments of the present disclosure. In some embodiments, the process 600 may be implemented in the O2O service system 100. For example, the process 600 may be stored in the storage device 120 and/or the storage (e.g., the ROM 230, the RAM 240, or the storage 390) as the form of instructions, and invoked and/or executed by the server 110 (e.g., the processing device 112 of the server 110, or the processor 220 of the computing device 200) .

In 602, for each of a plurality of labelled historical orders, the processor (e.g., the acquisition module 410 of the processing device 112) may obtain one or more features associated with each labelled historical order. The plurality of labelled historical orders may include a first portion of emergency orders and a second portion of non-emergency orders. In some embodiments, the emergency order may be labelled by “1” , and the non-emergency order may be labelled by “0” . The plurality of labelled historical orders may include orders in a certain time period in the past, for example, three days, one week, one month, half year, one year, etc. The processor may further extract the one or more features of each labelled historical order. In some embodiments, the one or more features may include but not limited to an order time, a pick-up time, a pick-up location, a drop-off location, a Point of Interest (POI) type of the drop-off location, a user portrait, a trip mode, a weather condition, a waiting time period, etc.

The order time refers to a request time of the order. In some embodiments, the order time may be classified to a time bucket, for example, rush hours or non-rush hours. The exemplary POI type may include restaurant, shopping mall, hotel, transport station, financial service, medical organization, scenic region, enterprise and public institution, and so on. A plurality of POI types may be classified based on a clustering algorithm (e.g., K-means ) . For example, a region (e.g., a city, or a town) may be classified to a plurality of unit grids. A size and/or a shape of each unit grid may be preset. For example, the size of each unit grid may be 500 square meters, and the shape of each unit grid may be a regular hexagon. In some embodiments, the processor may integrate some unit grids to form a sub-region based on a clustering algorithm (e.g., K-means) . The processor may determine the POI type of the sub-region based on the number of the same or similar POIs. For example, assuming that a sub-region A includes 100 POIs in total, 90 POIs of the total 100 POIs relate to medical organization, then the POI type of the sub-region A may be designated as medical organization. Each sub-region may correspond to a type of POI. The POI type of the drop-off location may correspond to the POI type of the sub-region including the drop-off location. In some embodiments, the processor may determine the POI type of the drop-off location based on a third party database. The third party database may include POI types corresponding to a plurality of sub-regions. The processor may perform an inquiry operation for the third party database in order to determine the POI type of the drop-off location. In some embodiments, the inquiry operation may include Term Frequency-Inverse Document Frequency (TF-IDF) algorithm. The third party database may also provide information that, when combined with the features of the order request, helps to determine whether the order request is an emergency order request. For example, information from the third party database may indicate that an event (e.g., sporting event, or music event) will take place at a specific time at a certain POI in the future. The destination of the order request, when being aligned with the POI, and the closeness of the pick-up time to the specific time of the event, may indicate that the person making the request is going to the event. In certain embodiments, the time period between the pick-up time and the time of event, as well as the distance between the pick-up location and the destination, may indicate that the order request is an emergency order request.

The user portrait may include information about user preferences, for example, consuming habit, time preference, location preference, etc. In some embodiments, the user portrait may include travel habits of one or more classes of service requesters. Each of the one or more classes may include one or more service requesters having one similar/same aspect (e.g., hobbies or preferences) . The travel habits may include high-frequency routes (e.g., commute route) , high-frequency order times (e.g., commute time) , high- frequency trip modes, and so on. The trip model may include an Express car mode, an Expresspool car mode, a luxury car mode, a business van mode, etc. The weather condition may include sunny day, rainy day, snowy day, windy day, foggy day, etc. The waiting time period refers to a time period from request time of the order to pick-up time of the order. In some embodiments, the waiting time period may include one or more time intervals, for example, 30 seconds, 50 seconds, 1 minute, 2 minutes, 3 minutes, etc. It should be noted that the one or more features may not be limited to the descriptions above, for those skilled in the art, the more features, the better the model training.

In 604, the processor (e.g., the model determination module 420 of the processing device 112) may apply the one or more features of the plurality of labelled historical orders to train the original machine-learning identification model. The original machine-learning identification model may be preset based on different training goals. For example, the original machine-learning identification model may be a category-based model or a regression-based model. Either the category-based model or the regression-based model may be used to predict whether an order request is an emergency order request. In preferred embodiments, the original machine-learning identification model may be the category-based model. For the original machine-learning model, the parameters of the model need be trained/optimized based on the one or more features. Exemplary machine-learning identification model may include an Extreme Gradient Boosting (Xgboost) model, a decision tree model, a Gradient Boosted Decision Tree (GBDT) model, a neural network model, or the like, or any combination thereof. In some embodiments, the machine-learning model may be the Xgboost model. The Xgboost model may include one or more trees. Each tree may include a plurality of nodes, such as the root node and the leaf node.

In some embodiments, the processor may randomly sample a portion of historical orders from the plurality of labelled historical orders based on a first sampling rate (e.g., 0.7, 0.8, or 0, 9, etc) . The sampled portion of historical orders may be designated as the training set. For each sample of the training set, the processor may randomly sample a portion of features from the obtained one or more features based on a second sampling rate (e.g., 0.7, 0.8, or 0.9, etc) . The sampled portion of features may be designated as input of the model for training. The first sampling rate and the second sampling rate may be predetermined according to an empirical value. It should be understood that the first sampling rate and the second sampling rate may vary.

In some embodiments, the processor may preset the number of trees, and/or a maximum depth of each tree. For example, the number of trees may be set as 100, and the maximum depth of each tree may be set as 6. The depth of each tree refers to the number of nodes from the root node to a leaf node. For example, the maximum depth of the tree 710 shown in FIG. 7A is 3.

During training, the processor may generate one or more trees (e.g., a tree 710 shown in FIG. 7A or a tree 720 shown in FIG. 7B) based on the features. For each of the one or more trees, the processor may firstly determine a root node corresponding to a first feature (e.g., the root node 711 shown in FIG. 7A or the root node 721 shown in FIG. 7B) . The processor may determine the corresponding feature of the root node by comparing information gain or Gini index of each feature. For example, a feature that has a maximum information gain may be designated as the root node. As another example, a feature that has a minimum Gini index may be designated as the root node. The processor may further split the root node into a plurality of leaf nodes based on different features (e.g., the leaf nodes 712-1 and 712-2) . The processor may generate a whole tree by further splitting the one or more leaf nodes. Note that each node may include a group of labelled historical orders that satisfy a corresponding split rule. The split rule may relate to a feature. For example, the split rule for the root node 711 is that the POI type of the drop-off location is medical organization or shopping mall. The historical orders whose drop-off location are medical organization may be classified to the leaf node 712-1, the historical orders whose drop-off location are shopping mall may be classified to the leaf node 712-2. More details about the tree may be found elsewhere in the present disclosure (e.g., FIGs. 7A and 7B, and the descriptions thereof. )

In 606, the processor (e.g., the model determination module 420 of the processing device 112) may update one or more parameters associated with the original machine-learning identification model by minimizing an objective function to obtain the trained identification model. For the Xgboost model, the one or more parameters may include a structure of each tree and predicted score of each leaf node (also be called “leaf weight” ) . The processor may minimize the objective function based on an additive training (e.g., a boosting method) . More specially, assuming that there are n rounds training process (e.g., n≥1) : at the first round, the processor may generate a first tree; at the second round, the processor may generate a second tree based on the first tree and the minimization of the objective function. Similarly, at the n-th round, the processor may generate an n-th tree based on the (n-1) -th tree and the minimization of the objective function. The trained identification model that includes the generated n trees may be determined. The processor may further predict whether an order request is an emergency order request by using the trained identification model.

In some embodiments, the objective function may include a loss function and a regularization term. For example, the objective function may be expressed shown in Equation (1) :

Obj (θ) =L (θ) +∈ (θ) (1) ,

wherein Obj (θ) denotes the objective function, L (θ) denotes the loss function, and ∈ (θ) denotes the regularization term. The loss function may measure how well the model fits with the training data, and the regularization factor may measure the complexity of the model/tree.

In some embodiments, the loss function may be defined by a cross entropy. For example, the loss function L (θ) may be defined shown in Equation (2) :

wherein m denotes the number of training samples (or historical orders) , θ denotes the parameters of the model, y _i denotes a labelled value of each training sample (e.g., 0 or 1) , y′ _i denotes a predicted value of each training sample (also referred to herein as predicted probability) . For Equation (2) , 0×log0 = 0 may be defined.

In some embodiments, the regularization term ∈ (θ) may be defined shown in Equation (3) :

wherein γ and λ denote a preset hyper-parameter respectively, ω _i denotes a predicted score of a leaf, T denotes the number of trees.

It should be noted that the above description is merely provided for the purposes of illustration, and not intended to limit the scope of the present disclosure. For persons having ordinary skills in the art, multiple variations and modifications may be made under the teachings of the present disclosure. For example, the process 600 may also include an operation for testing robustness of the trained identification model based on a test set, and the test set may include a plurality of labelled historical orders. However, these variations and modifications still remain in the scope of the present disclosure.

FIGs. 7A and 7B are schematic diagrams illustrating an exemplary machine-learning identification model according to some embodiments of the present disclosure. The processor (e.g., the model determination module 420) may generate one or more trees as illustrated in FIG. 7A and FIG. 7B. The one or more trees may construct the identification model, and the identification model may be used to determine whether an order request is an emergency order request by processing one or more features associated with the order request.

As shown in FIG. 7A, a node 711 may be a root node related to a first feature (e.g., a POI type of the drop-off location) . The processor may split the root node 711 into a plurality of leaf nodes (e.g., a leaf node 712-1 and a leaf node 712-2) . Each of the plurality of leaf nodes may be obtained based on a split rule related to the first feature. For example, the leaf node 712-1 may be obtained based on a split rule that the POI type of the drop-off location is medical organization. In other words, training samples (e.g., historical orders) indicating the POI type of drop-off location is the medical organization may be processed to the leaf node 712-1. Similarly, the leaf node 712-2 may be obtained based on a split rule that the POI type of the drop-off location is shopping mall. In some embodiments, the plurality of leaf nodes (e.g., the leaf nodes 712-1 and 712-2) may each relate to a feature. For example, the leaf node 712-1 is related to route type and the leaf node 712-2 is related to an order time. Each of the leaf nodes may be further split into a plurality of secondary leaf nodes based on a split rule related to the corresponding feature. For example, the leaf node 712-1 may be split into a leaf node 713-1 and a leaf node 713-2 based on a split rule related to the route type (e.g., whether route type of the training sample is a high-frequency route or a low-frequency route) . The leaf node 712-2 may be split into a leaf node 713-3 and a leaf node 713-4 based on a split rule related to the order time (e.g., whether the order time of the training sample is rush hours or non-rush hours) . Similar to the tree 710, the tree 720 may be generated by splits of a root node 721. For example, leaf nodes 722-1, 722-2, and 722-3 may be generated in the first split of the root node 721 based on a split rule related to a feature of the root node 721 (e.g., a POI type of the drop-off location) . In some embodiments, the processor may generate a tree ensemble that includes a plurality of trees. In preferred embodiments, the tree ensemble may include 100 trees. The 100 trees may construct the identification model for predicting whether the input order is an emergency order. In some embodiments, the order identification module 430 may invoke the trained identification model to process the received order request.

Having thus described the basic concepts, it may be rather apparent to those skilled in the art after reading this detailed disclosure that the foregoing detailed disclosure is intended to be presented by way of example only and is not limiting. Various alterations, improvements, and modifications may occur and are intended to those skilled in the art, though not expressly stated herein. These alterations, improvements, and modifications are intended to be suggested by this disclosure, and are within the spirit and scope of the exemplary embodiments of this disclosure.

Moreover, certain terminology has been used to describe embodiments of the present disclosure. For example, the terms “one embodiment, ” “an embodiment, ” and “some embodiments” mean that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Therefore, it is emphasized and should be appreciated that two or more references to “an embodiment” or “one embodiment” or “an alternative embodiment” in various portions of this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures or characteristics may be combined as suitable in one or more embodiments of the present disclosure.

Further, it will be appreciated by one skilled in the art, aspects of the present disclosure may be illustrated and described herein in any of a number of patentable classes or context including any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof. Accordingly, aspects of the present disclosure may be implemented entirely hardware, entirely software (including firmware, resident software, micro-code, etc. ) or combining software and hardware implementation that may all generally be referred to herein as a “module, ” “unit, ” “component, ” “device, ” or “system. ” Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer readable media having computer readable program code embodied thereon.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including electro-magnetic, optical, or the like, 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 may communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable signal medium may be transmitted using any appropriate medium, including wireless, wireline, optical fiber cable, RF, or the like, or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C++, C#, VB. NET, Python or the like, conventional procedural programming languages, such as the "C" programming language, Visual Basic, Fortran 2003, Perl, COBOL 2002, 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, partly on the user's computer, 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 type of network, including 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 using an Internet Service Provider) or in a cloud computing environment or offered as a service such as a Software as a Service (SaaS) .

Furthermore, the recited order of processing elements or sequences, or the use of numbers, letters, or other designations therefore, is not intended to limit the claimed processes and methods to any order except as may be specified in the claims. Although the above disclosure discusses through various examples what is currently considered to be a variety of useful embodiments of the disclosure, it is to be understood that such detail is solely for that purpose, and that the appended claims are not limited to the disclosed embodiments, but, on the contrary, are intended to cover modifications and equivalent arrangements that are within the spirit and scope of the disclosed embodiments. For example, although the implementation of various components described above may be embodied in a hardware device, it may also be implemented as a software only solution, e.g., an installation on an existing server or mobile device.

Similarly, it should be appreciated that in the foregoing description of embodiments of the present disclosure, various features are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure aiding in the understanding of one or more of the various embodiments. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed subject matter requires more features than are expressly recited in each claim. Rather, claim subject matter lie in less than all features of a single foregoing disclosed embodiment.

Claims

A system for identifying an emergency order request in an online to offline service, comprising:

at least one storage device including one or more sets of instructions; and

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

receive an order request from a mobile device of a service requester, the order request including features that include at least a pick-up location, a pick-up time, and a drop-off location;

determine whether the order request is an emergency order request by processing the features of the order request;

in response to the determination that the order request is the emergency order request:

generate an order by preferentially allocating the order request to a service provider;

dynamically adjust a service charge of the order; and

transmit signals to the mobile device of the service requester, the signals prompting the mobile device to display the order including the adjusted service charge.
The system of claim 1, wherein the signals further prompt the mobile device to display an inquiry to the service requester as to whether to accept the order.
The system of any one of claims 1-2, wherein to generate an order by preferentially allocating the order request to a service provider, the at least one processor is configured to cause the system to:

select a target service provider that is available and has a shortest estimated time of arrival (ETA) from the target service provider’s current location to the pick-up location; and

allocate the order request to the target service provider.
The system of any one of claims 1-3, wherein to generate an order by preferentially allocating the order request to a service provider, the at least one processor is configured to further cause the system to:

bypass other service requests in a same queue with the service request from the service requester.
The system of any one of claims 1-4, wherein the processing the features of the order request comprises: processing the features of the order request with a trained identification model, wherein the trained identification model is generated by training an original machine-learning identification model with training data, the training data comprising a plurality of labelled historical orders.
The system of claim 5, wherein the training an original machine-learning identification model with training data comprises:

for each of the plurality of labelled historical orders, obtaining one or more features associated with each labelled historical order;

applying the one or more features of the plurality of labelled historical orders to train the original machine-learning identification model; and

updating one or more parameters associated with the original machine-learning identification model by minimizing an objective function to obtain the trained identification model, the objective function including a loss function.
The system of claim 6, wherein the one or more features associated with the plurality of labelled historical orders include an order time, a pick-up time, a pick-up location, a drop-off location, a Point of Interest (POI) type of the drop-off location, a user portrait, a trip mode, a weather condition, and a waiting time period.
The system of claim 7, wherein the user portrait includes travel habits of one or more classes of service requesters.
The system of any one of claims 1-8, wherein the order includes:

a planned route that has a shortest ETA from the pick-up location to the drop-off location.
A method for identifying an emergency order request in an online to offline service, the method implemented on a computing device having at least one processor and at least one computer-readable storage medium, the method comprising:

receiving an order request from a mobile device of a service requester, the order request including features that include at least a pick-up location, a pick-up time, and a drop-off location;

determining whether the order request is an emergency order request by processing the features of the order request;

in response to the determination that the order request is the emergency order request:

generating an order by preferentially allocating the order request to a service provider;

adjusting a service charge of the order dynamically; and

transmitting signals to the mobile device of the service requester, the signals prompting the mobile device to display the order including the adjusted service charge.
The method of claim 10, wherein the signals further prompt the mobile device to display an inquiry to the service requester as to whether to accept the order.
The method of any one of claims 10-11, wherein the generating an order by preferentially allocating the order request to a service provider comprises:

selecting a target service provider that is available and has a shortest estimated time of arrival (ETA) from the target service provider’s current location to the pick-up location; and

allocating the order request to the target service provider.
The method of any one of claims 10-12, wherein the generating an order by preferentially allocating the order request to a service provider further comprises:

bypassing other service requests in a same queue with the service request from the service requester.
The method of any one of claims 10-13, wherein the processing the features of the order request comprises: processing the features of the order request with a trained identification model, wherein the trained identification model is generated by training an original machine-learning identification model with training data, the training data comprising a plurality of labelled historical orders.
The method of claim 14, wherein the training an original machine-learning identification model with training data comprises:

for each of the plurality of labelled historical orders, obtaining one or more features associated with each labelled historical order;

applying the one or more features of the plurality of labelled historical orders to train the original machine-learning identification model; and

updating one or more parameters associated with the original machine-learning identification model by minimizing an objective function to obtain the trained identification model, the objective function including a loss function.
The method of claim 15, wherein the one or more features associated with the plurality of labelled historical orders include an order time, a pick-up time, a pick-up location, a drop-off location, a Point of Interest (POI) type of the drop-off location, a user portrait, a trip mode, a weather condition, and a waiting time period.
The method of claim 16, wherein the user portrait includes travel habits of one or more classes of service requesters.
The method of any one of claims 10-17, wherein the order includes:

a planned route that has a shortest ETA from the pick-up location to the drop-off location.
A non-transitory computer readable medium, comprising at least one set of instructions for identifying an emergency order request in an online to offline service, wherein when executed by at least one processor of a computing device, the at least one set of instructions causes the computing device to perform a method, the method comprising:

receiving an order request from a mobile device of a service requester, the order request including features that include at least a pick-up location, a pick-up time, and a drop-off location;

determining whether the order request is an emergency order request by processing the features of the order request;

in response to the determination that the order request is the emergency order request:

generating an order by preferentially allocating the order request to a service provider;

adjusting a service charge of the order dynamically; and

transmitting signals to the mobile device of the service requester, the signals prompting the mobile device to display the order including the adjusted service charge.