WO2016119749A1 - 一种订单分配***及方法 - Google Patents

一种订单分配***及方法 Download PDF

Info

Publication number
WO2016119749A1
WO2016119749A1 PCT/CN2016/072840 CN2016072840W WO2016119749A1 WO 2016119749 A1 WO2016119749 A1 WO 2016119749A1 CN 2016072840 W CN2016072840 W CN 2016072840W WO 2016119749 A1 WO2016119749 A1 WO 2016119749A1
Authority
WO
WIPO (PCT)
Prior art keywords
order
user
information
grab
time
Prior art date
Application number
PCT/CN2016/072840
Other languages
English (en)
French (fr)
Inventor
胡涛
崔玮
尹君
胡志琳
叶勇
杨平
邓晓琳
张雨
刘养彪
石宽
曹中宇
Original Assignee
北京嘀嘀无限科技发展有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from CN201510046647.2A external-priority patent/CN104599218B/zh
Priority claimed from CN201510078862.0A external-priority patent/CN104616065B/zh
Priority claimed from CN201510163336.4A external-priority patent/CN104766262A/zh
Priority claimed from CN201510172959.8A external-priority patent/CN104915855B/zh
Priority claimed from CN201510451956.8A external-priority patent/CN105117777A/zh
Priority claimed from CN201510456730.7A external-priority patent/CN105118013A/zh
Priority claimed from CN201510516346.1A external-priority patent/CN105139228A/zh
Priority claimed from CN201510516040.6A external-priority patent/CN105117842A/zh
Priority claimed from CN201510537192.4A external-priority patent/CN105096166A/zh
Priority to KR1020177024089A priority Critical patent/KR20180013843A/ko
Application filed by 北京嘀嘀无限科技发展有限公司 filed Critical 北京嘀嘀无限科技发展有限公司
Priority to SG11201706188YA priority patent/SG11201706188YA/en
Priority to EP16742811.9A priority patent/EP3252705A4/en
Priority to US15/547,221 priority patent/US10977585B2/en
Publication of WO2016119749A1 publication Critical patent/WO2016119749A1/zh
Priority to PH12017501364A priority patent/PH12017501364B1/en
Priority to HK18104774.4A priority patent/HK1245473A1/zh
Priority to US17/227,439 priority patent/US20210232984A1/en

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/04Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/02Reservations, e.g. for tickets, services or events
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40Business processes related to the transportation industry
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q90/00Systems or methods specially adapted for administrative, commercial, financial, managerial or supervisory purposes, not involving significant data processing

