WO2016124118A1 - 一种订单处理方法与系统 - Google Patents

一种订单处理方法与系统 Download PDF

Info

Publication number
WO2016124118A1
WO2016124118A1 PCT/CN2016/072837 CN2016072837W WO2016124118A1 WO 2016124118 A1 WO2016124118 A1 WO 2016124118A1 CN 2016072837 W CN2016072837 W CN 2016072837W WO 2016124118 A1 WO2016124118 A1 WO 2016124118A1
Authority
WO
WIPO (PCT)
Prior art keywords
order
user
information
service provider
time
Prior art date
Application number
PCT/CN2016/072837
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 CN201510053500.6A external-priority patent/CN104599168A/zh
Priority claimed from CN201510065334.1A external-priority patent/CN104598978A/zh
Priority claimed from CN201510075815.0A external-priority patent/CN104639646B/zh
Priority claimed from CN201510149155.6A external-priority patent/CN104715285B/zh
Priority claimed from CN201510174117.6A external-priority patent/CN105005816A/zh
Priority claimed from CN201510207953.XA external-priority patent/CN104867016A/zh
Priority claimed from CN201510633919.9A external-priority patent/CN105160021A/zh
Priority claimed from CN201610035351.5A external-priority patent/CN105719173A/zh
Priority to GB1712642.6A priority Critical patent/GB2550523A/en
Priority to US15/547,528 priority patent/US10657581B2/en
Application filed by 北京嘀嘀无限科技发展有限公司 filed Critical 北京嘀嘀无限科技发展有限公司
Priority to PH12017501388A priority patent/PH12017501388A1/en
Priority to SG11201706269QA priority patent/SG11201706269QA/en
Priority to MYPI2017001131A priority patent/MY181464A/en
Publication of WO2016124118A1 publication Critical patent/WO2016124118A1/zh
Priority to HK18106251.1A priority patent/HK1246941A1/zh
Priority to US16/869,447 priority patent/US11315170B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635—Processing of requisition or of purchase orders
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry

Definitions

  • the present application relates to an order processing method and system, and more particularly to an order processing method and system using mobile internet technology and data processing technology.
  • the on-demand service system assigns the order to the driver to wait for the driver to respond, and selects one of the responding drivers to send the order.
  • the on-demand service system assigns the order to the driver to wait for the driver to respond, and selects one of the responding drivers to send the order.
  • an order processing method may include: receiving an order and extracting order information; extracting service provider information and obtaining a service Provider characteristics; determining whether the order information matches the service provider feature, or determining whether the service provider feature meets a preset condition, generating a determination result; and performing, according to the determination result, the service provider Sorting; generating an order to be dispensed; and assigning the to-assigned order to the service provider according to the ranking.
  • a system can include a computer readable storage medium configured to store an executable module, and a processor executable to execute the executable module of the computer readable storage medium storage.
  • the executable module may include: an order extraction module, configured to receive an order and extract order information; a service provider information extraction module, configured to extract service provider information and obtain a service provider feature; and a determination module, configured to determine the order information Whether to match the service provider feature, or to determine whether the service provider feature satisfies a preset condition, and generate a determination result; the ranking module is configured to sort the service provider according to the determination result; order generation a module, configured to generate an order to be allocated; and an order allocation module, configured to allocate the to-be-allocated order to the service provider according to the sorting.
  • a computer readable storage medium configured to store executable modules and store information.
  • the calculation can execute an order processing method.
  • the processing method may include: receiving an order and extracting order information; extracting service provider information and obtaining a service provider feature; determining whether the order information matches the service provider feature, or determining whether the service provider feature is satisfied Determining a condition, generating a judgment result; sorting the service provider according to the judgment result; generating an order to be allocated; and assigning the to-be-allocated order to the service provider according to the ranking.
  • the order information includes time, time period, location, and area.
  • the service provider features include: order similarity, preference, cool rate, grab characteristics, and response time.
  • the order similarity includes a cosine similarity between a historical order and a current order
  • the historical order may include an confirmed order and a cancelled order
  • the preference includes a preference area and a preference period.
  • the above-described order processing method and system further comprise: obtaining or calculating the preference from the service provider.
  • calculating the preference area comprises: performing cluster analysis on a latitude and longitude coordinate of a historical order destination by using a density peak clustering algorithm.
  • the order processing method and system further includes: acquiring latitude and longitude coordinates corresponding to the destination of the to-be-allocated order; calculating latitude and longitude coordinates corresponding to the destination of the to-be-distributed order, and the service provider The distance A z of the center point of the destination preference area; calculating the destination of the service provider for the to-be-allocated order based on the distance A z and the coverage radius d of the service provider's destination preference area Preference L,
  • obtaining the saturation rate comprises calculating using the following formula:
  • T x is the cool rate
  • k is the number of cool orders in the last n orders that the service provider x is assigned.
  • p is the average refresh rate.
  • the order allocation method and the order distribution system further include: determining, according to the response time, a candidate service provider request for the order; selecting from the candidate service provider request A service provider requests processing.
  • the order allocation method and the order distribution system further include: determining a geographic area, determining an order group and a service provider group according to the geographic area; analyzing the order group and the service provider group Determining the order transaction rate, the success rate of the order, and the rate of the order, and calculating the weighted sum of the order transaction rate, the success rate of the order, and the rate of the order; and determining the order according to the weighted sum Allocation.
  • FIG. 1 is a schematic diagram of a network environment including an order processing engine, shown in accordance with some embodiments of the present application;
  • FIG. 2 is a schematic diagram of an order processing engine shown in accordance with some embodiments of the present application.
  • FIG. 3 is an exemplary flow chart of order processing shown in accordance with some embodiments of the present application.
  • 4A is a schematic diagram of a processing module shown in accordance with some embodiments of the present application.
  • 4-B is an exemplary flow diagram of the operation of the processing module shown in accordance with some embodiments of the present application.
  • FIG. 5 is a schematic diagram of assigning an order according to an order similarity, according to some embodiments of the present application.
  • FIG. 6 is an exemplary flow diagram of assigning an order based on order similarity, shown in accordance with some embodiments of the present application.
  • FIG. 7 is a schematic diagram of assigning an order according to a preference according to some embodiments of the present application.
  • FIG. 8 is an exemplary flow diagram of calculating a preference region, shown in accordance with some embodiments of the present application.
  • FIG. 9 is an exemplary flow chart of calculating a preference shown in accordance with some embodiments of the present application.
  • FIG. 10 is a schematic diagram of a principle of computing preference shown in accordance with some embodiments of the present application.
  • FIG. 11 is a schematic diagram of an originating period and an originating area allocation order according to a user request, according to some embodiments of the present application.
  • FIG. 12 is an exemplary flowchart showing an allocation period and an originating area allocation order according to a user request, according to some embodiments of the present application;
  • Figure 13 is a schematic illustration of an order being dispensed according to a cool rate rate, in accordance with some embodiments of the present application.
  • FIG. 14 is an exemplary flow diagram of assigning an order according to a cool rate as shown in some embodiments of the present application.
  • 15 is an exemplary flow chart for allocating an order according to a grabbing characteristic, according to some embodiments of the present application.
  • 16 is a flow chart of statistical snatch behavior shown in accordance with some embodiments of the present application.
  • 17-A and 17-B are diagrams showing user grabbing characteristics according to some embodiments of the present application.
  • FIG. 18 is an exemplary flow diagram of allocating an order based on a user response time, in accordance with some embodiments of the present application.
  • 19 is a flow diagram of a particular embodiment of allocating an order based on a user response time, in accordance with some embodiments of the present application.
  • 20 is an exemplary flow diagram of assigning a group of orders to a group of users, in accordance with some embodiments of the present application.
  • 21 is a flowchart of a specific embodiment of allocating an order group to a user group, according to some embodiments of the present application.
  • Figure 22 shows the structure of a mobile device that can implement the particular system disclosed in this application
  • Figure 23 shows the structure of a computer that can implement the particular system disclosed in this application.
  • 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, motor trains, high-speed rail, subways, ships, airplanes, spaceships, hot air balloons, unmanned vehicles, receiving/delivery, etc., apply management and/or distribution of transportation. system.
  • 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.
  • the "passenger”, “customer”, “demander”, “service demander”, “consumer”, “consumer”, “user demander”, etc. described in this application are interchangeable, meaning that they are required or ordered.
  • the party to the service can be an individual or a tool.
  • the "driver”, “provider”, “supplier”, “service provider”, “servicer”, “service party”, etc. described herein are also interchangeable, meaning that the service is provided or assisted.
  • the "user” described in the present application may be a party that needs or subscribes to a service, or a party that provides a service or assists in providing a service.
  • Network environment 100 may 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 more information Source 160.
  • on demand Service system 105 can include an order processing engine 110.
  • the order processing engine 110 can be used in a system that analyzes the collected information to generate an analysis result.
  • the order processing engine 110 can be a server (eg, a cloud server) or 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 processing engine 110 can be local or remote.
  • the order processing engine 110 can access the information of the user 120/140, the information in the information source 160, the information in the database 130 through the network 150, or directly access the information in the information source 160, the database 130. Information in.
  • the passenger terminal 120 and the driver terminal 140 may be collectively referred to as a user, 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. In this document, "passenger”, “passenger” and “passenger equipment” are used interchangeably.
  • 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 or more 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, and the like. Combination of species.
  • the built-in device 120-3 of the motor vehicle may be a carputer or the like;
  • the mobile device 120-4 may be a smart phone, a personal digital assistance (PDA), a tablet computer, or a handheld game console.
  • PDA personal digital assistance
  • 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 passenger terminal 120 and/or the driver terminal 140 and various data generated in the operation of the order processing engine 110.
  • 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.
  • the database 130 can be used to store various information such as programs 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 A combination of one or more of a heap read memory, a floating connection gate random access memory, a nano random access memory, a track memory, a variable resistive memory, a programmable metallization cell, 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 processing engine 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. 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.
  • 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/or the information source 160 and various data generated in the operation of the order processing engine 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.
  • the connection between the database 130 and other storage devices in the system may be wired or wireless.
  • the connection or communication between the database 130 and other modules of the system may be wired or wireless.
  • the internet 150 can provide a channel for information exchange.
  • the 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.
  • Information source 160 is a source of additional information for the system.
  • the information source 160 can 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.
  • the information source 160 may exist in the form of a single central server, or in the form of a plurality of servers connected through a network, or 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.
  • the information source 160 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 processing engine 110), or a combination of the two.
  • the on-demand service system 105 or a portion thereof (e.g., the order processing engine 110), or a combination of the two.
  • user 120/140 can access information in information source 160 over network 150.
  • the connection or communication between the information source 160 and other modules of the system may be wired or wireless.
  • the 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.
  • the information source 160 may be a physical information source, such as a common speed measuring device, a sensing, an Internet of Things device, such as a driver's vehicle speedometer, an onboard diagnostic system, a radar speedometer on a road, a temperature and humidity sensor, and the like.
  • the information source 160 may also be a source for obtaining news, information, real-time information on the road, etc., such as a network information source, including but not limited to an Internet news group based on Usenet, a server on the Internet, a weather information server, a road status information server, and the like.
  • a network information source including but not limited to an Internet news group based on Usenet, a server on the Internet, a weather information server, a road status information server, and the like.
  • the information source 160 may be stored somewhere A system of numerous catering service providers in the domain, a municipal service system including map information and city service information, a traffic condition system, a weather broadcast system, a news network, and the like.
  • the above examples are not intended to limit the scope of the information sources herein, nor to the scope of the examples.
  • the present invention can be applied to any service, any device or network capable of providing information related to the corresponding service. Can be classified as a source of information.
  • information exchange between different parts of the system can be made by way of an order.
  • 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.
  • the 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 is an exemplary system diagram of order processing.
  • the order processing engine 110 may include one or more processing modules 210, one or more storage modules 220, one or more passenger interfaces 230, one or more driver interfaces 240.
  • the modules of the order processing engine 110 may be centralized or distributed.
  • One or more of the modules of the order processing engine 110 may be local or remote.
  • the order processing engine 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 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.
  • passenger interface 230 and driver interface 240 can read information from database 130 and information source 160, 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, or may be calculated and processed by the processing module 210.
  • 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 210 and the driver interface 230 can be used to output information that has been processed and processed by the processing module 210.
  • 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, may be stored in the storage module 220, or may be stored in the processing module 210.
  • 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 database 130, the information source 160, and the like.
  • the processing module 210 may send the processed information to the passenger interface 230 and/or the driver interface 240, may save the processed information to the database 130 or other backup database or storage device, or save the processed information in the processing.
  • 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 Processing Processor (DSP), Field-Programmable Gate Array (FPGA), Programmable Logic A combination of one or more of a device (Programmable Logic Device (PLD)), a processor, a microprocessor, 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 Processing Processor
  • FPGA Field-Programmable Gate Array
  • PLD Programmable Logic A combination of one or more of a device
  • PLD Programmable Logic Device
  • the foregoing processing module 210 may actually exist in the system, or may perform corresponding functions through a 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 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).
  • the order processing engine 110 and the on-demand service system is merely for convenience of description, and the present application is not limited to the scope of the embodiments. It will be understood that, after understanding the principles of the system, various modifications and changes in the form and details of the application of the above-described methods and systems may be made without departing from the principle. .
  • the storage module may be internal to the system or may be an external device of the system. The storage module may actually exist in the system, or may complete the corresponding function through the cloud computing platform.
  • the passenger interface 230, the processing module 210, the driver interface 240, and the storage module 220 may be different modules embodied in one system, or may be a module that implements two or more of the above modules.
  • 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 passengers.
  • the 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 allocation process can be performed by the on-demand service system 105 or a portion thereof (eg, the order processing engine 110).
  • the order information can be obtained from the user 120/140 (see Figure 1) at step 310.
  • information of database 130 and/or information source 160 may also be obtained.
  • the form of the order information may include, but is not limited to, one or a combination of text, picture, audio, video, and the like. Taking a taxi service order as an example, the content of the order information may include, but is not limited to, the order itself information, user information, and other information.
  • the information of the order itself may include but is not limited to the time of sending the order, the order number, the place of departure, the destination, the departure time, the arrival time, the time of waiting, the number of passengers, whether it is willing to carpool, the selected model, the presence or absence of luggage, the 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 sending 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, rating, time of use, driving age, age, model, condition, license plate number, driver's license number, certification status, user habits/likes, additional service capabilities (eg trunk size of the car, A combination of one or more of an additional feature such as a panoramic sunroof.
  • 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, which may be reservation order information or historical order information.
  • the real-time order information may be order information that is departed at the current time.
  • Real-time order information may include departure time, departure location, and the like.
  • the reservation order information may be order information of a passenger reserved at a certain time or a certain period of time.
  • 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 reservation order information may also include information such as departure time, departure location, destination, and the like.
  • the historical order information may include past related information, for example, one of the requested order quantity, the accepted order quantity, the volume of the order, the grab rate, the success rate of the grab, the breach rate, the refresh rate, the turnover rate, the user habit/likeness, and the like. Or a combination of several.
  • user characteristics can be obtained.
  • the user characteristics may include, but are not limited to, a name, a nickname, a gender, a nationality, an age, a contact information (a phone number, a mobile phone number, a social account information (such as a micro-signal code, a QQ number, a LinkedIn, etc.), etc., which may be contacted by the user.
  • a contact information a phone number, a mobile phone number, a social account information (such as a micro-signal code, a QQ number, a LinkedIn, etc.), etc., which may be contacted by the user.
  • Mode, etc. occupation, rating 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 trunk size of the car, panoramic sunroof, etc.)
  • additional service capabilities such as trunk size of the car, panoramic sunroof, etc.
  • User habits/likes may be passengers' preferences for departures, destinations, departure times, passengers' preferences for drivers, waiting times that passengers can receive, passengers' preferences for carpooling passengers, passengers' preference for models, drivers' departures, Destination, departure time preference, driver's preference for driving route, driver's working time, driver's grab rate, driver's response time, driver's grab characteristics, driver's refresh rate, division The amount of grabs, the success of the grab, the volume of the order, the success rate of the grab, and the turnover rate.
  • the user feature may be a user feature directly acquired according to a user's active input, or may be a user feature obtained through a certain data processing manner.
  • the processing of information includes, but is not limited to, a combination of one or more of storing, classifying, filtering, converting, calculating, retrieving, predicting, training, and the like.
  • 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 method, it may be supervised learning, unsupervised learning, semi-supervised learning or reinforcement learning; depending on the algorithm, the machine learning algorithm may be regression algorithm learning, instance-based learning, Formal learning, decision tree learning, Bayesian learning, clustering algorithm learning, association rule learning, neural network learning, deep learning, and reduced dimensional algorithm learning.
  • 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 the 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)
  • the Bayesian model it can be a Naive Bayes algorithm, an Averaged One-Dependence Estimators, or a Bayesian Belief Network (BBN); for a kernel-based algorithm model, it can be a support vector machine ( Support Vector Machine), Radial Basis Function or Linear Discriminate Analysis; for the clustering algorithm model, it may be k-Means algorithm or Expectation Maximization;
  • the rule model may be an Apriori algorithm or an Eclat algorithm; for a neural network model, it may be a Perceptron
  • Deep learning model which can be Restricted Boltzmann Machine, Deep Belief Networks (DBN), Convolutional Network or Stacked Auto-encoders;
  • the algorithm model can be Principal Component Analysis, Partial Least Square Regression, Sammon Mapping, Multi-Dimensional Scaling or Projection Pursuit.
  • an order is assigned based on the user characteristics.
  • the order processing engine 110 can send information, such as order information, to one or more driver devices 140, one or more passenger devices 120, one or more third party platforms, and the like.
  • the content of the sent order information may include, but is not limited to, order information, user information, and other information.
  • the order itself information may include but is not limited to order number, departure place, 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 bag usage, payment method (such as cash payment, credit card payment, online payment, remittance payment, etc.), order completion status, service provider selection order status, consumer order status, etc., or any combination of the above information.
  • User information refers to information about the user 120/140.
  • User information can be packaged Including but 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.), occupation, evaluation One of the 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, panoramic sunroof, etc.) Combination of species or several. 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.
  • the information sent may be direct information of the order, processing information of the order, or a combination of two types of order information.
  • 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 processing flow is merely for convenience of description, 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, may make changes to the order processing flow without departing from the principle. For example, some steps can be added or subtracted.
  • the order information can be pre-processed after step 310.
  • 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 another example, in the order processing process, the steps of data storage can also be added. Variations such as these are within the scope of the present application.
  • the processing module 210 may include the following modules: an order information extraction module 410, a user information extraction module 420, a calculation module 430, a determination module 440, a ranking module 450, an order generation module 460, and an order distribution module 470.
  • the processing module 210 may also include one or more other modules or units.
  • Each of the above modules 410-470 can communicate with each other, and the connection manner between the modules It can be wired or wireless.
  • the connection between the modules is exemplarily shown in Fig. 4-A, but it does not mean that the connection between the modules is limited to this.
  • the order information extraction module 410 can be used to extract direct or indirect information related to the order.
  • Orders can include real-time orders, reserved orders, and historical orders.
  • the order information may include: order delivery time, order number, departure place, destination, departure time, arrival time, time to wait, number of passengers, whether or not to carpool, selected model, presence or absence of baggage, mileage, price , consumer price increase, service party price adjustment, system price adjustment, red envelope usage, payment methods (such as cash payment, credit card payment, online payment, remittance payment, etc.), order completion, service provider selection of orders, consumer orders, etc. , or any combination of the above information.
  • the order information may also include other information related to the order, such as passenger information (such as gender, nickname, contact information, etc.) and other information that is not controlled by the consumer or the servant, or temporary/sudden Information.
  • passenger information such as gender, nickname, contact information, etc.
  • 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.
  • Order information can be extracted in real time or non-real time. The extracted order information may be stored in the order information extraction module 410, the storage module 220, or any of the storage devices integrated in the system or independent of the system as described in this application.
  • the order information extraction module 410 may further include one or more sub-units, such as a time information extraction unit (not shown in the figure), a location information extraction unit (not shown), and a parsing unit (not shown in the figure) ), processing unit (not shown in the figure), etc.
  • the time information extraction unit may be configured to extract time information related to the order (eg, the time at which the order was sent, the time at which the reservation was scheduled, the time period at which the departure time was reserved, etc.).
  • the location information extraction unit may be configured to extract location information related to the order (eg, departure place, destination, area where the departure place is located, traffic conditions around the departure place, traffic conditions around the destination, etc.).
  • the parsing unit can be used to analyze time information, location information, and the like related to the order, for example, converting the location information from a text description to an address coordinate.
  • the text description may refer to one or more of the name of the place, the house number, the building name, etc.
  • the address coordinates may refer to coordinate information of a certain place, such as latitude and longitude coordinates.
  • the processing unit can be used to process the order One or more order-related information extracted by the single information extraction module 410, including but not limited to calculation, recognition, verification, judgment, screening, and the like.
  • the user information extraction module 420 can be used to extract direct or indirect information related to the user and to identify, organize, and categorize the information.
  • Users can include passengers or drivers. Taking the driver as an example, the user information may include an order selected by history, an order cancelled by history, a time of historical order taking, a time period of historical order taking, a position of a historical order, an area of a historical order, a time or a period of a historical landing system , the location or area where the history was logged into the system, and the historical cool order.
  • User information can be extracted in real time or non-real time.
  • the extracted user information may be stored in the user information extraction module 420, the storage module 220, or any of the storage devices integrated in the system or independent of the system as described in this application.
  • the extracted order information and user information may be transmitted to the calculation module 430 for further calculation and analysis in real time or non-real time, or may be transmitted to the judgment module 440 or the sorting module 450 for further judgment or sorting in real time or non-real time.
  • the order information extraction module 410 and the user information extraction module 420 can be integrated in the same module, and at the same time implement the function of extracting order information and extracting user information.
  • the user information extraction module 420 may further include one or more sub-units, such as an information receiving unit (not shown), an information parsing unit (not shown), and an information transmission unit (not shown). Wait.
  • the information receiving unit may be configured to receive or read user information.
  • the information sent by the driver may be the current location of the driver determined by the positioning technology, the speed at which the driver travels, and the current service status fed back by the driver (carrier, Waiting for passengers, idling, one or more of the driver's choice of service request, confirmation or rejection information.
  • the above information may be one or more of natural language text information, binary information, audio information (including driver's voice input), image information (still picture or video), and other types of multimedia information.
  • the information parsing unit can be used to sort or classify the above information, for example, into a readable or storable format.
  • the information transmission unit can be used to receive or transmit information and can include one or more wired or wireless transceiver devices.
  • the calculation module 430 can be used to calculate the user characteristics.
  • User characteristics can include similarity, preference, cool rate, grab characteristics, response time of historical orders and current orders. Wait.
  • the calculation module 430 may include a similarity calculation unit 431, a preference calculation unit 432, a saturation rate calculation unit 433, a grab single characteristic calculation unit 434, a response time calculation unit 435, and other one or more user feature calculation units, and the like.
  • the computing module 430 may also integrate one or more storage units (not shown) for storing the calculated driver characteristics.
  • the calculated user features may be transmitted to the decision module 440 or the ranking module 450 for further analysis processing in real time or non-real time.
  • Calculation methods may include, but are not limited to, minimum-maximum normalization, Z-score normalization, scaling by decimal scale, linear function method, logarithmic function method, inverse cotangent function method, norm method, historical threshold iteration, modeling method, Least squares method, elimination method, reduction method, substitution method, image method, comparison method, scaling method, vector method, induction method, counter-evidence method, exhaustive method, matching method, undetermined coefficient method, changing element method, dismantling One or more of the item method, the complement method, the factorization method, the parallel movement method, the function approximation method, the interpolation method, the curve fitting method, the integral method, the differential method, the disturbance method, and the like.
  • the information involved in the calculation process may be obtained from the order information extraction module 410 and the user information extraction module 420, or may be obtained from the database 130 and/or the information source 160.
  • the determining module 440 can be configured to determine whether the order information matches the user feature, or whether the user feature satisfies one or more preset conditions, and the like.
  • the determination process can consider both the order information and the user characteristics, for example, extracting time information (eg, the origination time) in the order information, setting a time threshold (eg, time preference) associated with the user feature, through The difference between the time information in the order information and the time threshold determines whether the order information matches the user characteristics.
  • the decision process may only consider user features, for example, one or more preset conditions associated with user features may be set.
  • the refresh rate threshold may be set, and it is determined whether the user feature satisfies the preset condition by determining the difference between the user's refresh rate and the refresh rate threshold.
  • the preset condition may be a fixed system default value or may be dynamically adjusted in different situations.
  • preset conditions can be dynamically adjusted over time, location, traffic conditions, passenger demand, and the like.
  • the preset conditions can be dynamically adjusted based on the adjustment rules.
  • the adjustment rule may be to set a fixed adjustment parameter at a fixed time in each day, or the adjustment parameter may be changed at a certain time interval (for example, every hour).
  • Pre-set conditions can be related to the order, related to the user's characteristics, or both.
  • the sorting module 450 can be used to sort the users. The sorting process can be based on the degree of matching of the order information with the user characteristics, or the degree of difference between the user characteristics and the preset conditions.
  • the ranking module 450 can be integrated in the decision module 440 or integrated into any of the other modules. In some embodiments, the ranking module 450 can also score the users, set different priorities for the users according to the user rating, and sort the users according to the priority. In some embodiments, when sorting the user, in addition to considering the degree of matching of the order information with the user feature or the degree of difference between the user feature and the preset condition, the user's preference setting may also be considered.
  • the driver can set a parameter related to the passenger's star rating in the personal account (eg, preferentially receive orders from 5-star passengers).
  • passenger preferences may also be considered when sorting users.
  • the passenger can also set a personal preference parameter in the personal account, and when the system sorts the driver, the driver with higher relevance to the passenger's personal preference parameter will be prioritized.
  • the order generation module 460 can be used to integrate order information to generate an order to be dispensed.
  • the characteristics of the order to be dispensed may include the location of the order to be sent, the location of the order to send the order to the driver, the destination of the order, the destination area of the order, the road conditions around the location where the order was sent, the road conditions around the destination of the order, and the order's Dynamic fare increase, number of passengers, whether to carry luggage, whether to receive carpooling, etc.
  • the order generation module 460 can perform format conversion, content modification or adjustment, etc. on the received order information. This format conversion, content change or adjustment, etc. can be based on user settings, such as driver settings. The format conversion, content change or adjustment, etc. may be based on default settings of the on-demand service system 105 or the order processing engine 110.
  • the generated order to be allocated may be a text format, an audio format, an image format, a video format, and the like.
  • the order allocation module 470 can be used to assign an order to be assigned to the user.
  • the order allocation module 470 can be integrated into the driver interface 240.
  • the order allocation module 470 can read the sorting results, user characteristics, order information, judgment results, and the like from other modules in real time or non-real time.
  • the order allocation module 470 can read the user characteristics calculated by the computing module 430 to directly assign an order based on the user characteristics.
  • the order allocation module 470 can also perform order assignment based on the ranking results generated by the ranking module 450.
  • the order allocation module 470 can be integrated with the order generation module 460 in a separate module while implementing the functionality of generating orders and dispensing orders.
  • the order distribution module 470 can send order related information to the passenger, including but not limited to the order information (for example, the driver has received the order), the real-time fare increase information (for example, the dynamic adjustment of the time when the vehicle is used), and the like.
  • the order dispensing module 470 can be integrated into the passenger interface 230.
  • one or more storage modules may be integrated within the processing module 210.
  • the storage module (not shown) is used to store various information and intermediate data extracted, calculated, and/or generated by other modules.
  • each of the sub-modules 410-470 within the processing module 210 may internally integrate a respective storage unit (not shown) for storing information or intermediate data.
  • each of the sub-modules 410-470 in the processing module 210 may be logic-based operations, such as NAND operations, or may be numeric-based operations.
  • Each of the sub-modules 410-470 in the processing module 210 can include one or more processors.
  • the processor can be any general purpose processor, such as a programmed programmable logic device (PLD), or an application specific integrated circuit (ASIC), or a microprocessor, or a system on chip (SoC), etc. It can be a digital signal processor (DSP) or the like.
  • PLD programmed programmable logic device
  • ASIC application specific integrated circuit
  • SoC system on chip
  • DSP digital signal processor
  • Two or more of the respective sub-modules 410-470 may be integrated on one hardware device or two or more hardware devices independent of each other.
  • each of the sub-modules 410-470 in the processing module 210 can be implemented in a variety of ways.
  • the system can be implemented by hardware, software, or a combination of software and hardware, not only by semiconductors such as very large scale integrated circuits or gate arrays, such as logic chips, transistors, etc., or such as field programmable gates.
  • Hardware circuit implementations of programmable hardware devices, such as arrays, programmable logic devices, etc. may also be implemented, for example, by software executed by various types of processors, or by a combination of the above-described hardware circuits and software (eg, firmware). achieve.
  • FIG. 4-B illustrated in FIG. 4-B is an exemplary flow diagram of processing module 210 performing order processing.
  • the order information can be extracted.
  • the order information extraction module 410 can extract the order information. Orders can be real-time orders, reserved orders, or historical orders. Orders may be transmitted by the passenger interface 230 to the processing module 210, or may be read from the storage module 220 in real time or non-real time.
  • Order information can include, but is not limited to, order delivery time, order Single number, departure point, destination, departure time, arrival time, time to wait, number of passengers, whether you are willing to carpool, selected models, presence or absence of baggage, mileage, price, consumer fare increase, service party price adjustment, system price adjustment, Red bag usage, payment method (such as cash payment, credit card payment, online payment, remittance payment, etc.), order completion status, service provider selection order status, consumer order status, etc., or any combination of the above information.
  • the extracted order information may be stored in the order information extraction module 210, or may be stored in the storage module 220, or may be stored in any of the storage devices integrated in the system or independent of the system described in the present application.
  • user information can be extracted.
  • the user information extraction module 420 can extract user information.
  • the user can be a service provider (such as a driver) or a service requester (such as a passenger).
  • User information may include, but is not limited to, basic information (name, nickname, gender, nationality, age, contact information (phone number, mobile number, social account information (such as micro-signal code, QQ number, LinkedIn, etc.), etc.
  • order related information such as historically selected orders, historically cancelled orders, historical order times, historical orders, historical orders, historical orders, historical orders, historical landing system time or time
  • other relevant information such as driving age, age, model, license plate number, driver's license number, additional service capabilities (such as the trunk size of the car, panoramic sunroof, etc.)
  • the historical information of different time periods may have the same influence or may have different influences.
  • historical information of a time period that is relatively close to the current order and historical information of a time period that is far away from the current order interval may have the same effect on the processing result.
  • the historical information of the time period that is close to the current order may also have a greater impact on the processing result, and the historical information of the time period that is far away from the current order interval may have less or no effect on the processing result.
  • user characteristics can be calculated and obtained.
  • the calculation module 430 can calculate user characteristics based on the extracted user information. As shown in FIG. 4-A, the user characteristics may include the similarity between the historical order and the current order, the user preference, the user's refresh rate, the user's grab characteristics, the user response time, and the like. In some embodiments, the order information can be read when calculating user characteristics.
  • the order information and user characteristics can be determined.
  • the decision process can be performed by the decision module 484.
  • the determination process can consider both the order information and the user characteristics, for example, extracting time information (eg, the origination time) in the order information, setting a time threshold (eg, time preference) associated with the user feature, through The difference between the time information in the order information and the time threshold determines whether the order information matches the user characteristics.
  • the decision process may only consider user features.
  • one or more preset condition setting steps (not shown) may be added, which may set preset conditions related to user characteristics, such as but not limited to a cool rate threshold and a grab feature. Curves, response time thresholds, preference thresholds, similarity thresholds, etc.
  • the preset condition setting step (not shown in the figure) is not necessary, and the preset condition may also be the system default or input by the user.
  • the refresh rate threshold may be set, and it is determined whether the user feature satisfies the preset condition by determining the difference between the user's refresh rate and the refresh rate threshold.
  • the determination result may be generated. The result of the determination can be transmitted to the ranking module 450 in real time or non-real time.
  • the user can be sorted.
  • the sorting process can be performed based on the judgment result.
  • the decision process can be performed by the ranking module 450.
  • the sorting process can be set by the user according to the system default rules or all or part of the user.
  • the sorting process can be based on the degree of matching of the order information with the user characteristics, or the degree of difference between the user characteristics and the preset conditions.
  • the user may also be scored during the ranking process (see Figure 4-A for a detailed description).
  • an order to be dispensed can be generated.
  • the process of generating an order to be dispensed may be performed by the order generation module 460.
  • the order to be dispensed can be a real-time order or an order.
  • the characteristics of the order to be dispensed may include, but are not limited to, the location of the order to be sent, the location of the order to send the driver, the destination of the order, the destination area of the order, the road conditions around the location where the order was sent, and the road conditions around the destination of the order. , the dynamic price increase of orders, and so on.
  • the order may also be processed, for example, format processing (including but not limited to text, audio, video, etc.), content processing (eg, adding or deleting portions of content, etc.), and the like.
  • format processing including but not limited to text, audio, video, etc.
  • content processing eg, adding or deleting portions of content, etc.
  • the above process can be performed by the order generation module 460.
  • an order can be assigned to the user based on the ranking result.
  • the order allocation process can be performed by the order allocation module 470.
  • the decision step 484 and the sorting step 485 can be combined into one step, the decision process and the sorting process being performed concurrently or simultaneously.
  • other selection conditions may be added between any two steps, such as storing the results of either step for storage backup, and the like.
  • FIG. 5 is an exemplary system diagram of processing module 210 assigning an order based on order similarity.
  • the similarity calculation unit 431 may include a similarity determination unit 501, and/or a cosine similarity determination unit 501 and a selection/cancellation similarity determination unit 503.
  • the order information extraction module 410 can include an order feature acquisition unit 506 and other units (not shown).
  • the user information extraction module 420 may include a reception feature acquisition unit 504, and/or a selection/cancel feature acquisition unit 505.
  • the judging module 440 may include a snatch probability A determining unit 507, and/or a snatch probability B determining unit 508.
  • the sorting module 450 can include a sorting acquisition unit 509 and other units (not shown).
  • the connection manner between the units shown in FIG. 5 may be wired or wireless, and information communication between the units may be performed.
  • the processing module 210 can read historical orders and current orders.
  • the historical order described herein may refer to a certain time interval from the current time (eg, 5 minutes, 10 minutes, 1 hour, 5 hours, 10 hours, 20 hours, 1 day, 2 days, 5 days, Historical orders within 10 days, one month, etc.).
  • the time interval described here can be system default or can be adjusted in real time depending on the situation. For example, in some embodiments, assuming that a driver has no historical orders within the last 5 days, the time interval can be set to 10 days or more.
  • a smaller time interval may be set under the premise that the statistical results are accurate (for example, 2 days before the current order).
  • the historical order described herein may refer to a historical number of a certain number (eg, 5, 10, 20, 50, 100, etc.) in the near future. Historical order letter
  • the historical order information of different time periods may have the same impact or may have different effects. For example, historical order information for a time period that is closer to the current order and historical order information for a time period that is far from the current order interval may have the same effect on the processing result.
  • the historical order information of the time period that is close to the current order may also have a greater impact on the processing result, and the historical order information of the time period that is far away from the current order interval may have less or no effect on the processing result.
  • the current order described herein may refer to an order sent by the passenger at the current time, or may be an order sent by the passenger before the current time but not allocated.
  • the current order described here can be a real-time order or an appointment order.
  • the current order refers to an order that is intended to be presented to the user or is being presented.
  • the current order may refer to an order that has not been presented to the user, or an order that is being presented to some users but not presented to other users.
  • the current order may be issued directly by the passenger or may be an order forwarded by another intermediary (eg, a website).
  • the order feature acquisition unit 506 can be used to acquire features of the current order.
  • the characteristics of the current order may include, but are not limited to, the location at which the order is sent, the area in which the order is sent, the distance from the location where the order is sent, the distance from the user, the time the order was sent, the time period during which the order was sent, the time at which the order was placed and the time period from which the order was placed, and the appointment
  • the characteristics of the historical order may also include: the time the passenger is willing to wait, the number of passengers, whether to carry large pieces of
  • the receiving feature obtaining unit 504 can be configured to acquire a feature of a historical order received by the user.
  • the "user" in FIG. 5 may refer to "driver.”
  • the characteristics of the historical order received by the user may also include, but are not limited to, the characteristics of the current order described above.
  • the selection/cancellation feature acquisition unit 505 can be used to acquire the characteristics of the historical order selected by the user and the characteristics of the historical order cancelled by the user.
  • the historical order selected by the user herein may refer to an order that the user responds to (the success of the grab or the unsuccessful grab may be considered as the user's order) Out of response), can also refer to an order that the system assigns to the user.
  • the historical order cancelled by the user may refer to an order for which the user has not responded, and may also refer to an order cancelled by the user for some reason.
  • the historical information of different time periods may have the same influence or may have different influences. For example, historical information of a time period that is relatively close to the current order and historical information of a time period that is far away from the current order interval may have the same effect on the processing result. For another example, the historical information of the time period that is close to the current order may also have a greater impact on the processing result, and the historical information of the time period that is far away from the current order interval may have less or no effect on the processing result.
  • the similarity determining unit 501 is configured to determine the similarity between the current order and the historical received order according to the characteristics of the received historical order and the characteristics of the current order.
  • the cosine similarity determining unit 502 can determine the cosine similarity between the current order and the historical received order.
  • the selection/cancellation similarity determining unit 503 can be used to determine the similarity between the current order and the historical order selected by the user, and the similarity between the current order and the historical order cancelled by the user.
  • the cosine similarity determining unit 502 and the selection/cancellation similarity determining unit 503 may be integrated in the similarity determining unit 501.
  • the similarity determining unit 501 may further include one or more other similarity determining sub-units (not shown) for determining other similarities between the current order and the historical order received by the user.
  • the historical order information of the time period that is closer to the current order and the historical order information of the time period far from the current order interval may have the same effect on the processing result.
  • the historical order information of the time period that is close to the current order may also have a greater impact on the processing result, and the historical order information of the time period that is far away from the current order interval may have less or no effect on the processing result.
  • the current order is compared to a historical order selected by the user during a time period from the current order time interval less than or equal to a threshold to evaluate the similarity.
  • the grab single probability A determining unit 507 can be configured to determine the probability that the user selects the current order based on the determined similarity and the characteristics of the current order.
  • the grab probability B determination unit 508 can utilize the machine learning model to determine the probability that the user will select the current order.
  • the machine learning model can include the similarity between the current order and the historical order selected by the user, the current order and The similarity of the historical order cancelled by the user, the characteristics of the current order, and the like.
  • the machine learning model can be updated in real time, or at regular intervals (for example, every day, every two days, every 10 days, every month, etc.), or at specific times of the day (for example, 0:00, 9:00, 12:00, 20:00, etc.).
  • the snatch probability A determination unit 507 and the snatch probability B determination unit 508 may be integrated in the same unit, using a machine learning model or other model, simultaneously or non-simultaneously, to determine the probability that the user selected the current order.
  • the sort acquisition unit 509 can sort the users according to the determined similarity, the characteristics of the current order, and the like. In some embodiments, the ranking acquisition unit 509 can also score the user (see Figure 4-A for a detailed description).
  • processing modules is merely a specific example and should not be considered as the only feasible implementation.
  • Each of the above modules or units may be implemented by one or more components, and the function of each module or unit is not limited thereto.
  • various modifications in the form and details of the specific implementation manners and steps of the processing module may be performed without departing from this principle.
  • changes it is also possible to make some simple deductions or substitutions, and make certain adjustments or combinations of the order of the modules or units without any creative work, but these modifications and changes are still within the scope of the above description.
  • a storage unit can be added to store intermediate data or processing results generated during the operation of each unit or module.
  • one or more units may be integrated in the same unit to implement the functionality of one or more units.
  • Each unit indicated by a broken line in the figure is not required, and may be added or deleted according to a specific implementation scenario or needs.
  • step 610 features of historical orders received by the user may be obtained.
  • the receiving feature acquisition unit 504 can acquire the characteristics of the historical order.
  • Step 610 can include a step 611 of obtaining features of a historical order selected by the user and features of the historical order cancelled by the user.
  • Step 611 can be performed by the selection/cancellation feature acquisition unit 505. As shown in FIG.
  • the historical order may refer to a historical order within a certain time interval from the current order time, or may be a certain number of historical orders before the current order, or may mean that both conditions are met simultaneously.
  • Historical order During the presentation of historical orders, the user may respond to historical orders in real time or non-real time, such as selecting historical orders, canceling historical orders, establishing settings associated with preferences for selecting orders, and the like.
  • the user selection history order described herein may refer to the user responding to the order (the success of the grab or the unsuccessful grab may be considered as the user responding to the order), or the system may assign an order to the user.
  • the user canceling the order may mean that the user does not respond to the order, and may also mean that the user cancels an order for some reason. In some embodiments, the user has not responded to the historical order and may be considered to have cancelled the historical order. After the user responds to the historical order, the response can be transmitted to the order processing engine 110.
  • historical orders selected by the user, historical orders cancelled by the user, and preferences of the user may be stored in the snatch log.
  • the snatch log can be stored in the user client 140 or the server 105.
  • the snatch log may be stored in the cache of the server 105, such as storing only the snatch log containing nearly 20 user responses in the cache as a historical snatch log.
  • the rush ticket can be updated synchronously according to the predetermined settings. For example, the synchronization update can be performed according to a predetermined period (for example, the latest rush ticket is added every 15 minutes and the old robbed log is deleted).
  • the snatch log can be pre-processed.
  • the pre-processing may include format processing, text processing, and the like.
  • the characteristics of the historical order may include: the location at which the order was sent, the area in which the order was sent, the distance from the location at which the order was sent to the user, the time at which the order was sent, the time period during which the order was sent, the time at which the order was placed, and the time at which the order was placed The time slot, the originating location of the reserved order and the originating area, the destination location of the order, the destination area of the order, the destination type of the order (for example, airport, train station, hospital, school, shopping mall, etc.), where the passenger is located The real-time location, the distance between the real-time location of the passenger and the user, the road conditions around the order origination or destination location, the fare increase of the order (for example, the consumption the passenger is willing to pay, etc.).
  • the characteristics of the historical order may also include: the time the passenger is willing to wait, the number of passengers, whether to carry large pieces of luggage, whether they are willing to carpool, and the like.
  • the characteristics of the historical order may be extracted directly or indirectly from the snatch log.
  • the destination information of the order can be determined directly from the text information of the historical order.
  • the location information of the sent order and the location of the user may be combined The information determines the distance between the location where the order was sent and the user.
  • the text information in the order may be analyzed to determine the destination category.
  • the order feature acquisition unit 506 can acquire an order feature.
  • the current order may be an order placed by a passenger or an order forwarded by another intermediary (e.g., a website).
  • the current order can be a real-time order or an order.
  • the characteristics of the current order may include: the location where the order is sent, the area where the order is sent, the distance between the location where the order is sent and the user, the time when the order was sent, the time period during which the order was sent, the time of the scheduled order, the time of departure, and the time of the reservation.
  • Origination location and origination area destination location of the order, destination area of the order, destination type of the order (eg, airport, train station, hospital, school, shopping mall, etc.), real-time location of the passenger, passengers The distance between the real-time location and the user, the road conditions around the order origination or destination location, the fare increase of the order (for example, the tip the passenger is willing to pay, etc.).
  • the characteristics of the current order may also include: the time the passenger is willing to wait, the number of passengers, whether to carry large pieces of luggage, whether they are willing to carpool, and the like.
  • Step 630 a similarity between the current order and the received historical order can be determined.
  • Step 630 can be performed by the similarity determining unit 501.
  • Step 630 may include step 631 and step 632.
  • steps 631 and 632 respectively determine the cosine similarity between the current order and the received historical order and determine the similarity between the current order and the historical order/user cancelled historical order selected by the user.
  • Step 631 and step 632 may be performed by the cosine similarity determining unit 502 and the selecting/cancelling similarity determining unit 503, respectively.
  • the characteristics of the current order and the characteristics of the historical order received by the user may be represented by a vector.
  • the similarity of the current order to the historical order received by the user can be calculated by the vector.
  • the cosine similarity formula can be used to calculate the cosine similarity between the two vectors to obtain the cosine similarity between the current order and the received historical order.
  • each current order may be represented by a vector such that the similarity of each current order to a historical order received by the user may be determined, respectively.
  • the determined plurality of phases may be determined. The degree of similarity is normalized.
  • a value based on time decay may be integrated into a value between 0 and 1 as a similarity feature value.
  • the similarity between the current order and the historical order selected by the user and the similarity with the historical order cancelled by the user may be integrated into one similarity feature value.
  • Step 640 the current order presented to the user can be selected based on the determined similarity.
  • Step 640 can be performed by decision module 440 and/or sequencing module 450.
  • Step 640 can include step 641 (determining the probability that the user selected the current order) and step 642 (presenting the current order to the user based on the probability).
  • a machine learning model can be utilized to determine the probability that the user selected the current order.
  • the process of determining the probability that the user selects the current order may be implemented by the grab probability A determination unit 507 and/or the grab probability B determination unit 508.
  • the features of the machine learning model can include training features and target features.
  • the training features may include features of a large number of orders received by the server, and the target characteristics may include user responses to those orders.
  • training features and target features may be analyzed, evaluated, predicted, etc. using a local or cloud server (eg, a big data platform), using statistical analysis or the like to determine the probability of the user selecting the current order.
  • the machine learning model can be a logistic regression model, a support vector machine model, or the like.
  • statistical analysis can be utilized to determine the probability that a user will select a current order.
  • the user may be sorted according to the probability.
  • the sorting process can be implemented by the sort acquisition unit 509.
  • the ordering can be based on the magnitude of the probability.
  • the current order can be presented to the user based on the sorting result.
  • the highest ranked user can be selected and presented to the user.
  • the users of the first few eg, the top 3
  • the process of presenting the current order to the user may be implemented by the driver interface 240 and may be presented to the user in the form of a voice announcement or text display. After the end of step 640, it is returned to step 610 to continue a new process.
  • step 610 and step 620 may be performed in any order, and may be performed sequentially or simultaneously.
  • Step 611 can be omitted.
  • any one or more of steps 631 and 632 may be omitted, either combined in one step or broken down into multiple steps.
  • similar processing can be performed for steps 641 and 642.
  • FIG. 7 illustrated in FIG. 7 is an exemplary system diagram of processing module 210 internal preference calculation unit 432.
  • the "user" in FIG. 7 may refer to "driver.”
  • the system can make order assignments based on user preferences. User preference can be entered manually by the user or calculated by the system.
  • the system may extract user information and/or order information and calculate the user preference by the preference calculation unit 432.
  • the preference calculation unit 432 may include a preference area determination section 710 and a preference determination section 720.
  • the preference region determining portion 710 may include a local density calculating unit 701, a cluster cluster forming unit 702, a cluster forming unit 703, a cover radius calculating unit 704, and a preference region determining unit 705.
  • the preference determination portion 720 may include a coordinate acquisition unit 706, a center distance calculation unit 707, and a preference determination unit 708.
  • the local density calculation unit 701 can be configured to calculate the local density ⁇ i of the latitude and longitude coordinate points according to the preset cutoff distance d c .
  • the preset cutoff distance d c may be a system default value or may be calculated by the system according to the destination information of the user history order.
  • a certain time interval eg, 5 minutes, 10 minutes, 1 hour, 5 hours, 10 hours, 20 hours, 1 day, 2 days, 5 days, 10 days, one month, etc.
  • Historical order information eg, a certain number (eg, 5, 10, 20, 50, 100, etc.) of historical order information may be extracted.
  • historical orders for which both conditions are met can be extracted.
  • the latitude and longitude coordinate point herein may refer to a latitude and longitude coordinate corresponding to a location.
  • a latitude and longitude coordinate corresponding to a certain location may be represented as (a, b), where a represents longitude coordinates, and b represents latitude coordinates.
  • ⁇ i can represent the number of coordinate points whose distance from the i-th coordinate point is less than the cut-off distance d c ,
  • the clustering cluster forming unit 702 can be used to generate one or more clustering clusters.
  • center point clustering may be performed on each latitude and longitude coordinate point according to the local density ⁇ i of the latitude and longitude coordinate point i and the preset density threshold rho to form a plurality of cluster clusters.
  • the preset density threshold rho may be set according to the number of historical orders within a preset time period, or may be a system default value. In some embodiments, if the number of historical orders in the preset time period is large, the preset density threshold rho needs to be set to a larger value; otherwise, the preset density threshold rho is smaller.
  • the cluster forming unit 703 can be used to generate one or more clusters.
  • the distance between the center points of any two cluster clusters may be calculated, and cluster clusters whose center point distance is smaller than the preset cluster spacing are selected, and the two cluster clusters are clustered and combined to form Multiple clusters.
  • the preset cluster spacing can be a system default value, or different preset cluster spacings can be set in different situations.
  • the coverage radius calculation unit 704 can be used to calculate the coverage radius of the cluster.
  • the average distance of each latitude and longitude coordinate point within each cluster to the cluster center point may be calculated and used as the coverage radius of the cluster.
  • the coverage radius calculation unit 704 may further include one or more model units (not shown in the figure), and the model unit (not shown) may include one or more mathematical models, one or more simulations. Simulation models, etc. When calculating the coverage radius, different models can be read for calculation.
  • the preference area determining unit 705 can be used to determine a preference area of the user.
  • the center point and coverage radius of the user's destination preference area may be determined based on the cluster center point and coverage radius of each cluster.
  • the same user may have different preference areas in different situations.
  • the preference area of a user may be in a remote area with relatively good traffic conditions.
  • a user may have a different preference area on weekdays and weekends.
  • a time factor or other relevant factor may be considered when determining a user preference area.
  • the coordinate obtaining unit 706 can be configured to acquire latitude and longitude coordinates corresponding to the destination of the order to be allocated.
  • the coordinate obtaining unit 706 may include one or more address resolution units (not shown), and the address resolution unit (not shown) may extract the destination address information and parse the latitude and longitude coordinate information corresponding to the destination address.
  • the center distance calculation unit 707 can be used to calculate the distance between the latitude and longitude coordinates corresponding to the destination of the order to be allocated and the center point of the destination preference area of each user.
  • the central distance calculation unit 707 can include an order destination information buffer (not shown) and a user preference area buffer (not shown).
  • the preference determination unit 708 can be used to determine the preference of each user.
  • the preference L of each user to the destination of the assigned order may be calculated according to the distance and the coverage radius of the destination preference area of each user, and the formula is the following formula (3):
  • a z is the distance between the latitude and longitude coordinates corresponding to the destination of the order to be allocated and the center point of each user's destination preference area, and d is the coverage radius of the user's preferred area.
  • the preference calculation unit 432 may further include one or more user interfaces (not shown in the figure), the user User preference areas, user preferences, and other relevant information can be manually entered through the user interface.
  • the preference calculation unit 432 may also integrate one or more storage units (not shown) for storing any intermediate data or final result generated in each unit calculation or processing.
  • FIG. 8 illustrated in FIG. 8 is an exemplary flow chart for computing a user preference area.
  • the "user" in Figure 8 may be referred to as "driver.”
  • the local density ⁇ i of each latitude and longitude coordinate point i can be calculated according to the preset cutoff distance d c .
  • Step 810 can be performed by local density calculation unit 701.
  • the preset phase distance dc may be a system default value, or may be calculated by the system according to the destination information of the user history order.
  • the preset cutoff distance dc may be set according to the average of the latitude and longitude coordinates corresponding to the historical order destination of the user within a preset time interval (for example, 20 hours) and the historical order quantity of the user within the preset time interval. Specifically, for example, suppose that a user has 5 historical orders in a preset time interval (for example, 20 hours), and the latitude and longitude coordinate set corresponding to 5 historical order destinations is [(110, 80), (112.5, 85). , (115, 90), (117.5, 95), (120, 100)].
  • the starting point of the preset cutoff distance d c can be set to (115, 90), and the length can be set to
  • the local density ⁇ i of the calculated coordinate point can be expressed by the aforementioned formula (1).
  • Step 820 center point clustering is performed on each latitude and longitude coordinate point according to the local density ⁇ i of the latitude and longitude coordinate point i and the preset density threshold value rho to form a plurality of cluster clusters.
  • Step 820 can be performed by cluster cluster forming unit 702.
  • the latitude and longitude coordinate points i can be classified into three categories: when the local density of a certain latitude and longitude coordinate point is greater than the density threshold, then determining The latitude and longitude coordinate point is a cluster center point; when a local density of a latitude and longitude coordinate point is less than the density threshold, and the center point is within the cutoff distance range of the latitude and longitude coordinate point, determining that the latitude and longitude coordinate point is non-aggregated A class center point; when a local density of a latitude and longitude coordinate point is less than the density threshold, and there is no center point within the truncation distance range of the latitude and longitude coordinate point, the latitude and longitude coordinate point is determined to be a noise point.
  • Step 830 calculating the distance between the center points of any two cluster clusters, and screening The cluster cluster whose center point distance is smaller than the preset cluster pitch is clustered, and the two cluster clusters are clustered and combined to form a plurality of clusters.
  • Step 830 can be performed by the cluster forming unit 703.
  • the preset cluster spacing is variable. For example, different users may correspond to different preset cluster spacings; similarly, different time periods may also correspond to different preset cluster spacings.
  • Step 840 an average distance from each latitude and longitude coordinate point in each cluster to the cluster center point is calculated, and the average distance is used as the coverage radius of the cluster.
  • Step 840 can be performed by coverage radius calculation unit 704.
  • an average distance of the cluster center points of each latitude and longitude coordinate point in the cluster is a coverage radius; If a user has multiple clusters of latitude and longitude coordinates corresponding to a historical order destination within a preset time period, respectively calculate an average distance of each latitude and longitude coordinate in each cluster to the cluster center point as each cluster. Cover radius.
  • Step 850 a center point and a coverage radius of the user's destination preference area are determined based on the cluster center point and the coverage radius of each cluster. Step 850 can be performed by preference region determination unit 705.
  • step 820 and step 830 can be combined into one step, ie, the process of generating cluster clusters and generating clusters can be cross-processed.
  • one or more caching steps may be added in the process shown in FIG.
  • any data is preprocessed.
  • one or more preset steps may be added to pre-set any preset values involved in the process, such as a preset cutoff distance, a preset cluster pitch, and the like.
  • FIG. 9 illustrated in FIG. 9 is an exemplary flow chart for calculating user preferences.
  • the "user" described in Figure 9 may be referred to as "driver.”
  • the latitude and longitude coordinates of the order destination and the destination can be acquired.
  • the coordinate obtaining unit 720 can acquire the latitude and longitude coordinates of the order destination.
  • a distance A z between the latitude and longitude coordinates of the destination of the to-be-allocated order and the center point of the destination preference area of each user may be calculated.
  • Step 920 can be performed by the center distance calculation unit 707.
  • Step 930 based on the distance A z and the coverage radius d of each user's destination preference area, the destination preference L of each user to be assigned an order is calculated, and the calculation formula is the aforementioned formula (3). Step 930 can be performed by preference determination unit 708.
  • one or more steps not shown in the figures may also be included in FIG. 9 prior to calculating the destination preference L for each user to be assigned an order.
  • the method may include the steps of: obtaining an originating location where the order to be allocated is located and an originating area where the originating location is located, and further comprising the step of acquiring a user in the originating area.
  • a preset range can be set.
  • the preset range can be the system default value or dynamically adjusted according to different situations.
  • the value of the preset range may be set and adjusted according to information such as traffic volume, specific urban location, and road condition of the current city.
  • the value of the preset range can be set to a larger value; conversely, if the originating area in which the order location is located is in a traffic situation For the area, the value of the preset range should be set to a smaller value.
  • the process shown in FIG. 9 may further include the step of obtaining a destination preference area for each user within the preset range of the origin. In some embodiments, it may further include acquiring historical order information (eg, destination information, latitude and longitude coordinate information corresponding to the destination) of each user within a preset time interval. Historical orders can include orders for different travel modes, such as taxis, buses, express trains, rides, buses, and more. The historical order information may include the departure place, destination, departure time, order amount, and the like of the order.
  • historical order information eg, destination information, latitude and longitude coordinate information corresponding to the destination
  • Historical orders can include orders for different travel modes, such as taxis, buses, express trains, rides, buses, and more.
  • the historical order information may include the departure place, destination, departure time, order amount, and the like of the order.
  • user preferences may be obtained based on the destination information.
  • user preferences may be obtained based on destination information entered by the user on the mobile terminal.
  • the destination information may be a geographic name (eg, upper ground), or one coordinate on the map (eg, latitude and longitude), or a certain range (eg, 2 kilometers near Huilongguan), and the like. For example, you can also set some common destination information to facilitate quick selection.
  • at least one user may be determined for the order. For example, if the destination information obtained from some users is the upper land and the destination of the order is also the upper land, these users can be determined for these orders.
  • the destination information may also be inconsistent with the destination of the order. For example, if the destination of the order is A, the destination information of the user is B, and A and B are inconsistent, but the order of the place A to the B place is more and more concentrated, and the destination information can also be determined for these orders as B. User. Thus, the user is more likely to receive an order to location B after completing these orders.
  • orders for which routes are concentrated can be obtained through big data analytics.
  • statistics, calculations, classifications, and the like of data for a period of time eg, within 1 month of the current time
  • one or more selection factors eg, weather factors, road conditions factors, passenger/driver preference parameters, etc.
  • selection factors eg, weather factors, road conditions factors, passenger/driver preference parameters, etc.
  • user preference may be obtained by statistically analyzing historical user order information.
  • Information elements in historical orders can be assigned weights and user preferences calculated based on weights.
  • the user A may be given a higher priority, and if the difference is very Far, give the user A a lower priority.
  • these information elements can be weighted and summed to obtain the user rating.
  • the user score can be calculated using the following formula (4):
  • v i may represent a normalized score of the information element i
  • w i may represent the weight of the information element i.
  • FIG. 10 is a schematic diagram of the principle of calculating user preferences, in accordance with some embodiments of the present application.
  • the "user" in FIG. 10 may be referred to as "driver.”
  • the corresponding preference degree may be separately calculated according to each preference area. Then, the preference degrees corresponding to the multiple regions are summed to obtain the preference for the order destination. Preference can be obtained by the following formula (5) Calculated to obtain:
  • FIG. 11 is an exemplary system block diagram of an order issuance based on an origination period and an origination area requested by a user.
  • the "user" in FIG. 11 may refer to "driver.”
  • the processing module 210 may include a reservation order information acquiring unit 1101, a reservation order associated information acquiring unit 1102, a user request obtaining unit 1103, a reserved order similarity determining unit 1104, a predetermined order transmitting unit 1106, and/or Storage unit 1105.
  • the user request obtaining unit 1103 may be configured to acquire an origination period and an origination area of the reservation order requested by the user; the reservation order information acquiring unit 1101 may be configured to acquire a reservation order associated with the originating period and the originating area;
  • the association information obtaining unit 1102 may be configured to acquire an origination time and an origination location of the reservation order; the reservation order similarity determination unit 1104 may be configured to determine an origination time and an origination location of the reservation order and an origination period and a start of the user request. The similarity of the hair area.
  • the reserved order transmitting unit 1106 may The sending time, the originating place, and other related order information for sending the reserved order to the user; the storage unit 1105 can be used to store order information, user request information, intermediate data, and the like.
  • the above units and combinations are only one specific implementation of the processing module 210 and should not be considered as the only feasible implementation. Any two or more of the above units may be integrated into one or more modules or units to perform the functions of more than one unit.
  • the above units can communicate with each other, and the connection manner thereof can be wired or wireless.
  • FIG. 12 is an exemplary flow diagram for assigning an order based on an origination period and an origination area requested by a user.
  • the "user" in FIG. 12 may refer to "driver.” It should be noted that only one exemplary flow is given in FIG. 12, and it does not mean that the application must be performed according to the following procedure.
  • one or more Steps can be removed or adjusted.
  • the departure time and the origination location of the passenger reservation order can be obtained.
  • the originating time and origin of the extraction can be stored in the reservation order list.
  • the originating time and the originating place may be extracted by the reservation order information acquiring unit 1101.
  • the originating time and the originating area in which the originating time and the originating location are located may be determined.
  • the originating period and the originating area may be determined by the reservation order associated information acquiring unit 1102.
  • the origination period may refer to a time interval, for example, from 9 am to 10 am.
  • the origination period may refer to a time range, such as January 28, 2016, all day.
  • the origination period may refer to a combination of a time interval and a time range, such as from 9 am to 10 am on January 28, 2016.
  • the originating area may be divided by a feature location, such as a site, a road section, a block, a residential area, a mall, a train station, an airport, and the like.
  • the originating area may be a range of areas, for example, an area within a radius of 5 kilometers centered on the originating location.
  • step 1203 it is determined whether the time difference between the release time and the origination time of the reservation order is less than a predetermined threshold.
  • the predetermined threshold may be a system default (eg, 15 minutes) or may be set by the user. If the time difference is less than the predetermined threshold, then the reserved order is considered to be a real-time order, and the order is assigned to the driver in the originating area as a real-time order at step 1204. If the time difference is greater than the predetermined threshold, then at step 1205, the origination time, origination location, origination period, and origination area of the order are stored. In some embodiments, step 1203 is not required and the order origination time, origination location, origination period, and origination area may be stored directly.
  • an origination period and an origination area requested by the driver are obtained.
  • the user request acquisition unit 1103 can acquire the origination period and the origination area requested by the driver.
  • the driver may select an origination period from a predetermined list of origination periods and/or select an origination area from a predetermined list of originating regions.
  • the originating period in the initial period list may be divided into a certain time interval (for example, 15 minutes, specifically, 10:00-10:15 in the morning), and the originating area in the originating area list It can be divided in a certain geographical location (for example, each site, road segment or block).
  • the originating area and/or the originating period may be pre-set by the driver, such as the time of day out of the car and the time of departure. region.
  • the driver can adjust the originating period and the originating area in real time, ie the driver can send the request in real time.
  • an appointment order associated with the originating period and the originating area may be acquired.
  • Step 1207 can be performed by the reserved order similarity determining unit 1104.
  • the order associated with the originating period and the originating area is that the originating time is within the originating period and the originating location is within the originating region.
  • the origination period of the reservation order and the origination area may be compared or compared with the origination period and the origination area requested by the user, and the origination period and the origination area requested by the user are determined according to the similarity degree.
  • Related appointment orders In some embodiments, a reservation order associated with the originating time period and the originating area may be retrieved in a predetermined reservation order list.
  • the reservation order list may be pre-stored in any one of the system's built-in or independent system storage devices.
  • the reservation order list may store a plurality of reservation orders requested by a plurality of passengers, and may store information such as an origination time, an origination period, an origination location, and an origination area of the plurality of reservation orders. Additionally or alternatively, the reservation order list may also pre-store information such as the destination point of the reservation order, the number of guests, whether the old/children are carried, whether to receive the fare increase, and whether or not to carry the bulky baggage.
  • the reservation order is sent to the driver.
  • the reservation order transmitting unit 1106 can send a reservation order to the driver.
  • the driver's departure time and origination location may be sent to the driver.
  • the driver can receive the selection of the reservation order, and according to the selection, send the contact information of the reservation order to the driver.
  • one or more monitoring steps may also be included for monitoring whether an order has been placed.
  • one or more time differences can be calculated. As an example, the time difference from the time when the reservation order is stored in the reservation order list to the departure time of the reservation order, the time difference from the current time to the departure time of the reservation order, and the like.
  • one or more time thresholds may be set at the monitoring step. It is monitored whether the reserved order has been received by calculating whether one or more of the time differences described above meet the one or more time thresholds described above. As an example, if the scheduled time of the scheduled order is after 24 hours, the scheduled order may be monitored for receipt at regular intervals (eg, 1 hour). If the time difference from the departure time of the scheduled order is short (eg 6 hours), you can increase the priority of the reservation order, for example, provide priority order, or provide incentives to drivers.
  • the passenger issues an appointment order, which may include the departure time and origination location of the passenger.
  • appointment order which may include the departure time and origination location of the passenger.
  • the reservation orders issued by the four passengers A, B, C, and D are as shown in Table 1 below.
  • the system After receiving the reservation order list, the system first determines whether the time difference between the time when the reservation order is issued and the departure time of the reservation order is less than a predetermined time threshold (for example, 15 minutes). If the time difference is less than the predetermined time threshold, the system treats the reserved order as a real-time order and sends it to the driver in the originating area. As shown in Table 1, since the time difference between the time when the passenger A issues the reservation order and the departure time is only 10 minutes, which is less than the predetermined time threshold of 15 minutes, the reservation order issued by the passenger A will be used as a real-time order and sent to the vicinity of Fengtai Road. Driver.
  • a predetermined time threshold for example, 15 minutes
  • the system will determine the originating period in which the originating time is located and the originating area in which the originating location is located. As shown in Table 1, the time difference between the time of the reservation order issued by passengers B, C and D and the time of its origination is not less than the predetermined time threshold of 15 minutes, so the system will determine the appointments issued by passengers B, C and D. The originating period and the originating area of the order.
  • the system-determined origination period and origination area can be as shown in Table 2 below.
  • Table 2 shows examples of the originating period and the originating area
  • the system can be based on the system default fixed rule (for example, the interval of the originating period is 15 minutes, and the range of the originating area is within 5 km of the origin radius). ), can also be based on a dynamic rule, different dynamic rules can be used in different situations. For example, when the originating location is relatively remote, the range of the originating area may be a range in which the starting point is a radius of 10 km. For another example, the originating time may be set to 1 hour or longer in the middle of the night or in the early hours of the morning.
  • the system may store the originating time, the originating period, the originating place, and the originating area of the reserved order in any one of the system or any storage device related to the system.
  • a list of reserved orders including the above-described originating period and originating area may be generated.
  • the list of reservation orders may also include the contents shown in Table 3 below.
  • the driver can request the departure time and the origination area of the reservation order. For example, the driver can select the departure time period from 15:00-15:15 from the predetermined departure time list, and start from the scheduled time. In the hair area, select the starting area Xizhimen.
  • the system can retrieve and obtain an appointment order that matches the origination period and the origination area from the reservation order list. For example, the system can retrieve and retrieve reservation orders for Passenger C and Passenger D in any storage device that stores a list of reserved orders.
  • the system can send the reservation order to the driver and the originating time and originating place of the reservation order.
  • the system may also send the driver additional information related to the appointment order, such as destination information.
  • the appointment order sent to the driver can be as shown in Table 4 below.
  • the above example merely describes an example process of assigning an order to a driver based on the originating period and the originating area requested by the driver, and does not mean that the specific implementation manner of allocating an order to the driver according to the originating period and the originating area requested by the driver is limited thereto.
  • FIG. 13 illustrated in FIG. 13 is an exemplary system block diagram of processing module 210 assigning an order based on a user's cool rate.
  • the "user" in FIG. 13 may refer to "driver.”
  • the processing module 210 may include a request receiving unit 1301, an order generating unit 1302, a feedback receiving unit 1303, a refresh rate calculating unit 433, and an order allocating unit 1304.
  • the request receiving unit 1301 may be configured to receive a car request from a passenger.
  • the order generating unit 1302 can be configured to generate order information based on the car request.
  • the order information may include the origination time, the origination location, the destination, the number of passengers, and the like.
  • one or more order push units (not shown) may also be included.
  • One or more order push units may be used to push order information to one or more user terminals (eg, driver clients), for example, to n terminals, n being an integer not less than one.
  • the feedback receiving unit 1303 can be configured to receive a snatch request fed back by the terminal.
  • the terminal that has subscribed to the snatch request may be marked as a feedback terminal.
  • the cool rate calculation unit 433 can be used to calculate the saturation rate of the feedback terminal (see FIG. 4-A for details).
  • Order allocation The unit 1304 can be configured to select one or more target terminals from the feedback terminal according to the calculated saturation rate, and allocate the order information to the target terminal.
  • the refresh rate calculation unit 433 may include a mapping table storage unit (not shown), or the mapping table storage unit (not shown) may be integrated in any other unit or module.
  • a mapping table storage unit (not shown) stores a correspondence between the user terminal and the refresh rate.
  • the order assigning unit 1304 can directly read the refresh rate information of the user terminal from the mapping table storage unit (not shown), and allocate an order to the user terminal according to the refresh rate information.
  • FIG. 14 illustrated in FIG. 14 is an exemplary flow chart for assigning an order based on a user's cool rate.
  • the "user" in FIG. 14 may be referred to as "driver.”
  • the passenger request issued by the passenger is received.
  • the request receiving unit 1301 can receive a car request issued by the passenger.
  • the car request can be issued by the passenger terminal, which can include a mobile phone, a tablet, a palmtop, a laptop, a desktop computer, and any other terminal device having similar functions.
  • the car request can include departure time, departure address, destination address, passenger location, number of passengers, and the like.
  • the passenger address may be determined by the positioning device of the passenger terminal (eg, a GPS device) or manually by the passenger.
  • order information may be generated based on the received vehicle request.
  • the order generation process can be implemented by the order generation unit 1302. This step can be integrated into the order information.
  • the format of the order information can be a text format, an image format, an audio format, or a video format.
  • the order information can be generated by the order generating unit 1302.
  • the generated order information can be stored in any of the storage devices as described in any of the embodiments of the present application.
  • the order information is pushed to n terminals, where n ⁇ 1, and the terminal is a driver terminal.
  • the push order process can be implemented by the order generating unit 1302.
  • the driver terminal can reflect the driver's location information.
  • the list of terminals that will push the order information can be determined according to the origination position of the order and the location information of the driver.
  • a distance threshold may be set, the originating position of the order as a starting point, and the driver terminal within the distance threshold range is added to the terminal list.
  • Distance The threshold can be the system default (for example, 3 kilometers), or it can be adjusted in real time depending on the situation. For example, when traffic is congested, the distance threshold can be set to a small value (for example, 1 km). For another example, when the originating position is relatively remote, the distance threshold can be set to a large value (for example, 8 kilometers).
  • Step 1404 a grab request sent back by the driver terminal is received, and the terminal that has fed back the grab request is marked as a feedback terminal.
  • Step 1404 can be performed by feedback receiving unit 1303.
  • the driver's cool rate is calculated.
  • the cool rate can be obtained by calculation or by retrieving the mapping table.
  • the saturation rate can be calculated by the following formula (6):
  • T x can be a cool rate
  • k can be the number of cool orders in the last n orders allocated by the feedback terminal x.
  • the combination number of k can be selected as n, and p can be the average refresh rate.
  • the average cool rate p can be calculated by the following formula (7):
  • V is the total number of cool orders for all driver terminals
  • S is the total number of orders for all driver terminals.
  • the calculated saturation rate can be stored in a mapping table storage unit (not shown).
  • the freshness rate can be obtained from a retrieval map.
  • the reasons for the cool-up can be basically divided into two categories, one is the coolness caused by the fact that the order cannot be completed due to some force majeure; the second type is the malicious grace (for example, the driver grabs the better or more interested). Orders, or just the roadside passengers need to use a car, etc.).
  • a screening step (not shown) can be added when calculating the saturation rate.
  • the screening process can be accomplished by analyzing some information related to the driver or the order. As an example, the location where the driver terminal responds to the grab request and the location of the passenger who issued the order may be obtained.
  • the behavior of the driver to express the order is defined as the cause of force majeure. Lead to a cool contract, the subsequent screening will be such that the order does not participate in the calculation of the rate. As yet another example, for some cool orders with passenger complaints, it can be defined as a malicious grace. As a further example, the passenger or driver can submit the reason for cancellation to the system when the order is cancelled, and the system can read the reason for canceling the order, from And to determine whether the cool order is a malicious and cool behavior.
  • the driver's cool rate is less than a predetermined threshold.
  • the preset threshold described herein may be a system default value or may be adjusted in real time as needed. As an example, assume that the driver terminals a, b feedback the grab request, if the cool rate of the terminal a is 0.2, the cool rate of the terminal b is 0.99, and if the preset threshold is 0.98, the terminal b is directly excluded. Terminal a is selected as the target terminal. However, it is assumed that the three terminals of the driver terminals a, b, and c all feed back the grab request.
  • the terminal b can be directly excluded, and one of the terminals a and c is selected as the target terminal.
  • the selection may be made in a variety of ways, such as selecting terminal a with a lower rate of saturation as the target terminal. For another example, a terminal closer to the departure address in the terminals a and c is selected as the target terminal. For another example, one of the driver terminals a, c is randomly selected as the target terminal.
  • an order may be assigned to the selected user terminal based on the selection result.
  • the order allocation process can be performed by order allocation unit 1304.
  • the "user" depicted in Figure 15 may be referred to as a "driver.”
  • the grabbing characteristic of the user within the preset time period is obtained.
  • the process of obtaining the snatch feature can be implemented by the snatch feature calculation unit 434.
  • the grabbing characteristic may be a feature of each user's grab probability as a function of time.
  • the user grabbing characteristics may be acquired periodically, or the user grabbing characteristics may be acquired non-periodically.
  • the feature of obtaining the user's sneak sneak is obtained at a fixed time. For example, the feature of the user is acquired weekly, daily, or hourly.
  • the number of users acquired each time can be one or more.
  • the number of users acquired each time can be the same or different.
  • a data update message is generated.
  • the process of generating a data update message can be implemented by the snatch feature calculation unit 434.
  • the data update message may include, but is not limited to, an order grab feature update directory, and the like. It can be understood that the data update message may also include other information, which is not limited herein.
  • the order grabning feature update directory is generated according to the acquired order grabning characteristic of the user within a predetermined time period.
  • the order rushing feature update directory may include, but is not limited to, a user identifier to be updated. It can be understood that the order rushing feature update directory may also include other information, which is not limited herein.
  • the grabbing characteristics are updated.
  • the process of updating the snatch feature can be implemented by the snatch feature calculation unit 434.
  • the order alert feature of the catalog update user may be updated based on the order grab feature in the order data update message.
  • the order grab feature of the user corresponding to the terminal identifier download identifier in the directory update identifier may be updated according to the order grab feature.
  • the order information may be allocated to the user according to the updated snatching feature of the user.
  • the order allocation process can be implemented by the order allocation module 470.
  • a step of determining may be added after step 1510 to determine if a user's order grab feature requires an update. If yes, proceed to step 1520 to generate a data update message; if not, the process ends.
  • a statistic step can be added after step 1520 to count which users' order grab characteristics change more frequently. Users who frequently change the order grabbing characteristics can conduct appropriate search, investigation, monitoring, etc. according to the actual situation. Variations such as these are within the scope of the present application.
  • the above description about the process of updating the feature of the grab is applicable not only to the update of the grab feature but also to the update of other information.
  • the update may be one or more of an update to the user's vehicle status (eg, fuel remaining amount, fuel consumption rate, etc.), user's habit/like update, and the like.
  • the user's habits/like preferences may include, but are not limited to, passengers' preferences for departures, destinations, departure times, passengers' preferences for service providers, waiting times that passengers can accept, passengers' preferences for spelling, Passenger preferences for types of vehicles (eg, aircraft, trains, ships, subways, taxis, buses, motorcycles, bicycles, walking, etc.), passengers for business types (eg, taxis, express trains, special cars, rides, Bus, car rental, driver's preference, passenger's preference for vehicle model, service provider's preference for departure point, destination, departure time, service provider's preference for driving route, service party's working time, service party's cool appointment
  • the order time information of the order and the grab time information are collected.
  • the process of collecting the broadcast time information and the grab time information may be implemented by the user information extraction module 420.
  • the order time information of the order and the grab time information are collected, and the play time information and the grab time information are saved to form a log.
  • the order time information of the order may be a point in time when the order information is broadcast to the user.
  • the grab time information of the order may refer to a point in time when the user subscribes to the order information.
  • the manner of the collection may be automatically obtained by the processing module 210.
  • the processing module 210 may send the order time information and the grab time information of the order after the collection request is sent to the user, or the user may actively upload the order.
  • the broadcast time information and the grab time information are not limited herein.
  • the collection of the order time information and the grab time information of the order may be periodic or non-periodic. Periodically collecting the ordering time information and the grabbing time information of the order means acquiring the user's grabbing characteristics at regular intervals, such as collecting the ordering time information and the grabbing time information of the order every week, every day or every hour.
  • the number of users collected each time can be one or more. The number of users collected each time can be the same or different.
  • the broadcast time information and the grab time information of the plurality of orders of the user within a predetermined time are read.
  • the process of reading the broadcast time information and the grab time information may be implemented by the grab characteristics calculation unit 434.
  • the plurality of logs are summarized, and the time information of the plurality of orders of the user in the predetermined time period and the time information of the rushing time are obtained. interest. In some embodiments, it may be read and summarized immediately after collecting the broadcast time information and the grab time information, or may be read and summarized over a period of time, which is not limited herein.
  • the order rushing characteristic of the user within the predetermined time period is obtained according to the phonon time information and the rushing time information of the plurality of orders of the user in the predetermined time period.
  • the process of obtaining the grabbing characteristic can be implemented by the grabbing characteristic calculation unit 434. Specifically, for each user, analyzing a difference between the broadcast time information and the grab time information of each order corresponding to the user, determining a characteristic that the user's grab probability in the predetermined time period changes with time, and obtaining the User's order grabbing feature.
  • the preset time period for the grabbing feature may be fixed, or may be adjusted according to actual conditions. For different users, the preset time period for the grabbing feature may be the same or different.
  • FIGS. 17-A and 17-B are schematic diagrams of the grabbing characteristics of two different users within a predetermined time period, respectively.
  • the "user" described in Figures 17-A and 17-B may be referred to as "driver.”
  • the grabbing characteristics in the figure are based on the statistics of the grabbed data of two users from November 30, 2014 to December 29, 2014.
  • the coordinate 0 point can indicate the point in time when the order information is broadcast to the user.
  • Figure 17-A it is the grabbing feature of User 1.
  • the probability that the user 1 grabs the ticket within 0 to 5 seconds is high, and the probability of grabbing the ticket after 5 seconds is basically zero.
  • the probability that the user 2 grabs the ticket within 5 to 20 seconds is high, and the probability of grabbing the ticket within 5 seconds is substantially zero.
  • the comparison shows that the grab speed of the user 1 is greater than the grab speed of the user 2.
  • two uses The possibility of grabbing orders will be less and less. After the time point 0 is very long, the two users basically have no possibility of grabbing the order.
  • the user ticketing characteristics and related information may be stored in the order allocation engine 110 or stored in any of the storage devices described in this application.
  • the processing module 210 can perform order allocation based on certain pre-conditions according to the grabbing characteristics of the user.
  • the preset condition can be the default of the system or can be adjusted in real time according to the situation.
  • the snatch feature may be information about changes in the user's snatch request over time.
  • the system can assign orders to users according to the grabbing characteristics of users in different time periods. Specifically, for example, if the user grabbing characteristic indicates that the user is rushing to order more frequently at 10 am every day, the system can allocate an order to the user within a certain time interval before or after 10 am every day.
  • a user request to respond to the order is received.
  • the process of receiving a user request to respond to an order may be implemented by the order information extraction module 410.
  • a user request from the user to respond to the order may be received after the order is placed.
  • the order may be a real-time order, may be an order, or may be an order of other forms, which is not limited herein.
  • a user response time is determined.
  • the process of determining the user response time can be implemented by the response time calculation unit 435.
  • the user response time corresponding to the user request is determined.
  • the user response time may be a time interval from when the order is placed to when the user's response request is received.
  • a user request to be selected is determined.
  • the process of determining the user request to be selected may be implemented by the response time calculation unit 435.
  • a candidate user request for an order is determined based on the user response time determined at step 1820.
  • the manner of determining the user request to be selected may be determined by using a comparison of the user response time with a predetermined threshold (eg, a predetermined response time), may be determined according to the historical response time data of the user, and may be based on User response time is sent and received at all
  • a predetermined threshold eg, a predetermined response time
  • one of the user requests is processed.
  • the process of processing one of the user requests can be implemented by the ranking module 450.
  • one of the user requests may be selected from the candidate user requests determined at step 1830 for processing while rejecting other user requests.
  • one user may be randomly selected from among the users to be selected for processing, or one user may be selected to be processed among the selected users according to certain indicators.
  • the indicator may include but is not limited to the response time of the user, the distance between the ordering user and the departure place in the order, the travel time between the ordering user and the departure place in the order, the expected income of the order, and the direction of the order destination.
  • the user habits/like preferences may include, but are not limited to, a consumer's preference for a departure place, a destination, a departure time, a consumer's preference for a service party, a wait time acceptable to the consumer, and a consumer's preference for the order.
  • Consumer preferences for types of vehicles eg, aircraft, trains, ships, subways, taxis, buses, motorcycles, bicycles, walks, etc.
  • consumers' type of business eg, taxis, express trains, special vehicles, Preference for the ride, bus, car rental, driver's license, consumer preferences for the vehicle model, service provider's preferences for departure, destination, departure time, service provider's preference for driving directions, service party's working hours,
  • one of the user requests may be selected for processing in the candidate user request based on only one indicator. For example, the user can only select according to the response time of the user, and the user with the shortest response time can be selected to deliver the order. For example, the user can select only the distance between the order user and the departure place in the order, and the user with the shortest distance between the order user and the departure place in the order can be selected to place the order.
  • one of the user requests may be selected for processing in the candidate user request based on a plurality of indicators. For example, it can be based on the distance between the ordering user and the departure point in the order.
  • the response time of the user is two indicators, and each is given a weight, and the score is calculated separately for each candidate user by using the distance between the order user and the departure place in the order and the response time of the user based on the weight.
  • the order is issued to the highest rated candidate.
  • a statistical step may be added after step 1820 to count which user's response times are often part of an unreasonable response time range. For these users, appropriate measures such as searching, investigating, monitoring, setting permissions, and adding blacklists can be taken according to the actual situation. Variations such as these are within the scope of the present application.
  • step 19 is an exemplary flow chart for determining a request for a user to be selected, in accordance with some embodiments of the present application.
  • the user response time is determined (see step 1820 for details).
  • step 1930 it is determined whether the user response time is greater than the second predetermined time interval T 2 .
  • the second predetermined time interval T 2 may be greater than the first predetermined time interval T 1 .
  • the first predetermined time interval T 1 may be set to a time difference that is significantly out of a reasonable time interval, and the second predetermined time interval T 2 is set to a time difference that is significantly within a reasonable time interval. .
  • the first predetermined time interval T 1 and the second predetermined time interval T 2 may be set based on a user reaction time, a time required to send an order, and a time required to receive a user request.
  • the user response time may include, but is not limited to, a combination of one or more of a time required by the user to understand the order information, a time required by the user to make a decision, and the like.
  • the time required for the user to understand the order information may include, but is not limited to, a combination of one or more of the time required for the user to view the order, the time required for the voice order broadcast, and the time required for the video order to play.
  • the time required to send the order and the time required to receive the user request may be set according to the transmission rate of the mobile network operator.
  • the user is assumed that the normal order of the reaction may be the fastest time t 1, can be the slowest t 2, where t 2> t 1.
  • the time required to send an order can be t 3
  • the time required to receive a user request can be t 4 .
  • the second preset time interval T 2 t 2 +t 3 +t 4 .
  • setting the first predetermined time interval T 1 is 1.7 seconds and the second predetermined time interval T 2 was 3.2 seconds.
  • step 1940 may be performed to determine whether the number of user requests is greater than a predetermined threshold. .
  • step 1940 it is determined if the number of user requests is greater than a predetermined threshold.
  • the decision process can be implemented by the decision module 440. If the number of user requests is greater than the predetermined threshold, proceed to step 1950 to reject the user request; if the number of user requests is less than or equal to the predetermined threshold, proceed to step 1960 to determine that the user request is for the user request to be selected.
  • the user requests received for the order in real time may be counted to determine the number N of user requests received for the order.
  • step 1910 step 1930 may be first performed to determine whether the user response time is greater than the second predetermined time interval T 2 .
  • step 1960 If the user response time is greater than the second predetermined time interval T 2 , proceed to step 1960; if the user response time is less than or equal to the second predetermined time interval T 2 , proceed to step 1920 to determine whether the user response time is less than the first predetermined time interval T 1 . If the user response time is less than the first predetermined time interval T 1 , then go to step 1950; if the user response time is greater than the first predetermined time interval T1, then go to step 1940. In some embodiments, after step 1910, it may be determined whether the user response time falls within a predetermined threshold range [T 1 , T 2 ].
  • step 1940 If the user response time falls within the predetermined threshold range, the process proceeds to step 1940; if the user response time does not fall within a predetermined threshold range, it is possible to determine whether the user response time is less than a first predetermined time interval T 1, it is determined whether the user response time is greater than the first Two predetermined time intervals T 2 , or first determining whether the user response time is greater than the second predetermined time interval T 2 , determining whether the user response time is less than the first predetermined time interval T 1 . Variations such as these are within the scope of the present application.
  • FIG. 20 is an exemplary flow diagram of an order allocation, in accordance with some embodiments of the present application.
  • the "user" depicted in Figure 20 may be referred to as a "driver.”
  • an order group including a plurality of orders to be allocated and a user group including a plurality of pending orders users may be acquired.
  • the process of obtaining the order group and the user group may be implemented by the order information extraction module 410 or the user information extraction module 420.
  • the order to be dispensed may be a real-time order or an appointment order.
  • the order to be allocated may be an order that has been created but has not been pushed to the service party, and may be an order that has been pushed to the service party but has not been robbed after a certain period of time, or may be the service party or the consumer after the successful payment of the order. Orders that are cool or broken can also be a combination of the above orders.
  • the status of the pending order user may be an idle state, a status of the order service to be completed, a parcel status, and the like.
  • an order group and a user group may be acquired based on a geographic area.
  • all current orders in a certain geographical area may be determined as an order group, and all current pending orders users in the geographical area are determined as a user group.
  • the geographical area may include a geographical area divided by an administrative area, such as a province, a city, a county, and the like, and may be a geographical longitude and a latitude.
  • the geographical area to be divided may also be a geographical area divided by a business circle, a landmark, or the like. It can be understood that the present application is not limited by the manner in which specific geographical regions are divided.
  • an order allocation method can be determined based on the order group and the user group.
  • the process of determining the order allocation method can be implemented by the processing module 210.
  • step 2020 further includes determining an order allocation based on the order group and the user group, and based on at least one of an order turnover rate, a success rate of the grab, and a billing rate.
  • the order turnover rate refers to the ratio of the final deald order in the order group to all the orders in the order group.
  • the success rate of the grab is the ratio of the number of successful billing operations performed by the user in the user group to the number of grab orders performed by the user.
  • the order rush rate refers to the ratio of the number of rush orders performed by the user in the user group to the order pushed to him and the number of orders pushed to him in the order group. It can be understood that determining the order allocation according to at least one of the order transaction rate, the success rate of the order, and the order grab rate is only one implementation method for determining the order allocation method based on the order group and the user group. Those skilled in the art can use other indicators or other methods to determine the order allocation method based on the order group and the user group in specific technical environments, application scenarios, and design requirements. Among them, other indicators can be the competition probability of the order.
  • determining the order allocation manner according to at least one of an order turnover rate, a success rate of grabbing, and a billing rate of the order may include: calculating an order turnover rate, a success rate of grabbing, and a single order The weighted sum of the rates; and determining the way in which the weighted sum is the largest order allocation, as the determined order allocation method.
  • a person skilled in the art can set the weight between the three indicators according to an actual technical scenario or environment, which can be expressed by the following formula (8):
  • E OrderSuccRate can indicate the order turnover rate
  • E StriveSuccRate can indicate the success rate of the grab
  • E StriveRate can represent the single-single rate
  • E can represent the weighted sum of these three indicators
  • ⁇ 1 , ⁇ 2 , ⁇ 3 can be respectively Indicates the weight value of these three indicators.
  • the setting method of the weight value may include, but is not limited to, a combination of subjective experience method, primary and secondary indicator queuing classification method, expert investigation method, and the like.
  • the way in which the weighting and Emax of the three indicators are maximized is selected as the final determined order allocation method. It can be understood that those skilled in the art can use other methods to comprehensively consider the three indicators to finally determine the order allocation manner.
  • the present application is not limited to the linear weighting method as described above, and the method is only an embodiment of the present application. An example of this.
  • At least one of the following algorithms may be used to determine an order allocation method that maximizes the weighted sum E: exhaustive method, genetic algorithm, ant colony algorithm, tabu search algorithm, simulated annealing algorithm, greedy based Mountain climbing algorithm, etc. It can be understood that those skilled in the art can also use other intelligent algorithms and non-intelligent algorithms to solve the above model, which is not limited in this application.
  • an order in the order group is pushed to the users in the user group based on the determined order allocation method.
  • the process of pushing an order can be implemented by order generation module 460 or order allocation module 470.
  • the determined order allocation method may be to push an order to a user, or to push multiple orders to one user; an order may be pushed to only one user at a time, or at a time. It is pushed to multiple users; you can push at least one order to each user, or you can not push orders to certain users if it is not suitable for the order. It can be understood that the number of the specific push orders and the rules can be selected according to specific technical scenarios and requirements, and the present application does not limit the present.
  • 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 allocation process is merely a specific example and should not be considered as the only feasible implementation. Obviously, for those skilled in the art, after understanding the basic principle of order allocation, it is possible to carry out various amendments to the form and details of the specific implementation manners and steps of the order allocation without departing from this principle. Changes, but these corrections and changes are still within the scope of the above description.
  • the step of adding a data cache in the order allocation process is used to store the current pending order or pending order user, entry of new data, deletion of expired data, and the like.
  • step of data caching may be performed before step 2030 or at the same time as step 20100, step 2020 or step 2030.
  • an initial order allocation manner in determining a process of maximizing the weighting sum, may be generated based on a predetermined rule, and then an initial order allocation mode is optimized using a greedy-based hill climbing algorithm to determine a weighted sum The largest order allocation method. Variations such as these are within the scope of the present application.
  • FIG. 21 is an exemplary flow chart for determining an order allocation method, in accordance with some embodiments of the present application.
  • the "user" depicted in Figure 21 may be referred to as a "driver.”
  • the current order group and user group are obtained (see step 2010 for details).
  • the current probability of grabbing a single for any order is calculated.
  • the process of calculating the grab probability may be implemented by the processing module 210.
  • the order turnover rate, the success rate of the rush, and the rush rate may be separately calculated based on the probability of grabbing any order in the order group by any one of the user groups.
  • the probability of the user i in the user group for the order i in the order group can be expressed as P ij .
  • the order turnover rate, the success rate of the grab and the rate of the order can be expressed as the following formula:
  • the order turnover rate, the success rate of the rush, and the rush rate can be derived from the singularity probability according to other methods. It can be understood that, besides the probability of grabbing the order, the order transaction rate, the success rate of the grab and the rate of the order can be obtained based on other information. This application is not limited herein.
  • the grab probability P ij may be calculated based on state characteristics associated with the pending single user and the user who placed the order.
  • Such status features may include, but are not limited to, the distance between the order user and the departure place in the order, the travel time between the order user and the departure place in the order, the expected income of the order, and whether the order direction of the order is with the user.
  • the user habits/like preferences may include, but are not limited to, a consumer's preference for a departure place, a destination, a departure time, a consumer's preference for a service party, a wait time acceptable to the consumer, and a consumer's preference for the order.
  • Consumer preferences for types of vehicles eg, aircraft, trains, ships, subways, taxis, buses, motorcycles, bicycles, walks, etc.
  • consumers' type of business eg, taxis, express trains, special vehicles, Preference for the ride, bus, car rental, driver's license, consumer preferences for the vehicle model, service provider's preferences for departure, destination, departure time, service provider's preference for driving directions, service party's working hours,
  • the grab probability P ij can be expressed as:
  • X ij can represent a feature vector composed of state features
  • W can represent a weight corresponding to each state feature in X ij , and can be set according to a specific technical scenario and requirement.
  • the setting method of the weight value may include, but is not limited to, a combination of subjective experience method, primary and secondary indicator queuing classification method, expert investigation method, and the like.
  • a model is built and the model is solved to obtain an allocation matrix.
  • the process of solving and obtaining the allocation matrix can be implemented by the processing module 210.
  • the analysis and solution can be performed by modeling based on the order allocation method of the order group and the user group.
  • a service party user can only accept one order at a time, and the same order can be pushed to multiple service parties.
  • the order allocation model can be mathematically modeled as follows:
  • E OrderSuccRate , E StriveSuccRate , and E StriveRate can be core business indicators, and E can be a weighted sum of the above core indicators.
  • the optimization goal of the model can be the weighted and the target is the largest.
  • the order allocation process is merely a specific example and should not be considered as the only feasible implementation. Obviously, for those skilled in the art, after understanding the basic principle of order allocation, it is possible to carry out various amendments to the form and details of the specific implementation manners and steps of the order allocation without departing from this principle. Changes, but these corrections and changes are still within the scope of the above description.
  • the data obtained in the calculation process can be stored as historical data. In the process of establishing a model to solve the distribution matrix, the historical data can be analyzed and solved. Variations such as these are within the scope of the present application.
  • Hypothesis 1 The driver decides whether to initiate a grab request, which is positively related to the distance between the driver and the order. The closer the driver is to the order, the more the driver is willing to grab the bill. The farther the distance is, the less likely the driver is to grab the bill. Hypothesis 2: If the driver is very far from the order, the driver will hardly participate in the grab, because the pick-up will be long distances, resulting in low returns. Hypothesis 3: After the passenger places an order, there is a certain degree of patience. If the driver does not answer the card for a long time, the passenger will cancel the order.
  • order 1 is 500 meters from driver 1 and 400 meters from driver 2; order 2 is 2000 meters from driver 1 and 500 meters from driver 2.
  • order group all the current passengers (orders) as a whole are recorded as an order group, and all current pending orders (drivers) as a whole are recorded as a user group.
  • the order group and the user group are allocated.
  • the unit, therefore the model is an order-driver many-to-many order allocation system.
  • Current driver and driver status feature information may include, but is not limited to, pending orders and subscriptions
  • the distance between the departure place in the order, the travel time between the order user and the departure place in the order, the expected income of the order, the passenger fare increase, whether the passenger destination direction is consistent with the user's expected driving direction, and the order destination order Difficulty, road congestion, weather conditions, user's vehicle status (eg, fuel remaining, fuel consumption rate, etc.), user habits/likes, other influences, orders, and orders One or a combination of factors, etc.
  • the global target of the platform is the turnover rate E of all orders
  • the machine learning method can be used to train the estimate.
  • the training sample is the historical broadcast order grab data ⁇ Y ij
  • X ij represents a number of feature vectors for the push time, including but not limited to the distance between the pending order user and the departure place in the order, between the ordering user and the departure place in the order.
  • Driving time expected revenue of the order, passenger fare increase, whether the passenger destination direction is consistent with the user's expected driving direction, the difficulty of order destination order, road congestion, weather conditions, user's vehicle status (eg, fuel One or a combination of factors such as the remaining amount, fuel consumption rate, etc., user habits/likes, other factors affecting the order of the order to be received by the ordering user, and Y i indicates whether the driver has robbed after the push. Single, 1 is the grab, and 2 is the unsold.
  • the prediction model can use the LR model widely used in the industry (similar models as well as linear regression, svm, gbdt, etc.).
  • the LR model expresses the probability estimate as the following formula (15):
  • X ij may be a number of feature vectors of the push time
  • W may be a weight corresponding to each feature in X ij .
  • the feature vector may include, but is not limited to, the distance between the pending order user and the departure place in the order, the travel time between the order user and the departure place in the order, the expected income of the order, the passenger fare increase, and the direction of the passenger destination.
  • the user's expected direction of travel is consistent, the difficulty of order destination order, road congestion, weather conditions, user's vehicle status (eg, fuel remaining, fuel consumption rate, etc.), user habits/likes, other influences One or a combination of factors such as the factor of the order to be accepted by the order subscriber.
  • the model is trained with the historical broadcast order record, and then each (order, driver) pair can be predicted online in real time, which is called STR (striVe through rate) estimation.
  • STR trimVe through rate
  • the order allocation method can be modeled in the manner described in FIG. First, the grab probability P ij is calculated, and only one feature of the distance is used here for the sake of simplicity.
  • the weight of the distance feature is 0.001, so the formula for the probability of grabbing can be recorded as:
  • Figure 22 depicts a structure of a mobile device that can be used to implement a particular system disclosed in this application.
  • the user equipment for displaying and interacting with location related information is a mobile device 2200, including but not limited to, a smart phone or a tablet. Brain, music player, portable game console, global positioning system (GPS) receiver, wearable computing device (such as glasses, watches, etc.), or other forms.
  • the mobile device 2200 in this example includes one or more central processing units (CPUs) 2240, one or more graphics processing units (GPUs) 2230, a display 2220, a memory 2260, and an antenna 2210, such as A wireless communication unit, storage unit 2290, and one or more input output (I/O) devices 2250.
  • CPUs central processing units
  • GPUs graphics processing units
  • display 2220 a display 2220
  • memory 2260 a memory 2260
  • antenna 2210 such as A wireless communication unit, storage unit 2290, and one or more input output (I/O) devices 2250.
  • any other suitable components including but not limited to a system bus or controller (not shown), may also be included in the mobile device 2200.
  • a mobile operating system 2270 such as iOS, Android, Windows Phone, etc.
  • applications 2280 can be loaded into memory 2260 from storage unit 2290 and executed by central processor 2240.
  • Application 2280 may include a browser or other mobile application suitable for receiving and processing location related information on mobile device 2200. User interaction with location related information may be obtained by input/output system device 2250 and provided to order processing engine 110, and/or other components of system 100, such as through network 150.
  • a computer hardware platform may be utilized as a hardware platform for one or more of the elements described above (eg, order processing engine 110, and/or Other components of system 100 described in 1-20).
  • 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 (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 23 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. Both computers can be used to implement the particular system in this embodiment.
  • Computer 2300 can be used to implement Any of the components previously described to provide the information needed for on-demand service.
  • the order processing engine 110 can be implemented by a computer such as computer 2300 through its hardware devices, software programs, firmware, and combinations thereof.
  • Only one computer is drawn for convenience, but the related computer functions described in this embodiment for providing information required for on-demand services can be implemented in a distributed manner by a similar set of platforms, a decentralized system. Processing load.
  • Computer 2300 includes a communication port 2350 to which is connected a network that implements data communication.
  • Computer 2300 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 2310, different forms of program storage units and data storage units, such as a hard disk 2370, read only memory (ROM) 2330, random access memory (RAM) 2340, 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 2300 also includes an input/output component 2360 that supports input/output data flow between the computer and other components, such as user interface 2380. The computer 2300 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.
  • 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 cable, fiber optic cable or air.
  • Physical media such as cables, wireless connections, or fiber optic cables that come to the carrier can also be considered as the medium that carries the software.
  • a computer readable medium can take many forms, including but not limited to, a tangible storage medium, carrier medium or physical transmission medium.
  • 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)
  • Tourism & Hospitality (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Development Economics (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Quality & Reliability (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Traffic Control Systems (AREA)

Abstract

一种订单分配的方法及实施该方法的订单分配系统，所述方法包括：接收订单并提取订单信息（481）；提取服务提供者信息（482）并获得服务提供者特征（483）；判断所述订单信息是否与所述服务提供者特征匹配，或判断所述服务提供者特征是否满足预设条件（484），生成判断结果；根据所述判断结果，对所述服务提供者进行排序（485）；生成待分配订单（486）；并且根据所述排序，向所述服务提供者分配所述待分配订单（487）。

Description

一种订单处理方法与系统
交叉引用
本申请要求以下申请的优先权：
2015年2月2日提交的编号为CN201510053500.6的中国申请；
2015年2月6日提交的编号为CN201510065334.1的中国申请；
2015年2月12日提交的编号为CN201510075815.0的中国申请；
2015年3月31日提交的编号为CN201510149155.6的中国申请；
2015年4月13日提交的编号为CN201510174117.6的中国申请；
2015年4月28日提交的编号为CN201510207953.X的中国申请；
2015年9月29日提交的编号为CN201510633919.9的中国申请；
2016年1月19日提交的编号为CN201610035351.5的中国申请；以及
上述申请的内容以引用方式被包含于此。
技术领域
本申请涉及订单处理方法与系统，尤其是涉及一种应用移动互联网技术和数据处理技术的订单处理方法与系统。
背景技术
目前，按需服务应用的使用越来越普遍。以交通服务为例，按需服务系统将订单分配给司机等待司机响应，并从发出响应的司机中选择一个发送订单。为了提高司机的订单响应率和成交率，需要把订单信息和司机的习惯或喜好进行快速的匹配，将司机偏好的订单精确、灵活地推送给司机。
简述
根据本申请的一个方面，提供了一种订单处理方法。该处理方法可以包括：接收订单并提取订单信息；提取服务提供者信息并获得服务 提供者特征；判断所述订单信息是否与所述服务提供者特征匹配，或判断所述服务提供者特征是否满足预设条件，生成判断结果；根据所述判断结果，对所述服务提供者进行排序；生成待分配订单；并且根据所述排序，向所述服务提供者分配所述待分配订单。
根据本申请的另一个方面，提供了一种系统。该系统可以包括：一种计算机可读的存储媒介，被配置为存储可执行模块，和一个处理器，所述处理器能够执行所述计算机可读的存储媒介存储的可执行模块。可执行模块可以包括：订单提取模块，用于接收订单并提取订单信息；服务提供方信息提取模块，用于提取服务提供方信息并获得服务提供方特征；判断模块，用于判断所述订单信息是否与所述服务提供者特征匹配，或判断所述服务提供者特征是否满足预设条件，生成判断结果；排序模块，用于根据所述判断结果，对所述服务提供者进行排序；订单生成模块，用于生成待分配订单；及订单分配模块，用于根据所述排序，向所述服务提供者分配所述待分配订单。
根据本申请的另一个方面，提供了一种计算机可读的存储媒介，被配置为存储可执行模块，并存储信息。所述信息被读取时，所述计算可以执行订单处理方法。该处理方法可以包括：接收订单并提取订单信息；提取服务提供者信息并获得服务提供者特征；判断所述订单信息是否与所述服务提供者特征匹配，或判断所述服务提供者特征是否满足预设条件，生成判断结果；根据所述判断结果，对所述服务提供者进行排序；生成待分配订单；并且根据所述排序，向所述服务提供者分配所述待分配订单。
根据本申请的一个实施例，所述订单信息包括时间、时段、位置及区域。
根据本申请的一个实施例，所述服务提供者特征包括：订单相似度、偏好度、爽约率、抢单特性及响应时间。
根据本申请的一个实施例，所述订单相似度包括历史订单与当前订单的余弦相似度，所述历史订单可以包括确认的订单及取消的订单。
根据本申请的一个实施例，所述偏好度包括偏好区域及偏好时段。
根据本申请的一个实施例，上述订单处理方法及系统进一步包括：从所述服务提供者获得或计算获得所述偏好度。
根据本申请的一个实施例，计算所述偏好区域包括：利用密度峰聚类算法对历史订单目的地的经纬度坐标进行聚类分析。
根据本申请的一个实施例，上述订单处理方法及系统进一步包括：获取所述待分配订单的目的地对应的经纬度坐标；计算所述待分配订单的目的地对应的经纬度坐标与所述服务提供者的目的地偏好区域的中心点的距离Az；根据所述距离Az以及所述服务提供者的目的地偏好区域的覆盖半径d计算所述服务提供者对所述待分配订单的目的地的偏好度L，
Figure PCTCN2016072837-appb-000001
根据本申请的一个实施例，获得所述爽约率包括使用如下公式计算：
Figure PCTCN2016072837-appb-000002
其中Tx为爽约率，k为服务提供者x被分配的最近n个订单中的爽约订单个数，
Figure PCTCN2016072837-appb-000003
为n选k的组合数，p为平均爽约率。
根据本申请的一个实施例，上述订单分配方法与订单分配系统进一步包括：根据所述响应时间，确定针对所述订单的待选服务提供者请求；从所述待选服务提供者请求中选择其中一个服务提供者请求进行处理。
根据本申请的一个实施例，上述订单分配方法与订单分配系统进一步包括：确定一个地理区域，根据所述地理区域确定订单群和服务提供者群；分析所述订单群和所述服务提供者群，确定订单成交率、抢单成功率及听单抢单率；计算所述订单成交率、所述抢单成功率及所述听单抢单率的加权和；根据所述加权和，确定订单分配方式。
附图描述
在此所述的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的限定。在各图中，相同标号表示相同部件。
图1是根据本申请的一些实施例所示的一个包含订单处理引擎的网络环境的示意图；
图2是根据本申请的一些实施例所示的一个订单处理引擎的示意图；
图3是根据本申请的一些实施例所示的订单处理的示例性流程图；
图4-A是根据本申请的一些实施例所示的处理模块的示意图；
图4-B是根据本申请的一些实施例所示的处理模块运作的示例性流程图；
图5是根据本申请的一些实施例所示的根据订单相似度分配订单的示意图；
图6是根据本申请的一些实施例所示的根据订单相似度分配订单的示例性流程图；
图7是根据本申请的一些实施例所示的根据偏好度分配订单的示意图；
图8是根据本申请的一些实施例所示的计算偏好区域的示例性流程图；
图9是根据本申请的一些实施例所示的计算偏好度的示例性流程图；
图10是根据本申请的一些实施例所示的计算偏好度原理的示意图；
图11是根据本申请的一些实施例所示的根据用户请求的始发时段和始发区域分配订单的示意图；
图12是根据本申请的一些实施例所示的根据用户请求的始发时段和始发区域分配订单的示例性流程图；
图13是根据本申请的一些实施例所示的根据爽约率分配订单的示意图；
图14是根据本申请的一些实施例所示的根据爽约率分配订单的示例性流程图；
图15是根据本申请的一些实施例所示的根据抢单特性分配订单的示例性流程图；
图16是根据本申请的一些实施例所示的统计抢单特性的流程图；
图17-A和图17-B是根据本申请的一些实施例所示的用户抢单特性的示意图；
图18是根据本申请的一些实施例所示的根据用户响应时间分配订单的示例性流程图；
图19是根据本申请的一些实施例所示的根据用户响应时间分配订单的具体实施方式的流程图；
图20是根据本申请的一些实施例所示的向用户群分配订单群的示例性流程图；
图21是根据本申请的一些实施例所示的向用户群分配订单群的具体实施方式的流程图；
图22显示的是一个移动设备的结构，该移动设备可以实施本申请中披露的特定系统；和
图23显示的是一个计算机的结构，该计算机可以实施本申请中披露的特定系统。
具体描述
为了更清楚地说明本申请的实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。应当理解，给出这些示例性实施例仅仅是为了使相关领域的技术人员能够更好地理解进而实现本发明，而并非以任何方式限制本发明的范围。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。
如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其他的步骤或元素。
虽然本申请对根据本申请的实施例的系统中的某些模块做出了各种引用，然而，任何数量的不同模块可以被使用并运行在客户端和/或服务器上。所述模块仅是说明性的，并且所述系统和方法的不同方面可以使用不同模块。
本申请中使用了流程图用来说明根据本申请的实施例的系统所执行的操作。应当理解的是，前面或下面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各种步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。
本申请的实施例可以应用于不同的运输系统，不同的运输系统包括但不限于陆地、海洋、航空、航天等中的一种或几种的组合。例如，出租车、专车、顺风车、巴士、火车、动车、高铁、地铁、船舶、飞机、飞船、热气球、无人驾驶的交通工具、收/送快递等应用了管理和/或分配的运输系统。本申请的不同实施例应用场景包括但不限于网页、浏览器插件、客户端、定制系统、企业内部分析系统、人工智能机器人等中的一种或几种的组合。应当理解的是，本申请的系统及方法的应用场景仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。例如，其他类似的用户接单系统。
本申请描述的“乘客”、“顾客”、“需求者”、“服务需求者”、“消费者”、“消费方”、“使用需求者”等是可以互换的，是指需要或者订购服务的一方，可以是个人，也可以是工具。同样地，本申请描述的“司机”、“提供者”、“供应者”、“服务提供者”、“服务者”、“服务方”等也是可以互换的，是指提供服务或者协助提供服务的个人、工具或者其他实体等。另外，本申请描述的“用户”可以是需要或者订购服务的一方，也可以是提供服务或者协助提供服务的一方。
根据本申请的一些实施例，图1所示的是一个网络环境100的示意图。网络环境100可以包括一个或多个按需服务系统105、一个或多个乘客端120、一个或多个数据库130、一个或多个司机端140、一个或多个网络150、一个或多个信息源160。在一些实施例中，按需 服务系统105可以包含一个订单处理引擎110。在一些实施例中，订单处理引擎110可以用于对收集的信息进行分析加工以生成分析结果的系统。订单处理引擎110可以是一个服务器(例如云端服务器)，也可以是一个服务器群组。一个服务器群组可以是集中式的，例如数据中心。一个服务器群组也可以是分布式的，例如一个分布式系统。订单处理引擎110可以是本地的，也可以是远程的。在一些实施例中，订单处理引擎110可以通过网络150访问存取用户120/140的信息、信息源160中的信息、数据库130中的信息，也可以直接访问信息源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)等；移动设备120-4，可以为智能手机、个人数码助理(personal digital assistance(PDA))、平板电脑、掌上游戏机、智能眼镜、智能手表、可穿戴设备、虚拟显示设备或显示增强设备(如Google Glass、Oculus Rift、 Hololens、Gear VR)等中的一种或多种。司机端140也可以包括类似的设备中的一种或多种。
在一些实施例中，数据库130可以泛指具有存储功能的设备。数据库130主要用于存储从乘客端120和/或司机端140收集的数据和订单处理引擎110工作中产生的各种数据。数据库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相互连接或通信时，用户120/140可以通过网络150访问数据库130中的信息。各方对数据库130的访问权限可以是有限制的。例如，按需服务系统105，或其一部分(例如，订单处理引擎110)，对数据库130有最高的访问权限，可以从数据库130中读取或修改大众的或个人的信息；乘客端设备120或司机端设备140在满足一定条件时可以读取部分大众的信息或与用户相关的个人信息。例如，按需服务系统105可以根据一位用户(乘客或司机)的一次或多次使用按需服务系统105的经历更新/修改数据库130中大众的或与该位用户相关的信息。又例如，一位司机在收到一位乘客的服务订单时，可以查看数据库130中关于该乘客的部分信息；但该司机不可以自主修改数据库130中关于该乘客的信息，而只能向按需服务系统105汇报，由按需服务系统105决定是否修改数据库130中关于该乘客的信息。再例如，一位乘客，在收到一位司机的提供服务的请求时，可以查看数据库130中关于该司机的部分信息(如用户评分信息，驾驶经验等)；但该乘客不可以自主修改数据库130中关于该司机的信息，而只能向按需服务系统105汇报，由按需服务系统105决定是否修改数据库130中关于该司机的信息。
数据库130可以泛指具有存储功能的设备。数据库130主要用于存储从用户120/140和/或信息源160收集的数据和订单处理引擎110工作中产生的各种数据。数据库130或系统内的其他存储设备泛指所有可以具有读/写功能的媒介。数据库130或系统内其他存储设备可以是系统内部的，也可以是系统的外接设备。数据库130与系统内其他存储设备的连接方式可以是有线的，也可以是无线的。数据库130与系统其他模块间的连接或通信可以是有线的，也可以是无线的。网络 150可以提供信息交换的渠道。
网络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可以是存储有某一地 域众多餐饮服务商的系统、包含有地图信息与城市服务信息的市政服务系统、交通路况系统、天气播报系统、新闻网络等。上述举例并非用于局限此处的信息源的范围，也并非局限于所举实例这几类服务范围，本发明可以适用于各种服务任何能够提供与相应服务有关的信息的设备、网络，都可以被归为信息源。
基于位置的服务系统，在一些实施例中，该系统内不同部分之间的信息交流可以通过订单方式进行。订单的客体可以是任一产品。在一些实施例中，产品可以是有形产品或无形产品。对于实物产品，它可以是任何有形状大小或的实物，例如食品、药品、日用品、化工产品、电器、衣物、汽车、房产、奢侈品等中的一种或几种的组合。对于无形产品，包括但不限于服务性产品、金融性产品、知识性产品、互联网产品等中的一种或几种的组合。对于互联网产品，它可以是任一满足用户对信息、娱乐、沟通或商务需要的产品。互联网产品有很多分类方法，以其承载平台分类为例，包括但不限于个人主机产品、Web产品、移动互联网产品、商用主机平台产品、嵌入式产品等中的一种或几种的组合。其中的移动互联网产品可以是用在移动终端的软件、程序或系统。其中的移动终端包括但不限于笔记本、平板电脑、手机、个人数码助理(PDA)、电子手表、POS机、车载电脑、电视机等中的一种或几种的组合。例如，在电脑或手机上使用的各类社交、购物、出行、娱乐、学习、投资等软件。其中的出行软件又可以是旅行软件、交通工具预定软件、地图软件等。其中的交通预定软件是指可以用来预约汽车(如出租车、公交车等)、火车、地铁、船只(轮船等)、飞行器(飞机、航天飞机、火箭)、热气球等中的一种或几种的组合。
需要注意的是，以上对于服务系统的描述，仅为描述方便，并不能把本申请限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解该系统的原理后，可能在不背离这一原理的情况下，对各个模块进行任意组合，或者构成子系统与其他模块连接，对实施上述方法和系统的应用领域形式和细节上的各种修正和改变。例 如，数据库130可以是具有数据存储功能的云计算平台，包括但不限于公用云、私有云、社区云和混合云等。诸如此类的变形，均在本申请的保护范围之内。
根据本申请的一些实施例，图2所示的是订单处理的一种示例性系统图。为描述方便，该订单处理的系统以按需服务系统105中的订单处理引擎110为例来说明。订单处理引擎110可以包括一个或多个处理模块210、一个或多个存储模块220、一个或多个乘客接口230、一个或多个司机接口240。订单处理引擎110的模块可以是集中式的也可以是分布式的。订单处理引擎110的模块中的一个或多个模块可以是本地的也可以是远程的。在一些实施例中，订单处理引擎110可以是网页服务器、文件服务器、数据库服务器、FTP服务器、应用程序服务器、代理服务器、邮件服务器等中的一种或几种的组合。
在一些实施例中，乘客接口230与司机接口240可以用于分别从乘客120与司机140接收各自发送的信息。在一些实施例中，乘客接口230与司机接口240可以分别从数据库130和信息源160中读取信息。此处的信息，可以包括但不限于服务的请求信息、服务的接收信息、用户的习惯/喜好信息、用户定位信息等中的一种或几种的组合。其中，服务的请求信息可以是用户的订单请求信息(例如，乘客的打车请求、司机的接单请求等)、用户的其他请求信息(例如，司机向系统发送获取某一区域的订单密度的请求)等。服务的接收信息可以是用户同意接单的信息、用户放弃接单的信息、用户接单成功的信息、用户接单失败的信息等。用户的习惯/喜好信息可以是乘客对于司机的偏好、乘客可以接收的等待时间、乘客对于拼车乘客的偏好、乘客对于车型的偏好、司机对于出发地、目的地、出发时间的偏好等。信息的形式可以包括但不限于文本、音频、视频、图片等中的一种或几种的组合。信息的输入方式可以是手写输入、手势输入、图像输入、语音输入、视频输入、电磁波输入或者其他数据输入方式，或者以上的任意组合。所接收的信息，可以存储于数据库130中，也可以存储在存储模块220中，也可以由处理模块210进行计算与处理。
在一些实施例中，用户定位信息的获取，可以由定位系统完成。例如，可以通过一种或多种定位技术获取用户的当前位置、始发地、运动状态、运动速度等信息。该定位技术可以包括但不限于全球定位系统(GPS)技术、全球导航卫星系统(GLONASS)技术、北斗导航系统技术、伽利略定位系统(Galileo)技术、准天顶卫星系统(QAZZ)技术、基站定位技术、Wi-Fi定位技术、交通工具自带的各种定位测速系统等。
在一些实施例中，乘客接口210与司机接口230可以用于输出经过处理模块210分析处理后的信息。此处的信息，可以是优化后的定位信息、订单的直接信息、订单的处理信息、用户的直接信息、用户的处理信息等。信息的形式可以包括但不限于文本、音频、视频、图片等中的一种或几种的组合。输出的信息可以发送给乘客120和/或司机140，也可以不发送。不发送的输出信息可以存储在数据库130中，也可以存储在存储模块220中，也可以存储在处理模块210中。
在一些实施例中，处理模块210可以用于相关信息的处理。处理模块可以从乘客接口230、司机接口240、数据库130、信息源160等获取信息。处理模块210可以将处理后的信息发送至乘客接口230和/或司机接口240，可以将处理后的信息保存至数据库130或其他备份的数据库或存储设备，也可以将处理后的信息保存在处理模块210中。信息处理的方式可以包括但不限于对信息进行存储、分类、筛选、转换、计算、检索、预测、训练等中的一种或几种的组合。在一些实施例中，处理模块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可以实际存在于系统中，也可以通过云计算平台完成相应功能。其中，云计算平台包括但不限于存储数据为主的存储型云平台、以处理数据为主的计算型云平台以及兼顾数据存储和处理的综合云计算平台。系统所使用的云平台可以是公共云、私有云、社区云或混合云等。例如，根据实际需要，系统接收的一些订单信息和/或非订单信息，可以通过云平台进行计算和/或存储。另一些订单信息和/或非订单信息，可以通过本地处理模块和/或系统数据库进行计算和/或存储。
应当理解，图2所示的系统可以利用各种方式来实现。例如，在一些实施例中，系统可以通过硬件、软件或者软件和硬件的结合来实现。其中，硬件部分可以利用专用逻辑来实现；软件部分则可以存储在存储器中，由适当的指令执行系统，例如微处理器或者专用设计硬件来执行。本领域技术人员可以理解上述的方法和系统可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、CD或DVD-ROM的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本申请的系统及其模块不仅可以有诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用例如由各种类型的处理器所执行的软件实现，还可以由上述硬件电路和软件的结合(例如，固件)来实现。
需要注意的是，以上对于订单处理引擎110及按需服务系统的描述，仅为描述方便，并不能把本申请限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解该系统的原理后，可能在不背离这一原理的情况下，对实施上述方法和系统的应用领域形式和细节上的各种修正和改变。例如，在一些实施例中，订单处理引擎110中，还可以有一个存储模块。所述存储模块可以是系统内部的，也可以是系统的外接设备。所述存储模块可以实际存在于系统中，也可以通过云计算平台完成相应功能。对于本领域的技术人员来说，在 了解该系统的原理后，可能在不背离这一原理的情况下，对各个模块进行任意组合，或者构成子系统与其他模块连接。例如，在一些实施例中，乘客接口230、处理模块210、司机接口240和存储模块220可以是体现在一个系统中的不同模块，也可以是一个模块实现上述的两个或两个以上模块的功能。例如，乘客接口230/司机接口240可以是一个模块同时具有输入输出的功能，也可以是针对乘客的输入模块和输出模块。例如，处理模块210和存储模块220可以是两个模块，也可以是一个模块同时具有处理和存储功能。例如，各个模块可以共用一个存储模块，各个模块也可以分别具有各自的存储模块。诸如此类的变形，均在本申请的保护范围之内。
根据本申请的一些实施例，图3所示的是订单分配的一种示例性流程图。在一些实施例中，该订单分配流程可以由按需服务系统105或其一部分(例如，订单处理引擎110)执行。根据图3所示，订单信息可以在步骤310从用户120/140(详见图1)中被获取。在一些实施例中，在步骤310，也可以获取数据库130和/或信息源160(详见图1)的信息。订单信息的形式可以包括但不限于文字、图片、音频、视频等中的一种或几种的组合。以出租车服务订单为例，订单信息的内容可以包括但不限于订单本身信息、用户信息和其他信息等。订单本身信息可以包括但不限于发送订单的时间、订单编号、出发地、目的地、出发时间、到达时间、愿意等待的时间、乘客人数、是否愿意拼车、选择的车型、有无行李、里程、价格、消费方加价、服务方调价、系统调价、红包使用情况、付款方式(如现金支付、刷卡支付、网上支付、汇款支付等)、订单完成情况、服务方选择订单情况、消费方发送订单情况等，或者上述信息的任意组合。用户信息是指用户120/140的相关信息。用户信息可以包括但不限于姓名、昵称、性别、国籍、年龄、联系方式(电话号码、手机号码、社交账号信息(如微信号码、QQ号码和LinkedIn等)等可以联系到本人的方式等)、职业、评价等级、使用时间、驾龄、车龄、车型、车况、车牌号、驾驶证号、认证情况、用户习惯/喜好、额外服务能力(如车的后备箱大小、 全景天窗等额外特性)等中的一种或几种的组合。其他信息可以指不受消费方、服务方控制的信息，或者是指暂时性/突发性的信息。例如，其他信息可以包括但不限于天气情况、环境情况、道路状况(如因安全性或者道路作业等原因封闭道路)、交通条件等，或者上述信息的任意组合。
在一些实施例中，订单信息的部分内容可以是实时订单信息，可以是预约订单信息，也可以是历史订单信息。其中，实时订单信息可以是在当前时间出发的订单信息。实时订单信息可以包括出发时间、出发地点等。预约订单信息可以是乘客预约的在某个时刻或某个时间段的订单信息。其中，时间段可以是几秒、几分、几小时或者根据喜好自定义的时间段；时间段也可以是特定的时间，例如工作日、休息日、节假日、高峰时段、非高峰时段等。类似地，预约订单信息也可以包含出发时间、出发地点、目的地等信息。需要主要的是，在一些实施例中，如果预约订单的出发时刻与当前时间的时间差比较小(例如1分钟)，可以认为是实时订单。历史订单信息可以包括过去的相关信息，例如，请求订单量、接受订单量、成交量、抢单率、抢单成功率、毁约率、爽约率、成交率、用户习惯/喜好等中的一种或几种的组合。
在步骤320，可以获取用户特征。其中，所述用户特征可以包括但不限于姓名、昵称、性别、国籍、年龄、联系方式(电话号码、手机号码、社交账号信息(如微信号码、QQ号码和LinkedIn等)等可以联系到本人的方式等)、职业、评价等级、使用时间、驾龄、车龄、车型、车况、车牌号、驾驶证号、认证情况、用户习惯/喜好、额外服务能力(如车的后备箱大小、全景天窗等额外特性)等中的一种或几种的组合。用户习惯/喜好可以是乘客对于出发地、目的地、出发时间的偏好、乘客对于司机的偏好、乘客可以接收的等待时间、乘客对于拼车乘客的偏好、乘客对于车型的偏好、司机对于出发地、目的地、出发时间的偏好、司机对于行车路线的偏好、司机的工作时间、司机的抢单速率、司机的响应时间、司机的抢单特性、司机的爽约率、司 机的抢单量、抢单成功量、成交量、抢单成功率、成交率等。所述用户特征可以是根据用户主动输入而直接获取的用户特征，也可以是经由一定的数据处理方式得到的用户特征。信息的处理方式包括但不限于对信息进行存储、分类、筛选、转换、计算、检索、预测、训练等中的一种或几种的组合。
为描述方便，以下对信息处理一些实施例用到的预测模型和机器学习进行说明。在一些实施例中，预测模型可以是定性的，也可以是定量的。对于定量的预测模型，它可以基于时序预测法，也可以基于因果分析法。其中，时间预测法进一步可以包括平均平滑法、趋势外推法、季节变动预测法和马尔可夫时序预测法等中的一种或几种的组合。因果分析法进一步可以包括一元回归法、多元回归法和投入产出法。在一些实施例中，预测模型可以包括但不限于加权算术平均模型、趋势平均预测模型、指数平滑模型、平均发展速度模型、一元线性回归模型、高低点模型中的一种或几种的组合。另外在一些实施例中，对于信息处理所用到的公式、算法和/或模型，可以通过机器学习，不断进行优化。对于机器学习的方法，根据学习方式的不同可以是监督式学习、非监督式学习、半监督式学习或强化学习；根据算法的不同，机器学习的算法可以是回归算法学习、基于实例的学习、正规化学习、决策树学习、贝叶斯学习、聚类算法学习、关联规则学习、神经网络学习、深度学习、降低维度算法学习等。具体来说，对于回归算法模型，可以是最小二乘法(Ordinary Least Square)、逻辑回归(Logistic Regression)、逐步式回归(Stepwise Regression)、多元自适应回归样条(Multivariate Adaptive Regression Splines)或者本地散点平滑估计(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，SOM)或学习矢量量化(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)等。
在步骤330，基于用户特征，分配订单。在一些实施例中，订单处理引擎110可以发送信息，如订单信息，给一个或多个司机端设备140，一个或多个乘客端设备120，一个或多个第三方平台等。发送的订单信息的内容可以包括但不限于订单本身信息、用户信息和其他信息等。订单本身信息可以包括但不限于订单编号、出发地、目的地、出发时间、到达时间、愿意等待的时间、乘客人数、有无行李、里程、价格、消费方加价、服务方调价、系统调价、红包使用情况、付款方式(如现金支付、刷卡支付、网上支付、汇款支付等)、订单完成情况、服务方选择订单情况、消费方发送订单情况等，或者上述信息的任意组合。用户信息是指用户120/140的相关信息。用户信息可以包 括但不限于姓名、昵称、性别、国籍、年龄、联系方式(电话号码、手机号码、社交账号信息(如微信号码、QQ号码和LinkedIn等)等可以联系到本人的方式等)、职业、评价等级、使用时间、驾龄、车龄、车型、车况、车牌号、驾驶证号、认证情况、用户习惯/喜好、额外服务能力(如车的后备箱大小、全景天窗等额外特性)等中的一种或几种的组合。其他信息可以指不受消费方、服务方控制的信息，或者是指暂时性/突发性的信息。例如，其他信息可以包括但不限于天气情况、环境情况、道路状况(如因安全性或者道路作业等原因封闭道路)、交通条件等，或者上述信息的任意组合。发送的信息可以是订单的直接信息，也可以是订单的处理信息，也可以是两种订单信息的组合。发送的订单信息的形式可以包括但不限于文字、图片、音频、视频等中的一种或几种的组合。
需要注意的是，以上关于订单处理流程的描述，仅为描述方便，并不能把本申请限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解本申请的基本原理后，可以在不背离这一原理的情况下，对订单处理流程作出改变。例如，可以增加或减少一些步骤。例如在步骤310之后可以对订单信息进行预处理。预处理过程可以通过数据清理、数据集成、数据变换和/或数据规约等方法去除一些失真的数据。在一些实施例中，具体的失真数据去除方法可以包括但不限于判别法、剔除法、平均值法、拉平法、比例法、移动平均法、指数平滑法、差分法等中的一种或几种的组合。再例如，在订单处理流程中，还可以添加数据存储的步骤。诸如此类的变形，均在本申请的保护范围之内。
根据本申请的一些实施例，图4-A所示的是订单处理引擎110中的处理模块210的示意图。处理模块210可以包括以下模块：订单信息提取模块410、用户信息提取模块420、计算模块430、判断模块440、排序模块450、订单生成模块460、和订单分配模块470。除上述模块之外，处理模块210还可以包括一个或多个其他模块或单元。上述各个模块410-470之间可以相互通信，各个模块之间的连接方式 可以是有线的，也可以是无线的。图4-A中示例性给出了各个模块间的连接方式，但并不表示各个模块间的连接方式仅限于此。
订单信息提取模块410可以用于提取与订单相关的直接或间接的信息。订单可以包括实时订单、预约订单和历史订单。作为示例，订单信息可以包括：订单发送时间、订单编号、出发地、目的地、出发时间、到达时间、愿意等待的时间、乘客人数、是否愿意拼车、选择的车型、有无行李、里程、价格、消费方加价、服务方调价、系统调价、红包使用情况、付款方式(如现金支付、刷卡支付、网上支付、汇款支付等)、订单完成情况、服务方选择订单情况、消费方发送订单情况等，或者上述信息的任意组合。除上述描述外，订单信息还可以包括与订单相关的其他信息，例如乘客信息(例如性别、昵称、联系方式等)和其他不受消费方、服务方控制的信息，或者是指暂时性/突发性的信息。例如，其他信息可以包括但不限于天气情况、环境情况、道路状况(如因安全性或者道路作业等原因封闭道路)、交通条件等，或者上述信息的任意组合。订单信息可以实时提取，也可以非实时提取。提取的订单信息可以存储在订单信息提取模块410、存储模块220、或任何在本申请中所描述的集成在系统中或独立于系统外的存储设备中。
在一些实施例中，订单信息提取模块410还可以包括一个或多个子单元，例如时间信息提取单元(图中未体现)、位置信息提取单元(图中未体现)、解析单元(图中未体现)、处理单元(图中未体现)等。时间信息提取单元可以用于提取与订单相关的时间信息(例如发送订单的时间、预约出发的时间、预约出发时间所处的时段等)。位置信息提取单元可以用于提取与订单相关的位置信息(例如出发地、目的地、出发地所处的区域、出发地周围的交通路况、目的地周围的交通路况等)。解析单元可以用于分析与订单相关的时间信息、位置信息等，例如将位置信息从文字描述转换为地址坐标。文字描述可以指地点的名称、门牌号、建筑名称等中的一种或几种，地址坐标可以指某个地点的坐标信息，例如经纬度坐标。处理单元可以用于处理订 单信息提取模块410所提取的一种或多种与订单相关的信息，处理方式包括但不限于计算、识别、验证、判断、筛选等。
用户信息提取模块420可以用于提取与用户相关的直接或间接的信息，并对这些信息进行识别、整理和归类。用户可以包括乘客或司机。以司机为例，用户信息可以包括历史选择的订单、历史取消的订单、历史接单的时间、历史接单的时段、历史接单的位置、历史接单的区域、历史登陆系统的时间或时段、历史登陆系统时所处的位置或区域、历史的爽约订单等。用户信息可以实时提取，也可以非实时提取。提取的用户信息可以存储在用户信息提取模块420、存储模块220、或任何在本申请中所描述的集成在系统中或独立于系统外的存储设备中。上述提取的订单信息和用户信息可以实时或非实时地传输至计算模块430进行进一步的计算分析，也可以实时或非实时地传输至判断模块440或排序模块450进行进一步的判断或排序。在一些实施例中，订单信息提取模块410与用户信息提取模块420可以集成在同一个模块中，同时实现提取订单信息和提取用户信息的功能。
在一些实施例中，用户信息提取模块420还可以包括一个或多个子单元，例如信息接收单元(图中未体现)、信息解析单元(图中未体现)和信息传输单元(图中未体现)等。信息接收单元可以用于接收或读取用户信息，具体例如，司机所发送的信息可以是经定位技术所确定的司机当前位置、司机所行驶的速度、司机所反馈的当前服务状态(载客、等待载客、空驶)、司机对服务请求的选择、确认或拒绝信息等中的一种或多种。上述信息可以是自然语言文本信息、二进制信息、音频信息(包括司机的语音输入)、图像信息(静止图片或视频)以及其他类型的多媒体信息等中的一种或多种。信息解析单元可以用于对上述信息进行整理或分类，例如转换为可读取或可存储的格式等。信息传输单元可以用于接收或发送信息，可以包括一个或多个有线或无线的收发设备。
计算模块430可以用于计算获得用户特征。用户特征可以包括历史订单与当前订单的相似度、偏好度、爽约率、抢单特性、响应时间 等。计算模块430可以包括相似度计算单元431、偏好度计算单元432、爽约率计算单元433、抢单特性计算单元434、响应时间计算单元435、以及其他一个或多个用户特征计算单元等。计算模块430内部还可以集成一个或多个存储单元(图中未体现)，用于存储计算获得的司机特征。计算获得的用户特征可以实时或非实时地传输至判断模块440或排序模块450进行进一步的分析处理。计算方法可以包括但不限于最小-最大标准化、Z-score标准化、按小数定标标准化、线性函数法、对数函数法、反余切函数法、范数法、历史阈值迭代、建模法、最小二乘法、消元法、降次法、代入法、图象法、比较法、放缩法、向量法、归纳法、反证法、穷举法、配方法、待定系数法、换元法、拆项法、补项法、因式分解法、平行移动法、函数逼近法、插值法、曲线拟合法、积分法、微分法、扰动法等中的一种或多种。计算过程中所涉及的信息可以从订单信息提取模块410和用户信息提取模块420获取，也可以从数据库130和/或信息源160中获取。
判断模块440可以用于判断订单信息与用户特征是否匹配、或用户特征是否满足一个或多个预设条件等。在一些实施例中，判断过程可以同时考虑订单信息和用户特征，例如，提取订单信息中的时间信息(例如始发时间)，设定一个与用户特征相关的时间阈值(例如时间偏好)，通过订单信息中的时间信息与时间阈值的差别，确定订单信息是否与用户特征相匹配。在一些实施例中，判断过程可以仅考虑用户特征，例如，可以设定一个或多个与用户特征相关的预设条件。具体例如，可以设定爽约率阈值，通过判断用户的爽约率与爽约率阈值的差别，判断用户特征是否满足预设条件。在一些实施例中，预设条件可以是固定的系统默认值，也可以在不同的情况下动态调整。例如，预设条件可以随着时间、位置、交通状况、乘客需求等动态调整。在一些实施例中，预设条件可以基于调整规则而动态调整。例如，调整规则可以是在每一天中固定时刻设置固定的调整参数，或调整参数可以以一定时间间隔(例如每1小时)变化。预设条件可以与订单相关，也可以与用户特征相关，也可以与二者都相关。
排序模块450可以用于对用户进行排序。排序过程可以根据订单信息与用户特征的匹配程度，也可以根据用户特征与预设条件的差别程度。排序模块450可以集成在判断模块440中，或集成在任何一个其他模块中。在一些实施例中，排序模块450还可以对用户评分，根据用户评分情况，为用户设置不同的优先级，根据优先级情况，对用户进行排序。在一些实施例中，对用户进行排序时，除了考虑订单信息与用户特征的匹配程度或用户特征与预设条件的差别程度外，还可以考虑用户的偏好设置。例如，司机可以在个人账户中设置一个与乘客星级相关的参数(例如优先接收来自5星级乘客的订单)。在一些实施例中，对用户进行排序时，还可以考虑乘客的偏好设置。类似地，乘客也可以在个人账户中设置一个个人偏好参数，则系统对司机进行排序时，将优先考虑与该乘客的个人偏好参数关联度较高的司机。
订单生成模块460可以用于整合订单信息，生成待分配订单。待分配订单的特征可以包括发送订单的位置、发送订单的位置与司机的距离、订单的目的地、订单的目的地区域、发送订单的位置周围的路况、订单的目的地周围的路况、订单的动态加价、乘客人数、是否携带行李、是否接收拼车等。在一些实施例中，订单生成模块460可以对接收的订单信息进行格式转换、内容更改或调整等。该格式转换、内容更改或调整等可以依据用户的设定，如司机的设定。该格式转换、内容更改或调整等可以依据按需服务系统105或订单处理引擎110等的默认设定。生成的待分配订单可以是文本格式、音频格式、图像格式、视频格式等。
订单分配模块470可以用于向用户分配待分配订单。在一些实施例中，订单分配模块470可以集成在司机接口240中。订单分配模块470可以实时或非实时地从其他模块中读取排序结果、用户特征、订单信息、判断结果等。在一些实施例中，订单分配模块470可以读取计算模块430计算获得的用户特征，直接根据用户特征分配订单。在一些实施例中，订单分配模块470也可以根据排序模块450生成的排序结果进行订单分配。在一些实施例中，订单分配模块470可以和订单生成模块460集成在一个独立模块中，同时实现生成订单与分配订单的功能。在一些实施例 中，订单分配模块470可以向乘客发送订单相关信息，包括但不限于接单信息(例如司机已接单)、实时加价信息(例如用车高时费用的动态调整)等。在一些实施例中，订单分配模块470可以集成在乘客接口230中。
在一些实施例中，处理模块210内部可以集成一个或多个存储模块(图中未体现)。存储模块(图中未体现)用于存储其他各个模块所提取、计算、和/生成的各种信息及中间数据。在一些实施例中，处理模块210内部的各个子模块410-470内部可以集成各自的存储单元(图中未体现)，用于存储信息或中间数据。
在一些实施例中，处理模块210中的各个子模块410-470所执行的运算或处理可以是基于逻辑的运算，如与或非运算；也可以是基于数值的运算。处理模块210中的各个子模块410-470可以包含一个或多个处理器。处理器可以是任何通用处理器，例如，一个经过编程的可编程逻辑器件(PLD)，或者一个专用集成电路(ASIC)，或者一个微处理器，也可以是一个系统芯片(SoC)等，还可以是一个数字信号处理器(DSP)等等。各个子模块410-470中的两个或者更多的单元可以被集成在一个硬件设备上，也可以是彼此独立的两个或者更多的硬件设备上。应当理解，处理模块210中的各个子模块410-470可以利用各种方式来实现。例如，在一些实施例中，系统可以通过硬件、软件或者软件和硬件的结合来实现，不仅可以由诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用例如由各种类型的处理器所执行的软件实现，还可以由上述硬件电路和软件的结合(例如，固件)来实现。
根据本申请的一些实施例，图4-B所示的是处理模块210进行订单处理的示例性流程图。在步骤481，订单信息可以被提取。订单信息提取模块410可以提取订单信息。订单可以是实时订单、预约订单或历史订单。订单可以由乘客接口230传输至处理模块210，也可以从存储模块220中实时或非实时地读取。订单信息可以包括但不限于订单发送时间、订 单编号、出发地、目的地、出发时间、到达时间、愿意等待的时间、乘客人数、是否愿意拼车、选择的车型、有无行李、里程、价格、消费方加价、服务方调价、系统调价、红包使用情况、付款方式(如现金支付、刷卡支付、网上支付、汇款支付等)、订单完成情况、服务方选择订单情况、消费方发送订单情况等，或者上述信息的任意组合。提取的订单信息可以存储在订单信息提取模块210中，也可以存储在存储模块220中，也可以存储在本申请中所描述的任何一个集成在系统中或独立于系统外的存储设备中。
在步骤482，用户信息可以被提取。用户信息提取模块420可以提取用户信息。用户可以是服务提供者(例如司机)，也可以是服务请求者(例如乘客)。用户信息可以包括但不限于基本信息(姓名、昵称、性别、国籍、年龄、联系方式(电话号码、手机号码、社交账号信息(如微信号码、QQ号码和LinkedIn等)等可以联系到本人的方式等))、订单相关信息(例如历史选择的订单、历史取消的订单、历史接单的时间、历史接单的时段、历史接单的位置、历史接单的区域、历史登陆系统的时间或时段、历史登陆系统时所处的位置或区域等)、以及其他相关信息(例如驾龄、车龄、车型、车牌号、驾驶证号、额外服务能力(如车的后备箱大小、全景天窗等额外特性)等)。将上述各类及其他历史信息用于其他处理时，不同时段的历史信息可以有相同的影响，也可以有不同的影响。例如，与当前订单比较接近的时段的历史信息和与当前订单间隔比较遥远的时段的历史信息可以对处理结果有相同的影响。又例如，与当前订单比较接近的时段的历史信息也可以对处理结果较多的影响，而与当前订单间隔比较遥远的时段的历史信息可以对处理结果有较少的影响或没有影响。
在步骤483，用户特征可以计算获得。计算模块430可以根据所提取的用户信息，计算用户特征。如图4-A中所示，用户特征可以包括历史订单与当前订单的相似度、用户偏好度、用户爽约率、用户抢单特性、用户响应时间等。在一些实施例中，计算用户特征时，可以读取订单信息。
在步骤484，可以对订单信息及用户特征进行判断。判断过程可以由判断模块484执行。在一些实施例中，判断过程可以同时考虑订单信息和用户特征，例如，提取订单信息中的时间信息(例如始发时间)，设定一个与用户特征相关的时间阈值(例如时间偏好)，通过订单信息中的时间信息与时间阈值的差别，确定订单信息是否与用户特征相匹配。在一些实施例中，判断过程可以仅考虑用户特征。在该实施例中，可以添加一个或多个预设条件设定步骤(图中未显示)，该步骤可以设定与用户特征相关的预设条件，例如但不限于爽约率阈值、抢单特性曲线、响应时间阈值、偏好度阈值、相似度阈值等。该预设条件设定步骤(图中未显示)并非必须的，预设条件也可以是系统默认的，或由用户输入。具体例如，可以设定爽约率阈值，通过判断用户的爽约率与爽约率阈值的差别，判断用户特征是否满足预设条件。在步骤484，经过判断订单信息与用户特征后，可以生成判断结果。判断结果可以实时或非实时地传输至排序模块450。
在步骤485，可以对用户进行排序。排序过程可以根据判断结果执行。判断过程可以由排序模块450执行。排序过程可以根据系统默认的规则，也可以全部或部分地由用户设置。排序过程可以根据订单信息与用户特征的匹配程度，也可以根据用户特征与预设条件的差别程度。在一些实施例中，排序过程中还可以对用户进行评分(详细描述见图4-A)。
在步骤486，可以生成待分配订单。生成待分配订单过程可以由订单生成模块460执行。待分配订单可以是实时订单，也可以是预约订单。待分配订单的特征可以包括但不限于发送订单的位置、发送订单的位置与司机的距离、订单的目的地、订单的目的地区域、发送订单的位置周围的路况、订单的目的地周围的路况、订单的动态加价等。在步骤486，还可以对订单进行处理，例如，格式处理(包括但不限于文字、音频、视频等)，内容处理(例如添加或删减部分内容等)等。上述处理过程可以由订单生成模块460执行。在步骤487，可以根据排序结果，向用户分配订单。订单分配过程可以由订单分配模块470执行。
以上对订单处理过程的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。显然，对于本领域的专业人员来说，在了解各种算法的基本原理后，可能在不背离这一原理的情况下，对订单处理的具体实施方式与步骤进行形式和细节上的各种修正和改变，但是这些修正和改变仍在以上描述的范围之内。例如，在一些实施例中，判断步骤484和排序步骤485可以合并为一个步骤，判断过程和排序过程交叉或同时进行。在一些实施例中，在任意两个步骤之间可以加入其它选择条件，例如将任一步骤的结果进行存储备份等。
根据本申请的一些实施例，图5是处理模块210根据订单相似度分配订单的一个示例性系统图。如图5所示，在一些实施例中，相似度计算单元431可以包括相似度确定单元501，和/或余弦相似度确定单元501及选择/取消相似度确定单元503。订单信息提取模块410可以包括订单特征获取单元506及其他单元(图中未体现)。用户信息提取模块420可以包括接收特征获取单元504，和/或选择/取消特征获取单元505。判断模块440可以包括抢单概率A确定单元507，和/或抢单概率B确定单元508。排序模块450可以包括排序获取单元509及其他单元(图中未体现)。图5中所示各个单元间的连接方式可以是有线的或无线的，各个单元之间可以进行信息通信。
如图5中所示，处理模块210可以读取历史订单和当前订单。在一些实施例中，此处所述历史订单可以指距离当前时间一定时间间隔(例如，5分钟、10分钟、1小时、5小时、10小时、20小时、1天、2天、5天、10天、一个月等)内的历史订单。此处所述时间间隔可以是系统默认的，也可以根据情况实时调整。例如，在一些实施例中，假设某个司机在最近5天之内都没有历史订单，那么时间间隔可以设置为10天或更长时间。又例如，在一些实施例中，假设某个司机在一个时间段(例如，当前订单前一段时间)历史订单较多，在保证统计结果准确的前提下，可以设置较小的时间间隔(例如，当前订单前2天)。在一些实施例中，此处所述历史订单可以指近期的一定数量(例如，5个、10个、20个、50个、100个等)的历史订单。将历史订单信 息用于后续处理时，不同时段的历史订单信息可以有相同的影响，也可以有不同的影响。例如，与当前订单比较接近的时段的历史订单信息和与当前订单间隔比较遥远的时段的历史订单信息可以对处理结果有相同的影响。又例如，与当前订单比较接近的时段的历史订单信息也可以对处理结果较多的影响，而与当前订单间隔比较遥远的时段的历史订单信息可以对处理结果有较少的影响或没有影响。
此处所述当前订单可以指当前时间乘客发送的订单，也可以指在当前时间之前乘客发送的但并未分配的订单。此处所述当前订单可以是实时订单，也可以是预约订单。在一些实施例中，当前订单是指准备向用户呈现的或正在呈现的订单。作为示例，当前订单可以是指尚未向用户呈现的订单，或者正在向一些用户呈现而未向其他用户呈现的订单。当前订单可以是直接由乘客发出，也可以是由其他中间机构(例如，一个网站)转发的订单。
订单特征获取单元506可以用于获取当前订单的特征。当前订单的特征可以包括但不限于发送订单的位置、发送订单的区域、发送订单的位置与用户的距离、发送订单的时间、发送订单的时段、预约订单的始发时间与始发时段、预约订单的始发位置与始发区域、订单的目的地位置、订单的目的地区域、订单的目的地种类(例如，机场、火车站、医院、学校、商场等)、乘客所处的实时位置、乘客所处的实时位置与用户的距离、订单始发位置或目的地位置周围的路况、订单的加价(例如，乘客愿意支付的小费等)等。在一些实施例中，历史订单的特征还可以包括：乘客愿意等待的时间、乘坐人数、是否携带大件行李、是否愿意拼车等。
接收特征获取单元504可以用于获取用户接收的历史订单的特征。在一些实施例中，图5中所述“用户”可以指“司机”。用户接收的历史订单的特征也可以包括但不限于上述当前订单的特征。选择/取消特征获取单元505可以用于获取用户选择的历史订单的特征以及用户取消的历史订单的特征。此处所述用户选择的历史订单可以指用户对其作出响应的某个订单(抢单成功或抢单不成功都可以认为是用户对订单作 出响应)，也可以是指系统分配给用户的某个订单。所述用户取消的历史订单可以指用户对其未作出响应的某个订单，也可以指因为某些原因用户取消的某个订单。将上述各类及其他历史信息用于后续处理时，不同时段的历史信息可以有相同的影响，也可以有不同的影响。例如，与当前订单比较接近的时段的历史信息和与当前订单间隔比较遥远的时段的历史信息可以对处理结果有相同的影响。又例如，与当前订单比较接近的时段的历史信息也可以对处理结果较多的影响，而与当前订单间隔比较遥远的时段的历史信息可以对处理结果有较少的影响或没有影响。
相似度确定单元501用于根据接收的历史订单的特征以及当前订单的特征，确定当前订单与历史接收订单的相似度。余弦相似度确定单元502可以确定当前订单与历史接收订单的余弦相似度。选择/取消相似度确定单元503可以用于确定当前订单与用户选择的历史订单的相似度，以及当前订单与用户取消的历史订单的相似度。在一些实施例中，余弦相似度确定单元502和选择/取消相似度确定单元503可以集成在相似度确定单元501中。在一些实施例中，相似度确定单元501还可以包括一个或多个其他相似度确定子单元(图中未体现)，用于确定当前订单与用户接收的历史订单的其他相似度。与当前订单比较接近的时段的历史订单信息和与当前订单间隔比较遥远的时段的历史订单信息可以对处理结果有相同的影响。又例如，与当前订单比较接近的时段的历史订单信息也可以对处理结果较多的影响，而与当前订单间隔比较遥远的时段的历史订单信息可以对处理结果有较少的影响或没有影响。在一些实施例中，当前订单与距离当前订单时间间隔小于或等于一个阈值的时段内用户选择的历史订单相比较，以评价相似度。
抢单概率A确定单元507可以用于根据确定的相似度以及当前订单的特征，确定用户选择当前订单的概率。抢单概率B确定单元508可以利用机器学习模型，确定用户选择当前订单的概率。机器学习模型中可以包括当前订单与用户选择的历史订单的相似度、当前订单与 用户取消的历史订单的相似度、当前订单的特征等。机器学习模型可以实时更新，也可以以一定时间间隔(例如每天、每两天、每10天、每1个月等)，也可以在每天的特定时刻更新(例如0：00，9：00，12：00，20：00等)。在一些实施例中，抢单概率A确定单元507和抢单概率B确定单元508可以集成在同一个单元中，同时或非同时地利用机器学习模型或其他模型，确定用户选择当前订单的概率。排序获取单元509可以根据已确定的相似度、当前订单的特征等，对用户进行排序。在一些实施例中，排序获取单元509还可以对用户进行评分(详细描述见图4-A)。
以上对处理模块的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。上述每一个模块或单元均可通过一个或多个部件实现，每个模块或单元的功能也并不局限于此。显然，对于本领域的专业人员来说，在了解订单处理过程的基本原理后，可能在不背离这一原理的情况下，对处理模块的具体实施方式与步骤进行形式和细节上的各种修正和改变，还可以做出若干简单推演或替换，在不付出创造性劳动的前提下，对各模块或单元的顺序作出一定调整或组合，但是这些修正和改变仍在以上描述的范围之内。例如，可以添加一个存储单元，用于存储各单元或模块运行过程中产生的中间数据或处理结果。另外，一个或多个单元可以集成在同一个单元中，实现一个或多个单元的功能。图中虚线表示的各个单元均不是必须的，可以根据具体实施场景或需要选择添加或删除。
根据本申请的一些实施例，图6是根据订单相似度进行订单分配的示例性流程图。在一些实施例中，图6中所描述的“用户”可以指“司机”。在步骤610中，可以获取用户接收的历史订单的特征。接收特征获取单元504可以获取历史订单的特征。步骤610可以包括步骤611，获取用户选择的历史订单的特征以及用户取消的历史订单的特征。步骤611可以由选择/取消特征获取单元505执行。如图5中所述，历史订单可以指距离当前订单时间一定时间间隔内的历史订单，也可以是当前订单之前的一定数量的历史订单，也可以是指这两个条件同时满足 的历史订单。在呈现历史订单期间，用户可以实时地或非实时地对历史订单作出响应，例如选择历史订单、取消历史订单、建立与选择订单的偏好相关联的设置等。此处所述用户选择历史订单可以指用户对订单作出响应(抢单成功或抢单不成功都可以认为是用户对订单作出响应)，也可以是指系统分配给用户某个订单。所述用户取消订单可以指用户对订单未作出响应，也可以指因为某些原因用户取消了某个订单。在一些实施例中，用户未对历史订单作出任何响应，可以认为是用户取消了历史订单。用户对历史订单作出响应后，响应可以传输至订单处理引擎110。
在一些实施例中，用户选择的历史订单、用户取消的历史订单及用户的偏好设置等可以存储在抢单日志中。抢单日志可以存储在用户客户端140或服务器105中。在一些实施例中，抢单日志可以存储在服务器105的高速缓存中，例如只在高速缓存中存储包含近20次用户响应的抢单日志作为历史抢单日志。抢单日志可以按照预定设置进行同步更新，例如可以按照预定周期进行同步更新(例如每15分钟添加最新的抢单日志并删除过旧的抢单日志)。在一些实施例中，可以对抢单日志进行预处理。预处理可以包括格式处理、文本处理等。
在一些实施例中，历史订单的特征可以包括：发送订单的位置、发送订单的区域、发送订单的位置与用户的距离、发送订单的时间、发送订单的时段、预约订单的始发时间与始发时段、预约订单的始发位置与始发区域、订单的目的地位置、订单的目的地区域、订单的目的地种类(例如，机场、火车站、医院、学校、商场等)、乘客所处的实时位置、乘客所处的实时位置与用户的距离、订单始发位置或目的地位置周围的路况、订单的加价(例如，乘客愿意支付的消费等)等。在一些实施例中，历史订单的特征还可以包括：乘客愿意等待的时间、乘坐人数、是否携带大件行李、是否愿意拼车等。
在一些实施例中，历史订单的特征可以从抢单日志中直接或间接提取。作为示例，可以直接从历史订单的文本信息中确定订单的目的地信息。作为另一示例，可以结合发送订单的位置信息与用户的位置 信息确定发送订单的位置与用户的距离。作为又一示例，可以对订单中的文本信息进行分析处理从而确定目的地种类。
在步骤620，可以获取当前订单的特征。订单特征获取单元506可以获取订单特征。如图5中所述，当前订单可以是由乘客发出的订单，也可以是由其他中间机构(例如，一个网站)转发的订单。当前订单可以是实时订单，也可以是预约订单。当前订单的特征可以包括：发送订单的位置、发送订单的区域、发送订单的位置与用户的距离、发送订单的时间、发送订单的时段、预约订单的始发时间与始发时段、预约订单的始发位置与始发区域、订单的目的地位置、订单的目的地区域、订单的目的地种类(例如，机场、火车站、医院、学校、商场等)、乘客所处的实时位置、乘客所处的实时位置与用户的距离、订单始发位置或目的地位置周围的路况、订单的加价(例如，乘客愿意支付的小费等)等。在一些实施例中，当前订单的特征还可以包括：乘客愿意等待的时间、乘坐人数、是否携带大件行李、是否愿意拼车等。
在步骤630，可以确定当前订单与接收的历史订单的相似度。步骤630可以由相似度确定单元501执行。步骤630可以包括步骤631和步骤632，在步骤631和步骤632中，分别确定当前订单与接收的历史订单的余弦相似度以及确定当前订单与用户选择的历史订单/用户取消的历史订单的相似度。步骤631和步骤632可以分别由余弦相似度确定单元502和选择/取消相似度确定单元503执行。在一些实施例中，当前订单的特征和用户接收的历史订单的特征可以用向量表示。因此在步骤630，可以通过向量计算当前订单与用户接收的历史订单的相似度。具体地，在步骤631，可以利用余弦相似性公式来计算两个向量之间的余弦相似度，从而获得当前订单与接收的历史订单的余弦相似度。在一些实施例中，每一个当前订单都可以用向量表示，从而分别可以确定每一个当前订单与用户接收的历史订单的相似度。在一些实施例中，在步骤632，分别确定了当前订单与用户选择的历史订单的相似度以及与用户取消的历史订单的相似度之后，可以将所确定的多个相 似度进行归一化处理。作为示例，可以按照基于时间衰减的系数整合为一个0～1之间的数值作为相似度特征值。作为另一示例，可以对当前订单与用户选择的历史订单的相似度及与用户取消的历史订单的相似度整合为一个相似度特征值。
在步骤640，可以根据确定的相似度，选择向用户呈现的当前订单。步骤640可以由判断模块440和/或排序模块450执行。步骤640可以包括步骤641(确定用户选择当前订单的概率)和步骤642(根据概率向用户呈现当前订单)。在步骤641，可以利用机器学习模型，确定用户选择当前订单的概率。确定用户选择当前订单的概率过程可以由抢单概率A确定单元507和/或抢单概率B确定单元508实现。在一些实施例中，机器学习模型的特征可以包括训练特征和目标特征。训练特征可以包括服务器接收的大量订单的特征，目标特征可以包括用户对这些订单的响应。在一些实施例中，可以利用本地或云端服务器(例如大数据平台)对训练特征和目标特征进行分析、评估、预测等，利用统计分析等确定用户选择当前订单的概率。在一些实施例中，机器学习模型可以是逻辑回归模型、支持向量机模型等。在一些实施例中，可以利用统计分析，确定用户选择当前订单的概率。
在步骤642，确定用户选择当前订单的概率后，可以根据概率，对用户进行排序。排序过程可以由排序获取单元509实现。在一些实施例中，可以根据概率大小进行排序。对用户进行排序后，可以根据排序结果向用户呈现当前订单。在一些实施例中，可以选择排序最高的用户并向该用户呈现当前订单。在一些实施例中，可以选择排序前几名(例如前3名)的用户并向其呈现当前订单。向用户呈现当前订单的过程可以由司机接口240实现，可以通过语音播报或文本显示的形式向用户呈现。步骤640结束后，可以返回步骤610，继续开始一个新的流程。
以上对订单分配过程的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。显然，对于本领域的专业人员来说，在了解订单分配的基本原理后，可能在不背离这一原理的情况下，对订单分配的 具体实施方式与步骤进行形式和细节上的各种修正和改变，但是这些修正和改变仍在以上描述的范围之内。例如，步骤610和步骤620可以按照任意顺序执行，可以先后执行，也可以同时执行。步骤611可以省略。类似地，可以省略步骤631和步骤632中的任意一个或多个步骤，可以二者合并在一个步骤执行，或分解为多个步骤执行。类似地，也可以对步骤641和步骤642作出类似处理。
根据本申请的一些实施例，图7所示的是处理模块210内部偏好度计算单元432的示例性系统图。在一些实施例中，图7中所述“用户”可以指“司机”。如图4-A和图4-B中所述，在一些实施例中，系统可以根据用户偏好度进行订单分配。用户偏好度可以由用户手动输入，也可以由系统计算获得。在一些实施例中，系统可以提取用户信息和/或订单信息并通过偏好度计算单元432计算获得用户偏好度。如图7所示，偏好度计算单元432可以包括偏好区域确定部分710和偏好度确定部分720。偏好区域确定部分710可以包括局部密度计算单元701、聚类簇形成单元702、聚类形成单元703、覆盖半径计算单元704和偏好区域确定单元705。偏好度确定部分720可以包括坐标获取单元706、中心距离计算单元707和偏好度确定单元708。
在一些实施例中，局部密度计算单元701可以用于根据预设截断距离dc，计算经纬度坐标点的局部密度ρi。此处所述预设截断距离dc可以是系统默认值，也可以根据用户历史订单的目的地信息，由系统计算获得。在一些实施例中，可以提取一定时间间隔(例如，5分钟、10分钟、1小时、5小时、10小时、20小时、1天、2天、5天、10天、一个月等)内的历史订单信息。在一些实施例中，可以提取一定数量(例如，5个、10个、20个、50个、100个等)的历史订单信息。在一些实施例中，可以提取这两个条件同时满足的历史订单。此处所述经纬度坐标点可以指一个地点对应的经纬度坐标，例如某个地点对应的经纬度坐标可以表示为(a，b)，此处a表示经度坐标，b表示纬度坐标。
计算坐标点的局部密度可以利用下述公式(1)：
ρi＝∑χ(dij-dc)，   (1)
其中ρi可以表示与第i个坐标点之间距离小于截断距离dc的坐标点的个数，
其中
Figure PCTCN2016072837-appb-000004
聚类簇形成单元702可以用于生成一个或多个聚类簇。在一些实施例中，可以根据经纬度坐标点i的局部密度ρi以及预设密度阈值rho，对每一个经纬度坐标点进行中心点聚类，形成多个聚类簇。其中预设密度阈值rho可以根据在预设时间段内的历史订单的数量设定，也可以是系统默认值。在一些实施例中，如果在预设时间段内的历史订单数量很多，则预设密度阈值rho就需要设置为较大的数值；反之，则预设密度阈值rho较小。
聚类形成单元703可以用于生成一个或多个聚类。在一些实施例中，可以计算任意两个聚类簇中心点之间的距离，并且筛选出中心点距离小于预设簇间距的聚类簇，并将两个聚类簇进行聚类合并，形成多个聚类。预设簇间距可以是系统默认值，也可以在不同在情况下设置不同的预设簇间距。计算任意两个聚类簇的中心点之间的距离时，若两个聚类簇的中心点之间的距离小于预设簇间距，将局部密度较小的聚类簇的中心点向局部密度较大的聚类簇的中心点进行聚类。
覆盖半径计算单元704可以用于计算聚类的覆盖半径。在一些实施例中，可以计算每一个聚类内各个经纬度坐标点到该聚类中心点的平均距离，并将该平均距离作为该聚类的覆盖半径。在一些实施例中，覆盖半径计算单元704还可以包括一个或多个模型单元(图中未体现)，模型单元(图中未体现)中可以包括一个或多个数学模型、一个或多个模拟仿真模型等。在计算覆盖半径时，可以读取不同的模型进行计算。
偏好区域确定单元705可以用于确定用户的偏好区域。在一些实施例中，可以根据每一个聚类的聚类中心点和覆盖半径，确定用户的目的地偏好区域的中心点和覆盖半径。
在一些实施例中，同一个用户在不同的情况下可能有不同的偏好区域。作为示例，在早上上班或晚上下班车流量高峰时，某个用户的偏好区域可能在交通状况相对良好的偏远地区。作为又一示例，某个用户在工作日和周末时，其偏好区域也可能有所不同。因此在一些实施例中，确定用户偏好区域时，可以考虑时间因素或其他相关因素。
坐标获取单元706可以用于获取待分配订单的目的地对应的经纬度坐标。坐标获取单元706可以包括一个或多个地址解析单元(图中未体现)，地址解析单元(图中未体现)可以提取目的地地址信息，并从中解析出该目的地地址对应的经纬度坐标信息。
中心距离计算单元707可以用于计算待分配订单的目的地对应的经纬度坐标与每一用户的目的地偏好区域的中心点的距离。在一些实施例中，中心距离计算单元707可以包括一个订单目的地信息缓存区(图中未体现)和一个用户偏好区域缓存区(图中未体现)。
偏好度确定单元708可以用于确定每一个用户的偏好度。在一些实施例中，可以根据所述距离以及每一用户的目的地偏好区域的覆盖半径，计算每一用户对待分配订单的目的地的偏好度L，计算公式为下述公式(3)：
Figure PCTCN2016072837-appb-000005
其中Az为待分配订单的目的地对应的经纬度坐标与每一个用户的目的地偏好区域的中心点之间的距离，d为用户偏好区域的覆盖半径。
以上对偏好度计算单元的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。上述每一个模块或单元均可通过一个或多个部件实现，每个模块或单元的功能也并不局限于此。显然，对于本领域的专业人员来说，在了解偏好度计算过程的基本原理后，可能在不背离这一原理的情况下，对偏好度计算单元的具体实施方式与步骤进行形式和细节上的各种修正和改变，还可以做出若干简单推演或替换，在不付出创造性劳动的前提下，对各模块或单元的顺序作出一定调整或组合，但是这些修正和改变仍在以上描述的范围之内。例如，偏好度计算单元432还可以包括一个或多个用户界面(图中未体现)，用户 可以通过用户界面手动输入用户偏好区域、用户偏好度及其他相关信息。偏好度计算单元432内部还可以集成一个或多个存储单元(图中未体现)，用于存储各个单元计算或处理过程中产生的任何中间数据或最终结果。
根据本申请的一些实施例，图8所示的是计算用户偏好区域的示例性流程图。在一些实施例中，图8中所述“用户”可以指“司机”。在步骤810，可以根据预设截断距离dc，计算每一经纬度坐标点i的局部密度ρi。步骤810可以由局部密度计算单元701执行。如图7中所述，预设阶段距离dc可以是系统默认值，也可以根据用户历史订单的目的地信息，由系统计算获得。作为示例预设截断距离dc可以根据用户在预设时间间隔(例如20小时)内的历史订单目的地对应的经纬度坐标的平均值以及用户在预设时间间隔内的历史订单数量来设定。具体例如，假设某一用户在预设时间间隔(例如20小时)内的历史订单数量为5个，5个历史订单目的地对应的经纬度坐标集合为[(110，80)，(112.5，85)，(115，90)，(117.5，95)，(120，100)]。通过计算得到上述5个历史订单目的地对应的经纬度坐标的平均值为(115，90)，则预设截断距离dc的起点可设为(115，90)，长度可设为
Figure PCTCN2016072837-appb-000006
计算坐标点的局部密度ρi可以利用前述公式(1)。
在步骤820，根据经纬度坐标点i的局部密度ρi以及预设密度阈值rho，对每一个经纬度坐标点进行中心点聚类，形成多个聚类簇。步骤820可以由聚类簇形成单元702执行。在一些实施例中，根据局部密度ρi与预设密度阈值rho的相对关系，上述经纬度坐标点i可以分为三类：当某一经纬度坐标点的局部密度大于所述密度阈值时，则确定该经纬度坐标点为聚类中心点；当某一经纬度坐标点的局部密度小于所述密度阈值时，且该经纬度坐标点的截断距离范围内有中心点时，则确定该经纬度坐标点为非聚类中心点；当某一经纬度坐标点的局部密度小于所述密度阈值时，且该经纬度坐标点的截断距离范围内无中心点时，则确定该经纬度坐标点为噪声点。
在步骤830，计算任意两个聚类簇中心点之间的距离，并且筛选 出中心点距离小于预设簇间距的聚类簇，并将两个聚类簇进行聚类合并，形成多个聚类。步骤830可以由聚类形成单元703执行。在一些实施例中，预设簇间距是可变的，例如，不同的用户可以对应不同的预设簇间距；类似地，不同的时间段也可以对应不同的预设簇间距。
在步骤840，计算每一个聚类内各个经纬度坐标点到该聚类中心点的平均距离，并将该平均距离作为该聚类的覆盖半径。步骤840可以由覆盖半径计算单元704执行。在一些实施例中，如果某用户在预设时间段内的历史订单目的地对应的经纬度坐标只有一个聚类，则该聚类内各个经纬度坐标点该聚类中心点的平均距离为覆盖半径；如果某用户在预设时间段内的历史订单目的地对应的经纬度坐标有多个聚类，则分别计算每一聚类内的各个经纬度坐标到该聚类中心点的平均距离作为每一聚类的覆盖半径。
在步骤850，根据每一个聚类的聚类中心点和覆盖半径，确定用户的目的地偏好区域的中心点和覆盖半径。步骤850可以由偏好区域确定单元705执行。
以上对确定偏好区域过程的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。显然，对于本领域的专业人员来说，在了解计算偏好区域的基本原理后，可能在不背离这一原理的情况下，对确定偏好区域的具体实施方式与步骤进行形式和细节上的各种修正和改变，但是这些修正和改变仍在以上描述的范围之内。例如，步骤820和步骤830可以合并为一个步骤，即，生成聚类簇和生成聚类的过程可以交叉进行。又例如，在一些实施例中，图8所示流程中可以添加一个或多个缓存步骤，缓存计算过程中产生的中间数据；和/或一个或多个预处理步骤，对流程中所涉及的任何数据进行预处理操作。又例如，可以添加一个或多个预设步骤，预设定流程中所涉及的任何预设值，例如预设截断距离、预设簇间距等。
根据本申请的一些实施例，图9所示的是计算用户偏好度的示例性流程图。在一些实施例中，图9中所述“用户”可以指“司机”。如图9所示，在步骤910，可以获取订单目的地和目的地的经纬度坐标。坐 标获取单元720可以获取订单目的地的经纬度坐标。在步骤920，可以计算所述待分配订单的目的地对应的经纬度坐标与每一用户的目的地偏好区域的中心点的距离Az。步骤920可以由中心距离计算单元707执行。在步骤930，根据所述距离Az以及每一个用户的目的地偏好区域的覆盖半径d，计算获得每一个用户对待分配订单的目的地偏好度L，计算公式为前述公式(3)。步骤930可以由偏好度确定单元708执行。
在一些实施例中，在计算每一个用户对待分配订单的目的地偏好度L之前，图9中还可以包括一个或多个图中未示出的步骤。在一些实施例中，可以包括一个获取待分配订单的始发位置及始发位置所在的始发区域的步骤，还可以包括一个获取处于该始发区域内的用户的步骤。确定该始发区域时，可以设定一个预设范围。预设范围可以是系统默认值，也可以根据不同的情况动态调整。在一些实施例中，预设范围的数值可以根据当前所在城市的车流量、具体城区位置、路况等信息进行设置和调整。作为示例，如果订单位置所处的始发区域在交通状况良好的区域，则预设范围的取值可以设置为一个较大的数值；反之，如果订单位置所处的始发区域在交通状况拥堵的区域，则预设范围的取值应设置为一个较小的数值。
在一些实施例中，图9所示流程中还可以包括一个获取始发地预设范围内每一个用户的目的地偏好区域的步骤。在一些实施例中，还可以包括获取每一个用户在预设时间间隔内的历史订单信息(例如，目的地信息、目的地对应的经纬度坐标信息)。历史订单可以包括不同出行方式对应的订单，例如，出租车、专车、快车、顺风车、大巴车等。历史订单信息可以包括订单的出发地、目的地、出发时间、订单金额等。
在一些实施例中，可以基于目的地信息获取用户偏好。作为示例，可以根据用户在移动终端上输入的目的地信息获取用户偏好。这些目的地信息可以是地理名称(例如，上地)，或者地图上的一个坐标(例如，经纬度)，或者一定的范围(例如，回龙观附近2公里)等等。例如，也可以设置一些常用目的地信息，从而便于快捷选择。在一些实 施例中，当目的地信息与订单的目的地一致时，可以为订单确定至少一个用户。例如，如果从一些用户获得的目的地信息为上地，而订单的目的地也是上地，则可以为这些订单确定这些用户。在一些实施例中，目的地信息也可以与订单的目的地不一致。例如，如果订单的目的地为A，用户的目的地信息为B，A与B不一致，但是A地点去往B地点的订单较多、较集中，则也可以为这些订单确定目的地信息为B的用户。从而，用户在完成这些订单之后，更容易接收到去往地点B的订单。例如，哪些路线的订单比较集中可以通过大数据分析进行获得。作为示例，可以对一个时间段(例如距离当前时间1个月之内)的数据进行统计、计算、分类等，获得统计分析结果。作为又一示例，统计过程中可以加入一个或多个选择因素(例如天气因素、路况因素、乘客/司机的偏好参数等)。
在一些实施例中，用户偏好度可以通过统计分析用户的历史订单信息获得。可以对历史订单中的信息元素分配权重，并根据权重计算用户偏好度。作为示例，在考虑订单金额这个信息元素时，如果用户A的历史订单信息中的订单金额与待分配订单的预估金额接近，则可以给予该用户A较高的优先级，反之，如果相差很远，则给予该用户A较低的优先级。对历史订单中的信息元素进行权重分配后，可以对这些信息元素进行加权求和，得到用户评分。作为示例，用户评分可以用下述公式(4)来计算：
S＝w1*v1+w2*v2+...+wm*vm，   (4)
其中vi可以表示信息元素i的归一化评分，wi可以表示信息元素i的权重。在计算获得每一个用户的评分后，可以根据预设的评分阈值，对用户进行排序，并根据排序结果向用户分配订单。
根据本申请的一些实施例，图10是计算用户偏好度的原理示意图。在一些实施例中，图10中所述“用户”可以指“司机”。如图10中所示，如果某一个用户的偏好区域有多个时，可以根据每一个偏好区域，分别计算其对应的偏好度。之后再对多个区域对应的偏好度进行求和，从而获得对应该订单目的地的偏好度。偏好度可以利用下述公式(5) 计算获得：
Figure PCTCN2016072837-appb-000007
根据本申请的一些实施例，图11是根据用户请求的始发时段和始发区域分配订单的示例性系统框图。在一些实施例中，图11中所述“用户”可以指“司机”。如图11中所示，处理模块210可以包括预约订单信息获取单元1101、预约订单关联信息获取单元1102、用户请求获取单元1103、预约订单相似度确定单元1104、预定订单发送单元1106、和/或存储单元1105。
用户请求获取单元1103可以用于获取由用户请求的预约订单的始发时段和始发区域；预约订单信息获取单元1101可以用于获取与该始发时段和始发区域关联的预约订单；预约订单关联信息获取单元1102可以用于获取预约订单的始发时间和始发地点；预约订单相似度确定单元1104可以用于确定预约订单的始发时间和始发地点与用户请求的始发时段和始发区域的相似度。在一些实施例中，可以确定预约订单的始发时间是否处于用户请求的始发时段之内，以及确定预约订单的始发地点是否处于用户请求的始发区域范围内；预约订单发送单元1106可以用于向用户发送预约订单的始发时间、始发地点及其他相关订单信息；存储单元1105可以用于存储订单信息、用户请求信息、中间数据等。
上述各单元以及组合方式仅仅是处理模块210的一种具体实现方式，不应被视为是唯一可行的实施方案。上述任意两个或两个以上单元可以集成在一个或多个模块或单元中，实现一个以上单元的功能。上述各单元之间可以相互通信，并且其连接方式可以是有线的，也可以是无线的。
根据本申请的一些实施例，图12是根据用户请求的始发时段和始发区域分配订单的示例性流程图。在一些实施例中，图12中所述“用户”可以指“司机”。需要注意的是，图12中仅给出了一个示例性流程，并不表示本申请必须按照下述流程进行。在一些实施例中，一个或多 个步骤可以删除或调整顺序。在步骤1201，可以获取乘客预约订单的始发时间和始发地点。提取的始发时间和始发地点可以存储在预约订单列表中。所述始发时间和始发地点可以由预约订单信息获取单元1101提取。在步骤1202，可以确定该始发时间和始发地点所处的始发时段和始发区域。始发时段和始发区域可以由预约订单关联信息获取单元1102确定。在一些实施例中，始发时段可以指一个时间间隔，例如，上午9点至上午10点。在一些实施例中，始发时段可以指一个时间范围，例如2016年1月28日全天。在一些实施例中，始发时段可以指一个时间间隔与一个时间范围的结合，例如2016年1月28日上午9点至上午10点。在一些实施例中，始发区域可以以一个特征位置划分，例如站点、路段、街区、居民区、商场、火车站、机场等。在一些实施例中，始发区域可以是一个区域范围，例如，以始发地点为圆心的半径5公里之内的一个区域范围。
在步骤1203，判断该预约订单的发布时间与始发时间的时间差是否小于预定阈值。在该步骤中，预定阈值可以是系统默认值(例如15分钟)，也可以由用户设定。如果时间差小于预定阈值，那么则认为该预约订单为实时订单，并在步骤1204将该订单作为实时订单向该始发区域内的司机分配。如果时间差大于预定阈值，则在步骤1205，存储该订单的始发时间、始发地点、始发时段和始发区域。在一些实施例中，步骤1203并非必须的，可以直接将订单的始发时间、始发地点、始发时段和始发区域存储。
在步骤1206，获取由司机请求的始发时段和始发区域。用户请求获取单元1103可以获取司机请求的始发时段和始发区域。在一些实施例中，司机可以从预定的始发时段列表中选择始发时段和/或从预定的始发区域列表中选择始发区域。其中，该始发时段列表中的始发时段可以以一定时间间隔(例如15分钟，具体可以显示为，上午10：00-10：15)进行为划分，该始发区域列表中的始发区域可以以一定地理位置(例如各个站点、路段或街区)进行划分。在一些实施例中，始发区域和/或始发时段可以是由司机预先设置的，例如每天出车的时段和出车的 区域。在一些实施例中，司机可以实时调整始发时段和始发区域，即司机可以实时发送请求。
在步骤1207，可以获取与该始发时段和始发区域相关的预约订单。步骤1207可以由预约订单相似度确定单元1104执行。在一些实施例中，与该始发时段和始发区域相关的订单是指始发时间处于该始发时段内，始发位置位于该始发区域内。在一些实施例中，可以比较或计算预约订单的始发时段和始发区域与用户请求的始发时段和始发区域的相似度，根据相似度确定与用户请求的始发时段和始发区域相关的预约订单。在一些实施例中，可以在预定的预约订单列表中进行检索与该始发时段和始发区域相关的预约订单。如本申请中任何实施例中所描述的，该预约订单列表可以预先存储在任何一个系统内置的或独立于系统外的存储设备中。该预约订单列表中可以存储有由多个乘客请求的多个预约订单，同时可以存储多个预约订单的始发时间、始发时段、始发地点、始发区域等信息。附加地或者备选地，该预约订单列表还可以预先存储有这些预约订单的目的地点、客人数、是否携带老人/小孩、是否接收加价、以及是否携带大件行李等信息。
在步骤1208，向该司机发送该预约订单。预约订单发送单元1106可以向司机发送预约订单。在一些实施例中，可以向该司机发送该预约订单的始发时间和始发地点。然后，可以接收该司机对预约订单的选择，以及根据该选择，向该司机发送预约订单的联系信息。
在一些实施例中，还可以包括一个或多个监控步骤，用于监控预约订单是否已被接单。在一些实施例中，可以计算一个或多个时间差。作为示例，预约订单存储在预约订单列表中的时间至该预约订单的始发时间的时间差、从当前时间至该预约订单的始发时间的时间差等。在一些实施例中，在该监控步骤，可以设置一个或多个时间阈值。通过计算上述一个或多个时间差是否满足上述一个或多个时间阈值，监控预约订单是否已被接单。作为示例，如果预约订单的始发时间在24小时之后，则可以每隔一定时间间隔(例如1小时)监控该预约订单是否已被接单。如果距离该预定订单的出发时间的时间差较短(例如 6小时)，则可以提高该预约订单的优先级，例如，提供优先抢单顺序，或向司机提供奖励等。
作为示例，乘客发布预约订单，该预约订单中可以包含该乘客的始发时间和始发地点。例如，在当前时间为12：00时，四位乘客A、B、C和D所发布的预约订单如下表1所示。
表1乘客所发布的预约订单列表
乘客 始发时间 始发地点 目的地点
A 12：10 丰台路 西二旗
B 14：00 北京仙昊商贸中心 天安门
C 15：00 西直门 东直门
D 15：05 北京北站 天安门
系统接收到预约订单列表后，首先判断发布该预约订单的时间与该预约订单的始发时间的时间差是否小于预定时间阈值(例如15分钟)。如果该时间差小于预定时间阈值，则系统将该预约订单作为实时订单并发送给该始发区域内的司机。如表1所示，由于乘客A发布预约订单的时间与其始发时间的时间差仅为10分钟，小于预定时间阈值15分钟，因此乘客A所发布的预约订单将作为实时订单并发送给丰台路附近的司机。
如果该时间差不小于该预定时间阈值，则系统将确定该始发时间所处的始发时段以及该始发地点所处的始发区域。如表1中所示，乘客B、C和D所发布的预约订单的时间与其始发时间的时间差都不小于该预定时间阈值15分钟，因此系统将确定乘客B、C和D所发布的预约订单的始发时段和始发区域。系统确定的始发时段和始发区域可以如下表2所示。
表2确定始发时段和始发区域示例
乘客 始发时间 始发地点 始发时段 始发区域
A 12：10 丰台路 实时 丰台路
B 14：00 北京仙昊商贸中心 14：00-14：15 丰台路
C 15：00 西直门 15：00-15：15 西直门
D 15：05 北京北站 15：00-15：15 西直门
系统在确定预约订单的始发时段和始发区域时，可以基于系统默认的固定规则(例如始发时段的时间间隔为15分钟，始发区域的范围为以始发地点为圆心半径5公里内)，也可以基于一个动态规则，不同的情况下可以使用不同的动态规则。例如，始发地点相对偏僻时，始发区域的范围可以是以始发地点为圆心半径为10公里的范围。又例如，始发时间在深夜或凌晨时，始发时段的时间间隔可以设置为1小时或更长。确定了预约订单的始发时段和始发区域后，系统可以将预约订单的始发时间、始发时段、始发地点及始发区域存储在系统的或与系统相关的任何一个存储设备中。在一些实施例中，可以生成包含上述始发时段和始发区域的预约订单列表。在一些实施例中，预约订单列表中还可以包含下表3所示内容。
表3预约订单列表示例
Figure PCTCN2016072837-appb-000008
司机可以请求预约订单的始发时段和始发区域，例如，司机可以从预定的始发时段列表中选择始发时段15：00-15：15，并且从预定的始 发区域中选择始发区域西直门。接收到司机请求的始发时段和始发区域后，系统可以从预约订单列表中检索并获取符合该始发时段和始发区域的预约订单。例如，系统可以在存储有预约订单列表的任何存储设备中检索并获取乘客C和乘客D的预约订单。获取符合条件的预约订单后，系统可以向司机发送该预约订单以及该预约订单的始发时间和始发地点。系统还可以向司机发送与该预约订单相关的其他信息，例如目的地信息。向司机发送的预约订单可以如下表4所示。
表4向司机发送的预约订单示例
乘客 始发时间 始发地点 目的地
C 15：00 西直门 东直门
D 15：05 北京北站 天安门
上述示例仅仅描述了根据司机请求的始发时段和始发区域向司机分配订单的示例过程，并不表示根据司机请求的始发时段和始发区域向司机分配订单的具体实现方式仅限于此。
根据本申请的一些实施例，图13所示的是处理模块210根据用户爽约率分配订单的示例性系统框图。在一些实施例中，图13中所述“用户”可以指“司机”。在本实施例中，处理模块210可以包括请求接收单元1301、订单生成单元1302、反馈接收单元1303、爽约率计算单元433和订单分配单元1304。
请求接收单元1301可以用于接收来自乘客的用车请求。订单生成单元1302可以用于根据用车请求生成订单信息。订单信息可以包含始发时间、始发地点、目的地、乘客人数等。在一些实施例中，还可以包括一个或多个订单推送单元(图中未体现)。一个或多个订单推送单元可以用于将订单信息推送至一个或多个用户终端(例如司机客户端)，例如可以推送至n个终端，n为不小于1的整数。反馈接收单元1303可以用于接收由上述终端所反馈的抢单请求。在一些实施例中，可以将反馈了抢单请求的终端标记为反馈终端。爽约率计算单元433可以用于计算获取所述反馈终端的爽约率(详细内容见图4-A)。订单分配 单元1304可以用于根据计算获取的爽约率，从反馈终端中选取一个或多个目标终端，并将订单信息分配至目标终端。
在一些实施例中，爽约率计算单元433中可以包括一个映射表存储单元(图中未体现)，或者映射表存储单元(图中未体现)可以集成在任何一个其他单元或模块中。在一些实施例中，映射表存储单元(图中未体现)中存储有用户终端与爽约率之间的对应关系。在一些实施例中，订单分配单元1304可以直接从映射表存储单元(图中未体现)中读取用户终端的爽约率信息，并根据该爽约率信息向用户终端分配订单。
根据本申请的一些实施例，图14所示的是根据用户爽约率分配订单的示例性流程图。在一些实施例中，图14中所述“用户”可以指“司机”。在步骤1401，乘客发出的用车请求被接收。请求接收单元1301可以接收由乘客发出的用车请求。用车请求可以由乘客终端发出，乘客终端可以包括手机、平板电脑、掌上电脑、笔记本电脑、台式电脑及其他任何具有类似功能的终端设备。用车请求可以包含出发时间、出发地址、目的地地址、乘客位置、乘客人数等。其中乘客地址可以由乘客终端的定位装置确定(例如GPS设备)，也可以由乘客手动输入。
在步骤1402，可以根据接收到的用车请求，生成订单信息。订单生成过程可以由订单生成单元1302实现。该步骤可以将用车请求整合为订单信息。订单信息的格式可以是文本格式、图像格式、音频格式或视频格式。订单信息可以由订单生成单元1302生成。生成的订单信息可以存储在如本申请的任何实施例里所描述的任何存储设备中。
在步骤1403，推送订单信息至n个终端，其中n≥1，所述终端为司机终端。推送订单过程可以由订单生成单元1302实现。在一些实施例中，司机终端可以反映司机的位置信息。在推送订单之前，可以根据订单的始发位置和司机的位置信息，确定将要推送订单信息的终端列表。在一些实施例中，可以设定一个距离阈值，订单的始发位置作为起点，将在所述距离阈值范围内的司机终端加入到终端列表中。距离 阈值可以是系统默认值(例如3公里)，也可以根据情况实时调整。例如，交通拥堵时，距离阈值可以设定为较小值(例如1公里)。又例如，始发位置较为偏僻时，距离阈值可以设定为较大值(例如8公里)。
在步骤1404，接收由司机终端反馈的抢单请求，并将反馈了抢单请求的终端标记为反馈终端。步骤1404可以由反馈接收单元1303执行。在步骤1405，计算司机的爽约率。爽约率可以通过计算获得，也可以通过检索映射表获得。在一些实施例中，爽约率可以通过下述公式(6)计算获得：
Figure PCTCN2016072837-appb-000009
其中，Tx可以为爽约率，k可以为反馈终端x分配的最近n个订单中的爽约订单个数，
Figure PCTCN2016072837-appb-000010
可以为n选k的组合数，p可以为平均爽约率。
平均爽约率p可以通过下述公式(7)计算获得：
p＝V/S，   (7)
其中V为全部司机终端的爽约订单总数，S为全部司机终端的订单总数。计算获得的爽约率可以存储在映射表存储单元(图中未体现)中。在一些实施例中，爽约率可以由检索映射表获得。
在一些实施例中，爽约原因基本可以分为两类，一类是确实由于某种不可抗力原因无法完成订单而造成的爽约；第二类是恶意爽约(例如司机抢到更好或更感兴趣的订单，或恰好路边有乘客需要用车等)。为了排除第一类不可抗力原因而造成的爽约，在进行爽约率计算时，可以添加一个筛选步骤(图中未体现)。在一些实施例中，筛选过程可以通过分析一些与司机或与订单相关的信息完成。作为示例，可以获取司机终端反馈抢单请求时所处的位置以及发布订单的乘客所处的位置，如果司机位置与乘客位置间的路况较为拥堵，则将司机爽约该订单的行为定义为不可抗力原因导致爽约，后续将筛选出此类订单不参与爽约率的计算。作为又一示例，对于一些有乘客投诉的爽约订单，可以定义为恶意爽约。作为进一步示例，乘客或司机在取消订单时可以向系统提交取消原因，系统可以读取取消订单的原因，从 而判断该爽约订单是否属于恶意爽约行为。
在步骤1406，可以判断司机爽约率是否小于预设阈值。此处所述预设阈值可以是系统默认值，也可以根据需要实时调整。作为示例，假设司机终端a、b反馈了抢单请求，若终端a的爽约率为0.2，终端b的爽约率为0.99，若所述预设阈值为0.98，则将所述终端b直接排除，将终端a选择为目标终端。但假设司机终端a、b、c三个终端都反馈了抢单请求，若终端a的爽约率为0.2，终端b的爽约率为0.99，终端c的爽约率为0.3，若所述预设阈值为0.98，则可将所述终端b直接排除，从终端a、c中选择一个作为目标终端。在一些实施例中，可以采用多种方式来进行选择，例如：选择爽约率更低的终端a作为目标终端。又例如，选择终端a、c中距离出发地址更近的终端作为目标终端。又例如，随机选择司机终端a、c中的一个终端作为目标终端。在一些实施例中，还可以加入其它筛选条件，采用其他方式来进行选择，本实施方式对此不加以限制。在步骤1407，可以根据选择结果，将订单分配给所选择的用户终端。订单分配过程可以由订单分配单元1304执行。
根据本申请的一些实施例，图15是一种订单抢单特性的自动更新方法的示例性流程图。在一些实施例中，图15中所描述的“用户”可以指“司机”。在步骤1510，获取用户在预设时间段内的抢单特性。获取抢单特性的过程可以由抢单特性计算单元434实现。在一些实施例中，所述抢单特性可以是各用户的抢单概率随时间变化的特征。在一些实施例中，可以是周期性地获取用户抢单特性，也可以非周期性地获取用户抢单特性。周期性地获取用户抢单特性是指每隔固定的时间获取终端抢单特性，如每周、每天或每小时获取用户抢单特性等。每次获取的用户的数量可以是一个，也可以是多个。每次获取的用户的数量可以相同，也可以不同。
在步骤1520，生成数据更新消息。生成数据更新消息的过程可以由抢单特性计算单元434实现。其中，所述数据更新消息可以包括但不限于订单抢单特性更新目录等。可以理解，所述数据更新消息还可以包括其他信息，本申请在此不作限制。在一些实施例中，在获取到 订单抢单特性后，根据获取的用户在预定时间段内的订单抢单特性，生成订单抢单特性更新目录。其中，所述订单抢单特性更新目录中可以包括但不限于需更新的用户标识。可以理解，所述订单抢单特性更新目录还可以包括其他信息，本申请在此不作限制。
在步骤1530，更新抢单特性。更新抢单特性的过程可以由抢单特性计算单元434实现。在一些实施例中，可以根据所述订单数据更新消息中的订单抢单特性更新目录更新用户的订单抢单特性。在一些实施例中，可以根据订单抢单特性更新目录中的终端标识下载标识所对应的用户的订单抢单特性。进一步地，可以根据更新后的用户的抢单特性，为用户分配订单信息。订单分配过程可以由订单分配模块470实现。
以上对更新抢单特性过程的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。显然，对于本领域的专业人员来说，在了解了抢单特性的基本原理后，可能在不背离这一原理的情况下，对更新抢单特性的具体实施方式与步骤进行形式和细节上的各种修正和改变，但是这些修正和改变仍在以上描述的范围之内。例如，在一些实施例中，可以在步骤1510之后添加一个判断的步骤，用于判断是否有用户的订单抢单特性需要更新。若有，则进入步骤1520，生成数据更新消息；若没有，则结束该流程。在一些实施例中，可以在步骤1520之后添加一个统计步骤，用于统计哪些用户的订单抢单特性变化比较频繁。对于订单抢单特性变化比较频繁的用户可以根据实际情况进行适当的寻访、调查、监控等。诸如此类的变形，均在本申请的保护范围之内。
可以理解，上述关于抢单特性更新流程的描述，不仅适用于抢单特性的更新，也适用于其他信息的更新。例如，更新可以是针对用户的交通工具状态(例如，燃料剩余量、燃料消耗速率等)的更新、用户的习惯/喜好的更新等中的一种或多种。其中，用户的习惯/喜好可以包括但不限于乘客对于出发地、目的地、出发时间的偏好、乘客对于服务方的偏好、乘客可以接受的等待时间、乘客对于拼单的偏好、 乘客对于交通工具种类(例如，飞行器、火车、船舶、地铁、出租车、公交车、摩托车、自行车、步行等)的偏好、乘客对于业务类型(例如，出租车、快车、专车、顺风车、巴士、租车、代驾)的偏好、乘客对于交通工具型号的偏好、服务方对于出发地、目的地、出发时间的偏好、服务方对于行车路线的偏好、服务方的工作时间、服务方的爽约率、服务方的抢单量、抢单成功量、成交量、抢单成功率、成交率等中的一种或几种的组合。诸如此类的变形，均在本申请的保护范围之内。
根据本申请的一些实施例，图16是一种获取订单抢单特性的示例性流程图。在一些实施例中，图16中所描述的“用户”可以指“司机”。在步骤1610，采集订单的播单时间信息以及抢单时间信息。采集播单时间信息以及抢单时间信息的过程可以由用户信息提取模块420实现。在一些实施例中，采集订单的播单时间信息以及抢单时间信息，并保存所述播单时间信息和所述抢单时间信息，从而形成日志。其中，所述订单的播单时间信息可以是指订单信息播送给用户的时间点。所述订单的抢单时间信息可以是指用户订阅所述订单信息的时间点。在一些实施例中，采集的方式可以是处理模块210自动获取，可以是处理模块210向用户发送采集请求之后由用户上传订单的播单时间信息和抢单时间信息，也可以是用户主动上传订单的播单时间信息和抢单时间信息，本申请在此不作限制。在一些实施例中，订单的播单时间信息和抢单时间信息的采集可以是周期性的，也可以是非周期性的。周期性地采集订单的播单时间信息和抢单时间信息是指每隔固定的时间获取用户抢单特性，如每周、每天或每小时采集订单的播单时间信息和抢单时间信息等。每次采集的用户的数量可以是一个，也可以是多个。每次采集的用户的数量可以相同，也可以不同。
在步骤1620，读取预定时间内用户的多个订单的播单时间信息和抢单时间信息。读取播单时间信息以及抢单时间信息的过程可以由抢单特性计算单元434实现。具体地，在步骤1620，对多个日志进行汇总，获得预定时间段内用户的多个订单的播单时间信息和抢单时间信 息。在一些实施例中，可以在采集播单时间信息和抢单时间信息之后立即读取并汇总，也可以过一段时间读取并汇总，本申请在此不作限制。
在步骤1630，根据所述预定时间段内的用户的多个订单的播单时间信息和抢单时间信息，获得用户在所述预定时间段内的订单抢单特性。获得抢单特性的过程可以由抢单特性计算单元434实现。具体地，对于每一用户，分析该用户对应的每个订单的播单时间信息和抢单时间信息的差值，确定该用户在预定时间段内的抢单概率随时间变化的特性，获得该用户的订单抢单特性。在一些实施例中，对于同一用户，抢单特性针对的预设时间段可以是固定的，也可以根据实际情况进行调整。对于不同用户，抢单特性针对的预设时间段可以是相同的，也可以是不同的。
以上对获取抢单特性过程的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。显然，对于本领域的专业人员来说，在了解了抢单特性的基本原理后，可能在不背离这一原理的情况下，对获取抢单特性的具体实施方式与步骤进行形式和细节上的各种修正和改变，但是这些修正和改变仍在以上描述的范围之内。例如，每次可以处理一个用户的订单抢单特性，也可以处理多个用户的订单抢单特性。诸如此类的变形，均在本申请的保护范围之内。
根据本申请的一些实施例，图17-A和图17-B分别是两个不同用户在预定时间段内的抢单特性示意图。在一些实施例中，图17-A和图17-B中所描述的“用户”可以指“司机”。图中的抢单特性是基于2014年11月30日至2014年12月29日两个用户的抢单数据进行统计得到的。如图中所示，坐标0点可以表示订单信息播送给用户的时间点。如图17-A所示，为用户1的抢单特性。由图可知，用户1在0至5秒内抢单的概率较高，而5秒以后抢单的概率基本为0。如图17-B所示，为用户2的抢单特性，由图可知，用户2在5至20秒内抢单的概率较高，而在5秒以内抢单的概率基本为0。对比可知，用户1的抢单速度要大于用户2的抢单速度。而且当时间越来越长时，两个用 户抢单的可能性会越来越少。距离坐标0点时间很长后，两个用户基本上没有抢单的可能。
上述图15-17描述了获取及更新用户抢单特性的示例性流程。在一些实施例中，用户抢单特性及相关信息可以存储在订单分配引擎110中，或存储在本申请中所描述的任何一个存储设备中。在一些实施例中，处理模块210可以根据用户的抢单特性，基于一定预设条件，进行订单分配。预设条件可以是系统默认的，也可以根据情况实时调整。作为示例，抢单特性可以是用户抢单请求随时间的变化信息。系统可以根据用户在不同的时间段内的抢单特性，向用户分配订单。具体例如，假设用户抢单特性显示用户在每天上午10点抢单较为频繁，则系统可以在每天上午10点之前或之后的一定时间间隔内向用户分配订单。
根据本申请的一些实施例，图18是一种根据用户响应时间处理用户请求的示例性流程图。在步骤1810，接收响应订单的用户请求。接收响应订单的用户请求的过程可以由订单信息提取模块410实现。在一些实施例中，在下发订单后，可以接收来自用户的用于响应订单的用户请求。在一些实施例中，所述订单可以是实时订单，可以是预约订单，也可以是其他形式的订单，本申请在此不作限制。
在步骤1820，确定用户响应时间。确定用户响应时间的过程可以由响应时间计算单元435实现。在一些实施例中，接收到用户发送的响应请求后，会确定出与所述用户请求对应的用户响应时间。在一些实施例中，所述用户响应时间可以是从下发订单到接收到用户的响应请求之间的时间间隔。
在步骤1830，确定待选的用户请求。确定待选的用户请求的过程可以由响应时间计算单元435实现。在一些实施例中，根据在步骤1820确定的用户响应时间，确定出针对订单的待选用户请求。在一些实施例中，确定待选的用户请求的方式可以是利用用户响应时间与预定阈值(例如，预定响应时间)的比较来确定，可以是根据用户的历史响应时间数据来确定，可以是根据用户的响应时间在所有发送接收 订单的请求的用户中的排名来确定，可以是其他确定方式，也可以是以上几种方式的组合。
在步骤1840，处理其中一个用户请求。处理其中一个用户请求的过程可以由排序模块450实现。在一些实施例中，可以从在步骤1830确定的待选用户请求中选择其中一个用户请求进行处理，同时拒绝其他用户请求。在一些实施例中，可以在待选用户中随机选择一个用户请求进行处理，也可以根据一定指标在待选用户中选择一个用户请求进行处理。所述指标可以包括但不限于用户的响应时间、接单用户与订单中的出发地之间的距离、接单用户与订单中的出发地之间的行驶时间、订单预期收入、订单目的地方向是否与用户的预期行驶方向一致、道路的拥堵情况、用户的交通工具状态(例如，燃料剩余量、燃料消耗速率等)、用户习惯/喜好、其他影响选择用户请求的因素等的一种或几种的组合。其中，所述用户习惯/喜好可以包括但不限于消费方对于出发地、目的地、出发时间的偏好、消费方对于服务方的偏好、消费方可以接受的等待时间、消费方对于拼单的偏好、消费方对于交通工具种类(例如，飞行器、火车、船舶、地铁、出租车、公交车、摩托车、自行车、步行等)的偏好、消费方对于业务类型(例如，出租车、快车、专车、顺风车、巴士、租车、代驾)的偏好、消费方对于交通工具型号的偏好、服务方对于出发地、目的地、出发时间的偏好、服务方对于行车路线的偏好、服务方的工作时间、服务方的爽约率、服务方的抢单特性、服务方的抢单量、抢单成功量、成交量、抢单成功率、成交率等中的一种或几种的组合。
在一些实施例中，可以只根据一项指标在待选用户请求中选择其中一个用户请求进行处理。例如，可以只根据用户的响应时间进行选择，可以选择用户响应时间最短的用户来下发订单。例如，可以只根据接单用户与订单中的出发地之间的距离进行选择，可以选择接单用户与订单中的出发地之间的距离最短的用户来下发订单。在一些实施例中，可以根据多项指标在待选用户请求中选择其中一个用户请求进行处理。例如，可以根据接单用户与订单中的出发地之间的距离和用 户的响应时间两项指标，并且分别赋予各自权重，针对每个待选用户利用所述接单用户与订单中的出发地之间的距离和所述用户的响应时间基于权重来分别计算评分，将订单下发给评分最高的待选用户。
需要注意的是，以上关于处理用户响应请求流程的描述，仅为描述方便，并不能把本申请限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解本申请的基本原理后，可以在不背离这一原理的情况下，对处理用户响应请求流程作出改变。例如，在一些实施例中，可以在步骤1820之后添加一个统计的步骤，用于统计哪些用户的响应时间经常属于不合理响应时间范围。对于这些用户可以根据实际情况采取适当的寻访、调查、监控、设置权限、加入黑名单等措施。诸如此类的变形，均在本申请的保护范围之内。
根据本申请的一些实施例，图19是一种确定待选用户请求的示例性流程图。在步骤1910，确定用户响应时间(详见步骤1820)。在步骤1920，判断用户响应时间是否小于第一预定时间间隔T1。若用户响应时间小于第一预定时间间隔T1，则进入步骤1950，拒绝用户请求；若用户响应时间大于或等于第一预定时间间隔T1，则进入步骤1930。在步骤1930，判断用户响应时间是否大于第二预定时间间隔T2。若用户响应时间大于第二预定时间间隔T2，则进入步骤1960，确定该用户请求为待选的用户请求；若用户响应时间小于或等于第二预定时间间隔T2，则进入步骤1940，判断用户请求数目是否大于预定阈值。判断过程可以由判断模块440实现。在一些实施例中，所述第二预定时间间隔T2可以大于所述第一预定时间间隔T1。在一些实施例中，可以将所述第一预定时间间隔T1设定为明显不在合理时间间隔内的时间差，将所述第二预定时间间隔T2设定为明显在合理时间间隔内的时间差。在一些实施例中，可以基于用户反应时间、发送订单所需要的时间、接收用户请求所需要的时间来设定所述第一预定时间间隔T1以及所述第二预定时间间隔T2。其中，所述用户反应时间可以包括但不限于用户了解订单信息所需要的时间、用户做出决定所需要的时间等中的一种或几种的组合。所述用户了解订单信息所需 要的时间可以包括但不限于用户浏览订单所需要的时间、语音订单播报所需要的时间、视频订单播放所需要的时间等中的一种或几种的组合。所述发送订单所需要的时间以及所述接收用户请求所需要的时间可以根据移动网络运营商的传输速率来设定。在一些实施例中，假设正常用户对订单的反应时间最快可以为t1，最慢可以为t2，其中t2＞t1。假设发送订单所需要的时间可以为t3，接收用户请求所需要的时间可以为t4。则可以设定第一预设时间间隔T1＝t1+t3+t4，第二预设时间间隔T2＝t2+t3+t4。例如，在一些实施例中，用户了解订单信息需要的时间可以为1.0-2.0秒，用户做出决定所需要的时间可以为0.5-1.0秒。因此，用户对订单的正常反应时间可以为1.5-3.0秒。所以t1＝1.5秒，t2＝3.0秒。发送订单所消耗的时间t3以及接收用户请求所消耗的时间t4可以分别设置为1.0秒。因此，根据以上数据，可以设定第一预定时间间隔T1为1.7秒以及第二预定时间间隔T2为3.2秒。在一些实施例中，如果发现某个用户的响应时间T小于T1(例如，1.7秒)，例如仅为0.5秒，则可以拒绝该用户的用户请求。如果发现某个用户的响应时间大于T2(例如，3.2秒)，例如4秒，则可以将该用户的用户请求确定为待选用户请求。如果发现某个用户的响应时间大于或等于T1(例如，1.7秒)且小于或等于T2(例如，3.2秒)，例如2秒，则可以进入步骤1940，判断用户请求数目是否大于预定阈值。
在步骤1940，判断用户请求数目是否大于预定阈值。判断过程可以由判断模块440实现。若用户请求数目大于预定阈值，则进入步骤1950，拒绝用户请求；若用户请求数目小于或等于预定阈值，则进入步骤1960，确定该用户请求为待选的用户请求。在一些实施例中，可以对实时接收到的针对该订单的用户请求进行计数，从而确定出接收到的针对订单的用户请求的数目N。
以上对确定待选用户请求过程的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。显然，对于本领域的专业人员来说，在了解确定待选用户请求的基本原理后，可能在不背离这一原理的情况下，对确定待选用户请求的具体实施方式与步骤进行形式和细节上的 各种修正和改变，但是这些修正和改变仍在以上描述的范围之内。例如，在一些实施例中，在步骤1910之后，可以先进行步骤1930，判断用户响应时间是否大于第二预定时间间隔T2。若用户响应时间大于第二预定时间间隔T2，则进入步骤1960；若用户响应时间小于或等于第二预定时间间隔T2，则进入步骤1920，判断用户响应时间是否小于第一预定时间间隔T1。若用户响应时间小于第一预定时间间隔T1，则进入步骤1950；若用户响应时间大于第一预定时间间隔T1，则进入步骤1940。在一些实施例中，在步骤1910之后，可以判断用户响应时间是否落入预定阈值范围[T1，T2]。若用户响应时间落入预定阈值范围，则进入步骤1940；若用户响应时间没有落入预定阈值范围，可以先判断用户响应时间是否小于第一预定时间间隔T1，在判断用户响应时间是否大于第二预定时间间隔T2，或者先判断用户响应时间是否大于第二预定时间间隔T2，在判断用户响应时间是否小于第一预定时间间隔T1。诸如此类的变形，均在本申请的保护范围之内。
根据本申请的一些实施例，图20是一种订单分配的示例性流程图。在一些实施例中，图20中所描述的“用户”可以指“司机”。在步骤2010，可以获取包括多个待分配订单的订单群和包括多个待接单用户的用户群。获取订单群和用户群的过程可以由订单信息提取模块410或用户信息提取模块420实现。在一些实施例中，待分配订单可以是实时订单，也可以是预约订单。待分配订单可以是已经创建但是尚未推送给服务方的订单，可以是已经向服务方推送但是在一段时间之后没有被抢单的订单，也可以是服务方在抢单成功之后服务方或消费方爽约或毁约的订单，也可以是以上几种订单的组合。在一些实施例中，待接单用户的状态可以是空闲状态、即将完成订单服务的状态、可拼单状态等。根据本申请的一些实施例，在步骤2010中，可以基于一个地理区域来获取订单群和用户群。具体而言，可以将某个地理区域中的当前所有订单确定为订单群，并且将该地理区域中的当前所有待接单用户确定为用户群。例如，该地理区域可以包括省、城市、县市等通过行政区域来划分的地理区域，可以是通过地理上的经度和纬度 来划分的地理区域，也可以是通过商圈、地标等来划分的地理区域。可以理解，本申请并不受具体的地理区域的划分方式的限制。
在步骤2020，可以基于订单群和用户群来确定订单分配方式。确定订单分配方式的过程可以由处理模块210实现。在一些实施例中，步骤2020进一步包括基于订单群和用户群，并且根据订单成交率、抢单成功率以及听单抢单率中的至少一项来确定订单分配方式。其中所述订单成交率是指在订单群中的最终成交的订单与订单群中的所有订单的比率。所述抢单成功率是指用户群中的用户实施的成功抢单操作的数量与用户实施的抢单操作的数量的比率。所述听单抢单率是指用户群中的用户对推送给他的订单实施抢单操作的数量与订单群中被推送给他的订单数量的比率。可以理解，根据订单成交率、抢单成功率以及订单抢单率中的至少一项来确定订单分配的方式仅仅是基于订单群和用户群来确定订单分配方式的一种实施方式。本领域的技术人员可以在具体的不同的技术环境、应用场景、以及设计要求的情况下，采用其他指标或其他方式来基于订单群和用户群而确定订单分配方式。其中，其他指标可以是订单的竞争概率等。
根据本发明的一些实施例，根据订单成交率、抢单成功率以及听单抢单率中的至少一项来确定订单分配方式可以包括：计算订单成交率、抢单成功率以及听单抢单率的加权和；以及确定使得该加权和最大的订单分配方式，作为所确定的订单分配方式。具体而言，本领域的技术人员可以根据实际的技术场景或者环境来设置这三个指标之间的权重，可以用如下公式(8)表示：
E＝α1*EOrderSuccRate+α2*EStriveSuccRate+α3*EStriveRate，   (8)
其中，EOrderSuccRate可以表示订单成交率，EStriveSuccRate可以表示抢单成功率，EStriveRate可以表示听单抢单率，E可以表示这三个指标的加权和，α1、α2、α3可以分别表示这三个指标的权重值。权重值的设置方法可以包括但不限于主观经验法，主次指标排队分类法，专家调查法等中的一种或几种的组合。在一些实施例中，选择使得三个指标的加权和E最大的订单分配方式作为最终确定的订单分配方式。可以 理解，本领域的技术人员可以采用其他的方式来综合考虑这三个指标而最终确定订单分配方式，本申请并不局限于如上所述的线性加权方式，该方式仅仅是本申请的实施例的一种示例。
在一些实施例中，可以使用以下算法中的至少一种来确定使得上述加权和E最大的订单分配方式：穷举法、遗传算法、蚁群算法、禁忌搜索算法、模拟退火算法、基于贪心的爬山算法等。可以理解，本领域的技术人员还可以采用其他的智能算法和非智能算法来对上述模型进行求解，本申请对此不做限制。
在步骤2030，根据所确定的订单分配方式，向用户群中的用户推送订单群中的订单。推送订单的过程可以由订单生成模块460或订单分配模块470实现。在一些实施例中，所确定的订单分配方式可以是向一个用户推送一个订单，也可以是向一个用户推送多个订单；一个订单可以在一个时间仅被推送给一个用户，也可以在一个时间被推送给多个用户；可以向每个用户至少推送一个订单，也可以在没有适合订单的情况下不向某些用户推送订单。可以理解，具体的推送订单的个数以及规则可以根据具体的技术场景和需求来选择，本申请在此不做限制。发送的订单信息的形式可以包括但不限于文字、图片、音频、视频等中的一种或几种的组合。
以上对于订单分配过程的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。显然，对于本领域的专业人员来说，在了解订单分配的基本原理后，可能在不背离这一原理的情况下，对订单分配的具体实施方式与步骤进行形式和细节上的各种修正和改变，但是这些修正和改变仍在以上描述的范围之内。例如，例如，可以在订单分配流程中添加数据缓存的步骤用来存储当前待分配订单或待接单用户、新数据的进入、过期数据的删除等工作。具体而言，在订单被创建时或者被推送但是在一段时间之后未被抢单，或者被成功抢单但是服务方或消费方爽约或毁约时，将该订单添加到订单缓存区中，并且在订单被推送给用户之后，从订单缓存区删除该订单。此外，当用户处于待接单状态时，将该用户添加到用户缓存区中，并且当用户抢单 成功之后，从用户缓存区删除该用户。数据缓存的步骤可以在步骤2010、步骤2020或步骤2030之前，可以在步骤2030之后，也可以与任一步骤同时进行。在一些实施例中，在确定使得加权和最大的处理过程中，可以基于预定规则来生成初始的订单分配方式，再使用基于贪心的爬山算法对初始的订单分配方式进行优化，从而确定使得加权和最大的订单分配方式。诸如此类的变形，均在本申请的保护范围之内。
根据本申请的一些实施例，图21是一种确定订单分配方式的示例性流程图。在一些实施例中，图21中所描述的“用户”可以指“司机”。在步骤2110，获取当前订单群和用户群(详见步骤2010)。在步骤2120，计算当前任一用户对任一订单的抢单概率。计算抢单概率的过程可以由处理模块210实现。在一些实施例中，可以基于用户群中的任一用户对订单群中的任一订单的抢单概率，分别计算订单成交率、抢单成功率以及听单抢单率。在一些实施例中，假设在订单群中存在No个订单，用户群中存在Nd个用户，则用户群中的用户i对订单群中的订单i的抢单概率可以表示为Pij。那么订单成交率、抢单成功率以及听单抢单率可以表示为下述公式：
Figure PCTCN2016072837-appb-000011
Figure PCTCN2016072837-appb-000012
Figure PCTCN2016072837-appb-000013
其中，
Figure PCTCN2016072837-appb-000014
可以理解，还可以根据其他的方式从抢单概率推导出订单成交率、抢单成功率以及听单抢单率。可以理解，除了抢单概率，还可以根据其他信息得出订单成交率、抢单成功率以及听单抢单率。本申请在此不作限制。
在一些实施例中，可以基于与待接单用户和发出订单的用户有关的状态特征来计算抢单概率Pij。这样的状态特征可以包括但不限于接单用户与订单中的出发地之间的距离、接单用户与订单中的出发地之间的行驶时间、订单预期收入、订单目的地方向是否与用户的预期行驶方向一致、道路的拥堵情况、用户的交通工具状态(例如，燃料剩余量、燃料消耗速率等)、用户习惯/喜好、其他影响选择用户请求的因素等的一种或几种的组合。其中，所述用户习惯/喜好可以包括但不限于消费方对于出发地、目的地、出发时间的偏好、消费方对于服务方的偏好、消费方可以接受的等待时间、消费方对于拼单的偏好、消费方对于交通工具种类(例如，飞行器、火车、船舶、地铁、出租车、公交车、摩托车、自行车、步行等)的偏好、消费方对于业务类型(例如，出租车、快车、专车、顺风车、巴士、租车、代驾)的偏好、消费方对于交通工具型号的偏好、服务方对于出发地、目的地、出发时间的偏好、服务方对于行车路线的偏好、服务方的工作时间、服务方的爽约率、服务方的抢单特性、服务方的抢单量、抢单成功量、成交量、抢单成功率、成交率等中的一种或几种的组合。在这种情况下，抢单概率Pij可以表示为：
Figure PCTCN2016072837-appb-000015
其中，Xij可以表示状态特征所组成的特征向量，W可以表示Xij中每个状态特征所对应的权重，W可以根据具体的技术场景和需求来设置。权重值的设置方法可以包括但不限于主观经验法，主次指标排队分类法，专家调查法等中的一种或几种的组合。
在步骤2130，建立模型并对模型进行求解，得到分配矩阵。求解并得到分配矩阵的过程可以由处理模块210实现。在一些实施例中，可以基于订单群和用户群的订单分配方法通过建立模型来进行分析和求解。首先，在业务上假设一个服务方用户同时只能接受一个订单，同一订单可以推送给多个服务方。当多个服务方对同一订单发起抢单请求时，只有一个服务方能抢单成功，其余服务方则抢单失败。在这个业务场景下，对订单分配模型可以在数学上建模如下：
Figure PCTCN2016072837-appb-000016
在上述模型中，EOrderSuccRate、EStriveSuccRate、EStriveRate可以为核心业务指标，E可以为以上若干核心指标的加权和。模型的优化目标可以为加权和目标最大。模型的解可以为矩阵{dij，i∈[0，No]，j∈[0，Nd]}。也就是，对No个待分配订单，Nd个待接单用户，按照上面的约束及对 应的抢单率Pij，求出使综合目标E最大的分配方式D＝{dij}。
以上对于订单分配过程的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。显然，对于本领域的专业人员来说，在了解订单分配的基本原理后，可能在不背离这一原理的情况下，对订单分配的具体实施方式与步骤进行形式和细节上的各种修正和改变，但是这些修正和改变仍在以上描述的范围之内。例如，可以将计算过程中得到的数据存储起来作为历史数据，在建立模型求解分配矩阵的过程中，可以参考历史数据进行分析和求解。诸如此类的变形，均在本申请的保护范围之内。
以下以打车系统为例从具体的示例方面来论述根据本申请的实施例的订单分配方法及系统。在讨论如何进行订单分配之前，先进行以下假设。
假设1：司机决定是否发起抢单请求，与司机和订单间的距离正相关，司机距离订单越近，司机越愿意抢单，距离越远，司机越不愿意抢单。假设2：如果司机距离订单非常远，则该司机几乎不会参加抢单，因为接驾将要空驶很长距离，导致收益不高。假设3：乘客发出订单后，有一定的忍耐度，如果较长时间还没有司机应答，乘客会取消订单。
例如，订单1距离司机1有500米，距离司机2有400米；订单2距离司机1有2000米，距离司机2有500米。首先，将当前所有乘客(订单)作为一个整体，记为订单群，将当前所有待接单用户(司机)作为一个整体，记为用户群，在分配过程中，以订单群和用户群作为分配单位，因此该模型是订单-司机多对多的订单分配系统。其次，确定全局期望目标和个体期望目标，建立全局目标和个体目标间的联系。对个体目标而言，希望每个司机积极响应对其推送的订单，因此假设所有司机对定单的抢单意愿服从同一条件概率分布P(STRIVE＝1|X)，其中，STRIVE＝1可以表示司机抢单，STRIVE＝0可以表示司机不抢单，X可以表示当前司机与司机的状态特征信息。当前司机与司机的状态特征信息可以包括但不限于待接单用户与订 单中的出发地之间的距离、接单用户与订单中的出发地之间的行驶时间、订单预期收入、乘客加价、乘客目的地方向是否与用户的预期行驶方向一致、订单目的地接单的难易程度、道路的拥堵情况、天气情况、用户的交通工具状态(例如，燃料剩余量、燃料消耗速率等)、用户习惯/喜好、其他影响接单待接单用户对于订单的抢单意愿的因素等的一种或几种的组合。同时，确定平台全局目标为所有订单成交率E，成交率是所有司机抢单期望的函数E＝F(P)。
对于抢单概率P(STRIVE＝1|X)，可以采用机器学习的方法训练预估，训练样本为历史播单抢单数据{Yij|Xij}，该记录表示一次推送记录，即某订单对某司机的一次推送，其中Xij表示该推送时刻的若干特征向量，包括但不限于待接单用户与订单中的出发地之间的距离、接单用户与订单中的出发地之间的行驶时间、订单预期收入、乘客加价、乘客目的地方向是否与用户的预期行驶方向一致、订单目的地接单的难易程度、道路的拥堵情况、天气情况、用户的交通工具状态(例如，燃料剩余量、燃料消耗速率等)、用户习惯/喜好、其他影响接单待接单用户对于订单的抢单意愿的因素等的一种或几种的组合，Yi表示推送后，司机是否发生抢单，1为抢单，2为未抢单。预测模型可以采用工业界广泛使用的LR模型(类似模型还有线性回归、svm、gbdt等)。LR模型将概率预估表示为以下公式(15)：
Figure PCTCN2016072837-appb-000017
其中，Xij可以为该推送时刻的若干特征向量，W可以为Xij中每个特征对应的权重。特征向量可以包括但不限于待接单用户与订单中的出发地之间的距离、接单用户与订单中的出发地之间的行驶时间、订单预期收入、乘客加价、乘客目的地方向是否与用户的预期行驶方向一致、订单目的地接单的难易程度、道路的拥堵情况、天气情况、用户的交通工具状态(例如，燃料剩余量、燃料消耗速率等)、用户习惯/喜好、其他影响接单待接单用户对于订单的抢单意愿的因素等的一种或几种的组合。
采用离线的方法，用历史播单抢单记录对模型进行训练，然后在线上就可以实时对每一(订单，司机)对，进行抢单率预估，叫做STR(striVe through rate)预估。获得任一对(订单i，司机j)的预估抢单率Pij后，就可以按照图21所描述的方式开始对订单分配方式进行建模。首先计算抢单概率Pij，这里为了简单性的缘故只使用了距离这一个特征。经过线下的机器训练，距离特征的权重为0.001，因此抢单概率的公式可以记为：
Figure PCTCN2016072837-appb-000018
按照上述公式(16)计算，抢单概率的计算结果如下表5所示。
表5用户抢单概率计算结果示例
  订单1 订单2
司机1 0.38 0.12
司机2 0.4 0.38
其次，求解模型，得到订单分配的解。在本实施例中，为了简单起见，可以只考虑成交率一个核心指标，则每个分配方式对应的成交率如下：
Figure PCTCN2016072837-appb-000019
从上述每个分配方式对应的成交率可以看出，(订单1，司机1)、(订单2，司机2)是使成交率最大的解，因此选择该订单分配方式并按此订单分配方式向司机分配订单。上述描述仅仅是为了举例说明订单分配的一种实现方式，并不对本申请构成任何限制。
图22描述了一种移动设备的结构，该移动设备能够用于实现实施本申请中披露的特定系统。在本例中，用于显示和交互位置相关信息的用户设备是一个移动设备2200，包括但不限于，智能手机、平板电 脑、音乐播放器、便携游戏机、全球定位系统(GPS)接收器、可穿戴计算设备(如眼镜、手表等)，或者其他形式。本例中的移动设备2200包括一个或多个中央处理器(CPUs)2240，一个或多个图形处理器(graphical processing units(GPUs))2230，一个显示2220，一个内存2260，一个天线2210，例如一个无线通信单元，存储单元2290，以及一个或多个输入/输出(input output(I/O))设备2250。任何其他合适的组件，包括但不限于系统总线或控制器(图上未显示)，也可能被包括在移动设备2200中。如图22所示，一个移动操作系统2270，如iOS，安卓，Windows Phone等，以及一个或多个应用2280可以从存储单元2290加载进内存2260中，并被中央处理器2240所执行。应用2280可能包括一个浏览器或其他适合在移动设备2200上接收并处理位置相关信息的移动应用。用户关于位置相关信息的交互可以通过输入/输出系统设备2250获得并提供给订单处理引擎110，以及/或系统100的其他组件，例如：通过网络150。
为了实现不同的模块、单元以及在之前的披露中所描述的他们的功能，计算机硬件平台可以被用作以上描述的一个或多个元素的硬件平台(例如：订单处理引擎110，和/或图1-20中描述的系统100的其他组件)。这类计算机的硬件元素、操作系统和程序语言在自然界中是常见的，可以假定本领域技术人员对这些技术都足够熟悉，能够利用这里描述的技术提供按需服务所需要的信息。一台包含用户界面元素的计算机能够被用作个人计算机(personal computer(PC))或其他类型的工作站或终端设备，被适当程序化后也可以作为服务器使用。可以认为本领域技术人员对这样的结构、程序以及这类计算机设备的一般操作都是熟悉的，因此所有附图也都不需要额外的解释。
图23描述了一种计算机设备的架构，这种计算机设备能够被用于实现实施本申请中披露的特定系统。本实施例中的特定系统利用功能框图解释了一个包含用户界面的硬件平台。这种计算机可以是一个通用目的的计算机，也可以是一个有特定目的的计算机。两种计算机都可以被用于实现本实施例中的特定系统。计算机2300可以用于实施当 前描述地提供按需服务所需要的信息的任何组件。例如：订单处理引擎110能够被如计算机2300的计算机通过其硬件设备、软件程序、固件以及他们的组合所实现。图中为了方便起见只绘制了一台计算机，但是本实施例所描述的提供按需服务所需要的信息的相关计算机功能是可以以分布的方式、由一组相似的平台所实施的，分散系统的处理负荷。
计算机2300包括通信端口2350，与之相连的是实现数据通信的网络。计算机2300还包括一个中央处理系统(CPU)单元用于执行程序指令，由一个或多个处理器组成。示例的计算机平台包括一个内部通信总线2310，不同形式的程序储存单元以及数据储存单元，例如硬盘2370，只读存储器(ROM)2330，随机存取存储器(RAM)2340，能够用于计算机处理和/或通信使用的各种数据文件，以及CPU所执行的可能的程序指令。计算机2300还包括一个输入/输出组件2360，支持计算机与其他组件(如用户界面2380)之间的输入/输出数据流。计算机2300也可以通过通信网络接受程序及数据。
以上概述了提供按需服务所需要的信息的方法的不同方面和/或通过程序实现其他步骤的方法。技术中的程序部分可以被认为是以可执行的代码和/或相关数据的形式而存在的“产品”或“制品”，是通过计算机可读的介质所参与或实现的。有形的、永久的储存介质包括任何计算机、处理器、或类似设备或相关的模块所用到的内存或存储器。例如各种半导体存储器、磁带驱动器、磁盘驱动器或者类似任何时间能够为软件提供存储功能的设备。
所有软件或其中的一部分有时可能会通过网络进行通信，如互联网或其他通信网络。此类通信能够将软件从一个计算机设备或处理器加载到另一个。例如：从按需服务系统的一个管理服务器或主机计算机加载至一个计算机环境的硬件平台，或其他实现系统的计算机环境，或与提供按需服务所需要的信息相关的类似功能的系统。因此，另一种能够传递软件元素的介质也可以被用作局部设备之间的物理连接，例如光波、电波、电磁波等，通过电缆、光缆或者空气实现传播。用 来载波的物理介质如电缆、无线连接或光缆等类似设备，也可以被认为是承载软件的介质。在这里的用法除非限制了有形的“储存”介质，其他表示计算机或机器“可读介质”的术语都表示在处理器执行任何指令的过程中参与的介质。
因此，一个计算机可读的介质可能有多种形式，包括但不限于，有形的存储介质，载波介质或物理传输介质。稳定的储存介质包括：光盘或磁盘，以及其他计算机或类似设备中使用的，能够实现图中所描述的系统组件的存储系统。不稳定的存储介质包括动态内存，例如计算机平台的主内存。有形的传输介质包括同轴电缆、铜电缆以及光纤，包括计算机系统内部形成总线的线路。载波传输介质可以传递电信号、电磁信号，声波信号或光波信号，这些信号可以由无线电频率或红外数据通信的方法所产生的。通常的计算机可读介质包括硬盘、软盘、磁带、任何其他磁性介质；CD-ROM、DVD、DVD-ROM、任何其他光学介质；穿孔卡、任何其他包含小孔模式的物理存储介质；RAM、PROM、EPROM、FLASH-EPROM，任何其他存储器片或磁带；传输数据或指令的载波、电缆或传输载波的连接装置、任何其他可以利用计算机读取的程序代码和/或数据。这些计算机可读介质的形式中，会有很多种出现在处理器在执行指令、传递一个或更多结果的过程之中。
本领域技术人员能够理解，本申请所披露的内容可以出现多种变型和改进。例如，以上所描述的不同系统组件都是通过硬件设备所实现的，但是也可能只通过软件的解决方案得以实现。例如：在现有的服务器上安装系统。此外，这里所披露的位置信息的提供可能是通过一个固件、固件/软件的组合、固件/硬件的组合或硬件/固件/软件的组合得以实现。
以上内容描述了本申请和/或一些其他的示例。根据上述内容，本申请还可以作出不同的变形。本申请披露的主题能够以不同的形式和例子所实现，并且本申请可以被应用于大量的应用程序中。后文权利要求中所要求保护的所有应用、修饰以及改变都属于本申请的范围。

Claims (20)

  1. 一种订单处理方法，包括：
    接收订单并提取订单信息；
    提取服务提供者信息并获得服务提供者特征；
    判断所述订单信息是否与所述服务提供者特征匹配，或判断所述服务提供者特征是否满足预设条件，生成判断结果；
    根据所述判断结果，对所述服务提供者进行排序；
    生成待分配订单；并且
    根据所述排序，向所述服务提供者分配所述待分配订单。
  2. 根据权利要求1所述的订单处理方法，所述订单信息包括时间、时段、位置及区域。
  3. 根据权利要求1所述的订单处理方法，所述服务提供者特征包括：订单相似度、偏好度、爽约率、抢单特性及响应时间。
  4. 根据权利要求3所述的订单处理方法，所述订单相似度包括历史订单与当前订单的余弦相似度。
  5. 根据权利要求3所述的订单处理方法，所述偏好度包括偏好区域及偏好时段。
  6. 根据权利要求3所述的订单处理方法，进一步包括：
    从所述服务提供者获得或计算获得所述偏好度。
  7. 根据权利要求3所述的订单处理方法，进一步包括：
    获取所述待分配订单的目的地对应的经纬度坐标；
    计算所述待分配订单的目的地对应的经纬度坐标与所述服务提供者的目的地偏好区域的中心点的距离Az；
    根据所述距离Az以及所述服务提供者的目的地偏好区域的覆盖半径d计算所述服务提供者对所述待分配订单的目的地的偏好度L，
    Figure PCTCN2016072837-appb-100001
    Figure PCTCN2016072837-appb-100002
  8. 根据权利要求3所述的订单处理方法，获得所述爽约率包括使用如下公式计算：
    Figure PCTCN2016072837-appb-100003
    其中Tx为爽约率，k为服务提供者x被分配的最近n个订单中的爽约订单个数，
    Figure PCTCN2016072837-appb-100004
    为n选k的组合数，p为平均爽约率。
  9. 根据权利要求3所述的订单处理方法，进一步包括：
    根据所述响应时间，确定针对所述订单的待选服务提供者请求；
    从所述待选服务提供者请求中选择其中一个服务提供者请求进行处理。
  10. 根据权利要求1所述的订单处理方法，进一步包括：
    确定一个地理区域，根据所述地理区域确定订单群和服务提供者群；
    分析所述订单群和所述服务提供者群，确定订单成交率、抢单成功率及听单抢单率；
    计算所述订单成交率、所述抢单成功率及所述听单抢单率的加权和；
    根据所述加权和，确定订单分配方式。
  11. 一种系统，包括：
    一种计算机可读的存储媒介，被配置为存储可执行模块，包括：
    订单提取模块，用于接收订单并提取订单信息；
    服务提供方信息提取模块，用于提取服务提供方信息并获得服务提供方特征；
    判断模块，用于判断所述订单信息是否与所述服务提供者特征匹配，或判断所述服务提供者特征是否满足预设条件，生成判断结果；
    排序模块，用于根据所述判断结果，对所述服务提供者进行排序；
    订单生成模块，用于生成待分配订单；及
    订单分配模块，用于根据所述排序，向所述服务提供者分配所述待分配订单，和
    一个处理器，所述处理器能够执行所述计算机可读的存储媒介存储的可执行模块。
  12. 根据权利要求11所述的系统，所述订单信息包括时间、时段、位置 及区域。
  13. 根据权利要求11所述的系统，所述服务提供者特征包括：订单相似度、偏好度、爽约率、抢单特性及响应时间。
  14. 根据权利要求13所述的系统，所述订单相似度包括历史订单与当前订单的余弦相似度。
  15. 根据权利要求13所述的系统，所述偏好度包括偏好区域及偏好时段。
  16. 根据权利要求13所述的系统，进一步包括：
    从所述服务提供者获得或计算获得所述偏好度。
  17. 根据权利要求13所述的系统，进一步包括：
    获取所述待分配订单的目的地对应的经纬度坐标；
    计算所述待分配订单的目的地对应的经纬度坐标与所述服务提供者的目的地偏好区域的中心点的距离Az；
    根据所述距离Az以及所述服务提供者的目的地偏好区域的覆盖半径d计算所述服务提供者对所述待分配订单的目的地的偏好度L，
    Figure PCTCN2016072837-appb-100005
    Figure PCTCN2016072837-appb-100006
  18. 根据权利要求13所述的系统，获得所述爽约率包括使用如下公式计算：
    Figure PCTCN2016072837-appb-100007
    其中Tx为爽约率，k为服务提供者x被分配的最近n个订单中的爽约订单个数，
    Figure PCTCN2016072837-appb-100008
    为n选k的组合数，p为平均爽约率。
  19. 根据权利要求13所述的系统，进一步包括：
    根据所述响应时间，确定针对所述订单的待选服务提供者请求；
    从所述待选服务提供者请求中选择其中一个服务提供者请求进行处理。
  20. 根据权利要求11所述的系统，进一步包括：
    确定一个地理区域，根据所述地理区域确定订单群和服务提供者群；
    分析所述订单群和所述服务提供者群，确定订单成交率、抢单成功率及听单抢单率；
    计算所述订单成交率、所述抢单成功率及所述听单抢单率的加权和；根据所述加权和，确定订单分配方式。
PCT/CN2016/072837 2015-02-02 2016-01-29 一种订单处理方法与系统 WO2016124118A1 (zh)

Priority Applications (7)

Application Number Priority Date Filing Date Title
MYPI2017001131A MY181464A (en) 2015-02-02 2016-01-29 Methods and systems for order processing
SG11201706269QA SG11201706269QA (en) 2015-02-02 2016-01-29 Methods and systems for order processing
PH12017501388A PH12017501388A1 (en) 2015-02-02 2016-01-29 Methods and systems for order processing
GB1712642.6A GB2550523A (en) 2015-02-02 2016-01-29 Methods and systems for order processing
US15/547,528 US10657581B2 (en) 2015-02-02 2016-01-29 Methods and systems for order processing
HK18106251.1A HK1246941A1 (zh) 2015-02-02 2018-05-15 訂單處理方法及系統
US16/869,447 US11315170B2 (en) 2015-02-02 2020-05-07 Methods and systems for order processing

Applications Claiming Priority (16)

Application Number Priority Date Filing Date Title
CN201510053500.6A CN104599168A (zh) 2015-02-02 2015-02-02 叫车订单的分配方法和装置
CN201510053500.6 2015-02-02
CN201510065334.1 2015-02-06
CN201510065334.1A CN104598978A (zh) 2015-02-06 2015-02-06 用于处理预约订单的方法及设备
CN201510075815.0 2015-02-12
CN201510075815.0A CN104639646B (zh) 2015-02-12 2015-02-12 用于处理用户请求的方法和设备
CN201510149155.6A CN104715285B (zh) 2015-03-31 2015-03-31 处理订单的方法和设备
CN201510149155.6 2015-03-31
CN201510174117.6A CN105005816A (zh) 2015-04-13 2015-04-13 订单处理方法及装置
CN201510174117.6 2015-04-13
CN201510207953.XA CN104867016A (zh) 2015-04-28 2015-04-28 订单抢单特性的自动更新方法及系统
CN201510207953.X 2015-04-28
CN201510633919.9 2015-09-29
CN201510633919.9A CN105160021A (zh) 2015-09-29 2015-09-29 基于目的地偏好的订单分配方法及装置
CN201610035351.5 2016-01-19
CN201610035351.5A CN105719173A (zh) 2016-01-19 2016-01-19 订单处理方法和订单处理设备

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US15/547,528 A-371-Of-International US10657581B2 (en) 2015-02-02 2016-01-29 Methods and systems for order processing
US16/869,447 Continuation US11315170B2 (en) 2015-02-02 2020-05-07 Methods and systems for order processing

Publications (1)

Publication Number Publication Date
WO2016124118A1 true WO2016124118A1 (zh) 2016-08-11

Family

ID=56563461

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/072837 WO2016124118A1 (zh) 2015-02-02 2016-01-29 一种订单处理方法与系统

Country Status (7)

Country Link
US (2) US10657581B2 (zh)
GB (1) GB2550523A (zh)
HK (1) HK1246941A1 (zh)
MY (1) MY181464A (zh)
PH (1) PH12017501388A1 (zh)
SG (1) SG11201706269QA (zh)
WO (1) WO2016124118A1 (zh)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108734950A (zh) * 2017-04-18 2018-11-02 北京嘀嘀无限科技发展有限公司 拼车方法及装置、网络约车方法及装置
US10458806B2 (en) 2015-01-27 2019-10-29 Beijing Didi Infinity Technology And Development Co., Ltd. Methods and systems for providing information for an on-demand service
CN111052158A (zh) * 2017-07-20 2020-04-21 北京嘀嘀无限科技发展有限公司 用于分配服务请求的系统和方法
WO2020114481A1 (zh) * 2018-12-06 2020-06-11 北京嘀嘀无限科技发展有限公司 一种信息处理方法、系统、装置及计算机可读存储介质
US20210172748A1 (en) * 2018-07-31 2021-06-10 Honda Motor Co., Ltd. Visit management apparatus, visit management method and visit management system
TWI760254B (zh) * 2020-02-13 2022-04-01 華南商業銀行股份有限公司 使用類神經網路的自動儲蓄方法
TWI764767B (zh) * 2019-02-13 2022-05-11 華南商業銀行股份有限公司 規劃客製化定存轉帳金額的自動儲蓄系統
EP3783506B1 (en) * 2018-06-21 2024-04-17 Shenzhen Institutes of Advanced Technology Parking lot data repair method and apparatus, device and storage medium

Families Citing this family (68)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10593005B2 (en) * 2014-09-03 2020-03-17 Meru Cab Company Private Limited Dynamic forecasting for forward reservation of cab
US10977585B2 (en) 2015-01-29 2021-04-13 Beijing Didi Infinity Technology And Development Co., Ltd. Order allocation system and method
US9904900B2 (en) * 2015-06-11 2018-02-27 Bao Tran Systems and methods for on-demand transportation
US10657486B1 (en) 2015-07-29 2020-05-19 DoorDash, Inc. Containers for crowdsourced delivery
US10157436B2 (en) 2015-10-09 2018-12-18 Gt Gettaxi Limited System for navigating vehicles associated with a delivery service
US10794713B2 (en) 2015-12-31 2020-10-06 Lyft, Inc. System for navigating drivers to passengers based on start times of events
US10417605B1 (en) 2016-02-29 2019-09-17 Square, Inc. Courier notifications regarding missing items
US11182709B2 (en) * 2016-08-16 2021-11-23 Teleport Mobility, Inc. Interactive real time system and real time method of use thereof in conveyance industry segments
US20220108260A1 (en) * 2016-08-16 2022-04-07 Teleport Mobility, Inc. Interactive network and method for securing conveyance services
US11176500B2 (en) * 2016-08-16 2021-11-16 Teleport Mobility, Inc. Interactive real time system and real time method of use thereof in conveyance industry segments
US11087252B2 (en) * 2016-08-16 2021-08-10 Teleport Mobility, Inc. Interactive real time system and real time method of use thereof in conveyance industry segments
CN106534132B (zh) * 2016-11-17 2021-05-18 京东方科技集团股份有限公司 基于打车订单的视频处理方法、装置、服务器和系统
US20180137594A1 (en) * 2016-11-17 2018-05-17 Gt Gettaxi Limited System and method for reserving drivers for a transportation service and navigating drivers to service transportation requests
US11042551B2 (en) * 2016-12-02 2021-06-22 Fair Isaac Corporation Fast automatic explanation of scored observations
CN110447276A (zh) * 2017-05-18 2019-11-12 北京嘀嘀无限科技发展有限公司 一种用于定位目标接入点的系统和方法
US10860968B1 (en) 2017-06-29 2020-12-08 DoorDash, Inc. System management based on device information
CN107352497B (zh) * 2017-07-21 2018-10-12 北京图森未来科技有限公司 一种车辆的自动加油方法、装置和系统
US11436554B2 (en) * 2017-11-02 2022-09-06 Uber Technologies, Inc. Network computer system to implement predictive time-based determinations for fulfilling delivery orders
US10706487B1 (en) 2017-11-11 2020-07-07 Lyft, Inc. Dynamically generating and updating multipliers for a transportation matching system using machine learning
US10559211B2 (en) 2017-11-27 2020-02-11 Uber Technologies, Inc. Real-time service provider progress monitoring
CN108197825B (zh) * 2018-01-29 2022-04-26 北京星选科技有限公司 系统调度方法及装置
CN108256977A (zh) * 2018-01-30 2018-07-06 金瓜子科技发展（北京）有限公司 车源推荐方法及装置
US11308536B1 (en) 2018-03-19 2022-04-19 DoorDash, Inc. Managing item options for distribution efficiency
US10719792B2 (en) * 2018-03-26 2020-07-21 GM Global Technology Operations LLC System and method to distribute and execute rideshare tasks
CN110998568B (zh) * 2018-03-28 2023-03-28 北京嘀嘀无限科技发展有限公司 寻觅乘客的可搭载车辆的导航确定系统和方法
US11410121B2 (en) * 2018-04-27 2022-08-09 EMC IP Holding Company LLC Proactively predicting large orders and providing fulfillment support related thereto
CN108711085A (zh) * 2018-05-09 2018-10-26 平安普惠企业管理有限公司 一种交易请求的响应方法及其设备
CN110619551A (zh) * 2018-06-19 2019-12-27 北京嘀嘀无限科技发展有限公司 订单分配方法、订单分配系统、计算机设备及存储介质
US10820726B2 (en) * 2018-06-20 2020-11-03 Jasna Ostojich Food stand system
CN110785749B (zh) * 2018-06-25 2020-08-21 北京嘀嘀无限科技发展有限公司 用于生成宽表的系统和方法
CN109064091B (zh) * 2018-07-13 2021-09-17 天津五八到家科技有限公司 资源确定、资源处理方法及装置
US10552773B1 (en) 2018-09-07 2020-02-04 Lyft, Inc. Efficiency of a transportation matching system using geocoded provider models
CN111144676A (zh) * 2018-11-05 2020-05-12 北京嘀嘀无限科技发展有限公司 用车订单分配方法、装置、服务器及计算机可读存储介质
CN110992072A (zh) * 2018-11-30 2020-04-10 北京嘀嘀无限科技发展有限公司 异常订单预测方法和系统
CN111260384B (zh) * 2018-11-30 2023-09-15 北京嘀嘀无限科技发展有限公司 服务订单处理方法、装置、电子设备及存储介质
CN111260427B (zh) * 2018-11-30 2023-07-18 北京嘀嘀无限科技发展有限公司 服务订单处理方法、装置、电子设备及存储介质
CN111325429A (zh) * 2018-12-14 2020-06-23 中移信息技术有限公司 一种订单推送方法、装置、介质和设备
CN109767289A (zh) * 2018-12-15 2019-05-17 深圳壹账通智能科技有限公司 订单智能分配方法、装置、计算机设备及存储介质
CN109636551B (zh) * 2019-01-31 2022-02-01 上海易点时空网络有限公司 业务订单生成方法及装置
CN111798283A (zh) * 2019-04-09 2020-10-20 北京嘀嘀无限科技发展有限公司 订单派发方法、装置、电子设备及计算机可读存储介质
US10657824B1 (en) 2019-05-16 2020-05-19 Allstate Insurance Company Roadside assistance system
CN110136431B (zh) * 2019-05-24 2021-11-12 深圳市元征科技股份有限公司 一种车辆共享方法及装置
US20200393256A1 (en) * 2019-06-14 2020-12-17 Uber Technologies, Inc. Managing movement of vehicles through directional route corridors
US11482111B2 (en) 2019-07-17 2022-10-25 Uber Technologies, Inc. Computing timing intervals for vehicles through directional route corridors
CN110473108B (zh) * 2019-09-16 2023-09-01 北京京东振世信息技术有限公司 基于区块链的合约生成方法和装置
CN111292034B (zh) * 2020-01-17 2023-09-05 深圳市人工智能与机器人研究院 订单履行方案的确定方法、装置、电子装置及存储介质
US11796330B2 (en) * 2020-02-11 2023-10-24 Delphi Technologies Ip Limited System and method for providing value recommendations to ride-hailing drivers
SG11202113323UA (en) * 2020-02-18 2021-12-30 Grabtaxi Holdings Pte Ltd System and method for partitioning geographical areas into logistical areas for dynamic pricing
CN111651251A (zh) * 2020-05-20 2020-09-11 拉扎斯网络科技（上海）有限公司 压力调控方法、装置、可读存储介质和电子设备
CN111582408B (zh) * 2020-06-19 2023-12-29 拉扎斯网络科技（上海）有限公司 数据处理方法、数据处理装置、存储介质和电子设备
CN111882109A (zh) * 2020-06-22 2020-11-03 北京嘀嘀无限科技发展有限公司 一种订单分配方法和系统
CN112061664B (zh) * 2020-08-31 2022-02-15 中国烟草总公司天津市公司物流中心 一种柔性卷烟分拣方法及系统
CN112651794A (zh) * 2020-09-30 2021-04-13 全景智联(武汉)科技有限公司 订单号管理方法、系统及存储介质
US11379907B1 (en) * 2020-12-11 2022-07-05 Coupang Corp. Systems and computerized methods for item correlation and prioritization
CN112507196A (zh) * 2020-12-18 2021-03-16 北京百度网讯科技有限公司 融合排序模型的训练方法、搜索排序方法、装置和设备
US20220198599A1 (en) * 2020-12-23 2022-06-23 Beijing Didi Infinity Technology And Development Co., Ltd. Method and system for preferential dispatch to orders with high risk
US11887017B2 (en) 2021-03-26 2024-01-30 Dell Products L.P. Automatically predicting transaction likelihood information and transaction-related temporal information using machine learning techniques
CN113205391B (zh) * 2021-05-24 2022-08-23 长沙市到家悠享家政服务有限公司 基于历史订单匹配度的派单方法、电子设备和计算机可读介质
US11790304B1 (en) * 2021-06-28 2023-10-17 Amazon Technologies, Inc. Models for early detection of delivery defects—expired delivery blocks
US11823118B1 (en) 2021-06-28 2023-11-21 Amazon Technologies, Inc. Models for early detection of delivery defects—unassigned delivery blocks
CN113255288B (zh) * 2021-07-15 2021-09-24 成都威频通讯技术有限公司 一种基于快速密度峰值聚类的电子元器件聚类方法
CN113723893A (zh) * 2021-09-15 2021-11-30 北京沃东天骏信息技术有限公司 用于处理订单的方法和装置
CN114037155A (zh) * 2021-11-09 2022-02-11 首约科技(北京)有限公司 一种订单统计的优化方法
CN114548682A (zh) * 2022-01-19 2022-05-27 浙江吉利控股集团有限公司 订单派发方法、订单派发装置、及计算机可读存储介质
CN114705809B (zh) * 2022-02-21 2024-10-01 深圳绿米联创科技有限公司 检测模块控制方法、装置及电子设备
US11791038B1 (en) * 2022-11-02 2023-10-17 Zengine Limited Machine learning system for asymmetrical matching of care givers and care receivers
CN116151401B (zh) * 2023-03-01 2024-06-07 南京领行科技股份有限公司 一种平台派单方法、装置、设备及存储介质
CN116402516A (zh) * 2023-04-28 2023-07-07 广州市神州联保科技有限公司 用于售后联保平台的服务商监控方法及系统

Citations (10)

* 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
CN102324181A (zh) * 2011-08-08 2012-01-18 上海市城市建设设计研究院 自助式出租车即时预约系统及自助式出租车即时预约方法
CN103218769A (zh) * 2013-03-19 2013-07-24 王兴健 出租车订单分配方法
CN104599168A (zh) * 2015-02-02 2015-05-06 北京嘀嘀无限科技发展有限公司 叫车订单的分配方法和装置
CN104598978A (zh) * 2015-02-06 2015-05-06 北京嘀嘀无限科技发展有限公司 用于处理预约订单的方法及设备
CN104639646A (zh) * 2015-02-12 2015-05-20 北京嘀嘀无限科技发展有限公司 用于处理用户请求的方法和设备
CN104715285A (zh) * 2015-03-31 2015-06-17 北京嘀嘀无限科技发展有限公司 处理订单的方法和设备
CN104867016A (zh) * 2015-04-28 2015-08-26 北京嘀嘀无限科技发展有限公司 订单抢单特性的自动更新方法及系统
CN105005816A (zh) * 2015-04-13 2015-10-28 北京嘀嘀无限科技发展有限公司 订单处理方法及装置
CN105160021A (zh) * 2015-09-29 2015-12-16 滴滴（中国）科技有限公司 基于目的地偏好的订单分配方法及装置

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7249061B1 (en) 1997-03-14 2007-07-24 Kabushiki Kaisha Toshiba Method of electronic commerce including receiving an acceptance signal indicating a change in a transaction available period based on a time adjustment day
US8055527B1 (en) * 2001-06-08 2011-11-08 Servigistics, Inc. Policy based automation for a supply chain
US20030128135A1 (en) * 2002-01-10 2003-07-10 Poltorak Alexander I. Apparatus and method for providing for the remote control of traffic control devices along a travel route
US8630996B2 (en) * 2005-05-05 2014-01-14 At&T Intellectual Property I, L.P. Identifying duplicate entries in a historical database
US20080059273A1 (en) 2006-02-21 2008-03-06 Dynamic Intelligence Inc. Strategic planning
KR101008579B1 (ko) 2008-06-23 2011-01-17 삼성에스디에스 주식회사 장비 데이터를 실시간으로 처리하는 역단위전산기 및 그방법
US20110225269A1 (en) * 2008-11-15 2011-09-15 Shong Clement Yap Wee System For Efficient Allocating And Monitoring Of Public Transport
US10002198B2 (en) * 2009-10-28 2018-06-19 Verizon Patent And Licensing Inc. Mobile taxi dispatch system
CA2782611C (en) 2009-12-04 2018-07-10 Uber Technologies, Inc. System and method for arranging transport amongst parties through use of mobile devices
CN101834903A (zh) 2010-04-22 2010-09-15 惠州Tcl移动通信有限公司 一种出租车调度系统、移动终端以及信息收发设备
CN102456203B (zh) 2010-10-22 2015-10-14 阿里巴巴集团控股有限公司 确定候选产品链表的方法及相关装置
US8773535B2 (en) * 2010-12-08 2014-07-08 GM Global Technology Operations LLC Adaptation for clear path detection using reliable local model updating
US9443028B2 (en) * 2010-12-11 2016-09-13 Microsoft Technology Licensing, Llc Relevance estimation using a search satisfaction metric
WO2012088623A1 (en) * 2010-12-27 2012-07-05 Yahoo! Inc. Selecting advertisements for placement on related web pages
US8661403B2 (en) 2011-06-30 2014-02-25 Truecar, Inc. System, method and computer program product for predicting item preference using revenue-weighted collaborative filter
CN102956009B (zh) * 2011-08-16 2017-03-01 阿里巴巴集团控股有限公司 一种基于用户行为的电子商务信息推荐方法与装置
US8688378B2 (en) * 2011-10-17 2014-04-01 GM Global Technology Operations LLC Ride-share service
US20130159028A1 (en) 2011-12-19 2013-06-20 Sap Ag Raising User Satisfaction in an Automated Ride Sharing System
CN102737501B (zh) 2012-06-12 2015-02-04 中国联合网络通信集团有限公司 出租车载客调度方法和系统以及调度服务器
CN102867410A (zh) 2012-09-21 2013-01-09 李明康 通过位置服务和云计算实现出租车司乘智能交互服务方法
TWI476727B (zh) 2012-10-31 2015-03-11 Chunghwa Telecom Co Ltd Automatic dispatching method and system of taxi using community network and geography instant exchange technology
CN103903147A (zh) 2012-12-27 2014-07-02 腾讯科技（上海）有限公司 一种监控网络供应商响应速度的方法及系统
CN103177572B (zh) 2013-02-22 2016-03-09 王兴健 出租车智能调度
JP2014194710A (ja) 2013-03-29 2014-10-09 Hitachi Solutions Ltd 利用者属性に依存した情報配信システム
US9996670B2 (en) * 2013-05-14 2018-06-12 Zynx Health Incorporated Clinical content analytics engine
CN103744966B (zh) 2014-01-07 2018-06-22 Tcl集团股份有限公司 一种物品推荐方法、装置
CA2871824A1 (en) * 2014-03-25 2015-09-25 Gustave Roy Methods and systems relating to immediate service delivery
AU2015251350A1 (en) 2014-04-24 2016-11-10 Beijing Didi Infinity Technology And Development Co., Ltd. System and method for managing supply of service
US10169715B2 (en) * 2014-06-30 2019-01-01 Amazon Technologies, Inc. Feature processing tradeoff management
US10559038B1 (en) * 2014-07-30 2020-02-11 Allstate Insurance Company Mobile service provider and insurance systems
WO2016019857A1 (zh) 2014-08-04 2016-02-11 北京嘀嘀无限科技发展有限公司 服务派发系统及方法

Patent Citations (10)

* 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
CN102324181A (zh) * 2011-08-08 2012-01-18 上海市城市建设设计研究院 自助式出租车即时预约系统及自助式出租车即时预约方法
CN103218769A (zh) * 2013-03-19 2013-07-24 王兴健 出租车订单分配方法
CN104599168A (zh) * 2015-02-02 2015-05-06 北京嘀嘀无限科技发展有限公司 叫车订单的分配方法和装置
CN104598978A (zh) * 2015-02-06 2015-05-06 北京嘀嘀无限科技发展有限公司 用于处理预约订单的方法及设备
CN104639646A (zh) * 2015-02-12 2015-05-20 北京嘀嘀无限科技发展有限公司 用于处理用户请求的方法和设备
CN104715285A (zh) * 2015-03-31 2015-06-17 北京嘀嘀无限科技发展有限公司 处理订单的方法和设备
CN105005816A (zh) * 2015-04-13 2015-10-28 北京嘀嘀无限科技发展有限公司 订单处理方法及装置
CN104867016A (zh) * 2015-04-28 2015-08-26 北京嘀嘀无限科技发展有限公司 订单抢单特性的自动更新方法及系统
CN105160021A (zh) * 2015-09-29 2015-12-16 滴滴（中国）科技有限公司 基于目的地偏好的订单分配方法及装置

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10458806B2 (en) 2015-01-27 2019-10-29 Beijing Didi Infinity Technology And Development Co., Ltd. Methods and systems for providing information for an on-demand service
US11156470B2 (en) 2015-01-27 2021-10-26 Beijing Didi Infinity Technology And Development Co., Ltd. Methods and systems for providing information for an on-demand service
CN108734950A (zh) * 2017-04-18 2018-11-02 北京嘀嘀无限科技发展有限公司 拼车方法及装置、网络约车方法及装置
CN108734950B (zh) * 2017-04-18 2021-03-16 北京嘀嘀无限科技发展有限公司 拼车方法及装置、网络约车方法及装置
CN111052158A (zh) * 2017-07-20 2020-04-21 北京嘀嘀无限科技发展有限公司 用于分配服务请求的系统和方法
CN111052158B (zh) * 2017-07-20 2023-09-22 北京嘀嘀无限科技发展有限公司 用于分配服务请求的系统和方法
EP3783506B1 (en) * 2018-06-21 2024-04-17 Shenzhen Institutes of Advanced Technology Parking lot data repair method and apparatus, device and storage medium
US20210172748A1 (en) * 2018-07-31 2021-06-10 Honda Motor Co., Ltd. Visit management apparatus, visit management method and visit management system
WO2020114481A1 (zh) * 2018-12-06 2020-06-11 北京嘀嘀无限科技发展有限公司 一种信息处理方法、系统、装置及计算机可读存储介质
TWI764767B (zh) * 2019-02-13 2022-05-11 華南商業銀行股份有限公司 規劃客製化定存轉帳金額的自動儲蓄系統
TWI760254B (zh) * 2020-02-13 2022-04-01 華南商業銀行股份有限公司 使用類神經網路的自動儲蓄方法

Also Published As

Publication number Publication date
US11315170B2 (en) 2022-04-26
US10657581B2 (en) 2020-05-19
HK1246941A1 (zh) 2018-09-14
GB201712642D0 (en) 2017-09-20
PH12017501388A1 (en) 2018-01-08
MY181464A (en) 2020-12-22
US20200265502A1 (en) 2020-08-20
GB2550523A (en) 2017-11-22
US20180025407A1 (en) 2018-01-25
SG11201706269QA (en) 2017-09-28

Similar Documents

Publication Publication Date Title
US11315170B2 (en) Methods and systems for order processing
US20210232984A1 (en) Order allocation system and method
JP6918087B2 (ja) オン・デマンドサービスの情報を提供する方法及びシステム
WO2016127918A1 (zh) 一种运力调度方法及系统
JP6559792B2 (ja) オーダーペアリングのシステム及び方法
US20170364933A1 (en) User maintenance system and method
US20200300650A1 (en) Systems and methods for determining an estimated time of arrival for online to offline services
CN111582559B (zh) 一种到达时间的预估方法及装置
JP7123186B2 (ja) オンライン・オンデマンドサービス・プラットフォームからのデータを処理するためのシステムおよび方法
Bolaños-Martinez et al. Predicting overnights in smart villages: the importance of context information
CN118824043A (zh) 智能停车引导方法、系统及存储介质
Riedel Evaluation of Geospatial Features for Forecasting Parking Occupancy Using Social Media Data
BR112017018866B1 (pt) Sistemas e métodos para emparelhamento de ordens
BR112017016064B1 (pt) Métodos e sistemas para fornecer informação para um serviço por demanda

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: 16746113

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15547528

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 11201706269Q

Country of ref document: SG

Ref document number: 12017501388

Country of ref document: PH

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 201712642

Country of ref document: GB

Kind code of ref document: A

Free format text: PCT FILING DATE = 20160129

122 Ep: pct application non-entry in european phase

Ref document number: 16746113

Country of ref document: EP

Kind code of ref document: A1