Definitions

  • This application requires a Chinese application with the number 201510046647.2 submitted on January 29, 2015, a Chinese application with the number 201510078862.0 submitted on February 13, 2015, and a Chinese application with the number 201510163336.4 submitted on April 8, 2015, 2015.
  • the present application relates to systems and methods for order allocation, and more particularly to order allocation systems and methods that employ mobile internet technology and data processing techniques.
  • an order distribution system can include: a computer readable storage medium configured to store an executable module, comprising: a receiving unit configured to receive order information and user information, the user information including a location letter Information or time information; an order allocation unit configured to perform order allocation based on location information or time information.
  • a processor executable by the processor to execute the executable module of the computer readable storage medium.
  • the order distribution system may further include: a play order range determining module configured to acquire a order broadcast area or an order receiving range; an order number obtaining unit configured to obtain the number of orders within the broadcast order range; The order density acquisition unit is configured to obtain the order density based on the order broadcast area or the order receiving range, and the number of orders.
  • the order distribution system may further include: a grab ratio prediction unit configured to predict a user grab rate based on the location information or the time information.
  • the order distribution system may further include: a distance determining unit configured to acquire a distance between the user position and the departure place of the order or a road surface distance; and a grab rate prediction unit configured to be based on the distance or the road surface distance, Predict the user's grab rate.
  • the order distribution system may further include: an obtaining unit configured to acquire a historical broadcast time of the order or a historical grab time of the user; and a subscription probability calculation unit configured to be based on the historical broadcast time or The history of grabbing time, predicting the rate of user grabbing.
  • the rush rate prediction unit may be further configured to establish a user rush rate prediction model based on the location information or the time information.
  • the order distribution system may further include: an accuracy determining unit configured to determine an accuracy of the grab rate prediction.
  • the order distribution system may further include: an actual rush rate determination unit configured to determine a user's actual rush rate for the order; and an accuracy determination unit configured to rob the order based on the user's prediction Rate and actual grab rate, determine the accuracy of the grab rate prediction.
  • an order allocation method can include receiving order information and user information, the order information and the user information including location information or time information; and performing order distribution based on the location information or the time information.
  • a tangible, non-transitory computer readable Medium on which information can be stored.
  • the computer can execute the order allocation method.
  • Order allocation method can include receiving order information and user information, the order information and the user information including location information or time information; and performing order distribution based on the location information or the time information.
  • the location information may be one or more of a departure place, an origination place, a destination, coordinate information, and a geographical range.
  • the time information may be one or two of an order broadcast time and a user grab time.
  • the order allocation based on the location information may further include: acquiring a order broadcast area or an order receiving range, and an order number; obtaining an order density based on the order broadcast area or the order receiving range, and the order number; and based on the order Density, order allocation.
  • the order allocation based on the location information or the time information may further include: predicting a user's rush rate based on the location information or the time information; and performing the order allocation based on the user rush rate.
  • predicting the user's grab rate based on the location information may further include: obtaining a distance between the user location and the departure place of the order or a road surface distance; and predicting the user's grab rate based on the distance or the road surface distance.
  • predicting the user's grab rate according to the time information may further include: acquiring a historical broadcast time of the order or a historical grab time of the user; and predicting the user's grab based on the historical broadcast time or the historical grab time rate.
  • predicting the user's rush rate may further include: acquiring location information or time information of the order; establishing a user rush rate prediction model based on the location information or the time information; and predicting a model based on the user rush rate prediction User grab rate.
  • predicting the user's grab rate may further include determining the accuracy of the user's grab rate prediction.
  • determining the user's rush rate prediction accuracy may further include: obtaining a predicted rush rate of the user for the order; determining a user's actual rush rate for the order; and based on the user's predicted rush rate and actual Grab the rate and determine the rate of grabbing Accuracy.
  • FIG. 1 is a schematic diagram of a network environment including a location based service system, according to some embodiments of the present application;
  • FIG. 2 is a schematic illustration of an order distribution system 110, shown in accordance with some embodiments of the present application;
  • FIG. 3 is a schematic illustration of an order distribution system 110, shown in accordance with some embodiments of the present application.
  • FIG. 4 is an exemplary flow chart of an order allocation method shown in accordance with some embodiments of the present application.
  • FIG. 5 is a schematic illustration of an order distribution system 110, shown in accordance with some embodiments of the present application.
  • FIG. 6 is an exemplary flowchart of an order allocation method shown in accordance with some embodiments of the present application.
  • FIG. 7 is a schematic illustration of an order distribution system 110, shown in accordance with some embodiments of the present application.
  • FIG. 8 is an exemplary flowchart of an order allocation method according to some embodiments of the present application.
  • FIG. 9 is an exemplary flowchart of an order allocation method shown in accordance with some embodiments of the present application.
  • FIG. 10 is a schematic illustration of an order distribution system 110, shown in accordance with some embodiments of the present application.
  • FIG. 11 is a schematic illustration of an order distribution system 110, shown in accordance with some embodiments of the present application.
  • FIG. 12 is an example of an order allocation method according to some embodiments of the present application. Sexual flow chart
  • FIG. 13 is an exemplary flowchart of an order allocation method according to some embodiments of the present application.
  • FIG. 14 is a schematic illustration of an order distribution system 110, shown in accordance with some embodiments of the present application.
  • 16 is a schematic illustration of an order distribution system 110, shown in accordance with some embodiments of the present application.
  • FIG. 17 is an exemplary flowchart of an order allocation method shown in accordance with some embodiments of the present application.
  • 18 is a schematic illustration of an order distribution system 110, shown in accordance with some embodiments of the present application.
  • 21A is an exemplary schematic diagram of an order allocation method according to some embodiments of the present application.
  • 21B is an exemplary schematic diagram of a rush time distribution according to some embodiments of the present application.
  • 22 is a schematic illustration of an order distribution system 110, shown in accordance with some embodiments of the present application.
  • 25 is a schematic illustration of an order distribution system 110, shown in accordance with some embodiments of the present application.
  • 26 is an exemplary flowchart of an order allocation method shown in accordance with some embodiments of the present application.
  • FIG. 27 is an exemplary flowchart of an order allocation method according to some embodiments of the present application.
  • FIG. 28 is a block diagram showing the structure of a mobile device that can implement the specific system disclosed in the present application.
  • Figure 29 is a block diagram showing the structure of a computer that can implement the particular system disclosed in this application.
  • “single rate”, “single probability”, “user's rate”, “user terminal's probability of grabbing”, “ Words such as order grab rate, “order grab probability” and / or “subscription probability” can refer to the probability that the user will perform a grab operation on the order.
  • uppercase and lowercase English letters (for example, A, D, M, N, P, R, n, t, etc.) in the embodiments and/or the drawings are merely code numbers for convenience of describing the application. .
  • it may have the same or different meanings, which may be determined according to actual scenarios.
  • Words such as “broadcast”, “send”, and/or “push” may refer to the system transmitting information to a user.
  • Embodiments of the present application may be applied to different transportation systems including, but not limited to, one or a combination of terrestrial, marine, aerospace, aerospace, and the like. For example, taxis, buses, trains, buses, trains, trains, high-speed rail, subways, ships, airplanes, spaceships, hot air balloons, unmanned vehicles, receiving/delivery, etc., apply and manage transport systems. .
  • Application scenarios of different embodiments of the present application include, but are not limited to, a combination of one or more of a web page, a browser plug-in, a client, a customization system, an in-house analysis system, an artificial intelligence robot, and the like. It should be understood that the application scenarios of the system and method of the present application are only some examples or embodiments of the present application. For those skilled in the art, according to the drawings, without any creative work, This application is applied to other similar scenarios. For example, other similar order distribution systems.
  • the "passenger”, “order requester (party)”, “customer”, “demander”, “service demander”, “consumer”, “consumer”, “user demander”, etc. described in the present application are Interchanged refers to the party that needs or subscribes to the service, which can be an individual, an entity or a tool.
  • the "driver”, “order receiver (party)”, “provider”, “supplier”, “service provider”, “servicer”, “service party”, etc. described herein are also interchangeable. Refers to individuals, tools or other entities that provide services or assist in providing services.
  • the "user”, “terminal” and/or “user terminal” described in the present application may be a party that needs or subscribes to a service, or may be a party that provides a service or assists in providing a service.
  • FIG. 1 illustrated in FIG. 1 is a schematic diagram of a network environment including a location based service system, in accordance with some embodiments of the present application.
  • the location based service system 100 can include one or more on-demand service systems 105, one or more passenger terminals 120, one or more databases 130, one or more drivers 140, one or more networks 150, one or Multiple other sources of information 160.
  • the on-demand service system 105 can include an order distribution system 110.
  • the order distribution system 110 can be used in a system that analyzes the collected information to generate an analysis result.
  • the order distribution system 110 can be a server, can be part of a server, or can be a server group.
  • a server group can be centralized, such as a data center.
  • a server group can also be distributed, such as a distributed system.
  • the order distribution system 110 can be local or remote. In some embodiments, the order distribution system 110 can access information accessing the user 120/140, information in other information sources 160, and/or information in the database 130 via the network 150 or other means of communication.
  • the passenger terminal 120 and the driver terminal 140 may be collectively referred to as a user, a user terminal, or a terminal, and may be a person, a tool, or other entity formed by a service order in various forms, such as a requester and a service provider of a service order.
  • Passengers can be service demanders.
  • the passenger may also include a user of the passenger end device 120. In some embodiments, the user may not be the passenger himself.
  • user A of passenger terminal device 120 may use passenger terminal device 120 to request on-demand service for passenger B, or to accept other information or instructions sent by on-demand service or on-demand service system 105.
  • the user of the passenger end device 120 may also be referred to herein simply as a passenger.
  • the driver can be a service provider. In this article, “driver”, “driver” and “driver device” are used interchangeably.
  • the driver may also include a user of the driver's end device 140. In some embodiments, the user may not be the driver himself.
  • user C of driver device 140 may use driver device 140 to accept other information or instructions sent by driver D to on-demand service or on-demand service system 105.
  • the user of the driver device 120 may also be referred to simply as a driver.
  • the passenger terminal 120 may include, but is not limited to, one of the desktop computer 120-1, the notebook computer 120-2, the built-in device 120-3 of the motor vehicle, the mobile device 120-4, or the like. Several combinations. Further, the built-in device 120-3 of the motor vehicle may be a carputer or the like. In some embodiments, these users may also be some other smart terminals including, but not limited to, smart home devices, wearable devices, smart mobile devices, or other smart devices.
  • smart home devices it may include, but is not limited to, a combination of one or more of intelligent lighting devices, smart electrical control devices, intelligent monitoring devices, smart televisions, smart cameras, smart phones, walkie-talkies, etc.; for wearable devices, Including but not limited to a combination of smart bracelets, smart watches, smart footwear, smart glasses, smart helmets, smart headbands, smart clothing, smart backpacks, smart accessories, etc.; for smart mobile devices, This includes, but is not limited to, a combination of one or more of a built-in device of a vehicle (on-board computer or car TV, etc.), a gaming device, a GPS device, a POS machine, and the like.
  • Driver terminal 140 may also include one or more of similar devices.
  • database 130 can be broadly referred to as a device having a storage function.
  • the database 130 is primarily used to store data collected from the users 120/140 and various data generated in the operation of the order distribution system 110.
  • Database 130 or other storage devices within the system generally refer to all media that can have read/write capabilities.
  • the database 130 or other storage devices in the system may be internal to the system or external devices of the system.
  • Database 130 can be local or remote.
  • Database 130 may include, but is not limited to, a combination of one or more of a hierarchical database, a networked database, and a relational database.
  • the database 130 can digitize the information and store it in a storage device that utilizes electrical, magnetic or optical means.
  • Database 130 can be used to store various information such as systems, software, programs, information, and data.
  • the database 130 may be a device that stores information by means of electrical energy, such as various memories, random access memory (RAM), read only memory (ROM), and the like.
  • the random access memory includes but is not limited to a decimal counter tube, a selection tube, a delay line memory, a Williams tube, a dynamic random access memory (DRAM), a static random access memory (SRAM), a thyristor random access memory (T-RAM), and a zero capacitor.
  • DRAM dynamic random access memory
  • SRAM static random access memory
  • T-RAM thyristor random access memory
  • Z-RAM random access memory
  • Read-only memory includes, but is not limited to, bubble memory, magnetic button line memory, thin film memory, magnetic plate line memory, magnetic core memory, drum memory, optical disk drive, hard disk, magnetic tape, early non-volatile memory (NVRAM), phase change Memory, magnetoresistive random storage memory, Ferroelectric random access memory, nonvolatile SRAM, flash memory, electronic erasable rewritable read only memory, erasable programmable read only memory, programmable read only memory, shielded heap read memory, floating connection gate random access A combination of one or more of a memory, a nano random access memory, a track memory, a variable resistance memory, a programmable metallization unit, and the like.
  • the database 130 may be a device that stores information using magnetic energy, such as a hard disk, a floppy disk, a magnetic tape, a magnetic core memory, a magnetic bubble memory, a USB flash drive, a flash memory, or the like.
  • the database 130 may be a device that optically stores information, such as a CD or a DVD or the like.
  • the database 130 may be a device that stores information by magneto-optical means, such as a magneto-optical disk or the like.
  • the access mode of the database 130 may be one or a combination of random storage, serial access storage, read-only storage, and the like.
  • the database 130 can be a non-permanent memory or a permanent memory.
  • the storage devices mentioned above are just a few examples, and the storage devices that the system can use are not limited thereto.
  • the database 130 can be interconnected or communicated with the network 150, or can be directly connected or communicated with the on-demand service system 105 or a portion thereof (e.g., the order distribution system 110), or a combination of the two. In some embodiments, database 130 can be placed in the background of on-demand service system 105. In some embodiments, database 130 can be self-contained and directly coupled to network 150. The connection or communication between the database 130 and other modules of the system may be wired or wireless. Network 150 can provide a conduit for information exchange. When the database 130 and the network 150 are connected or communicating with each other, the user 120/140 can access the information in the database 130 via the network 150. The access rights of the parties to the database 130 can be limited.
  • the on-demand service system 105 has the highest access to the database 130, and can read or modify public or personal information from the database 130; the passenger device 120 or The driver device 140 can read some of the public's information or personal information related to the user when certain conditions are met.
  • the on-demand service system 105 can update/modify the information of the public or related to the user in the database 130 based on the experience of one or more users of a user (passenger or driver) using the on-demand service system 105.
  • a driver when a driver receives a service order from a passenger, he can view part of the information about the passenger in the database 130; but the driver cannot modify the information about the passenger in the database 130, but can only press
  • the service system 105 is required to report, and the on-demand service system 105 determines whether to modify the information about the passenger in the database 130.
  • a passenger may, when receiving a request for service from a driver, view part of the information about the driver in the database 130 (such as user rating information, driving experience, etc.); but the passenger may not modify the database autonomously.
  • the information about the driver in 130 can only be reported to the on-demand service system 105, and the on-demand service system 105 decides whether to modify the information about the driver in the database 130.
  • Network 150 can be a single network or a combination of multiple networks.
  • Network 150 may include, but is not limited to, a combination of one or more of a local area network, a wide area network, a public network, a private network, a wireless local area network, a virtual network, a metropolitan area network, a public switched telephone network, and the like.
  • Network 150 may include a variety of network access points, such as wired or wireless access points, base stations, or network switching points, through which the data sources connect to network 150 and transmit information over the network.
  • Other sources of information 160 are a source of additional information for the system.
  • Other sources of information 160 may be used to provide service related information to the system, such as weather conditions, traffic information, legal and regulatory information, news events, lifestyle information, lifestyle guide information, and the like.
  • Other information sources 160 may exist in the form of a single central server, or in the form of multiple servers connected by a network, or in the form of a large number of personal devices. When the information source exists in the form of a large number of personal devices, the devices can connect the cloud server with the user through a user-generated content, such as uploading text, sound, image, video, etc. to the cloud server. A large number of personal devices together form an information source.
  • Other information sources 160 may be interconnected or communicated with the network 150, or may be directly connected or in communication with the on-demand service system 105 or a portion thereof (e.g., the order distribution system 110), or a combination of the two. When other information sources 160 are connected or communicating with the network 150, the users 120/140 can access information in other information sources 160 over the network 150.
  • the connection or communication between other information sources 160 and other modules of the system may be wired or wireless.
  • the other information source 160 may be a municipal service system including map information and city service information, a traffic real-time broadcast system, a weather broadcast system, a news network, and the like.
  • Other sources of information 160 may be physical sources of information, such as common speed measuring devices, Sensing, IoT devices, such as the driver's on-board speedometer, on-board diagnostic system, radar speedometer on the road, temperature and humidity sensors, etc.
  • Other information sources 160 may also be sources for obtaining news, information, road real-time information, etc., such as a network information source, including but not limited to Usenet-based Internet newsgroups, servers on the Internet, weather information servers, road status information servers, etc. .
  • the other information source 160 may be a system that stores a plurality of catering service providers in a certain area, a municipal service system including map information and city service information, a traffic road condition system, a weather broadcast system, a news network, and the like. .
  • a municipal service system including map information and city service information, a traffic road condition system, a weather broadcast system, a news network, and the like.
  • the above examples are not intended to limit the scope of other information sources herein, nor are they limited to the scope of services of the examples.
  • the present application can be applied to any service, any device or network capable of providing information related to the corresponding service. Can be classified as other sources of information.
  • the object of the order can be any product.
  • the product can be a tangible product or an intangible product.
  • a physical product it can be any kind or combination of physical objects, such as food, medicine, daily necessities, chemical products, electrical appliances, clothing, automobiles, real estate, luxury goods, and the like.
  • intangible products including but not limited to a combination of one or more of a service product, a financial product, an intellectual product, an internet product, and the like.
  • Internet products it can be any product that meets the user's needs for information, entertainment, communication or business.
  • the mobile internet product therein may be software, a program or a system for use in a mobile terminal.
  • the mobile terminal includes, but is not limited to, a combination of one or more of a notebook, a tablet, a mobile phone, a personal digital assistant (PDA), an electronic watch, a POS machine, a car computer, a television, and the like.
  • PDA personal digital assistant
  • the travel software can be travel software, vehicle reservation software, map software, and the like.
  • the traffic reservation software refers to one of available for booking a car (such as a taxi, a bus, etc.), a train, a subway, a ship (a ship, etc.), an aircraft (aircraft, a space shuttle, a rocket), a hot air balloon, or the like. Several combinations.
  • database 130 may be a cloud computing platform with data storage capabilities, including but not limited to public clouds, private clouds, community clouds, hybrid clouds, and the like. Variations such as these are within the scope of the present application.
  • FIG. 2 shown in FIG. 2 is a schematic diagram of an order distribution system 110.
  • the order distribution system is illustrated with the order distribution system 110 in the on-demand service system 105 as an example.
  • the order distribution system 110 is described by taking a car service system as an example.
  • the order distribution system 110 can include one or more processing modules 210, one or more storage modules 220, one or more passenger interfaces 230, and one or more driver interfaces 240.
  • the modules of order distribution system 110 may be centralized or distributed.
  • One or more of the modules of the order distribution system 110 may be local or remote.
  • the order distribution system 110 can be one or a combination of a web server, a file server, a database server, an FTP server, an application server, a proxy server, a mail server, and the like.
  • the processing module 210 can be used for processing related information.
  • the processing module can obtain information from the passenger interface 230, the driver interface 240, the storage module 220, the database 130, other information sources 160, and the like.
  • the processing module 210 can send the processed information to the passenger interface 230 and/or the driver interface 240, and can save the processed information to the database 130 or the storage module 220 or other backed up database or storage device.
  • the manner of information processing may include, but is not limited to, a combination of one or several of storing, classifying, filtering, converting, calculating, retrieving, predicting, training, and the like.
  • the processing module 210 may include, but is not limited to, a central processing unit (CPU), an application specific integrated circuit (ASIC), and an application specific instruction set processor. (ASIP)), Physical Processing Unit (PPU), Digital Signal Processor (DSP), Field-Programmable Gate Array (FPGA), Programmable Logic Device (PLD), processor, microprocessor, A combination of one or more of a controller, a microcontroller, and the like.
  • CPU central processing unit
  • ASIC application specific integrated circuit
  • ASIP application specific instruction set processor
  • PPU Physical Processing Unit
  • DSP Digital Signal Processor
  • FPGA Field-Programmable Gate Array
  • PLD Programmable Logic Device
  • processor microprocessor
  • the foregoing processing module 210 or the database 130 may actually exist in the system, and may also perform corresponding functions through the cloud computing platform.
  • the cloud computing platform includes, but is not limited to, a storage-based cloud platform based on storage data, a computing cloud platform based on processing data, and an integrated cloud computing platform that takes into account data storage and processing.
  • the cloud platform used by the system can be a public cloud, a private cloud, a community cloud, or a hybrid cloud.
  • some order information and/or non-order information received by the system may be calculated and/or stored by the cloud platform according to actual needs.
  • Other order information and/or non-order information may be calculated and/or stored by a local processing module and/or a system database.
  • the passenger interface 230 and the driver interface 240 can be used to receive respective transmitted information from the passenger 120 and the driver 140, respectively.
  • the information herein may include, but is not limited to, one or a combination of request information of the service, reception information of the service, user's habit/favorite information, user location information, and the like.
  • the service request information may be a user's order request information (for example, a passenger's taxi request, a driver's order request, etc.), and other request information of the user (for example, the driver sends a request to the system to obtain an order density of a certain area). )Wait.
  • the receiving information of the service may be information that the user agrees to receive the order, information that the user gives up the order, information that the user has successfully received the order, information that the user fails to receive the order, and the like.
  • the user's habit/favorite information may be the passenger's preference for the driver, the waiting time that the passenger can receive, the passenger's preference for the carpooling passenger, the passenger's preference for the car, the driver's preference for the departure place, the destination, the departure time, and the like.
  • the form of the information may include, but is not limited to, one or a combination of text, audio, video, pictures, and the like.
  • the information input manner may be handwriting input, gesture input, image input, voice input, video input, electromagnetic wave input or other data input mode, or any combination of the above.
  • the received information may be stored in the database 130, may be stored in the storage module 220, may be calculated and processed by the processing module 210, or may be a combination of the above.
  • the acquisition of user location information can be accomplished by a location system.
  • information such as the current location, origin, motion state, speed of motion, etc. of the user may be obtained by one or more positioning techniques.
  • the positioning technology may include, but is not limited to, Global Positioning System (GPS) technology, Global Navigation Satellite System (GLONASS) technology, Beidou navigation system technology, Galileo positioning system (Galileo) technology, Quasi-Zenith satellite system (QAZZ) technology, base station positioning Technology, Wi-Fi positioning technology, various positioning and speed measuring systems that are provided by the vehicle.
  • GPS Global Positioning System
  • GLONASS Global Navigation Satellite System
  • Beidou navigation system technology Beidou navigation system technology
  • Galileo positioning system Galileo positioning system
  • QAZZ Quasi-Zenith satellite system
  • base station positioning Technology Wi-Fi positioning technology
  • Wi-Fi positioning technology various positioning and speed measuring systems that are provided by the vehicle.
  • the passenger interface 230 and the driver interface 240 can be used to output information processed by the processing module 210 for analysis.
  • the information here may be optimized positioning information, direct information of the order, processing information of the order, direct information of the user, processing information of the user, and the like.
  • the form of the information may include, but is not limited to, one or a combination of text, audio, video, pictures, and the like.
  • the outputted information may or may not be sent to the passenger 120 and/or the driver 140.
  • the output information that is not transmitted may be stored in the database 130 or may be stored in the storage module 220.
  • the system shown in Figure 2 can be implemented in a variety of ways.
  • the system can be implemented in hardware, software, or a combination of software and hardware.
  • the hardware portion can be implemented using dedicated logic; the software portion can be stored in memory and executed by a suitable instruction execution system, such as a microprocessor or dedicated design hardware.
  • a suitable instruction execution system such as a microprocessor or dedicated design hardware.
  • processor control code such as a carrier medium such as a magnetic disk, CD or DVD-ROM, such as read-only memory (firmware)
  • Such code is provided on a programmable memory or on a data carrier such as an optical or electronic signal carrier.
  • the system of the present application and its modules can be implemented not only with hardware such as very large scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, etc., or programmable hardware devices such as field programmable gate arrays, programmable logic devices, and the like. It can also be implemented by, for example, software executed by various types of processors, or by a combination of the above-described hardware circuits and software (for example, firmware).
  • FIG. 2 is not limited to the car service system, but can also be applied to other traffic service systems, and can also be applied to other service systems, for example, a reservation service system, a home service system, a reservation service system, and the like. This application does not limit this system.
  • the processing module 210, the storage module 220, the passenger interface 230, and the driver interface 240 may be different modules embodied in one system, or may be a module that implements two or more modules described above.
  • the passenger interface 230/driver interface 240 can be a module that has both input and output functions, and can also be an input module and an output module for the passenger/driver.
  • processing module 210 and the storage module 220 may be two modules, or one module may have both processing and storage functions.
  • each module can share a storage module, and each module can also have its own storage module. Variations such as these are within the scope of the present application.
  • the order distribution system 110 can include one or more interface modules 230/240 and one or more processing modules 210.
  • the interface module 230/240 can be used for information interaction and can include one or more passenger interfaces 230 and/or one or more driver interfaces 240, see FIG.
  • the interface module 230/240 can further include one or more receiving units 231 and one or more transmitting units 232.
  • the receiving unit 231 can be used to receive information from the passenger 120 and the driver 140, as specifically described in FIG.
  • the sending unit 232 can be used to output the processed information processed by the processing module 210. For details, refer to the description in the related figure.
  • the processing module 210 can further include one or more order pre-processing modules 310, one or more user pre-processing modules 320, one or more determination modules 330, one or more prediction modules 340, one or A plurality of analysis modules 350 and one or more decision modules 360.
  • the order pre-processing module 310 can be used to process order information.
  • the order pre-processing module 310 may further include one or more order generating units 311, one or more order screening units 312, and one or more order information acquiring units 313.
  • User pre-processing module 320 can be used to pre-process user information.
  • the processing module 320 may further include one or more user terminal determining units 321, one or more user terminal detecting units 322, one or more user terminal screening units 323, and one or more user information acquiring units 324.
  • the order information acquiring unit 313 and the user information acquiring unit 324 may be collectively referred to as an acquiring unit (not shown).
  • the determination module 330 can be used to determine some location related information.
  • the determination module 330 may further include one or more play order radius determining units 331, one or more order receiving range determining units 332, one or more pass level determining units 333, and one or more distance determining units 334.
  • the prediction module 340 can be used to predict the user's willingness to grab the order.
  • the prediction module 340 can further include one or more subscription probability calculation units and one or more grab ratio prediction units 342.
  • the analysis module 350 can be configured to perform an analysis determination based on the order characteristics determined by the determination module 330 and/or the prediction module 340.
  • the analysis module 350 can further include one or more comparison units 351 and one or more determination units 352.
  • Decision module 360 can be used to make order assignments or other processing based on the output of analysis module 350.
  • the decision module 360 can further include one or more order allocation units 361 and one or more adjustment units 362.
  • the order distribution system 110 is described by taking a car service system as an example.
  • the order allocation process can be performed by the on-demand service system 105 or a portion thereof (eg, the order distribution system 110).
  • the order information can be received from the user 120/140 (see FIG. 1) via the interface module 230/240 at step 410.
  • information of database 130 and/or other information sources 160 may also be received.
  • the content of the order information may include, but is not limited to, the order itself information, user information, and other information.
  • the order itself information may include but is not limited to the order number, departure place (or origin), destination, departure time, arrival time, time to wait, number of passengers, presence or absence of baggage, mileage, price, consumer fare increase, service Party price adjustment, system price adjustment, red envelope usage, payment method (such as cash payment, credit card payment, online payment, remittance payment, etc.), order completion status, service provider selection order status, consumer sent order status, etc., or any combination of the above information.
  • User information refers to information about the user 120/140.
  • User information may include, but is not limited to, name, nickname, gender, nationality, age, contact information (telephone number, mobile phone number, social account information (such as micro-signal code, QQ number, Linkedin, etc.), etc., etc.) Occupation, evaluation level, time of use, driving age, age, model, condition, license plate number, driver's license number, certification status, user habits/likes, additional service capabilities (such as the trunk size of the car, additional features such as panoramic sunroof), etc.
  • Other information may refer to information that is not controlled by the consumer or the servant, or that is temporary/bursty.
  • other information may include, but is not limited to, weather conditions, environmental conditions, road conditions (eg, closed roads due to safety or road work, etc.), traffic conditions, etc., or any combination of the above.
  • part of the content of the order information may be real-time order information or historical order information.
  • the real-time order information may be order information at a certain time or at a certain time period.
  • the time period may be a few seconds, a few minutes, a few hours, or a time period customized according to preferences; the time period may also be a specific time, such as a work day, a rest day, a holiday, a peak time, an off-peak time, and the like.
  • the historical order information may include relevant information in the past, for example, the requested order quantity, the accepted order quantity, the volume of the order, the grab rate (general) rate, the success rate of the grab, the breach rate, the refresh rate, the turnover rate, the user habit/likeness, etc. One or several combinations.
  • the order characteristics can be processed by the processing module 210 based on the received order information.
  • the above order features may include direct information of the order, processed information, and the like.
  • the direct information of the order may be one or a combination of the information of the order itself, the user information, the other information, and the like.
  • the information processed by the order can be obtained through certain data processing methods, including but not limited to the user's grab time, grab rate, grab success rate, breach rate, cool rate, transaction rate, order density, order competition. Combination of probability, order buffer time, order broadcast time, user accepted broadcast range, route grade, road distance, distance from user to departure point, accuracy of predicted order grab probability, etc. .
  • the processing of information The formula includes, but is not limited to, a combination of one or more of storing, classifying, filtering, converting, calculating, retrieving, predicting, training, and the like of information.
  • the predictive model can be qualitative or quantitative.
  • it can be based on time series prediction or based on causal analysis.
  • the time prediction method may further include one or a combination of an average smoothing method, a trend extrapolation method, a seasonal variation prediction method, and a Markov time series prediction method.
  • the causal analysis method may further include a one-way regression method, a multiple regression method, and an input-output method.
  • the predictive model may include, but is not limited to, a combination of one or more of a weighted arithmetic average model, a trend average prediction model, an exponential smoothing model, an average development speed model, a unitary linear regression model, and a high and low point model.
  • the formulas, algorithms, and/or models used for information processing can be continuously optimized through machine learning.
  • machine learning methods depending on the learning style, it may be supervised learning, unsupervised learning, semi-supervised learning or reinforcement learning.
  • machine learning algorithms can be regression algorithm learning, instance-based learning, normalized learning, decision tree learning, Bayesian learning, clustering algorithm learning, association rule learning, neural network learning, deep learning, and reduction. Dimensional algorithm learning, etc.
  • the regression algorithm model may be an Ordinary Least Square, a Logistic Regression, a Stepwise Regression, a Multivariate Adaptive Regression Splines, or a local dispersion.
  • Locally Estimated Scatterplot Smoothing for instance-based models, it can be k-Nearest Neighbor, Learning Vector Quantization, or Self-Organizing Map.
  • the normalized algorithm model it can be RIDge Regression, Least Absolute Shrinkage and Selection Operator (LASSO) or Elastic Net (Elastic Net); for decision tree model, it can be Classification and Regression Tree, ID3 (Iterative) Dichotomiser 3), C4.5, Chi-squared Automatic Interaction Detection (CHAID), Decision Stump, Random Forest, Multiple Adaptive Regression Spline (MARS) Or Gradient Boosting Machine (GBM); for Bayesian model, it can be Naive Bayes algorithm, Averaged One-Dependence Estimators or Bayesian Belief Network (BBN);
  • the algorithm model of the kernel may be a Support Vector Machine, a Radial Basis Function, or a Linear Discriminate Analysis; for the clustering algorithm model, it may be a k-Means algorithm or expectation.
  • Expectation Maximization etc.
  • association rule model it may be Apriori algorithm or Eclat algorithm
  • neural network model it may be Perceptron Neural Network, Back Propagation, Hopfield network , Self-Organizing Map or Learning Vector Quantization
  • deep learning models it can be Restricted Boltzmann Machine, Deep Belief Networks (DBN), Convolution Convolutional Network or Stacked Autoencoder (Stack Ed Auto-encoders)
  • DBN Deep Belief Networks
  • Convolution Convolutional Network or Stacked Autoencoder Stack Ed Auto-encoders
  • reduced dimension algorithm model it can be Principal Component Analysis, Partial Least Square Regression, Sammon Mapping, Multi-Dimensional Scaling or Projection Tracking. (Projection Pursuit) and so on.
  • order distribution system 110 can send information to one or more driver devices 140, one or more passenger devices 120, one or more third party platforms, etc. via interface module 230/240.
  • the information sent may include, but is not limited to, direct information and/or processing information of the order.
  • Direct information for the order may include, but is not limited to, order information, user information, and/or other information.
  • the processing information of the order includes but is not limited to the user's grab time, grab rate, grab success rate, breach rate, cool rate, transaction rate, order density, order competition probability, order buffer time, order broadcast time
  • the form of the transmitted order information may include, but is not limited to, one or a combination of text, picture, audio, video, and the like.
  • the order information can be pre-processed after step 410.
  • the preprocessing process can remove some distorted data through methods such as data cleansing, data integration, data transformation, and/or data specification.
  • the specific distortion data removal method may include, but is not limited to, one or more of a discriminant method, a culling method, an average method, a leveling method, a proportional method, a moving average method, an exponential smoothing method, a difference method, and the like. Combination of species. For example, in some embodiments, it may be continually adjusted or optimized for a particular order feature. As another example, in the order allocation process, the steps of data storage can also be added. Variations such as these are within the scope of the present application.
  • FIG. 5 is a schematic diagram of an order distribution system 110, in accordance with some embodiments of the present application.
  • the order distribution system 110 can include one or more order generating units 311, one or more determining units 352, and one or more transmitting units 232.
  • the transmitting unit 232 can further include one or more dispatch mode user transmit subunits 510, one or more snatch mode user transmit subunits 520, and one or more other dispatch mode user transmit subunits. 530.
  • the order generating unit 311 can be configured to generate an order based on the taxi request when the order requester makes a taxi request.
  • the determining unit 352 determines whether there is a user of the dispatch mode within a range in which the distance from the departure place of the order is less than the first preset threshold.
  • the dispatch mode user transmit sub-unit 510 can be configured to send the order to a dispatch mode-only user that satisfies the condition when the terminal of the dispatch mode exists within the first preset threshold.
  • the snatch mode user transmit subunit 520 can be used to be the first When there is no user of the dispatch mode in the preset threshold, the user who acquires the grab mode with the distance from the departure place of the order is less than the second preset threshold, and sends the order to the grab mode user who meets the condition.
  • the first preset threshold may be less than the second preset threshold.
  • the dispatch mode user sending subunit 510 may be further configured to: when the users of the multiple dispatch mode exist within the first preset threshold, the pre-compliance may be selected from the users of the multiple dispatch mode. Set a user to match the condition and send the order to the user.
  • the preset matching condition may include the closest distance to the departure place of the order, the shortest time to reach the place of departure of the order, the shortest road congestion time, the highest user credit/score, and the highest number of user grabs. One or a combination of the highest levels of user loyalty.
  • the order distribution system 110 may further include other dispatch mode user sending sub-units 530, which may be used to interval the first preset time period, and sequentially send the order to other parties according to the preset matching condition.
  • Other dispatch mode user sending sub-units 530 which may be used to interval the first preset time period, and sequentially send the order to other parties according to the preset matching condition.
  • the user of the other dispatch mode may be a user other than the above-mentioned filtered user among the plurality of split mode users.
  • the order distribution system 110 may further include one or more user terminal detecting units 322, which may be configured to detect the departure place of the order every second preset time period before any user orders the order. The distance is less than the user within the first preset threshold whether there is a dispatch mode.
  • the order distribution system 110 may further include one or more order assigning units 361, which may be used to assign the order to the dispatch mode user when the order mode user orders, and stop Send the order.
  • the user may wait for the third preset time period, and determine whether there is a single-mode user order in the third preset time period; if the third preset time period is sent, If the single mode user orders, the order is assigned to the user of the dispatch mode; if there is no single mode user order in the third preset time period, the order is assigned to the user of the grab mode. .
  • the order assigning unit 361 may be further configured to: when a user with multiple snatching modes simultaneously grabs a single order, select one of the plurality of snatching mode users to meet a preset matching condition. User and assign the order to the user.
  • the order distribution system 110 can also include a storage module.
  • the storage module can be internal to the system or an external device of the system. The storage module can actually exist in the system, or can complete the corresponding function through the cloud computing platform.
  • individual modules or units may be combined in any combination or configured to interface with other modules.
  • the transmitting subunits 510-530 can be integrated together as one transmitting unit 232.
  • the order generating unit 311, the determining unit 352, the user terminal detecting unit 322, and the order assigning unit 361 in the processing module may be used as a single unit, may be arbitrarily combined into a new unit, or may be integrated into one processing module 210 or the like. Variations such as these are within the scope of the present application.
  • step 610 the order requester's taxi request can be received.
  • the taxi request of the order requester may be received by the receiving unit 231, which may generate an order by the order generating unit 311.
  • the order distribution system 110 can also directly process ready-made orders that are stored by itself or transmitted from elsewhere, ie, step 610 can be omitted.
  • the departure location information of the order and/or the location information of the user may be obtained.
  • the departure location information of the order and the location information of the user may be obtained by the receiving unit 231.
  • the departure location information of the order may be extracted by the order information acquisition unit 313 in FIG. 3, and the location of the user may be extracted by the user information acquisition unit 324 in FIG.
  • the user here can be either a passenger or a driver.
  • the driver is taken as an example for explanation.
  • the driver can select two listening modes: a dispatch mode and a grab mode.
  • an order can be sent only to a terminal that is most suitable (for example, the closest to the departure point of the order). If the terminal does not respond or does not receive the order, it can be sent to another terminal.
  • an order can be sent to multiple terminals at the same time for multiple terminals to grab orders.
  • the preset threshold can be a value or an interval.
  • the preset threshold may be one or more.
  • the preset threshold can be set manually or can be obtained by the order distribution system 110 through machine learning.
  • the preset threshold can be kept unchanged or dynamically updated according to the actual scene.
  • the user may be a driver in the dispatch mode or a driver in the grab mode. To facilitate the application, the driver in the dispatch mode is taken as an example.
  • step 630 it may be determined by the determining unit 352 whether there is a user in the dispatch mode in which the order departure distance is less than a preset threshold. If there is a dispatch mode user that satisfies the condition, the process proceeds to step 640. If not, the process returns to step 620.
  • the order can be sent to a user of the dispatch mode that satisfies the condition.
  • the order can be sent by the sending unit 232 to the user of the dispatch mode that satisfies the condition.
  • the user of the dispatch mode may also send the order by the dispatch mode user transmit subunit 510.
  • there is only one user in the dispatch mode at which point the order distribution system 110 can send the order directly to the user.
  • the matching condition may include the closest distance to the place of departure of the order, the shortest time to reach the place of departure of the order, the shortest road congestion time, the highest user credit/score, the highest number of user grabs, and the highest user loyalty. One or several combinations.
  • the first preset time period is intervald, and the order is sequentially sent to the other according to the matching condition in descending order of the distance from the place of departure of the order.
  • the users of the other dispatch mode are users other than the filtered users among the users of the multiple dispatch mode.
  • the order may be first sent to the user who is closest to the departure place of the order, and wait for the first preset time period (for example, N seconds, N may be larger than Any value of 0), within N seconds, the order may not be broadcast to the new terminal, but the user who has already broadcast the order continues to broadcast.
  • the order is sequentially sent to other dispatch mode users in descending order of the distance from the departure place of the order.
  • the process returns to step 620 to obtain the location information of the grab mode user.
  • a preset threshold (the second preset threshold) may be consistent with the preset threshold (the first preset threshold) of the dispatch mode user, or may be inconsistent.
  • the first preset threshold may be smaller than the second preset threshold.
  • the first preset threshold may be set to n kilometers, and the second preset threshold may be set to n+m kilometers, where n and m are both greater than zero.
  • the order can be sent to the grab mode user who meets the condition.
  • the order can be sent by the grab mode user send subunit 520 to the grab mode user that meets the condition.
  • the order is assigned to the user.
  • a plurality of users in the single-single mode may be rushed at the same time.
  • a most suitable user that meets the preset matching condition may be selected from the users of the multiple snatch mode, and the The order is assigned to this user.
  • the preset matching conditions may include the closest distance to the departure place of the order, the shortest time to reach the place of departure of the order, the shortest road congestion time, the highest user credit/score, the highest number of user grabs, and the highest user loyalty. One or several combinations.
  • the step of whether there is a dispatch mode user that satisfies the condition may also be added.
  • the user terminal detecting unit 322 can detect whether there is a dispatch mode user whose distance from the order is less than the first preset threshold every second preset time period.
  • the order is sent to the grab mode user that satisfies the condition. While sending the order to the grab mode user, detecting the departure place of the order every second preset time period Whether there is a dispatch mode user within a range smaller than the first preset threshold. If a user with a dispatch mode is detected, the order can be sent to the dispatch mode user at the same time.
  • the order allocation process illustrated in FIG. 6 may further include the step of assigning an order.
  • the order assigning step may include:
  • the order is assigned to the user of the dispatch mode, and the order is stopped. Specifically, when a user with a dispatch mode receives a order, the order can be immediately assigned to the user and the order is stopped at the same time.
  • the order assigning step may further include:
  • the third preset time period may be waited for. Specifically, when a user who has a snatch mode grabs a ticket, the order is not immediately assigned to the user, but is waited for a third preset time period (for example, 7 seconds). During the third predetermined time period, the order may not be broadcast to the new user, but will continue to be broadcast to the user who has already broadcast the order.
  • B02 Determine whether there is a single mode user order in the third preset time period.
  • the order is allocated to the user of the dispatch mode.
  • steps in FIG. 6 may change the order of execution, some steps may be omitted, some steps may be added, multiple steps may be combined into one step, and/or one step may be broken down into multiple steps.
  • steps 610 and 620 may not be strictly differentiated, i.e., there may be no need to generate an order or obtain an order origin and/or user location.
  • the user in the grab mode can also be judged first, and then the user in the single mode is judged.
  • steps such as data preprocessing, data storage, and the like can also be added.
  • the order distribution system 110 can include one or more receiving units 231, one or more order generating units 352, one or more determining units 352, and one or more transmitting units 232.
  • the receiving unit 231 can be configured to receive a taxi request from the order requestor.
  • the order generating unit 352 can be configured to generate order information according to the taxi request, the order information including at least a departure place.
  • the determining unit 352 can be configured to determine whether the nth preset time is reached. Wherein n is an integer not less than 1 and not more than N, and N is an integer greater than 1.
  • the sending unit 232 can be configured to send the order information to all users in the nth preset broadcast area when the determining unit 352 determines that the nth preset time is reached.
  • the transmitting unit 232 includes one or more terminal identification acquisition sub-units 730 and one or more transmission sub-units 740.
  • the terminal identifier acquisition sub-unit 730 can be configured to acquire the terminal identifiers of all users in the n-th preset broadcast ticket area when the nth preset time is reached.
  • the sending subunit 740 can be configured to send the order information to the user according to the terminal identifier acquired by the terminal identifier obtaining subunit 730.
  • the order distribution system 110 may further include one or more play order radius determining units 331 that may be configured to determine respective preset play order radii based on the first order turnover rate in the historical data.
  • the order distribution system 110 can further include one or more first adjustment units 710.
  • the first adjustment unit 710 may further include one or more transaction rate acquisition subunits 711, one or more judgment subunits 712, and one or more play order radius adjustment subunits 713.
  • the transaction rate obtaining sub-unit 711 can be configured to obtain a second order transaction rate corresponding to the order sending in the preset time range; the determining sub-unit 712 can be used to determine the Whether the second order transaction rate is less than a preset threshold; the play order radius adjustment sub-unit 713 can be used to adjust each preset broadcast order radius and/or each when the determining sub-unit 712 determines that the second order transaction rate is less than a preset threshold Preset time.
  • the order distribution system 110 can further include one or more second adjustment units 720.
  • the second adjustment unit 720 may further include one or more order density acquisition subunits 721 and one or more play order radius adjustment subunits 722; and/or one or more terminal density acquisition subunits 721 and one or more The play order radius adjustment subunit 724.
  • the order density acquisition sub-unit 721 can be configured to acquire an order density in the preset area after the order generating unit 311 generates the order information according to the taxi request; the play order radius adjustment sub-unit 722 can be configured to adjust each according to the acquired order density.
  • the preset broadcast radius and/or each preset time; the terminal density acquisition sub-unit 721 can be configured to acquire the user density in the preset area after the order generating unit 311 generates the order information according to the taxi request; the broadcast radius adjustment subunit 724 can be used to adjust each preset play order radius and/or each preset time according to the acquired terminal density.
  • the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment (ie, FIG. 8 to FIG. 10).
  • the above description of the order distribution system 110 is merely for convenience of understanding and is not intended to limit the application to the scope of the embodiments. It will be understood by those skilled in the art that various modifications and changes in form and detail may be made to the order dispensing system 110 without departing from the principles of the system. For example, in some embodiments, some units may be added or subtracted, or any combination of units may be performed, or the subsystems may be connected to other modules, while performing similar functions. Variations such as these are within the scope of the present application.
  • step 810 is an exemplary flow chart of an order allocation method, in accordance with some embodiments of the present application.
  • an order requester's taxi request can be received, and the taxi request can generate order information.
  • the taxi request of the order requester may be received by the receiving unit 231, and the taxi request may be generated by the order generating unit 311. interest.
  • the order information reference may be made to the related description of the present application.
  • the order information includes at least a departure place.
  • the order distribution system 110 can also directly process ready-made orders that are stored by itself or transmitted from elsewhere, ie, step 810 can be omitted.
  • each preset play order radius may be determined based on the first order transaction rate in the historical data. For example, each preset play order radius may be determined by the play order radius determining unit 331 according to the first order transaction rate in the historical data. For example, by analyzing the transaction rate of historical order data, the radius of each preset broadcast order is determined.
  • the following description is made by way of examples, but the application does not limit the scope of the embodiments.
  • the transaction rate is in the broadcast area of 80% to 100%, and the broadcast order radius corresponding to the broadcast area is 200 meters, which is the first preset broadcast order radius. It is determined that the transaction rate is in the broadcast area of 60% to 80%, and the broadcast order radius corresponding to the broadcast area is 400 meters, which is the second preset broadcast order radius. It is determined that the transaction rate is in the broadcast area of 40% to 60%, and the broadcast order radius corresponding to the broadcast area is 800 meters, which is the third preset broadcast order radius. It is determined that the transaction rate is in the broadcast area of 20% to 40%, and the broadcast order radius corresponding to the broadcast area is 1000 meters, which is the fourth preset broadcast order radius.
  • step 820 is not a necessary step, that is, a process of order allocation may be completed without a preset broadcast radius.
  • the order information may be sent to all users in the nth preset broadcast area.
  • the preset time here can be any time point set according to actual needs.
  • the nth preset time may correspond to the nth set time point.
  • the nth preset broadcast area may be an area determined by the nth preset play order radius centering on the location where the order departure place is located. Wherein n is an integer not less than 1 and not more than N, and N is an integer greater than 1.
  • the n+1th preset time may be later than the nth preset time
  • the n+1 preset play order radius may be greater than the nth preset play order radius. Therefore, the user who is closer to the place of departure of the order receives the order information earlier and more frequently, so that the user who is farther away from the place of departure of the order receives the order information later, the number of times less.
  • the n+1th preset broadcast ticket radius may not be greater than the nth preset play order radius, so that the user who is farther away from the departure place of the order receives the order information earlier. The number of times is higher, so that users who are closer to the place of departure of the order receive the order information later and less frequently.
  • the terminal identifier acquisition sub-unit 730 may first acquire the terminal identifier of all users in the n-th preset broadcast ticket area, and then, according to the terminal identifier, the user The order information is sent to enable all users in the corresponding preset broadcast area to know the order information.
  • the following description is made by way of examples, but the application does not limit the scope of the embodiments.
  • the time for generating the order information corresponding to the taxi request is 8:55:10 on August 3, 2015, and then when the first preset time is 8:55:11, the acquisition is obtained.
  • the terminal identifier of all users in the first preset broadcast area and then sends the order information to all users in the first preset broadcast area according to the terminal identifier.
  • the second preset time is 8:55:18, the terminal identifiers of all users in the second preset broadcast area are obtained, and then the terminal identifier is sent to all users in the second preset broadcast area. order information.
  • the terminal identifiers of all users in the third preset broadcast area are obtained, and then the terminal identifier is sent to all users in the third preset broadcast area. order information. And so on, when the nth preset time is reached, the terminal identifiers of all users in the nth preset broadcast area are first acquired, and then the order information is sent to the user according to the terminal identifier.
  • the order information is sent to all users in the n-1th preset broadcast area, and before the nth preset time, the n-1th pre- If a certain user of the broadcast area successfully grabs the order, the order information may not be sent to the user in the nth preset broadcast area, or only to a part of the user at the nth preset time.
  • step 820 can be omitted.
  • the transaction rate analysis step of the historical order can be added.
  • the transaction rate of the historical order can also be obtained from elsewhere.
  • steps such as data preprocessing, data storage, and the like can also be added.
  • steps such as data preprocessing, data storage, and the like can also be added.
  • a step of adjusting each preset play order radius and/or each preset time may also be added. Variations such as these are within the scope of the present application.
  • Step 9 is an exemplary flow chart of an order allocation method, in accordance with some embodiments of the present application.
  • Steps 810 and 830 may refer to the related description in FIG.
  • the second order transaction rate corresponding to the order sending in the preset time range may be obtained.
  • the transaction rate acquisition sub-unit 711 can obtain the second order transaction rate corresponding to the order transmission within the preset time range.
  • the preset time range may be less than or equal to the running time of the order allocation method in FIG. 8.
  • it may be determined whether the second order transaction rate is less than a preset threshold.
  • each preset play order radius and/or each preset time may be adjusted.
  • each preset play order radius and/or each preset time may be adjusted by the play order radius radius adjustment sub-unit 713.
  • the preset preset broadcast radius may be re-determined according to other historical data (distinct from the historical data in FIG. 8 above), or the previously selected preset broadcasts according to the empirical value. Fine-tuning with a single radius.
  • the implementation effect of the order allocation method shown in FIG. 8 is checked by the order transaction rate index. Of course, it can also be based on other indicators, including but not limited to the order cancellation rate, user credit/evaluation, and the like.
  • each preset play order radius and/or each preset time may be adjusted.
  • each preset play order radius and/or each preset time may be adjusted by the second adjustment unit 720.
  • the order density in the preset area is obtained by the order density acquisition sub-unit 721, and then each preset preset order radius and/or each preset time can be adjusted by the play order radius adjustment sub-unit 722 according to the order density.
  • the user density in the preset area may be acquired by the terminal density acquisition sub-unit 723, and then each preset preset radius and/or each preset may be adjusted by the play order radius adjustment sub-unit 724 according to the user density. time. In some embodiments, each preset play order radius and/or each preset time may be adjusted simultaneously based on order density and user density. In some embodiments, the order density and/or user density may be the ratio of the number of orders and/or the number of users in the preset area to the area of the preset area.
  • the order quantity in the preset area is the quantity of the order information in which the location where the order origination belongs belongs to the preset area.
  • step 1020 when the nth preset time or the adjusted nth preset time is reached, all users in the nth preset broadcast area determined to the nth preset play order radius or the adjusted first n All users in the nth preset broadcast area determined by the preset play order radius send the order information.
  • the preset area is an area that is centered on the departure place of the order and is less than or equal to the Nth preset broadcast area (the most effective broadcast area).
  • each preset play order radius may be lengthened when the order density and/or user density in the preset area is greater than the first threshold.
  • each preset play order radius can be shortened. For example, for dividing a valid broadcast area into five gradient broadcast areas, assume that each preset broadcast order has a radius of 200 meters, 400 meters, 800 meters, 1000 meters, and 1500 meters.
  • each preset play order radius may be adjusted to 230 meters, 500 meters, 900 meters, 1200 meters, and 1500 meters.
  • each preset play order radius may be adjusted to 150 meters, 300 meters, 500 meters, 800 meters, and 1500 meters.
  • a portion of the preset time may be postponed. For example, you can postpone the 2nd and 3rd presets time.
  • the time may be partially preset in advance. For example, the 2nd and 3rd preset moments can be advanced.
  • the above description of the order allocation process is merely for the convenience of understanding the application, and the present application is not limited to the scope of the embodiments. It will be understood that those skilled in the art, after understanding the basic principles of the present application, can make changes to the order allocation process without departing from this principle.
  • the steps in FIG. 10 may change the order of execution, some steps may be omitted, some steps may be added, multiple steps may be combined into one step, and/or one step may be decomposed into multiple steps.
  • the preset preset broadcast radius and/or each preset time may be adjusted by other methods or by trial and error to determine a better adjustment manner. Variations such as these are within the scope of the present application.
  • the order distribution system 110 can include one or more first number of order receiving range determining units 1130, one or more first number of order receiving sub-units 1110, and one or more first number of order receiving sub-units. 1120, one or more second number of order receiving range determining units 1140 and one or more optional setting units 1150.
  • the first number of order receiving range determining unit 1130 can be used to determine a default order receiving range of the first number of users in the area; the first number of order receiving sub-units 1110 can be used to obtain the first number of users to receive in the default order. a first average order number in the range; the second number order receiving range determining unit 1140 may be configured to obtain a second average order number of the second number of users in the default order receiving range; the second number of order receiving range determining unit 1140 may And determining an order receiving range of the second number of users according to the first average order number and the second average order number; the optional setting unit 1150 may be configured to set the order receiving range as the default order receiving range.
  • the order distribution system 110 since it is basically similar to the method embodiment, the description is relatively simple, and the relevant points can be referred to the partial description of the method embodiment (ie, FIG. 12). It should be noted that the above description of the order distribution system 110 is merely for convenience of understanding and is not intended to limit the application to the scope of the embodiments. It will be understood that those skilled in the art, after understanding the principles of the system, Various modifications and changes in form and detail can be made to the order distribution system 110 without departing from this principle. For example, in some embodiments, some units may be added or subtracted, or any combination of units may be performed, or the subsystems may be connected to other modules, while performing similar functions. Variations such as these are within the scope of the present application.
  • a default order acceptance range for the first number of users in the region can be determined.
  • the area may refer to an administrative division or an artificially set range, and the size may be fixed or adjusted according to actual scenarios.
  • the default order receiving range may be a pre-set range, and sending the order to the user according to the default order receiving range may enable the user to obtain a more reasonable number of orders at any time, thereby enabling the user and the order originator to Establish and complete orders more efficiently.
  • the default order receiving range can be set to any distance within the range of 1 to 5 kilometers.
  • the default order receiving range can be set to be larger or smaller.
  • the first number of users may be a statistical sample, the first number may be equal to or less than the number of all users in the area, for example the first number may be 80% or more of the total number of users in the area. More or less.
  • the default order receiving range may be set directly by the order dispensing system 110 or may be set by the user.
  • the order distribution system 110 can count the number of evaluation orders completed by the user within a unit time (eg, 1 hour, 1 day, etc.) when the first number of order receiving ranges in the area are set to different values, And the order receiving range corresponding to the maximum average order number is set as the default order receiving range.
  • each user's preferred order receiving range may be selected by each user in the area, and the default order receiving range in the area may be obtained by the order dispensing system 110 by, for example, averaging different preferred order receiving ranges for these different users.
  • a first average number of orders for the first number of users in the default order receiving range may be obtained.
  • the first number of order receiving sub-units 1110 can obtain the first average number of orders for the first number of users in the default order receiving range.
  • the first average order number may be derived by the order distribution system 110 by, for example, averaging the number of orders received by each of the first number of users in the default order receiving range.
  • the number of orders that the user has received and displayed or to be displayed at this time can be obtained for one time point to obtain the first average order number.
  • the number of orders received by the user during this time period can also be obtained for a period of time (eg, 10 minutes to 1 hour or any period of time) to obtain the first average order number.
  • a second average number of orders for the second number of users in the default order receiving range described above may be obtained.
  • a second number of order receiving sub-units 1120 can obtain a second average number of orders for the second number of users in the default order receiving range described above.
  • the second number may be less than, greater than or equal to the first number. In some embodiments, the second number can be less than the first number. In other embodiments, for example, when the first number of users is a representative user in the region, the second number may also be greater than or equal to the first number.
  • the first number of users being representative users in the area means that the average number of orders of most or all of the order recipients in the area can be reliably inferred by the average number of orders of the first number of users. Determining whether the first number of order recipients is a representative order receiver can follow a number of criteria, for example, the area can be evenly divided into equal-sized sub-areas, and then a certain number is selected from each sub-area (these numbers can be The sum of the same or different) is the first number of users. Since these users are evenly selected according to geographical distribution, they can be considered as representative users. It should be understood that the smaller the sub-region segmentation, the higher the degree to which the first number of order recipients may be representative.
  • an order receiving range for the second number of users may be determined based on the first average order number and the second average order number.
  • the second number of orders receiving range determining unit 1140 may determine the order receiving range of the second number of users based on the first average order number and the second average order number.
  • the user's order receiving range may be any shape including, but not limited to, a circle, an ellipse, a rectangle, a square, a triangle, or other shapes.
  • the order receiving range is a circular range centered on the user, in this case, determining the user's order receiving range can be determined by The radius of the circular range is achieved.
  • the range of the order recipient may be a user-centered square displayed on the map in order to divide the range of the area into square blocks for processing, in which case determining the user's order receiving range may pass Determine the side length of the square range to achieve.
  • the relationship between the first average order number and the second average order number may be used as a coefficient.
  • the following description will be made by way of examples, but the application is not limited to these embodiments.
  • the ratio of the first average order number to the second average order number may be used as a determining factor to determine an order receiving range. Wherein, when the first average order quantity is greater than the second average order quantity, the user's order receiving range should be increased, and at this time, the determining factor is greater than 1, so the radius (or side length) and the determining factor of the user as described above can be used.
  • the radius (or side length) is multiplied by the determination factor to obtain a reduced order reception range; when the first average order number is exactly equal to the second average order number, the determination factor is equal to 1, so no processing is required as described above.
  • the determined order receiving range described in these embodiments can be expressed by the following formula 1:
  • R1 may be a radius (or side length) corresponding to the default order receiving range of the user
  • N1 may be the first average order number
  • N2 may be the second average order number
  • R2 may be the determined radius of the user (or edge) long).
  • the ratio of the first average order number to the second average order number may be processed as a determining factor. For example, since the first average order number and the second average order number both reflect the number of orders in the order receiving range as the area, the ratio of the first average order number to the second average order number may be pre-processed as The factor is determined such that when determining the above radius or side length as the length of the line segment, a more accurate average order number can be determined.
  • the determined order receiving range described in these embodiments can be expressed by the following formula 2:
  • R1 is the radius (or side length) of the user corresponding to the default order receiving range
  • N1 is the first average order number
  • N2 is the second average order number
  • R2 is the determined radius (or side length) of the user.
  • the upper limit value and/or the lower limit value may also be preset for the above determination factor (eg, the upper limit value may be 1.5 or any reasonable value, and the lower limit value may be 0.5 or any reasonable value).
  • the determining factor is adopted; when the calculated determining factor is greater than the upper limit value, the upper limit value may be used as the determining factor; When the determination factor is less than the lower limit value, the lower limit value can be used as the determination factor.
  • the determination may be made only by the magnitude relationship between the first average order number and the second average order number. For example, when the first average order number is greater than the second average order number, the radius (or side length) of the order receiver as described above may be multiplied by a predetermined first predetermined value (eg 1.2 or any reasonable value). To obtain an increased order receiving range; and when the first average order number is less than the second average order number, the radius (or side length) of the order receiving party as described above and a preset second predetermined value may be used ( For example, 0.8 or any reasonable value is multiplied to obtain a reduced order acceptance range. When the first average order number is equal to the second average order number, the above default order receiving range may be used as the determined order receiving range.
  • the determined order receiving range described in these embodiments can be expressed by the following formula 3:
  • R1 is the radius (or side length) of the user corresponding to the default order receiving range
  • N1 is the first average order number
  • N2 is the second average order number
  • a is the first predetermined value
  • b is the second predetermined value
  • R2 is the determined radius (or side length) of the user.
  • step 1250 may be entered.
  • the determined order receiving range may be determined as the default order receiving range.
  • the order allocation method illustrated in Figure 12 can be performed in real time, dynamically.
  • the above process may be performed in real time each time the user requests a new order from the order distribution system 110 and the order distribution system 110 sends a new order to the user, so that the user's order receiving range can be continuously dynamically adjusted.
  • the above process may be performed periodically at intervals (e.g., 5 minutes or any predetermined time).
  • the above process can also be performed in response to a request by the user and the order distribution system 110.
  • step 1220 and step 1230 may be performed in any order or concurrently, step 1250 may be omitted, step 1220 and step 1230 may be combined into one step execution, and/or step 1240 may be decomposed to compare the first average order number and the second.
  • step 1240 may be decomposed to compare the first average order number and the second.
  • the steps of the average order number and the steps of determining the user's order receiving range are performed in two steps. Variations such as these are within the scope of the present application.
  • Figure 13 provides an exemplary flow chart of an order allocation method, in accordance with some embodiments of the present application.
  • the order information can be obtained.
  • order information may be retrieved by receiving unit 231 in order distribution system 110.
  • Order information may include, but is not limited to, order information, user information, and other information.
  • the order itself information may include order number, departure place, departure time, order time, departure time, arrival time, waiting time, mileage, number of passengers, availability of luggage, price, payment method (eg cash payment, credit card payment, online A payment or a combination of any information, such as payment, remittance payment, etc., consumer price increase, service party price adjustment, system price adjustment, red envelope/coupon usage, order completion status, service provider selection order status, consumer order status, etc.
  • payment method eg cash payment, credit card payment, online A payment or a combination of any information, such as payment, remittance payment, etc., consumer price increase, service party price adjustment, system price adjustment, red envelope/coupon usage, order completion status,
  • User information may include, but is not limited to, user name, nickname, gender, nationality, age, contact information (telephone number, mobile number, social account information (eg, micro-signal) Code, QQ number, Linkedin, etc.), etc., any location information (coordinate information, direction information, sports status information, etc.), occupation, rating level, usage time, driving age, age, model A combination of one or more of the license plate number, driver's license number, certification status, user habits/likes, additional service capabilities (eg, trunk size of the car, additional features such as a panoramic sunroof).
  • Other information refers to information that is not controlled by the consumer or the servant, or refers to temporary/bursty information.
  • Other information may include, but is not limited to, weather conditions, environmental conditions, road conditions (eg, closed roads for reasons such as safety or road work), traffic conditions, etc., or any combination of the above.
  • part of the content of the order information may be real-time information or historical order information.
  • the real-time information may be order information at a certain time or at a certain time period, and the time period may be a few seconds, minutes, hours, or a time period customized according to preferences; the time period may also be a specific time, such as a working day. , rest days, holidays, peak hours, off-peak hours, etc.
  • the historical order information may include past related information, for example, a combination of one or a combination of a completed order quantity, a requested order quantity, a received order quantity, an order completion rate, a grab rate, a breach rate, and the like.
  • order location information may be obtained for the order information.
  • the order location information may be one of information of the order requester's coordinate information, the order recipient's coordinate information, the city's traffic map information, the road surface distance between the order requester and the order receiver, and the like. Or any combination of several. A description of the road surface distance can be found in the relevant descriptions of other parts of this application.
  • the order location information may be one or a combination of the origin and destination of the order, the destination of the user terminal, the current motion state information of the user, and the traversal level of the user determined according to the policy. . For a description of the grading level, refer to the relevant descriptions of other parts of this application.
  • the order location information may also be one or any of information such as the origin of the order, the origin, the destination, the current location of the user terminal, and the distance between the origin of the order and the user terminal. Combination of species.
  • the user's grab rate may be obtained based on the location information.
  • the robbing rate may be based on a combination of one or any combination of location information, time information, and historical order information, using a pre-established prediction model to obtain a rush of the user terminal. rate.
  • a description of the prediction model can be found in the descriptions of other sections of this application.
  • order information may be sent to the user terminal based on the user's grab rate information.
  • the order information may be transmitted by the transmitting unit 232 to the user terminal based on the user's grab rate information.
  • whether to place an order to the terminal may be determined based on the user's grab rate.
  • the order information can be sent to a user terminal based on the user's grab rate.
  • an order may be allocated to a plurality of user terminals in accordance with the grab rate of the user according to the order of the grab rate.
  • order allocation method described in FIG. 13 is merely for convenience of understanding the application, and the present application is not limited to the scope of the embodiments. It will be understood that those skilled in the art, after understanding the principle of the method, may arbitrarily combine the various steps without departing from the principle, or the application form and details of the implementation of the above method. Various corrections and changes.
  • the order location information can also be any other information related to the order location, such as historical order information for the order location. These modifications and changes are within the scope of this application.
  • FIG. 14 provides a schematic diagram of an order distribution system 110, in accordance with some embodiments of the present application.
  • the order distribution system 110 can include one or more interface modules 230/240 and one or more processing modules 210.
  • the interface module 230/240 may further include one or more receiving units 231 and one or more transmitting units 232.
  • the processing module 210 may further include one or more of the distance determination unit 334, one or more of the one or more order rate prediction units 342 and one or more order allocation units 361.
  • Distance determining unit 334 may include one or more coordinate information acquisition sub-units 1410 and one or more road surface distance acquisitions at unit 1420.
  • a related description of the interface module 230/240, the receiving unit 231, and the transmitting unit 232 can be found in the related description of any other part of the application.
  • the coordinate information acquisition subunit 1410 may be configured to: after receiving a taxi request sent by the passenger through the device, acquire coordinate information of the order requester and each order recipient within the preset range of the coordinate information, and each order The coordinate information of the recipient; in some embodiments, the coordinate information may include one or any combination of absolute coordinate information, relative coordinate information, relative polar coordinate information, and the like. Coordinate information can also Is any combination of ordered pairs or data values that can be used to calibrate geographic relationships.
  • the road surface distance obtaining sub-unit 1420 may be configured to acquire a city to which the order belongs according to an order request sent by the order requester, thereby acquiring traffic map information of the city. Obtaining the order requester and each order recipient according to the traffic map information of the city of the order requester, the coordinate information of the order requester acquired by the coordinate information obtaining subunit 1410, and the coordinate information of each order receiver within the preset range The distance between the roads.
  • the road surface distance may be a linear distance between the order requester and the order receiver, or may be the actual situation of the vehicle that arrives at the order requestor by the order receiver obtained by the positioning system and/or the actual road condition information. distance.
  • the rush rate prediction unit 342 can be used to predict the road surface distance between each order recipient and the order requestor and the related feature information of the historical order of each order recipient within a preset time period.
  • the order grab probability for each order recipient can be used to predict the order grab probability of each order recipient using a pre-established prediction model.
  • the predictive model can be established based on information about the historical order of the order recipient for a predetermined period of time.
  • the road surface distance may be a predictor variable in the prediction model, and the order grab probability of the order receiver may be the target variable in the prediction model.
  • the relevant feature information of the historical order may include a combination of one or a combination of the city that generated the historical order, the time the historical order was generated, the road congestion condition of the historical order, and the value of the historical order. .
  • the predictive model can be qualitative or quantitative. For quantitative predictive models, it can be based on time series prediction or based on causal analysis.
  • the time prediction method may further include one or a combination of an average smoothing method, a trend extrapolation method, a seasonal variation prediction method, and a Markov time series prediction method.
  • the causal analysis method may further include a one-way regression method, a multiple regression method, and an input-output method.
  • the predictive model may include, but is not limited to, a combination of one or more of a weighted arithmetic average model, a trend average prediction model, an exponential smoothing model, an average development speed model, a unitary linear regression model, and a high and low point model.
  • the formulas, algorithms, and/or models used for information processing can be continuously optimized through machine learning.
  • the rush rate prediction unit 342 can also be used to pre-establish a pre-established order-related information based on online real-time acquisition and the road surface distance between the order receiver and the order requestor in the corresponding order.
  • the prediction model is optimized. For a description of machine learning algorithms, refer to the relevant descriptions of any other part of this application.
  • the order assigning unit 361 can be configured to assign an order corresponding to the taxi request to the order recipient according to the order grab probability of each order recipient predicted by the grab rate prediction unit 342. Specifically, the order assigning unit 361 can be configured to select an order grab probability of the order grab probability, which is greater than a preset threshold, and assign the order information corresponding to the taxi request to the order receiver corresponding to each order grab probability.
  • the order distribution system 110 can also include a historical data acquisition module, a predictive model building module, and a map information update module.
  • the historical data obtaining module may be configured to obtain a historical order of each order recipient within a preset time period before the grab rate prediction unit 342 predicts the order grab probability of each order receiver by using the pre-established prediction model. Relevant feature information and the road surface distance between the order receiver and the order requester in each historical order.
  • the prediction model establishing module may be configured to use the correlation feature information of the historical order acquired by the historical data acquisition module and the road surface distance between the corresponding order requester and the order receiver as the training data, using a linear regression model pair
  • the training data is trained to obtain a prediction model of the order grab probability.
  • the linear regression model can be one of a logistic regression model and a support vector machine model. In order to facilitate understanding, the linear regression model is further illustrated by taking the logistic regression model as an example.
  • the Logistic Regression model is widely used in the two-class problem.
  • the Logistic regression model can be used to determine the level of competition probability.
  • the logistic regression formula is expressed as follows:
  • w can be estimated using a maximum likelihood method. For example, various feature data in a related feature of a historical order (eg, the city that generated the historical order, the time at which the historical order was generated, the road congestion condition for the historical order, and the value of the historical order may be A plurality of) are extracted into the predictor variable x, and the competition probability of the newly initiated order is taken as the target variable y.
  • the competition probability of the newly initiated order can be predicted by performing a logistic regression model training on the transaction information of the historical order.
  • the accuracy of the logistic regression model can be continuously improved by continuously increasing the characteristics of whether the newly initiated order is robbed or not.
  • the map information update module may update the traffic map information of the city according to a preset time period.
  • the traffic map information of the city to which the order requester belongs may be updated by the map information update module according to a preset time period.
  • the order distribution system 110 depicted in FIG. 14 is merely for ease of understanding and is not intended to limit the scope of the embodiments. It will be understood that, after understanding the principle of the system, it is possible for the various modules/units to be arbitrarily combined without any deviation from the principle, or the subsystems are connected with other modules, Various modifications and changes in the form and details of the application of the above system are implemented.
  • the order distribution system 110 may further include a historical data acquisition module, a prediction model establishment module, and a map information update module.
  • the order information processing system 110 may only have processing functions and not involve the receiving unit and the transmitting unit. Corrections and changes such as these are within the scope of the present application.
  • Figure 15 provides an exemplary flow chart of an order allocation method, in accordance with some embodiments of the present application.
  • coordinate information of the order requester and the order recipient in the order can be obtained.
  • the coordinate information obtaining subunit 1410 may acquire the coordinate information of the order requester and each order recipient within the preset range of the coordinate information, and each order receiver Coordinate letter interest.
  • the order requester's coordinate information may be added to the taxi request sent by the order requester, and after receiving the taxi request sent by the order requester, the coordinate information of the order requester is obtained from the taxi request.
  • the location information of each order recipient within a preset range of the coordinate information of the order requester in real time can be determined by the positioning system positioning information and/or the base station positioning information and uploaded in real time.
  • the taxi request sent by the order requester may further include one or more of information such as a departure place, an origin, a destination, and a user identifier of the order requester.
  • the user identifier of the order requester may include one or more of a mobile phone number, an identity code (id), and a hardware address (MAC).
  • id identity code
  • MAC hardware address
  • the specific value of the preset range may be set and adjusted according to information such as the traffic road condition of the city to which the order requester belongs, the specific urban area of the city to which the order belongs. For example, if the city where the order requester belongs is Daxing District of Beijing and the traffic conditions are good, the value of the preset range is set to be larger. If the city where the order requester belongs is Haidian District of Beijing, the traffic condition is relatively congested, then Set the value of the preset range to be smaller. This application does not specifically limit this.
  • the coordinate information may include one or any combination of absolute coordinate information, relative coordinate information, relative polar coordinate information, and the like.
  • the coordinate information can also be any combination of ordered pairs or data values that can calibrate geographic relationships.
  • the road surface distance between the order requestor and the order recipient can be obtained. For example, based on the traffic map information of the city to which the order requester belongs, the coordinate information of the order requester, and the coordinate information of each order recipient, the road surface distance obtaining sub-unit 1420 can acquire the road surface of the order requester to each order receiver. distance.
  • the order requester can be calculated by the traffic map information of the city to which the order requester belongs and the coordinate information of the order requester and the coordinate information of each order receiver within the preset range of the order requester.
  • the actual road surface distance of an order recipient Through the order allocation phase, under the same conditions, the roots can be The order is distributed according to the actual road surface distance of the order requester to each order receiver, so that the order receiver can obtain the order information more accurately.
  • the order rate of the order recipient can be predicted. For example, based on the road surface distance corresponding to each order recipient and the related feature information of the historical order of the order receiver within the preset time period, the grab rate prediction unit 342 can predict the order grab probability of the order receiver.
  • the rush rate prediction unit 342 can pass the road distance corresponding to each order recipient and other order-related feature information of the order recipient to the order recipient.
  • the order grab probability is predicted.
  • the order can be allocated according to the orders of the order recipients, for example, by ordering the order grab probability, sending the order to the order receiver according to the order probability, or preset a grab probability threshold. Filter the order recipients.
  • the relevant feature information of the order includes order recipient related feature information, order related feature information, and the like.
  • step 1530 can include predicting an order grab probability for each order recipient using a pre-established predictive model.
  • the prediction model may be established according to relevant feature information of the historical order of the order receiver within a preset time period, the road surface distance may be a predictive variable of the forecast model, and the order grab probability of the order receiver may be the prediction model Target variable.
  • the relevant feature information of the historical order may include a combination of one or a combination of the city that generated the historical order, the time the historical order was generated, the road congestion condition of the historical order, and the value of the historical order. .
  • the prediction model For a description of the prediction model, reference may be made to the description in the system embodiment in this application.
  • the following steps may be included before predicting the order grab probability for each order recipient using a pre-established predictive model:
  • the road surface distance obtaining sub-unit 1420 can acquire relevant feature information of a historical order of each order recipient within a preset time period and a road surface distance corresponding to the order receiver in each historical order. Then, the grab rate prediction unit 342 can use the relevant feature information of the historical order and the road surface distance corresponding to the order receiver in each historical order as training data, and use the linear regression model to train the training data to obtain an order grab.
  • a single probability prediction model may be used according to the relevant feature information of the online real-time acquired order and the road surface distance corresponding to the order receiver in the corresponding order. The established predictive model is optimized.
  • the various feature data in the relevant feature of the historical order may be extracted as a predictor, and the linear order regression model training may be performed with the order grab result of the historical order as the target variable, and the order grab probability is obtained.
  • Forecast model may be performed with the order grab result of the historical order as the target variable, and the order grab probability is obtained.
  • the linear regression model can be one of a logistic regression model and a support vector machine model.
  • a logistic regression model see the description of the System Embodiments section (see Figure 14).
  • the order grab probability prediction can be divided into two phases, offline training and online real-time calculation.
  • the offline training stage can extract various feature data in the relevant features of the historical order, such as driver related features, order related features, etc. into predictive variables, use the competition probability of the order as the target variable, and use the historical data to model Train and get a predictive model.
  • the model can be applied to the line, and the relevant feature information of the real-time extracted order and the road surface distance corresponding to the order receiver in the corresponding order are calculated, and the pre-established prediction model is adopted by using a machine learning algorithm. optimize. See the rest of this application for a description of machine learning algorithms.
  • the order corresponding to the taxi request may be assigned to the order recipient based on the order grab probability of each order recipient.
  • the order assigning unit 361 can assign an order corresponding to the taxi request to the order receiver according to the order grab probability of each order recipient.
  • the order corresponding to the taxi request may include the origin of the order requester, the origin, the destination, the user identification, the time at which the order was generated, the departure time, and the order requestor to each order recipient.
  • One or a combination of information such as road surface distance.
  • step 1540 may specifically include selecting an order grab probability from the order grab probability that is greater than a preset threshold, and ordering the billing probability for each order selected.
  • the single recipient assigns an order corresponding to the taxi request.
  • the current order may be sent to the order recipient in descending order of the order grab probability. For example, in the case of sending a plurality of orders including the current order to the order recipient, if the order probability of the historical order related to the current order is smaller than the grab order probability of the historical order related to other current orders, It is then determined that the current order will likely be of no value or low value for the order recipient. Therefore, it is necessary to select an order grab probability that is greater than a preset threshold in the order grab probability, and allocate an order corresponding to the taxi request to the order receiver corresponding to each selected order grab probability.
  • the order assigning method may further include updating the traffic map information of the city to which the order requester belongs according to the preset time period. For example, by adopting the updated traffic map information of the city, it is possible to prevent the change of the map information caused by the transformation of the traffic route by the urban traffic construction, thereby accurately obtaining the road distance of the order requester to each order receiver.
  • the order allocation method described in FIG. 15 is merely for convenience of understanding the application, and the present application is not limited to the scope of the embodiments. It will be understood that those skilled in the art, after understanding the principle of the method, may arbitrarily combine the various steps without departing from the principle, or the application form and details of the implementation of the above method. Various corrections and changes. For example, the road surface distance between the order requester and the order receiver can be obtained by calculating other ways than coordinates. As another example, the order acceptor's grab rate can be trained through a decision tree model. These modifications and changes are within the scope of this application.
  • FIG. 16 provides a schematic diagram of an order distribution system 110, in accordance with some embodiments of the present application.
  • order distribution system 110 can include one or more interface modules 230/240 and one or more processing modules 210.
  • the interface module 230/240 may further include one or more receiving units 231 and one or more transmitting units 232.
  • the processing module 210 may further include one or more matching condition obtaining units 1610, one or more order screening units 312, one or more pass level determining units 333, one or more grab rate prediction units 342, and one or more One of the order allocating units 361 Kind or any combination of several.
  • a related description of the interface module 230/240, the receiving unit 231, and the transmitting unit 232 can be found in the related description of any other part of the application.
  • the matching condition obtaining unit 1610 may be configured to acquire an order matching condition corresponding to the user.
  • the order matching condition may include a matching range of the order, a matching time, and the like.
  • the matching range of the order may be determined according to the city to which the user belongs, the urban area, and the current geographic location of the user, the current athletic status, and the current destination of the driver user.
  • the matching time may be determined based on the current schedule of the driver user.
  • the matching condition acquisition unit 1610 may further include one or any combination of an order matching condition receiving unit, an order matching condition determining unit, and the like.
  • the order matching condition receiving unit may be configured to receive an order matching condition uploaded by the user; the order matching condition determining unit may be configured to determine an order matching condition corresponding to the user according to the current motion state, the geographical location, and the like of the user and the preset rule. .
  • the order screening unit 312 can be configured to conditionally match the current order according to the order matching condition corresponding to the user, and filter out the order that meets the matching condition of the order.
  • the current order may be an order to be assigned in the taxi platform.
  • the traversing level determining unit 333 can be used to determine the traversal level corresponding to each order for each order and preset policy selected by the order screening unit 312.
  • the downstream level determining unit 333 may further include an order address obtaining unit, a terminal address obtaining unit, and a downstream level determining unit.
  • the order address obtaining unit may be used to obtain the origin and destination of the selected order.
  • the terminal address obtaining unit may be configured to acquire the current destination of the user.
  • the forward route determining unit may be configured to determine, according to the preset policy, a destination level of the current destination of the owner of the order and a destination of the user corresponding to the destination.
  • the forward level may include direct and indirect arrivals. Specifically, the specific setting of the smoothing level can be more accurately set and divided according to the user's needs.
  • the forward route level may be divided into five levels of A, B, C, D, and E according to the road distance that the driver user actually needs to travel, and/or the time required for actual driving. Among them, the distance that the driver user actually needs to travel, and/or the actual line
  • the time required for driving can be a preset strategy for determining the order level of the order corresponding to the user.
  • the rush rate prediction unit 342 can be configured to use a pre-established sneak probability prediction model to predict the order rush probability of the user based on the traversal level of the order.
  • the order assigning unit 361 can be configured to determine whether to allocate the filtered order to the user according to the order grab probability predicted by the grab rate prediction unit 342.
  • the order allocation unit 361 can further include a determination unit and an allocation unit.
  • the determining unit may be configured to determine whether the order grab probability is greater than a preset threshold.
  • the allocating unit may be configured to determine that the order meets the order allocation condition when the judgment result of the determining unit is greater than a preset threshold, and allocate the filtered order to the user.
  • the allocating unit may be further configured to: when there are multiple orders in the selected order that meet the order allocation condition, assign the order to the order according to the order probability of the order being grabbed. Order.
  • the order distribution system 110 may further include one or any of a historical data acquisition module, a predictive model establishment module, and the like.
  • the historical data obtaining module may be configured to acquire historical order data of the user within a predetermined time period.
  • the predictive model building module can be used to use the historical order data as training data, and the training data is trained by using a linear regression model to obtain an estimated model of the grab probability.
  • the historical order data may include a pass grade feature for each historical order corresponding to the user.
  • the linear regression model can be one of the following: a logistic regression model, a support vector machine model.
  • the linear regression model used in the prediction model building module is further illustrated by taking the Logistic regression model as a linear regression training model as an example.
  • the Logistic Regression model can be widely used in the two-class problem.
  • X represents the predictor variable
  • Y represents the target variable
  • w indicates a model parameter
  • historical order data (eg, one or more of order related features at the time of the order, driver related features, order and driver related features, etc.) may be extracted into the predictor variable X, and the new order will be initiated.
  • the probability of competition is the target variable Y.
  • the competition probability of the current order to be allocated can be predicted.
  • the accuracy of the logistic regression model can also be continually improved by continuously adding features to whether the newly initiated order is robbed.
  • the predictive model building module may be further configured to optimize the order probability prediction model by using a machine learning algorithm according to online order data acquired in real time.
  • the order data acquired in real time may include a pass grade feature of the corresponding user of the order. See the rest of this application for a description of machine learning algorithms.
  • the order distribution system 110 depicted in FIG. 16 is merely for ease of understanding of the application and is not intended to limit the application to the scope of the embodiments. It will be understood that, after understanding the principle of the system, it is possible for the various modules/units to be arbitrarily combined, or the subsystems are connected to other modules, or Various modifications and changes in the form and details of the field of application for implementing the above systems.
  • the order distribution system 110 may directly filter the order without including the matching condition acquisition unit 1610.
  • the order distribution system 110 may further include one or any of a history data acquisition module, a prediction model establishment module, and the like.
  • the interface module 230/240 can be omitted. Modifications and variations such as these are within the scope of the present application.
  • FIG. 17 provides an exemplary flow chart of an order allocation method, which may include the following steps:
  • an order matching condition corresponding to the user may be obtained.
  • the matching condition obtaining unit 1610 can acquire an order matching condition corresponding to the user.
  • the order matching condition may be obtained by receiving an order matching condition uploaded by the user.
  • the order matching condition may be acquired by monitoring the current motion state information of the user, such as the driving speed, the driving direction, etc., based on the current motion state information of the user, determining the order matching of the user according to the preset rule. condition.
  • the prediction rules can be set according to distance and time gaps that the driver can accept.
  • step 1710 can also be omitted without having to obtain the order matching criteria corresponding to the user.
  • the current order can be matched according to the order matching condition corresponding to the user, and the order that meets the matching condition of the order is filtered out.
  • the order screening unit 312 can conditionally match the current order according to the order matching condition corresponding to the user, and filter out the order that meets the matching condition of the order.
  • the current order may be an order to be assigned in the taxi platform. After the taxi platform generates the corresponding order according to the taxi request, the taxi platform will match the current order according to the order matching condition corresponding to the terminal, and select the order to be allocated in the taxi platform that meets the matching condition of the order to allocate to the terminal.
  • the order matching condition may include a matching range of the order, a matching time, and the like.
  • the matching range of the order may be determined according to the geographic location of the user, the urban area, and the current geographic location of the terminal, the current motion state, and the current destination of the driver user; the matching time may be determined according to the current schedule of the driver user. .
  • the order level corresponding to the order may be determined according to a preset policy.
  • the smoothing level determining unit 333 may determine, according to a preset policy, the order level of the order corresponding to the user for each of the filtered orders.
  • determining the traversal level of the corresponding user according to the preset policy may further include obtaining the origin and destination of the selected item, obtaining the current destination of the user, and determining the order according to the preset policy.
  • the order information may include, but is not limited to, the order itself information, User information and other information.
  • the order itself information may include order number, departure place, departure time, order time, departure time, arrival time, waiting time, mileage, number of passengers, availability of luggage, price, payment method (eg cash payment, credit card payment, online A payment or a combination of any information, such as payment, remittance payment, etc., consumer price increase, service party price adjustment, system price adjustment, red envelope/coupon usage, order completion status, service provider selection order status, consumer order status, etc. .
  • the origin of the order can be entered or spoken by the passenger using his user terminal to activate the taxi software passenger terminal, or can be done via the positioning system.
  • the technologies used in the positioning system include, but are not limited to, Global Positioning System (GPS) technology, Global Navigation Satellite System (GLONASS) technology, Beidou navigation system technology, Galileo positioning system (Galileo) technology, and Quasi-Zenith satellite system (QAZZ) technology.
  • GPS Global Positioning System
  • GLONASS Global Navigation Satellite System
  • Beidou navigation system technology Beidou navigation system technology
  • Galileo positioning system Galileo positioning system
  • QAZZ Quasi-Zenith satellite system
  • base station positioning technology Wi-Fi positioning technology
  • various positioning and speed measuring systems that are provided by the vehicle.
  • the origin of the order may also be determined via other information as appropriate.
  • the other information may include, but is not limited to, a bus stop, a subway station, a specific intersection, and a specific building, and two-dimensional code information posted at the locations.
  • a pre-established grab rate prediction model may be employed to predict the order grab rate of the user based on the order level of each order.
  • the order grab rate can be calculated by the grab rate prediction unit 342.
  • the order of the order of an order can be determined by the order routing level determining unit 333.
  • step 1750 it may be determined whether to assign the filtered order to the user based on the order grab rate.
  • the order assigning unit 361 may determine whether to allocate the filtered order to the user based on the order grab rate predicted by the grab rate prediction unit 342.
  • step 1750 may specifically include determining whether the grab probability is greater than a preset threshold. When greater than the preset threshold, determining that the order meets the condition of the order allocation, and assigning the filtered order to the user.
  • the order when there are multiple orders in the selected order that meet the order allocation condition, the order may be further included in the order of the order grab probability, and the order that meets the order allocation condition is allocated to the user.
  • the method of order allocation may further include acquiring the user in timing
  • the historical order data in the interval is used as the training data, and the training data is trained by the linear regression model to obtain the grab probability prediction model.
  • the historical order data includes the traversal level characteristics of the user corresponding to each historical order.
  • the linear regression model can be one of a logistic regression model and a support vector machine model.
  • Logistic regression model reference may be made to the description in the corresponding system embodiment in this application.
  • the method may further include: optimizing the grab probability prediction model by using a machine learning algorithm according to online order data acquired in real time.
  • the order data corresponding to the order of the order may be included in the order data acquired in real time.
  • the order grab probability estimate can be divided into two phases: offline training and online real-time calculation.
  • offline training phase various characteristics such as order related features, driver-related features, orders and driver-related features during the broadcast can be extracted into predictive variables, whether the driver is grabbed as the target variable, and the history of the broadcast and the grab is used.
  • the data is trained in the model to obtain a model for predicting the probability of grabbing a single.
  • the model can be applied to the line, and the real-time extracted order is calculated corresponding to the user's smoothness level, and the machine learning algorithm is used to optimize the pre-established prediction model.
  • the machine learning algorithm is used to optimize the pre-established prediction model.
  • step 1710 may be omitted, that is, the order matching condition corresponding to the user may be a default condition without user upload or setting.
  • the order acceptor's grab rate can be trained through a decision tree model.
  • FIG. 18 provides an order distribution system 110 in accordance with some embodiments of the present application.
  • order distribution system 110 can include one or more interface modules 230/240 and one or more processing modules 210.
  • the interface module 230/240 may further include one or more receiving units 231 and one or more transmitting units 232.
  • the processing module 210 may further include one or more order generating units 311, one or more user terminal screening units 323, one or more determining modules 330, one or more grab rate prediction units 342, and one or more order allocations Unit 361.
  • the determining module 330 may further include one or more play order radius determining units 331 and one or more distance determining units 334.
  • a related description of the interface module 230/240, the receiving unit 231, and the transmitting unit 232 can be found in the related description of any other part of the application.
  • the order generating unit 311 can be configured to generate an order according to the taxi request when receiving the taxi request of the user terminal.
  • the user terminal screening unit 323 can be configured to acquire at least one user terminal within the broadcast order range of the order according to the departure place of the order.
  • the play order radius determining unit 331 may be configured to acquire historical order data in the first preset time period in the preset area, and then determine the current order broadcast order according to the historical order data and the time information of the current order. range.
  • the range in which the order grab probability is greater than the preset threshold within a preset time period may be defined as the broadcast order range of the current order based on the departure place.
  • the distance determining unit 334 can be configured to determine, for each of the acquired user terminals, a distance between the current location of the terminal and the departure location of the order.
  • the rush rate prediction unit 342 can be configured to adopt a pre-established sneak probability prediction model, and obtain a sneak probability of the user terminal according to the distance and the current time information.
  • the order assigning unit 361 can be configured to allocate the order according to the grab probability of the at least one user terminal. Specifically, when the at least one user terminal only includes one terminal, the order may be sent to the terminal; when the at least one user terminal includes multiple terminals, the probability of grabbing orders of multiple terminals may be changed from large to small. The order is sent to the plurality of terminals in sequence.
  • the order distribution system 110 can also include an estimate model Stand unit.
  • the predictive model building unit can be used to use the historical order data as feature data, and the feature data is trained by using a linear regression model to obtain an estimated model of the grab probability.
  • the historical order data may include the transaction distance of each transaction order, the transaction time, the time taken by the terminal to arrive at the place of departure, the robbed distance of canceling the order after each response, the time of robbing, the cancellation time, and the terminal distance when the order is cancelled. Any combination of one or several of the data such as the distance from the place of departure of the order.
  • the linear regression model may be one of a logistic regression model or a support vector machine model, or may be other models.
  • the order distribution system 110 can also include a model optimization unit.
  • the model optimization unit can be used to optimize the grab probability prediction model based on the order data acquired in real time and using a machine learning algorithm. For a description of the machine learning algorithm, refer to the descriptions of other parts of this application.
  • the order distribution system 110 depicted in FIG. 18 is merely for ease of understanding of the application and is not intended to limit the application to the scope of the embodiments. It will be understood that, after understanding the principle of the system, it is possible for the various modules/units to be arbitrarily combined, or the subsystems are connected to other modules, or Various modifications and changes in the form and details of the field of application for implementing the above systems.
  • the determination module 330 may not include the play order radius determining unit, and directly adopts the default play order radius.
  • the order distribution system 110 can directly perform screening assignments on existing orders without including the order generating unit 311. Modifications and variations such as these are within the scope of the present application.
  • FIG. 19 provides an exemplary flow chart of an order allocation method that may include the following steps:
  • an order may be generated according to the taxi request to obtain the origin of the order.
  • the order generating unit 311 may generate an order according to the taxi request after receiving the taxi request of the user terminal, and acquire the origin of the order.
  • At step 1920, at least one user terminal within the broadcast order range of the order may be acquired based on the origin of the order.
  • the user terminal screening unit 323 can acquire at least one user terminal within the broadcast order range of the order according to the origin of the order.
  • the order probability of an order within a preset time period may be based on the origin of the origin.
  • a range greater than the preset threshold is set to the current play range.
  • the preset threshold can be set to 100%, and each order within the preset time period (for example, yesterday) is robbed in the broadcast order. The probability is 100%.
  • the order quantity of the current order is determined according to the order history data in the preset time period, and the terminal is initially screened according to the broadcast range (maximum order distance), and the taxi system can only be within the broadcast order range.
  • the terminal sends the order information to match the best distance order for the driver of the most suitable order.
  • the distance between the current location of the terminal and the departure place of the order may be determined for each terminal acquired.
  • the distance determining unit 334 may determine, for each terminal acquired, the distance between the current location of the terminal and the departure place of the order.
  • the user terminal can obtain its current location according to the positioning technology and send it to the taxi system, and the taxi system calculates the distance between the current location of the terminal and the origin of the order.
  • the distance may be a linear distance between the user terminal and the place of departure of the order, or may be the actual distance traveled by the user terminal obtained by the positioning system and/or the actual road condition information to the place of departure of the order.
  • a pre-established grab probability estimation model may be adopted, and the grab probability of the terminal is obtained according to the distance and the current time information.
  • the grab rate prediction unit 342 may use a pre-established grab probability estimation model to obtain the grab probability of the terminal based on the distance and the current time information.
  • the terminal may predict the order probability of the order.
  • the one-step prediction of the grab probability may also be made by the distance between the user's origin and the destination, the order value, the road condition information, and the like.
  • the probability that the terminal grabs the order for the order may be affected by the distance, current time information, etc., and the current time information may reflect characteristics such as a peak period or a peak period, for example, a peak period from 8:00 am to 9:00 am, and the pair is broadcasted.
  • the range and the probability of grabbing will definitely have an impact; the closer the distance, the higher the probability of grabbing.
  • the order can be allocated based on the grab probability of the at least one terminal.
  • the order assigning unit 361 can allocate the order according to the grab probability of the at least one terminal.
  • the order may be sent to the terminal; when the at least one user terminal includes multiple terminals, the multiple terminals may be sequentially sent to the multiple terminals according to the order probability of the multiple terminals. The order.
  • step 1920 the following steps may also be included:
  • the historical order data in the first preset time period in the preset area is acquired.
  • the historical order data may include the transaction distance of each transaction order, the transaction time, the time taken by the terminal to reach the departure place of the order, the grabbing distance of canceling the order after each response, the time of grabbing the order, the cancellation time, and the terminal distance when the order is cancelled.
  • the preset area may represent a geographic area, such as a different city or a different area of the same city.
  • the broadcast order range of the current order is determined.
  • the historical order data can be analyzed, for example, the historical order data is counted by hour and sub-region, and the maximum order distance (the broadcast order range) of the order in different time zones of different regions can be obtained, and further according to the time information of the current order, From the departure location information, etc., you can determine the scope of the current order.
  • the above two steps can obtain the maximum order distance of different cities in different time periods.
  • the broadcast range can be continuously updated dynamically, that is, according to the related features of whether the newly-initiated order is robbed, the grabbing distance, the grabbing time, and the grabbing area, the broadcast range is re-pre-predicted. estimate.
  • the range of broadcast orders for orders received today can be estimated based on yesterday's historical order data.
  • the historical order data may be included as feature data, and the feature data is trained by using a linear regression model to obtain a grab probability prediction model.
  • the linear regression model may be one of a logistic regression model or a support vector machine model, or may be other models. A related description of the Logistic regression model can be found in the description of the rest of the application.
  • the method may further include: optimizing the grab probability estimation model by using a machine learning algorithm according to the online data acquired in real time.
  • the accuracy of the logistic regression model is continually improved by continuously adding features that are relevant to whether the newly initiated order is robbed.
  • the grab probability estimation is divided into offline training and online real-time meter Count two stages.
  • various characteristics such as order related features, terminal related features, orders and terminal related features during the broadcast can be extracted into predictive variables, and whether the terminal is grabbed as the target variable, and the historical data of the broadcast and the grab is used.
  • the model is trained to obtain a model for predicting the probability of grabbing a single.
  • the online real-time calculation phase can apply the model to the line, and calculate the distance between the current order origin of the current order and the current position of the terminal.
  • a description of the machine learning algorithm can be found in the description of other parts of the application.
  • the order allocation method described in FIG. 19 is merely for convenience of understanding the application, and the present application is not limited to the scope of the embodiments. It will be understood that those skilled in the art, after understanding the principle of the method, may arbitrarily combine the various steps without departing from the principle, or the application form and details of the implementation of the above method. Various corrections and changes.
  • the playlist range can be updated at any time.
  • the order acceptor's grab rate can be trained through a decision tree model.
  • the current order can be sent to the user.
  • the current order can be sent to the user by the sending unit 232 (see Figure 3).
  • the order type and order information, etc. refer to the relevant description of this application.
  • the historical grab time of the user for the historical order from receipt to grabbing may be obtained.
  • the user information acquisition unit 324 may acquire the historical grab time of the user for receiving the historical order from the receipt of the order.
  • the current order can be sent based on the historical grab time.
  • the current order can be sent by the determination module 330 (see FIG. 3) based on the historical grab time.
  • step 2030 can further include the following two steps:
  • the user may be set to set a timer to determine whether the user has grabbed the order within a predetermined time, and if the ticket is grabbed, record the historical grab time of the user for the order from receipt to grab.
  • the C02. Determine, according to the historical grab time, the user to grab the scheduled time. Single rate.
  • the rush rate can be determined by determining the number of rush orders for the user for all historical orders, determining the number of rush orders for the user after the predetermined time, and determining that the user is after the predetermined time The rate of grabbing.
  • the robbing rate may be determined by determining a plurality of rush time intervals based on the historical rush time; and determining that the user is robbed in the rush time interval of the historical rush time.
  • the rush rate may be determined based on the number of rush orders of the user for all historical orders and the number of robbed times of the user in the rush time interval of the historical rush time; and determining that the user is The rate of grabbing in the grabbing time interval after the scheduled time.
  • the transaction rate of the current order may be determined first based on the grab rate.
  • P n is the rate of grabbing of the user n after the predetermined time.
  • the current order can then be sent based on the transaction rate.
  • a plurality of current orders including the current order may be transmitted in descending order of the grab rate x (1 - trade rate), which may make the order grab rate higher, the higher the priority, and the order The lower the transaction rate, the higher the priority, so that the order grab rate and the transaction rate are comprehensively considered.
  • the order can be presented or played to dn -2 users.
  • dn-2 users may be represented by the symbol D n-2 hereinafter.
  • the order can be presented or played to dn -1 users.
  • dn-1 users can be represented by the symbol D n-1 hereinafter.
  • step 2130 the n-th wheel distribution at time t n the beginning, if the user D n-2 from the time t n-2 to the time t does not grab a single predetermined time n, based on the user D n-2 for
  • the historical order time of the historical order from the receipt to the grab is determined, and the grab rate of the user D n-2 after the predetermined time is determined, for example, P (user D n-2 grabs the order after time t n ).
  • this grab rate can be determined by the following conditional probability formula 7.
  • P user D n-2 grabs the ticket after time t n-2
  • P may indicate the grab rate of the user D n-2 for the current order.
  • this grab rate represents a willingness to grab a ticket, usually depending on various factors: the distance between the origin of the current order and the current location of the user D n-2 , The distance between the origin of the current order and the destination, whether the origin of the current order is in the vicinity of the current travel route of the user Dn-2 , and the like.
  • P user D n-2 grabs the order after time t n
  • the cost ratio The probability of the grab action is executed from time t n-2 to time t longer.
  • this probability represents a grabbing ability, usually depending on various factors: the user D n-2 takes a long time to listen to the current order, and the user D n-2 costs more. It is necessary to decide whether to grab the bill for a long time, and the user D n-2 takes a long time to perform the grabbing action because the vehicle is very cautious.
  • P (user D n-2 grabs a ticket after time t n
  • a past period of time eg, one week, one month, one year, etc.
  • the number of times the user D n-2 grabs the ticket after the predetermined time is determined. For example, the number of grabs of the user D n-2 in the grab operation of the past period of time (for example, one week, one month, one year, etc.) and after the time t n is determined.
  • P is determined (user D n-2 grabs the order after time t n
  • P (user D n-2 grabs the ticket after time t n
  • the rate of grabbing of the user D n-2 in the grabbing time interval to which the historical grab time belongs is determined.
  • the user can determine that the D n-2 for the number of single grab all the historical orders, determine the number of times within a single grab the user D n-2 grab a single time interval in the history belongs to grab a single time, and based on these two The number of grabs is determined, and the grab rate of the user D n-2 in the grab time period of the historical grab time is determined.
  • the rush rate of the user D n-2 in the rush time period to which the historical rush time belongs may be equal to the quotient of the number of rush orders and the number of previous robbed times.
  • the above probability may also be determined by a schematic diagram of the historical grab time distribution shown in FIG. 21B.
  • the rate of grabbing in the corresponding grab time interval is determined by the probability density curve at each subsequent time point.
  • the grab rate of the user D n-2 in the historical grab time t n to t n+1 is a graph surrounded by the probability density curve and the abscissa axis at the historical grab time t n to t n The area within +1 .
  • the grab rate of the user D n-2 in the historical grab time t n+1 to t n+2 is a graph surrounded by the probability density curve and the abscissa axis at the historical grab time t n +1 to the area within t n+2 .
  • the sum of the rush rates in the rush time period of the user D n-2 after the predetermined time is determined. For example, determining the sum of the rush rate of the user D n-2 in the historical rush time t n to t n+1 and the historical rush time t n+1 to t n+2 , wherein the probability may be The area enclosed by the probability density curve and the abscissa axis is the area within the historical grab time t n to t n+2 .
  • step 2140 the n-th wheel distribution at the time tn, the beginning, if the user D n-1 from the time t n-1 to the time t does not grab a single predetermined time n, based on the user D n-1 of the historical
  • the order grab-off time from the receipt to the grab order determines the grab rate of the user D n-1 after the predetermined time, for example, P (user D n-1 grabs the ticket after time t n ).
  • step 1240 is similar to step 1230, and therefore will not be described again. At the same time, those skilled in the art can also understand that there is no strict execution order between step 1240 and step 1230. For example, step 1240 may precede step 1230. Execution can also be performed simultaneously with step 1230.
  • the transaction rate of the current order may be determined based on the rush rate determined at step 2130 and the rush rate determined at step 2140.
  • the transaction rate can be determined by Equation 8 below:
  • the rush rate determined in step 1230 and the rush rate determined in step 1240 are greater than a predetermined rush rate threshold, so as to avoid The effect of the determined user with a small grab rate on the turnover rate.
  • the grab rate threshold may be a value or an interval.
  • step 1260 it is determined whether the transaction rate of the current order determined in step 1250 is greater than a predetermined transaction rate threshold. If so, the current order has been presented or played to a sufficient number of users, so the current transmission is prohibited in the nth round of allocation. Order, and the method ends. Otherwise, step 2170 is performed.
  • a plurality of current orders including the current order are transmitted based on the order of the transaction rate determined in step 1250 from low to high, so that the current order with a lower turnover rate in the nth round of distribution can be more presented. Or play.
  • a plurality of current orders including a current order may be transmitted in descending order of the grab rate x (1 - trade rate), which may make the order grab rate higher The higher the level, and the lower the order turnover rate, the higher the priority, so that the order grab rate and the transaction rate are comprehensively considered in the nth round of distribution.
  • step 21A may change the order of execution, some steps may be omitted, some steps may be added, multiple steps may be combined into one step, and/or one step may be decomposed into multiple steps.
  • step 2120 and step 2130 may be performed in any order or simultaneously, and step 2120 and step 2130 may be combined into one step execution.
  • FIG. 22 provides a schematic diagram of an order distribution system 110, in accordance with some embodiments of the present application.
  • order distribution system 110 can include one or more order interface modules 230/240 and one or more processing modules 210.
  • the interface module 230/240 may further include one or more receiving units 231 and one or more transmitting units 232.
  • Processing module 210 may further include one or more subscription probability calculation units 341 and one or more analysis modules 350.
  • Analysis module 350 may further include one or more comparison units 351 and one or more determination units 352.
  • the receiving unit 231 can be configured to receive a taxi request sent by the user terminal.
  • the sending unit 232 can be configured to generate order information according to the taxiing request acquired by the receiving unit 231, and send the order information to the first terminal.
  • the order information may be sent to the first terminal according to an order allocation policy.
  • the order information may include a preset range set by the departure place, and the order information may be sent to any terminal in the preset range according to the preset range.
  • the subscription probability calculation unit 341 can be configured to obtain a probability that the order information is subscribed according to the initial rush rate and the robbed attenuation characteristic of the first terminal.
  • the initial rush rate of the first terminal may be an initial rush rate generated according to the order information.
  • the grabbing attenuation characteristic of the first terminal may be obtained in advance according to the order history data of the first terminal.
  • the subscription probability calculation unit 341 can be used to combine one or any combination of information such as a departure point, a destination, a user indication, an order generation time, and location information of the first terminal in the order information.
  • the initial rush rate s(t0) of the first terminal is generated; and the pre-established singularity attenuation characteristic f 0 (t) of the first terminal is obtained, and the probability Psr that the order information is subscribed can be obtained by using the following formula 9:
  • s(tn) may represent the initial robbing rate of the (N+1)th terminal
  • n may be a positive integer greater than or equal to
  • fn(t) may represent the singularity attenuation characteristic of the (N+1) th terminal.
  • f 0 (0), ..., f n (0) may both be set to 1.
  • the comparing unit 351 can be configured to compare the subscription probability with a preset threshold to obtain a comparison result.
  • the determining unit 352 can be configured to determine, according to the comparison result, whether the order information is sent to the Nth terminal; wherein N is a positive integer, and N is greater than or equal to 2, and the first terminal to the Nth terminal are both A terminal for providing an operation service for the user terminal.
  • the determining unit 352 can send the order information to the Nth terminal.
  • the determining unit 352 is further configured to obtain an initial rush rate and a robbed attenuation characteristic of the Nth terminal.
  • the initial rush rate of the Nth terminal may be an initial rush rate generated according to the order information, and the singularity attenuation characteristic of the Nth terminal may be obtained according to the order history data of the Nth terminal in advance.
  • the subscription probability that the order information is subscribed may be obtained; and the subscription probability is compared with a preset threshold.
  • the order distribution system 110 may further include a preset unit, which may be configured to establish a sneak mitigation characteristic of the terminal according to the order history data of each terminal.
  • the preset unit may obtain, for each terminal, historical data of the broadcast time information and the grab time information of the multiple orders corresponding to the terminal.
  • the broadcast time information may be a time point when the order information is broadcast to the terminal, and the grab time information may be a time point when the terminal subscribes to the order information. According to the historical data, the grabbing attenuation characteristic of the terminal can be obtained.
  • the preset unit may be further configured to analyze a difference between the broadcast time information and the grab time information corresponding to each order information in the historical data, and determine a characteristic that the ticket grab probability of the terminal decays with time, and obtain The terminal's grab attenuating characteristics.
  • the order distribution system 110 can also include a redundancy unit.
  • the redundancy unit can be used to remove redundant data in the historical data. Which redundant data can The data includes the same order information broadcasted to the same terminal with multiple broadcast time information, and the same terminal subscribes to the same order information with multiple grab time information. Specifically, when the same order information is broadcast to the same terminal and has multiple broadcast time information, the latest one of the plurality of play time information is retained. When the same terminal subscribes to the same order information and has multiple rush time information, the earliest one of the multiple rush time information is retained.
  • the order dispensing system 110 depicted in FIG. 22 is merely for ease of understanding of the application and is not intended to limit the application to the scope of the embodiments. It will be understood that, after understanding the principle of the system, it is possible for the various modules/units to be arbitrarily combined, or the subsystems are connected to other modules, or Various modifications and changes in the form and details of the field of application for implementing the above systems.
  • the comparison unit 351 and the determination unit 352 can be combined into one analysis unit, which can be used to compare and determine the subscription probability.
  • the order distribution system 110 can directly perform screening assignments on existing orders without including the order receiving unit 231. Modifications and variations such as these are within the scope of the present application.
  • FIG. 23 provides an exemplary flowchart of an order allocation method, which may include the following steps:
  • the order information is generated according to the taxi request, and the order information is sent to the first terminal.
  • the sending unit 232 can be configured to generate order information according to the taxi request acquired by the receiving unit 231, and send the order information to the first terminal.
  • the order information may be sent to the first terminal according to an order allocation policy.
  • the order information may include a preset range set by the departure place, and the order information may be sent to any terminal in the preset range according to the preset range.
  • the subscription probability that the acquisition order information is subscribed may be calculated according to the initial rush rate and the robbed attenuation characteristic of the first terminal.
  • the subscription probability calculation unit 341 may calculate the subscription probability that the acquisition order information is subscribed according to the initial rush rate and the robbed attenuation characteristic of the first terminal.
  • the initial rush rate of the first terminal may be an initial rush rate generated according to the order information.
  • the grabbing attenuation characteristic of the first terminal may be obtained in advance according to the order history data of the first terminal.
  • the subscription probability calculation unit 341 can be used to combine one or any combination of information such as a departure point, a destination, a user indication, an order generation time, and location information of the first terminal in the order information.
  • the initial rush rate s(t0) of the first terminal is generated; the preemptive singularity attenuation characteristic f 0 (t) of the first terminal is searched, and the probability Psr of the subscription information being subscribed is obtained by using the subscription probability calculation formula.
  • a related description of the calculation of the subscription probability can be found in the relevant description of the corresponding system embodiment section in this application.
  • the comparison result can be obtained by comparing the subscription probability with a preset threshold.
  • the comparison unit 351 can obtain a comparison result by comparing the subscription probability with a preset threshold.
  • the preset threshold can be set according to the required order probability. For example, if the required subscription probability is 95%, the preset threshold is set to 95%; if the current subscription probability is greater than or equal to 95%, the order information is stopped from being sent to other terminals; if the current subscription probability is less than 95 %, then continue to send the order information to other terminals.
  • the determining unit 352 may determine whether to send the order information to the Nth terminal according to the comparison result acquired in step 2330.
  • N is a positive integer, and N is greater than or equal to 2, and the first terminal to the Nth terminal may each be a terminal for providing an operation service for the user terminal.
  • the order information may continue to be sent to another terminal; when the subscription probability is greater than or equal to the preset threshold, the order information may be stopped.
  • the step 2340 may further include the following steps: when the subscription probability is less than the preset threshold, the order information may be sent to the Nth terminal; and the initial rush rate and the robbed attenuation characteristic of the Nth terminal are obtained; According to the initial rush rate and the robbed attenuation characteristic of all terminals that send the order information, the subscription probability that the order information is subscribed may be obtained; and the subscription probability is compared with a preset threshold.
  • the initial rush rate of the Nth terminal may be an initial rush rate generated according to the order information, and the singularity attenuation characteristic of the Nth terminal may be obtained according to the order history data of the Nth terminal in advance. If the subscription probability is still less than the preset threshold, the order information may continue to be sent to other terminals until the cumulative subscription probability of the order information reaches a preset threshold.
  • the method may further include receiving the user terminal. Send a taxi request.
  • the method before step 2310, further includes establishing a sneak-attenuation characteristic of the terminal according to the order history data of each terminal.
  • the method may include the following steps: for each terminal, the historical data of the broadcast time information and the rush time information of the multiple orders corresponding to the terminal may be obtained; and according to the historical data, the sneak-singing characteristic of the terminal may be acquired.
  • the broadcast time information may be a time point when the order information is broadcast to the terminal
  • the grab time information may be a time point when the terminal subscribes to the order information.
  • establishing a sneak-attenuation characteristic for each terminal may be a preferred case in which each terminal grabs a history sufficiently.
  • the order type of the order can be divided into cities, and the user terminal ID is used as the key value to calculate the time decay curve of the subscription order information of each city terminal.
  • the subscription probability is further calculated based on the attenuation curve.
  • the order type can be an appointment order, an instant order, and the like.
  • redundant data when redundant data is present in the historical data, it may also include removing redundant data in the historical data.
  • the redundant data may include data that sends the same order information to the same terminal with multiple broadcast time information, and the same terminal subscribes to the same order information, and has multiple data of the grab event information. Specifically, when the same order information is sent to the same terminal and there is multiple broadcast time information, the latest one of the broadcast time information may be retained; when the same terminal subscribes to the same order information and has multiple grab event information, the reservation is retained. The earliest grab time in a single time.
  • the method further includes: acquiring the singularity attenuation characteristic of the terminal according to the historical data of removing the redundant data. Specifically, the difference between the broadcast time information and the grab time information corresponding to each order information in the historical data may be analyzed, and the characteristic of the terminal's grab probability is attenuated with time, and the grabbing attenuation characteristic of the terminal is obtained.
  • FIG. 24 provides another exemplary flowchart of an order allocation method, which may include the following steps:
  • order information can be generated based on the taxi request.
  • the receiving unit 231 may receive a taxi request sent by the user terminal, and generate order information according to the taxi request.
  • the order information can be sent to the Mth terminal.
  • the transmitting unit 232 can transmit the order information to the Mth terminal.
  • M may be a positive integer greater than or equal to 1.
  • an initial rush rate and a rush rate attenuation characteristic of the Mth terminal can be obtained.
  • a description of the initial grab rate and grab attenuation characteristics can be found in the relevant descriptions of other parts of the application.
  • the subscription probability that the order information is subscribed may be calculated according to the initial rush rate and the rush rate attenuation characteristics of all terminals that send the order information.
  • the subscription probability calculation unit 341 can calculate the subscription probability that the order information is subscribed according to the initial rush rate and the rush rate attenuation characteristics of all terminals that send the order information.
  • a related description of subscription probability prediction can be found in the relevant descriptions of other parts of the application.
  • the size of the subscription probability and the preset threshold can be compared.
  • the order allocation method described in FIG. 23 and FIG. 24 is merely for convenience of understanding the application, and the present application is not limited to the scope of the embodiments. It will be understood that those skilled in the art, after understanding the principle of the method, may arbitrarily combine the various steps without departing from the principle, or the application form and details of the implementation of the above method. Various corrections and changes.
  • the preset threshold can be manually updated at any time, or it can be automatically updated based on system feedback.
  • historical data can be updated and replaced at any time.
  • FIG. 25 provides a schematic diagram of an order distribution system 110, in accordance with some embodiments of the present application.
  • order distribution system 110 can include one or more order interface modules 230/240 and one or more processing modules 210.
  • the interface module 230/240 may further include one or more receiving units 231 and one or more transmitting units 232.
  • Processing module 210 may further include one or more grab rate prediction units 342 and one or more determination modules 330.
  • the determining module 330 may in turn further comprise one or more real The grab rate determination unit 2510 and one or more accuracy determination units 2520.
  • a related description of the interface module 230/240, the receiving unit 231, and the transmitting unit 232 can be found in the related description of any other part of the application.
  • the grab rate prediction unit 342 can be used to predict the probability that the user will perform a grab operation for the order.
  • the actual grab rate determination unit 2510 can be used to determine the probability that the user actually performs the grab operation for the order.
  • the accuracy determining unit 2520 may be configured to determine the accuracy of the prediction based on the predicted probability and the determined probability.
  • the grab ratio prediction unit 342 can include one extraction unit and one prediction unit.
  • the extraction unit can be used to extract features in the order.
  • the prediction unit may be configured to predict a probability that the user performs an operation for the order based on the predicted weight corresponding to the feature.
  • the actual grab ratio determination unit 2510 may include a first determination unit, a second determination unit, and a third determination unit.
  • the first determining unit may be configured to determine a number of times the user actually performs the grabbing operation for the order; the second determining unit may be configured to determine the number of times the order is issued to the user; the third determining unit may be used to The probability that the user actually performs the grab operation for the order is determined according to the number of grabs and the number of times the order is posted.
  • the accuracy determining unit 2520 can include a fourth determining unit.
  • the fourth determining unit may be configured to determine a relative deviation between the predicted probability and the determined large probability as the accuracy of the prediction.
  • the actual grab ratio determination unit 2510 may further include a fifth determination unit, a sixth determination unit, and a seventh determination unit.
  • the fifth determining unit may be configured to determine the number of times the user actually performs the grabbing operation for the plurality of orders, and the sixth unit may be used to determine the number of times the plurality of orders are issued to the user; the seventh determining unit may use The probability of actually performing a grab operation for the plurality of orders is determined according to the number of times of grabbing and the number of times of posting.
  • the accuracy determining unit 2520 may further include an eighth determining unit and a ninth determining unit.
  • the eighth determining unit may be configured to determine an average value of the plurality of prediction probabilities respectively corresponding to the plurality of orders; the ninth determining unit may be configured to use the average value The relative deviation between the determined probabilities is determined as the accuracy of the prediction.
  • the actual grab ratio determination unit 2510 may include a sorting unit, a first dividing unit, and a first acquiring unit.
  • the sorting unit may be configured to sort the orders according to the predicted probability from small to large; the first dividing unit may be configured to divide the sorted order into a plurality of order groups; the first obtaining unit may be used to Get multiple orders in this group in the order group.
  • the accuracy determining unit 2520 may include a tenth determining unit and an eleventh determining unit.
  • the tenth determining unit may be configured to respectively determine a corresponding prediction probability for each of the plurality of order groups, and a relative deviation between the predicted probability and the corresponding determined probability; the eleventh determining unit may be used to compare the relative deviation The average value is determined as the accuracy of the prediction.
  • the accuracy determining unit 2520 may include a twelfth determining unit and a thirteenth determining unit.
  • the twelfth determining unit may be configured to respectively determine a relative deviation between the probability of the corresponding prediction and the determined probability for each of the plurality of order groups; the thirteenth determining unit may be configured to use the mean square of the relative deviation The root value is determined as the accuracy of the prediction.
  • the actual grab ratio determination unit 2510 may include a second sorting unit, a second dividing unit, and a fourteenth determining unit.
  • the second sorting unit may be configured to sort the broadcast orders issued to each user according to the order of predicting the probability that each user performs the grab operation for the broadcast order from small to large; the second dividing unit may be used to The sorted playlist is divided into a plurality of play order packets; the fourteenth determining unit may be configured to determine, according to each of the plurality of play order packets, the actual user to perform the grab operation in the playlist group The probability.
  • the accuracy determining unit 2520 may include a fifteenth determining unit and a sixteenth determining unit.
  • the fifteenth determining unit may be configured to respectively determine a relative deviation between the corresponding prediction probability and the determined probability for each of the broadcast group packets; the sixteenth determining unit may be configured to determine the average value of the relative deviations as the accuracy of the prediction. degree.
  • the accuracy determining unit 2520 may include a seventeenth determining unit and an eighteenth determining unit.
  • the seventeenth determining unit can be used for each broadcast order The grouping respectively determines a relative deviation between the corresponding prediction probability and the determined probability; the eighteenth determining unit may be configured to determine the root mean square value of the relative deviation as the accuracy of the prediction.
  • the order distribution system 110 depicted in FIG. 25 is merely for ease of understanding of the application and is not intended to limit the application to the scope of the embodiments. It will be understood that, after understanding the principle of the system, it is possible for the various modules/units to be arbitrarily combined, or the subsystems are connected to other modules, or Various modifications and changes in the form and details of the field of application for implementing the above systems. For example, the determination of all actual grab rates and accuracy can be done in one module. For another example, the eighteen determining units do not necessarily indicate that there are eighteen, one determining unit may combine to perform a plurality of determining tasks, and one determining task may also be divided into multiple determining units. Modifications and variations such as these are within the scope of the present application.
  • FIG. 26 provides an exemplary flow chart of an order allocation method, which may include the following steps:
  • the probability that the user will perform a grab operation for the order can be predicted.
  • the snatch probability prediction unit 342 can predict the probability that the user will perform a grab operation for the order.
  • the probability of a grab operation may be predicted by extracting features in the order and predetermined weights corresponding to the features. Among them, according to a predetermined prediction method, features in an order can be assigned different weights. The weights can be determined based on machine learning models using corresponding features in historical orders. For ease of understanding, the following describes the prediction process distance.
  • the characteristics indicating the origin and the user distance in the order may be Assign a larger weight.
  • a probability that the user actually performs a grab operation for the order may be determined.
  • the actual grab rate determination unit 2510 may determine the probability that the user actually performs the grab operation for the order.
  • the number of times the order is issued to the user may be separately determined, and then the order is executed according to the number of times of the order and the number of times of the release.
  • the number of operations determines the probability that the user actually performs a grab operation for the order. For the sake of understanding, an example is given in which the order is issued to 100 users within a predetermined range. If the order Published to the 100 users, the number of publications is 100.
  • the probability that the user actually performs the grab operation for the order may be equal to the ratio of the number of grabs to the number of times of posting, that is, 5%.
  • the accuracy of the prediction may be determined based on the predicted probability and the determined probability.
  • the accuracy determining unit 2520 may determine the accuracy of the prediction based on the predicted probability and the determined probability.
  • the relative deviation between the predicted probability and the determined probability may be determined as the accuracy of the prediction.
  • an example is given by taking the predicted probability of 6% and the determined probability of 5% as an example.
  • the accuracy of the prediction can be calculated according to the following formula 10:
  • the PB can represent the relative deviation between the predicted probability and the determined probability, that is, the prediction accuracy.
  • A can represent the predicted probability, and R can represent the determined probability.
  • the accuracy of the prediction calculated by the above formula can be equal to
  • / 5% 0.2.
  • the number of times the plurality of orders are sent to the plurality of users and the order in which the plurality of orders are actually executed are separately determined.
  • the probability of actually performing the operation is determined according to the number of times of grabbing and the number of times of posting. For example, when 100 orders are issued to the surrounding 100 users, the number of the 100 orders is 10,000. At the same time, for each of the 100 orders, 5 of the 100 users actually perform the grab operation, and the number of grabs is 500. Therefore, the probability of actually performing the grab operation may be equal to the ratio of the number of grabs to the number of times of posting, that is, 5%.
  • multiple orders may be used as a whole to count the number of times of posting and the number of robbing orders, and determine the probability of actually performing a rush order operation based on the number of times of posting and the number of robbing orders.
  • it may also be determined in accordance with other ways to determine the actual probability of a grab operation. For example, determine the actual grab probability for the user for each of the multiple orders and determine the average of these probabilities, respectively. For 100 orders sent to 100 users, if the predicted probability of 50 orders is 6%, the predicted probability of 30 orders is 5.66%, the predicted probability of the other 20 orders is 5%, then the average of the multiple predicted probabilities corresponding to the 100 orders is (50 ⁇ 6% + 30 ⁇ 5.66% + 20 ⁇ 5%) / 100 5.7% . The accuracy of the prediction may be determined based on the relative deviation between the predicted probability (eg, 5.7%) and the determined probability (eg, 5%). According to Equation 10, the accurate reading of the prediction can be calculated as 0.14.
  • FIG. 27 provides an exemplary flowchart of an order allocation method, which is illustrated by taking N orders as an example, and may include the following steps:
  • the probability that the user will perform a grab operation for each of the N orders may be predicted.
  • the grab rate prediction unit 342 can predict the probability that the user will perform a grab operation for each of the N orders, respectively.
  • a description of the prediction step can be found in the related description in step 2610.
  • the N orders are sorted in ascending order of predicted probabilities, and the sorted N orders are divided into a plurality of order groups. Among them, there may be a larger number of orders in each group, for example, k. Therefore, the grouping results can be as follows:
  • P represents the probability that the predicted user performs a grab operation for the corresponding order.
  • step 2730 taking the nth order group as a whole, the probability of the user performing the grab operation for all the orders in the nth order group is predicted by the following formula 11:
  • Equation 12 The probability that the user actually performs the grab operation for all orders in the i-th order group is determined by Equation 12 below:
  • a i represents the probability of predicting the user's execution of the grab operation for the order in the i-th order group
  • R i represents the probability of determining the user's execution of the grab operation for the order in the i-th order group
  • Q i indicates that the user is The number of rush orders for the order in the i-th order group and the actual rush order operation
  • B i indicates the number of times the order in the ith order group is issued to the user.
  • the accuracy of the prediction can be determined.
  • the accuracy determining unit 2520 may determine the average of the probability deviations as the accuracy of the prediction according to the following formula 13:
  • the APB can represent the average of the probability deviations, and thus the accuracy of the prediction.
  • Ai may indicate the probability that the predicted user performs a grab operation for the order in the i-th order group; and may indicate the probability that the determined user actually performs the grab operation for the order in the i-th order group, n
  • the number of packets of the above order group can be represented.
  • the accuracy of the prediction can also be determined by the root mean square value of the probability deviation, as follows:
  • the user equipment for displaying and interacting with the location related information is a mobile device 2800, including but not limited to a smart hand.
  • a mobile device 2800 including but not limited to a smart hand.
  • GPS global positioning system
  • the mobile device 2800 in this example includes one or more central processing units (CPUs) 2840, one or more graphics processing units (GPUs) 2830, a display 2820, a memory 2860, and an antenna 2810 (eg, A wireless communication unit), a storage unit 2890, and one or more input/output (I/O) devices 2850.
  • CPUs central processing units
  • GPUs graphics processing units
  • I/O input/output
  • Any other suitable components such as a system bus or controller (not shown), may also be included in the mobile device 2800.
  • a mobile operating system 2870 such as iOS, Android, Windows Phone, etc.
  • applications 2880 can be loaded into memory 2860 from storage unit 2890 and executed by central processor 2840.
  • Application 2880 may include a browser or other mobile application suitable for receiving and processing order information on mobile device 2800. User interaction with the order information may be obtained by the input/output system device 2850 and provided to the order distribution system 110, and/or other components of the system 100, such as through the network 150.
  • a computer hardware platform may be utilized as a hardware platform for one or more of the elements described above (eg, order allocation system 110, and/or Other components of system 100 described in 1-27).
  • the hardware elements, operating systems, and programming languages of such computers are common in nature, and it is assumed that those skilled in the art are familiar enough with these techniques to be able to provide the information needed for on-demand services using the techniques described herein.
  • a computer containing user interface elements can be used as a personal computer (Personal Computer (PC)) or other type of workstation or terminal device, and can be used as a server after being properly programmed.
  • PC Personal Computer
  • Those skilled in the art will be recognized to be familiar with such structures, programs, and general operations of such computer devices, and thus all drawings do not require additional explanation.
  • Figure 29 depicts an architecture of a computer device that can be used to implement a particular system disclosed in this application.
  • the particular system in this embodiment utilizes a functional block diagram to explain a hardware platform that includes a user interface.
  • a computer can be a general purpose computer or a computer with a specific purpose.
  • Two computers Both can be used to implement the particular system in this embodiment.
  • Computer 2900 can be used to implement any unit of current order allocation.
  • order distribution system 110 can be implemented by a computer such as computer 2900 through its hardware devices, software programs, firmware, and combinations thereof.
  • Only one computer is depicted in FIG. 29, but the related computer functions described in this embodiment for providing the information required for on-demand services can be implemented in a distributed manner by a similar set of platforms. Dispose of the processing load of the system.
  • Computer 2900 includes a communication port 2950 to which is connected a network that implements data communication.
  • Computer 2900 also includes a central processing unit (CPU) unit for executing program instructions comprised of one or more processors.
  • An exemplary computer platform includes an internal communication bus 2910, different forms of program storage units and data storage units, such as a hard disk 2970, read only memory (ROM) 2930, random access memory (RAM) 2940, which can be used for computer processing and/or Or various data files used for communication, and possible program instructions executed by the CPU.
  • Computer 2900 also includes an input/output component 2960 that supports input/output data flow between the computer and other components (e.g., user interface 2980). The computer 2900 can also accept programs and data over a communication network.
  • Tangible, permanent storage media includes the memory or memory used by any computer, processor, or similar device or associated module. For example, various semiconductor memories, tape drives, disk drives, or the like that can provide storage functions for software at any time.
  • All software or parts of it may sometimes communicate over a network, such as the Internet or other communication networks.
  • Such communication can load software from one computer device or processor to another.
  • a system that loads from a management server or host computer of an on-demand service system to a computer environment, or other computer environment that implements the system, or a similar function associated with the information needed to provide on-demand services. Therefore, another medium capable of transmitting software elements can also be used as a physical connection between local devices, such as light waves, electric waves, electromagnetic waves, etc., through cables, fiber optic cables or air. broadcast. Physical media used for carrier waves such as cables, wireless connections, or fiber optic cables can also be considered as media for carrying software. Usage herein Unless the tangible "storage" medium is limited, other terms referring to a computer or machine "readable medium” mean a medium that participates in the execution of any instruction by the processor.
  • a computer readable medium can take many forms, including but not limited to tangible storage media, carrier media or physical transmission media.
  • Stable storage media include: optical or magnetic disks, as well as storage systems used in other computers or similar devices that enable the implementation of the system components described in the figures.
  • Unstable storage media include dynamic memory, such as the main memory of a computer platform.
  • Tangible transmission media include coaxial cables, copper cables, and fiber optics, including the circuitry that forms the bus within the computer system.
  • the carrier transmission medium can transmit electrical signals, electromagnetic signals, acoustic signals or optical signals, which can be generated by radio frequency or infrared data communication methods.
  • Typical computer readable media include hard disks, floppy disks, magnetic tape, any other magnetic media; CD-ROM, DVD, DVD-ROM, any other optical media; perforated cards, any other physical storage media containing aperture patterns; RAM, PROM , EPROM, FLASH-EPROM, any other memory slice or tape; a carrier, cable or carrier for transmitting data or instructions, any other program code and/or data that can be read by a computer. Many of these forms of computer readable media appear in the process of the processor executing instructions, passing one or more results.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • Human Resources & Organizations (AREA)
  • Tourism & Hospitality (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Development Economics (AREA)
  • Primary Health Care (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Game Theory and Decision Science (AREA)
  • Traffic Control Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • General Factory Administration (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种订单分配***及方法。该订单分配***包括一种计算机可读的存储媒介,被配置为存储可执行模块;以及一个处理器,被配置为能够执行所述计算机可读的存储媒介存储的可执行模块。计算机可读的存储媒介包括接收单元(231),被配置为接收订单信息与用户信息,该用户信息包括位置信息或时间信息;以及订单分配单元(361),被配置为基于该位置信息或时间信息,进行订单分配。该订单分配方法包括接收订单信息与用户信息,该订单信息与用户信息包括位置信息或时间信息;以及基于该位置信息或时间信息,进行订单分配。

Description

一种订单分配***及方法
交叉引用
本申请要求2015年1月29日提交的编号为201510046647.2的中国申请、2015年2月13日提交的编号为201510078862.0的中国申请、2015年4月8日提交的编号为201510163336.4的中国申请、2015年4月13日提交的编号为201510172959.8的中国申请、2015年7月28日提交的编号为201510451956.8的中国申请、2015年7月29日提交的编号为201510456730.7的中国申请、2015年8月20日提交的编号为201510516040.6的中国申请、2015年8月20日提交的编号为201510516346.1的中国申请以及2015年8月27日提交的编号为201510537192.4的中国申请的优先权,其内容以引用方式被包含于此。
技术领域
本申请涉及订单分配的***及方法,尤其是涉及应用移动互联网技术和数据处理技术的订单分配***及方法。
背景技术
随着城市的快速发展,打车需求已成为社会各阶层人士的普遍需求。同时,移动互联网的高速发展,以及智能设备特别智能导航与智能手机的普及,打车***平台的使用已经越来越普遍,对人们的出行带来了极大的便利。对于打车***平台的来说,如何将订单快速地、精准地分配给适当的用户,是具有挑战性的问题。
申请简述
根据本申请的一个方面,提供了一种订单分配***。该***可以包括:一种计算机可读的存储媒介,被配置为存储可执行模块,包括:接收单元,被配置为接收订单信息与用户信息,用户信息包括位置信 息或时间信息;订单分配单元,被配置为基于位置信息或时间信息,进行订单分配。一个处理器,处理器能够执行该计算机可读的存储媒介存储的可执行模块。
根据本申请的实施例,订单分配***可以进一步包括:播单范围确定模块,被配置为获取订单播送区域或订单接收范围;订单数目获取单元,被配置为获取播单范围内的订单数目;以及订单密度获取单元,被配置为基于订单播送区域或订单接收范围,以及订单数目,得到订单密度。
根据本申请的实施例,订单分配***可以进一步包括:抢单率预测单元,被配置为基于位置信息或时间信息,预测用户抢单率。
根据本申请的实施例,订单分配***可以进一步包括:距离确定单元,被配置为获取用户位置与订单出发地的距离或路面距离;以及抢单率预测单元,被配置为基于距离或路面距离,预测用户抢单率。
根据本申请的实施例,订单分配***可以进一步包括:获取单元,被配置为获取订单的历史播单时间或用户的历史抢单时间;以及订阅概率计算单元,被配置为基于历史播单时间或历史抢单时间,预测用户抢单率。
根据本申请的实施例,抢单率预测单元可以进一步被配置为基于位置信息或时间信息,建立用户抢单率预测模型。
根据本申请的实施例,订单分配***可以进一步包括:准确度确定单元,被配置为确定抢单率预测的准确度。
根据本申请的实施例,订单分配***可以进一步包括:实际抢单率确定单元,被配置为确定用户针对该订单实际的抢单率;以及准确度确定单元,被配置为基于用户的预测抢单率与实际抢单率,确定抢单率预测的准确度。
根据本申请的一个方面,提供了一种订单分配方法。该方法可以包括接收订单信息与用户信息,订单信息与用户信息包括位置信息或时间信息;以及基于位置信息或时间信息,进行订单分配。
根据本申请的另一个方面,提供了一种有形的非暂时性计算机可读 媒介,该媒介上可以存储信息。当该信息被计算机读取时,该计算机即可执行订单分配方法。订单分配方法。该方法可以包括接收订单信息与用户信息,订单信息与用户信息包括位置信息或时间信息;以及基于位置信息或时间信息,进行订单分配。
根据本申请的实施例,位置信息可以为出发地、始发地、目的地、坐标信息、地域范围中的一种或几种。
根据本申请的实施例,时间信息可以为订单播单时间、用户抢单时间中的一种或两种。
根据本申请的实施例,基于位置信息进行订单分配可以进一步包括:获取订单播送区域或订单接收范围,以及订单数目;基于订单播送区域或订单接收范围,以及订单数目,得到订单密度;以及基于订单密度,进行订单分配。
根据本申请的实施例,基于位置信息或时间信息进行订单分配可以进一步包括:基于位置信息或时间信息,预测用户抢单率;以及基于用户抢单率,进行订单分配。
根据本申请的实施例,根据位置信息预测用户抢单率可以进一步包括:获取用户位置与订单出发地的距离或路面距离;以及基于距离或路面距离,预测用户抢单率。
根据本申请的实施例,根据时间信息预测用户抢单率可以进一步包括:获取订单的历史播单时间或用户的历史抢单时间;以及基于历史播单时间或历史抢单时间,预测用户抢单率。
根据本申请的实施例,预测用户抢单率可以进一步包括:获取订单的位置信息或时间信息;基于位置信息或时间信息,建立用户抢单率预测模型;以及基于用户抢单率预测模型,预测用户抢单率。
根据本申请的实施例,预测用户抢单率可以进一步包括确定用户抢单率预测的准确度。
根据本申请的实施例,确定用户抢单率预测准确度可以进一步包括:获取用户针对订单的预测抢单率;确定用户针对该订单实际的抢单率;以及基于用户的预测抢单率与实际抢单率,确定抢单率预测的 准确度。
附图描述
在此所述的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的限定。各图中相同的标号表示相同的部件。
图1是根据本申请一些实施例所示的包含基于位置服务***的网络环境的示意图;
图2是根据本申请一些实施例所示的订单分配***110的一种示意图;
图3是根据本申请一些实施例所示的订单分配***110的一种示意图;
图4是根据本申请一些实施例所示的订单分配方法的一种示例性流程图;
图5是根据本申请一些实施例所示的订单分配***110的一种示意图;
图6是根据本申请一些实施例所示的订单分配方法的一种示例性流程图;
图7是根据本申请一些实施例所示的订单分配***110的一种示意图;
图8是根据本申请一些实施例所示的订单分配方法的一种示例性流程图;
图9是根据本申请一些实施例所示的订单分配方法的一种示例性流程图;
图10是根据本申请一些实施例所示的订单分配***110的一种示意图;
图11是根据本申请一些实施例所示的订单分配***110的一种示意图;
图12是根据本申请一些实施例所示的订单分配方法的一种示例 性流程图;
图13是根据本申请一些实施例所示的订单分配方法的一种示例性流程图;
图14是根据本申请一些实施例所示的订单分配***110的一种示意图;
图15是根据本申请一些实施例所示的订单分配方法的一种示例性流程图;
图16是根据本申请一些实施例所示的订单分配***110的一种示意图;
图17是根据本申请一些实施例所示的订单分配方法的一种示例性流程图;
图18是根据本申请一些实施例所示的订单分配***110的一种示意图;
图19是根据本申请一些实施例所示的订单分配方法的一种示例性流程图;
图20是根据本申请一些实施例所示的订单分配方法的一种示例性流程图;
图21A是根据本申请一些实施例所示的订单分配方法的一种示例性示意图;
图21B根据本申请一些实施例所示的抢单时间分布的一种示例性示意图;
图22是根据本申请一些实施例所示的订单分配***110的一种示意图;
图23是根据本申请一些实施例所示的订单分配方法的一种示例性流程图;
图24是根据本申请一些实施例所示的订单分配方法的一种示例性流程图;
图25是根据本申请一些实施例所示的订单分配***110的一种示意图;
图26是根据本申请一些实施例所示的订单分配方法的一种示例性流程图;
图27是根据本申请一些实施例所示的订单分配方法的一种示例性流程图;
图28显示的是一个移动设备的结构示意图,该移动设备可以实施本申请中披露的特定***;和
图29显示的是一个计算机的结构示意图,该计算机可以实施本申请中披露的特定***。
具体描述
为了更清楚地说明本申请的实施例的技术方案,下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地,下面描述中的附图仅仅是本申请的一些示例或实施例,对于本领域的普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图将本申请应用于其他类似情景。除非从语言环境中显而易见或另做说明,图中相同标号代表相同结构或操作。
如本申请和权利要求书中所示,除非上下文明确提示例外情形,“一”、“一个”、“一种”和/或“该”等词并非特指单数,也可包括复数。一般说来,术语“包括”与“包含”仅提示包括已明确标识的步骤和元素,而这些步骤和元素不构成一个排他性的罗列,方法或者设备也可能包含其他的步骤或元素。
如本申请和权利要求书中所示,除非上下文明确指示例外情形,“抢单率”、“抢单概率”、“用户(的)抢单率”、“用户终端的抢单概率”、“订单抢单率”“订单抢单概率”和/或“订阅概率”等词汇都可以指用户针对订单执行抢单操作的概率。
如本申请所示,实施例和/或附图中的大写与小写英文字母(例如,A,D,M,N,P,R,n,t等)仅仅为方便描述申请而设定的代号。对于同一种代号,在不同的实施例和/或附图中,它可以具备相同或不同的含义,可以根据实际场景而定。如本申请所示,实施例和/或附图 中的“播送”、“发送”和/或“推送”等词汇都可以指***向用户传输信息。
虽然本申请对根据本申请的实施例的***中的某些模块做出了各种引用,然而,任何数量的不同模块可以被使用并运行在客户端和/或服务器上。所述模块仅是说明性的,并且所述***和方法的不同方面可以使用不同模块。
本申请中使用了流程图用来说明根据本申请的实施例的***所执行的操作。应当理解的是,前面或下面的操作不一定按照顺序来精确地执行。相反,可以按照倒序和/或同时处理各种步骤。同时,也可以将其他操作添加到这些过程中,或从这些过程移除某一步或数步操作。
本申请的实施例可以应用于不同的运输***,该不同的运输***包括但不限于陆地、海洋、航空、航天等中的一种或几种的组合。例如出租车、专车、顺风车、巴士、火车、动车、高铁、地铁、船舶、飞机、飞船、热气球、无人驾驶的交通工具、收/送快递等应用了管理和/或分配的运输***。本申请的不同实施例应用场景包括但不限于网页、浏览器插件、客户端、定制***、企业内部分析***、人工智能机器人等中的一种或几种的组合。应当理解的是,本申请的***及方法的应用场景仅仅是本申请的一些示例或实施例,对于本领域的普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图将本申请应用于其他类似情景。例如,其他类似的订单分配***。
本申请描述的“乘客”、“订单请求者(方)”、“顾客”、“需求者”、“服务需求者”、“消费者”、“消费方”、“使用需求者”等是可以互换的,是指需要或者订购服务的一方,可以是个人、实体或工具等。同样地,本申请描述的“司机”、“订单接收者(方)”、“提供者”、“供应者”、“服务提供者”、“服务者”、“服务方”等也是可以互换的,是指提供服务或者协助提供服务的个人、工具或者其他实体等。另外,本申请描述的“用户”、“终端”和/或“用户终端”可以是需要或者订购服务的一方,也可以是提供服务或者协助提供服务的一方。
根据本申请的一些实施例,图1所示的是根据本申请的一些实施例所示的包含基于位置的服务***的网络环境的示意图。基于位置的服务***100可以包括一个或多个按需服务***105、一个或多个乘客端120、一个或多个数据库130、一个或多个司机端140、一个或多个网络150、一个或多个其他信息源160。在一些实施例中,按需服务***105可以包含一个订单分配***110。在一些实施例中,订单分配***110可以用于对收集的信息进行分析加工以生成分析结果的***。订单分配***110可以是一个服务器,可以是服务器的一部分,也可以是一个服务器群组。一个服务器群组可以是集中式的,例如数据中心。一个服务器群组也可以是分布式的,例如一个分布式***。订单分配***110可以是本地的,也可以是远程的。在一些实施例中,订单分配***110可以通过网络150或其他通信方式访问存取用户120/140的信息、其他信息源160中的信息和/或数据库130中的信息。
乘客端120和司机端140可以统称为用户、用户终端或终端,它可以是服务订单通过各种形式形成的个人、工具或者其他实体,例如服务订单的请求者与提供服务者。乘客可以是服务需求方。在本文中,“乘客”、“乘客端”和“乘客端设备”可以互换使用。乘客还可以包括乘客端设备120的使用者。在一些实施例中,该使用者可以不是乘客本人。例如,乘客端设备120的使用者A可以使用乘客端设备120为乘客B请求按需服务,或接受按需服务或按需服务***105发送的其他信息或指令。为简便起见,在本文中该乘客端设备120的使用者也可以简称为乘客。司机可以是服务提供方。在本文中,“司机”、“司机端”和“司机端设备”可以互换使用。司机还可以包括司机端设备140的使用者。在一些实施例中,该使用者可以不是司机本人。例如,司机端设备140的使用者C可以使用司机端设备140为司机D接受按需服务或按需服务***105发送的其他信息或指令。为简便起见,在本文中该司机端设备120的使用者也可以简称为司机。在用户为工具的实施例中,乘客端120可以包括但不限于台式电脑120-1、笔记本电脑120-2、机动车的内置设备120-3、移动设备120-4等中的一种或 几种的组合。进一步地,机动车的内置设备120-3,可以为车载电脑(carputer)等。在一些实施例中,这些用户还可以是一些其他智能终端,包括但不限于智能家居设备、可穿戴设备、智能移动设备或其他智能设备。对于智能家居设备,可以包括但不限于智能照明设备、智能电器控制设备、智能监控设备、智能电视、智能摄像机、智能电话、对讲机等中的一种或几种的组合;对于可穿戴设备,可以包括但不限于智能手环、智能手表、智能鞋袜、智能眼镜、智能头盔、智能头带、智能服装、智能背包、智能配饰等中的一种或几种的组合;对于智能移动设备,可以包括但不限于交通工具内置设备(车载电脑或车载电视等)、游戏设备、GPS设备、POS机等中的一种或几种的组合。司机端140也可以包括类似的设备中的一种或多种。
在一些实施例中,数据库130可以泛指具有存储功能的设备。数据库130主要用于存储从用户120/140收集的数据和订单分配***110工作中产生的各种数据。数据库130或***内的其他存储设备泛指所有可以具有读/写功能的媒介。数据库130或***内其他存储设备可以是***内部的,也可以是***的外接设备。数据库130可以是本地的,也可以是远程的。数据库130可以包括但不限于层次式数据库、网络式数据库和关系式数据库等其中的一种或几种的组合。数据库130可以将信息数字化后再以利用电、磁或光学等方式的存储设备加以存储。数据库130可以用来存放各种信息例如***、软件、程序、信息和数据等。数据库130可以是利用电能方式存储信息的设备,例如各种存储器、随机存取存储器(Random Access Memory(RAM))、只读存储器(Read Only Memory(ROM))等。其中随机存储器包括但不限于十进计数管、选数管、延迟线存储器、威廉姆斯管、动态随机存储器(DRAM)、静态随机存储器(SRAM)、晶闸管随机存储器(T-RAM)、零电容随机存储器(Z-RAM)等中的一种或几种的组合。只读存储器包括但不限于磁泡存储器、磁钮线存储器、薄膜存储器、磁镀线存储器、磁芯内存、磁鼓存储器、光盘驱动器、硬盘、磁带、早期非易失存储器(NVRAM)、相变化内存、磁阻式随机存储式内存、 铁电随机存储内存、非易失SRAM、闪存、电子抹除式可复写只读存储器、可擦除可编程只读存储器、可编程只读存储器、屏蔽式堆读内存、浮动连接门随机存取存储器、纳米随机存储器、赛道内存、可变电阻式内存、可编程金属化单元等中的一种或几种的组合。数据库130可以是利用磁能方式存储信息的设备,例如硬盘、软盘、磁带、磁芯存储器、磁泡存储器、U盘、闪存等。数据库130可以是利用光学方式存储信息的设备,例如CD或DVD等。数据库130可以是利用磁光方式存储信息的设备,例如磁光盘等。数据库130的存取方式可以是随机存储、串行访问存储、只读存储等中的一种或几种的组合。数据库130可以是非永久记忆存储器,也可以是永久记忆存储器。以上提及的存储设备只是列举了一些例子,该***可以使用的存储设备并不局限于此。
数据库130可以与网络150相互连接或通信,也可以直接与按需服务***105或其一部分(例如,订单分配***110)相互连接或通信,也可以是两种方式的结合。在一些实施例中,数据库130可以设置在按需服务***105的后台。在一些实施例中,数据库130可以是独立的,直接与网络150相连接。数据库130与***其他模块间的连接或通信可以是有线的,也可以是无线的。网络150可以提供信息交换的渠道。当数据库130与网络150相互连接或通信时,用户120/140可以通过网络150访问数据库130中的信息。各方对数据库130的访问权限可以是有限制的。例如,按需服务***105,或其一部分(例如,订单处理引擎110),对数据库130有最高的访问权限,可以从数据库130中读取或修改大众的或个人的信息;乘客端设备120或司机端设备140在满足一定条件时可以读取部分大众的信息或与用户相关的个人信息。例如,按需服务***105可以根据一位用户(乘客或司机)的一次或多次使用按需服务***105的经历更新/修改数据库130中大众的或与该位用户相关的信息。又例如,一位司机在收到一位乘客的服务订单时,可以查看数据库130中关于该乘客的部分信息;但该司机不可以自主修改数据库130中关于该乘客的信息,而只能向按 需服务***105汇报,由按需服务***105决定是否修改数据库130中关于该乘客的信息。再例如,一位乘客,在收到一位司机的提供服务的请求时,可以查看数据库130中关于该司机的部分信息(如用户评分信息,驾驶经验等);但该乘客不可以自主修改数据库130中关于该司机的信息,而只能向按需服务***105汇报,由按需服务***105决定是否修改数据库130中关于该司机的信息。
网络150可以是单一网络,也可以是多种网络的组合。网络150可以包括但不限于局域网、广域网、公用网络、专用网络、无线局域网、虚拟网络、都市城域网、公用开关电话网络等中的一种或几种的组合。网络150可以包括多种网络接入点,例如有线或无线接入点、基站或网络交换点,通过以上接入点使数据源连接网络150并通过网络发送信息。
其他信息源160是为***提供其他信息的一个源。其他信息源160可以用于为***提供与服务相关的信息,例如,天气情况、交通信息、法律法规信息、新闻事件、生活资讯、生活指南信息等。其他信息源160可以是以一个单独的中央服务器的形式存在,也可以是以多个通过网络连接的服务器形式存在,还可以是以大量的个人设备形式存在。当信息源以大量个人设备形式存在时,这些设备可以通过一种用户生成内容(user-generated contents)的方式,例如向云端服务器上传文字、声音、图像、视频等,从而使云端服务器连同与其连接的众多个人设备一起组成信息源。其他信息源160可以与网络150相互连接或通信,也可以直接与按需服务***105或其一部分(例如,订单分配***110)相互连接或通信,也可以是两种方式的结合。当其他信息源160与网络150相互连接或通信时,用户120/140可以通过网络150访问其他信息源160中的信息。其他信息源160与***其他模块间的连接或通信可以是有线的,也可以是无线的。
以交通服务为例,其他信息源160可以是包含有地图信息与城市服务信息的市政服务***、交通实时播报***、天气播报***、新闻网络等。其他信息源160可以是实物信息源,例如常见的测速设备、 传感、物联网设备,例如司机的车载测速仪、车载诊断***、道路上的雷达测速仪、温湿度传感器等。其他信息源160也可以是获取新闻、资讯、道路实时信息等的源,例如一个网络信息源,包括但不限于基于Usenet的互联网新闻组、Internet上的服务器、天气信息服务器、道路状况信息服务器等。具体的,对于送餐服务,其他信息源160可以是存储有某一地域众多餐饮服务商的***、包含有地图信息与城市服务信息的市政服务***、交通路况***、天气播报***、新闻网络等。上述举例并非用于局限此处的其他信息源的范围,也并非局限于所举实例这几类服务范围,本申请可以适用于各种服务任何能够提供与相应服务有关的信息的设备、网络,都可以被归为其他信息源。
基于位置的服务***100,在一些实施例中,该***内不同部分之间的信息交流可以通过订单方式进行。订单的客体可以是任一产品。在一些实施例中,产品可以是有形产品或无形产品。对于实物产品,它可以是任何有形状大小或的实物,例如食品、药品、日用品、化工产品、电器、衣物、汽车、房产、奢侈品等中的一种或几种的组合。对于无形产品,包括但不限于服务性产品、金融性产品、知识性产品、互联网产品等中的一种或几种的组合。对于互联网产品,它可以是任一满足用户对信息、娱乐、沟通或商务需要的产品。互联网产品有很多分类方法,以其承载平台分类为例,包括但不限于个人主机产品、Web产品、移动互联网产品、商用主机平台产品、嵌入式产品等中的一种或几种的组合。其中的移动互联网产品可以是用在移动终端的软件、程序或***。其中的移动终端包括但不限于笔记本、平板电脑、手机、个人数码助理(PDA)、电子手表、POS机、车载电脑、电视机等中的一种或几种的组合。例如,在电脑或手机上使用的各类社交、购物、出行、娱乐、学习、投资等软件。其中的出行软件又可以是旅行软件、交通工具预定软件、地图软件等。其中的交通预定软件是指可以用来预约汽车(例如出租车、公交车等)、火车、地铁、船只(轮船等)、飞行器(飞机、航天飞机、火箭)、热气球等中的一种或几种的组合。
需要注意的是,以上对于基于位置的服务***100的描述,仅为描述方便,并不能把本申请限制在所举实施例范围之内。可以理解,对于本领域的技术人员来说,在了解该***的原理后,可能在不背离这一原理的情况下,对各个模块进行任意组合,或者构成子***与其他模块连接,对实施上述方法和***的应用领域形式和细节上的各种修正和改变。例如,数据库130可以是具有数据存储功能的云计算平台,包括但不限于公用云、私有云、社区云和混合云等。诸如此类的变形,均在本申请的保护范围之内。
根据本申请的一些实施例,图2所示的是订单分配***110的一种示意图。为描述方便,该订单分配***以按需服务***105中的订单分配***110为例来说明。为描述方便,该订单分配***110以叫车服务***为例来说明。订单分配***110可以包括一个或多个处理模块210、一个或多个存储模块220、一个或多个乘客接口230、一个或多个司机接口240。订单分配***110的模块可以是集中式的也可以是分布式的。订单分配***110的模块中的一个或多个模块可以是本地的也可以是远程的。在一些实施例中,订单分配***110可以是网页服务器、文件服务器、数据库服务器、FTP服务器、应用程序服务器、代理服务器、邮件服务器等中的一种或几种的组合。
在一些实施例中,处理模块210可以用于相关信息的处理。处理模块可以从乘客接口230、司机接口240、存储模块220、数据库130、其他信息源160等获取信息。处理模块210可以将处理后的信息发送至乘客接口230和/或司机接口240,可以将处理后的信息保存至数据库130或存储模块220或其他备份的数据库或存储设备。信息处理的方式可以包括但不限于对信息进行存储、分类、筛选、转换、计算、检索、预测、训练等中的一种或几种的组合。在一些实施例中,处理模块210可以包括但不限于中央处理器(Central Processing Unit(CPU))、专门应用集成电路(Application Specific Integrated Circuit(ASIC))、专用指令处理器(Application Specific Instruction Set Processor(ASIP))、物理处理器(Physics Processing Unit(PPU))、 数字信号处理器(Digital Processing Processor(DSP))、现场可编程逻辑门阵列(Field-Programmable Gate Array(FPGA))、可编程逻辑器件(Programmable Logic Device(PLD))、处理器、微处理器、控制器、微控制器等中的一种或几种的组合。
需要注意的是,上述处理模块210或数据库130可以实际存在于***中,也可以通过云计算平台完成相应功能。其中,云计算平台包括但不限于存储数据为主的存储型云平台、以处理数据为主的计算型云平台以及兼顾数据存储和处理的综合云计算平台。***所使用的云平台可以是公共云、私有云、社区云或混合云等。例如,根据实际需要,***接收的一些订单信息和/或非订单信息,可以通过云平台进行计算和/或存储。另一些订单信息和/或非订单信息,可以通过本地处理模块和/或***数据库进行计算和/或存储。在一些实施例中,乘客接口230与司机接口240可以用于分别从乘客120与司机140接收各自发送的信息。此处的信息,可以包括但不限于服务的请求信息、服务的接收信息、用户的习惯/喜好信息、用户定位信息等中的一种或几种的组合。其中,服务的请求信息可以是用户的订单请求信息(例如,乘客的打车请求、司机的接单请求等)、用户的其他请求信息(例如,司机向***发送获取某一区域的订单密度的请求)等。服务的接收信息可以是用户同意接单的信息、用户放弃接单的信息、用户接单成功的信息、用户接单失败的信息等。用户的习惯/喜好信息可以是乘客对于司机的偏好、乘客可以接收的等待时间、乘客对于拼车乘客的偏好、乘客对于车型的偏好、司机对于出发地、目的地、出发时间的偏好等。信息的形式可以包括但不限于文本、音频、视频、图片等中的一种或几种的组合。信息的输入方式可以是手写输入、手势输入、图像输入、语音输入、视频输入、电磁波输入或者其他数据输入方式,或者以上的任意组合。所接收的信息,可以被存储于数据库130中,可以被存储于存储模块220中,可以由处理模块210进行计算与处理,也可以是以上几种方式的组合。
在一些实施例中,用户定位信息的获取,可以由定位***完成。 例如,可以通过一种或多种定位技术获取用户的当前位置、始发地、运动状态、运动速度等信息。该定位技术可以包括但不限于全球定位***(GPS)技术、全球导航卫星***(GLONASS)技术、北斗导航***技术、伽利略定位***(Galileo)技术、准天顶卫星***(QAZZ)技术、基站定位技术、Wi-Fi定位技术、交通工具自带的各种定位测速***等。
在一些实施例中,乘客接口230与司机接口240可以用于输出经过处理模块210分析处理后的信息。此处的信息,可以是优化后的定位信息、订单的直接信息、订单的处理信息、用户的直接信息、用户的处理信息等。信息的形式可以包括但不限于文本、音频、视频、图片等中的一种或几种的组合。输出的信息可以发送给乘客120和/或司机140,也可以不发送。不发送的输出信息可以存储在数据库130中,也可以存储在存储模块220中。
应当理解,图2所示的***可以利用各种方式来实现。例如,在一些实施例中,***可以通过硬件、软件或者软件和硬件的结合来实现。其中,硬件部分可以利用专用逻辑来实现;软件部分则可以存储在存储器中,由适当的指令执行***,例如微处理器或者专用设计硬件来执行。本领域技术人员可以理解上述的方法和***可以使用计算机可执行指令和/或包含在处理器控制代码中来实现,例如在诸如磁盘、CD或DVD-ROM的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本申请的***及其模块不仅可以有诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现,也可以用例如由各种类型的处理器所执行的软件实现,还可以由上述硬件电路和软件的结合(例如,固件)来实现。
可以理解,图2所示的***不仅限于叫车服务***,也可以应用在其他交通服务***中,还可以应用在其他服务***中,例如,订餐服务***、上门服务***、预约服务***等。本申请对此并不加以限 制。
需要注意的是,以上对于订单分配***110的描述,仅为描述方便,并不能把本申请限制在所举实施例范围之内。可以理解,对于本领域的技术人员来说,在了解该***的原理后,可能在不背离这一原理的情况下,对各个模块进行任意组合,或者构成子***与其他模块连接。例如,在一些实施例中,处理模块210、存储模块220、乘客接口230、司机接口240可以是体现在一个***中的不同模块,也可以是一个模块实现上述的两个或两个以上模块的功能。例如,乘客接口230/司机接口240可以是一个模块同时具有输入输出的功能,也可以是针对乘客/司机的输入模块和输出模块。例如,处理模块210和存储模块220可以是两个模块,也可以是一个模块同时具有处理和存储功能。例如,各个模块可以共用一个存储模块,各个模块也可以分别具有各自的存储模块。诸如此类的变形,均在本申请的保护范围之内。
根据本申请的一些实施例,图3为订单分配***110的一种示意图。据图所示,订单分配***110可以包括一个或多个接口模块230/240和一个或多个处理模块210。其中,接口模块230/240可以用于信息交互,可以包括一个或多个乘客接口230和/或一个或多个司机接口240,参见图2。在一些实施例中,接口模块230/240可以进一步包括一个或多个接收单元231和一个或多个发送单元232。其中,接收单元231可以用于接收来自乘客120与司机140的信息,具体参见图2的描述。发送单元232可以用于输出经处理模块210分析处理后的信息,具体可以参见相关图中的描述。
在一些实施例中,处理模块210可以进一步包括一个或多个订单预处理模块310、一个或多个用户预处理模块320、一个或多个确定模块330、一个或多个预测模块340、一个或多个分析模块350和一个或多个决策模块360。其中,订单预处理模块310可以用于预处理订单信息。订单预处理模块310可以进一步包括一个或多个订单生成单元311、一个或多个订单筛选单元312、和一个或多个订单信息获取单元313。用户预处理模块320可以用于预处理用户信息。用户预 处理模块320可以进一步包括一个或多个用户终端判断单元321、一个或多个用户终端检测单元322、一个或多个用户终端筛选单元323、和一个或多个用户信息获取单元324。其中,订单信息获取单元313和用户信息获取单元324可以统称为获取单元(图中未画出)。确定模块330可以用于确定一些与位置相关的信息。确定模块330可以进一步包括一个或多个播单半径确定单元331、一个或多个订单接收范围确定单元332、一个或多个顺路等级确定单元333、和一个或多个距离确定单元334。预测模块340可以用于预测用户的抢单意愿。预测模块340可以进一步包括一个或多个订阅概率计算单元和一个或多个抢单率预测单元342。分析模块350可以用于根据确定模块330和/或预测模块340所确定的订单特征进行分析判断。分析模块350可以进一步包括一个或多个比较单元351和一个或多个判断单元352。决策模块360可以用于基于分析模块350的输出结果进行订单分配或其他处理。决策模块360可以进一步包括一个或多个订单分配单元361和一个或多个调整单元362。
对于图3中订单分配***110的实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处可以参见方法实施例的部分说明即可。
根据本申请的一些实施例,图4为订单分配的一种示例性流程图。为描述方便,该订单分配***110以叫车服务***为例来说明。在一些实施例中,该订单分配流程可以由按需服务***105或其一部分(例如,订单分配***110)执行。根据图4所示,订单信息可以在步骤410通过接口模块230/240从用户120/140(详见图1)中被接收。在一些实施例中,在步骤310,也可以接收数据库130和/或其他信息源160(详见图1)的信息。以出租车服务订单为例,订单信息的内容可以包括但不限于订单本身信息、用户信息和其他信息等。订单本身信息可以包括但不限于订单编号、出发地(或始发地)、目的地、出发时间、到达时间、愿意等待的时间、乘客人数、有无行李、里程、价格、消费方加价、服务方调价、***调价、红包使用情况、付款方式 (例如现金支付、刷卡支付、网上支付、汇款支付等)、订单完成情况、服务方选择订单情况、消费方发送订单情况等,或者上述信息的任意组合。用户信息是指用户120/140的相关信息。用户信息可以包括但不限于姓名、昵称、性别、国籍、年龄、联系方式(电话号码、手机号码、社交账号信息(例如微信号码、QQ号码和Linkedin等)等可以联系到本人的方式等)、职业、评价等级、使用时间、驾龄、车龄、车型、车况、车牌号、驾驶证号、认证情况、用户习惯/喜好、额外服务能力(例如车的后备箱大小、全景天窗等额外特性)等中的一种或几种的组合。其他信息可以指不受消费方、服务方控制的信息,或者是指暂时性/突发性的信息。例如,其他信息可以包括但不限于天气情况、环境情况、道路状况(例如因安全性或者道路作业等原因封闭道路)、交通条件等,或者上述信息的任意组合。
在一些实施例中,订单信息的部分内容可以是实时订单信息,也可以是历史订单信息。其中,实时订单信息可以是在某个时刻或在某个时间段的订单信息。其中,时间段可以是几秒、几分、几小时或者根据喜好自定义的时间段;时段也可以是特定的时间,例如工作日、休息日、节假日、高峰时段、非高峰时段等。历史订单信息可以包括过去的相关信息,例如,请求订单量、接受订单量、成交量、抢单(概)率、抢单成功率、毁约率、爽约率、成交率、用户习惯/喜好等中的一种或几种的组合。
在步骤420,可以由处理模块210基于接收的订单信息处理其订单特征。上述订单特征可以包括订单的直接信息和处理后的信息等。其中,订单的直接信息可以是订单本身信息、用户信息、其他信息等中的一种或几种的组合,具体可以参考本申请的相关描述。订单处理后的信息可以经由一定的数据处理方式得到,它包括但不限于用户的抢单时间、抢单率、抢单成功率、毁约率、爽约率、成交率、订单的密度、订单的竞争概率、订单的缓冲时间、订单的播报时间、用户接受的播单范围、顺路等级、路面距离、用户距出发地的距离、预测订单抢单概率的准确度等中的一种或几种的组合。其中,信息的处理方 式包括但不限于对信息进行存储、分类、筛选、转换、计算、检索、预测、训练等中的一种或几种的组合。
为描述方便,以下对订单信息处理中一些实施例用到的预测模型和机器学***均平滑法、趋势外推法、季节变动预测法和马尔可夫时序预测法等中的一种或几种的组合。因果分析法进一步可以包括一元回归法、多元回归法和投入产出法。在一些实施例中,预测模型可以包括但不限于加权算术平均模型、趋势平均预测模型、指数平滑模型、平均发展速度模型、一元线性回归模型、高低点模型中的一种或几种的组合。另外在一些实施例中,对于信息处理所用到的公式、算法和/或模型,可以通过机器学***滑估计(Locally Estimated Scatterplot Smoothing);对于基于实例的模型,可以是k-最近邻法(k-Nearest Neighbor)、学习矢量量化(Learning Vector Quantization)或者自组织映射算法(Self-Organizing Map)等;对于正规化算法模型,可以是RIDge Regression、Least Absolute Shrinkage and Selection Operator(LASSO)或者弹性网络(Elastic Net);对于决策树模型,可以是分类及回归树(Classification And Regression Tree)、ID3(Iterative Dichotomiser 3)、C4.5、Chi-squared Automatic Interaction Detection(CHAID)、Decision Stump、随机森林(Random Forest)、多元自适应回归样条(MARS) 或梯度推进机(Gradient Boosting Machine(GBM))等;对于贝叶斯模型,可以是朴素贝叶斯算法、平均单依赖估计(Averaged One-Dependence Estimators)或Bayesian Belief Network(BBN)等;对于基于核的算法模型,可以是支持向量机(Support Vector Machine)、径向基函数(Radial Basis Function)或线性判别分析(Linear Discriminate Analysis)等;对于聚类算法模型,可以是k-Means算法或期望最大化算法(Expectation Maximization)等;对于关联规则模型,可以是Apriori算法或Eclat算法等;对于神经网络模型,可以是感知器神经网络(Perceptron Neural Network)、反向传递(Back Propagation)、Hopfield网络、自组织映射(Self-Organizing Map)或学习矢量量化(Learning Vector Quantization)等;对于深度学习模型,可以是受限波尔兹曼机(Restricted Boltzmann Machine)、Deep Belief Networks(DBN)、卷积网络(Convolutional Network)或堆栈式自动编码器(Stacked Auto-encoders)等;对于降低维度算法模型,可以是主成份分析(Principle Component Analysis)、偏最小二乘回归(Partial Least Square Regression)、Sammon映射、多维尺度(Multi-Dimensional Scaling)或投影追踪(Projection Pursuit)等。
在步骤430,基于上述订单特征,分配订单。在一些实施例中,订单分配***110可以通过接口模块230/240发送信息给一个或多个司机端设备140,一个或多个乘客端设备120,一个或多个第三方平台等。发送的信息可以包括但不限于订单的直接信息和/或处理信息。订单的直接信息可以包括但不限于订单本身信息、用户信息和/或其他信息。订单的处理信息包括但不限于用户的抢单时间、抢单率、抢单成功率、毁约率、爽约率、成交率、订单的密度、订单的竞争概率、订单的缓冲时间、订单的播报时间、用户接受的播单范围、顺路等级、路面距离、用户距出发地的距离、预测订单抢单概率的准确度等中的一种或几种的组合。发送的订单信息的形式可以包括但不限于文字、图片、音频、视频等中的一种或几种的组合。
可以理解,图4所示的订单分配流程不仅限于叫车服务***,也 可以应用在其他交通服务***中,还可以应用在其他服务***中,例如,订餐服务***、上门服务***、预约服务***等。本申请对此并不加以限制。
需要注意的是,以上关于订单分配流程的描述,仅为理解申请方便,并不能把本申请限制在所举实施例范围之内。可以理解,对于本领域的技术人员来说,在了解本申请的基本原理后,可以在不背离这一原理的情况下,对订单分配流程作出改变。例如,可以增加或减少一些步骤。例如,在步骤410之后可以对订单信息进行预处理。预处理过程可以通过数据清理、数据集成、数据变换和/或数据规约等方法去除一些失真的数据。在一些实施例中,具体的失真数据去除方法可以包括但不限于判别法、剔除法、平均值法、拉平法、比例法、移动平均法、指数平滑法、差分法等中的一种或几种的组合。例如,在一些实施例中,针对特定订单特征,可以不断调整或优化。再例如,在订单分配流程中,还可以添加数据存储的步骤。诸如此类的变形,均在本申请的保护范围之内。
根据本申请的一些实施例,图5为订单分配***110的一种示意图。据图所示,该订单分配***110可以包括一个或多个订单生成单元311、一个或多个判断单元352、和一个或多个发送单元232。在一些实施例中,发送单元232可以进一步包括一个或多个派单模式用户发送子单元510、一个或多个抢单模式用户发送子单元520和一个或多个其他派单模式用户发送子单元530。
在一些实施例中,订单生成单元311可以用于在订单请求方的打车请求时,根据该打车请求生成订单。
在一些实施例中,判断单元352判断与该订单的出发地的距离小于第一预设阈值的范围内是否存在派单模式的用户。
在一些实施例中,派单模式用户发送子单元510可以用于当第一预设阈值内存在派单模式的终端时,向满足条件的派单模式用户发送该订单。
在一些实施例中,抢单模式用户发送子单元520可以用于当第一 预设阈值内不存在派单模式的用户时,获取与该订单的出发地的距离小于第二预设阈值的抢单模式的用户,并向满足条件的抢单模式用户发送该订单。在一些实施例中,第一预设阈值可以小于第二预设阈值。
在一些实施例中,派单模式用户发送子单元510,可以进一步用于当第一预设阈值内存在多个派单模式的用户时,可以从多个派单模式的用户中筛选出符合预设的匹配条件的一个用户,并向该用户发送该订单。在一些实施例中,该预设的匹配条件可以包括与该订单的出发地的距离最近、达到该订单的出发地的时间最短、路面拥堵时间最短、用户信用/评分最高、用户抢单次数最多、用户忠诚度最高等中的一种或几种的组合。
在一些实施例中,该订单分配***110还可以包括其他派单模式用户发送子单元530,可以用于间隔第一预设时间段,根据上述预设的匹配条件将该订单依次发送给其他派单模式的用户。其中,该其他派单模式的用户可以为上述多个派单模式的用户中除上述筛选出的用户之外的用户。
在一些实施例中,该订单分配***110还可以包括一个或多个用户终端检测单元322,可以用于在任一用户接单之前,每隔第二预设时间段检测与该订单的出发地的距离小于第一预设阈值内是否存在派单模式的用户。
在一些实施例中,该订单分配***110还可以包括一个或多个订单分配单元361,可以用于当派单模式的用户接单时,将该订单分配给该派单模式的用户,并停止发送该订单。当抢单模式的用户抢单时,可以等待第三预设时间段,并判断该第三预设时间段内是否有派单模式的用户接单;若该第三预设时间段内有派单模式的用户接单,则将该订单分配给该派单模式的用户;若该第三预设时间段内没有派单模式的用户接单,则将该订单分配给该抢单模式的用户。
在一些实施例中,该订单分配单元361还可以进一步用于当同时有多个抢单模式的用户抢单时,从该多个抢单模式的用户中筛选出符合预设的匹配条件的一个用户,并将该订单分配给该用户。
对于订单分配***110的实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处可以参见方法实施例(即图6)的部分说明即可。需要注意的是,以上对于订单分配***110的描述,仅为理解申请方便,并不能把本申请限制在所举实施例范围之内。可以理解,对于本领域的技术人员来说,在了解该***的原理后,可以在不背离这一原理的情况下,对订单分配***110作出形式和细节上的各种修正和改变。例如,在一些实施例中,订单分配***110中还可以包括一个存储模块。该存储模块可以是***内部的,也可以是***的外接设备。该存储模块可以实际存在于***中,也可以通过云计算平台完成相应功能。在一些实施例中,可以对各个模块或单元进行任意组合,或者构成子***与其他模块连接。例如,发送子单元510-530可以集成在一起,作为一个发送单元232。再例如,处理模块中的订单生成单元311、判断单元352、用户终端检测单元322和订单分配单元361可以单独作为一个单元,可以任意组合成新的单元,也可以集成为一个处理模块210等。诸如此类的变形,均在本申请的保护范围之内。
根据本申请的一些实施例,图6为订单分配方法的一种示例性流程图。据图所示,在步骤610,订单请求方的打车请求可以被接收。例如,订单请求方的打车请求可以被接收单元231接收,该打车请求可以由订单生成单元311生成订单。需要指出的是,在一些实施例中,订单分配***110也可以直接处理自身存储或从其他地方传来的现成订单,即步骤610可以省略。
在步骤620,订单的出发地信息和/或用户的位置信息可以被获取。例如,在一些实施例中,订单的出发地信息和用户的位置信息可以由接收单元231获取。在另一些实施例中,订单的出发地信息可以由图3中的订单信息获取单元313提取,用户的位置可以由图3中的用户信息获取单元324提取。此处的用户可以是乘客,也可以是司机。为理解申请方便,接下来以司机为例进行说明。在一些实施例中,司机可以选择两种听单模式:派单模式和抢单模式。在派单模式的实施 例中,一个订单可以只发送给一个最适合(例如与订单出发地距离最近)的终端,若该终端不响应或不接单,则可以再发送给另外的终端。在抢单模式的实施例中,一个订单可以同时能够发送给多个终端,以供多个终端抢单。
在步骤630,可以判断是否存在与订单出发地的距离小于预设阈值的用户。例如,可以由判断单元352判断是否存在与订单出发地的距离小于预设阈值的用户。在一些实施例中,预设阈值可以是一个数值或一个区间。预设阈值可以是一个,也可以是多个。预设阈值可以人为设定,也可以由订单分配***110通过机器学习获得。预设阈值可以保持不变,也可以根据实际场景动态更新。在一些实施例中,用户可以是处于派单模式的司机,也可以是处于抢单模式的司机,为理解申请方便,接下来以处于派单模式的司机为例进行说明。此类实施例中,在步骤630,可以由判断单元352判断是否存在于订单出发地距离小于预设阈值的处于派单模式的用户。若存在满足条件的派单模式用户,进入步骤640,若不存在,则返回步骤620。
在步骤640,可以将该订单发送给满足条件的派单模式的用户。例如,可以由发送单元232将该订单发送给满足条件的派单模式的用户。在一些实施例中,派单模式的用户也可以由派单模式用户发送子单元510发送订单。在一些实施例中,仅存在一个派单模式的用户,此时订单分配***110可以直接将该订单发送给该用户。在另一些实施例中,可能存在多个派单模式的用户,此时可以用一个或多个匹配条件筛选出最合适的一个用户,并向该用户发送订单。在一些实施例中,该匹配条件可以包括与订单出发地的距离最近、达到订单出发地的时间最短、路面拥堵时间最短、用户信用/评分最高、用户抢单次数最多、用户忠诚度最高等中的一种或几种的组合。
在一些实施例中,在步骤640发送满足条件的派单模式用户之后,间隔第一预设时间段,根据该匹配条件按照与订单出发地的距离从小到大的顺序将该订单依次发送给其他派单模式的用户。其中,其他派单模式的用户为多个派单模式的用户中除筛选出的用户之外的用户。 例如,当上述预设阈值内存在多个派单模式的用户时,可以首先向与订单出发地距离最近的用户发送该订单,并等待第一预设时间段(例如N秒,N可以取大于0的任何数值),在该N秒内可以不向新的终端播送订单,而对已播送过该订单的用户继续播送。而第一预设时间段之后,按照与该订单的出发地的距离从小到大的顺序将该订单依次发送给其他的派单模式用户。
当不存在满足条件的派单模式用户时,返回步骤620,可以获取抢单模式用户的位置信息。接着在步骤630,可以由判断单元352判断是否存在于订单出发地距离小于预设阈值的抢单模式用户。此处的预设阈值(第二预设阈值),可以与判断派单模式用户的预设阈值(第一预设阈值)一致,也可以不一致。例如,第一预设阈值可以小于第二预设阈值。举例来说,第一预设阈值可以设置为n公里,第二预设阈值可设置为n+m公里,其中,n、m均大于0。
在步骤640,可以向满足条件的抢单模式用户发送该订单。例如,可以由抢单模式用户发送子单元520向满足条件的抢单模式用户发送该订单。在一些实施例中,只有一个抢单模式的用户抢单时,则将该订单分配给该用户即可。在另一些实施例中,可能同时有多个抢单模式的用户抢单,此时可以从多个抢单模式的用户中筛选出符合预设的匹配条件的一个最合适的用户,并将该订单分配给该用户。其中,预设的匹配条件可以包括与订单的出发地的距离最近、达到订单的出发地的时间最短、路面拥堵时间最短、用户信用/评分最高、用户抢单次数最多、用户忠诚度最高等中的一种或几种的组合。
在一些实施例中,向抢单模式用户发送订单后,还可以添加是否存在满足条件的派单模式用户的步骤。例如,在任一抢单模式用户接单之前,每隔第二预设时间段可以由用户终端检测单元322检测是否存在与该订单出发地距离小于第一预设阈值的派单模式用户。具体来说,在一些实施例中,当检测到第一预设阈值范围内不存在派单模式的用户时,则向满足条件的抢单模式用户发送该订单。在向抢单模式用户发送该订单的同时,每隔第二预设时间段检测与该订单的出发地 距离小于第一预设阈值的范围内是否存在派单模式用户。若检测到存在派单模式的用户,可以同时将该订单发送给该派单模式用户。
在一些实施例中,图6所示的订单分配流程还可以进一步包括对订单进行分配的步骤。例如,当派单模式用户接单时,该订单分配步骤可以包括:
A01、当派单模式的用户接单时,则将该订单分配给该派单模式的用户,并停止发送该订单。具体来说,当有派单模式的用户接单时,可以即时将该订单分配给该用户,并同时停止播送该订单。
当抢单模式的终端接单时,该订单分配步骤可以进一步包括:
B01、当抢单模式的用户抢单时,可以等待第三预设时间段。具体来说,当有抢单模式的用户抢单时,并不即时将该订单分配给该用户,而是等待第三预设时间段(例如7秒)。在第三预设时间段内,可以不向新的用户播送该订单,而是继续向已播送过该订单的用户播送。
B02、判断该第三预设时间段内是否有派单模式的用户接单。
B03、若该第三预设时间段内有派单模式的用户接单,则将该订单分配给该派单模式的用户。
B04、若该第三预设时间段内没有派单模式的用户接单,则将该订单分配给该抢单模式的用户。
需要注意的是,以上关于订单分配流程的描述,仅为理解申请方便,并不能把本申请限制在所举实施例范围之内。可以理解,对于本领域的技术人员来说,在了解本申请的基本原理后,可以在不背离这一原理的情况下,对订单分配流程作出改变。图6中的步骤可以改变执行次序,可以省略某些步骤,可以添加某些步骤,可以将多个步骤合并成一个步骤,和/或将一个步骤分解为多个步骤。例如在步骤610和步骤620可以不用严格区分,即可以不必有生成订单或者获取订单出发地和/或用户位置的步骤。例如,在第一次订单分配流程中,也可以先判断抢单模式的用户,再判断派单模式的用户。再例如,在订单分配流程中,还可以添加诸如数据预处理、数据存储等步骤。诸如此 类的变形,均在本申请的保护范围之内。
根据本申请的一些实施例,图7为订单分配***的一种示意图。据图所示,该订单分配***110可以包括一个或多个接收单元231、一个或多个订单生成单元352、一个或多个判断单元352和一个或多个发送单元232。
在一些实施例中,接收单元231可以用于接收订单请求方的打车请求。
在一些实施例中,订单生成单元352可以用于根据该打车请求生成订单信息,该订单信息中至少包括出发地。
在一些实施例中,判断单元352可以用于判断是否到达第n预设时刻。其中n为不小于1且不大于N的整数,N为大于1的整数。
在一些实施例中,发送单元232可以用于当判断单元352确定到达第n预设时刻时,向第n预设播单区域内的所有用户发送该订单信息。
在一些实施例中,发送单元232包括一个或多个终端标识获取子单元730和一个或多个发送子单元740。
其中,终端标识获取子单元730,可以用于在到达第n预设时刻时,获取第n预设播单区域内的所有用户的终端标识。发送子单元740,可以用于根据终端标识获取子单元730获取的终端标识向该用户发送该订单信息。
在一些实施例中,该订单分配***110可以进一步包括一个或多个播单半径确定单元331,可以用于根据历史数据中的第一订单成交率确定各个预设播单半径。
在一些实施例中,该订单分配***110可以进一步包括一个或多个第一调整单元710。该第一调整单元710还可以进一步包括一个或多个成交率获取子单元711、一个或多个判断子单元712和一个或多个播单半径调整子单元713。
其中,成交率获取子单元711可以用于获取预设时间范围内进行订单发送所对应的第二订单成交率;判断子单元712可以用于判断该 第二订单成交率是否小于预设阈值;播单半径调整子单元713可以用于在判断子单元712确定该第二订单成交率小于预设阈值时,调整各个预设播单半径和/或各个预设时刻。
在一些实施例中,该订单分配***110可以进一步包括一个或多个第二调整单元720。该第二调整单元720可以进一步包括一个或多个订单密度获取子单元721和一个或多个播单半径调整子单元722;和/或,一个或多个终端密度获取子单元721和一个或多个播单半径调整子单元724。
其中,订单密度获取子单元721可以用于在订单生成单元311根据打车请求生成订单信息之后,获取预设区域内的订单密度;播单半径调整子单元722可以用于根据获取的订单密度调整各个预设播单半径和/或各个预设时刻;终端密度获取子单元721可以用于在订单生成单元311根据打车请求生成订单信息之后,获取预设区域内的用户密度;播单半径调整子单元724可以用于根据获取的终端密度调整各个预设播单半径和/或各个预设时刻。
对于该订单分配***110的实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处可以参见方法实施例(即图8-图10)的部分说明即可。需要注意的是,以上对于订单分配***110的描述,仅为理解申请方便,并不能把本申请限制在所举实施例范围之内。可以理解,对于本领域的技术人员来说,在了解该***的原理后,可以在不背离这一原理的情况下,对订单分配***110作出形式和细节上的各种修正和改变。例如,在一些实施例中,可以在完成相似功能的前提下,添加或减少一些单元,或者对各个单元进行任意组合,或者构成子***与其他模块连接。诸如此类的变形,均在本申请的保护范围之内。
根据本申请的一些实施例,图8为订单分配方法的一种示例性流程图。据图所示,在步骤810,订单请求方的打车请求可以被接收,该打车请求可以生成订单信息。例如,订单请求方的打车请求可以被接收单元231接收,该打车请求可以由订单生成单元311生成订单信 息。关于订单信息可以参看本申请相关描述,在本实施例中,该订单信息至少要包括出发地。需要指出的是,在一些实施例中,订单分配***110也可以直接处理自身存储或从其他地方传来的现成订单,即步骤810可以省略。
在步骤820,可以根据历史数据中的第一订单成交率确定各个预设播单半径。例如,可以由播单半径确定单元331根据历史数据中的第一订单成交率确定各个预设播单半径。例如,通过对历史订单数据的成交率进行分析,确定各个预设播单半径。为理解申请方便,以下通过实施例进行说明,但本申请并不限制本实施例范围内。
例如,通过分析历史订单数据的成交率,确定成交率在80%~100%的播单区域,与该播单区域对应的播单半径200米为第一预设播单半径。确定成交率在60%~80%的播单区域,与该播单区域对应的播单半径400米为第二预设播单半径。确定成交率在40%~60%的播单区域,与该播单区域对应的播单半径800米为第三预设播单半径。确定成交率在20%~40%的播单区域,与该播单区域对应的播单半径1000米为第四预设播单半径。确定成交率在0%~20%的播单区域,与该播单区域对应的播单半径1500米为第五预设播单半径。在一些实施例中,步骤820并非必需的环节,即不需要预设播单半径也可以完成订单分配的流程。
在步骤830,在到达第n预设时刻时,可以向第n预设播单区域内的所有用户发送该订单信息。此处的预设时刻,可以是根据实际需要设置的任意时间点。其中,第n预设时刻,可以对应于第n个设置的时间点。第n预设播单区域,可以是以订单出发地所处位置为中心,按照第n预设播单半径确定的区域。其中,n为不小于1且不大于N的整数,N为大于1的整数。其中,第N(当n=N时)预设播单半径为最长有效播单距离,第N预设播单区域为最大有效播单区域,即向第N预设播单区域以外的区域发送该订单信息时,不会有用户接收该订单信息。
在一些实施例中,第n+1预设时刻可以晚于第n预设时刻,第 n+1预设播单半径可以大于第n预设播单半径。从而使与该订单的出发地相距更近的用户接收到该订单信息的时间更早,次数更多,使与该订单的出发地相距更远的用户接收到该订单信息的时间更晚,次数更少。在另一些实施例中,也可以使第n+1预设播单半径不大于第n预设播单半径,使与该订单的出发地相距更远的用户接收到该订单信息的时间更早,次数更多,使与该订单的出发地相距更近的用户接收到该订单信息的时间更晚,次数更少。
在步骤830的一些实施例中,在到达第n预设时刻时,可以首先由终端标识获取子单元730获取第n预设播单区域内的所有用户的终端标识,然后根据终端标识向该用户发送该订单信息,以使相应的预设播单区域内的所有用户能够获知该订单信息。为理解申请方便,以下通过实施例进行说明,但本申请并不限制本实施例范围内。
例如,对于某一打车请求,生成与该打车请求对应的订单信息的时间为2015年8月3日8点55分10秒,那么在到达第一预设时刻8点55分11秒时,获取第1预设播单区域内的所有用户的终端标识,然后根据该终端标识向第1预设播单区域内的所有用户发送该订单信息。在到达第二预设时刻8点55分18秒时,获取第2预设播单区域内的所有用户的终端标识,然后根据该终端标识向第2预设播单区域内的所有用户发送该订单信息。在到达第三预设时刻8点55分25秒时,获取第3预设播单区域内的所有用户的终端标识,然后根据该终端标识向第3预设播单区域内的所有用户发送该订单信息。依此类推,在到达第n预设时刻时,首先获取第n预设播单区域内的所有用户的终端标识,然后根据该终端标识向用户发送该订单信息。
在一些实施例中,当到达第n-1预设时刻,向第n-1预设播单区域内的所有用户发送该订单信息之后,若在第n预设时刻之前,第n-1预设播单区域的某一用户成功抢单,则可以在第n预设时刻,不用再继续向第n预设播单区域内的用户发送该订单信息,或者只发送给一部分用户。
需要注意的是,以上关于订单分配流程的描述,仅为理解申请方 便,并不能把本申请限制在所举实施例范围之内。可以理解,对于本领域的技术人员来说,在了解本申请的基本原理后,可以在不背离这一原理的情况下,对订单分配流程作出改变。图8中的步骤可以改变执行次序,可以省略某些步骤,可以添加某些步骤,可以将多个步骤合并成一个步骤,和/或将一个步骤分解为多个步骤。例如,步骤820可以省略。例如,在订单分配流程中可以添加历史订单的成交率分析步骤,当然历史订单的成交率也可以从别处获得。例如,在订单分配流程中,还可以添加诸如数据预处理、数据存储等步骤。再例如,在步骤830之后,还可以添加调整各个预设播单半径和/或各个预设时刻的步骤。诸如此类的变形,均在本申请的保护范围之内。
根据本申请的一些实施例,图9为订单分配方法的一种示例性流程图。步骤810和步骤830可以参看图8中的相关描述。在步骤910,可以获取预设时间范围内进行订单发送所对应的第二订单成交率。例如,可以由成交率获取子单元711获取预设时间范围内进行订单发送所对应的第二订单成交率。其中,预设时间范围可以小于或等于图8中订单分配方法的运行时间。在步骤920,可以判断该第二订单成交率是否小于预设阈值。例如,可以由判断子单元712判断该第二订单成交率是否小于预设阈值,若是则执行步骤930,若否则流程结束。在步骤930,可以调整各个预设播单半径和/或各个预设时刻。例如,可以由播单半径半径调整子单元713调整各个预设播单半径和/或各个预设时刻。其中,在调整各个预设播单半径时,也可以根据其他历史数据(区别与上述图8中的历史数据)重新确定各预设播单半径,或根据经验值对之前选取的各预设播单半径进行微调。本实施例是以订单成交率为指标检验图8所示的订单分配方法的实施效果,当然,还可以根据其他指标,包括但不限于订单取消率、用户信用/评价等。
根据本申请的一些实施例,图10为订单分配方法的一种实施例流程图。步骤810可以参考图8中的相关描述。在步骤1010,可以调整各个预设播单半径和/或各个预设时刻。例如,可以由第二调整单元720调整各个预设播单半径和/或各个预设时刻。在一些实施例中,可 以由订单密度获取子单元721获取预设区域内的订单密度,然后可以由播单半径调整子单元722根据该订单密度调整各个预设播单半径和/或各个预设时刻。在一些实施例中,可以由终端密度获取子单元723获取预设区域内的用户密度,然后可以由播单半径调整子单元724根据该用户密度调整各个预设播单半径和/或各个预设时刻。在一些实施例中,可以同时根据订单密度和用户密度调整各个预设播单半径和/或各个预设时刻。在一些实施例中,订单密度和/或用户密度可以为该预设区域中的订单数量和/或用户数量与该预设区域的面积的比值。其中,预设区域中的订单数量为订单出发地所处位置属于该预设区域的订单信息的数量。
在步骤1020,在到达第n预设时刻或调整后的第n预设时刻时,可以向第n预设播单半径确定的第n预设播单区域内的所有用户或向调整后的第n预设播单半径确定的第n预设播单区域内的所有用户发送该订单信息。其中,该预设区域为以订单的出发地为中心,小于或等于第N预设播单区域(最大有效播单区域)的区域。
为理解申请方便,以下通过实施例来说明如何根据预设区域内的订单密度和/或用户密度调整各个预设播单半径和/或各个预设时间,但本申请并不局限在这些实施例中。
在一些实施例中,当预设区域内的订单密度和/或用户密度大于第一阈值时,可以加长各预设播单半径。当预设区域内的订单密度和/或用户密度小于第一阈值时,可以缩短各预设播单半径。例如,对于将一个有效播单区域划分为5个梯度播单区域,假设各预设播单半径为200米、400米、800米、1000米、和1500米。当预设区域内的订单密度和/或用户密度大于第一阈值时,各预设播单半径可以被调整为230米、500米、900米、1200米、和1500米。当预设区域内的订单密度和/或用户密度小于第一阈值时,各预设播单半径可以被调整为150米、300米、500米、800米、和1500米。
在一些实施例中,当预设区域内的订单密度和/或用户密度大于第一阈值时,可以推迟部分预设时刻。例如,可以推迟第2和第3预设 时刻。当预设区域内的订单密度和/或用户密度小于第一阈值时,可以提前部分预设时刻。例如,可以提前第2和第3预设时刻。
需要注意的是,以上关于订单分配流程的描述,仅为理解申请方便,并不能把本申请限制在所举实施例范围之内。可以理解,对于本领域的技术人员来说,在了解本申请的基本原理后,可以在不背离这一原理的情况下,对订单分配流程作出改变。图10中的步骤可以改变执行次序,可以省略某些步骤,可以添加某些步骤,可以将多个步骤合并成一个步骤,和/或将一个步骤分解为多个步骤。例如在实际应用时,可以采用其他方式或通过反复试验确定较优的调整方式来调整上述各个预设播单半径和/或各个预设时刻。诸如此类的变形,均在本申请的保护范围之内。
根据本申请的一些实施例,图11为订单分配***的一种示意图。据图所示,该订单分配***110可以包括一个或多个第一数目订单接收范围确定单元1130、一个或多个第一数目订单接收子单元1110、一个或多个第一数目订单接收子单元1120、一个或多个第二数目订单接收范围确定单元1140和一个或多个可选的设置单元1150。
其中,第一数目订单接收范围确定单元1130可以用于确定区域中的第一数目的用户的默认订单接收范围;第一数目订单接收子单元1110可以用于获取第一数目的用户在默认订单接收范围中的第一平均订单数目;第二数目订单接收范围确定单元1140可以用于获取第二数目的用户在默认订单接收范围中的第二平均订单数目;第二数目订单接收范围确定单元1140可以用于根据第一平均订单数目以及第二平均订单数目来确定第二数目的用户的订单接收范围;可选的设置单元1150可以用于将订单接收范围设置为默认订单接收范围。
对于该订单分配***110的实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处可以参见方法实施例(即图12)的部分说明即可。需要注意的是,以上对于订单分配***110的描述,仅为理解申请方便,并不能把本申请限制在所举实施例范围之内。可以理解,对于本领域的技术人员来说,在了解该***的原理后, 可以在不背离这一原理的情况下,对订单分配***110作出形式和细节上的各种修正和改变。例如,在一些实施例中,可以在完成相似功能的前提下,添加或减少一些单元,或者对各个单元进行任意组合,或者构成子***与其他模块连接。诸如此类的变形,均在本申请的保护范围之内。
根据本申请的一些实施例,图12为订单分配方法的一种示例性流程图。据图所示,在步骤1210,可以确定区域中的第一数目的用户的默认订单接收范围。在一些实施例中,区域可以指行政区划分或者人为设定的范围,其大小可以固定不变,也可以根据实际场景进行调整。在一些实施例中,默认订单接收范围可以是预先设定的范围,按照默认订单接收范围将其中的订单发送给用户可以使用户能够随时获得较为合理数目的订单,从而使得用户与订单发起者能够较为高效地确立并且完成订单。例如,默认订单接收范围可以被设定为1至5公里范围内的任何距离。同时,根据实际应用场景与情况的不同,默认订单接收范围可以被设定为更大或者更小。在一些实施例中,第一数目的用户可以作为统计样本,该第一数目可以等于或小于该区域中的所有用户的数目,例如第一数目可以是该区域中所有用户数目的80%或更多或更少。
在一些实施例中,可以由订单分配***110直接设定默认订单接收范围,也可以由用户设定。例如,订单分配***110可以统计将区域中的第一数目的订单接收范围设定成不同值时,其中的用户在单位时间(例如,1小时、1天等)内所完成的评价订单数目,并且将与最大平均订单数目对应的订单接收范围设定为默认订单接收范围。再例如,可以由区域中的各个用户选择自己的优选订单接收范围,并且由订单分配***110通过对这些不同用户的不同优选订单接收范围进行例如求平均值来得到区域中的默认订单接收范围。
在步骤1220,可以获取第一数目的用户在默认订单接收范围中的第一平均订单数目。例如,可以由第一数目订单接收子单元1110获取第一数目的用户在默认订单接收范围中的第一平均订单数目。在一 些实施例中,可以由订单分配***110通过对第一数目的用户中的每个用户在默认订单接收范围中所接收到的订单数目进行例如求平均值来得到第一平均订单数目。其中,可以针对一个时间点来获得用户此时已接收并被显示或待显示的订单数目来获取第一平均订单数目。也可以针对一个时间段(例如,10分钟至1小时或者任何时间段)来获得用户在这个时间段内所接收到的订单数目来获取第一平均订单数目。
在步骤1230,可以获取第二数目的用户在上述默认订单接收范围中的第二平均订单数目。例如,可以由第二数目订单接收子单元1120获取第二数目的用户在上述默认订单接收范围中的第二平均订单数目。其中,第二数目可以小于、大于或等于第一数目。在一些实施例中,第二数目可以小于第一数目。在另一些实施例中,例如当第一数目的用户为区域中的有代表性的用户时,第二数目也可以大于或者等于第一数目。其中,第一数目的用户为区域中的有代表性的用户是指可以通过第一数目的用户的平均订单数目可信地推断出区域中的大部分或者所有订单接收方的平均订单数目。判断第一数目的订单接收方是否为有代表性的订单接收方可以遵循许多标准,例如,可以将区域均匀地分割成大小相等的子区域,而后从每个子区域中选取一定数目(这些数目可以相同或者不相同)的、总和为第一数目的用户。由于这些用户是按照地理分布被均匀选择的,因此可以将他们视为有代表性的用户。应当理解,子区域分割的越小,第一数目的订单接收方有代表性的程度可能越高。
在步骤1240,可以根据第一平均订单数目以及第二平均订单数目,来确定第二数目的用户的订单接收范围。例如,可以由第二数目订单接收范围确定单元1140根据第一平均订单数目以及第二平均订单数目,来确定第二数目的用户的订单接收范围。其中,用户的订单接收范围可以是任意形状,包括但不限于圆形、椭圆形、长方形、正方形、三角形或者其他形状。例如,若订单接收范围是以用户为圆心的圆形范围,在这种情况下,确定用户的订单接收范围可以通过确定 圆形范围的半径来实现。再例如,订单接收方的范围可以是在地图上显示的以用户为中心的正方形以便于将区域的范围分成正方形的小块来进行处理,在这种情况下,确定用户的订单接收范围可以通过确定正方形范围的边长来实现。
根据本申请的一些实施例,在确定第二数目用户的订单接收范围时,可以使用第一平均订单数目与第二平均订单数目的关系作为系数来进行确定。为理解申请方便,以下将通过实施例进行说明,但本申请并不局限在这些实施例之中。
在一些实施例中,可以使用第一平均订单数目与第二平均订单数目之比作为确定因子来确定订单接收范围。其中,当第一平均订单数目大于第二平均订单数目时,应当增大用户的订单接收范围,而此时确定因子大于1,因此可以用如上述的用户的半径(或者边长)与确定因子相乘来获得增大后的订单接收范围;当第一平均订单数目小于第二平均订单数目时,应当减小用户的订单接收范围,而此时确定因子小于1,因此可以用如上述的用户的半径(或者边长)与确定因子相乘来获得减小后的订单接收范围;当第一平均订单数目恰好等于第二平均订单数目时,确定因子等于1,因此如上述无需进行任何处理。这些实施例中所描述的确定订单接收范围可以用以下公式1来表示:
Figure PCTCN2016072840-appb-000001
   (公式1)
其中,R1可以为用户的与默认订单接收范围对应的半径(或者边长),N1可以为第一平均订单数目,N2可以为第二平均订单数目,R2可以为用户的确定的半径(或者边长)。
在一些实施例中,可以对上述第一平均订单数目与第二平均订单数目之比进行处理来作为确定因子。例如,由于第一平均订单数目与第二平均订单数目均体现了作为面积的订单接收范围中的订单数目,因此可以将第一平均订单数目与第二平均订单数目之比进行开方处理来作为确定因子,从而使得在确定作为线段长度的上述半径或者边长时,能够确定更为精准的平均订单数目。这些实施例中所描述的确定订单接收范围可以用以下公式2来表示:
Figure PCTCN2016072840-appb-000002
   (公式2)
其中,R1为用户的与默认订单接收范围对应的半径(或者边长),N1为第一平均订单数目,N2为第二平均订单数目,R2为用户的确定的半径(或者边长)。
在一些实施例中,还可以为上述确定因子预先设定上限值和/或下限值(例如,上限值可以为1.5或者任何合理数值,下限值可以为0.5或者任何合理数值)。当计算出的确定因子在上限值和下限值之间时,则采用该确定因子;当计算出的确定因子大于上限值时,则可以采用上限值作为确定因子;当计算出的确定因子小于下限值时,则可以采用下限值作为确定因子。
在一些实施例中,可以仅通过第一平均订单数目与第二平均订单数目的大小关系来进行确定。例如,当第一平均订单数目大于第二平均订单数目时,可以用如上述的订单接收方的半径(或者边长)与预先设定的第一预定值(例如1.2或者任何合理数值)相乘来获得增大后的订单接收范围;而当第一平均订单数目小于第二平均订单数目时,可以用如上述的订单接收方的半径(或者边长)与预先设定的第二预定值(例如0.8或者任何合理数值)相乘来获得减小后的订单接收范围。当第一平均订单数目等于第二平均订单数目时,可以将上述默认订单接收范围作为确定后的订单接收范围。这些实施例中所描述的确定订单接收范围可以用以下公式3来表示:
Figure PCTCN2016072840-appb-000003
   (公式3)
其中,R1为用户的与默认订单接收范围对应的半径(或者边长),N1为第一平均订单数目,N2为第二平均订单数目,a为第一预定值,b为第二预定值,R2为用户的确定的半径(或者边长)。
根据本申请的一些实施例,当第二数目的用户的订单接收范围被确定后,可以进入可选步骤1250。在步骤1250中,可以将确定的订单接收范围确定为默认订单接收范围。
在一些实施例中,图12所示的订单分配方法可以实时、动态地执行。例如,可以在用户每次向订单分配***110请求新的订单以及订单分配***110每次向用户发送新的订单时实时执行上述过程,从而使得可以持续地动态调整用户的订单接收范围。再例如,为了减小订单分配***110的计算量,可以每隔一段时间(例如5分钟或者任何预先设定的时间)周期性地执行上述过程。同时,也可以响应于用户以及订单分配***110的请求来执行上述过程。
需要注意的是,以上关于订单分配流程的描述,仅为理解申请方便,并不能把本申请限制在所举实施例范围之内。可以理解,对于本领域的技术人员来说,在了解本申请的基本原理后,可以在不背离这一原理的情况下,对订单分配流程作出改变。例如,图12中的步骤可以改变执行次序,可以省略某些步骤,可以添加某些步骤,可以将多个步骤合并成一个步骤,和/或将一个步骤分解为多个步骤。例如,步骤1220与步骤1230可以按照任意顺序或者同时执行,可以省略步骤1250,可以将步骤1220和步骤1230合并为一个步骤执行,和/或将步骤1240分解为比较第一平均订单数目以及第二平均订单数目的步骤以及确定用户的订单接收范围的步骤两个步骤执行。诸如此类的变形,均在本申请的保护范围之内。
根据本申请的一些实施例,图13提供了订单分配方法的一种示例性流程图。在步骤1310,订单信息可以被获取。例如,订单信息可以被订单分配***110中的接收单元接收231获取。订单信息可以包括但不限于订单本身信息、用户信息和其他信息。其中订单本身信息可以包括订单编号、出发地、出发时间、订单时间、出发时间、到达时间、愿意等待时间、里程、搭乘人数、有无行李、价格、付款方式(例如现金支付、刷卡支付、网上支付、汇款支付等)、消费方加价、服务方调价、***调价、红包/优惠券使用情况、订单完成情况、服务方选择订单情况、消费方发送订单情况等中的一个信息或者任意信息的组合。用户信息可以包括但不限于用户姓名、昵称、性别、国籍、年龄、联系方式(电话号码、手机号码、社交账号信息(例如微信号 码、QQ号码和Linkedin等)等任何可以联系到本人的方式和信息等)、位置信息(坐标信息、方向信息、运动状态信息等)、职业、评价等级、使用时间、驾龄、车龄、车型、车牌号、驾驶证号、认证情况、用户习惯/喜好、额外服务能力(例如车的后备箱大小、全景天窗等额外特性)等中的一种或几种的组合。其他信息是指不受消费方、服务方控制的信息,或者是指暂时性/突发性的信息。其他信息可以包括但不限于天气情况、环境情况、道路状况(例如因安全性或者道路作业等原因封闭道路)、交通条件等,或者上述信息的任意组合。
在一些实施例中,订单信息的部分内容可以是实时信息,也可以是历史订单信息。实时信息可以是在某个时刻或在某个时间段的订单信息,时间段可以是几秒、几分、几小时或者根据喜好自定义的时间段;时段也可以是特定的时间,例如工作日、休息日、节假日、高峰时段、非高峰时段等。历史订单信息可以包括过去的相关信息,例如,完成订单量、请求订单量、接收订单量、订单完成率、抢单率、毁约率等中的一种或几种的组合。
在步骤1320,可以针对订单信息获取订单位置信息。在一些实施例中,订单位置信息可以是订单请求者的坐标信息、订单接收者的坐标信息、该城市的交通地图信息、订单请求者和订单接收者之间的路面距离等信息中的一种或任意几种的组合。关于路面距离的相关描述可参见本申请中其他部分的相关说明。在一些实施例中,订单位置信息可以是订单的始发地和目的地,用户终端的目的地,用户当前运动状态信息以及根据策略确定的用户的顺路等级中的一种或任意几种的组合。关于顺路等级的相关描述可参见本申请中其他部分的相关说明。在一些实施例中,订单位置信息还可以是订单的出发地、始发地、目的地,用户终端的当前位置,以及订单出发地与用户终端之间的距离等信息中的一种或任意几种的组合。
在步骤1330,可以基于位置信息获取用户的抢单率。在一些实施例中,抢单率可以根据位置信息、时间信息和历史订单信息中的一种或任意几种的组合,采用预先建立的预估模型,获得用户终端的抢单 率。关于预估模型的相关描述可参见本申请中其他部分的说明。
在步骤1340,可以基于用户的抢单率信息,向用户终端发送订单信息。例如,可以基于用户的抢单率信息,由发送单元232向用户终端发送订单信息。在一些实施例中,可以根据用户的抢单率,确定是否向该终端分配订单。在一些实施例中,可以根据用户的抢单率,向一个用户终端发送订单信息。在一些实施例中,可以根据用户的抢单率,根据抢单率的由大到小依次向多个用户终端分配订单。
需要注意的是,图13所描述的订单分配方法仅为理解申请方便,并不能把本申请限制在所举实施例的范围内。可以理解,对于本领域的技术人员来说,在了解该方法的原理后,可能在不背离这一原理的情况下,对各个步骤进行任意组合,或者对实施上述方法的应用领域形式和细节上的各种修正和改变。例如,订单位置信息还可以是任何与订单位置相关的其他信息,例如订单位置的历史订单信息等。这些修正和改变都在本申请的保护范围之内。
根据本申请的一些实施例,图14提供了订单分配***110的一种示意图。订单分配***110可以包括一个或多个接口模块230/240和一个或多个处理模块210。其中,接口模块230/240可以进一步包括一个或多个接收单元231和一个或多个发送单元232。处理模块210可以进一步包括一个或多个距离确定单元334,一个或多个抢单率预测单元342和一个或多个订单分配单元361中的一种或任意几种的组合。距离确定单元334又可以包括一个或多个坐标信息获取子单元1410和一个或多个路面距离获取在单元1420。关于接口模块230/240、接收单元231和发送单元232的相关描述可参见本申请其他任意部分的相关说明。
在一些实施例中,坐标信息获取子单元1410可以用于接收乘客通过设备发送的打车请求之后,获取订单请求者的坐标信息和该坐标信息预设范围内的各个订单接收者,以及每一个订单接收者的坐标信息;在一些实施例中,坐标信息可以包括绝对坐标信息、相对坐标信息、相对极坐标信息等中的一种或任意几种的组合。坐标信息还可以 是任何可以标定地理位置关系的有序数对或数据值的组合。
在一些实施例中,路面距离获取子单元1420可以用于根据订单请求者发送的订单请求获取订单所属城市,进而获取该城市的交通地图信息。根据订单请求者该城市的交通地图信息、坐标信息获取子单元1410获取的该订单请求者的坐标信息和预设范围内每个订单接收者的坐标信息获取订单请求者与每个订单接收者之间的路面距离。在一些实施例中,路面距离可以是订单请求者和订单接收者之间的直线距离,也可以是通过定位***和/或实际道路路情况信息得到的订单接收者到达订单请求者的车辆实际行驶距离。
在一些实施例中,抢单率预测单元342可以用于根据每个订单接收者与订单请求者之间的路面距离以及每个订单接收者在预设时间段内的历史订单的相关特征信息预测每个订单接收者的订单抢单概率。具体地,抢单率预测单元342可以用于采用预先建立的预测模型,预测每个订单接收者的订单抢单概率。在一些实施例中,预测模型可以根据订单接收者在预设时间段内的历史订单的相关信息建立。其中,路面距离可以是预测模型中的预测变量,订单接收者的订单抢单概率可以为预测模型中的目标变量。在一些实施例中,历史订单的相关特征信息可以包括产生该历史订单的城市、产生该历史订单的时间、该历史订单的道路拥堵情况以及该历史订单的价值中的一个或者任意几个的组合。
在一些实施例中,预测模型可以是定性的,也可以是定量的。对于定量的预测模型,它可以基于时序预测法,也可以基于因果分析法。其中,时间预测法进一步可以包括平均平滑法、趋势外推法、季节变动预测法和马尔可夫时序预测法等中的一种或几种的组合。因果分析法进一步可以包括一元回归法、多元回归法和投入产出法。在一些实施例中,预测模型可以包括但不限于加权算术平均模型、趋势平均预测模型、指数平滑模型、平均发展速度模型、一元线性回归模型、高低点模型中的一种或几种的组合。另外在一些实施例中,对于信息处理所用到的公式、算法和/或模型,可以通过机器学习,不断进行优化。
在一些实施例中,抢单率预测单元342还可以用于根据线上实时获取的订单相关信息和相应订单中订单接收者与订单请求者之间的路面距离,采用机器学习算法,对预先建立的预测模型进行优化。关于机器学习算法的相关描述,可参见本申请其他任何部分的相关说明。
在一些实施例中,订单分配单元361可以用于根据抢单率预测单元342预测出的每个订单接收者的订单抢单概率,向订单接收者分配与打车请求相对应的订单。具体地,订单分配单元361可以用于选取订单抢单概率中大于预设阈值的订单抢单概率,向选取的每一个订单抢单概率所对应的订单接收者分配打车请求对应的订单信息。
在一些实施例中,订单分配***110还可以包括一个历史数据获取模块、一个预测模型建立模块和一个地图信息更新模块等。其中,在抢单率预测单元342采用预先建立的预测模型预测每个订单接收者的订单抢单概率之前,历史数据获取模块可以用于获取每个订单接收者在预设时间段内的历史订单的相关特征信息和每一个历史订单中订单接收者与订单请求者之间的路面距离。
在一些实施例中,预测模型建立模块可以用于将历史数据获取模块获取的历史订单的相关特征信息和相应的订单请求者与订单接收者之间的路面距离作为训练数据,采用线性回归模型对训练数据进行训练,得到订单抢单概率的预测模型。在一些实施例中,线性回归模型可以是逻辑斯特回归模型和支持向量机模型中的一种。为了便于理解,下面以逻辑斯特回归模型为例,对线性回归模型做进一步的说明。
逻辑斯特回归(Logistic Regression)模型广泛应用于二分类问题中。在本申请的一些实施例中,逻辑斯特回归模型可以用于判断竞争概率的高低问题中。逻辑斯特回归公式表示如下:
Figure PCTCN2016072840-appb-000004
   (公式4)
其中,
Figure PCTCN2016072840-appb-000005
其中,x为预测变量,y为目标变量,y=1表示预测为抢单,y=0 表示预测为不抢单,w为模型参数。在一些实施例中,w可以采用最大似然方法进行估计。例如,可以将历史订单的相关特征中的各种特征数据(例如,产生该历史订单的城市,产生该历史订单的时间,针对该历史订单的道路拥堵情况以及该历史订单的价值中的一个或者多个)抽取成预测变量x,将新发起的订单的竞争概率作为目标变量y。在一些实施例中,通过对历史订单的成交信息进行逻辑斯特回归模型训练,可以对新发起订单的竞争概率进行预测。在另外一些实施例中,还可以通过不断增加新发起订单是否被抢相关的特征,不断地提高逻辑斯特回归模型的精准度。
在一些实施例中,地图信息更新模块可以根据预设时间周期更新订单该城市的交通地图信息。在一些实施例中,可以通过地图信息更新模块根据预设时间周期更新订单请求者所属城市的交通地图信息。采用更新后的城市的交通地图信息,可以防止由于城市的交通建设对交通路线的改造造成的地图信息的改变,从而准确的获取该订单请求者到每一个订单接收者的路面距离。
需要注意的是,图14所描述的订单分配***110仅为理解方便,并不能把本申请限制在所举实施例的范围内。可以理解,对于本领域的技术人员来说,在了解该***的原理后,可能在不背离这一原理的情况下,对各个模块/单元进行任意组合,或者构成子***与其他模块连接,对实施上述***的应用领域形式和细节上的各种修正和改变。例如,订单分配***110还可以包括一个历史数据获取模块、一个预测模型建立模块和一个地图信息更新模块等。又例如,订单信息处理***110可以只有处理功能而不涉及接收单元和发送单元。诸如此类的修正和改变均在本申请的保护范围内。
根据本申请的一些实施例,图15提供了订单分配方法的一种示例性流程图。在步骤1510,可以获取订单中订单请求者和订单接收者的坐标信息。例如,在接收订单请求者发送的打车请求之后,坐标信息获取子单元1410可以获取该订单请求者的坐标信息和该坐标信息的预设范围内的各个订单接收者,以及每一个订单接收者的坐标信 息。
在一些实施例中,可以将订单请求者的坐标信息添加到订单请求者发送的打车请求中,在接收订单请求者发送的打车请求之后,从打车请求中获取该订单请求者的坐标信息。通过实时接收订单请求者的坐标信息的预设范围内的各个订单接收者的的位置信息可由定位***定位信息和/或基站定位信息来确定并实时上传。
在一些实施例中,订单请求者发送的打车请求还可以包括:出发地、始发地、目的地及该订单请求者的用户标识等信息中的一种或多种。订单请求者的用户标识可以包括手机号码、身份标识码(Identity,简称id)、硬件地址(Media Access Control,简称MAC)等信息中的一种或多种。关于更多的订单信息,可以参看本申请中其他相关的描述。
在一些实施例中,预设范围的具体取值可以根据订单请求者所属城市的交通路况、所属城市的具体城区等信息进行设置和调整。例如,若订单请求者所属城市为北京的大兴区、交通路况良好,则将预设范围的取值设置的大一些,若订单请求者所属城市为北京的海淀区,交通路况较为拥堵,则可以将预设范围的取值设置的小一些。本申请对此不做具体限定。
在一些实施例中,坐标信息可以包括绝对坐标信息、相对坐标信息、相对极坐标信息等中的一种或任意几种的组合。坐标信息还可以是任何可以标定地理位置关系的有序数对或数据值的组合。
在步骤1520,可以获取订单请求者和订单接收者之间的路面距离。例如,根据订单请求者所属城市的交通地图信息、该订单请求者的坐标信息和每一订单接收者的坐标信息,路面距离获取子单元1420可以获取该订单请求者到每一个订单接收者的路面距离。
在一些实施例中,可以通过订单请求者所属城市的交通地图信息以及该订单请求者的坐标信息和订单请求者的预设范围内的每一个订单接收者的坐标信息,计算订单请求者到每一个订单接收者的实际的路面距离。通过订单分配阶段,在其他因素相同的情况下,可以根 据订单请求者到每一个订单接收者的实际的路面距离进行订单分配,使得订单接收者可以更为准确的获得订单信息。
在步骤1530,可以预测订单接收者的抢单率。例如,根据每一个订单接收者对应的路面距离和该订单接收者的在预设时间段内的历史订单的相关特征信息,抢单率预测单元342可以预测该订单接收者的订单抢单概率。
在一些实施例中,叫车***在订单分配阶段中,抢单率预测单元342可以通过每一个订单接收者对应的路面距离和该订单接收者的其他与订单相关特征信息对该订单接收者的订单抢单概率进行预测。可以根据订单接收者的订单抢单概率进行订单的分配,例如通过对订单抢单概率进行排序,按照抢单概率从大到小的顺序向订单接收者发送订单,或者预设一个抢单概率阈值对订单接收者进行筛选。
在一些实施例中,订单的相关特征信息包括订单接收者相关特征信息、订单相关特征信息等。
在一些实施例中,步骤1530可以包括采用预先建立的预测模型预测每个订单接收者的订单抢单概率。预测模型可以是根据该订单接收者在预设时间段内的历史订单的相关特征信息建立的,该路面距离可以为该预测模型的预测变量,订单接收者的订单抢单概率可以为该预测模型的目标变量。在一些实施例中,历史订单的相关特征信息可以包括产生该历史订单的城市、产生该历史订单的时间、该历史订单的道路拥堵情况以及该历史订单的价值中的一个或者任意几个的组合。关于预测模型的相关描述,可参见本申请中***实施例中的说明。
在一些实施例中,在采用预先建立的预测模型预测每个订单接收者的订单抢单概率之前,还可以包括以下步骤:
首先,路面距离获取子单元1420可以获取每一个订单接收者在预设时间段内的历史订单的相关特征信息和每一历史订单中该订单接收者对应的路面距离。然后,抢单率预测单元342可以将历史订单的相关特征信息和每一历史订单中该订单接收者对应的路面距离作为训练数据,采用线性回归模型对该训练数据进行训练,得到订单抢 单概率的预测模型。在一些实施例中,获取订单抢单概率的预测模型后,还可以根据线上实时获取的订单的相关特征信息和相应订单中该订单接收者对应的路面距离,采用机器学习算法,对该预先建立的预测模型进行优化。
在一些实施例中,可以通过抽取该历史订单的相关特征中的各种特征数据作为预测变量,并以该历史订单的订单抢单结果作为目标变量进行线性回归模型训练,得到订单抢单概率的预测模型。
在一些实施例中,线性回归模型可以是逻辑斯特回归模型和支持向量机模型中的一种。关于逻辑斯特回归模型的相关描述,可参见***实施例部分(见图14)的说明。
在一些实施例中,订单抢单概率预测可以分成离线训练和线上实时计算两个阶段。其中,离线训练阶段可以将历史订单的相关特征中的各种特征数据,例如司机相关特征、订单相关特征等各种特征抽取成预测变量,将订单的竞争概率作为目标变量,利用历史数据进行模型训练,得到预测模型。线上实时计算阶段可以将模型运用于线上,对实时抽取出来的订单的相关特征信息和相应订单中该订单接收者对应的路面距离进行计算,采用机器学习算法,对该预先建立的预测模型进行优化。关于机器学习算法的相关描述请参见本申请的其他部分。
在步骤1540,可以根据每一订单接收者的订单抢单概率,向订单接收者分配该打车请求对应的订单。例如,订单分配单元361可以根据每一订单接收者的订单抢单概率,向订单接收者分配该打车请求对应的订单。
在一些实施例中,该与打车请求对应的订单可以包括订单请求者的出发地、始发地、目的地、用户标识、订单产生的时间、出发时间、订单请求者到每个订单接收者的路面距离等信息中的一种或者几种的组合。
在一些实施例中,步骤1540可以具体包括选取订单抢单概率中大于预设阈值的订单抢单概率,向选取的每一订单抢单概率对应的订 单接收者分配该打车请求对应的订单。
在一些实施例中,可以按照订单抢单概率从大到小的顺序,向该订单接收者发送该当前订单。例如,对于向该订单接收者发送包括该当前订单的多个订单的情况,如果与该当前订单相关的历史订单的抢单概率相对其他当前订单相关的历史订单的抢单概率来说较小,则确定当前订单对于该订单接收者来说将可能是无价值或低价值的。因此,需要选取该订单抢单概率中大于预设阈值的订单抢单概率,并通过向选取的每一订单抢单概率对应的订单接收者分配该打车请求对应的订单。
在一些实施例中,订单分配方法还可以包括,根据预设时间周期更新该订单请求者所属城市的交通地图信息。例如,通过采用更新后的城市的交通地图信息,可以防止由于城市的交通建设对交通路线的改造造成的地图信息的改变,从而准确的获取该订单请求者到每一个订单接收者的路面距离。
需要注意的是,图15所描述的订单分配方法仅为理解申请方便,并不能把本申请限制在所举实施例的范围内。可以理解,对于本领域的技术人员来说,在了解该方法的原理后,可能在不背离这一原理的情况下,对各个步骤进行任意组合,或者对实施上述方法的应用领域形式和细节上的各种修正和改变。例如,订单请求者和订单接收者的路面距离可以通过计算除坐标以外的其他方式获得。又例如,订单接收者的抢单率可以通过决策树模型训练。这些修正和改变都在本申请的保护范围之内。
根据本申请中的一些实施例,图16提供了订单分配***110的一种示意图。如图16,订单分配***110可以包括一个或多个接口模块230/240和一个或多个处理模块210。其中,接口模块230/240可以进一步包括一个或多个接收单元231和一个或多个发送单元232。处理模块210可以进一步包括一个或多个匹配条件获取单元1610,一个或多个订单筛选单元312,一个或多个顺路等级确定单元333,一个或多个抢单率预测单元342和一个或多个订单分配单元361中的一 种或任意几种的组合。关于接口模块230/240、接收单元231和发送单元232的相关描述可参见本申请其他任意部分的相关说明。
在一些实施例中,匹配条件获取单元1610可以用于获取用户对应的订单匹配条件。其中,订单匹配条件可以包括订单的匹配范围、匹配时间等条件。在一些实施例中,订单的匹配范围可以根据用户所属城市、城区以及用户当前所处的地理位置、当前的运动状态和司机用户当前的目的地进行确定。在一些实施例中,匹配时间可根据司机用户当前的时间安排确定。
在一些实施例中,匹配条件获取单元1610可以进一步包括订单匹配条件接收单元、订单匹配条件判定单元等中的一种或任意组合。其中,订单匹配条件接收单元可以用于接收用户上传的订单匹配条件;订单匹配条件判定单元可以用于根据用户当前的运动状态、地理位置等信息以及预设的规则,确定用户对应的订单匹配条件。
在一些实施例中,订单筛选单元312可以用于根据用户对应的订单匹配条件对当前订单进行条件匹配,筛选出符合该订单匹配条件的订单。在一些实施例中,当前订单可以为打车平台中待分配的订单。
在一些实施例中,顺路等级确定单元333可以用于针对订单筛选单元312筛选出的每一个订单和预设策略,确定每一订单对应的顺路等级。
在一些实施例中,顺路等级确定单元333可以进一步包括订单地址获取单元、终端地址获取单元以及顺路等级判定单元。其中,订单地址获取单元可以用于获取筛选出的订单的始发地和目的地。终端地址获取单元可以用于获取该用户当前的目的地。顺路等级判定单元可以用于根据预设策略确定所属订单的始发地和目的地对应的用户当前的目的地的顺路等级。在一些实施例中,顺路等级可以包括直达和间接到达。具体的,顺路等级的具体设定可以根据用户需求进行更加准确的设定和划分。例如,顺路等级可以根据司机用户实际需要行驶的路面距离,和/或,实际行驶需要的时间等划分为A、B、C、D、E五个等级。其中,司机用户实际需要行驶的路面距离,和/或,实际行 驶需要的时间,可以为用于确定订单对应该用户的顺路等级的预设策略。
在一些实施例中,抢单率预测单元342可以用于采用预先建立的抢单概率预估模型,根据该订单的顺路等级预测该用户的订单抢单概率。
在一些实施例中,订单分配单元361可以用于根据抢单率预测单元342预测出的订单抢单概率,确定是否向用户分配筛选出的订单。
在一些实施例中,订单分配单元361可以进一步包括判断单元和分配单元。判断单元可以用于判断订单抢单概率是否大于预设阈值。分配单元可以用于当该判断单元的判断结果为大于预设阈值时,确定该订单符合订单分配条件,并向该用户分配筛选出的订单。在一些实施例中,分配单元还可以用于当筛选出的订单中,存在多个符合订单分配条件的订单时,按照订单抢单概率从大到小的顺序,向该用户分配符合订单分配条件的订单。
在一些实施例中,订单分配***110还可以进一步包括历史数据获取模块、预测模型建立模块等中的一种或任意几种。其中,历史数据获取模块可以用于获取用户在预定时间段内的历史订单数据。预测模型建立模块可以用于将该历史订单数据作为训练数据,采用线性回归模型对该训练数据进行训练,得到抢单概率的预估模型。
在一些实施例中,历史订单数据可以包括每一历史订单对应该用户的顺路等级特征。
在一些实施例中,线性回归模型可以是以下中的一种:逻辑斯特回归模型、支持向量机模型。为便于理解,下面以以逻辑斯特回归模型作为线性回归训练模型为例,对预测模型建立模块使用的线性回归模型做进一步说明。
逻辑斯特回归(Logistic Regression)模型可以广泛运用于二分类问题。在预测变量X=x时,目标变量Y=1的概率如下公式5表示:
P=(Y=1|X=x)=1/(1+exp(-w*x)),   (公式5)
在预测变量X=x时,目标变量Y=0的概率如下公式6表示:
P=(Y=0|X=x)=1/(1+exp(-w*x)),   (公式6)
其中,X表示预测变量,Y表示目标变量,Y=1表示预测为抢单,Y=0表示预测为不抢单,w表示模型参数。
在一些实施例中,可以将历史订单数据(例如,播单时的订单相关特征、司机相关特征、订单和司机相关特征等中的一个或多个)抽取成预测变量X,而将新发起订单的竞争概率作为目标变量Y。通过对历史订单的成交信息进行逻辑斯特回归模型训练,可以对当前待分配订单的竞争概率进行预测。在一些实施例中,还可以通过不断添加新发起订单是否被抢相关的特征,不断地提高逻辑斯特回归模型的准确度。
在一些实施例中,预测模型建立模块还可以用于根据线上实时获取的订单数据,采用机器学习算法,对订单概率预测模型进行优化。在一些实施例中,实时获取的订单数据可以包括订单对应用户的顺路等级特征。关于机器学习算法的相关描述请参见本申请的其他部分。
需要注意的是,图16所描述的订单分配***110仅为理解申请方便,并不能把本申请限制在所举实施例的范围内。可以理解,对于本领域的技术人员来说,在了解该***的原理后,可能在不背离这一原理的情况下,对各个模块/单元进行任意组合,或者构成子***与其他模块连接,或者对实施上述***的应用领域形式和细节上的各种修正和改变。例如,订单分配***110可以不包括匹配条件获取单元1610而直接对订单进行筛选。又例如,订单分配***110还可以包括历史数据获取模块、预测模型建立模块等中的一种或任意几种。再例如,接口模块230/240可以省略。诸如此类的修正和改变均在本申请的保护范围之内。
根据本申请中的一些实施例,图17提供了订单分配方法的一种示例性流程图,该方法可以包括如下步骤:
在步骤1710,可以获取用户对应的订单匹配条件。例如,匹配条件获取单元1610可以获取用户对应的订单匹配条件。在一些实施例中,订单匹配条件的获取方式可以是接收用户上传的订单匹配条件。 在一些实施例中,订单匹配条件的获取方式可以是监测用户当前的运动状态信息,例如行驶速度,行驶方向等,基于该用户当前的运动状态信息,根据预设规则确定该用户对应的订单匹配条件。在一些实施例中,预测规则可以根据司机可以接受的距离差距和时间差距进行规则设定。在一些实施例中该,步骤1710也可以省去,不必获取用户对应的订单匹配条件。
在步骤1720,可以根据用户对应的订单匹配条件对当前订单进行条件匹配,筛选出符合该订单匹配条件的订单。例如,订单筛选单元312可以根据用户对应的订单匹配条件对当前订单进行条件匹配,筛选出符合该订单匹配条件的订单。在一些实施例中,该当前订单可以是打车平台中待分配的订单。当打车平台根据该打车请求生成相应的订单后,打车平台会根据终端对应的订单匹配条件对当前订单进行条件匹配,筛选出符合该订单匹配条件的打车平台中待分配的订单向终端分配。
在一些实施例中,订单匹配条件可以包括订单的匹配范围、匹配时间等条件。具体的,订单的匹配范围可以根据用户所属城市、城区以及终端当前所处的地理位置、当前的运动状态和所属司机用户当前的目的地进行确定;匹配时间可根据所属司机用户当前的时间安排确定。
在步骤1730,可以针对筛选出的每一个订单,根据预设策略确定该订单对应该用户的顺路等级。例如,顺路等级确定单元333可以针对筛选出的每一个订单,根据预设策略确定该订单对应该用户的顺路等级。
在一些实施例中,根据预设策略确定对应用户的顺路等级,还可以包括获取筛选出的该订单的始发地和目的地,获取该用户当前的目的地,根据预设策略确定该订单的始发地和目的地对应的用户当前的目的地顺路等级等。关于顺路等级的相关描述可参见本申请中其他任意部分关于顺路等级的说明。
在一些实施例中,订单信息可以包括但不限于订单本身信息、用 户信息和其他信息。其中订单本身信息可以包括订单编号、出发地、出发时间、订单时间、出发时间、到达时间、愿意等待时间、里程、搭乘人数、有无行李、价格、付款方式(例如现金支付、刷卡支付、网上支付、汇款支付等)、消费方加价、服务方调价、***调价、红包/优惠券使用情况、订单完成情况、服务方选择订单情况、消费方发送订单情况等中的一个信息或者任意信息的组合。订单的始发地可以由乘客使用其用户终端启动打车软件乘客端来键入或者说出,也可以经由定位***完成。该定位***所采用的技术包括但不限于全球定位***(GPS)技术、全球导航卫星***(GLONASS)技术、北斗导航***技术、伽利略定位***(Galileo)技术、准天顶卫星***(QAZZ)技术、基站定位技术、Wi-Fi定位技术、交通工具自带的各种定位测速***等。在一些实施例中,订单的始发地还可以在适当的情况下经由其他信息来确定。其中,该其他信息可以包括但不限于公交车站、地铁站、特定路口和特定建筑物以及在这些位置处所张贴的二维码信息等。
在步骤1740,可以采用预先建立的抢单率预估模型,根据每一个订单的顺路等级预测用户的订单抢单率。例如,订单抢单率可以由抢单率预测单元342计算。一个订单的顺路等级可以由订单顺路等级确定单元333来确定。
在步骤1750,可以根据订单抢单率确定是否向用户分配筛选出的该订单。例如,订单分配单元361可以根据抢单率预测单元342预测的订单抢单率确定是否向用户分配筛选出的该订单。
在一些实施例中,步骤1750具体可以包括判断该抢单概率是否大于预设阈值,当大于预设阈值时,确定该订单符合订单分配的条件,并向该用户分配筛选出的订单。
在一些实施例中,当筛选出的订单中存在多个符合订单分配条件的订单时,还可以包括按照订单抢单概率从大到小的顺序,向该用户分配符合订单分配条件的订单。
在一些实施例中,订单分配的方法还可以包括获取用户在于定时 间段内的历史订单数据,将该历史订单数据作为训练数据,采用线性回归模型对该训练数据进行训练,得到抢单概率预测模型。在一些实施例中,历史订单数据中包括每一历史订单对应用户的顺路等级特征。
在一些实施例中,线性回归模型可以是逻辑斯特回归模型和支持向量机模型中的一种。关于逻辑斯特回归模型的相关描述,可参见本申请中相应***实施例中的描述。
在一些实施例中,获取抢单概率预测模型之后,还可以包括根据线上实时获取的订单数据,采用机器学习算法,对该抢单概率预测模型进行优化。在一些实施例中,实时获取的订单数据中可以包括该订单对应该终端的顺路等级特征。
在一些实施例中,订单抢单概率预估可以分成离线训练和线上实时计算两个阶段。对于离线训练阶段,可以将播单时的订单相关特征、司机相关特征、订单和司机相关特征等各种特征抽取成预测变量,将司机是否抢单作为目标变量,利用播单和抢单的历史数据进行模型训练,得到抢单概率预测模型。对于线上实时计算阶段,可以将模型运用于线上,对实时抽取出来的订单对应该用户的顺路等级进行计算,采用机器学习算法,对该预先建立的预测模型进行优化。关于机器学习算法的相关描述,可参见本申请中其他部分关于机器学习算法的说明。
需要注意的是,图17所描述的订单分配方法仅为理解申请方便,并不能把本申请限制在所举实施例的范围内。可以理解,对于本领域的技术人员来说,在了解该方法的原理后,可能在不背离这一原理的情况下,对各个步骤进行任意组合,或者对实施上述方法的应用领域形式和细节上的各种修正和改变。例如,步骤1710可以省略,即用户对应的订单匹配条件可以是默认条件,而无需用户上传或者设定。又例如,订单接收者的抢单率可以通过决策树模型训练。这些修正和改变都在本申请的保护范围之内。
根据本申请中的一些实施例,图18提供了订单分配***110的 一种示意图。如图18,订单分配***110可以包括一个或多个接口模块230/240和一个或多个处理模块210。其中,接口模块230/240可以进一步包括一个或多个接收单元231和一个或多个发送单元232。处理模块210可以进一步包括一个或多个订单生成单元311,一个或多个用户终端筛选单元323,一个或多个确定模块330,一个或多个抢单率预测单元342和一个或多个订单分配单元361。其中,确定模块330可以进一步包括一个或多个播单半径确定单元331和一个或多个距离确定单元334。关于接口模块230/240、接收单元231和发送单元232的相关描述可参见本申请其他任意部分的相关说明。
在一些实施例中,订单生成单元311可以用于在接收用户终端的打车请求时,根据该打车请求生成订单。
在一些实施例中,用户终端筛选单元323可以用于根据订单的出发地,获取该订单的播单范围内的至少一个用户终端。
在一些实施例中,播单半径确定单元331可以用于获取预设区域内的第一预设时间段内的历史订单数据,然后根据历史订单数据及当前订单的时间信息确定当前订单的播单范围。在一些实施例中,可以以出发地为基准,将在预设时间段内订单抢单概率大于预设阈值的范围定义成当前订单的播单范围。
在一些实施例中,距离确定单元334可以用于针对获取的每一个用户终端,确定该终端当前位置与该订单的出发地的距离。
在一些实施例中,抢单率预测单元342可以用于采用预先建立的抢单概率预估模型,根据该距离及当前的时间信息获得该用户终端的抢单概率。
在一些实施例中,订单分配单元361可以用于根据该至少一个用户终端的抢单概率,对该订单进行分配。具体的,当该至少一个用户终端只包含一个终端时,则可以向该终端发送该订单;当该至少一个用户终端包含多个终端时,则可以按照多个终端的抢单概率从大到小的顺序,向该多个终端依次发送该订单。
在一些实施例中,订单分配***110还可以包括一个预估模型建 立单元。预估模型建立单元可以用于将该历史订单数据作为特征数据,采用线性回归模型对该特征数据进行训练,得到抢单概率的预估模型。其中,历史订单数据可以包括每一成交订单的成交距离,成交时间,终端到达订单出发地的耗时,每一应答后取消订单的抢单距离,抢单时间,取消时间和取消订单时终端距离订单出发地的距离等中数据的一种或者几种的任意组合。其中,线性回归模型可以是逻辑斯特回归模型或支持向量机模型中的一种,也可以是其他模型。
在一些实施例中,订单分配***110还可以包括一个模型优化单元。模型优化单元可以用于根据实时获取的订单数据,采用机器学习算法,对抢单概率预估模型进行优化。其中关于机器学习算法的相关描述,可参见本申请中其他部分的说明。
需要注意的是,图18所描述的订单分配***110仅为理解申请方便,并不能把本申请限制在所举实施例的范围内。可以理解,对于本领域的技术人员来说,在了解该***的原理后,可能在不背离这一原理的情况下,对各个模块/单元进行任意组合,或者构成子***与其他模块连接,或者对实施上述***的应用领域形式和细节上的各种修正和改变。例如,确定模块330可以不包含播单半径确定单元,直接采用默认播单半径。又例如,订单分配***110可以对已经存在的订单直接进行筛选分配,而不包含订单生成单元311。诸如此类的修正和改变均在本申请的保护范围之内。
根据本申请中的一些实施例,图19提供了订单分配方法的一种示例性流程图,该方法可以包括如下步骤:
在步骤1910,可以在接收用户终端的打车请求后,根据打车请求生成订单,获取订单的始发地。例如,订单生成单元311可以在接收用户终端的打车请求后,根据打车请求生成订单,获取订单的始发地。
在步骤1920,可以根据该订单的始发地,获取该订单的播单范围内的至少一个用户终端。例如,用户终端筛选单元323可以根据该订单的始发地,获取该订单的播单范围内的至少一个用户终端。在一些实施例中,可以以始发地为基准,将在预设时间段内订单的抢单概率 大于预设阈值的范围设定为当前的播单范围。为方便理解,举个例子:为了增加订单的成交率,可以将预设阈值设置为100%,则预设时间段内(例如昨天)的每个订单在该播单范围内播单被抢单的概率为100%。具体的,根据预设时间段内的订单历史数据确定当前订单在当前时间点的播单范围,根据播单范围(最大播单距离)对终端进行初步筛选,打车***可以只向播单范围内的终端发送该订单信息,对最合适订单的司机进行最佳距离订单匹配。
在步骤1930,可以针对获取的每一终端,确定该终端当前位置与该订单的出发地的距离。例如,距离确定单元334可以针对获取的每一终端,确定该终端当前位置与该订单的出发地的距离。具体的,用户终端可以根据定位技术获得其当前位置并发送至打车***,打车***计算得到终端当前位置和订单出发地之间的距离。在一些实施例中,距离可以是用户终端和订单出发地之间的直线距离,也可以是通过定位***和/或实际道路路情况信息得到的用户终端到达订单出发地的车辆实际行驶距离。
在步骤1940,可以采用预先建立的抢单概率预估模型,根据该距离及当前的时间信息获得该终端的抢单概率。例如,抢单率预测单元342可以采用预先建立的抢单概率预估模型,根据该距离及当前的时间信息获得该终端的抢单概率。在一些实施例中,根据步骤1930获取的距离以及当前的时间信息,可以对该终端对该订单的抢单概率进行预测。在一些实施例中,还可以通过用户出发地与目的地之间的距离、该订单价值、路况信息等对抢单概率进行一步预测。终端对该订单的抢单概率可能受到距离、及当前时间信息等的影响,而当前时间信息可以反应出高峰期或平峰期等特征,例如早上8点至9点为高峰期,其对播单范围及抢单概率肯定会有所影响;而距离越近,抢单概率则相应越高。
在步骤1950,可以根据该至少一个终端的抢单概率,对该订单进行分配。例如,订单分配单元361可以根据该至少一个终端的抢单概率,对该订单进行分配。在一些实施例中,当该至少一个用户终端只 包含一个终端时,则可以向该终端发送该订单;当该至少一个用户终端包含多个终端时,则可以按照多个终端的抢单概率从大到小的顺序,向该多个终端依次发送该订单。
在一些实施例中,步骤1920之前还可以包括如下步骤:
首先,获取预设区域内的第一预设时间段内的历史订单数据。其中,历史订单数据可以包括每一成交订单的成交距离,成交时间,终端达到订单出发地的耗时,每一应答后取消订单的抢单距离,抢单时间,取消时间及取消订单时终端距离订单出发地的距离等数据中的一种或任意几种组合。在一些实施例中,预设区域可以表示地理区域,例如不同城市或同一城市的不同区域。
其次,根据该历史订单数据及当前订单的时间信息,确定当前订单的播单范围。具体的,可以对历史订单数据进行分析,例如按小时、分区域统计历史订单数据,可以得到订单在不同区域不同时段的最大播单距离(播单范围),而进一步根据当前订单的时间信息、出发地信息等,就可以确定当前订单的播单范围。上述两个步骤可以获得不同城市不同时段的最大播单距离。
在一些实施例中,可以不断地对播单范围进行动态的更新,即根据新发起订单是否被抢、抢单距离、抢单时间及抢单区域等相关的特征,对播单范围重新进行预估。如今天接收的订单的播单范围可根据昨天的历史订单数据进行预估。
在一些实施例中,步骤1920之前还可以包括将该历史订单数据作为特征数据,采用线性回归模型对该特征数据进行训练,得到抢单概率预估模型。线性回归模型可以是逻辑斯特回归模型或支持向量机模型中的一种,也可以是其他模型。关于逻辑斯特回归模型的相关描述可3参见本申请其他部分的说明。
在一些实施例中,步骤1920之前还可以包括根据线上实时获取的订单数据,采用机器学习算法,对该抢单概率预估模型进行优化。通过不断添加新发起订单是否被抢相关的特征,不断地提高逻辑斯特回归模型的准确度。其中,抢单概率预估分成离线训练和线上实时计 算两个阶段。离线训练阶段可以将播单时的订单相关特征、终端相关特征、订单和终端相关特征等各种特征抽取成预测变量,将终端是否抢单作为目标变量,利用播单和抢单的历史数据进行模型训练,得到抢单概率预估模型。线上实时计算阶段可以将模型运用于线上,对实时抽取出来的当前订单出发地与终端当前位置的距离进行计算。关于机器学习算法的相关描述可参见本申请其他部分的说明。
需要注意的是,图19所描述的订单分配方法仅为理解申请方便,并不能把本申请限制在所举实施例的范围内。可以理解,对于本领域的技术人员来说,在了解该方法的原理后,可能在不背离这一原理的情况下,对各个步骤进行任意组合,或者对实施上述方法的应用领域形式和细节上的各种修正和改变。例如,播单范围可以随时进行更新。又例如,订单接收者的抢单率可以通过决策树模型训练。这些修正和改变都在本申请的保护范围之内。
根据本申请的一些实施例,图20为订单分配方法的一种示例性流程图。据图所示,在步骤2010,可以向用户发送当前订单。例如,可以由发送单元232(见图3)向用户发送当前订单。关于订单类型以及订单信息等,可以参见本申请的相关描述。在步骤2020,可以获取该用户对于历史订单从接收至抢单的历史抢单时间。例如,可以由用户信息获取单元324(见图3)获取该用户对于历史订单从接收至抢单的历史抢单时间。例如,当存在大量历史订单时,既可以获取所有这些历史订单的历史抢单时间,也可以获取预定期间内的历史订单的历史抢单时间。在步骤2030,可以基于该历史抢单时间,发送该当前订单。例如,可以由确定模块330(见图3)基于该历史抢单时间,发送该当前订单。
在一些实施例中,步骤2030可以进一步包括以下两个步骤:
C01、确定该用户在预定时间没有抢单。例如,可以给该用户设置定时器,以便确定该用户在预定时间内是否抢单,并且如果抢单,则记录该用户对于订单从接收至抢单的历史抢单时间。
C02、基于该历史抢单时间,确定该用户在该预定时间以后的抢 单率。在一些实施例中,该抢单率可以通过以下方式确定:确定该用户针对所有历史订单的抢单次数,确定该用户在该预定时间以后的抢单次数;以及确定该用户在该预定时间以后的抢单率。在另一些实施例中,该抢单率可以通过以下方式确定:基于该历史抢单时间,确定多个抢单时间区间;确定该用户在该历史抢单时间所属的抢单时间区间内的抢单率,其中这一抢单率可以基于该用户针对所有历史订单的抢单次数和该用户在该历史抢单时间所属的抢单时间区间内的抢单次数来确定;以及确定该用户在该预定时间以后的抢单时间区间内的抢单率。
在一些实施例中,可以首先基于该抢单率,确定该当前订单的成交率。例如,该当前订单的成交率可以通过如下公式确定,P成交率=1-(1-P1)×(1-P2)×(1-Pn),其中P成交率是该当前订单的成交率,Pn是用户n在该预定时间以后的抢单率。然后可以基于该成交率,发送该当前订单。例如,可以按照抢单率×(1-成交率)从高到低的顺序来发送包括当前订单的多个当前订单,其可以使得订单的抢单率越高则优先级越高,并且订单的成交率越低则优先级越高,从而综合考虑订单的抢单率和成交率。
为理解申请方便,下面以图21A为例进行说明订单分配的流程,但本申请并不局限在这些实施例中。
在步骤2110,在时刻tn-2开始的第n-2轮分配中,可以将订单呈现或播放给dn-2个用户。需要说明的是,下文中可以用符号Dn-2来表示该dn-2个用户中的一个用户。
在步骤2120,在时刻tn-1开始的第n-1轮分配中,可以将订单呈现或播放给dn-1个用户。需要说明的是,下文中可以用符号Dn-1来表示该dn-1个用户中的一个用户。
在步骤2130,在时刻tn开始的第n轮分配中,若用户Dn-2在从时刻tn-2至时刻tn的预定时间内没有抢单,则基于该用户Dn-2对于历史订单从接收至抢单的历史抢单时间,确定该用户Dn-2在该预定时间以后的抢单率,例如P(用户Dn-2在时刻tn以后抢单)。具体来说,这 一抢单率可以通过如下条件概率公式7来确定。
P(用户Dn-2在时刻tn以后抢单)=P(用户Dn-2在时刻tn-2以后抢单)×P(用户Dn-2在时刻tn以后抢单|用户Dn-2在时刻tn-2以后抢单),(公式7)
其中,P(用户Dn-2在时刻tn-2以后抢单)可以表示该用户Dn-2针对当前订单的抢单率。本领域技术人员能够理解,这一抢单率表示了一种抢单意愿,通常取决于如下多种因素:该当前订单的始发地与该用户Dn-2当前位置之间的距离、该当前订单的始发地与目的地之间的距离、该当前订单的始发地是否在该用户Dn-2当前行驶路线附近等中的一种或多种。
并且其中,P(用户Dn-2在时刻tn以后抢单|用户Dn-2在时刻tn-2以后抢单)表示在该用户Dn-2愿意抢单的情况下,花费比从时刻tn-2至时刻t更长的时间来执行抢单动作的概率。本领域技术人员能够理解,这一概率表示了一种抢单能力,通常取决于如下多种因素:该用户Dn-2花费较长时间来收听该当前订单、该用户Dn-2花费较长时间来决定是否抢单、该用户Dn-2由于驾驶车辆非常谨慎而花费较长时间来执行抢单动作等。
根据本公开的实施例,P(用户Dn-2在时刻tn以后抢单|用户Dn-2在时刻tn-2以后抢单)可以通过如下方式来确定:
方式一
第一,确定用户Dn-2针对所有历史订单的抢单次数。例如,确定该用户Dn-2针对过去一段时间内(例如一周、一个月、一年等)的历史订单的抢单次数。
第二,确定用户Dn-2在该预定时间以后的抢单次数。例如,确定该用户Dn-2在过去一段时间内(例如一周、一个月、一年等)的抢单操作中、在时刻tn以后的抢单次数。
第三,基于这两个抢单次数,确定P(用户Dn-2在时刻tn以后抢单|用户Dn-2在时刻tn-2以后抢单)。例如,P(用户Dn-2在时刻tn以后抢单|用户Dn-2在时刻tn-2以后抢单)可以等于在后的抢单次数与在先 的抢单次数的商。
方式二
第一,确定用户Dn-2在历史抢单时间所属的抢单时间区间内的抢单率。
具体来说,可以确定该用户Dn-2针对所有历史订单的抢单次数,确定该用户Dn-2在该历史抢单时间所属的抢单时间区间内的抢单次数,以及基于这两个抢单次数,确定该用户Dn-2在历史抢单时间所属的抢单时间区间内的抢单率。例如,该用户Dn-2在历史抢单时间所属的抢单时间区间内的抢单率可以等于在后的抢单次数与在先的抢单次数的商。
另外,在一些实施例中,上述概率还可以通过图21B所示的历史抢单时间分布的示意图来确定。在图21B中,针对在时刻tn-2所发布的历史订单,通过后续各时间点处的概率密度曲线来确定相应的抢单时间区间内的抢单率。例如,该用户Dn-2在历史抢单时间tn至tn+1内的抢单率是由该概率密度曲线与横坐标轴围成的图形在该历史抢单时间tn至tn+1内的面积。类似地,该用户Dn-2在历史抢单时间tn+1至tn+2内的抢单率是由该概率密度曲线与横坐标轴围成的图形在该历史抢单时间tn+1至tn+2内的面积。
第二,确定用户Dn-2在预定时间以后的抢单时间区间内的抢单率之和。例如,确定用户Dn-2在历史抢单时间tn至tn+1和历史抢单时间tn+1至tn+2内的抢单率之和,其中这一概率可以是由该概率密度曲线与横坐标轴围成的图形在该历史抢单时间tn至tn+2内的面积。
在步骤2140,在时刻tn开始的第n轮分配中,若用户Dn-1在从时刻tn-1至时刻tn的预定时间内没有抢单,则基于该用户Dn-1对于历史订单从接收至抢单的历史抢单时间,确定该用户Dn-1在该预定时间以后的抢单率,例如P(用户Dn-1在时刻tn以后抢单)。
本领域技术人员可以理解,步骤1240与步骤1230类似,因此不再赘述。同时,本领域技术人员还可以理解,步骤1240与步骤1230之间并不存在严格的执行顺序,例如步骤1240既可以先于步骤1230 执行,也可以与步骤1230同时执行。
在步骤2150,可以基于步骤2130所确定的抢单率和步骤2140所确定的抢单率而确定当前订单的成交率。例如,该成交率可以通过如下的公式8来确定:
P成交率=1-(1-P(用户Dn-2在时刻tn以后抢单))×(1-P(用户Dn-1在时刻tn以后抢单)),   (公式8)
备选地或者附加地,在确定当前订单的成交率之前,还可以判断该步骤1230中所确定的抢单率和步骤1240中所确定的抢单率是否大于预定抢单率阈值,以便避免所确定的抢单率较小的用户对该成交率的影响。其中,抢单率阈值可以是一个数值,也可以是一个区间。
在步骤1260,判断步骤1250中所确定的当前订单的成交率是否大于预定成交率阈值,如果是,则当前订单已经呈现或播放给足够多的用户,因此在第n轮分配中禁止发送该当前订单,并且本方法结束。否则,执行步骤2170。
在步骤2170,基于步骤1250中所确定的成交率从低到高的顺序,发送包括当前订单的多个当前订单,以便在第n轮分配中成交率较低的当前订单能够得到更多地呈现或播放。例如,根据本公开的实施例,可以按照抢单率×(1-成交率)从高到低的顺序来发送包括当前订单的多个当前订单,其可以使得订单的抢单率越高则优先级越高,并且订单的成交率越低则优先级越高,从而在第n轮分配中综合考虑订单的抢单率和成交率。
需要注意的是,以上关于订单分配流程的描述,仅为理解申请方便,并不能把本申请限制在所举实施例范围之内。可以理解,对于本领域的技术人员来说,在了解本申请的基本原理后,可以在不背离这一原理的情况下,对订单分配流程作出改变。例如,图21A中的步骤可以改变执行次序,可以省略某些步骤,可以添加某些步骤,可以将多个步骤合并成一个步骤,和/或将一个步骤分解为多个步骤。例如,步骤2120与步骤2130可以按照任意顺序或者同时执行,可以将步骤2120和步骤2130合并为一个步骤执行。诸如此类的变形,均在本申 请的保护范围之内。
根据本申请的一些实施例,图22提供了订单分配***110的一种示意图。如图22,订单分配***110可以包括一个或多个订单接口模块230/240和一个或多个处理模块210。其中接口模块230/240可以进一步包括一个或多个接收单元231和一个或多个发送单元232。处理模块210可以进一步包括一个或多个订阅概率计算单元341和一个或多个分析模块350。分析模块350又可以进一步包括一个或多个比较单元351和一个或多个判断单元352。
在一些实施例中,接收单元231可以用于接收用户终端发送的打车请求。
在一些实施例中,发送单元232可以用于根据接收单元231获取的打车请求生成订单信息,将该订单信息发送给第一终端。具体的,可以根据订单分配策略将该订单信息发送给第一终端。其中订单信息中可以包含出发地设置预设范围,可以根据该预设范围将该订单信息发送给预设范围内的任一终端。
在一些实施例中,订阅概率计算单元341可以用于根据该第一终端的初始抢单率和抢单衰减特性,获取该订单信息被订阅的概率。其中,第一终端的初始抢单率可以是根据该订单信息生成的初始抢单率。第一终端的抢单衰减特性可以是预先根据该第一终端的订单历史数据获取的。具体的,订阅概率计算单元341可以用于根据订单信息中的用户终端的出发地,目的地,用户表示,订单生成时间以及第一终端的位置信息等信息中的一种或任意几种的组合,生成第一终端的初始抢单率s(t0);查找预先建立的第一终端的抢单衰减特性f0(t),可以采用如下公式9获取订单信息被订阅的概率Psr:
Psr=1-(1-s(t0)f0(t))*...*(1-s(tn)fn(t)),   (公式9)
其中,s(tn)可以表示第N+1个终端的初始抢单率,n可以为大于等于0的正整数,fn(t)可以表示第N+1终端的抢单衰减特性。在一些实施例中,f0(0)、...、fn(0)可以均设为1。
为便于理解,举个例子说明订阅概率计算公式。若某一个订单信 息在t0时刻发送给第一终端,在t1时刻发送给第二终端,早tn时刻发送给第N+1终端,则可以基于上述N+1个终端的初始抢单率和抢单衰减特性,计算在t(n+1)时刻该订单被订阅的概率,准确地预测订单播单历史对订单订阅概率的影响。
在一些实施例中,比较单元351可以用于将该订阅概率与预设阈值进行比较,获得比较结果。
在一些实施例中,判断单元352可以用于根据比较结果,确定是否向第N终端发送该订单信息;其中,N为正整数,且N大于等于2,且第一终端至第N终端均可以为用于为该用户终端提供运营服务的终端。
在一些实施例中,当该订阅概率小于该预设阈值时,判断单元352可以将订单信息发送至第N终端。判断单元352还可以用于获取第N终端的初始抢单率和抢单衰减特性。其中,该第N终端的初始抢单率可以为根据该订单信息生成的初始抢单率,该第N终端的抢单衰减特性可以为预先根据该第N终端的订单历史数据获取的。根据发送该订单信息的所有终端的初始抢单率和抢单衰减特性,可以获取该订单信息被订阅的订阅概率;将该订阅概率与预设阈值进行比较。
在一些实施例中,订单分配***110还可以包括一个预设单元,可以用于根据每一终端的订单历史数据建立该终端的抢单衰减特性。具体的,预设单元可以针对每个终端,可以获取该终端对应的多个订单的播单时间信息和抢单时间信息的历史数据。其中播单时间信息可以是订单信息播送给该终端的时间点,抢单时间信息可以是该终端订阅该订单信息的时间点。根据该历史数据,可以获取该终端的抢单衰减特性。
在一些实施例中,预设单元还可以用于分析历史数据中每一订单信息对应的播单时间信息与抢单时间信息的差值,确定该终端的抢单概率随时间衰减的特性,获得该终端的抢单衰减特性。
在一些实施例中,订单分配***110还可以包括一个消冗单元。消冗单元可以用于去除该历史数据中的冗余数据。其中冗余数据可以 包括将相同订单信息播送给相同终端有多个播单时间信息的数据,及相同终端订阅相同订单信息有多个抢单时间信息的数据。具体的,当相同订单信息播送给相同终端有多个播单时间信息时,保留多个播单时间信息中的最晚一个播单时间信息。当相同终端订阅相同订单信息有多个抢单时间信息时,保留多个抢单时间信息中的最早一个抢单时间信息。
需要注意的是,图22所描述的订单分配***110仅为理解申请方便,并不能把本申请限制在所举实施例的范围内。可以理解,对于本领域的技术人员来说,在了解该***的原理后,可能在不背离这一原理的情况下,对各个模块/单元进行任意组合,或者构成子***与其他模块连接,或者对实施上述***的应用领域形式和细节上的各种修正和改变。例如,比较单元351和判断单元352可以合并为一个分析单元,可以用于比较并且判断订阅概率。又例如,订单分配***110可以对已经存在的订单直接进行筛选分配,而不包含订单接收单元231。诸如此类的修正和改变均在本申请的保护范围之内。
根据本申请中的一些实施例,图23提供了订单分配方法的一种示例性流程图,该方法可以包括如下步骤:
在步骤2310,用于根据打车请求生成订单信息,将该订单信息发送给第一终端。例如,发送单元232可以用于根据接收单元231获取的打车请求生成订单信息,将该订单信息发送给第一终端。具体的,可以根据订单分配策略将该订单信息发送给第一终端。其中订单信息中可以包含出发地设置预设范围,可以根据该预设范围将该订单信息发送给预设范围内的任一终端。
在步骤2320,可以根据第一终端的初始抢单率和抢单衰减特性,计算获取订单信息被订阅的订阅概率。例如,订阅概率计算单元341可以根据第一终端的初始抢单率和抢单衰减特性,计算获取订单信息被订阅的订阅概率。其中,第一终端的初始抢单率可以是根据该订单信息生成的初始抢单率。第一终端的抢单衰减特性可以是预先根据该第一终端的订单历史数据获取的。具体的,订阅概率计算单元341可 以用于根据订单信息中的用户终端的出发地,目的地,用户表示,订单生成时间以及第一终端的位置信息等信息中的一种或任意几种的组合,生成第一终端的初始抢单率s(t0);查找预先建立的第一终端的抢单衰减特性f0(t),采用订阅概率计算公式获取订单信息被订阅的概率Psr。关于订阅概率计算的相关描述可参见本申请中相应的***实施例部分的相关说明。
在步骤2330,可以通过比较订阅概率与预设阈值,获得比较结果。例如,比较单元351可以通过比较订阅概率与预设阈值,获得比较结果。其中,预设阈值可以根据所需的订单概率设置。举个例子,如果所需订阅概率为95%,则将预设阈值设置为95%;如果当前的订阅概率大于等于95%,则停止向其他终端发送该订单信息;如果当前的订阅概率小于95%,则继续向其他终端发送该订单信息。
在步骤2340,可以根据比较结果判定是否向第N终端发送订单信息。例如,判断单元352可以根据步骤2330获取的比较结果判定是否向第N终端发送订单信息。其中,N为正整数,且N大于等于2,且第一终端至第N终端均可以为用于为该用户终端提供运营服务的终端。具体的,当该订阅概率小于预设阈值,可以继续向另一终端发送该订单信息;当该订阅概率大于等于预设阈值,可以停止发送该订单信息。
在一些实施例中,步骤2340还可以包括如下步骤:当该订阅概率小于该预设阈值时,可以将订单信息发送至第N终端;获取第N终端的初始抢单率和抢单衰减特性;根据发送该订单信息的所有终端的初始抢单率和抢单衰减特性,可以获取该订单信息被订阅的订阅概率;将该订阅概率与预设阈值进行比较。其中,第N终端的初始抢单率可以为根据该订单信息生成的初始抢单率,第N终端的抢单衰减特性可以为预先根据第N终端的订单历史数据获取的。如果该订阅概率仍然小于预设阈值,可以继续向其他终端发送上述订单信息,直至该订单信息的累积订阅概率达到预设阈值。
在一些实施例中,在步骤2310之前还可以包括接收用户终端发 送的打车请求。
在一些实施例中,在步骤2310之前还可以包括根据每一终端的订单历史数据建立该终端的抢单衰减特性。具体的,可以包括如下步骤:针对每一终端,可以获取该终端对应的多个订单的播单时间信息和抢单时间信息的历史数据;根据历史数据,可以获取该终端的抢单衰减特性。其中,播单时间信息可以是订单信息播送给该终端的时间点,抢单时间信息可以是该终端订阅该订单信息的时间点。在一些实施例中,建立每个终端的抢单衰减特性可以在每个终端抢单历史充分的优选情况下。如果抢单历史数据不足,可分城市分订单类型,以用户终端ID为键值,计算得到每个城市终端订阅订单信息的时间衰减曲线。利用该曲线替代且终端的抢单衰减特性,进一步根据该衰减曲线来计算订阅概率。其中,订单类型可以是预约订单,即时订单等。
在一些实施例中,当历史数据中存在冗余数据时,还可以包括去除历史数据中的冗余数据。其中冗余数据可以包括将相同订单信息发送给相同终端有多个播单时间信息的数据,相同终端订阅相同订单信息有多个抢单事件信息的数据等。具体的,当相同订单信息发送给相同终端有多个播单时间信息时,可以保留其中最晚的一个播单时间信息;当相同终端订阅相同订单信息有多个抢单事件信息时,保留详单时间中最早的抢单时间。
在一些实施例中,去除历史数据中冗余信息之后还可以包括根据去除冗余数据的历史数据,获取该终端的抢单衰减特性。具体的,可以分析历史数据中每一订单信息对应的播单时间信息与抢单时间信息的差值,确定该终端的抢单概率随时间衰减的特性,获得该终端的抢单衰减特性。
根据本申请中的一些实施例,图24提供了订单分配方法的另一种示例性流程图,该方法可以包括如下步骤:
在步骤2410和2420,可以根据打车请求生成订单信息。例如,接收单元231可以接收用户终端发送的打车请求,并根据打车请求生成订单信息。
在步骤2430,可以将该订单信息发送至第M终端。例如,发送单元232可以将该订单信息发送至第M终端。其中,M可以为大于等于1的正整数。
在步骤2440,可以获取第M终端的初始抢单率和抢单衰减特性。关于初始抢单率和抢单衰减特性的相关描述可参见本申请其他部分的相关说明。
在步骤2450,可以根据发送订单信息的所有终端的初始抢单率和抢单衰减特性,计算获得该订单信息被订阅的订阅概率。例如,订阅概率计算单元341可以根据发送订单信息的所有终端的初始抢单率和抢单衰减特性,计算获得该订单信息被订阅的订阅概率。关于订阅概率预测的相关描述可参见本申请其他部分的相关说明。
在步骤2460,可以比较订阅概率与预设阈值的大小。例如,比较单元351可以比较订阅概率与预设阈值的大小。如果订阅概率小于预设阈值成立,则执行M=M+1,继续执行步骤2430;如果订阅概率小于预设阈值不成立,则执行步骤2470,停止发送该订单信息。
需要注意的是,图23和图24所描述的订单分配方法仅为理解申请方便,并不能把本申请限制在所举实施例的范围内。可以理解,对于本领域的技术人员来说,在了解该方法的原理后,可能在不背离这一原理的情况下,对各个步骤进行任意组合,或者对实施上述方法的应用领域形式和细节上的各种修正和改变。例如,预设阈值可以随时进行手动更新,也可以根据***反馈信息自动更新。又例如,历史数据也可以随时进行更新替换。这些修正和改变都在本申请的保护范围之内。
根据本申请的一些实施例,图25提供了订单分配***110的一种示意图。如图25,订单分配***110可以包括一个或多个订单接口模块230/240和一个或多个处理模块210。其中接口模块230/240可以进一步包括一个或多个接收单元231和一个或多个发送单元232。处理模块210可以进一步包括一个或多个抢单率预测单元342和一个或多个确定模块330。确定模块330又可以进一步包括一个或多个实 际抢单率确定单元2510和一个或多个准确度确定单元2520。关于接口模块230/240、接收单元231和发送单元232的相关描述可参见本申请其他任意部分的相关说明。
在一些实施例中,抢单率预测单元342可以用于预测用户针对订单执行抢单操作的概率。实际抢单率确定单元2510可以用于确定用户针对订单实际执行抢单操作的概率。准确度确定单元2520可以用于基于所预测的概率与确定的概率,确定预测的准确度。
在一些实施例中,抢单率预测单元342可以包括一个提取单元和一个预测单元。其中,提取单元可用于提取订单中的特征。预测单元可以用于根据与该特征对应的预测权重,预测用户针对该订单而执行操作的概率。
在一些实施例中,实际抢单率确定单元2510可以包括第一确定单元,第二确定单元和第三确定单元。其中,第一确定单元可以用于确定用户针对订单而实际执行抢单操作的抢单次数;第二确定单元可以用于确定该订单被发布给该用户的发布次数;第三确定单元可以用于根据抢单次数和发布次数确定该用户针对该订单而实际执行抢单操作的概率。
在一些实施例中,准确度确定单元2520可以包括第四确定单元。第四确定单元可以用于将预测的概率与确定大概率之间的相对偏差确定为预测的准确度。
在一些实施例中,实际抢单率确定单元2510还可以包括第五确定单元,第六确定单元和第七确定单元。其中,第五确定单元可以用于确定用户分别针对多个订单实际执行抢单操作的抢单次数;第六单元可以用于确定多个订单被发布给用户的发布次数;第七确定单元可以用于根据抢单次数和发布次数确定针对该多个订单实际执行抢单操作的概率。
在一些实施例中,准确度确定单元2520还可以包括第八确定单元和第九确定单元。其中,第八确定单元可以用于确定与多个订单分别对应的多个预测概率的平均值;第九确定单元可以用于将平均值与 确定的概率之间的相对偏差确定为预测的准确度。
在一些实施例中,实际抢单率确定单元2510可以包括排序单元,第一划分单元和第一获取单元。其中,排序单元可以用于按照预测的概率从小到大的顺序将订单进行排序;第一划分单元可以用于将排序后的订单划分为多个订单分组;第一获取单元可以用于从其中一个订单分组中获取该组中的多个订单。
在一些实施例中,准确度确定单元2520可以包括第十确定单元和第十一确定单元。其中,第十确定单元可以用于针对多个订单分组中的每个分组分别确定相应的预测概率,以及预测概率与相应确定概率之间的相对偏差;第十一确定单元可以用于将相对偏差的平均值确定为该预测的准确度。
在一些实施例中,准确度确定单元2520可以包括第十二确定单元和第十三确定单元。其中,第十二确定单元可以用于针对多个订单分组中的每个分组分别确定相应的预测的概率与确定概率之间的相对偏差;第十三确定单元可以用于将相对偏差的均方根值确定为预测的准确度。
在一些实施例中,实际抢单率确定单元2510可以包括第二排序单元,第二划分单元和第十四确定单元。其中,第二排序单元可以用于将发布给每个用户的播单,按照预测每个用户针对播单的执行抢单操作的概率从小到大的顺序进行排序;第二划分单元可以用于将经过排序的播单划分为多个播单分组;第十四确定单元可以用于基于多个播单分组中的每个播单分组,确定相应的用户对播单分组中的实际执行抢单操作的概率。
在一些实施例中,准确度确定单元2520可以包括第十五确定单元和第十六确定单元。其中,第十五确定单元可以用于针对每个播单分组分别确定相应的预测概率和确定概率之间的相对偏差;第十六确定单元可以用于将相对偏差的平均值确定为预测的准确度。
在一些实施例中,准确度确定单元2520可以包括第十七确定单元和第十八确定单元。其中,第十七确定单元可以用于针对每个播单 分组分别确定相应的预测概率与确定概率之间的相对偏差;第十八确定单元可以用于将相对偏差的均方根值确定为预测的准确度。
需要注意的是,图25所描述的订单分配***110仅为理解申请方便,并不能把本申请限制在所举实施例的范围内。可以理解,对于本领域的技术人员来说,在了解该***的原理后,可能在不背离这一原理的情况下,对各个模块/单元进行任意组合,或者构成子***与其他模块连接,或者对实施上述***的应用领域形式和细节上的各种修正和改变。例如,所有实际抢单率和精确度的确定可以在一个模块中进行。又例如,十八个确定单元并非表示一定有十八个,一个确定单元可合并执行多个确定任务,一个确定任务也可以分给多个确定单元完成。诸如此类的修正和改变均在本申请的保护范围之内。
根据本申请中的一些实施例,图26提供了订单分配方法的一种示例性流程图,该方法可以包括如下步骤:
在步骤2610,可以预测用户针对订单执行抢单操作的概率。例如,抢单概率预测单元342可以预测用户针对订单执行抢单操作的概率。在一些实施例中,抢单操作的概率可以通过提取订单中特征以及与特征相对应的预定权重来预测。其中,根据预定的预测方法,订单中的特征可以被分配有不同的权重。权重可以基于机器学习模型,使用历史订单中相应的特征来确定。为便于理解,下面对预测过程距离说明。例如,如果根据机器学习模型,历史订单的始发地和用户的距离被确定为与该历史订单被执行抢单操作的关联度较大,则可以将订单中表示始发地和用户距离的特征分配较大的权重。
在步骤2620,可以确定用户针对订单实际执行抢单操作的概率。例如,实际抢单率确定单元2510可以确定用户针对订单实际执行抢单操作的概率。在一些实施例中,在将一个订单发布给周围预定范围内的用户的过程中,可以分别确定该订单被发布给该用户的发布次数,然后根据抢单次数和发布次数以及实际中执行抢单操作的次数,确定该用户针对该订单实际执行抢单操作的概率。为方便理解,以该订单被发布给周围预定范围内有100名用户为例进行说明。如果订单 被发布给这100名用户,则发布次数为100。同时,如果100名用户中的5名用户实际执行抢单操作,则抢单次数是5。因此,该用户针对该订单的实际执行抢单操作的概率可以等于抢单次数与发布次数的比,即5%。
在步骤2630,可以基于预测的概率和确定的概率,确定预测的准确度。例如,准确度确定单元2520可以基于预测的概率和确定的概率,确定预测的准确度。具体的,可以将预测概率与确定概率之间的相对偏差确定为预测的准确度。为方便理解,以预测概率6%和确定概率5%为例进行说明。预测的准确度可以根据如下公式10进行计算:
PB=|A-R|/R,   (公式10)
其中,PB可以表示预测概率与确定概率之间的相对偏差,即表示预测准确度。A可以表示预测概率,R可以表示确定概率。
因此,通过上述公式计算预测的准确度可以等于|6%-5%|/5%=0.2。
在一些实施例中,在将多个订单发布给周围预定范围内的用户的过程中,可以分别确定多个订单被发送给多个用户的发布次数和该多个订单实际被执行抢单操作的抢单次数。然后根据抢单次数和发布次数确定实际执行操作的概率。以100个订单被发布给周围100名用户为例,该100个订单的发布次数为10000。同时,针对这100个订单中的每个订单都存在赛100名用户中的5名用户实际执行抢单操作,则抢单次数为500。因此,实际执行抢单操作的概率可以等于抢单次数与发布次数的比值,即5%。
在一些实施例中,多个订单可以作为一个整体来统计发布次数和抢单次数,并根据发布次数和抢单次数确定实际执行抢单操作的概率。
在一些实施例中,还可以根据其他用来确定实际抢单操作概率的方式来确定。例如,分别确定该用户针对多个订单中每个订单的实际抢单概率并确定这些概率的平均值。针对100个订单发送给100名用户,如果其中50个订单的预测概率是6%,30个订单的预测概率是 5.66%,另外20个订单的预测概率是5%,则这100个订单对应的多个预测概率的平均值是(50×6%+30×5.66%+20×5%)/100=5.7%。可以根据预测概率(例如5.7%)与所确定的概率(例如5%)之间的相对偏差确定为该预测的准确度。根据公式10即可计算预测的准确读为0.14。
根据本申请中的一些实施例,图27提供了订单分配方法的一种示例性流程图,该方法以N个订单为例进行说明,可以包括如下步骤:
在步骤2710,可以预测用户分别针对该N个订单中的每个订单而执行抢单操作的概率。例如,抢单率预测单元342可以预测用户分别针对该N个订单中的每个订单而执行抢单操作的概率。关于该预测步骤的相关描述可参见步骤2610中的相关说明。
在步骤2720,按照所预测的概率从小到大的顺序将N个订单进行排序,将经排序的该N个订单划分为多个订单分组。其中,在每个分组中可以具有较大数量的订单,例如k个。因此,分组结果可以如下:
分组1:P1,P2,P3......Pk
分组2:Pk+1,Pk+2,Pk+3......P2k
……
分组i:P(i-1)k+1,P(i-1)k+2,P(i-1)k+3......Pik
其中,P表示预测用户针对相应订单执行抢单操作的概率。
在步骤2730,以第n个订单分组整体为例,通过如下公式11预测用户针对第n个订单分组中的所有订单而执行抢单操作的概率:
Figure PCTCN2016072840-appb-000006
   (公式11)
通过如下公式12确定用户针对该第i个订单分组中的所有订单而实际执行抢单操作的概率:
Ri=Qi/Bi   (公式12)
其中Ai表示预测用户针对第i个订单分组中订单的执行抢单操作的概率,Ri表示确定用户针对该第i个订单分组中订单的执行抢单操 作的概率,Qi表示用户针对该第i个订单分组中的订单而实际执行抢单操作的抢单次数,Bi表示该第i个订单分组中的订单被发布给该用户的发布次数。
在步骤2740,可以确定预测的准确度。例如,准确度确定单元2520可以根据如下公式13确定概率偏差的平均值作为预测的准确度:
Figure PCTCN2016072840-appb-000007
   (公式13)
其中,APB可以表示概率偏差的平均值,进而表示预测的准确度。Ai可以表示预测的用户针对第i个订单分组中的订单而执行抢单操作的概率;而可以表示所确定的用户针对该第i个订单分组中的订单而实际执行抢单操作的概率,n可以表示上述订单分组的分组数目。
在一些实施例中,预测的准确度还可以通过概率偏差的均方根值来确定,公式如下:
Figure PCTCN2016072840-appb-000008
   (公式14)
其中相应符号表示的意义可参见上述公式中的相关说明。
需要注意的是,图26和图27所描述的订单分配方法仅为理解申请方便,并不能把本申请限制在所举实施例的范围内。可以理解,对于本领域的技术人员来说,在了解该方法的原理后,可能在不背离这一原理的情况下,对各个步骤进行任意组合,或者对实施上述方法的应用领域形式和细节上的各种修正和改变。例如,可以按照从大到小的顺序将订单进行排序,可也不对订单进行排序操作。又例如,准确的计算公式并不限于上述描述的几种,本领域的技术人员可根据实际需求对公式做出改变和调整。这些修正和改变都在本申请的保护范围之内。
图28描述了一种移动设备的结构示意图,该移动设备能够用于实现实施本申请中披露的特定***。在本实施例中,用于显示和交互位置相关信息的用户设备是一个移动设备2800,包括但不限于智能手 机、平板电脑、音乐播放器、便携游戏机、全球定位***(GPS)接收器、可穿戴计算设备(例如眼镜、手表等),或者其他形式,可参看本申请其他处的相关描述。本例中的移动设备2800包括一个或多个中央处理器(CPUs)2840,一个或多个图形处理器(Graphical Processing Units(GPUs))2830,一个显示2820,一个内存2860,一个天线2810(例如一个无线通信单元),存储单元2890,以及一个或多个输入/输出(Input Output(I/O))设备2850。任何其他合适的组件,例如***总线或控制器(图上未显示),也可能被包括在移动设备2800中。如图28所示,一个移动操作***2870,例如iOS、Android、Windows Phone等,以及一个或多个应用2880可以从存储单元2890加载进内存2860中,并被中央处理器2840所执行。应用2880可能包括一个浏览器或其他适合在移动设备2800上接收并处理订单信息的移动应用。用户关于订单信息的交互可以通过输入/输出***设备2850获得并提供给订单分配***110,和/或***100的其他组件,例如:通过网络150。
为了实现不同的模块、单元以及在之前的披露中所描述的他们的功能,计算机硬件平台可以被用作以上描述的一个或多个元素的硬件平台(例如:订单分配***110,和/或图1-27中描述的***100的其他组件)。这类计算机的硬件元素、操作***和程序语言在自然界中是常见的,可以假定本领域技术人员对这些技术都足够熟悉,能够利用这里描述的技术提供按需服务所需要的信息。一台包含用户界面元素的计算机能够被用作个人计算机(Personal Computer(PC))或其他类型的工作站或终端设备,被适当程序化后也可以作为服务器使用。可以认为本领域技术人员对这样的结构、程序以及这类计算机设备的一般操作都是熟悉的,因此所有附图也都不需要额外的解释。
图29描述了一种计算机设备的架构,这种计算机设备能够被用于实现实施本申请中披露的特定***。本实施例中的特定***利用功能框图解释了一个包含用户界面的硬件平台。这种计算机可以是一个通用目的的计算机,也可以是一个有特定目的的计算机。两种计算机 都可以被用于实现本实施例中的特定***。计算机2900可以用于实施当前订单分配的任何单元。例如:订单分配***110能够被如计算机2900的计算机通过其硬件设备、软件程序、固件以及他们的组合所实现。为了方便起见,图29中只绘制了一台计算机,但是本实施例所描述的提供按需服务所需要的信息的相关计算机功能是可以以分布的方式、由一组相似的平台所实施的,分散***的处理负荷。
计算机2900包括通信端口2950,与之相连的是实现数据通信的网络。计算机2900还包括一个中央处理***(CPU)单元用于执行程序指令,由一个或多个处理器组成。示例的计算机平台包括一个内部通信总线2910,不同形式的程序储存单元以及数据储存单元,例如硬盘2970,只读存储器(ROM)2930,随机存取存储器(RAM)2940,能够用于计算机处理和/或通信使用的各种数据文件,以及CPU所执行的可能的程序指令。计算机2900还包括一个输入/输出组件2960,支持计算机与其他组件(例如用户界面2980)之间的输入/输出数据流。计算机2900也可以通过通信网络接受程序及数据。
以上概述了订单分配的方法的不同方面和/或通过程序实现其他步骤的方法。技术中的程序部分可以被认为是以可执行的代码和/或相关数据的形式而存在的“产品”或“制品”,是通过计算机可读的介质所参与或实现的。有形的、永久的储存介质包括任何计算机、处理器、或类似设备或相关的模块所用到的内存或存储器。例如各种半导体存储器、磁带驱动器、磁盘驱动器或者类似任何时间能够为软件提供存储功能的设备。
所有软件或其中的一部分有时可能会通过网络进行通信,例如互联网或其他通信网络。此类通信能够将软件从一个计算机设备或处理器加载到另一个。例如:从按需服务***的一个管理服务器或主机计算机加载至一个计算机环境的硬件平台,或其他实现***的计算机环境,或与提供按需服务所需要的信息相关的类似功能的***。因此,另一种能够传递软件元素的介质也可以被用作局部设备之间的物理连接,例如光波、电波、电磁波等,通过电缆、光缆或者空气实现传 播。用来载波的物理介质如电缆、无线连接或光缆等类似设备,也可以被认为是承载软件的介质。在这里的用法除非限制了有形的“储存”介质,其他表示计算机或机器“可读介质”的术语都表示在处理器执行任何指令的过程中参与的介质。
一个计算机可读的介质可能有多种形式,包括但不限于有形的存储介质,载波介质或物理传输介质。稳定的储存介质包括:光盘或磁盘,以及其他计算机或类似设备中使用的,能够实现图中所描述的***组件的存储***。不稳定的存储介质包括动态内存,例如计算机平台的主内存。有形的传输介质包括同轴电缆、铜电缆以及光纤,包括计算机***内部形成总线的线路。载波传输介质可以传递电信号、电磁信号,声波信号或光波信号,这些信号可以由无线电频率或红外数据通信的方法所产生的。通常的计算机可读介质包括硬盘、软盘、磁带、任何其他磁性介质;CD-ROM、DVD、DVD-ROM、任何其他光学介质;穿孔卡、任何其他包含小孔模式的物理存储介质;RAM、PROM、EPROM、FLASH-EPROM,任何其他存储器片或磁带;传输数据或指令的载波、电缆或传输载波的连接装置、任何其他可以利用计算机读取的程序代码和/或数据。这些计算机可读介质的形式中,会有很多种出现在处理器在执行指令、传递一个或更多结果的过程之中。
本领域技术人员能够理解,本申请所披露的内容可以出现多种变型和改进。例如,以上所描述的不同***组件都是通过硬件设备所实现的,但是也可能只通过软件的解决方案得以实现。例如:在现有的服务器上安装***。此外,这里所披露的位置信息的提供可能是通过一个固件、固件/软件的组合、固件/硬件的组合或硬件/固件/软件的组合得以实现。
以上内容描述了本申请和/或一些实施例。根据上述内容,本申请还可以作出不同的变形。本申请披露的主题能够以不同的形式和例子所实现,并且本申请可以被应用于大量的应用程序中。后文权利要求中所要求保护的所有应用、修饰以及改变都属于本申请的范围。

Claims (20)

  1. 一种订单分配***,包括:
    一种计算机可读的存储媒介,被配置为存储可执行模块,包括:
    接收单元,被配置为接收订单信息与用户信息,所述用户信息包括位置信息或时间信息;
    订单分配单元,被配置为基于所述位置信息或时间信息,进行订单分配。
    一个处理器,所述处理器能够执行所述计算机可读的存储媒介存储的可执行模块。
  2. 根据权利要求1所述的***,其特征在于,所述位置信息为出发地、始发地、目的地、坐标信息、地域范围中的一种或几种。
  3. 根据权利要求1所述的***,其特征在于,所述时间信息为订单播单时间、用户抢单时间中的一种或两种。
  4. 根据权利要求2所述的***,其特征在于,所述订单分配***进一步包括:
    播单范围确定模块,被配置为获取订单播送区域或订单接收范围;
    订单数目获取单元,被配置为获取播单范围内的订单数目;以及订单密度获取单元,被配置为基于所述订单播送区域或订单接收范围,以及订单数目,得到订单密度。
  5. 根据权利要求1所述的***,其特征在于,所述订单分配***进一步包括:
    抢单率预测单元,被配置为基于所述位置信息或时间信息,预测用户抢单率。
  6. 根据权利要求5所述的***,其特征在于,所述订单分配***进一步包括:
    距离确定单元,被配置为获取用户位置与订单出发地的距离或路面距离;以及
    抢单率预测单元,被配置为基于所述距离或路面距离,预测用 户抢单率。
  7. 根据权利要求5所述的***,其特征在于,所述订单分配***进一步包括:
    获取单元,被配置为获取订单的历史播单时间或用户的历史抢单时间;以及
    订阅概率计算单元,被配置为基于所述历史播单时间或历史抢单时间,预测用户抢单率。
  8. 根据权利要求5所述的***,其特征在于,所述抢单率预测单元进一步被配置为基于所述位置信息或时间信息,建立用户抢单率预测模型。
  9. 根据权利要求5所述的***,其特征在于,所述订单分配***进一步包括:
    准确度确定单元,被配置为确定所述抢单率预测的准确度。
  10. 根据权利要求9所述的***,其特征在于,所述订单分配***进一步包括:
    实际抢单率确定单元,被配置为确定所述用户针对所述订单实际的抢单率;以及
    准确度确定单元,被配置为基于所述用户的预测抢单率与实际抢单率,确定所述抢单率预测的准确度。
  11. 一种订单分配方法,包括:
    接收订单信息与用户信息,所述订单信息与用户信息包括位置信息或时间信息;
    基于所述位置信息或时间信息,进行订单分配。
  12. 根据权利要求11所述的方法,其特征在于,所述位置信息为出发地、始发地、目的地、坐标信息、地域范围中的一种或几种。
  13. 根据权利要求11所述的方法,其特征在于,所述时间信息为订单播单时间、用户抢单时间中的一种或两种。
  14. 根据权利要求12所述的方法,其特征在于,所述基于位置信息进行订单分配进一步包括:
    获取订单播送区域或订单接收范围,以及订单数目;
    基于所述订单播送区域或订单接收范围,以及订单数目,得到订单密度;以及
    基于所述订单密度,进行订单分配。
  15. 根据权利要求11所述的方法,其特征在于,所述基于位置信息或时间信息进行订单分配进一步包括:
    基于所述位置信息或时间信息,预测用户抢单率;以及
    基于所述用户抢单率,进行订单分配。
  16. 根据权利要求15所述的方法,其特征在于,所述根据位置信息预测用户抢单率进一步包括:
    获取用户位置与订单出发地的距离或路面距离;以及
    基于所述距离或路面距离,预测用户抢单率。
  17. 根据权利要求15所述的方法,其特征在于,所述根据时间信息预测用户抢单率进一步包括:
    获取订单的历史播单时间或用户的历史抢单时间;以及
    基于所述历史播单时间或历史抢单时间,预测用户抢单率。
  18. 根据权利要求15所述的方法,其特征在于,所述预测用户抢单率进一步包括:
    获取订单的位置信息或时间信息;
    基于所述位置信息或时间信息,建立用户抢单率预测模型;以及
    基于所述用户抢单率预测模型,预测用户抢单率。
  19. 根据权利要求15所述的方法,其特征在于,所述预测用户抢单率进一步包括确定所述用户抢单率预测的准确度。
  20. 根据权利要求19所述的方法,其特征在于,所述确定用户抢单率预测准确度进一步包括:
    获取用户针对订单的预测抢单率;
    确定所述用户针对所述订单实际的抢单率;以及
    基于所述用户的预测抢单率与实际抢单率,确定所述抢单率预测的准确度。
PCT/CN2016/072840 2015-01-29 2016-01-29 一种订单分配***及方法 WO2016119749A1 (zh)

Priority Applications (7)

Application Number Priority Date Filing Date Title
US15/547,221 US10977585B2 (en) 2015-01-29 2016-01-29 Order allocation system and method
EP16742811.9A EP3252705A4 (en) 2015-01-29 2016-01-29 Order allocation system and method
SG11201706188YA SG11201706188YA (en) 2015-01-29 2016-01-29 Order allocation system and method
KR1020177024089A KR20180013843A (ko) 2015-01-29 2016-01-29 오더 할당 시스템 및 방법
PH12017501364A PH12017501364B1 (en) 2015-01-29 2017-07-28 Order allocation system and method
HK18104774.4A HK1245473A1 (zh) 2015-01-29 2018-04-12 訂單分配系統和方法
US17/227,439 US20210232984A1 (en) 2015-01-29 2021-04-12 Order allocation system and method

Applications Claiming Priority (18)

Application Number Priority Date Filing Date Title
CN201510046647.2A CN104599218B (zh) 2015-01-29 2015-01-29 用于确定订单接收范围的方法和设备
CN201510046647.2 2015-01-29
CN201510078862.0 2015-02-13
CN201510078862.0A CN104616065B (zh) 2015-02-13 2015-02-13 用于处理订单的方法及设备
CN201510163336.4A CN104766262A (zh) 2015-04-08 2015-04-08 用于处理订单的方法及设备
CN201510163336.4 2015-04-08
CN201510172959.8 2015-04-13
CN201510172959.8A CN104915855B (zh) 2015-04-13 2015-04-13 订单抢单率的预估方法及装置
CN201510451956.8 2015-07-28
CN201510451956.8A CN105117777A (zh) 2015-07-28 2015-07-28 一种订单分配的方法及装置
CN201510456730.7A CN105118013A (zh) 2015-07-29 2015-07-29 一种订单的分配方法及装置
CN201510456730.7 2015-07-29
CN201510516346.1 2015-08-20
CN201510516040.6A CN105117842A (zh) 2015-08-20 2015-08-20 订单推送方法及装置
CN201510516040.6 2015-08-20
CN201510516346.1A CN105139228A (zh) 2015-08-20 2015-08-20 一种订单分配的方法及装置
CN201510537192.4A CN105096166A (zh) 2015-08-27 2015-08-27 一种订单分配的方法及装置
CN201510537192.4 2015-08-27

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US15/547,221 A-371-Of-International US10977585B2 (en) 2015-01-29 2016-01-29 Order allocation system and method
US17/227,439 Continuation US20210232984A1 (en) 2015-01-29 2021-04-12 Order allocation system and method

Publications (1)

Publication Number Publication Date
WO2016119749A1 true WO2016119749A1 (zh) 2016-08-04

Family

ID=56542470

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/072840 WO2016119749A1 (zh) 2015-01-29 2016-01-29 一种订单分配***及方法

Country Status (7)

Country Link
US (2) US10977585B2 (zh)
EP (1) EP3252705A4 (zh)
KR (1) KR20180013843A (zh)
HK (1) HK1245473A1 (zh)
PH (1) PH12017501364B1 (zh)
SG (1) SG11201706188YA (zh)
WO (1) WO2016119749A1 (zh)

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109214551A (zh) * 2018-08-08 2019-01-15 北京三快在线科技有限公司 一种配送调度方法及装置
CN110634012A (zh) * 2018-06-25 2019-12-31 北京嘀嘀无限科技发展有限公司 一种订单分配方法及装置、服务器、计算机可读存储介质
US10572932B2 (en) 2017-01-27 2020-02-25 Walmart Apollo, Llc System for providing optimal shopping routes in retail store and method of using same
CN111160637A (zh) * 2019-12-18 2020-05-15 中国平安财产保险股份有限公司 智能化人力分配方法、装置及计算机可读存储介质
US10657580B2 (en) 2017-01-27 2020-05-19 Walmart Apollo, Llc System for improving in-store picking performance and experience by optimizing tote-fill and order batching of items in retail store and method of using same
US10699328B2 (en) 2017-04-17 2020-06-30 Walmart Apollo, Llc Systems to fulfill a picked sales order and related methods therefor
CN111724089A (zh) * 2019-03-20 2020-09-29 顺丰科技有限公司 一种订单收派分配方法、***、终端及存储介质
CN111784088A (zh) * 2019-04-03 2020-10-16 北京嘀嘀无限科技发展有限公司 派单匹配方法、派单匹配装置、服务器和存储介质
US10810542B2 (en) 2017-05-11 2020-10-20 Walmart Apollo, Llc Systems and methods for fulfilment design and optimization
CN111815361A (zh) * 2020-07-10 2020-10-23 北京思特奇信息技术股份有限公司 区域边界计算方法、装置、电子设备及存储介质
CN111832788A (zh) * 2019-04-23 2020-10-27 北京嘀嘀无限科技发展有限公司 一种服务信息生成的方法、装置、计算机设备及存储介质
CN111861081A (zh) * 2019-12-23 2020-10-30 北京嘀嘀无限科技发展有限公司 一种订单分配方法、装置、电子设备及存储介质
US10846645B2 (en) 2017-04-28 2020-11-24 Walmart Apollo, Llc Systems and methods for real-time order delay management
US11126953B2 (en) 2017-06-14 2021-09-21 Walmart Apollo, Llc Systems and methods for automatically invoking a delivery request for an in-progress order
US11657347B2 (en) 2020-01-31 2023-05-23 Walmart Apollo, Llc Systems and methods for optimization of pick walks
US11669886B2 (en) 2017-07-13 2023-06-06 Walmart Apollo, Llc Systems and methods for determining an order collection start time
US11868958B2 (en) 2020-01-31 2024-01-09 Walmart Apollo, Llc Systems and methods for optimization of pick walks
US11941577B2 (en) 2017-06-28 2024-03-26 Walmart Apollo, Llc Systems and methods for automatically requesting delivery drivers for online orders

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10444121B2 (en) * 2016-05-03 2019-10-15 Sap Se Fault detection using event-based predictive models
WO2018227368A1 (en) * 2017-06-13 2018-12-20 Beijing Didi Infinity Technology And Development Co., Ltd. Systems and methods for recommending an estimated time of arrival
US11238544B2 (en) * 2017-07-07 2022-02-01 Msm Holdings Pte System and method for evaluating the true reach of social media influencers
RU2673388C1 (ru) * 2017-12-26 2018-11-26 Илья Владимирович Редкокашин Способ распределения заказов
CN108681857B (zh) * 2018-05-18 2020-03-10 北京顺丰同城科技有限公司 一种配送订单分配方法及装置、计算机可读存储介质
CN110570263B (zh) * 2018-06-06 2021-10-15 北京嘀嘀无限科技发展有限公司 订单分配方法、分配***、计算机设备及可读存储介质
US20210192410A1 (en) * 2018-07-04 2021-06-24 Sony Corporation Information processing device, information processing method, and program
CN110914856B (zh) 2018-07-10 2023-11-21 北京嘀嘀无限科技发展有限公司 用于确定线上到线下服务的营销策略的***和方法
US11442999B2 (en) 2018-07-24 2022-09-13 Microsoft Technology Licensing Llc Personalized whole search page organization and relevance
CN109117989B (zh) * 2018-07-26 2021-06-11 北京云鸟科技有限公司 一种任务匹配时的预测方法及装置
US11500825B2 (en) * 2018-08-20 2022-11-15 Intel Corporation Techniques for dynamic database access modes
CN111353837A (zh) * 2018-12-20 2020-06-30 北京嘀嘀无限科技发展有限公司 一种拼车方法、***及计算机可读介质
CN111353676B (zh) * 2018-12-24 2022-09-09 北京嘀嘀无限科技发展有限公司 订单分配方法、***、计算机设备和计算机可读存储介质
CN111382969B (zh) * 2018-12-30 2023-10-13 北京极智嘉科技股份有限公司 订单处理方法、装置、设备及存储介质
CN111833131A (zh) * 2019-05-29 2020-10-27 北京嘀嘀无限科技发展有限公司 一种订单处理方法、装置、电子设备及存储介质
CN112836914A (zh) * 2019-11-25 2021-05-25 北京三快在线科技有限公司 订单结构的调整方法、装置、存储介质及电子设备
US11514271B2 (en) * 2019-12-19 2022-11-29 Beijing Didi Infinity Technology And Development Co., Ltd. System and method for automatically adjusting strategies
KR102252774B1 (ko) * 2020-03-09 2021-05-17 주식회사 우아한형제들 배달 과정을 관리하기 위한 장치, 방법 및 명령을 기록한 기록 매체
US20210334709A1 (en) * 2020-04-27 2021-10-28 International Business Machines Corporation Breadth-first, depth-next training of cognitive models based on decision trees
CN111681423A (zh) * 2020-05-07 2020-09-18 北京明略软件***有限公司 实现车牌信息处理的方法、装置、计算机存储介质及终端
CN111553645B (zh) * 2020-06-08 2024-02-02 北京顺达同行科技有限公司 订单分派方法、装置、计算机设备和存储介质
CN114723125B (zh) * 2022-04-01 2024-06-28 华侨大学 一种结合深度学习和多任务优化的城际车订单分配方法
WO2023191708A2 (en) * 2022-04-01 2023-10-05 Grabtaxi Holdings Pte. Ltd. Server and method for processing request for search for on-demand service

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110046988A1 (en) * 2008-02-12 2011-02-24 Peter John Gosney Automated taxi dispatching system using telephone networks
CN102572697A (zh) * 2012-02-26 2012-07-11 沈哲 基于手持移动终端的出租车呼叫***及方法
CN104025075A (zh) * 2011-10-26 2014-09-03 托马斯·保罗·希德 用于车队导航、调度以及多个车辆、多个目的地指定路线的方法及***
CN104156868A (zh) * 2014-08-22 2014-11-19 北京嘀嘀无限科技发展有限公司 基于订单价值判断促进订单成交的出租车积分***
CN104766262A (zh) * 2015-04-08 2015-07-08 北京嘀嘀无限科技发展有限公司 用于处理订单的方法及设备
CN104915855A (zh) * 2015-04-13 2015-09-16 北京嘀嘀无限科技发展有限公司 订单抢单率的预估方法及装置
CN105096166A (zh) * 2015-08-27 2015-11-25 北京嘀嘀无限科技发展有限公司 一种订单分配的方法及装置
CN105117842A (zh) * 2015-08-20 2015-12-02 北京嘀嘀无限科技发展有限公司 订单推送方法及装置
CN105117777A (zh) * 2015-07-28 2015-12-02 北京嘀嘀无限科技发展有限公司 一种订单分配的方法及装置
CN105118013A (zh) * 2015-07-29 2015-12-02 北京嘀嘀无限科技发展有限公司 一种订单的分配方法及装置
CN105139228A (zh) * 2015-08-20 2015-12-09 北京嘀嘀无限科技发展有限公司 一种订单分配的方法及装置

Family Cites Families (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09153098A (ja) 1995-11-30 1997-06-10 Omron Corp 車両需要予測システム
KR100433734B1 (ko) * 2001-06-18 2004-06-04 이재욱 통신망을 이용한 택시 자동연결 서비스 방법
JP3860496B2 (ja) * 2002-03-28 2006-12-20 富士通株式会社 配車方法、および配車プログラム
JP4949645B2 (ja) 2005-06-16 2012-06-13 ヤフー株式会社 コンピュータ演算処理方法およびプログラム
CN100357986C (zh) 2005-09-16 2007-12-26 曲声波 车辆调度***中传输和处理调度信息的方法
US7739031B2 (en) * 2006-09-05 2010-06-15 Nissan Technical Center North America, Inc. Vehicle on-board unit
JP2009294742A (ja) 2008-06-03 2009-12-17 Hitachi Kokusai Electric Inc 配車管理装置
US20090313077A1 (en) * 2008-06-17 2009-12-17 Wheeler Iv George Y Consumer initiated, service provider direct dispatching system
CN101620781B (zh) 2008-06-30 2012-08-29 株式会社查纳位资讯情报 预测乘客信息的***和搜索乘客信息的***及其方法
US8386177B2 (en) * 2009-05-13 2013-02-26 Taiwan Mobile Communication Vehicle-dispatching method and vehicle-dispatching system
US10055804B2 (en) * 2011-09-20 2018-08-21 Metrobee, Llc Roaming transport distribution management system
US8868332B2 (en) 2011-10-26 2014-10-21 Right There Ware LLC Method and system for navigation using bounded geograhic regions
HK1165942A2 (en) 2012-06-08 2012-10-12 Agito Group Ltd A computer-implemented system for ordering a taxi
CN102833680B (zh) 2012-09-11 2014-09-24 中国水产科学研究院东海水产研究所 基于位置的海洋渔业信息服务方法
CN203165207U (zh) 2012-12-14 2013-08-28 清华大学苏州汽车研究院(吴江) 基于智能手机的出租车自动寻呼***
US20140172737A1 (en) * 2012-12-18 2014-06-19 Ebay Inc. Community shipping platform
US20140278635A1 (en) * 2013-03-15 2014-09-18 Bringaroo, LLC Delivery methods and systems utilizing a stand-by delivery driver
CN103218769A (zh) 2013-03-19 2013-07-24 王兴健 出租车订单分配方法
EP2843598A1 (en) 2013-08-30 2015-03-04 GT Gettaxi Limited System and method for ordering a transportation vehicle
CN104463650A (zh) 2013-09-12 2015-03-25 墨林设计顾问股份有限公司 特定区域实时反馈的预约交易方法
CN103514738B (zh) 2013-09-18 2015-09-02 福建工程学院 一种出租车叫车拼车顺路匹配方法及其***
CA2932828C (en) * 2013-12-11 2023-12-05 Uber Technologies, Inc. Optimizing selection of drivers for transport requests
CN103680135A (zh) 2013-12-31 2014-03-26 北京东方车云信息技术有限公司 一种提供打车服务的方法、装置及***
CN103680134B (zh) 2013-12-31 2016-08-24 北京东方车云信息技术有限公司 一种提供打车服务的方法、装置及***
CA2946648A1 (en) 2014-04-24 2015-10-29 Lingyu Zhang System and method for managing supply of service
CN103985247B (zh) 2014-04-24 2016-08-24 北京嘀嘀无限科技发展有限公司 基于城市叫车需求分布密度的出租车运力调度***
CN104123836B (zh) 2014-07-29 2016-04-06 北京嘀嘀无限科技发展有限公司 基于城市叫车订单时间地点组合的订单推送***
CN104183118B (zh) 2014-08-19 2016-08-24 北京嘀嘀无限科技发展有限公司 基于拍卖模式获得乘客最优接驾司机的派单***
MY188692A (en) 2014-08-04 2021-12-23 Beijing Didi Infinity Technology & Dev Co Ltd Methods and systems for distributing orders
CN104715426B (zh) 2015-04-08 2018-08-03 北京嘀嘀无限科技发展有限公司 用于处理订单的方法及设备
CN104157133B (zh) 2014-08-20 2016-10-05 北京嘀嘀无限科技发展有限公司 基于司机在线活跃情况的运力拉升***
CN104794553B (zh) 2014-08-12 2018-07-10 北京东方车云信息技术有限公司 网络租车中基于出租车运营区域熟悉程度的派单***和方法
CN110009256A (zh) 2014-11-27 2019-07-12 北京嘀嘀无限科技发展有限公司 一种订单处理方法、设备、计算机***及存储介质
CN104484787A (zh) 2014-12-16 2015-04-01 四川创物科技有限公司 一种信息推送方法
CN104574018B (zh) 2014-12-26 2018-05-15 北京京东尚科信息技术有限公司 一种抢单控制方法及***
CN104463509A (zh) 2014-12-29 2015-03-25 先锋智道(北京)科技有限公司 网络打车的订单推送方法和网络打车的订单确认方法
MY193639A (en) * 2015-01-27 2022-10-21 Beijing Didi Infinity Technology & Dev Co Ltd Methods and systems for providing information for an on-demand service
CN104599218B (zh) 2015-01-29 2020-09-11 北京嘀嘀无限科技发展有限公司 用于确定订单接收范围的方法和设备
PH12017501388A1 (en) 2015-02-02 2018-01-08 Beijing Didi Infinity Technology & Dev Co Ltd Methods and systems for order processing
CN104616086A (zh) 2015-02-28 2015-05-13 北京嘀嘀无限科技发展有限公司 用于动态设置订单的缓冲时间的方法和设备
CN104751271A (zh) 2015-03-04 2015-07-01 径圆(上海)信息技术有限公司 智能订单调度方法、服务器、电动车、移动终端及***
US10055995B2 (en) * 2015-10-06 2018-08-21 Gt Gettaxi Limited System for preemptively navigating drivers to an event created through a social network system
US10832367B2 (en) * 2016-02-17 2020-11-10 Justin Andrew Frankert System for arranging transportation services and associated methods
US11138524B2 (en) * 2016-03-11 2021-10-05 Uber Technologies, Inc. Cascaded boosted predictive models

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110046988A1 (en) * 2008-02-12 2011-02-24 Peter John Gosney Automated taxi dispatching system using telephone networks
CN104025075A (zh) * 2011-10-26 2014-09-03 托马斯·保罗·希德 用于车队导航、调度以及多个车辆、多个目的地指定路线的方法及***
CN102572697A (zh) * 2012-02-26 2012-07-11 沈哲 基于手持移动终端的出租车呼叫***及方法
CN104156868A (zh) * 2014-08-22 2014-11-19 北京嘀嘀无限科技发展有限公司 基于订单价值判断促进订单成交的出租车积分***
CN104766262A (zh) * 2015-04-08 2015-07-08 北京嘀嘀无限科技发展有限公司 用于处理订单的方法及设备
CN104915855A (zh) * 2015-04-13 2015-09-16 北京嘀嘀无限科技发展有限公司 订单抢单率的预估方法及装置
CN105117777A (zh) * 2015-07-28 2015-12-02 北京嘀嘀无限科技发展有限公司 一种订单分配的方法及装置
CN105118013A (zh) * 2015-07-29 2015-12-02 北京嘀嘀无限科技发展有限公司 一种订单的分配方法及装置
CN105117842A (zh) * 2015-08-20 2015-12-02 北京嘀嘀无限科技发展有限公司 订单推送方法及装置
CN105139228A (zh) * 2015-08-20 2015-12-09 北京嘀嘀无限科技发展有限公司 一种订单分配的方法及装置
CN105096166A (zh) * 2015-08-27 2015-11-25 北京嘀嘀无限科技发展有限公司 一种订单分配的方法及装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3252705A4 *

Cited By (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10572932B2 (en) 2017-01-27 2020-02-25 Walmart Apollo, Llc System for providing optimal shopping routes in retail store and method of using same
US10657580B2 (en) 2017-01-27 2020-05-19 Walmart Apollo, Llc System for improving in-store picking performance and experience by optimizing tote-fill and order batching of items in retail store and method of using same
US11270372B2 (en) 2017-01-27 2022-03-08 Walmart Apollo, Llc System for improving in-store picking performance and experience by optimizing tote-fill and order batching of items in retail store and method of using same
US10825076B2 (en) 2017-04-17 2020-11-03 Walmart Apollo Llc Systems to fulfill a picked sales order and related methods therefor
US11978108B2 (en) 2017-04-17 2024-05-07 Walmart Apollo, Llc Systems to fulfill a picked sales order and related methods therefor
US11508000B2 (en) 2017-04-17 2022-11-22 Walmart Apollo, Llc Systems to fulfill a picked sales order and related methods therefor
US10699328B2 (en) 2017-04-17 2020-06-30 Walmart Apollo, Llc Systems to fulfill a picked sales order and related methods therefor
US11494829B2 (en) 2017-04-17 2022-11-08 Walmart Apollo, Llc Systems to fulfill a picked sales order and related methods therefor
US10796357B2 (en) 2017-04-17 2020-10-06 Walmart Apollo, Llc Systems to fulfill a picked sales order and related methods therefor
US11461831B2 (en) 2017-04-17 2022-10-04 Walmart Apollo, Llc Systems to fulfill a picked sales order and related methods therefor
US10846645B2 (en) 2017-04-28 2020-11-24 Walmart Apollo, Llc Systems and methods for real-time order delay management
US10810542B2 (en) 2017-05-11 2020-10-20 Walmart Apollo, Llc Systems and methods for fulfilment design and optimization
US11126953B2 (en) 2017-06-14 2021-09-21 Walmart Apollo, Llc Systems and methods for automatically invoking a delivery request for an in-progress order
US11734642B2 (en) 2017-06-14 2023-08-22 Walmart Apollo, Llc Systems and methods for automatically invoking a delivery request for an in-progress order
US11941577B2 (en) 2017-06-28 2024-03-26 Walmart Apollo, Llc Systems and methods for automatically requesting delivery drivers for online orders
US11669886B2 (en) 2017-07-13 2023-06-06 Walmart Apollo, Llc Systems and methods for determining an order collection start time
CN110634012A (zh) * 2018-06-25 2019-12-31 北京嘀嘀无限科技发展有限公司 一种订单分配方法及装置、服务器、计算机可读存储介质
CN109214551B (zh) * 2018-08-08 2022-08-26 北京三快在线科技有限公司 一种配送调度方法及装置
CN109214551A (zh) * 2018-08-08 2019-01-15 北京三快在线科技有限公司 一种配送调度方法及装置
CN111724089A (zh) * 2019-03-20 2020-09-29 顺丰科技有限公司 一种订单收派分配方法、***、终端及存储介质
CN111724089B (zh) * 2019-03-20 2023-04-28 顺丰科技有限公司 一种订单收派分配方法、***、终端及存储介质
CN111784088A (zh) * 2019-04-03 2020-10-16 北京嘀嘀无限科技发展有限公司 派单匹配方法、派单匹配装置、服务器和存储介质
CN111832788B (zh) * 2019-04-23 2024-03-29 北京嘀嘀无限科技发展有限公司 一种服务信息生成的方法、装置、计算机设备及存储介质
CN111832788A (zh) * 2019-04-23 2020-10-27 北京嘀嘀无限科技发展有限公司 一种服务信息生成的方法、装置、计算机设备及存储介质
CN111160637A (zh) * 2019-12-18 2020-05-15 中国平安财产保险股份有限公司 智能化人力分配方法、装置及计算机可读存储介质
CN111160637B (zh) * 2019-12-18 2024-04-05 中国平安财产保险股份有限公司 智能化人力分配方法、装置及计算机可读存储介质
CN111861081A (zh) * 2019-12-23 2020-10-30 北京嘀嘀无限科技发展有限公司 一种订单分配方法、装置、电子设备及存储介质
US11657347B2 (en) 2020-01-31 2023-05-23 Walmart Apollo, Llc Systems and methods for optimization of pick walks
US11868958B2 (en) 2020-01-31 2024-01-09 Walmart Apollo, Llc Systems and methods for optimization of pick walks
CN111815361A (zh) * 2020-07-10 2020-10-23 北京思特奇信息技术股份有限公司 区域边界计算方法、装置、电子设备及存储介质

Also Published As

Publication number Publication date
US10977585B2 (en) 2021-04-13
US20180012153A1 (en) 2018-01-11
PH12017501364A1 (en) 2017-12-18
EP3252705A4 (en) 2018-07-04
SG11201706188YA (en) 2017-08-30
EP3252705A1 (en) 2017-12-06
KR20180013843A (ko) 2018-02-07
US20210232984A1 (en) 2021-07-29
HK1245473A1 (zh) 2018-08-24
PH12017501364B1 (en) 2017-12-18

Similar Documents

Publication Publication Date Title
WO2016119749A1 (zh) 一种订单分配***及方法
US11315170B2 (en) Methods and systems for order processing
JP6918087B2 (ja) オン・デマンドサービスの情報を提供する方法及びシステム
JP6506460B2 (ja) サービスの供給状況を管理するシステム及び方法
WO2016127918A1 (zh) 一种运力调度方法及***
JP6559792B2 (ja) オーダーペアリングのシステム及び方法
EP3479306B1 (en) Method and system for estimating time of arrival
CN112236787B (zh) 用于生成个性化目的地推荐的***和方法
WO2016091173A1 (zh) 一种用户维护***及方法
WO2016127917A1 (zh) 一种订单推送方法及***
JP2018528535A (ja) 過去の注文に基づき現在の注文に関係がある情報を決定するためのシステムおよび方法
JP2018533778A (ja) 共有可能な注文を割り当てるためのシステムおよび方法
US20200300650A1 (en) Systems and methods for determining an estimated time of arrival for online to offline services
WO2018146622A1 (en) Dynamic selection of geo-based service options in a network system
BR112017018866B1 (pt) Sistemas e métodos para emparelhamento de ordens

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16742811

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 11201706188Y

Country of ref document: SG

Ref document number: 15547221

Country of ref document: US

Ref document number: 12017501364

Country of ref document: PH

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2016742811

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 20177024089

Country of ref document: KR

Kind code of ref document: A