WO2016127918A1 - 一种运力调度方法及系统 - Google Patents

一种运力调度方法及系统 Download PDF

Info

Publication number
WO2016127918A1
WO2016127918A1 PCT/CN2016/073559 CN2016073559W WO2016127918A1 WO 2016127918 A1 WO2016127918 A1 WO 2016127918A1 CN 2016073559 W CN2016073559 W CN 2016073559W WO 2016127918 A1 WO2016127918 A1 WO 2016127918A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
order
scheduling
policy
user
Prior art date
Application number
PCT/CN2016/073559
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 CN201510079087.0A external-priority patent/CN104599088A/zh
Priority claimed from CN201510088837.0A external-priority patent/CN104616119A/zh
Priority claimed from CN201510097280.7A external-priority patent/CN104657933A/zh
Priority claimed from CN201510303334.0A external-priority patent/CN104867065B/zh
Priority claimed from CN201510428931.6A external-priority patent/CN105096588B/zh
Priority claimed from CN201510516164.4A external-priority patent/CN105139089A/zh
Priority claimed from CN201510737743.1A external-priority patent/CN106657199A/zh
Priority claimed from CN201510990222.7A external-priority patent/CN105575105B/zh
Priority claimed from CN201610046769.6A external-priority patent/CN105608886A/zh
Priority to SG11201706602RA priority Critical patent/SG11201706602RA/en
Priority to US15/550,169 priority patent/US20180032928A1/en
Application filed by 北京嘀嘀无限科技发展有限公司 filed Critical 北京嘀嘀无限科技发展有限公司
Priority to KR1020197005368A priority patent/KR20190020852A/ko
Priority to EP16748719.8A priority patent/EP3258430A4/en
Priority to KR1020177025673A priority patent/KR20180011053A/ko
Publication of WO2016127918A1 publication Critical patent/WO2016127918A1/zh
Priority to PH12017501450A priority patent/PH12017501450A1/en
Priority to HK18106920.2A priority patent/HK1247422A1/zh

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
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • 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
    • G06Q10/00—Administration; Management
    • G06Q10/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"
    • 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/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • 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/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083—Shipping
    • G06Q50/40—

Definitions

  • the present application relates to a capacity scheduling method and system, and more particularly to a capacity scheduling method and system for applying mobile internet technology and data processing technology.
  • a capacity dispatch system can include: a computer readable storage medium and a processor.
  • the computer readable storage can store executable modules.
  • the processor can execute the executable module of the computer readable storage medium storage.
  • the executable module may include: an order information extraction module; a user information extraction module; an environment information extraction module; a calculation module; and a scheduling module.
  • the order information extraction module, the user information extraction module, and the environment information extraction module may acquire scheduling reference information.
  • the calculation module may determine a scheduling policy according to the scheduling reference information.
  • the scheduling module can send the scheduling policy.
  • the executable module may also include one or more other modules, such as an order distribution module or the like.
  • a capacity scheduling method may include: acquiring scheduling reference information; determining a scheduling policy according to the scheduling reference information; and transmitting the scheduling policy to an order initiator or an order receiver.
  • a method of using a location information based service may include: the terminal transmitting the location information to the location information based scheduling system; the terminal receiving the location information based scheduling policy sent by the system.
  • the terminal may include: a passenger terminal, a driver terminal.
  • the display form may include voice, text, graphics, video.
  • the graphic display form may be displaying different supply and demand density, order density, order quantity, and number of users based on the map of the terminal.
  • a tangible, non-transitory computer readable medium on which information can be stored.
  • the computer can perform the capacity scheduling method.
  • the capacity scheduling method may include: acquiring scheduling reference information; determining a scheduling policy according to the scheduling reference information; and transmitting the scheduling policy to an order initiator or an order receiver.
  • the scheduling reference information may include: historical order information, real-time order information, historical weather information, real-time weather information, future weather information, traffic information, historical service provider information, or real-time service provider. Information or vehicle information collected by the onboard diagnostic system.
  • the determining process of the scheduling policy may include: determining an actual scheduling amount according to the scheduling reference information; and determining a scheduling policy according to the actual scheduling amount.
  • the determining the actual scheduling amount according to the scheduling reference information may include: determining a regional distribution of the plurality of service providers; calculating a potential scheduling amount for each region based on the regional distribution; The potential dispatch amount of the region calculates the potential volume for each region; calculates the maximum potential deal increment based on the potential volume for each region; and determines the actual amount of dispatch for each region based on the maximum potential deal increment sum.
  • the determining the actual scheduling amount according to the scheduling reference information may include: determining a geographic information based area partitioning; calculating a current demand quantity of the service provider related to the area dividing; calculating and Determining the expected demand quantity of the service provider related to the zoning; determining the actual scheduling quantity based on the current demand quantity and the expected demand quantity.
  • the scheduling policy may include: a supply and demand density push policy, a hotspot feature push policy, a statistical feature push policy, an order push policy, an order adjustment policy, or a prompt information push policy.
  • the determining process of the supply and demand density push strategy may include: acquiring a quantity of orders at a given time and within a given area; calculating potentials at the given time and within the given area The number of service providers receiving the order; determining the supply and demand density of the given area based on the predicted order quantity and the number of service providers potentially receiving the order.
  • the determining process of the statistical feature pushing policy may include: extracting location information of the service provider according to the acquired scheduling reference information; and obtaining location information of the service provider according to the obtained Extracting a plurality of order information near the location of the service provider; determining a mark location corresponding to each of the plurality of orders; grouping the plurality of orders based on the mark location and order time information; Calculate the statistical characteristics of each set of orders.
  • the capacity scheduling method and the capacity scheduling system may further include: selecting a set of real-time orders corresponding to the marked location for a specific landmark location.
  • the order push policy determining process may include: Determining a first region in which the ratio of the order demand to the service provider service capability is less than the first threshold and a second region in which the ratio of the order demand to the service provider service capability is greater than a second threshold; in the first region, for each An order, selecting a user presented to it; in the second area, for each user, selecting an order presented to it.
  • the order adjustment policy determining process may include: extracting weather information of the target area in the first preset time period according to the obtained reference information; and extracting, according to the obtained reference information Determining the order information of the second preset time period in the target area, and the service provider information at the current time; determining, according to the weather information, the order information in the second preset time period, and the service provider information Order adjustment strategy.
  • FIG. 1 is a schematic diagram of a network environment, shown in accordance with some embodiments of the present application.
  • FIG. 2 is a schematic diagram of a system for capacity scheduling, in accordance with some embodiments of the present application.
  • FIG. 3 is an exemplary flow chart showing capacity scheduling in accordance with some embodiments of the present application.
  • 4A and 4B are exemplary flowcharts of capacity scheduling at the user end, according to some embodiments of the present application.
  • FIG. 5 is a schematic illustration of a processing module shown in accordance with some embodiments of the present application.
  • FIG. 6 is a schematic diagram of a processing module shown in accordance with some embodiments of the present application.
  • 7-A, 7-B, and 7-C are schematic diagrams of area divisions shown in accordance with some embodiments of the present application.
  • FIG. 8 is an exemplary flowchart of a capacity scheduling based on scheduling amount predictions, in accordance with some embodiments of the present application.
  • FIG. 9 is a schematic diagram of a processing module shown in accordance with some embodiments of the present application.
  • FIG. 10 is a capacity based on environmental information, according to some embodiments of the present application.
  • 11 is an exemplary flowchart of determining whether a scheduling policy needs to be initiated, according to some embodiments of the present application.
  • FIG. 12 is a schematic diagram of a processing module shown in accordance with some embodiments of the present application.
  • FIG. 13 is an exemplary flowchart of capacity scheduling based on region partitioning, according to some embodiments of the present application.
  • FIG. 14 is a schematic diagram of a processing module shown in accordance with some embodiments of the present application.
  • FIG. 15 is an exemplary flowchart of a capacity scheduling method based on volume information, according to some embodiments of the present application.
  • 16 is a schematic diagram of a processing module shown in accordance with some embodiments of the present application.
  • FIG. 17 is a schematic diagram of a network environment of a capacity scheduling system according to some embodiments of the present application.
  • FIG. 18 is an exemplary flowchart of a capacity scheduling method based on an onboard diagnostic system, according to some embodiments of the present application.
  • FIG. 19 is an exemplary flowchart of a matching process in a capacity scheduling method based on an onboard diagnostic system, according to some embodiments of the present application.
  • FIG. 20 is a schematic diagram of a processing module shown in accordance with some embodiments of the present application.
  • 21 is an exemplary flowchart of a statistical information based capacity scheduling method, according to some embodiments of the present application.
  • FIG. 22 is an exemplary flowchart of a statistical information based capacity scheduling method, according to some embodiments of the present application.
  • FIG. 23 is a schematic diagram of a processing module shown in accordance with some embodiments of the present application.
  • 24 is an exemplary flowchart of a capacity scheduling method based on supply and demand density information, according to some embodiments of the present application.
  • 25 is a schematic diagram of a processing module shown in accordance with some embodiments of the present application.
  • 26 is an exemplary flowchart of a capacity scheduling method based on order interaction information and distribution information, according to some embodiments of the present application.
  • FIG. 27 is a schematic illustration of a processing module shown in accordance with some embodiments of the present application.
  • 29 is a diagram of a structure of a mobile device that can be used to implement a particular system disclosed in this application, in accordance with some embodiments of the present application;
  • Figure 30 is an architecture of a computer device that can be used to implement a particular system disclosed in this application.
  • Embodiments of the present application may be applied to different transportation systems, which may include, but are not limited to, one or a combination of terrestrial, marine, aerospace, aerospace, and the like.
  • transportation systems may include, but are not limited to, one or a combination of terrestrial, marine, aerospace, aerospace, and the like.
  • taxis, cars, rides, buses, trains, trains, high-speed rail, subways, boats Ships, airplanes, spaceships, hot air balloons, unmanned vehicles, receiving/delivery couriers, etc. have applied management and/or distribution of transportation systems.
  • Application scenarios of different embodiments of the present application may 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 requester”, “service requester”, “consumer”, “consumer”, “user demander”, etc. described in this application are interchangeable. , refers to the party that needs or subscribes to the service, can be an individual, or a tool. Similarly, the “driver”, “provider”, “supplier”, “service provider”, “service provider”, “service provider”, “service party”, etc. described herein are also interchangeable, Refers to individuals, tools, or other entities that provide services or assist in providing services. Additionally, the "user” described herein may be the party that needs or subscribes to the service, or the party that provides the service or assists in providing the service.
  • the "order" described in this application may be the originator of the order by the party who needs or subscribes to the service, or the party that provides the service or assists in providing the service as the originator of the order.
  • the order may be the originator of the order by the party who needs or subscribes to the service, or the party that provides the service or assists in providing the service as the originator of the order.
  • An “order” may be an order that is approved by both the consumer and the service provider, or an order that is only approved by the service party or the consumer.
  • An “order” can be a paid order, or a free order.
  • the network environment 100 can include an on-demand service system 105, one or more passenger devices 120, one or more databases 130, one or more driver devices 140, one or more networks 150, one or more information Source 160.
  • the on-demand service system 105 can include a scheduling engine 110.
  • the scheduling engine may also be referred to as a scheduling system.
  • a system may refer to an on-demand service system, or a scheduling engine or a scheduling system.
  • the scheduling engine 110 is a system that can analyze the collected information to generate an analysis result.
  • the scheduling engine 110 can be a service Server, or a group of servers, each of which is connected by a wired or wireless network.
  • a server group can be centralized, such as a data center.
  • a server group can be distributed, such as a distributed system.
  • the scheduling engine 110 can be local or remote. In some embodiments, the scheduling engine 110 can access information accessing the passenger device 120 and/or the driver device 140, information in the information source 160, information in the database 130, or directly accessing the information source 160 via the network 150. Information, information in database 130.
  • Passengers and drivers may be collectively referred to as users, which may be individuals, tools or other entities directly associated with the service order, such as requesters and service providers of service orders. 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 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 be referred to herein simply as a driver.
  • the passenger device 120 may include, but is not limited to, one of the desktop computer 120-1, the notebook computer 120-2, the built-in device 120-3 of the motor vehicle, the mobile device 120-4, or the like. Several combinations. Further, the built-in device 120-3 of the motor vehicle may be a carputer or the like. In some embodiments, these users may also be some other smart terminals, which may include, but are not limited to, smart home devices, wearable devices, smart mobile devices, or other smart devices.
  • a smart home device it may include, but is not limited to, a combination of one or more of an intelligent lighting device, a smart electrical control device, an intelligent monitoring device, a smart television, a smart camera, a smart phone, a walkie-talkie, etc.;
  • the wearable device may include, but is not limited to, a combination of one or more of a smart bracelet, smart footwear, smart glasses, smart helmet, smart headband, smart clothing, smart backpack, smart accessories, etc.; for smart mobile
  • the device may include, but is not limited to, a combination of one or more of a smart watch, a notebook, a tablet, a built-in device of a vehicle (a car computer or a car TV, etc.), a game device, a GPS device, a POS machine, and the like.
  • Driver device 140 may 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 premises equipment 120 and/or the driver equipment 140 and various data utilized, generated and output in the operation of the dispatch 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 may include, but is not limited to, a decimal counter, a select 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 zero.
  • DRAM dynamic random access memory
  • SRAM static random access memory
  • T-RAM thyristor random access memory
  • Z-RAM capacitive random access memory
  • Read-only memory may include, 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 Variable 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 can be a magneto-optical side A device that stores information, such as a magneto-optical disk.
  • 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.
  • 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.
  • Database 130 may be interconnected or in communication with network 150, or may be interconnected or communicated directly with on-demand service system 105 or a portion thereof (e.g., scheduling engine 110), or a combination of both.
  • database 130 can be placed in the background of on-demand service system 105.
  • 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 passenger device 120 and/or the driver device 140 can access the information in the database 130 via the network 150.
  • 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 premises equipment 120 and/or the driver equipment 140 and/or the information source 160 and various data generated in the operation of the dispatch 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 to the system.
  • the connection of the database 130 to 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 can be wired or wireless.
  • Network 150 can provide a conduit for information exchange.
  • the on-demand service system 105 or a portion thereof (e.g., order push engine 110), and/or the manner in which the client 120/140 is connected to the database 130 can be different.
  • the access rights of the parties to the database 130 can be limited.
  • the on-demand service system 105, or a portion thereof e.g., the scheduling engine 110
  • the end device 140 can read part of the public 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 140 may view partial information about the passenger 120 in the database 130 upon receiving a service order from a passenger 120; however, the driver 140 may not autonomously modify the database 130 regarding the The information of the passenger 120, which can only be reported to the on-demand service system 105, is determined by the on-demand service system 105 whether to modify the information in the database 130 regarding the passenger 120.
  • a passenger 120 upon receiving a request from a driver 140 to provide a service, may view some information about the driver 140 in the database 130 (such as user rating information, driving experience, etc.); but the passenger 120 does not.
  • the information about the driver 140 in the database 130 can be modified autonomously, and 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 140 in the database 130.
  • Network 150 can be a single network, or a combination of multiple different networks.
  • network 150 can 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 multiple network access points, such as wired or wireless access points, such as base station 150-1, base station 150-2, Internet switching points, etc., through which any data source may be accessed.
  • Network 150 transmits information over network 150.
  • Information source 160 is a source of other information for the system.
  • the information source 160 can provide information related to the service to the system, such as weather conditions, traffic information, legal and regulatory information, news events, living information, living guide information, and the like.
  • the information source 160 may be in the form of a single central server, or in the form of multiple servers connected by a network, or in the form of a large number of personal devices.
  • 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.
  • Information source 160 may be interconnected or in communication with network 150, or may be interconnected or communicated directly with on-demand service system 105 or a portion thereof (e.g., scheduling engine 110), or a combination of both.
  • the passenger device 120 and/or the driver device 140 can access information in the information source 160 over the network 150.
  • the connection or communication between the information source 160 and other modules of the system can 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, News network, etc.
  • 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, a radar speedometer on a road, a temperature and humidity sensor, an onboard diagnostic system, and the like.
  • the information source 160 may be a source of news, information, road real-time information, etc., such as a network information source.
  • the network information source may include, but is not limited to, one or more of a Usenet-based Internet newsgroup, a server on the Internet, a weather information server, a road condition information server, and the like.
  • the information source 160 may be a system that stores a plurality of catering service providers in a certain area, a municipal service system, a traffic condition system, a weather broadcast system, a news network, and rules for storing legal and regulatory information about the local area.
  • 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 portions of a location-based service 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.
  • an intangible product one or a combination of a service product, a financial product, an intellectual product, an internet product, and the like may be included, but not limited to.
  • For Internet products it can be any product that meets people's needs for information, entertainment, communication or business. There are many classification methods for Internet products.
  • the classification of the bearer platform may include, but is not limited to, a combination of one or more of a personal host product, a Web product, a mobile Internet product, a commercial host platform product, an embedded product, and the like.
  • the mobile internet product therein may be software, a program or a system for use in a mobile terminal.
  • the mobile terminal therein may include, 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, a smart wearable device, and the like.
  • PDA personal digital assistant
  • various types of social, shopping, travel, entertainment, learning, investment, and other software or applications used on a computer or mobile phone for example, various types of social, shopping, travel, entertainment, learning, investment, and other software or applications used on a computer or mobile phone.
  • the travel software or application can be software or applications such as travel software, vehicle reservations, maps, and the like.
  • the traffic reservation software or application means that it can be used to reserve horses, carriages, Rickshaws (eg, two-wheeled bicycles, tricycles, etc.), cars (eg, taxis, buses, etc.), trains, subways, boats, aircraft (eg, airplanes, helicopters, space shuttles, rockets, hot air balloons, etc.) One or a combination of several.
  • the database 130 may be a cloud computing platform with data storage functions, which may include, but is not limited to, a public cloud, a private cloud, a community cloud, a hybrid cloud, and the like. Variations such as these are within the scope of the present application.
  • FIG. 2 shown in FIG. 2 is a schematic diagram of a scheduling engine 110.
  • the scheduling engine 110 can 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 scheduling engine 110 can be centralized or distributed. One or more of the modules of the scheduling engine 110 may be local or remote.
  • the scheduling 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 dispatch engine 110 can receive information from the passenger end device 120 via the passenger interface 230 or send the processed information to the passenger end device 120 via the passenger interface 230.
  • the scheduling engine 110 can receive information from the driver device 140 via the driver interface 240 or send the processed information to the driver device 140 via the driver interface 240.
  • the scheduling engine 110 can obtain information from the database 130 and/or the information source 160, or send the processed information to the passenger device 120 via the passenger interface 230, or send the processed information to the driver device via the driver interface 240. 140.
  • the passenger interface 230 and the driver interface 240 can receive respective transmitted information from the passenger end device 120 and the driver device 140, respectively.
  • Passenger interface 230 and driver interface 240 can read information from database 130 and/or information source 160, respectively.
  • the information herein may include, but is not limited to, a combination of one or more of request information of the service, reception information of the service, user's habit/favorite information, current 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).
  • 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, or stored in the storage module 220, or calculated and processed by the processing module 210.
  • the passenger interface 210 and the driver interface 230 can 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, historical information of the order, real-time information of the order, direct information of the user, processing information of the user, historical information of the user, user's Real-time information, environmental information, etc.
  • 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 be sent to the passenger end device 120 and/or the driver's end device 140 or not.
  • the output information that is not transmitted may be stored in the database 130, or stored in the storage module 220, or stored in the processing module 210.
  • processing module 210 can process related information.
  • the processing module can obtain information from the passenger interface 230, the driver interface 240, the database 130, the information source 160, the storage module 220, and the like.
  • the processing module 210 can send the processed information to the passenger interface 230 and/or the driver interface 240, and can save the processed information to the database 130 or 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 cloud computing platform may include, but is not limited to, a storage-based cloud platform that stores data, a computing cloud platform that processes data, and an integrated cloud computing platform that takes into account data storage and processing.
  • the cloud platform used by the on-demand service system 105 or a portion thereof may 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 on-demand service system 105 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.
  • scheduling engine 110 shown in FIG. 2 can be implemented in a variety of ways.
  • scheduling engine 110 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 on-demand service system 105 or a portion thereof (eg, the scheduling engine 110) and its modules described in this application can have not only integrated power such as ultra-large scale A circuit or gate array, a semiconductor such as a logic chip, a transistor, or the like, or a hardware circuit implementation of a programmable hardware device such as a field programmable gate array, a programmable logic device, or the like, or executed by, for example, various types of processors
  • the software implementation can also be implemented by a combination of the above hardware circuits and software (for example, firmware).
  • the above description of the scheduling engine 110 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 can be internal or external.
  • the storage module may actually exist in the scheduling engine 110 or complete a corresponding function through a cloud computing platform.
  • any combination of modules can be performed without departing from the principle, or subsystems and other modules can be constructed. connection.
  • 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 one module may implement the functions of 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, or an input module and an output module for passengers.
  • the processing module 210 and the storage module 220 can be two modules, or one module can have both processing and storage functions.
  • each module may share a single storage module, or each module may have its own storage module. Variations such as these are within the scope of the present application.
  • FIG. 3 is an exemplary flow chart of capacity scheduling.
  • the capacity scheduling process can be performed by the on-demand service system 105 or a portion thereof (eg, the scheduling engine 110).
  • scheduling reference information can be obtained.
  • the acquisition of the scheduling reference information may be performed by the scheduling engine 110. More specifically, the acquisition of the scheduling reference information may be performed by the processing module 210.
  • the scheduling reference information may include, but is not limited to, a combination of one or more of order information, user information, environment information, and the like.
  • the order information may be order time information (eg, order departure time, order waiting time), order type information (eg, long distance order, short distance order), order location information (eg, departure location, destination location), order price information ( For example, a combination of one or more of an order transaction price, a surcharge, and the like.
  • the user information may be user identity information (eg, user occupation, user gender), user terminal device information (eg, user terminal device model, user terminal device remaining power), user preference information (eg, passengers for drivers) Preferences, driver preferences for departure, destination, and departure time), user history order information (eg, driver history orders, passenger history orders), user credit information (eg, passenger's payment history, driver's traffic) A combination of one or more of the violation information).
  • the environmental information may be weather information (eg, temperature information, weather type information), traffic information (eg, road information, traffic congestion information, traffic regulation information), event information (eg, holiday information, major event information) A combination of one or more of geographic information (eg, zoning information, latitude and longitude information), 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 scheduling reference information may be real-time information, may be historical information, and may be prediction information.
  • the real-time information may be order information starting at the current time, user information at the current time, weather information at the current time, and the like.
  • the history information may be information in the past N days, may be information at a specific time (for example, every Monday, 10:00 every day).
  • the prediction information may be predicted weather information, predicted traffic information, and the like.
  • the scheduling reference information may be derived from information received by the passenger interface 230 from the passenger terminal device 120, may be derived from information received by the driver interface 240 from the driver device 140, or may be derived from the database 130, the information source 160. And/or information stored in the storage module 220.
  • the communication method when the information is acquired may be wired or wireless.
  • a scheduling policy may be determined according to the scheduling reference information.
  • the determination of the scheduling policy can be performed by the scheduling engine 110. More specifically, the determination of the scheduling policy can be performed by the processing module 210.
  • the scheduling policy may include, but is not limited to, a combination of one or more of a supply and demand density push policy, a hotspot feature push policy, a statistical feature push policy, an order push policy, an order adjustment policy, or a prompt information push policy.
  • Said The density push strategy can point to the user pushing the supply and demand density information.
  • the supply and demand density information may be one or more of current supply and demand density information, historical supply and demand density information, predicted supply and demand density information, and the like.
  • the hotspot feature push policy may point to the user pushing the hotspot feature information.
  • the hotspot feature information may be hotspot information (eg, an area with the largest number of orders, an order quantity of a specific area), hotspot information (eg, an order quantity for a specific time period, and a number of drivers for a specific time period) One or more of hot order information (for example, which type of order is the most).
  • the statistical feature push policy may point to the user pushing the statistical feature information.
  • the statistical feature information may be statistical characteristic information of the driver (eg, driver's order preference, driver's daily average order amount), statistical characteristic information of the passenger (eg, passenger's selection preference, passenger) Daily average order quantity), statistical characteristics of the order (for example, the number of orders in a specific area, the average transaction price of the order), statistical characteristics of the traffic (for example, statistics on traffic congestion at a specific road segment and time), weather statistics One or more of feature information (for example, statistics of rain and snow weather in a specific area and a specific time).
  • the statistical feature information may be real-time statistical feature information (eg, current order quantity), historical statistical feature information (eg, historical order quantity), predicted statistical feature information (eg, prediction) One or more of the number of orders).
  • the order push policy may point to the user pushing the order information.
  • the order information may be one or more of a specific order information, a plurality of order information selected by the user, and the like.
  • the order adjustment policy may point to the user pushing the order adjustment information.
  • the order adjustment information may include, but is not limited to, adjustment information of an order price, adjustment information of an order type, and the like.
  • the prompt information pushing policy may point to the user pushing the prompt information.
  • the prompt information may include, but is not limited to, one or more of traffic conditions, weather conditions, historical order status, 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 process of the processing module 210 determining the scheduling policy may include, but is not limited to, one or more of storing, classifying, filtering, converting, YES, detecting, predicting, training, etc. the scheduling reference information. The combination.
  • the predictive model can be qualitative, or Quantitative.
  • the quantitative predictive model can be based on time series prediction, and/or based on causal analysis.
  • the temporal prediction method may further include a combination of one or more 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 model may be RIDge Regression, Least Absolute Shrinkage and Selection Operator (LASSO) or Elastic Net (Elastic Net); for decision tree model, it can be Classification and Regression Tree, ID3 (Iterative) Dichotomiser 3), C4.5, CHAID (Chi-squared Automatic Interaction Detection), Decision Stump, Random Forest, Multiple Adaptive Regression Spline (MARS) or Gradient Boosting Machine (GBM)
  • the model may be a Naive Bayes algorithm, an Averaged One-Dependence Estimators, or a Bayesian Belief Network (BBN); for a kernel-based algorithm model, it may be a Support Vector Machine, radial Radial Basis Function or Linear discriminate analysis, etc.; for the clustering algorithm model, it may be k-Means algorithm or Expectation Maximization; for the association rule model, it may be Apriori algorithm or Eclat algorithm; for neural network
  • the model may be a Perceptron Neural
  • a scheduling policy can be sent.
  • the transmission of the scheduling policy may be performed by the scheduling engine 110.
  • the scheduling policy can be sent to the passenger end device 120 via the passenger interface 230.
  • adjustment information of the order price is transmitted to the passenger terminal device 120 through the passenger interface 230.
  • the scheduling policy can be sent to the driver device 140 via the driver interface 240.
  • real-time order information is sent to the driver device 140 via the driver interface 240.
  • the historical order status in the current area is transmitted to the driver device 140 via the driver interface 240.
  • the scheduling policy can be sent to the storage module 220, the database 130, the information source 160, or sent by one internal module or unit of the processing module 210 to another internal module or unit.
  • the price adjustment policy is sent to the order price calculation sub-unit (not shown in Figure 3) in the processing module 210 to make an adjustment to the order price calculation result (for example, the order price is multiplied by 1.5 times the premium based on the original price) ).
  • FIG. 4-A is an exemplary flowchart of the capacity scheduling method on the user side.
  • the capacity scheduling process can be performed by the passenger terminal device 120.
  • a scheduling policy from the server can be received.
  • the scheduling policy can One or more of the following include, but are not limited to, a supply and demand density push strategy, a hotspot feature push strategy, a statistical feature push strategy, an order push policy, an order adjustment policy, or a prompt information push strategy (see FIG. 3 for details).
  • the scheduling strategy may be an order adjustment strategy in which the order price is multiplied by N times the premium based on the original price.
  • the scheduling policy may be a prompt information push strategy that prompts passengers to avoid traveling during peak hours.
  • the scheduling policy may be an order pushing strategy that pushes driver information to the passenger.
  • the communication method for receiving the scheduling policy may be wired or wireless. Taking the mobile device 2900 shown in FIG. 29 as an example, when the device functions as the passenger device 120, the reception of the scheduling policy can be implemented by the antenna 2910.
  • a scheduling policy from the server can be displayed.
  • the display form of the scheduling policy may include, but is not limited to, a combination of one or more of voice, text, graphics, video, and the like.
  • information on price adjustments can be broadcast in the form of voice.
  • the number of vehicles in different areas can be displayed in the form of text.
  • the current vehicle distribution can be displayed on the map in the form of a graph, with a triangle representing the taxi and a square representing the private car.
  • the density information of the driver is displayed in the form of a display frame.
  • the display of the scheduling policy may be displayed based on a map of the passenger device.
  • the degree of concentration of the vehicle can be distinguished by color, the area where the vehicle is most concentrated on the map in red, and the area where the vehicle is less in blue.
  • different supply and demand densities, order densities, order quantities, number of users, and the like can be displayed on the map with different gray scale conditions.
  • the display of the scheduling policy may or may not be triggered by the user. For example, after receiving the trigger signal sent by the passenger, the corresponding scheduling information is displayed on the map of the passenger terminal device. Taking the mobile device 2900 shown in FIG. 29 as an example, when the device is used as the passenger device 120, the display of the scheduling policy can be performed by the display unit 2920.
  • the scheduling policy may require some data processing (eg, data encoding, decoding, format conversion, etc.) from receiving the display.
  • the data processing process can be performed by graphics processor 2930, central processor 2940, and/or memory 2960 of mobile device 2900.
  • demand information can be received.
  • the demand information may be passenger's order request information, passenger's preference information, or other request information of the passenger.
  • the order request information of the passenger may include, but is not limited to, a departure place, a departure time, and an expected time. One or more of the time, the number of passengers waiting, the number of passengers, the gender of the passenger, whether to carry the baggage, the amount of baggage carried, whether to carry the pet, the type and quantity of the pet to be carried, the mileage, the price, the price increase of the consumer, and the like.
  • the passenger's preference information may include, but is not limited to, a preference for the model, a preference for the service provider (eg, a driver who prefers to drive for more than 10 years), a preference for the route (eg, a route with the shortest distance), One or more of the preference for waiting time (for example, a driver who prefers a waiting time of about 5 to 10 minutes).
  • the other request information of the passenger may include, but is not limited to, one or more of request information for acquiring weather conditions sent to the system, request information for obtaining driver distribution of a certain region, information for requesting price adjustment, 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, body sense input or other data input mode, or any combination of the above.
  • the received demand information may be stored in a storage unit of the receiving device or sent directly. Taking the mobile device 2900 shown in FIG. 29 as an example, when the device is used as the passenger device 120, the demand information received by the input/output unit 2950 can be stored in the memory 2960, the central processing unit 2940, or directly stored via the input. / Output unit 2950 or antenna 2910 is transmitted.
  • the received demand information can be transmitted.
  • the transmitted demand information may be the passenger's original demand information or the processed demand information.
  • the processing of the information may include, but is not limited to, one or more of error correction, merging, screening, converting, calculating, and the like of the information.
  • the passenger enters the information in the form of text “Departure: No. 3 Haijie Street, Haidian District, Beijing”.
  • the equipment shown in Figure 4-A can correct the information as “departure: Haidian Street, Haidian District, Beijing”
  • the demand information is transmitted in the form of the latitude and longitude coordinates corresponding to the geographic location.
  • FIG. 4-B is an exemplary flowchart of the capacity scheduling method on the user side.
  • the capacity scheduling process can be performed by the driver device 140.
  • a scheduling policy from the scheduling engine 110 can be received.
  • the scheduling policy may include, but is not limited to, a supply and demand density push strategy, a hotspot feature push strategy, and a statistical special One or more of the push strategy, order push strategy, order adjustment strategy, or prompt information push strategy (see Figure 3 for details).
  • a prompt information pushing strategy for reminding the driver to go to another area to take orders.
  • it may be an order pushing policy that preferentially pushes an order to a driver with a higher credit rating.
  • it may be a statistical feature pushing strategy that displays historical order and real-time order information of the area.
  • the communication method for receiving the scheduling policy may be wired or wireless. Taking the mobile device 2900 shown in FIG. 29 as an example, the reception of the scheduling policy can be implemented by the antenna 2910.
  • a scheduling policy from the scheduling engine 110 can be displayed.
  • the display form of the scheduling policy may include, but is not limited to, a combination of one or more of voice, text, graphics, video, and the like.
  • information on price adjustments can be broadcast in the form of voice.
  • the number of passengers in different areas can be displayed in the form of text.
  • the current order distribution can be displayed on the map in the form of a graphic, with a circle representing a long distance order and a diamond representing a short distance.
  • the density information of the order is displayed in the form of a display box.
  • the display of the scheduling policy may be displayed based on a map of the passenger device.
  • the degree of concentration of the passengers can be distinguished by color, the area where the passengers are most concentrated is marked on the map in red, and the area where the passengers are less in blue.
  • different supply and demand densities, order densities, order quantities, number of users, and the like can be displayed on the map with different gray scale conditions.
  • the display of the scheduling policy may or may not be triggered by the user. For example, after receiving the trigger signal sent by the driver, the corresponding scheduling information is displayed on the map of the driver device. Taking the mobile device 2900 shown in FIG. 29 as an example, the display of the scheduling policy can be performed by the display unit 2920.
  • the scheduling policy may require some data processing (eg, data encoding, decoding, format conversion, etc.) from receiving the display.
  • the data processing process can be performed by graphics processor 2930, central processor 2940, and/or memory 2960 of mobile device 2900.
  • the scheduling reference information may be pre-processed after step 311.
  • 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.
  • a judging step may be added to determine whether the server has sent a new scheduling policy. The reception of the scheduling policy is continued after the new scheduling policy is detected.
  • the passenger can receive from the dispatcher device 120 whether the service request from the dispatch engine 110 is accepted and related information.
  • the passenger may also provide feedback to the received information via the passenger device 120.
  • the driver can provide feedback (eg, one or more of selection, acceptance, rejection, etc.) to the scheduling policy via the driver device 140. Variations such as these are within the scope of the present application.
  • FIG. 5 is a schematic diagram of a processing module 210 in a capacity scheduling system.
  • the processing module 210 can include one or more order information extraction modules 510, one or more user information extraction modules 520, one or more environmental information extraction modules 530, one or more order information distribution modules 540, one or more schedules Module 550, and one or more computing modules 570.
  • the processing module 210 may also include one or more other modules or units.
  • Each of the above modules 510-570 can communicate with each other, and the connection manner between the modules can be wired or wireless.
  • the connection between the modules is exemplarily shown in FIG. 5, but it does not mean that the connection between the modules is limited to this.
  • the order information extraction module 510 can extract direct or indirect information related to the order.
  • the order information may be one or more of real-time order information, historical order information, reservation order information, forecast order information, and the like.
  • 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 models, carry luggage, carry luggage Quantity, pets, 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 order status, etc., or any combination of the above information.
  • 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 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 One or more of the information and the like.
  • 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 extracted in real time.
  • the extracted order information may be stored in the order information extraction module 510, the storage module 220, the information source 160, the database 130, 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 510 may also include one or more sub-units, such as a time information extraction unit (not shown in FIG. 5), a location information extraction unit (not shown in FIG. 5), a parsing unit ( Not shown in Figure 5), processing unit (not shown in Figure 5), etc.
  • the time information extracting unit may extract time information related to the order (for example, the time at which the order was sent, the time at which the reservation was scheduled, the time period at which the scheduled departure time was taken, and the like).
  • the location information extraction unit may 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 analyze time information, location information, and the like related to the order. For example, the parsing unit can convert location information from a textual 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 may process one or more order-related information extracted by the order information extraction module 510.
  • the processing manner may include, but is not limited to, one or more of calculation, identification, verification, judgment, screening, and the like.
  • the user information extraction module 520 can extract direct or indirect information related to the user.
  • the user may include a passenger or a driver.
  • the user information may be one or more of historical user information, real-time user information, or predicted user information, and the like.
  • the user information may be user identity information, user terminal device letter A combination of one or more of interest, user preference information, user history order information, user credit information, and the like.
  • the user identity information may include, but is not limited to, a user's name, nickname, gender, nationality, occupation, age, contact information (telephone number, mobile phone number, social account information (such as micro-signal code, QQ number, LinkedIn, etc.), etc.
  • the user terminal device information may include, but is not limited to, communication device information (eg, device model, network mode, time when the device accesses the network, etc.), traffic device information (eg, vehicle model, license plate number, fuel consumption per kilometer, One or more of remaining equipment, age, trunk size, panoramic sunroof, historical maintenance, etc., other equipment information (eg, information on emergency medical equipment carried, information on fire extinguishing equipment).
  • the user preference information may include, but is not limited to, one or more of a passenger's preference for the driver, a driver's preference for the passenger, a user's preference for the departure place, destination, waiting time, and the like.
  • the user history order information may include, but is not limited to, one or more of a driver history order number, a passenger history order quantity, a user history order origin, a destination, a departure time, a waiting time, and the like.
  • the user credit information may include, but is not limited to, one or more of a user history refresh ratio, user traffic violation information, a user bank information record, a user history payment record, and the like.
  • User information can be extracted in real time or extracted in real time. For example, some user information can be extracted in real time, and some user information can be extracted in real time.
  • the extracted user information may be stored in the user information extraction module 520, the storage module 220, the information source 160, the database 130, or any of the storage devices integrated in the system or independent of the system as described in this application.
  • the user information extraction module 520 may also include one or more sub-units, such as an information receiving unit (not shown in FIG. 5), an information parsing unit (not shown in FIG. 5), and an information transmission unit (not Shown in Figure 5).
  • the information receiving unit can 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, the current service status fed back by the driver (eg, passengers, waiting for passengers, empty driving), driver's request for service One or more of selection, confirmation or rejection information.
  • the above information may be natural language text information, binary information, audio information (for example, including driver's voice input), One or more of information such as information (eg, still pictures or video) and other types of multimedia information.
  • the information parsing unit may sort or classify the above information, for example, into a readable or storable format.
  • the information transmission unit can receive or transmit information.
  • the information transmission unit may include one or more wired or wireless transceiver devices.
  • the environment information extraction module 530 can extract direct or indirect information related to the environment.
  • the environmental information may be one or more of real-time environmental information, historical environmental information, predicted environmental information, and the like.
  • the environmental information may be a combination of one or more of weather information, traffic information, event information, geographic information, and the like.
  • the weather information may include, but is not limited to, temperature (eg, highest temperature, minimum temperature), humidity, type of weather (eg, sunny, cloudy, overcast, rain, snow, floating dust, sand, shovel, wind), One or more of the quantity indicators of different types of weather (for example, rainfall, snowfall, haze index, wind speed).
  • the traffic information may include, but is not limited to, the location of the road, whether the road is unobstructed, the speed limit condition, whether there is an emergency situation (eg, traffic accident, maintenance construction, traffic police control), and the like.
  • the event information may include, but is not limited to, one or more of holiday information, major events, and the like.
  • the geographic information may include, but is not limited to, one or more of area division information, latitude and longitude information, building information, and the like.
  • Environmental information can be extracted in real time or extracted in real time. The extracted environmental information may be stored in the environmental information extraction module 530, the storage module 220, the information source 160, the database 130, or any storage device integrated in the system or independent of the system as described in this application.
  • the extracted order information, user information and environmental information may be transmitted to the calculation module 570 for further calculation analysis in real time or non-real time, or may be transmitted to the order distribution module 540 or the scheduling module 550 for order allocation or in real time or non-real time.
  • Capacity scheduling For example, after obtaining the traffic accident information, the environment information obtaining module 530 may initiate a prompt information push scheduling policy, and transmit the accident information to the passenger and/or the driver through the passenger interface 230 and/or the driver interface 240 in real time.
  • the environment information extraction module 530 may further include one or more sub-units, such as an information receiving unit (not shown in FIG. 5), an information parsing unit (not shown in FIG. 5), and an information transmission unit (not Shown in Figure 5).
  • the information receiving unit can receive or read environmental information. Specifically, for example, weather messages at specific times and specific locations One or more of the predicted future traffic congestion conditions, specific time and traffic accident information at a specific location.
  • the above information may be one or more of natural language text information, binary information, audio information (eg, including driver's voice input), image information (eg, still picture or video), and other types of multimedia information.
  • the information parsing unit may sort or classify the above information, for example, into a readable or storable format.
  • the information transmission unit can receive or transmit information.
  • the information transmission unit may include one or more wired or wireless transceiver devices.
  • the order allocation module 540 can assign an order to be assigned to the user.
  • the order distribution module 540 can be integrated into the passenger interface 230 and/or the driver interface 240.
  • the order assigning module 540 can read one or more of 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 540 can read the scheduling policy calculated by the computing module 570 and allocate the order according to the scheduling policy.
  • the order allocation module 540 can be integrated with the scheduling module 550 in a separate module while implementing the functions of scheduling policy push and order publishing.
  • the scheduling module 550 can send a scheduling policy to the user.
  • the scheduling policy may be derived from the calculation result of the scheduling policy calculation unit 579, may be the result of calculation by other units (eg, the feature index calculation unit 573, the prediction model calculation unit 577), or directly from other modules (eg, The information acquired by the order information extraction module 510, the user information extraction module 520, and the environment information acquisition module 530).
  • the scheduling module 550 can directly receive the supply and demand density information calculated from the predictive model calculation unit 577 and transmit the information to the user.
  • the environment information acquiring module 530 directly sends the traffic accident information to the user by the scheduling module.
  • the scheduling module 550 can be integrated in the passenger interface 230 and/or the driver interface 240.
  • the calculation module 570 can calculate a scheduling policy.
  • the calculation module 570 can include one or more region information calculation units 571, a feature index calculation unit 573, an order group calculation unit 575, a prediction model calculation module 577, and a scheduling information calculation module 579.
  • the computing module 570 can also include one or more other modules Or unit.
  • the interior of the computing module 570 can also integrate one or more storage units (not shown in FIG. 5) for storing acquired order information, user information, environmental information, and/or calculated scheduling policies.
  • the calculated scheduling policy can be transmitted to the order allocation module 540 or the scheduling module 550 in real time or non-real time for distribution of orders or distribution of scheduling information.
  • the calculation methods used by the calculation module 570 can 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-evid method, exhaustive method, Method, undetermined coefficient method, changing element method, split method, supplementary method, factorization method, parallel movement method, function approximation method, interpolation method, curve fitting method, integral method, differential method, perturbation method, etc.
  • the information involved in the calculation process may be obtained from the order information extraction module 510, the user information extraction module 520, the environment information extraction module 530, or may be obtained from the database 130 and/or the information source 160.
  • the area information calculation unit 571 can process information related to area division. The processing may include, but is not limited to, performing one or more of area division, merging, splitting, finding, and the like.
  • the area information calculation unit 571 may also include one or more subunits.
  • the area information calculation unit 571 may include an area division sub-unit 5711 (not shown in FIG. 5), a flag location determination sub-unit 5713 (not shown in FIG. 5), and an area attribution determination sub-unit 5715 (not shown in FIG. 5).
  • One or more of the area merge sub-unit 5717 (not shown in FIG. 5) and the like.
  • the feature index calculation unit 573 can calculate the feature indicator.
  • the feature indicators include, but are not limited to, one or more of a regional feature indicator, a user feature indicator, an order feature indicator, and the like.
  • the feature index calculation unit 573 may further include one or more subunits.
  • the feature index calculation unit 573 may include a region feature calculation sub-unit 5731 (not shown in FIG. 5), an order feature calculation sub-unit 5732 (not shown in FIG. 5), and a supply and demand feature calculation sub-unit 5733 (not shown in FIG. 5).
  • user feature calculation sub-unit 5734 (not shown in Figure 5), hotspot feature calculation sub-unit 5735 (not shown in Figure 5), probability calculation sub-unit 5736 (not shown in Figure 5), environmental characteristics Calculation subunit 5737 (not in One or more of those shown in Figure 5).
  • the order group calculation unit 575 can perform order grouping.
  • the order may include, but is not limited to, one or more of a historical order, a real-time order, an appointment order, a forecast order, and the like.
  • the scheduling policy calculation unit 579 can include one or more sub-units, such as storage sub-units (not shown in Figure 5).
  • the prediction model calculation unit 577 can perform various predictions.
  • the predicted content may include, but is not limited to, prediction of one or more of future order quantities, number of users, supply and demand density, order density, environmental information, and the like.
  • the predictive model calculation unit 577 can include one or more subunits.
  • the prediction model calculation unit 577 may include a prediction feature sub-unit 5771 based on the region feature (not shown in FIG. 5), a prediction sub-unit 5773 based on the environment information (not shown in FIG. 5), an order receiver prediction sub-unit 5775.
  • the scheduling policy calculation unit 579 can perform calculation of the scheduling policy.
  • the scheduling policy may include, but is not limited to, a combination of one or more of a supply and demand density push policy, a hotspot feature push policy, a statistical feature push policy, an order push policy, an order adjustment policy, or a prompt information push policy (detailed description See Figure 3).
  • the scheduling policy calculation unit 579 can include one or more sub-units.
  • the scheduling policy calculation unit 579 may include a supply and demand adjustment policy determination subunit 5791 (not shown in FIG. 5), a high probability user selection subunit 5792 (not shown in FIG.
  • one or more memory modules may be integrated within processing module 210.
  • the storage module (not shown in FIG. 5) can store various information and intermediate data extracted, calculated, and generated by other modules.
  • various sub-modules 510-570 within processing module 210 may internally integrate respective storage units (not shown in FIG. 5) for storing information or intermediate data.
  • each of the sub-modules 510-570 in the processing module 210 can be logic-based operations, such as NAND operations or numeric-based operations.
  • Each of the sub-modules 510-570 in the processing module 210 can include one or more processors, which 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 chip (SoC), etc., can also be a digital signal processor (DSP) and so on.
  • PLD programmed programmable logic device
  • ASIC application specific integrated circuit
  • SoC system chip
  • DSP digital signal processor
  • each of the sub-modules 510-570 in the processing module 210 can be implemented in a variety of manners.
  • the order engine 110 or the on-demand service system 105 can be implemented by hardware, software, or a combination of software and hardware, not only by, for example, very large scale integrated circuits or gate arrays, such as logic chips, transistors, and the like.
  • Semiconductor circuits, or hardware circuit implementations of programmable hardware devices such as field programmable gate arrays, programmable logic devices, etc., or implemented in software, for example, executed by various types of processors, may also be implemented by hardware circuits and software as described above. Combined with (for example, firmware).
  • FIG. 6 is a schematic diagram of processing module 210.
  • the processing module 210 may include one or more order information extraction modules 510, a user information extraction module 520, an environment information extraction module 530, an order distribution module 540, a scheduling module 550, and a calculation module 570, and the like.
  • the calculation module 570 may include one or more area information calculation units 571, a feature index calculation unit 573, a prediction model calculation unit 577, and other units (not shown in FIG. 6).
  • the area information calculation unit 571 may include an area division sub-unit 5711 and other sub-units (not shown in FIG. 6).
  • the feature index calculation unit 573 may include a region feature index calculation sub-unit 5731 and other sub-units (not shown in FIG. 6).
  • the prediction model calculation unit 577 may include prediction sub-units 5771 and other sub-units based on the region features (not shown in FIG. 6).
  • one or more of the order information extraction module 510, the user information extraction module 520, the environment information extraction module 530, the order distribution module 540, and the scheduling module 550 can be respectively connected to the calculation module 570. As shown in FIG. 6, the connection manner between each module and the unit may be wired or wireless, and each module and unit may be Conduct information communication.
  • the order information extraction module 510 can acquire order information.
  • the user information extraction module 520 can acquire user information.
  • the environment information extraction module 530 can obtain environment information.
  • the order allocation module 540 can assign an order to be assigned to the user.
  • the scheduling module 550 can send a scheduling policy to the user. The related content is described in detail in FIG. 5, and details are not described herein again.
  • the area dividing sub-unit 5711 can perform the division of the area.
  • the area division method may include a combination of one or more of a division method according to a grid, a division method according to a cluster, a division method according to a specific rule (for example, an administrative area), and the like (for details, see FIG. 7-A, FIG. 7-B, Figure 7-C).
  • the area attribution judging sub-unit 5715 can be used to determine the area to which the specific location belongs, and can also be used to determine the user situation in the specific area.
  • the user can be a driver or a passenger.
  • the specific location may be the current location of the driver, or the departure location of the order, the destination location of the order, and the like.
  • the location information may be the location coordinates of the passenger equipment 120 and/or the driver equipment 140 that are located by the positioning technology, or the current location of the passenger or driver input, and the like.
  • the positioning technology includes, 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, One or more of base station positioning technology, Wi-Fi positioning technology, various positioning speed measuring systems provided by the vehicle, and the like.
  • GPS Global Positioning System
  • GLONASS Global Navigation Satellite System
  • Beidou navigation system technology Beidou navigation system technology
  • Galileo positioning system (Galileo) technology Galileo positioning system
  • QAZZ Quasi-Zenith satellite system
  • One or more of base station positioning technology can be acquired based on the Wi-Fi positioning technology.
  • a wireless router has a globally unique Media Access Control (MAC) address, and in general the wireless router does not move for a period of time.
  • the Wi-Fi device 120 can scan and collect the surrounding router signals to obtain the MAC address broadcasted by the router.
  • the passenger terminal device 120 can transmit these data capable of indicating the router to the positioning module (not shown in Figure 6).
  • the positioning module (not shown in FIG. 6) can retrieve the geographic location of the relevant router in the database 130 according to the received data, and calculate the strength of the different router signals received by the passenger terminal device 120. The location of the passenger end device 120.
  • the area feature index calculation sub-unit 5731 can perform calculation of the area feature index.
  • the regional feature indicator may include, but is not limited to, a basic feature indicator of the region, and a calendar A combination of one or more of a historical characteristic indicator and a real-time characteristic indicator.
  • the basic feature indicators may include, but are not limited to, weekend information, holiday information, current time, weather information related to a particular partition, activity information, and business circle information. It can be understood that the demand for taxis on weekdays and weekends may be significantly different, so whether weekend information for weekends can be one of the basic characteristics of the impact of capacity scheduling.
  • the current time is also a basic characteristic indicator that affects capacity scheduling, especially in combination with specific business circle information.
  • the international trade area has a greater demand for capacity on the working day from 6:00 pm to 11:00 pm.
  • Weather information is also a basic indicator of the impact of capacity scheduling. For large cities like Beijing, the weather conditions in different regions may be different. For example, the international trade area has already rained and the Huilongguan area is still sunny. The capacity demand of the international trade area may change due to the weather.
  • the historical characteristic indicators may include, but are not limited to, vehicle history contemporaneous requirements associated with a particular partition, transaction rate data associated with a particular partition, and the like.
  • the Guomao Division had a demand for 800 taxis during the same period of time from 19:00 to 20:00 on January 10, 2015, and 600 orders (with a turnover rate of 75%) during this time period. At 18:55 on October 10, 2016, there were only 200 taxis, far below the historical level. According to this, we can consider dispatching some taxis from other regions to the Guomao Division.
  • the real-time features may include, but are not limited to, one or more of a number of vehicle demands, a change amount of the demand amount, and the like in a time period prior to the current time associated with a particular partition.
  • the distribution of taxi demand in the first three hours of the International Trade Zone is 600, 500, and 400, showing a trend of decreasing demand.
  • the calculation method of the regional feature index by the regional feature index calculation sub-unit 5731 may include, but is not limited to, one or more of statistics, grouping, summation, clustering, and the like.
  • 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.
  • 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 prediction subunit 5771 based on the region feature can perform prediction of the indicator.
  • the predicted indicators may include, but are not limited to, one or more of an order quantity, a demand amount, a turnover rate data, and the like of a specific area within a specific time period.
  • the data base used for the prediction may be a combination of one or more of the historical feature index, the real-time feature index, and the base feature index calculated by the region feature index calculation unit 5731.
  • the data base used for the prediction may also be one or more of the data directly obtained from the order information extraction module 510, the user information extraction module 520, and/or the environmental information extraction module 530.
  • the scheduling amount calculation sub-unit 5796 can calculate scheduling related parameters.
  • the scheduling related parameters may include, but are not limited to, one or more of an actual scheduling amount, a potential scheduling amount, a potential volume increment, a potential transaction increment sum, a maximum potential transaction increment, and the like.
  • the calculation of the scheduling related parameters may be based on one or more of real-time data, historical data, and future data. For example, the amount of dispatch is determined based on future weather conditions. For another example, the current amount of scheduling is determined based on historical order conditions.
  • the result of the scheduling amount calculation can be directly used for the scheduling of the capacity, for example, sending scheduling information to the corresponding number of drivers. It is also possible to select whether to send or not to send a scheduling policy according to the result of the calculation of the scheduling amount. For example, when the calculated scheduling amount is less than a certain threshold, the scheduling policy may not be started temporarily.
  • a prompt information generating unit may be added for generating prompt information.
  • the prompt information generating unit shown may be within the computing module 570 and may be external to the computing module 570.
  • FIGS 7-A, 7-B, and 7-C are schematic illustrations of region partitioning, in accordance with some embodiments of the present application.
  • the area division may be a uniform division or an uneven division. For example, divide an area into a grid of 1 km long and wide. Further, for example, a zone where a vehicle having a large area such as a lake cannot pass is divided into one zone, and the land portion is evenly divided.
  • an area may have one or more centers that are unevenly divided outward from one center, the portions near the center are small, and the portions far from the center are spaced apart.
  • the division of the regions may correspond to a certain area or may be independent of the area. In some embodiments, the locations in the regions may or may not be continuous.
  • the region partitioning may be done once, or may be a combination of multiple partitioning results. For example, based on the results of the previous division, the regions are merged or subdivided according to some conditions. For another example, in the process of using the division result, the division result can be continuously adjusted according to actual needs.
  • the representation of the regions may include, but is not limited to, descriptions using coordinate points, descriptions in latitude and longitude, and/or other ways in which a location information may be determined.
  • the region partitioning can be done by grid.
  • the method of dividing the area according to the grid may include, but is not limited to, free meshing, mapping meshing, line meshing, surface meshing, volume meshing, sweeping meshing, hybrid meshing, based on freedom.
  • the dividing method according to the grid may include one or more of the steps of defining a unit attribute, defining a grid attribute on the geometric model, dividing the grid, and the like.
  • region division can be performed in clusters.
  • the feature points (721a-n) can be clustered to form different sub-regions (731a-n).
  • the feature point may be one or more of location information corresponding to the user, location information corresponding to the order (eg, departure point, destination), location information determined by other information, and the like.
  • the particular points shown may represent the departure location of the order, and each sub-region may correspond to a centralized area of an order departure location.
  • the algorithm used according to the cluster division method may be one of a split clustering algorithm, a hierarchical clustering algorithm, a density-based clustering algorithm, a grid-based clustering algorithm, a model-based clustering algorithm, or the like.
  • Split clustering algorithm can include but not It is limited to K-average clustering algorithm, clustering algorithm based on random selection (CLARANS), partitioning-based clustering algorithm (FCM) and so on.
  • the split clustering algorithm may first create K partitions and then use loop positioning techniques to improve the partitioning results by moving objects from one partition to another.
  • the K divisions may be the result of an adaptive calculation or may be preset.
  • the hierarchical clustering algorithm may include, but is not limited to, one or more of a BIRCH algorithm, a CURE algorithm, a ROCK algorithm, a CHEMALOEN algorithm, and the like. In some embodiments, the hierarchical clustering algorithm may employ a top-down approach or a bottom-up approach.
  • the density based clustering algorithm may include, but is not limited to, one or more of a DBSCAN algorithm, an OPTICS algorithm, and the like. In some embodiments, the density based clustering algorithm can continuously cluster based on the density around the object.
  • the grid-based clustering algorithm may include, but is not limited to, the STING algorithm, the CLIQUE algorithm, and the like.
  • the grid-based clustering algorithm first divides the space into finite elements to form a grid structure, and then performs clustering using the grid structure.
  • the model-based clustering algorithm includes, but is not limited to, one or more of a statistical COBWEB method, a CLASSIT method, and the like.
  • zoning may be performed according to specific rules (eg, administrative area, geographic information).
  • the administrative area includes, but is not limited to, one or more of a province, a city, a county, a township, a town, a street, and the like.
  • the Haidian District can be divided into a sub-area.
  • the geographic information may include, but is not limited to, one or more of geomorphology, meteorology, precipitation, geology, hydrological information, and the like. For example, a location with an average elevation within a certain threshold range can be divided into a sub-region.
  • FIG. 8 is an exemplary flow diagram of a capacity schedule based on a schedule amount prediction.
  • the area division may be performed according to a certain area division method.
  • region partitioning may be performed by region partitioning sub-unit 5711.
  • the area dividing method may include a combination of one or more of a mesh division method, a cluster division method, a specific rule division method, and the like (see FIG. 7-A, FIG. 7-B, and FIG. 7-C).
  • a mesh division method for example, Beijing will be clustered according to all the order coordinate information in a week to get 937 partitions and corresponding center points.
  • Beijing is divided into 18 districts/counties including Dongcheng District, Xicheng District, Chongwen District and Miyun County according to administrative areas.
  • the current service offering associated with the partition can be obtained.
  • the acquisition of the current service supply amount can be performed by the area feature calculation sub-unit 5731.
  • the current service supply amount may be composed of a plurality of indicators, including but not limited to one of current traffic volume, distance of the vehicle, traveling speed of the vehicle, fuel quantity, remaining oil quantity, and the like. kind or more.
  • the region feature calculation sub-unit 5731 can calculate not only the current demand for the region, but also some other indicators.
  • the other indicators may include, but are not limited to, one or more of real-time feature indicators, historical feature indicators, and/or basic feature indicators of the region.
  • an expected demand amount associated with the partition can be obtained.
  • the calculation of the expected demand can be performed by the prediction feature sub-unit 5771 based on the region feature.
  • the calculation of the expected demand may be based on one or more of a historical feature indicator, a real-time feature indicator, and a base feature indicator.
  • the prediction of the expected demand can be made using a random forest approach.
  • the actual amount of dispatch can be determined based on the current service supply amount and the expected demand amount.
  • the calculation of the actual amount of scheduling may be performed by the schedule amount calculation subunit 5796.
  • the calculation of the actual amount of dispatch may be the difference between the expected demand and the current service offering. For example, the current demand for transportation in the current International Trade Zone is 800, and the current supply of vehicles is 600. It can be determined that the dispatch volume of the International Trade Zone is 200.
  • the actual amount of scheduling is calculated in addition to the expected In addition to the demand and current service supply, other variables (for example, time) can also be introduced.
  • the steps 803 and 805 can be performed at the same time, and the current service supply amount and the expected demand quantity are calculated, and the step 805 can be performed first and then the step 803 is performed.
  • other selection conditions may be added between any two steps, such as storing the results of any one step for storage backup, and the like.
  • FIG. 9 is a schematic diagram of processing module 210, in accordance with some embodiments of the present application.
  • the processing module 210 may include one or more order information extraction modules 510, a user information extraction module 520, an environment information extraction module 530, an order distribution module 540, a scheduling module 550, and a calculation module 570, and the like.
  • the calculation module 570 can include a prediction model calculation unit 577, a scheduling policy calculation unit 579, and other units (not shown in FIG. 9).
  • the prediction model calculation unit 577 may include prediction subunit 5773 based on environmental information and other subunits (not shown in FIG. 9).
  • the scheduling policy calculation unit 579 may include a supply and demand adjustment policy determination subunit 5791 and other subunits (not shown in FIG. 9).
  • one or more of the order information extraction module 510, the user information extraction module 520, the environment information extraction module 530, the order distribution module 540, and the scheduling module 550 can be respectively connected to the calculation module 570.
  • the connection manner between each module and the unit may be wired or wireless; information communication may be performed between each module and the unit.
  • the order information extraction module 510 can acquire order information.
  • the user information extraction module 520 can acquire user information.
  • the environment information extraction module 530 can obtain environment information.
  • the order allocation module 540 can assign an order to be assigned to the user.
  • the scheduling module 550 can send a scheduling policy to the user. The related content is described in detail in FIG. 5, and details are not described herein again.
  • the prediction information sub-unit 5773 based on the environment information may perform data prediction based on the environmental information.
  • the environmental information may be weather information, traffic information, event information, geographic information. A combination of one or more of the others (see Figure 5 for a detailed description).
  • the prediction can be a one-time prediction or an iterative prediction.
  • the predicted content may include, but is not limited to, one or more of a specific area and/or a number of orders, a number of users, a volume, and the like at a specific time.
  • the method used in the prediction may be a qualitative prediction method or a quantitative prediction method.
  • prediction methods may include moving average method, exponential smoothing method, trend extrapolation method, regression prediction method, grey prediction method, moving autoregressive prediction method, cobweb model method, analytic hierarchy process, entropy weight method, neural network method, genetics One or more of the algorithm model method and the like.
  • the supply and demand adjustment policy judgment subunit 5791 can determine whether to start the scheduling policy. The determination may be made in one or more ways, such as threshold comparison, substitution, and the like. The content of the judgment may also include selection of a scheduling policy.
  • a strategy of stimulating supply and/or suppressing demand may be initiated in the event of a demand. For example, scheduling capacity from a free area to a busy area. Another example is to remind passengers that it is difficult to take a taxi.
  • a strategy of stimulating demand and/or suppressing supply may be initiated. For example, additional taxi assistance is provided to stimulate passengers' demand for taxis. As another example, the capacity is dispatched from the oversupply area to the free area.
  • a scheduling strategy for diversion may also be initiated in areas where supply and demand are unbalanced. For example, divert passengers between express trains, speedboats, special cars, taxis, and carpools.
  • processing module 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.
  • Each of the above units may be added or deleted according to a specific implementation scenario or needs.
  • 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.
  • one or more storage modules may be integrated in the computing module for storing information in the calculation process and the like.
  • the prediction subunit based on the environment information and the 5773 and the supply and demand adjustment policy judging subunit 5791 may be integrated in the same module, and the scheduling parameter prediction is performed simultaneously. The choice and judgment of the scheduling strategy.
  • FIG. 10 is an exemplary flowchart of capacity scheduling based on environmental information.
  • order recipient e.g., driver
  • the acquisition of the order recipient information can be performed by the user information extraction module 520.
  • the target area may be an arbitrary area or an area where the current driver position is located.
  • the target area may be a fixed area (for example, within a radius of 5 km centered on the Tiananmen People's Hero Monument) or a changed area (for example, an area clustered based on real-time order conditions).
  • the target time may be the current time or an arbitrarily formulated time. Specifically, for example, the online number of the driver's device 140 in the Tiananmen area at 16 o'clock on January 29, 2016 can be obtained.
  • the environmental information may be a combination of one or more of weather information, traffic information, event information, geographic information, etc. (see FIG. 5 for a detailed description).
  • the environmental information may be daily rainfall information, denoted by a.
  • a When the daily rainfall a is greater than or equal to 0.05 mm and less than or equal to 10 mm, it means light rain; when the daily rainfall a is greater than 10 mm and less than or equal to 30 mm, it means moderate rain; when the daily rainfall a is greater than 30 mm, it means heavy rain.
  • the future time period can be one or more specific moments.
  • the current time is 7:00 AM on Friday
  • the future time period may be the time of the next hour of the current time, ie 8:00 AM.
  • the future time period can be one or more specific time periods.
  • the current time is 7:00 AM on Friday
  • the future time period may be the time period of the current hour in the next hour, that is, 7:00 AM-8:00 AM.
  • environmental information for each sub-area of the target area, or environmental information for a portion of the sub-areas may be obtained.
  • order information of the target area in the historical time period may be acquired.
  • the acquisition of the order information can be performed by the order information extraction module 510.
  • the order information may be a combination of one or more of order time information, order type information, order location information, order price information, and the like (see FIG. 5 for detailed description).
  • the historical time period may be one or more specific moments, or may be one or more specific time periods. For example, at the step The current time in 1020 is Friday 7:00AM, and the next hour is 7:00AM-8:00AM. Due to the strong weekly cycle of taxi demand, the historical time can be selected from 7:00AM on Friday in the past N days. Multiple time periods consisting of -8:00AM.
  • environment information of the target area during the historical time period can be obtained.
  • the acquisition of the environmental information may be performed by the environmental information extraction module 530. This step can appear as an optional step.
  • the historical order information may include environmental information associated with the order.
  • step 1050 it may be determined according to the acquired order receiver information, environment information, and order information whether the scheduling policy needs to be started.
  • the determination process can be performed by module 5791.
  • the judging process may include calculation of a supply and demand reference value, a supply and demand forecast value, etc. (see FIG. 11 for details).
  • the scheduling policy may be a combination of one or more of a supply and demand density push policy, a hotspot feature push policy, a statistical feature push policy, an order push policy, an order adjustment policy, or a prompt information push strategy (see FIG. 3).
  • the scheduling policy may be a scheduling policy sent to the driver or a scheduling policy sent to the passenger.
  • a driver may be sent a scheduling policy of stimulus supply. For example, one or more of increasing driver rewards, dynamic price adjustments, scheduling capacity from free areas, and busy areas.
  • the passenger in response to a situation of short supply, may be sent a scheduling strategy that suppresses demand. For example, reminding passengers to take a taxi, reminding passengers to wait for a long time, reminding passengers to add a tip, dynamically adjusting the price, and diverting the demand for the car to one of the product lines (taking a taxi, special car, carpooling, SF car, etc.) A variety.
  • the driver in order to cope with an oversupply situation, the driver may be sent a scheduling policy that suppresses the supply.
  • a scheduling strategy for stimulating demand may be sent to the passenger. For example, increase passenger travel discounts, dynamic price adjustments, and other travel subsidies (for example, three times a day to get a free ride, get a special supermarket's consumer vouchers by car), and remind passengers Short waiting time (for example, One or more of the other modes of travel, such as public transportation.
  • a step of determining may be added after step 1020, if the predetermined condition is met (eg, the average daily rainfall exceeds 100 mm/day, the degree of heavy rain is reached) may not pass 1030-1050. The steps directly start the corresponding scheduling policy.
  • FIG. 11 is an exemplary flow diagram of a method of determining whether a scheduling policy needs to be initiated, in accordance with some embodiments of the present application.
  • the steps 1101-1113 described in FIG. 11 can be performed by the supply and demand adjustment policy determination subunit 5791.
  • a supply and demand reference value may be calculated based on the order information and the order recipient information.
  • the supply and demand reference value may be represented by the difference between the number of taxi requests and the number of online drivers.
  • the supply and demand reference value may be expressed as a ratio of the number of taxi requests to the number of online drivers.
  • the supply and demand prediction value may be calculated based on the environmental information and the supply and demand reference value.
  • the environmental information may include environmental information of a future time period, and may also include environmental information of a historical time period.
  • steps 1105-1113 it may be determined based on the supply and demand prediction value, and based on the result of the determination, it is determined whether the scheduling policy needs to be started. If the result of the determination is that the scheduling policy is not initiated, step 1113 will be performed. If the result of the determination is that the supply and demand adjustment policy needs to be started, the processing module 210 may select to start the corresponding scheduling policy according to the result of the determination.
  • the supply and demand adjustment policy determination subunit 5791 can compare the magnitude of the supply and demand prediction value with the preset supply shortage request threshold. If the supply and demand prediction value is greater than the preset supply shortage threshold, the step jumps to 1109 to start the preset scheduling policy in case of shortage of supply. If the supply and demand predicted value is less than or equal to the preset supply shortage threshold, the step jumps to 1107 for further determination.
  • the predicted value of the supply and demand in step 1105 is greater than the preset supply or not.
  • the threshold should be specifically expressed as the content shown in formula (1):
  • a is the daily rainfall (for example, 100 mm/day)
  • D is the number of order requests
  • S is the number of orders receiving
  • T 1 is the default supply threshold.
  • Forecast value for supply and demand is the supply and demand reference value.
  • the supply and demand adjustment policy determination subunit 5791 can compare the supply and demand prediction value with the preset supply exceeding threshold. If the supply and demand prediction value is less than the preset oversupply threshold, the step jumps to 1111 to start the preset scheduling policy in the case of oversupply. If the predicted value of the supply and demand is greater than or equal to the preset oversupply threshold, the step jumps to 1113 without starting the preset scheduling policy.
  • the predicted value of the supply and demand in step 1105 is less than the preset oversupply threshold may be specifically expressed as the content shown in formula (2):
  • a is the daily rainfall (for example, 100 mm/day)
  • D is the number of order requests
  • S is the number of orders receiving parties
  • T 2 is the default supply threshold.
  • Forecast value for supply and demand is the supply and demand reference value.
  • steps 1105 and 1107 can be performed simultaneously, and the magnitude relationship between the supply and demand prediction and the preset supply shortage threshold and the preset oversupply threshold is determined.
  • other selection conditions may be added between any two steps, such as storing the results of any one step, etc.
  • FIG. 12 is a schematic diagram of processing module 210, in accordance with some embodiments of the present application.
  • the processing module 210 may include one or more order information extraction modules 510, a user information extraction module 520, an environment information extraction module 530, and an order.
  • the calculation module 570 can include a region information calculation unit 571, a feature index calculation unit 573, a scheduling policy calculation unit 579, and other units (not shown in FIG. 12).
  • the area information calculation unit 571 may include one or more of the area merging sub-unit 5717 and other sub-units (not shown in FIG. 12).
  • the feature index calculation unit 573 may include one or more of the supply and demand feature calculation sub-unit 5733, the hot spot feature calculation sub-unit 5735, the probability calculation sub-unit 5736, and other sub-units (not shown in FIG. 12).
  • the scheduling policy calculation unit 579 may include an area user selection subunit 5793, a regional order selection subunit 5795, a high probability user selection subunit 5792, a high probability order selection subunit 5794, and other subunits (not shown in FIG. 12).
  • one or more of the order information extraction module 510, the user information extraction module 520, the environment information extraction module 530, the order distribution module 540, and the scheduling module 550 can be respectively connected to the calculation module 570. As shown in FIG. 12, the connection manner between each module and the unit may be wired or wireless, and information communication between each module and the unit may be performed.
  • the order information extraction module 510 can acquire order information.
  • the user information extraction module 520 can acquire user information.
  • the environment information extraction module 530 can obtain environment information.
  • the order allocation module 540 can assign an order to be assigned to the user.
  • the scheduling module 550 can send a scheduling policy to the user. The related content is described in detail in FIG. 5, and details are not described herein again.
  • the region merging sub-unit 5717 can perform merging of regions.
  • the area may be the result of the area division sub-unit (not shown in FIG. 12), or the area information directly read from other information sources (for example, the order information may include the area attribution information of the order).
  • the regions are merged according to different feature parameters (eg, order quantity, number of users, supply and demand feature information).
  • the merging may be the merging of one or more sub-regions into one larger sub-region, or one sub-region being split into one or more different sub-regions.
  • the merged region information may be stored in the merge region sub-unit 5717, the storage module 220, or any of the storage devices integrated in or independent of the scheduling engine 110 or the on-demand service system 105 as described herein.
  • the supply and demand feature calculation sub-unit 5733 can calculate a supply and demand feature index.
  • the supply and demand characteristic indicators may include real-time supply and demand characteristic indicators, historical supply and demand characteristic indicators, and forecast supply and demand characteristics. One or more of the criteria.
  • the supply and demand feature can be expressed as one or more of the ratio of the order quantity to the order receiver, the order density, other indicators that can reflect the relationship between supply and demand.
  • the order quantity can be real-time order quantity, historical order quantity, predicted order quantity
  • order receiver quantity can be real-time order receiver quantity, historical order receiver quantity, predicted order receiver quantity One or more of the others.
  • the order density may be one or more of an area density of an order, a time density of an order, a composite density of an area of an order, and time.
  • the calculated supply and demand characteristic information may be stored in the supply and demand feature calculation sub-unit 5733, the storage module 220, any of the storage devices integrated in the scheduling engine 110 or the on-demand service system 105 or independently of the same as described in the present application.
  • the hotspot feature calculation sub-unit 5735 can calculate the hot spot feature indicator of the region.
  • the hot spot feature indicator may include one or more of a real-time hot spot feature indicator, a historical hot spot feature indicator, and a predicted hot spot feature indicator.
  • the hotspot feature indicator may be one or more of a hot spot feature of the user, a hot spot feature of the order, and the like.
  • Hotspot features can be expressed as an absolute number (eg, the number of online drivers in an area represents the hotspot characteristics of the area), or a relative amount (eg, the ranking of the number of online drivers in a plurality of areas using one area indicates the area) Hot feature).
  • the hotspot feature information may be stored in hotspot feature calculation sub-unit 5735, storage module 220, or any storage device integrated in or independent of scheduling engine 110 or on-demand service system 105 as described herein.
  • the probability calculation sub-unit 5736 can calculate the probability that the user will select an order associated with the user.
  • the user may be a service provider (eg, a driver), or a demanding party (eg, a passenger) of the service.
  • the user is associated with an order, and may be based on location information, association based on time information, association based on preference information, association based on other information, and the like.
  • the distance between the departure location of the order description and the driver location is within a predetermined range (eg, 1 kilometer, 3 kilometers), and it can be determined that the order is an order associated with the driver.
  • the departure time of the order belongs to the driver's free time, and it can be determined that the order is an order associated with the driver.
  • the user may be based on the characteristics of the order (departure place, departure time, purpose, desired arrival time, baggage information, tip, etc.), characteristics of the service provider (driving age, age, gender, historical order status, evaluation) Level, whether there is a violation record, order preference, etc.) Determining the user to select an order associated with the user by one or more factors such as gender (age, age, rating level, health status, order preference, etc.), environmental characteristics (weather conditions, traffic conditions, event information, etc.) The probability.
  • the calculated probabilities may be stored in probabilistic computing sub-unit 5736, storage module 220, or any storage device integrated in or independent of scheduling engine 110 or on-demand service system 105 as described herein.
  • the regional user selection sub-unit 5793 can select the user to present for each order within a particular area.
  • the regional order selection sub-unit 5795 can select an order presented to it for each user within a particular area.
  • the selection process can be a random selection or a selection based on certain rules.
  • the rules may include, but are not limited to, one or more based on probability, location information, user preferences, and the like.
  • the user may originate from within a particular area, or a boundary area of a particular area adjacent to other areas.
  • the selection results of the regional user selection sub-unit 5793 and/or the regional order selection sub-unit 5795 may be pushed to the user by the order allocation unit 540 or stored in a storage unit (not shown in Figure 12) for subsequent processing.
  • the high probability user selection sub-unit 5792 may select, for each order, among the users associated with the order, a user with a higher probability of picking the order (ie, a user with a higher probability or probability of accepting the order).
  • the high probability order selection sub-unit 5794 may select an order in which the user selects a higher probability in the order associated with the user (ie, the user has a higher probability or an acceptable acceptance of the order).
  • the selection process can be implemented in a sorted manner. For example, select the top 10 or the top 10% after sorting from high to low.
  • the selection process can be implemented in a threshold manner. For example, the threshold for setting the probability is 0.90, and orders or users above this threshold are orders or users with higher probability.
  • processing module 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.
  • Each of the above units may be added or deleted according to a specific implementation scenario or needs.
  • 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. And change, you can also make a few simple deductions or replacements, not paying Under the premise of creative labor, certain adjustments or combinations of the order of modules or units are made, but these modifications and changes are still within the scope of the above description.
  • the regional user selection sub-unit 5793 and the high-probability user selection sub-unit 5792 may be integrated in one sub-unit.
  • one or more storage units may be added for storing results of hotspot feature calculations or supply and demand feature calculations. 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.
  • FIG. 13 is an exemplary flow diagram for capacity scheduling based on environmental information.
  • order information of a specific area and user information of the area may be acquired.
  • the acquisition of the order information can be performed by the order information extraction module 510.
  • the order information may be a combination of one or more of order time information, order type information, order location information, order price information, and the like (see FIG. 5 for detailed description).
  • the acquisition of user information may be performed by the user information extraction module 520.
  • the user information may be a combination of one or more of user identity information, user terminal device information, user preference information, user history order information, user credit information, and the like (see FIG. 5 for details).
  • step 1303 a probability that a user of the region selects an order associated with the user may be determined.
  • This step is an optional step, that is, step 1303 may be performed after step 1301, or step 1303 may not be performed. This probability can reflect the interest of the user in selecting an order.
  • each order can be paired with the associated plurality of users one by one, and the probability that the user in the pair selects the order is calculated for each pair.
  • the probabilities may be the same or different.
  • each order can be paired with a corresponding group of users and a probability that a group of users in the pair selects the order is calculated for each pair.
  • the amount of users in the packet may be the same or different.
  • an order associated with a user in a particular area may be located in or outside of the area.
  • an order associated with the driver Zhao in the Zhongguancun area can be located in the Huangzhuang area of Haidian.
  • a user associated with an order in a particular area may be located in or outside of the area.
  • a driver associated with a Zhongguancun regional order can be located in the Huangzhuang area of Haidian.
  • an area of oversupply and an area of short supply may be determined.
  • the determination of the request area and the supply shortage area can be performed by the supply and demand feature calculation sub-unit 5733.
  • the determination of the oversupply area and/or the supply shortage area may be obtained by comparing the ratio of the number of orders to the number of service providers to a particular threshold.
  • the order number may be one or more of an actual order number, a historical order number, a predicted order number, and the like.
  • the number of orders may include the quantity of the order demand (for example, the order number 1001 describes that there are 5 people riding a car, and it is necessary to take 2 cars at the same time), or does not include information on the quantity required for the order.
  • the number of service providers may include the number of service provider service providing capabilities (for example, the number of passengers that the driver Lee can accommodate 4 people, one person has a car, and the number of carpools that can be accommodated is 3) Or does not include information on the number of service providers' service offering capabilities.
  • the particular threshold can be any value. In some embodiments, the particular threshold may be one. In some embodiments, the particular threshold may be a value less than one (eg, 0.01, 0.5, 0.6, 0.9), or a value that is much less than one (eg, 0.0001, 0.0000001), and the like.
  • the particular threshold may be a value greater than one (eg, 1.1, 1.3, 1.9, 10), or a value that is much greater than one (eg, 996, 10000), and the like.
  • the specific thresholds for determining the oversupply area and the supply shortage area may be equal.
  • the threshold corresponding to the supply short supply and the oversupply area may be set to 1
  • the area where the ratio of the number of orders to the number of service providers is greater than or equal to 1 is an area that is in short supply
  • the area smaller than 1 is an area of oversupply.
  • the particular thresholds used to determine the oversupply and supply shortage regions may also be unequal.
  • the threshold corresponding to the supply shortage area may be set to 0.7
  • the threshold corresponding to the supply exceeds the area may be set to 2.
  • an order hotspot area and a user hotspot area may be determined.
  • the determination of the order hotspot area and the user hotspot area may be performed by the hotspot feature calculation sub-unit 5735.
  • the order hotspot area may be determined by comparison of the order number and/or order density to the hotspot threshold.
  • the order number may be one or more of an actual order number, a historical order number, a predetermined order number, a predicted order number, and the like.
  • the number of orders may include information on the quantity of the order demand or information that does not include the quantity of the order demand.
  • the order density may be one or more of the area density of the order, the time density of the order, the area of the order, and the composite density of the time.
  • the value of the order density can be 100 orders/square thousand One or more of meters, 80 orders/minute, 120 orders/square kilometers ⁇ minutes, etc.
  • the order hotspot threshold may be a fixed value, or a changed threshold (eg, changes with time, changes in characteristics with regions), and the like.
  • the user hotspot area may be determined by comparison of the number of users and/or user density to a user threshold.
  • the number of users may be one or more of an actual number of users, a number of historical users, a predicted number of users, and the like.
  • the number of users when corresponding to the service provider, may include the number of service capability information of the user or the information of the number of service capabilities of the user.
  • the user density may be one or more of a user's area density, a user's time density, a user's area and a composite density of time, and the like.
  • the value of the user density may be one or more of 100 users/m2, 100 users/minute, 78 users/km2 ⁇ minute, and the like.
  • the user hotspot threshold may be a fixed value, or a varying threshold (eg, changes over time, changes in characteristics with regions), and the like.
  • the order hotspot area and/or the user hotspot area may be determined in a sorted manner.
  • the scheduling engine 110 can monitor the distribution of the number of orders and the number of users in each sub-area (or grid) in each zone.
  • the scheduling engine 110 can count the number of online orders and/or online users in a sub-area (or grid), for example, every two seconds. Based on the statistically obtained information, the scheduling engine 110 can sort the number of orders and/or the number of users in each area, and then select the area ranked earlier (for example, the top 10% or the top 100) as the hotspot of the order and/or the user. region.
  • an area of oversupply and supply shortage may be determined in the order hotspot area and the user hotspot area, respectively.
  • the determining process of the area for oversupply and supply shortage may be performed by the supply and demand feature calculation sub-unit 5733.
  • a certain amount of order hotspot areas may be merged into one new order hotspot area, and a certain amount of user hotspot areas may be merged into one new user hotspot area.
  • the merging of the order hotspot area and the user hotspot area may be performed by the area merging sub-unit 5717.
  • adjacent regions may be merged into one new order hotspot area and/or user hotspot area, or non-adjacent areas merged into one new order hotspot area and/or user hotspot area.
  • the two regional regions may be merged into one new order hotspot region and/or user hotspot region, or more than two (eg, The areas of 3, 8, 16, 100) are merged into a new order hotspot area and/or user hotspot area.
  • an area of oversupply and undersupply may be determined in the new order hotspot area and the new user hotspot area, respectively.
  • the determination of the associated oversupply area and the supply shortage area can be performed by the supply and demand feature calculation sub-unit 5733.
  • the user who presented it may be selected for an order in the area of oversupply.
  • This step can be performed by the regional user selection sub-unit 5793.
  • the user's choice can be random or according to certain rules. For example, the selection can be made according to the magnitude of the probability determined in step 1303. For another example, the location may be selected from near to far according to the order departure location and the user's current location.
  • a user with a higher probability of picking the order may be selected among the users associated with the order.
  • This step can be performed by the high probability user selection subunit 5792.
  • the probability of the user selecting the order may be ranked from high to low, and then a certain number (eg, 1, 10) or a certain percentage may be selected therefrom (eg, 5%, 10%) of users.
  • a threshold of probability eg, 0.56, 0.98 may be set, and a comparison of the thresholds may be used to determine which of the users associated with the order selected the high probability users who selected the order.
  • an order presented to it may be selected for a user in an area that is in short supply.
  • This step can be performed by the regional order selection unit 5795.
  • the order of choice can be random or according to certain rules. For example, the selection can be made according to the magnitude of the probability determined in step 1303. As another example, the user may choose from a near to far location based on the preferred location of the order's destination.
  • the user may be selected for an order with a higher probability in the order associated with the user in an area that is in short supply.
  • This step can be performed by the high probability order selection subunit 5794.
  • the probability that the user selects the order may be ranked from high to low in the order associated with the user, and then a certain number (eg, 1 piece, 10 pieces) or a certain ratio (eg, 5) may be selected therefrom. %, 10%) of the order.
  • a threshold of probability can be set (eg, 0.56, 0.96), the comparison of the thresholds can be used to determine which of the orders associated with the user have an order with which the user has a higher probability.
  • the step of zoning may be added prior to the start of step 1301.
  • steps 1307-110 and steps 1313, 1317 may occur as optional steps.
  • step 1311 and step 1315 may be performed in any order, may be performed sequentially, and may be performed simultaneously.
  • other selection conditions may be added between any two steps, such as storing the results of any one step for storage backup, and the like.
  • FIG. 14 is a schematic diagram of processing module 210, in accordance with some embodiments of the present application.
  • the processing module 210 may include one or more order information extraction modules 510, a user information extraction module 520, an environment information extraction module 530, an order distribution module 540, a scheduling module 550, a calculation module 570, and the like.
  • the calculation module 570 can include an area information calculation unit 571, a schedule information calculation unit 579, and other units (not shown in FIG. 14).
  • the area information calculation unit 571 may include an area division sub-unit 5711, an area attribution determination sub-unit 5715, and other units (not shown in FIG. 14).
  • the dispatch amount calculation unit 579 may include a schedule amount calculation subunit 5796 and other units (not shown in FIG. 14).
  • one or more of the order information extraction module 510, the user information extraction module 520, the environment information extraction module 530, the order distribution module 540, and the scheduling module 550 can be respectively connected to the calculation module 570.
  • the connection manner between each module and the unit may be wired or wireless, and information communication between each module and the unit may be performed.
  • the order information extraction module 510 can acquire order information.
  • the user information extraction module 520 can acquire user information.
  • the environment information extraction module 530 can obtain environment information.
  • the order allocation module 540 can assign an order to be assigned to the user.
  • the scheduling module 550 can send a scheduling policy to the user. The related content is described in detail in FIG. 5, and details are not described herein again.
  • the area dividing sub-unit 5711 can perform area division on a predetermined range.
  • the area dividing method may include a combination of one or more of a mesh division method, a cluster division method, a specific rule division method, and the like (see FIG. 7-A, FIG. 7-B, and FIG. 7-C).
  • the zoning may be based on one or more of an administrative district (eg, Haidian District, Chaoyang District), latitude and longitude, order distribution, business district, building, street name, and the like.
  • the area attribution judging sub-unit 5715 may determine an area to which the specific location belongs, or determine a user situation within the specific area.
  • the specific location may be one or more of a current location of the driver, a departure location of the order, a destination location of the order, and the like.
  • the user can be a driver or a passenger.
  • the current location of the driver Zhao is No. 3 Haidian Street.
  • the regional user attribution judgment sub-unit 5715 it can be determined that the area where Zhao is located is the Zhongguancun area.
  • the area attribution determination sub-unit 5715 can determine the number of all drivers in the Zhongguancun area or the number of passengers placing an order. More details about the region judging subunit 5715 are shown in FIG. 6, and details are not described herein again.
  • the scheduling amount calculation sub-unit 5796 can calculate scheduling related parameters.
  • the scheduling related parameters may include, but are not limited to, one or more of an actual scheduling amount, a potential scheduling amount, a potential volume increment, a potential transaction increment sum, a maximum potential transaction increment, and the like.
  • the calculation of the scheduling related parameters may be based on one or more of real-time data, historical data, future data, and the like. For a more detailed description of the scheduling amount calculation sub-unit 5796, see FIG. 6, which will not be described again.
  • processing module 210 is merely a specific example and should not be considered as the only feasible implementation.
  • Each of the above modules or units is not essential, and each module or unit may be implemented by one or more components, and the function of each module or unit is not limited thereto.
  • Each of the above modules or units may be added or deleted according to a specific implementation scenario or needs.
  • the area can be The dividing sub-unit 5711 and the area attribution judging sub-unit 5715 are integrated in one sub-unit, and the area described by the specific position is judged at the same time as the area division.
  • the area dividing sub-unit 5711, the area attribution judging sub-unit 5715, and the scheduling amount calculating sub-unit 5796 simultaneously integrate the storage sub-unit (not shown in FIG. 14) to store the calculated original data, Intermediate data and/or result information.
  • FIG. 15 is an exemplary flowchart of a capacity scheduling method based on volume information.
  • the dependent variable can be varied by adjusting one or some of the independent variables to achieve a specific value for the purpose of promoting vehicle usage.
  • the independent variable may be the number of service providers, the ratio of drivers (number of drivers/number of passengers), the number of orders, the increment of the service provider, the increment of the ratio (the number of drivers/number of passengers), the order One or more of the increments, etc.
  • the dependent variable may be volume, volume increment, transaction increment, user general acclaim, service provider rush rate distribution (for example, most service providers have a high success rate, only a small part) Service providers have a high success rate, etc.), service provider turnover rate distribution (for example, most service providers have high turnover rates, only a small number of service providers have high turnover rates, etc.).
  • the total number of service providers or the total number of orders may vary or be constant throughout the capacity scheduling process.
  • the following description of the capacity scheduling method shown in FIG. 15 takes as an example the argument that the argument is the increment of the service provider, and the dependent variable is the increment of the transaction and the total number of service providers. It can be understood that the capacity scheduling method shown in FIG. 15 can also be performed under other conditions, and the present application is not limited herein.
  • a regional distribution of a plurality of users can be determined. This determination process can be implemented by the area division sub-unit 5711 and/or the area attribution determination sub-unit 5715.
  • the user can be a service provider or a service requester.
  • the following description of the capacity scheduling method shown in FIG. 15 is exemplified by a service provider. It can be understood that the user in the capacity scheduling method shown in FIG. 15 may be a service requester, for example, when the scheduling method is applied in a visitor dispatching system, the user may be a service requester (eg, a visitor).
  • the manner in which the regions are divided may be based on administrative regions (eg, Haidian Zone, Chaoyang District, etc., one or more of latitude and longitude, order distribution, business circle, building, street name and other signs.
  • the area to which the service provider belongs may be determined based on the location information of the service provider to determine the distribution of the service provider within the area. It will be appreciated that the number of vehicles and service providers is generally consistent, so in this application, the number of service providers can also be used interchangeably with the number of vehicles. For example, within a predetermined range, there are currently m vehicles, n hotspot areas, and the following matrix can be defined:
  • the vehicle number can start from 1, the area number can start from 0, and 0 can represent the area that does not belong to the hot spot area within the predetermined range.
  • the hotspot area may be an area with a large total order quantity, an area with a relatively large order density, a small area with a small multiplier ratio, an area with a faster increase in the order quantity, or other hot spot characteristics.
  • a potential amount of scheduling within the region can be calculated based on the region distribution.
  • the process of calculating the potential scheduling amount can be implemented by the scheduling amount calculation sub-unit 5796.
  • the potential dispatch amount may represent an amount of call in or out of the vehicle.
  • A′ n ⁇ m may be used to represent the distribution of the pre-dispatch vehicle within the area;
  • a n ⁇ m represents the distribution of the vehicle within the area after dispatch, and equation (4) may be obtained:
  • the distribution A′ n ⁇ m of the vehicle in the area before dispatching can be expressed by formula (7):
  • the calculation result of the formula (9) can indicate that two vehicles are called in the area 0, and two vehicles are transferred in the area 1.
  • a potential volume increment for the region may be calculated based on the potential amount of dispatch for the region.
  • the process of calculating the potential volume increment can be implemented by the dispatch amount calculation sub-unit 5796.
  • the potential transaction increment is related to the increment of the vehicle, the order quantity, the turnover rate, and the like.
  • the turnover rate is related to the ratio of drivers (number of drivers/number of passengers). For example, the transaction rate E and the ratio The relationship between the two can be expressed by the formula (10):
  • k can represent the fit factor
  • q can represent the number of service providers (eg, the number of drivers) or the number of vehicles
  • o can represent the order quantity
  • the volume can be expressed as a function of the transaction rate and the order quantity.
  • the volume S can be expressed by the formula (11):
  • k can represent the fit factor
  • q can represent the number of service providers (eg, the number of drivers) or the number of vehicles
  • o can represent the order quantity
  • volume increments for individual regions can be calculated The relationship between vehicle data increments. For example, by differentiating equation (11), equation (12) can be obtained:
  • equation (12) a functional relationship between volume increments and vehicle increments. For example, by integrating equation (12), equation (13) can be obtained:
  • Equation (13) can be abbreviated as formula (14):
  • the potential deal increment sum within the predetermined range may be obtained based on the vehicle increment for the region obtained in step 1520 and the potential volume increment for the region obtained.
  • step 1520 and step 1530 is for only one potential scheduling scheme. If you want to calculate the maximum potential transaction increment, you need to calculate the respective potential transaction increments for multiple potential scheduling scenarios.
  • the respective potential deal increments may be calculated for all potential scheduling scenarios, and the respective potential deal delta sums may also be calculated for a portion of the potential scheduling scenarios.
  • some constraints can be set to filter out a portion of the potential scheduling scheme so that only a portion of the potential scheduling scheme is selected for calculation. The constraint may be that for any one of the potentially scheduled vehicles, the distance traveled from the area that is intended to travel does not exceed a certain distance (eg, cannot exceed 4 kilometers), the service corresponding to any one of the potentially scheduled vehicles.
  • the provider does not perform the passenger task within a certain period of time (for example, orders are not received within 10 consecutive minutes), and the multiplication ratio cannot exceed a certain threshold for a single region (for example, q i + ⁇ q i /q i ⁇ One or more of K), or other constraints.
  • the maximum potential deal increment sum can be calculated based on the potential volume increment of the region.
  • the process of calculating the maximum potential deal increment sum can be implemented by the dispatch amount calculation sub-unit 5796.
  • multiple potential scheduling scenarios may generate potential volume increments for regions within a predetermined range to derive a potential deal increment sum for each potential scheduling scenario. By comparing these potential transaction increments and comparing, analyzing, calculating, etc., the maximum potential transaction increment can be obtained.
  • the actual amount of dispatch for each zone may be determined based on the maximum potential deal increment.
  • the process of determining the actual amount of scheduling can be implemented by the scheduling amount calculation sub-unit 5796.
  • the maximum potential deal increment and corresponding scheduling scheme may be selected and may be determined as the actual scheduling scheme.
  • the scheduling policy may be sent to the service provider corresponding to the potentially scheduled vehicle according to the actual scheduling scheme.
  • the scheduling policy may be sent to the mobile device 2900 according to an actual scheduling scheme.
  • the scheduling policy may include, but is not limited to, one or more of a supply and demand density push policy, a hotspot feature push policy, a statistical feature push policy, an order push policy, an order adjustment policy, or a prompt information push policy.
  • rewards, subsidies, offers, etc. may be awarded to the service provider while the scheduling policy is being sent, thereby enabling efficient scheduling of the service provider.
  • some intelligent search algorithms such as one or more of a genetic algorithm, an ant colony algorithm, etc.
  • the initial solution can be generated according to the above formula, and then the local part of the current solution is transformed to generate a new solution; then it is judged whether the new solution is better. If the new solution is better, replace the current solution with a new one. If the new solution is not better, the current solution is output.
  • the initial solution population is generated; the solutions in the population are crossed by two to generate a new solution, and the population size is doubled at this time; the adaptation function is determined, and the average value of the population is used. , the solution below the average is eliminated; determine the exit function, If a certain number of iterations is reached or the result converges, then exit, otherwise continue to generate a new solution.
  • step 1510 can be split into three steps: dividing the area for a predetermined range, determining the area to which the user belongs, and determining the distribution of users within the area.
  • a step of calculating a potential deal increment sum for a potential scheduling scenario within a predetermined range may be added between step 1530 and step 1540. This step can also be combined with step 1530 or step 1540 to become a step. Variations such as these are within the scope of the present application.
  • FIG. 16 is a schematic diagram of processing module 210, in accordance with some embodiments of the present application.
  • the processing module 210 may include one or more order information extraction modules 510, a user information extraction module 520, an environment information extraction module 530, an order distribution module 540, a scheduling module 550, a calculation module 570, and the like.
  • the scheduling policy calculation unit 579 can include an order and user matching subunit 5798 and other units (not shown in FIG. 16).
  • one or more of the order information extraction module 510, the user information extraction module 520, the environment information extraction module 530, the order distribution module 540, and the scheduling module 550 may be respectively associated with the calculation module 570 or the scheduling policy calculation unit. 579 connected.
  • the connection manner between each module and the unit may be wired or wireless, and information communication between each module and the unit may be performed.
  • the order information extraction module 510 can acquire order information.
  • the environment information extraction module 530 can obtain environment information.
  • the order allocation module 540 can assign an order to be assigned to the user.
  • the scheduling module 550 can send a scheduling policy to the user. The related content is described in detail in FIG. 5, and details are not described herein again.
  • the user information extraction module 520 can acquire user information.
  • the user information may include, but is not limited to, acquiring vehicle state information corresponding to the user based on the onboard diagnostic system (see FIG. 5 for a more detailed description) and the like.
  • the vehicle state information may include, but is not limited to, vehicle speed, vehicle acceleration, position information, amount of remaining energy (eg, remaining oil amount, remaining power), One or more of energy consumption, energy consumption rate, vehicle operating state (eg, engine operating state, tank operating state, brake system operating state, vehicle stability system operating state, instrument system operating state safety system operating state, etc.) Combination of species.
  • the vehicle status information may be one or more of historical data, real-time data, predicted data, and the like.
  • the onboard diagnostic system can be part of a user terminal or can be relatively independent of the user terminal.
  • the onboard diagnostic system can be replaced by any system that can perform the same function, or can be replaced by a combination of multiple systems.
  • the onboard diagnostic system can be replaced by a combination of a speed detection system, a positioning system, and a vehicle inspection system.
  • the order-to-user matching sub-unit 5798 can select at least one user who can accept the order for the order, or match the order information with at least one vehicle status information of the user who can accept the order to obtain a matching result.
  • the user may be a consumer or a service provider.
  • the user may be a driver (on behalf of a service provider), and the order-to-user matching sub-unit 5798 may complete the match between the passenger order and the driver.
  • the user may be a vehicle owner (on behalf of a consumer), and the order and user matching subunit 5798 may complete the matching of the service site order with the owner.
  • the user may be a passenger on board the vehicle (representing the consumer), and the order-to-user matching sub-unit 5798 may complete the match between the restaurant order and the passenger.
  • each module or unit is not essential, and each module or unit may be implemented by one or more components, and the function of each module or unit is not limited thereto.
  • Each of the above modules or units may be added or deleted according to a specific implementation scenario or needs.
  • the order matches the user
  • the subunit 5798 can be divided into two units for respectively selecting at least one user who can accept the order for the order and matching the order information with the vehicle status information of at least one user who can accept the order to obtain a matching result. Variations such as these are within the scope of the present application.
  • FIG. 17 is a schematic diagram of a network environment of a capacity scheduling system.
  • the network environment of the capacity dispatch system may include a vehicle dispatch device 1710, one or more onboard diagnostic modules 1720, and one or more user terminals 1730.
  • the vehicle scheduling device 1710 can analyze the collected information to generate a result and transmit the generated result.
  • the onboard diagnostic module 1720 can obtain vehicle status information of the user.
  • the vehicle status information may include, but is not limited to, vehicle speed, vehicle acceleration, position information, amount of remaining energy, energy consumption, energy consumption rate, vehicle operating status (eg, engine operating status, tank operating status, braking system operating status, vehicle body) A combination of one or more of a stable system operating state, an instrument system operating state safety system operating state, and the like.
  • vehicle status information may be one or more of historical data, real-time data, predicted data, and the like.
  • the onboard diagnostic module 1720 can be part of the user terminal or relatively independent of the user terminal. The onboard diagnostic module 1720 can be replaced by any one or a combination of systems that can perform the same function.
  • the onboard diagnostic module 1720 can be replaced by a combination of a speed detection system, a positioning system, and a vehicle inspection system.
  • the user terminal 1730 can transmit vehicle status information, receive order allocation information, scheduling policies, and the like.
  • the user terminal 1730 may include, 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, an in-vehicle computer, a television, a smart wearable device, and the like.
  • PDA personal digital assistant
  • the connections between the various modules or units in the Figure can be wired or wireless.
  • the vehicle scheduling device 1710 can send the scheduling policy or order allocation information directly to the user terminal 1730. In some embodiments, the vehicle scheduling device 1710 can transmit scheduling policy or order allocation information to the onboard diagnostic module 1720, which in turn transmits the scheduling policy or order allocation information to the user terminal 1730.
  • each of the above modules or units is not essential, and each module or unit may be implemented by one or more components, and the function of each module or unit is not limited thereto.
  • Each of the above modules or units may be added or deleted according to a specific implementation scenario or needs.
  • FIG. 18 is an exemplary flow diagram of a capacity scheduling method based on an onboard diagnostic system.
  • order information can be obtained.
  • the acquisition of the order information can be performed by the order extraction module 510.
  • the order can be a historical order, a real-time order, an appointment order, a forecast order.
  • FIG. 5 For a more detailed description of the order information, reference may be made to FIG. 5, and details are not described herein again.
  • the order information may include, but is not limited to, an order delivery time, an order number, a departure place, a destination, a departure time, an arrival time, a time to wait, a number of passengers, a willingness to carpool, a selected vehicle type, a selected service type (for example, , taxi, express train, special train, ride, bus, car rental, driver, etc.), whether to carry baggage, the amount of baggage, whether to bring pets, mileage, price, consumer fare increase, service party price adjustment, system price adjustment, red envelope use Conditions, payment methods (such as cash payment, credit card payment, online payment, remittance payment, etc.), order completion status, service provider selection order status, consumer sent order status, etc., or any combination of the above information.
  • payment methods such as cash payment, credit card payment, online payment, remittance payment, etc.
  • order completion status service provider selection order status, consumer sent order status, etc., or any combination of the above information.
  • the order information may also include other information related to the order, such as service requester basic information (such as gender, nickname, contact information, hardware address, etc.) and other information not controlled by the consumer or the servant, or Refers to temporary/bursty information.
  • service requester basic information such as gender, nickname, contact information, hardware address, etc.
  • other information including but not limited to weather conditions, environmental conditions, road conditions (such as due to safety or road operations, etc.) Roads, traffic conditions, etc., or any combination of the above information.
  • the method of selection may be random selection or selection according to certain indicators.
  • the indicator may include, but is not limited to, the distance between the user and the departure place in the order, the travel time between the user and the departure place in the order, the expected income of the order, the direction of the order destination, and the expected direction of travel of the user.
  • the user habits/likes may include, but are not limited to, a service requester's preference for a departure place, a destination, a departure time, a service requester's preference for the user, a waiting time acceptable to the service requester, and a service requester for the fight.
  • service requester's preference for vehicle type eg, aircraft, train, ship, subway, taxi, bus, motorcycle, bicycle, walk, etc.
  • service requester for business type eg, taxi , express train, special car, ride, bus, car rental, driver's preference, service requester's preference for vehicle model, user's preference for departure place, destination, departure time, user's preference for driving route, user's
  • the status of the at least one user who can accept the order may be an idle state, a status of the order service to be completed, a state of carpooling, or other status that can accept the order.
  • At least one user whose location is less than the preset threshold from the place of departure of the order may be acquired, or at least one user of the area where the place of departure of the order is located may also be acquired.
  • the area where the order origination is located may be an area within a range from the departure point of the order that is less than a preset threshold, or may be a geographical area to which the order origination belongs.
  • the division of the geographic area to which the order originates may be based on one or more of an administrative area (eg, Haidian District, Chaoyang District, etc.), latitude and longitude, business district, building, street name, and the like.
  • the status information of the vehicle may include, but is not limited to, vehicle speed, vehicle acceleration, position information, amount of remaining energy, energy consumption, energy consumption rate, vehicle operating status (eg, engine operating status, tank operating status) , brake system operating state, vehicle stability system operating state, instrument system operating state safety system One or a combination of several of the operating states, etc.).
  • the energy source may be gasoline, kerosene, diesel, natural gas, liquefied petroleum gas, alcohol fuel, dimethyl ether, hydrogen fuel, biomass fuel, battery, solar energy, and the like.
  • the vehicle status information may be one or more of historical data, real-time data, predicted data, and the like.
  • the onboard diagnostic system can be part of a user terminal or can be relatively independent of the user terminal.
  • the onboard diagnostic system can be replaced by any system that can perform the same function, or can be replaced by a combination of multiple systems.
  • the onboard diagnostic system can be replaced by a combination of a speed detection system, a positioning system, and a vehicle inspection system.
  • the order information can be matched with at least one vehicle status information of the user who can accept the order to obtain a matching result.
  • This matching process can be implemented by the order and user matching sub-unit 5798.
  • the service requester's demand information for example, departure time, departure place, destination, travel distance, willingness to wait time, etc.
  • the matching algorithm calculates the matching degree between the service provider and the service requester, and matches the service provider with the service requester according to the matching degree.
  • the matching indicator may not be limited to the vehicle state information, but may also be other matching indicators, for example, the distance between the user and the departure place in the order, and between the user and the departure place in the order.
  • the user habits/likes may include, but are not limited to, a service requester's preference for a departure place, a destination, a departure time, a service requester's preference for the user, a waiting time acceptable to the service requester, and a service requester for the fight.
  • service requester's preference for vehicle type eg, aircraft, train, ship, subway, taxi, bus, motorcycle, bicycle, walk, etc.
  • service requester for business type eg, taxi , express train, special car, ride, bus, car rental, driver's preference, service requester's preference for vehicle model, user's preference for departure place, destination, departure time, user's preference for driving route, user's
  • the environmental information can be packaged This includes, but is not limited to, a combination of one or more of weather information, traffic information, event information, geographic information, and the like.
  • the traffic information may include, but is not limited to, a location of the road, whether the road is unobstructed, a speed limit condition, a combination of one or more of sudden situations (eg, traffic accidents, maintenance construction, traffic police control, etc.).
  • a scheduling policy may be sent to the user corresponding to the better matching result.
  • This transmission process can be implemented by the scheduling module 550 or the order allocation module 540.
  • the preferred matching result may be an optimal matching result, a sub-optimal matching result, or other matching result that satisfies the actual situation requirement.
  • the scheduling policy may include, but is not limited to, a combination of one or more of a supply and demand density push policy, a hotspot feature push policy, a statistical feature push policy, an order push policy, an order adjustment policy, or a prompt information push policy (detailed description See Figure 3).
  • the order pushing policy may include but is not limited to one or more of the origin, destination, service requester basic information (such as gender, nickname, contact information, hardware address, etc.), environmental information, and the like of the order. combination.
  • the scheduling policy can be sent to mobile device 2900.
  • a step of order allocation can be added after step 1830. Specifically, after the optimal allocation is obtained, the order is allocated to the user corresponding to the better matching result. Then, proceed to step 1840, and send a scheduling policy to the user corresponding to the better matching result. It will be appreciated that the order assignment step may also be performed concurrently with step 1840 or after step 1840.
  • the processing module 210 may perform step 1830 and step 1840 again to select other users to match the order. Variations such as these are within the scope of the present application.
  • FIG. 19 is based on the operation of the onboard diagnostic system.
  • the matching process shown in Figure 19 can be implemented by the order and user matching sub-unit 5798.
  • the distance between the departure point and the destination of the order description can be calculated based on the order information.
  • the distance between the place of departure and the destination may be the shortest of the plurality of routes, the longest of the plurality of routes, The average of various route routes, etc.
  • the impact of environmental factors on the distance calculation may also be considered when calculating the distance between the departure point and the destination.
  • the environmental factors may include, but are not limited to, one or a combination of weather information, traffic information, event information, geographic information, and the like.
  • the traffic information may include, but is not limited to, a location of the road, whether the road is unobstructed, a speed limit condition, a combination of one or more of sudden situations (eg, traffic accidents, maintenance construction, traffic police control, etc.).
  • the amount of energy required can be calculated based on the calculated distance and acquired vehicle status information (see step 1820). In some embodiments, a required amount of energy can be calculated for all users, or a required amount of energy can be calculated for one user. In some embodiments, the user may be categorized, one amount of energy required for each type of user, or other calculations.
  • step 1930 it may be determined whether the amount of remaining energy of the vehicle is greater than or equal to the amount of energy required. If the remaining energy amount of the vehicle is less than the required energy amount, proceed to step 1940 to remove the corresponding user of the vehicle from at least one user list that can accept the order; if the remaining energy amount of the vehicle is greater than or equal to the required amount The amount of energy proceeds to step 1950.
  • the distance information between the user and the origin of the order description can be obtained.
  • the distance information may include, but is not limited to, a combination of one or more of a distance between the user and the departure place of the order description, a time at which the user arrives at the departure place of the order description, environmental information, and the like.
  • a better match result can be determined based on the distance information.
  • determining the preferred match result may be based on one or more of a distance between the user and the departure location of the order description, a time at which the user arrived at the departure location of the order description, and the like. For example, you can select the user with the closest distance between the user and the origin of the order description as the preferred user. Match the result. For another example, the user with the shortest time at the place of departure of the order description can be selected as the better matching result.
  • the matching degrees of multiple possible matches can be calculated and the possible matches ranked according to the degree of matching.
  • determining the degree of match may be based on the distance between the user and the departure location of the order description, the time at which the user arrived at the departure location of the order description, the distance information, the vehicle status information, the expected revenue of the order, and whether the order destination direction is The user's expected driving direction is consistent, the service requester's preference for the user, the waiting time acceptable to the service requester, the service requester's preference for the order, and the service requester's type of vehicle (eg, aircraft, train, ship, subway) , taxi, bus, motorcycle, bicycle, walking, etc.
  • vehicle eg, aircraft, train, ship, subway
  • service requesters' preferences for business types eg taxis, express trains, special cars, rides, buses, car rentals, drivers
  • service requesters Preference for vehicle model, user's preference for departure place, destination, departure time, user's preference for driving route, user's working time, user's refresh rate, user's grabbing characteristics, user's grab amount, grab a group of one or several of a single success amount, a volume, a success rate, a turnover rate, and the like Hehe.
  • 20 is a schematic diagram of processing module 210, in accordance with some embodiments of the present application.
  • the processing module 210 may include one or more order information extraction modules 510, a user information extraction module 520, an environment information extraction module 530, an order distribution module 540, a scheduling module 550, a calculation module 570, and the like.
  • the calculation module 570 may include one or more area information calculation units 571, a feature index calculation unit 573, and an order group calculation unit 575 and other units (not shown in FIG. 20).
  • the area information calculation unit 571 may include a flag location determining sub-unit 5713 and other units (not shown in FIG. 20).
  • the feature index calculation unit 573 may include an order feature calculation sub-unit 5732 and other units (not shown in FIG. 20).
  • One or more of the single allocation module 540 and the scheduling module 550 can be coupled to the computing module 570, respectively.
  • the connection manner between each module and the unit may be wired or wireless, and information communication between each module and the unit may be performed.
  • the order information extraction module 510 can acquire order information.
  • the user information extraction module 520 can acquire user information.
  • the environment information extraction module 530 can obtain environment information.
  • the order allocation module 540 can assign an order to be assigned to the user.
  • the scheduling module 550 can send a scheduling policy to the user. The related content is described in detail in FIG. 5, and details are not described herein again.
  • the flag location determining sub-unit 5713 can determine the determination of the landmark location corresponding to the particular location.
  • the landmark location may be one location or multiple locations.
  • the landmark location may be a coordinate location (eg, longitude 109.3, latitude 56.7), a particular building (eg, Tiananmen Square People's Hero Monument), a specific range of areas (eg, Haidian District), etc. Or a variety.
  • the location of the logo may be pre-set or calculated (eg, determining the number of orders over a certain threshold location as the landmark location).
  • the method used in the determination of the landmark location may be a quantitative method, or a qualitative method.
  • the order feature calculation sub-unit 5732 can calculate the feature parameters of the order.
  • the order can be an individual feature of an order, or a statistical feature of multiple orders (eg, a time period or all orders for an area).
  • the order may be one or more of a historical order, a real-time order, an appointment order, a forecast order, and the like.
  • the characteristic parameters of the order include, but are not limited to, the total number of orders, departure time, average waiting time, arrival time, transaction price, average price, transaction rate, and the like.
  • the order group calculation unit 575 can group the orders.
  • the packet may be a manually specified packet or a packet calculated based on a certain rule.
  • orders with one or more of the same characteristic parameters eg, departure time, region of interest
  • the feature parameter for grouping may be the result of the calculation by the order group calculation unit 575, the result calculated by the feature index calculation unit 452, or directly obtained from the order information without calculation.
  • each module or unit is not required, and each module or unit can be implemented by one or more components, each of which is The function is not limited to this.
  • Each of the above modules or units may be added or deleted according to a specific implementation scenario or needs.
  • part of the functions of the flag location determining sub-unit 5713 may be integrated in the order feature calculation sub-unit 5732 and the user feature calculation sub-unit (not shown in FIG. 20), respectively, for determining the location of the mark corresponding to the order and the user.
  • the order grouping unit 575 and the order feature calculation sub-unit 5732 can be integrated in one sub-unit while calculating the order grouping and order feature parameters.
  • 21 is an exemplary flow diagram of a statistical information based capacity scheduling system, in accordance with some embodiments of the present application.
  • one or more historical order information for a region whose departure address is near a particular location may be obtained. This step can be performed by the order information acquisition module 510.
  • the area near the specific location may be an area to which the specific location belongs after being determined according to a certain area division method.
  • the area dividing method may be a combination of one or more of a mesh division method, a cluster division method, a specific rule division method, and the like (see FIG. 7-A, FIG. 7-B for details).
  • Figure 7-C The area near the particular location may be an area within a certain threshold range. For example, it may be an area formed by a position where the distance from the specific position is less than a certain threshold (for example, 100 meters, 1000 meters).
  • the area near the specific position may also be an area formed by a position within a certain range (for example, more than 10 meters and less than 100 meters) from the specific position.
  • the plurality of historical orders may be historical orders within a continuous time period. For example, a historical order for the last N days.
  • the historical order may also be a historical order within a discrete time period. For example, a historical order for each Monday in the last N days.
  • the plurality of historical orders may also be historical orders that satisfy certain screening criteria (eg, order type, order transaction price, order destination).
  • all historical orders within a given time period may be acquired first, and then the distance from the departure location to the particular location may be determined to be less than Multiple historical orders with a specific threshold (for example, 10 kilometers).
  • all historical orders for the administrative area at the particular location may be obtained first, and then multiple orders for all Mondays from 9:00 am to 13:00 on the same day may be selected.
  • a flag location corresponding to the historical order can be determined.
  • the determination of the landmark location may be performed by the landmark location determination sub-unit 5713.
  • the location of the logo is determined, may be determined based on the departure location of the order, may be determined based on the destination of the order, or may be determined based on other locations associated with the order (eg, intermediate locations).
  • a flag location or multiple landmark locations can be determined for an order.
  • multiple landmark locations are determined by pre-planning. For example, by designing a number of landmark locations such as Haidian District, Dongcheng District, and Guomao by hand. In some embodiments, multiple landmark locations may be determined based on the departure and destination addresses of all historical orders. For example, if you want to select 200 landmark locations in the end, you can keep the digits after the decimal point of the latitude and longitude of the departure address and destination address in the order data of the last N days, and then select the coordinates of 200 latitude and longitude. These 200 latitude and longitude coordinates or buildings near the latitude and longitude coordinates are used as landmarks. In some embodiments, after determining a plurality of landmark locations, the distance between each of the landmark locations and the destination address of each historical order is separately calculated, and then the marked location corresponding to the shortest distance is used as the landmark location of the order.
  • one or more historical orders may be grouped based on the landmark location and the order characteristics.
  • This grouping process can be implemented by the order group calculation unit 575.
  • the order feature may be a time characteristic of the order (eg, departure time, completion time, release time, scheduled departure time, actual departure time, waiting time), or other characteristics of the order (eg, order type, order transaction price), etc. One or more of them.
  • orders within the same group may have one or more identical features. Orders between different groups can have different characteristics or have the same characteristics.
  • one or more historical orders may be grouped according to the landmark location and departure time of the historical order. Orders in the group occur within the same time period and correspond to the same landmark location. For example, take it from 15:00 to 16:00 All historical orders for Tiananmen are grouped together in one group. For another example, all historical orders for the type of taxi going to Tiananmen are grouped into one group from 15:00 to 16:00.
  • statistics for each group of historical orders can be calculated.
  • the calculation of the statistical data in this step can be performed by the feature index calculation unit 573. More specifically, it can be performed by the order feature calculation sub-unit 5732.
  • the statistical data may be one statistical data or multiple statistical data.
  • the statistics include, but are not limited to, the total number of orders, the average response time of the order, the total number of orders originators, the average time interval for order delivery, and the order turnover rate.
  • one or more statistics for one or more sets of historical orders may be sent for a particular condition.
  • This transmission process can be performed by the scheduling module 550.
  • the specific condition may be one or more of a specific time period (eg, current time period), a specific location (eg, current location), a particular region (eg, current region), a user's selection, and the like.
  • the one or more statistical data transmitted may be one or more based on one or more statistical data selected by the user, one or more statistical data specified by the processing module 210, and the like.
  • the one or more statistical data sent may be all or part of the statistical data calculated in step 2107. For example, only the statistics of the top K group historical orders with the largest total number of orders in the current time period are sent.
  • the form of the transmitted data may be any one or a combination of text form, image form (dynamic form and static form) or voice form.
  • statistics of order types eg, express trains, taxis, cars
  • a current order eg, Zhongguancun
  • the current time period eg, 13:00-15:00 on Monday
  • data is sent to passengers for passengers to choose between different order types.
  • the demand information for different regions within the current time period may be sent to the driver for the driver to make a selection of where to provide the capacity service.
  • statistics for the total number of orders in a historical order within a particular region may be sent to the driver for the driver to select the order area.
  • the mobile device 2900 shown in FIG. 29 can receive one or more statistical data.
  • FIG. 22 is an exemplary flow diagram of a statistical information based capacity scheduling system, in accordance with some embodiments of the present application.
  • step 2201 one or more areas where the departure address is in the vicinity of the specific location may be obtained.
  • Information about real-time orders This step can be performed by the order information acquisition module 510.
  • the real-time order may be a real-time order that satisfies certain screening conditions (eg, unanswered, no pets).
  • all orders within a region near a particular location may be acquired first, and then an unanswered order is selected therefrom.
  • all real-time orders that meet the screening criteria may be obtained first, and then an order for the departure location of the order and the driver's location within a certain threshold (eg, 1 kilometer) may be selected.
  • a landmark location corresponding to the real-time order can be determined.
  • the determination of the landmark location may be performed by the landmark location determination sub-unit 5713.
  • the location of the mark please refer to FIG. 21, and details are not described herein again.
  • one or more real-time orders can be grouped based on the location of the flag.
  • This grouping process can be implemented by the order group calculation unit 575.
  • the order group may also reference other features, which may include, but are not limited to, time characteristics of the order (eg, departure time, release time, scheduled departure time, tolerable waiting time), order A combination of one or more of additional information features (eg, order type, tip), user preferences (eg, order passengers' preferences for driver driving age), and the like.
  • time characteristics of the order eg, departure time, release time, scheduled departure time, tolerable waiting time
  • order A combination of one or more of additional information features eg, order type, tip
  • user preferences eg, order passengers' preferences for driver driving age
  • step 2207 statistics for each group of real-time orders can be calculated.
  • the calculation of the statistical data in this step can be performed by the feature index calculation unit 573. More specifically, it can be performed by the order feature calculation sub-unit 5732.
  • the statistical feature calculation please refer to FIG. 21 and FIG. 20, and details are not described herein again.
  • one or more sets of real-time orders are sent for a particular condition.
  • the sending process can be performed by order allocation module 540 and/or scheduling module 550.
  • the order allocation module 540 can send specific order information to the driver
  • the scheduling module 550 can send statistical information of the real-time order to the driver.
  • the information is sent to the mobile device 2900 (see Figure 29 for details).
  • the specific condition may be a specific time period (eg, current time period), a specific location (eg, current location), a specific region (eg, current region) Domain), user selection, etc.
  • the processing module 210 may transmit the total number of real-time unanswered orders and order information for the landmark location.
  • step 2103 may be omitted, and the flag information is included in the order information acquired in step 2101.
  • step of receiving the user selection may be added before step 2109 or step 2209, and then the data is transmitted based on the acquired user selection information.
  • FIG. 23 is a schematic diagram of a processing module 210, in accordance with some embodiments of the present application.
  • the processing module 210 may include one or more order information extraction modules 510, a user information extraction module 520, an environment information extraction module 530, an order distribution module 540, a scheduling module 550, a calculation module 570, and the like.
  • the calculation module 570 can include a region information calculation unit 571, a feature index calculation unit 573, and other units (not shown in FIG. 23).
  • the area information calculation unit 571 may include an area division sub-unit 5711 and other sub-units (not shown in FIG. 23).
  • the feature index calculation unit 573 may include an order feature calculation sub-unit 5732, a user feature calculation sub-unit 5734, a supply and demand feature calculation sub-unit 5733, and other sub-units (not shown in FIG. 23).
  • the order information extraction module 510 can acquire order information.
  • the user information extraction module 520 can acquire user information.
  • the environment information extraction module 530 can obtain environment information.
  • the order allocation module 540 can assign an order to be assigned to the user.
  • the scheduling module 550 can send a scheduling policy to the user.
  • the area dividing sub-unit 5711 can perform the division of the area.
  • the area division method may include a combination of one or more of a division method according to a grid, a division method according to a cluster, a division method according to a specific rule (for example, an administrative area), and the like (for details, see FIG. 7-A, FIG. 7-B, Figure 7-C).
  • the order feature calculation sub-unit 5732 can calculate the feature parameters of the order.
  • the order may be a real-time order, a historical order, an appointment order, a forecast order, and the like.
  • the feature parameters include, but are not limited to, the number of real-time orders in the region, the number of historical orders, the third number of potential order originators, the preferences of potential order originators, and the number of real-time orders, historical orders, and potential orders.
  • the number of parties determines the first amount of order demand, etc.
  • the supply and demand feature calculation sub-unit 5733 can calculate the supply and demand characteristic index of the area.
  • the supply and demand characteristic indicators may include real-time supply and demand characteristic indicators, historical supply and demand characteristic indicators, and forecast supply and demand characteristic indicators.
  • the supply and demand feature can be expressed as the ratio of the quantity of orders to the number of service providers, expressed by order density, or by other indicators that reflect the relationship between supply and demand.
  • User feature calculation sub-unit 5734 can calculate the feature parameters of the user.
  • the feature parameters may include, but are not limited to, one or more of the number of static potential order recipients in the area, the number of dynamic potential order recipients in the area, the second number of potential order recipients, and the like.
  • each module or unit is not essential, and each module or unit may be implemented by one or more components, and the function of each module or unit is not limited thereto.
  • Each of the above modules or units may be added or deleted according to a specific implementation scenario or needs.
  • one or more storage units may be integrated in the partitioning subunit 5711, the order feature calculation subunit 5732, the supply and demand feature calculation subunit 5733, and the user feature calculation subunit 5734 for storing acquired data, intermediate data, and/or Calculation results.
  • 24 is an exemplary flow diagram of a capacity dispatch system based on supply and demand density information, in accordance with some embodiments of the present application.
  • the division of the area may be performed according to a certain area division method.
  • the area division can be performed by the area information calculation unit 571. Specifically, it can be performed by the area dividing sub-unit 5711.
  • the area dividing method may include a method of dividing according to a mesh, a dividing method according to a cluster, a dividing method according to a specific rule (for example, an administrative area, a business circle information), and the like (for a detailed description, see FIG. 7). -A, Figure 7-B, Figure 7-C).
  • the area division may be one division, or multiple divisions (for example, subdivision of regions based on the result of the previous division).
  • the zoning can be fixed or dynamic (eg, real-time clustering based on order or user conditions to get the results of zoning).
  • order demand information within a particular area can be obtained.
  • the order requirement information may be one or more of historical order information, real-time order information, potential order information, predicted order information, and the like.
  • a feature parameter of a potential order demand within a particular region may be calculated based on the acquired order demand information.
  • the calculation of the feature parameters can be performed by the order feature calculation sub-unit 5732.
  • the feature parameters of the order requirement may also be directly obtained by the order information acquisition unit 510.
  • the characteristic parameters of the order requirement include, but are not limited to, the number of real-time orders in the area, the number of historical orders, the third quantity of the potential order initiator, the preference of the potential order originator, and the number of real-time orders, the number of historical orders, and One or more of the first number of order requirements determined by the number of potential order originators.
  • the calculation of the feature parameters can be performed by the order feature calculation sub-unit 5732.
  • a first quantity K 1 of order requirements within the area may be calculated based on the number of real-time orders within a particular area, the number of historical orders, and the third number of potential order originators.
  • the specific calculation formula is as follows:
  • X may be the number of real-time orders in the area
  • P may be the third number of potential order initiators in the area
  • O pre may be the historical order quantity of the area
  • ⁇ and ⁇ are coefficients.
  • the real-time order number X in the area may be real-time order data processed based on some operational rule.
  • X can be the current number of real-time orders, or the number of orders currently tipped.
  • the third number P of potential order originators in the area may be the actual number of demand parties potentially having service needs, the number of online or offline service terminals (eg, taxi software passenger terminals), from The number of other terminals that are obtained by a third party, such as social software, payment software, obtained by the service provider's terminal location software (for example, GPS), or the base station location of the service provider's terminal access interface. The amount of information obtained, etc.
  • the historical order quantity O pre of the area may be a historical order quantity of all corresponding time periods, or a historical order quantity processed according to a certain operation rule, and the like.
  • the historical order quantity O pre of the area may be the actual number of orders for the period of the previous day, the average number of actual orders for the period before N days, or the total number of actual orders for the period before N days, and the like.
  • the coefficients ⁇ , ⁇ can be any value.
  • the values of the coefficients ⁇ and ⁇ may be equal or unequal. For example, when both ⁇ and ⁇ have a value of 1, K 1 can reflect the degree of service demand.
  • the coefficient ⁇ can be a value between 0.4 and 0.6, and the coefficient ⁇ can be 1.
  • the values of the coefficients ⁇ and ⁇ can be kept constant or dynamically adjusted. For example, the values of the coefficients ⁇ , ⁇ can be continuously adjusted by approximating the value of K 1 to the actual service demand. Finally, the values of the coefficients ⁇ and ⁇ can make the value of K 1 closer to the real service demand.
  • the first amount of order demand is positively correlated with the passenger car demand. For example, when ⁇ and ⁇ take a certain value, the larger K 1 represents the higher demand for the passenger car.
  • order recipient information within a particular area may be obtained.
  • the order recipient information may be real-time order receiver information or historical order receiver information.
  • the order recipient information may include, but is not limited to, one or more of order information, user information, environmental information (eg, road condition information), and the like related to the order recipient.
  • a feature parameter of the potential order recipient may be calculated based on the acquired order recipient information.
  • the feature parameters may include, but are not limited to, one or more of the number of static potential order recipients in the area, the number of dynamic potential order recipients in the area, the second number of potential order recipients, and the like.
  • the calculation of the feature parameters can be performed by the user feature calculation sub-unit 5734.
  • the number of static potential order recipients may refer to at some time The number of receivers that are stationary in the interval.
  • the number of static potential order recipients may be the number of available vehicles that are stationary waiting for passengers.
  • the stationary motion may be a shorter distance (eg, 500 meters) or no movement over a longer period of time (eg, 5 minutes).
  • the number of order recipients that are moving during a certain time period may be the number of available vehicles in motion.
  • the number of dynamic potential order recipients can be obtained in a variety of ways.
  • the number of potential order recipients currently exercising in the area may be predicted based on the history of the area or the road traffic congestion condition of the current time period.
  • the road traffic congestion condition of the historical or current time period can be obtained by other road condition information systems.
  • the road traffic congestion condition of the historical or current time period may be acquired by the environment information acquisition module 530.
  • the historical period may be a corresponding period of the previous N days.
  • the historical period may also be a time period corresponding to N days having the same feature. For example, if the current time period is Monday 8:00-9:00, you can select 8:00-9:00 on the previous N Mondays as the historical time.
  • 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.
  • 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 information for the N historical time periods may have the same impact on the prediction of the number of potential order recipients in the area.
  • the information of the N historical periods may have different effects on the prediction or estimation of the road traffic congestion condition of the historical or current time period.
  • the information of the historical time period that is relatively close to the current time period may have more influence on the prediction of the number of potential order receivers in the area, and the historical time period is relatively distant from the current time interval.
  • the information can have less impact on the number of potential order recipients in the area.
  • the N In the historical period the historical period with one or more of the same characteristics as the current time period (such as the same or similar weather, the same or similar special road conditions (eg, road repair, road closure, limit line, etc.) information in the area
  • the forecast of the number of potential order recipients has a greater impact.
  • the number of potential potential order recipients in the time period may be predicted according to the number of potential order recipients in the historical period movement in the area, the congestion status of the historical period road surface, and the current period road congestion condition.
  • the number of dynamic potential order recipients D pre in the current time period can be expressed by the following formula:
  • D pre can also be calculated in other ways, or obtained in the form of a comparison lookup table (for example, the degree of congestion of a road surface corresponds to a certain congestion coefficient). It is within the scope of this description to reflect the relative relationship between Dpre and the road surface to reflect the number of dynamic potential service providers.
  • the second number of potential order recipients may be expressed as a function of the number of static potential order recipients in the area and the number of dynamic potential order recipients within the area.
  • K 2 in equation (17) can be used to represent the second number of potential order recipients:
  • the number of available vehicles can be used in the region D h1 historical time period of the estimated number of potential dynamic order receiving side D pre, and accordingly the number of potential rough estimate of the second order receiving side K 2.
  • the number of available vehicles D h1 in the historical period of the region and the number of dynamic potential order recipients D pre can be expressed by equation (18):
  • the order supply and demand density within the area may be determined based on the feature parameters of the order demand and the characteristic parameters of the potential order recipient.
  • the calculation of the order supply and demand density may be performed by the supply and demand feature calculation sub-unit 5733.
  • the order supply and demand density may be expressed as a ratio of the first quantity of the order demand to the second quantity of the potential order recipient.
  • the order supply and demand density K can be expressed by the formula (19):
  • the order supply and demand density K can be expressed as:
  • the order supply and demand density sending object may be any information demanding end device (120 and/or 140), or may be a database 130, a storage module 220, or the like.
  • step 2405 can be omitted, and the information of the area division can be included in the process of acquiring the order information.
  • the environment information obtaining step may be added before step 2425, and environment information such as road conditions related to the order information may be acquired.
  • the calculation module 570 can include a region information calculation unit 571, and/or a scheduling policy calculation unit 579, and other units (not shown in FIG. 25).
  • the area information calculation unit 571 may include an area attribution determination sub-unit 5715 and other units (not shown in FIG. 25).
  • the scheduling policy calculation unit 579 can include a scheduling information lookup subunit 5797 and other units (not shown in FIG. 25).
  • One or more modules of the order allocation module 540 and the scheduling module 550 can be respectively connected to the computing module 570.
  • the connection manner between each module and the unit may be wired or wireless, and information communication between each module and the unit may be performed.
  • the area attribution judging sub-unit 5715 may determine an area to which the location information transmitted by the user belongs.
  • the user may be a service requester (eg, a passenger) or a service provider (eg, a driver).
  • the area to which the location information belongs may be an area within a range in which the distance from the location is less than a first preset threshold, or a geographic area to which the location information belongs.
  • the scheduling information lookup sub-unit 5797 can look up scheduling policies within the region for a preset period of time.
  • the information lookup source may include, but is not limited to, one or a combination of the database 130, the information source 160, the storage module 220, other storage devices, and the like.
  • the length of the preset time period may be fixed or may vary depending on the actual situation.
  • the area to which the scheduled scheduling policy belongs may be the area to which the location information is sent by the user, or the adjacent area of the area to which the location information is sent by the user.
  • the scheduling policy may include, but is not limited to, one or more of a supply and demand density push policy, a hotspot feature push policy, a statistical feature push policy, an order push policy, an order adjustment policy, or a prompt information push policy.
  • the statistical feature push policy may include, but is not limited to, one or a combination of order information, order interaction information, distribution information, environment information, and the like.
  • the order information may include, but is not limited to, a combination of one or a combination of the total number of orders, the time of placing an order, the place of departure, the destination, the departure time, the number of passengers, whether or not to carpool, presence or absence of luggage, and the like.
  • the order information may be one or more of real-time order information, reservation order information, historical order information, and the like.
  • the order interaction information, the distribution information, and the environment information may be one or more of historical data, real-time data, predicted data, and the like.
  • each of the above modules or units is not essential, and each module or unit may be implemented by one or more components, and the function of each module or unit is not limited thereto.
  • Each of the above modules or units may be added or deleted according to a specific implementation scenario or needs.
  • various modifications and changes in the form and details of the specific implementation modes and steps of the processing module may be performed without departing from this principle, and some simple deductions or replacements may be made. Certain adjustments, combinations or splits of the order of modules or units are made without creative effort, but such modifications and changes are still within the scope of the above description.
  • a prompt information generating unit may be added for generating prompt information.
  • the prompt information generating unit shown may be within the computing module 570 and may be external to the computing module 570.
  • the prompt information element may also be present in the user terminal.
  • a determination unit can be added. The determining unit may determine whether the total number of orders is less than a second preset threshold. If the total number of orders is less than the second preset threshold, the first prompt information is generated to prompt the user that the number of orders in the area is small; if the total number of orders is greater than the second preset threshold, the second prompt information is generated to prompt the user to Regional order resources are abundant.
  • the determining unit may further determine whether the total number of orders in the area is greater than a third preset threshold. If the total number of orders is greater than a third preset threshold, the scheduling module 550 performs a step of transmitting a scheduling policy to the user terminal; if the total number of orders is less than or equal to a third preset threshold, the scheduling module 550 does not perform a sending schedule. The step of the policy to the user terminal.
  • the determining unit may be within the computing module 570 or outside of the computing module 570. In addition, one or more units may be integrated in the same unit to implement the functionality of one or more units. Variations such as these are within the scope of the present application.
  • FIG. 26 is an exemplary flow diagram of a capacity scheduling method based on order interaction information and distribution information.
  • location information sent by the user can be obtained.
  • the process of obtaining the location information sent by the user may be implemented by the user information extraction module 520.
  • the user may be a service requester (eg, a passenger) or a service provider (eg, a driver).
  • the user may actively send location information to the scheduling engine 110 or send location information after receiving a transmission request from the scheduling engine 110.
  • the user may send location information to the scheduling engine 110 when needed, or authorize the scheduling engine 110 or other location information acquisition device to obtain user location information anytime, anywhere, regardless of whether the user has a need.
  • the user may periodically send location information or send location information from time to time. location information
  • the input mode can be actively input by the user or automatically obtained by the user terminal.
  • the manner in which the user actively inputs may include, but is not limited to, one or a combination of text input, picture input, voice input, video input, and somatosensory input.
  • the manner in which the user terminal automatically acquires may be obtained by using a positioning technology.
  • 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 A combination of one or more of positioning technology, Wi-Fi positioning technology, and the like.
  • the location information can be a location point or a location range.
  • an area to which the location information belongs may be determined based on the location information.
  • the process of determining the area to which the location information belongs may be implemented by the area attribution judging sub-unit 5715.
  • the area to which the location information belongs may be an area within a range in which the distance from the location is less than a first preset threshold, or a geographic area to which the location information belongs.
  • the first preset threshold may be fixed or changed according to actual conditions.
  • the first preset threshold may vary according to a geographic location, may vary according to a time period, or a combination of the two.
  • the first preset threshold for the location information to be Tiananmen may be less than the first preset threshold for the location information of the Yizhuang Industrial Park.
  • the first preset threshold for the peak hours of the commute may be less than the first preset threshold for the morning hours.
  • the first preset threshold for non-holiday may be less than the first preset threshold for the Chinese New Year.
  • the first preset threshold for a bad weather period or a significant activity period may be less than a first preset threshold for normal times.
  • the division of the geographical area to which the location information belongs may be based on one or more of an administrative area (eg, Haidian District, Chaoyang District, etc.), latitude and longitude, a business circle, a building, a street name, and the like. This application is not limited herein.
  • a scheduling policy within the preset time period within the region can be looked up.
  • the lookup process can be implemented by the dispatch information lookup subunit 5797.
  • the information lookup source may include, but is not limited to, one or a combination of the database 130, the information source 160, the storage module 220, other storage devices, and the like.
  • the length of the preset time period may be fixed or may vary according to actual conditions.
  • the area to which the scheduled scheduling policy belongs may be the area to which the location information is sent by the user, or may be the location information sent by the user. The adjacent area of the area to which it belongs.
  • the scheduling policy may include, but is not limited to, one or more of a supply and demand density push policy, a hotspot feature push policy, a statistical feature push policy, an order push policy, an order adjustment policy, or a prompt information push policy.
  • the statistical feature push policy may include, but is not limited to, one or a combination of order information, order interaction information, distribution information, environment information, and the like.
  • the order information may include, but is not limited to, a combination of one or a combination of the total number of orders, the time of placing an order, the place of departure, the destination, the departure time, the number of passengers, whether or not to carpool, presence or absence of luggage, and the like.
  • the order information may be one or more of real-time order information, reservation order information, historical order information, and the like.
  • the order interaction information may include, but is not limited to, the number of terminals robbing the same order, the number of orders sold, the number of unsold orders, the status of the order (for example, the order has been filled, the order is not filled, etc.), the order transaction rate, the competition probability of the order, etc.
  • the distribution information may include, but is not limited to, a combination of one or a combination of the total number of order service providers, the number of service providers that can be placed, the supply and demand density, the order density, the service provider density, and the like.
  • the status of the service provider that can receive the order can be empty, the order service will be completed, the car can be carpooled, or other orders can be received.
  • the order density and the service provider density may be the number of unit area areas (eg, 10 orders/m2, 20 drivers/km2), or the number of unit periods (eg, 10 orders/minute) Wait.
  • the environmental information may include, but is not limited to, one or a combination of weather information, traffic information, event information, geographic information, and the like.
  • the traffic information may include, but is not limited to, a location of the road, whether the road is unobstructed, a speed limit condition, a combination of one or more of sudden situations (eg, traffic accidents, maintenance construction, traffic police control, etc.).
  • the order interaction information, the distribution information, and the environment information may be one or more of historical data, real-time data, and predicted data.
  • a scheduling policy can be sent to the user terminal.
  • the process of transmitting the scheduling policy to the user terminal can be implemented by the scheduling module 550.
  • the sent scheduling policy may be a scheduling policy of the area to which the location information sent by the user belongs, a scheduling policy of the neighboring area of the area to which the user sends the location information, or a combination of the two scheduling policies.
  • the sent scheduling policy may be in the form of one or a combination of text, picture, video, audio, and the like.
  • the scheduling policy can be sent to the mobile device Standby 2900 (shown in Figure 29).
  • step 2630 can also include the step of generating prompt information. The total number of orders is compared to a second predetermined threshold.
  • the first prompt information is generated to prompt the user that the number of orders in the area is small; if the total number of orders is greater than the second preset threshold, the second prompt information is generated to prompt the user to Regional order resources are abundant.
  • the step of generating prompt information may also be implemented by a user terminal.
  • a determination step may be added to determine whether the total number of orders in the area is greater than a third predetermined threshold. If the total number of orders is greater than the third preset threshold, proceed to step 2640; if the total number of orders is less than or equal to the third preset threshold, then proceed to step 2640 to end the process.
  • the second preset threshold or the third preset threshold may be fixed or may change according to actual conditions.
  • the second preset threshold or the third preset threshold may vary according to a geographic location, may vary according to a time period, or may be a combination of the two.
  • the second preset threshold or the third preset threshold for the Tiananmen may be smaller than the second preset threshold or the third preset threshold for the Yizhuang Industrial Park.
  • the second preset threshold or the third preset threshold for the peak of the commuting period may be smaller than the second preset threshold or the third preset threshold for the morning hours.
  • the second preset threshold or the third preset threshold for normal time may be smaller than the second preset threshold or the third preset threshold for the Chinese New Year.
  • the second preset threshold or the third preset threshold for the bad weather period or the significant activity period may be smaller than the second preset threshold or the third preset threshold for the usual time.
  • the second predetermined threshold may be greater than the third predetermined threshold. Variations such as these are within the scope of the present application.
  • FIG. 27 is a schematic diagram of processing module 210, in accordance with some embodiments of the present application.
  • the processing module 210 may include one or more order information extraction modules 510, a user information extraction module 520, and environmental information extraction.
  • the calculation module 570 may include a feature index calculation unit 573, an order group calculation unit 575, and a prediction model calculation unit 577 and other units (not shown in FIG. 27).
  • the feature index calculation unit 573 may include an environment feature calculation sub-unit 5737, a supply and demand feature calculation sub-unit 5733, and other sub-units (not shown in FIG. 27).
  • the prediction model calculation unit 577 may include an order receiver prediction subunit 5775, an order quantity prediction subunit 5777, and other subunits (not shown in FIG. 27).
  • the order information extraction module 510 can acquire order information.
  • the user information extraction module 520 can acquire user information.
  • the environment information extraction module 530 can acquire user environment information.
  • the order allocation module 540 can assign an order to be assigned to the user.
  • the scheduling module 550 can send a scheduling policy to the user.
  • the supply and demand feature calculation sub-unit 5733 can calculate a supply and demand feature index.
  • the supply and demand characteristic indicator may include one or more of a real-time supply and demand characteristic indicator, a historical supply and demand characteristic indicator, and a predicted supply and demand characteristic indicator.
  • the supply and demand feature can be expressed as one or more of the ratio of the order quantity to the order receiver, the order density, or other indicators that reflect the supply and demand relationship.
  • the order quantity may be one or more of the real-time order quantity, the historical order quantity, the predicted order quantity, etc.; the order receiver quantity may be the real-time order receiver quantity, the historical order receiver One or more of the quantity, the number of predicted order recipients, and so on.
  • the order density may be one or more of an area density of an order, a time density of an order, a composite density of an area of an order, and time.
  • the environmental feature calculation sub-unit 5737 can calculate features of the environmental information.
  • the environmental information may be historical environmental information, real-time environmental information, and predicted environmental information.
  • the environmental information may be a combination of one or more of weather information, traffic information, event information, geographic information, and the like.
  • the order receiver prediction sub-unit 5775 can predict the number of order recipients.
  • the prediction may be based on a combination of one or more of historical data, real-time data, and predicted data. For example, a forecast of the number of order recipients is made based on the predicted order quantity.
  • the order quantity prediction sub-unit 5777 can predict the order quantity.
  • the prediction can be based on the calendar A combination of one or more of historical data, real-time data, and predicted data.
  • the order quantity can be predicted based on the order quantity of a specific area historical period.
  • the forecast of the order amount can be made based on the predicted weather conditions.
  • the order group calculation unit 575 can group the orders.
  • the packet may be a manually specified packet, or a packet calculated from a certain rule based on a certain rule.
  • orders with one or more of the same characteristic parameters may be grouped into one group.
  • each of the above modules or units is not essential, and each module or unit may be implemented by one or more components, and the function of each module or unit is not limited thereto.
  • Each of the above modules or units may be added or deleted according to a specific implementation scenario or needs.
  • FIG. 28 is an exemplary flow diagram of a capacity dispatch system based on supply and demand features, in accordance with some embodiments of the present application.
  • the order quantity at a particular time and in a particular area can be predicted.
  • the specific time and the specific area may be preset by the system, set based on user requirements, randomly set, or set based on specific conditions.
  • the time can be a time point or a time period.
  • the time may be a point in time and/or a time period that may be continuous, or a discrete point in time and/or time period.
  • the time standard can be a universal time standard or a time standard based on an order setting.
  • a specific area may be any spatial area, for example, may be a certain location point, or a certain orientation area.
  • a particular area may be a continuous location point and/or area, or a discrete location point and/or area.
  • the shape and size of a particular area are not limited.
  • the specific time may be that the order quantity feature is a set condition, and the duration in which the order quantity is relatively stable is set to a specific time.
  • the order quantity for predicting the specific time and area may be a prediction that satisfies a certain set condition.
  • the predicted setting conditions may include, but are not limited to, prediction based on the classification of the order, prediction based on the relevant statistical data of the order, and the like.
  • the classification of the order can be a classification that satisfies a certain set condition.
  • the classification setting condition may be one or more based on order statistics of a specific area and a specific time (for example, based on an order type), or based on user's data (eg, user's preference), and the like. combination.
  • the order type may be an order time type based on time, for example, morning order, noon order, late night order, and the like.
  • the order type may be an order distance type based on a distance basis, for example, a short-distance order, a long-distance order, or the like.
  • the order type may be an order specific type based on important events or holidays, such as a holiday order, a workday order, and the like.
  • the order type can be a short order, a long distance order, and the like.
  • the user preference may be a data processing result that is analyzed and processed based on the user-related information and that can reflect a certain regularity or meaning.
  • the user preference may be a user preference analysis result in conjunction with an order type.
  • the user preferences may include, but are not limited to, an order based destination, a departure place, a short distance order, a long distance order, and/or order time information, and the like.
  • the user preferences may be obtained through a preference analysis of the service demander or through a preference analysis of the service provider.
  • the service provider's preference analysis may include one or more of a driver group's preference characteristics, individual driver's preference characteristics, and the like.
  • the preference characteristics of the driver group can be embodied as premium destination orders.
  • destinations can be clustered to analyze orders that are common to group drivers. In the clustering process, the clusters are sorted according to the order distance and the order time to determine the driver's reaction in the same distance and time period, thereby reflecting the popularity of the destination, in order to determine the preference characteristics of the driver group.
  • the preference feature of the individual driver may be based on the driver's grab data information, analyzing the driver's grab time, order distance, order cost, order destination attribute, etc. to achieve an analysis of the preference characteristics of the individual driver.
  • orders can be divided into long distance orders, short distance orders, and preferred orders.
  • the information of the steps is derived from, but not limited to, database 130, information source 160, and/or storage module 220, and the like.
  • the step may be implemented by one or more modules or units in the order information extraction module 510, the user information extraction module 520, the order group calculation unit 575, and the like.
  • the prediction based on the relevant statistical data of the order may be that the relevant data of the order is processed according to a certain condition, and the processing result thereof may serve as a predictive action.
  • the relevant statistics of the order may be one or more of order time related data, order space related data, order cost, order business type, and the like.
  • the order time related data may be a combination of one or more of historical order data, real time order data, and future order data (eg, predetermined order data).
  • data analysis may be performed based on historical order data for a certain time point or a certain time period of the previous day or a few days before a certain area, and the order quantity of the area at a specific time is predicted.
  • the order quantity can be predicted based on real-time order data.
  • the order quantity predicted based on the historical data and the current real-time order quantity are given a certain weight value, and the order quantity is jointly determined by the two.
  • the information of the steps is derived from, but not limited to, database 130, information source 160, and/or storage module 220, and the like.
  • the steps may be implemented by one or more modules or units in the order information extraction module 510, the user information extraction module 520, the order group calculation unit 575, and/or the order receiver prediction subunit 5775, and the like.
  • step 2820 it may be to calculate the number of potential order recipients at a particular time and within a particular area.
  • the specific time and the specific area correspond to the relevant explanations in step 2810, and are not described herein again.
  • the particular time and specific region in step 2820 may be the same or different from the particular time and particular region in step 2810. In some embodiments, the particular time and particular region may be the same as the relevant interpretation in step 2810.
  • the potential order recipient can be a service provider.
  • the calculation of the number of potential order recipients at a specific time and in a specific area may be the calculation of the description corresponding to step 2420 and step 2425, and will not be described here as long as the purpose of data processing is to count at a specific time and within a specific area.
  • the information of the steps may be derived from database 130, information source 160, and/or storage module 220, and the like.
  • the step may be implemented by one or more modules or units in the user information extraction module 520, the order information extraction module 510, the environment information extraction module 530, the order receiver prediction subunit 5777, and the like.
  • a supply and demand characteristic for a particular region may be determined based on the predicted order quantity and the number of potential order recipients. Understandably, through a certain data processing process, Any data processing that ultimately results in a supply and demand feature for a particular region is within the scope of the description of step 2830.
  • the supply and demand feature may be a feature that reflects a supply-demand relationship between a specific time and an order quantity within a particular area and a potential number of users receiving the order.
  • the data processing process may be corresponding to step 2430, or other data processing method. The same processing method as step 2430 is not described here.
  • the supply and demand feature value may be a ratio of the order quantity to the number of potential users of the received order, and multiplied by a smoothing function. Setting the smoothing function optimizes data processing and can more effectively reflect the supply and demand characteristics.
  • the smoothing function can be a logarithmic function that is base to any value.
  • the logarithmic function of the logarithmic function is a reference to equation (21):
  • Q can be a supply and demand feature value
  • N can be an order quantity
  • O can be the number of potential order recipients
  • D can be the amount of data of an order type.
  • D (which may be the amount of data of an order type) may be a description of any one or more of the order types in step 2810, and details are not described herein again.
  • D may be a combination of one or more of the amount of data of a short-distance order, the amount of data of a long-distance order, the amount of data of a user's preference order, and the like.
  • the information at step 2830 may be derived from information including, but not limited to, the steps, which may be derived from database 130, information source 160, and/or storage module 220, and the like.
  • the steps may be implemented by the supply and demand feature calculation sub-unit 5733.
  • the user device that interacts with the location-related information is a mobile device 2900, which may include, but is not limited to, a smartphone, a tablet, a music player, a portable game console, a Global Positioning System (GPS) receiver, and a wearable computing device.
  • Equipment such as glasses, watches, etc.), or other forms.
  • the mobile device 2900 in this example may include one or more central processing units (CPUs) 2940, graphics processing units (GPUs) 2930, display unit 2920, memory 2960, antenna 2910 (eg, a wireless communication unit), A storage unit 2990, and one or more input output (I/O) units 2950.
  • CPUs central processing units
  • GPUs graphics processing units
  • I/O input output
  • Any other suitable components may include, but are not limited to, a system bus or controller (not shown) or may be included in the mobile device 2900.
  • a mobile operating system 2970 such as iOS, Android, Windows Phone, etc.
  • Application 2980 can include a browser or other mobile application suitable for receiving and processing location related information on mobile device 2900.
  • the passenger/driver interaction with the location related information may be obtained by the input/output system device 2950 and provided to the scheduling engine 110, and/or other components of the system 100, such as through the network 150.
  • a computer hardware platform may be utilized as a hardware platform for one or more of the elements described above (eg, scheduling engine 110, and/or FIG. 1 Other components of system 100 described in -28).
  • 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.
  • FIG. 30 is an architecture of a computer device capable of implementing the particular system disclosed in this application, in accordance with some embodiments of the present application.
  • the particular system in this embodiment utilizes a functional block diagram to explain a hardware platform that includes a user interface.
  • the computer can be a general purpose computer or a computer with a specific purpose.
  • the specific system in this embodiment can be implemented by both computers.
  • Computer 3000 can implement any of the components currently described to provide the information needed for on-demand service.
  • the scheduling engine 110 can be implemented by a computer such as computer 3000 through its hardware devices, software programs, firmware, and combinations thereof.
  • FIG. 30 only one computer is depicted in FIG. 30, but the related computer functions described in this embodiment for providing the information required for on-demand services can be implemented in a distributed manner by a similar set of platforms. Dispose of the processing load of the system.
  • Computer 3000 can include a communication port 3050 to which is connected a network that implements data communication.
  • Computer 3000 may also include 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 3010, different forms of program storage units and data storage units, such as a hard disk 3070, read only memory (ROM) 3030, random access memory (RAM) 3040, which can be configured for computer processing and / or various data files used for communication, and possible program instructions executed by the CPU.
  • Computer 3000 may also include an input/output component 3060 that supports input/output data streams between the computer and other components, such as user interface 3080.
  • Computer 3000 can also accept programs and data over a communications network.
  • a tangible, permanent storage medium may include 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 A 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., by means of cables, fiber optic cables or air. Physical media used for carrier waves such as cables, wireless connections, or fiber optic cables can also be considered as media for carrying software. Usage herein Unless the tangible "storage" medium is limited, other terms referring to a computer or machine "readable medium” mean a medium that participates in the execution of any instruction by the processor.
  • a computer readable medium can take many forms, including but not limited to, a tangible storage medium, carrier medium or physical transmission medium.
  • Stable storage media may include optical or magnetic disks, as well as storage systems used in other computers or similar devices that enable 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 can occur in the process by which the processor is executing instructions, delivering one or more results.

Abstract

本申请披露了一种运力调度的方法，包括获取调度参考信息；根据所述调度参考信息确定调度策略；以及向订单发起者或订单接收方发送所述调度策略。所述调度参考信息包括但不限于历史订单信息、实时订单信息、历史天气信息、实时天气信息、未来天气信息、交通信息、历史服务提供者信息、或实时服务提供者信息或由车载诊断系统采集的车辆信息。所述调度策略包括但不限于供求密度推送策略、热点特征推送策略、统计特征推送策略、订单推送策略、订单调整策略、或提示信息推送策略。

Description

一种运力调度方法及系统
交叉引用
本申请要求以下申请的优先权：
2015年2月13日提交的编号为CN201510079087.0的中国申请；
2015年3月4日提交的编号为CN201510097280.7的中国申请；
2015年6月5日提交的编号为CN201510303334.0的中国申请；
2015年8月20日提交的编号为CN201510516164.4的中国申请；
2015年2月26日提交的编号为CN201510088837.0的中国申请；
2015年7月20日提交的编号为CN201510428931.6的中国申请；
2015年11月2日提交的编号为CN201510737743.1的中国申请；
2015年12月24日提交的编号为CN201510990222.7的中国申请；
2016年1月21日提交的编号为CN201610046769.6的中国申请；
上述申请的内容以引用方式被包含于此。
技术领域
本申请涉及为运力调度方法及系统，尤其是涉及应用移动互联网技术和数据处理技术的运力调度方法及系统。
背景技术
目前，按需服务应用的使用越来越普遍。以交通服务为例，按需服务系统进行运力调度以满足乘客的乘车需求和司机的接单需求。为了提高运力系统的效率，需要制定灵活、实用的运力调度机制。科学地进行调度运力，能够促进供需平衡，满足供需双方的共同需求，提高交通服务的用户体验。
简述
根据本申请的一个方面，提供了一种运力调度系统。该系统可以包括：一种计算机可读的存储媒介和一个处理器。所述计算机可读的存 储媒介可以存储可执行模块。所述处理器可以执行所述计算机可读的存储媒介存储的可执行模块。所述可执行模块可以包括：订单信息提取模块；用户信息提取模块；环境信息提取模块；计算模块；和调度模块。所述订单信息提取模块、所述用户信息提取模块、和所述环境信息提取模块可以获取调度参考信息。计算模块可以根据所述调度参考信息确定调度策略。调度模块可以发送所述调度策略。所述可执行模块还可以包括一个或多个其他模块，如订单分配模块等。
根据本申请的另一个方面，提供了一种运力调度方法。所述运力调度方法可以包括：获取调度参考信息；根据所述调度参考信息确定调度策略；向订单发起者或订单接收方发送所述调度策略。
根据本申请的另一个方面，提供了一种基于位置信息的服务的使用方法。所述方法可以包括：终端向基于位置信息的调度系统发送位置信息；所述终端接收所述系统发送的基于位置信息的调度策略。根据本申请的一些实施例，所述终端可以包括：乘客终端、司机终端。根据本申请的一些实施例，所述显示形式可以包括语音、文字、图形、视频。根据本申请的一些实施例，所述图形显示形式可以是基于所述终端的地图显示不同的供求密度、订单密度、订单数量、用户数量。
根据本申请的另一个方面，提供了一种有形的非暂时性计算机可读媒介，该媒介上可以存储信息。当该信息被计算机读取时，该计算机即可执行运力调度方法。所述运力调度方法可以包括：获取调度参考信息；根据所述调度参考信息确定调度策略；向订单发起者或订单接收方发送所述调度策略。
根据本申请的一些实施例，所述调度参考信息可以包括：历史订单信息、实时订单信息、历史天气信息、实时天气信息、未来天气信息、交通信息、历史服务提供者信息、或实时服务提供者信息或由车载诊断系统采集的车辆信息。
根据本申请的一些实施例，所述调度策略的确定过程可以包括：根据所述调度参考信息确定实际调度量；根据所述实际调度量确定调度策略。
根据本申请的一些实施例，所述根据所述调度参考信息确定实际调度量可以包括：确定多个服务提供者的区域分布；基于所述区域分布计算针对各个区域的潜在调度量；基于针对各个区域的潜在调度量计算针对各个区域的潜在成交量；基于针对各个区域的潜在成交量计算最大潜在成交增量和；基于所述最大潜在成交增量和来确定针对各个区域的实际调度量。
根据本申请的一些实施例，所述根据所述调度参考信息确定实际调度量可以包括：确定基于地理信息的区域划分；计算与所述区域划分相关的服务提供者的当前需求数量；计算与所述区域划分相关的服务提供者的预期需求数量；基于所述当前需求数量和所述预期需求数量确定实际调度量。
根据本申请的一些实施例，所述调度策略可以包括：供求密度推送策略、热点特征推送策略、统计特征推送策略、订单推送策略、订单调整策略、或提示信息推送策略。
根据本申请的一些实施例，所述供求密度推送策略的确定过程可以包括：获取在给定时间和给定区域内的订单数量；计算在所述给定时间和所述给定区域内潜在地接收所述订单的服务提供者的数量；基于所述预测的订单量和所述潜在地接收所述订单的服务提供者的数量，确定所述给定区域的供求密度。
根据本申请的一些实施例，所述统计特征推送策略的确定过程可以包括：根据获取的所述调度参考信息，提取服务提供者所在的位置信息；根据获取的所述服务提供者所在的位置信息，提取所述服务提供者所在位置附近的多个订单信息；确定所述多个订单中每个订单对应的标志地点；基于所述标志地点和订单时间信息，对所述多个订单进行分组；计算每组订单的统计特征。
根据本申请的一些实施例，上述运力调度方法及运力调度系统可以进一步包括：针对特定的标志地点，选择对应于所述标志地点的一组实时订单。
根据本申请的一些实施例，所述订单推送策略确定过程可以包括： 确定订单需求与服务提供者服务能力的比值小于第一阈值的第一区域以及订单需求与服务提供者服务能力的比值大于第二阈值的第二区域；在所述第一区域中，针对每个订单，选择向其呈现的用户；在所述第二区域中，针对每个用户，选择向其呈现的订单。
根据本申请的一些实施例，所述订单调整策略确定过程可以包括：根据获取的所述参考信息，提取目标区域在第一预设时间段的天气信息；根据获取的所述参考信息，提取所述目标区域中第二预设时间段的订单信息，以及当前时刻的服务提供者信息；根据所述天气信息、所示第二预设时间段内的订单信息和所述服务提供者信息，确定订单调整策略。
附图描述
在此所述的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的限定。在各图中，相同标号表示相同部件。
图1是根据本申请的一些实施例所示的是一个网络环境的示意图；
图2是根据本申请的一些实施例所示的是运力调度的系统的示意图；
图3是根据本申请的一些实施例所示的是运力调度的一种示例性流程图；
图4-A和图4-B是根据本申请的一些实施例所示的运力调度在用户端的示例性流程图；
图5是根据本申请的一些实施例所示的处理模块的一个示意图；
图6是根据本申请的一些实施例所示的处理模块的一个示意图；
图7-A、图7-B和图7-C是是根据本申请的一些实施例所示的区域划分的示意图；
图8是根据本申请的一些实施例所示的基于调度量预测的运力调度的一个示例性流程图；
图9是根据本申请的一些实施例所示的处理模块的一个示意图；
图10是根据本申请的一些实施例所示的基于环境信息进行运力 调度的一个示例性流程图；
图11是根据本申请的一些实施例所示的确定是否需要启动调度策略的一个示例性流程图；
图12是根据本申请的一些实施例所示的处理模块的一个示意图；
图13是根据本申请的一些实施例所示的基于区域划分进行运力调度的一个示例性流程图；
图14是根据本申请的一些实施例所示的处理模块的一个示意图；
图15是根据本申请的一些实施例所示的基于成交量信息的运力调度方法的一个示例性流程图；
图16是根据本申请的一些实施例所示的处理模块的一个示意图；
图17是根据本申请的一些实施例所示的运力调度系统的一个网络环境示意图；
图18是根据本申请的一些实施例所示的基于车载诊断系统的运力调度方法的一个示例性流程图；
图19是根据本申请的一些实施例所示的基于车载诊断系统的运力调度方法中匹配流程的一个示例性流程图；
图20是根据本申请的一些实施例所示的处理模块的一个示意图；
图21是根据本申请的一些实施例所示的基于统计信息的运力调度方法的示例性流程图；
图22是根据本申请的一些实施例所示的基于统计信息的运力调度方法的示例性流程图；
图23是根据本申请的一些实施例所示的处理模块的一个示意图；
图24是根据本申请的一些实施例所示的基于供求密度信息的运力调度方法的示例性流程图；
图25是根据本申请的一些实施例所示的处理模块的一个示意图；
图26是根据本申请的一些实施例所示的基于订单交互信息和分布信息的运力调度方法的一个示例性流程图；
图27是根据本申请的一些实施例所示的处理模块的一个示意图；
图28是根据本申请的一些实施例所示的基于供求特征的运力调 度方法的示例性流程图；
图29是根据本申请的一些实施例所示的一种移动设备的结构，该移动设备能够用于实现实施本申请中披露的特定系统；以及
图30是一种计算机设备的架构，这种计算机设备能够被用于实现实施本申请中披露的特定系统。
具体描述
为了更清楚地说明本申请的实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。
如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其他的步骤或元素。
虽然本申请对根据本申请的实施例的系统中的某些模块做出了各种引用，然而，任何数量的不同模块可以被使用并运行在客户端和/或服务器上。所述模块仅是说明性的，并且所述系统和方法的不同方面可以使用不同模块。
本申请中使用了流程图用来说明根据本申请的实施例的系统所执行的操作。应当理解的是，前面或下面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各种步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。
本申请的实施例可以应用于不同的运输系统，不同的运输系统可以包括但不限于陆地、海洋、航空、航天等中的一种或几种的组合。例如，出租车、专车、顺风车、巴士、火车、动车、高铁、地铁、船 舶、飞机、飞船、热气球、无人驾驶的交通工具、收/送快递等应用了管理和/或分配的运输系统。本申请的不同实施例应用场景可以包括但不限于网页、浏览器插件、客户端、定制系统、企业内部分析系统、人工智能机器人等中的一种或几种的组合。应当理解的是，本申请的系统及方法的应用场景仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。例如，其他类似的服务接单系统。
本申请描述的“乘客”、“顾客”、“需求者”、“服务请求者”、“服务请求方”、“消费者”、“消费方”、“使用需求者”等是可以互换的，是指需要或者订购服务的一方，可以是个人，或工具。同样地，本申请描述的“司机”、“提供者”、“供应者”、“服务提供者”、“服务提供方”、“服务者”、“服务方”等也是可以互换的，是指提供服务或者协助提供服务的个人、工具或者其他实体等。另外，本申请描述的“用户”可以是需要或者订购服务的一方，或提供服务或者协助提供服务的一方。本申请描述的“订单”可以是由需要或者订购服务的一方作为订单的发起者，或由提供服务或者协助提供服务的一方作为订单的发起者。类似地，订单可以是由需要或者订购服务的一方作为订单的发起者，或由提供服务或者协助提供服务的一方作为订单的发起者。“订单”可以是经过消费方和服务提供方双方认可的订单，或只经过服务方或者消费方一方的认可的订单。“订单”可以是付费的订单，或免费的订单。
根据本申请的一些实施例，图1所示的是一个网络环境100的示意图。该网络环境100可以包括一个按需服务系统105、一个或多个乘客端设备120、一个或多个数据库130、一个或多个司机端设备140、一个或多个网络150、一个或多个信息源160。该按需服务系统105可以包含一个调度引擎110。为描述方便，调度引擎也可以称为调度系统。为描述方便，在本申请中，系统可以指按需服务系统，或调度引擎或调度系统。在一些实施例中，调度引擎110是可以对收集的信息进行分析加工以生成分析结果的系统。调度引擎110可以是一个服 务器，或一个服务器群组，群组内的各个服务器通过有线的或无线的网络进行连接。一个服务器群组可以是集中式的，例如数据中心。一个服务器群组可以是分布式的，例如一个分布式系统。调度引擎110可以是本地的，或远程的。在一些实施例中，调度引擎110可以通过网络150访问存取乘客端设备120和/或司机端设备140的信息、信息源160中的信息、数据库130中的信息，或直接访问信息源160中的信息、数据库130中的信息。
乘客和司机可以统称为用户，它可以是直接与服务订单相关联的个人、工具或者其他实体，例如服务订单的请求者与提供服务者。乘客可以是服务需求方。在本文中，“乘客”、“乘客端”和“乘客端设备”可以互换使用。乘客还可以包括乘客端设备120的使用者。在一些实施例中，该使用者可以不是乘客本人。例如，乘客端设备120的使用者A可以使用乘客端设备120为乘客B请求按需服务，或接受按需服务或按需服务系统105发送的其他信息或指令。为简便起见，在本文中该乘客端设备120的使用者可以简称为乘客。司机可以是服务提供方。在本文中，“司机”、“司机端”和“司机端设备”可以互换使用。司机还可以包括司机端设备140的使用者。在一些实施例中，该使用者可以不是司机本人。例如，司机端设备140的使用者C可以使用司机端设备140为司机D接受按需服务或按需服务系统105发送的其他信息或指令。为简便起见，在本文中该司机端设备120的使用者可以简称为司机。
在用户为工具的实施例中，乘客端设备120可以包括但不限于台式电脑120-1、笔记本电脑120-2、机动车的内置设备120-3、移动设备120-4等中的一种或几种的组合。进一步地，机动车的内置设备120-3，可以为车载电脑(carputer)等。在一些实施例中，这些用户还可以是一些其他智能终端，可以包括但不限于智能家居设备、可穿戴设备、智能移动设备或其他智能设备。对于智能家居设备，可以包括但不限于智能照明设备、智能电器控制设备、智能监控设备、智能电视、智能摄像机、智能电话、对讲机等中的一种或几种的组合；对 于可穿戴设备，可以包括但不限于智能手环、智能鞋袜、智能眼镜、智能头盔、智能头带、智能服装、智能背包、智能配饰等中的一种或几种的组合；对于智能移动设备，可以包括但不限于智能手表、笔记本、平板电脑、交通工具内置设备(车载电脑或车载电视等)、游戏设备、GPS设备、POS机等中的一种或几种的组合。司机端设备140可以包括类似的设备中的一种或多种。
在一些实施例中，数据库130可以泛指具有存储功能的设备。数据库130主要用于存储从乘客端设备120和/或司机端设备140收集的数据和调度引擎110工作中所利用、产生和输出的各种数据。数据库130可以是本地的，或远程的。数据库130可以包括但不限于层次式数据库、网络式数据库和关系式数据库等其中的一种或几种的组合。数据库130可以将信息数字化后再以利用电、磁或光学等方式的存储设备加以存储。数据库130可以用来存放各种信息例如程序和数据等。数据库130可以是利用电能方式存储信息的设备，例如各种存储器、随机存取存储器(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可以泛指具有存储功能的设备。数据库130主要用于存储从乘客端设备120和/或司机端设备140和/或信息源160收集的数据和调度引擎110工作中产生的各种数据。数据库130或系统内的其他存储设备泛指所有可以具有读/写功能的媒介。数据库130或系统内其他存储设备可以是系统内部的，或是系统的外接设备。数据库130与系统内其他存储设备的连接方式可以是有线的，或无线的。数据库130与系统其他模块间的连接或通信可以是有线的，或无线的。网络150可以提供信息交换的渠道。
按需服务系统105，或其一部分(例如，订单推送引擎110)，和/或用户端120/140与数据库130的连接方式可以是不同。各方对数据库130的访问权限可以是有限制的。例如，按需服务系统105，或其一部分(例如，调度引擎110)，对数据库130有最高的访问权限，可以从数据库130中读取或修改大众的或个人的信息；乘客端设备120或司机端设备140在满足一定条件时可以读取部分大众的信息或与用户相关的个人信息。例如，按需服务系统105可以根据一位用户(乘客或司机)的一次或多次使用按需服务系统105的经历更新/修改数据库130中大众的或与该位用户相关的信息。又例如，一位司机140在收到一位乘客120的服务订单时，可以查看数据库130中关于该乘客120的部分信息；但该司机140不可以自主修改数据库130中关于该 乘客120的信息，而只能向按需服务系统105汇报，由按需服务系统105决定是否修改数据库130中关于该乘客120的信息。再例如，一位乘客120，在收到一位司机140的提供服务的请求时，可以查看数据库130中关于该司机140的部分信息(如用户评分信息，驾驶经验等)；但该乘客120不可以自主修改数据库130中关于该司机140的信息，而只能向按需服务系统105汇报，由按需服务系统105决定是否修改数据库130中关于该司机140的信息。
网络150可以是单个网络，或多个不同网络的组合。例如，网络150可以包括但不限于局域网、广域网、公用网络、专用网络、无线局域网、虚拟网络、都市城域网、公用开关电话网络等中的一种或几种的组合。网络150可以包括多个网络接入点，例如，如基站150-1、基站150-2、互联网交换点等在内的有线或无线接入点，通过这些接入点，任何数据源可以接入网络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所示的是包含调度引擎110的一种示意图。为描述方便，按需服务系统105没有显示，而是以调度引擎110为例来说明。调度引擎110可以包括一个或多个处理模块210、一个或多个存储模块220、一个或多个乘客接口230、一个或多个司机接口240。调度引擎110的模块可以是集中式的或分布式的。调度引擎110的模块中的一个或多个模块可以是本地的或远程的。在一些实施例中，调度引擎110可以是网页服务器、文件服务器、数据库服务器、FTP服务器、应用程序服务器、代理服务器、邮件服务器等中的一种或几种的组合。
在一些实施例中，调度引擎110可以通过乘客接口230从乘客端设备120接收信息，或将处理后的信息通过乘客接口230发送给乘客端设备120。在一些实施例中，调度引擎110可以通过司机接口240从司机端设备140接收信息，或将处理后的信息通过司机接口240发送给司机端设备140。调度引擎110可以从数据库130和/或信息源160中获取信息，或将处理后的信息通过乘客接口230发送给乘客端设备120，或将处理后的信息通过司机端接口240发送给司机端设备140。
在一些实施例中，乘客接口230与司机接口240可以分别从乘客端设备120与司机端设备140接收各自发送的信息。在一些实施例中， 乘客接口230与司机接口240可以分别从数据库130和/或信息源160中读取信息。此处的信息可以包括但不限于服务的请求信息、服务的接收信息、用户的习惯/喜好信息、当前定位信息等中的一种或几种的组合。其中，服务的请求信息可以是用户的订单请求信息(例如，乘客的打车请求、司机的接单请求等)、用户的其他请求信息(例如，司机向系统发送获取某一区域的订单密度的请求)等。服务的接收信息可以是用户同意接单的信息、用户放弃接单的信息、用户接单成功的信息、用户接单失败的信息等。用户的习惯/喜好信息可以是乘客对于司机的偏好、乘客可以接收的等待时间、乘客对于拼车乘客的偏好、乘客对于车型的偏好、司机对于出发地、目的地、出发时间的偏好等。信息的形式可以包括但不限于文本、音频、视频、图片等中的一种或几种的组合。信息的输入方式可以是手写输入、手势输入、图像输入、语音输入、视频输入、电磁波输入或者其他数据输入方式，或者以上的任意组合。所接收的信息，可以存储于数据库130中，或存储在存储模块220中，或由处理模块210进行计算与处理。
在一些实施例中，乘客接口210与司机接口230可以输出经过处理模块210分析处理后的信息。此处的信息，可以是优化后的定位信息、订单的直接信息、订单的处理信息、订单的历史信息、订单的实时信息、用户的直接信息、用户的处理信息、用户的历史信息、用户的实时信息、环境信息等。信息的形式可以包括但不限于文本、音频、视频、图片等中的一种或几种的组合。输出的信息可以发送给乘客端设备120和/或司机端设备140，或不发送。不发送的输出信息可以存储在数据库130中，或存储在存储模块220中，或存储在处理模块210中。
在一些实施例中，处理模块210可以对相关信息进行处理。处理模块可以从乘客接口230、司机接口240、数据库130、信息源160、存储模块220等获取信息。处理模块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可以实际存在于系统中，或通过云计算平台完成相应功能。其中，云计算平台可以包括但不限于存储数据为主的存储型云平台、以处理数据为主的计算型云平台以及兼顾数据存储和处理的综合云计算平台。按需服务系统105或其一部分(例如，调度引擎110)所使用的云平台可以是公共云、私有云、社区云或混合云等。例如，根据实际需要，按需服务系统105接收的一些订单信息和/或非订单信息，可以通过云平台进行计算和/或存储。另一些订单信息和/或非订单信息，可以通过本地处理模块和/或系统数据库进行计算和/或存储。
应当理解，图2所示的调度引擎110可以利用各种方式来实现。例如，在一些实施例中，调度引擎110可以通过硬件、软件或者软件和硬件的结合来实现。其中，硬件部分可以利用专用逻辑来实现；软件部分则可以存储在存储器中，由适当的指令执行系统，例如微处理器或者专用设计硬件来执行。本领域技术人员可以理解上述的方法和系统可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、CD或DVD-ROM的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本申请中描述的按需服务系统105或其一部分(例如，调度引擎110)及其模块不仅可以有诸如超大规模集成电 路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，或用例如由各种类型的处理器所执行的软件实现，还可以由上述硬件电路和软件的结合(例如，固件)来实现。
需要注意的是，以上对于调度引擎110的描述，仅为描述方便，并不能把本申请限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解该系统的原理后，可能在不背离这一原理的情况下，对实施上述方法和系统的应用领域形式和细节上的各种修正和改变。例如，在一些实施例中，调度引擎110中，还可以有一个存储模块。所述存储模块可以是内部的，或是外接设备。所述存储模块可以实际存在于调度引擎110中，或通过云计算平台完成相应功能。对于本领域的技术人员来说，在了解该调度引擎110及按需服务系统110的原理后，可以在不背离这一原理的情况下，对各个模块进行任意组合，或者构成子系统与其他模块连接。例如，在一些实施例中，乘客接口230、处理模块210、司机接口240和存储模块220可以是体现在一个系统中的不同模块，或是一个模块实现上述的两个或两个以上模块的功能。例如，乘客接口230/司机接口240可以是一个模块同时具有输入输出的功能，或是针对乘客的输入模块和输出模块。例如，处理模块210和存储模块220可以是两个模块，或是一个模块同时具有处理和存储功能。例如，各个模块可以共用一个存储模块，或各个模块分别具有各自的存储模块。诸如此类的变形，均在本申请的保护范围之内。
根据本申请的一些实施例，图3所示的是运力调度的一种示例性流程图。在一些实施例中，该运力调度流程可以由按需服务系统105或其一部分(例如，调度引擎110)执行。
在步骤311，可以获取调度参考信息。所述调度参考信息的获取可以由调度引擎110执行。更具体地，所述调度参考信息的获取可以由处理模块210执行。其中，所述调度参考信息可以包括但不限于订单信息、用户信息、环境信息等中的一种或多种的组合。其中，所述 订单信息可以是订单时间信息(例如，订单出发时间、订单等待时间)、订单类型信息(例如，长途订单、短途订单)、订单位置信息(例如，出发位置、目的地位置)、订单价格信息(例如，订单成交价格、附加费)等中的一种或多种的组合。其中，所述用户信息可以是用户身份信息(例如，用户职业、用户性别)、用户终端设备信息(例如，用户终端设备型号、用户终端设备剩余电量)、用户偏好信息(例如，乘客对于司机的偏好、司机对于出发地、目的地和出发时间的偏好)、用户历史订单信息(例如，司机历史接单数量、乘客历史下单数量)、用户信用信息(例如，乘客的付费记录、司机的交通违章信息)等中的一种或多种的组合。其中，所述环境信息可以是天气信息(例如，温度信息、天气类型信息)、交通信息(例如，道路信息、交通拥堵信息、交通管制信息)、事件信息(例如，节假日信息、重大活动信息)、地理信息(例如，区域划分信息、经纬度信息)等中的一种或者多种的组合。信息的形式可以包括但不限于文本、音频、视频、图片等中的一种或几种的组合。在一些实施例中，调度参考信息可以是实时信息、可以是历史信息，可以是预测信息。其中，实时信息可以是在当前时间出发的订单信息、在当前时间的用户信息、当前时间的天气信息等。其中，历史信息可以是在过去N天中的信息、可以是在特定时间(例如，每个星期一，每天的10：00)的信息等。其中，预测信息可以是预测的天气信息、预测的交通信息等。
在一些实施例中，所述调度参考信息可以来源于乘客接口230从乘客端设备120接收的信息，可以来源于司机接口240从司机端设备140接收的信息，或来源于数据库130、信息源160和/或存储模块220中存储的信息。信息获取时的通信方式可以是有线的，或是无线的。
在步骤313，可以根据调度参考信息，确定调度策略。所述调度策略的确定可以由调度引擎110执行。更具体地，所述调度策略的确定，可以由处理模块210执行。所述调度策略可以包括但不限于供求密度推送策略、热点特征推送策略、统计特征推送策略、订单推送策略、订单调整策略、或提示信息推送策略等中的一种或多种的组合。所述供 求密度推送策略可以指向用户推送供求密度信息。在一些实施例中，所述供求密度信息可以是当前供求密度信息，历史供求密度信息，预测供求密度信息等中的一种或多种。所述热点特征推送策略可以指向用户推送热点特征信息。在一些实施例中，所述热点特征信息可以是热点区域信息(例如，订单数量最多的区域、特定区域的订单数量)、热点时段信息(例如，特定时段的订单数量、特定时段的司机数量)、热点订单信息(例如，哪一种类型的订单数量最多)等中的一种或多种。所述统计特征推送策略可以指向用户推送统计特征信息。在一些实施例中，所述统计特征信息可以是司机的统计特征信息(例如，司机的接单偏好、司机的日均接单量)，乘客的统计特征信息(例如，乘客的选择偏好、乘客的日均订单量)，订单的统计特征信息(例如，特定区域内订单数量、订单的平均成交价格)，交通的统计特征信息(例如，特定路段和时间出现交通堵塞的统计)，天气的统计特征信息(例如，特定区域和特定时间出现雨雪天气的统计)等中的一种或多种。在一些实施例中，所述统计特征信息可以是实时的统计特征信息(例如，当前的订单数量)，历史的统计特征信息(例如，历史的订单数量)，预测的统计特征信息(例如，预测的订单数量)等中的一种或多种。其中，所述订单推送策略可以指向用户推送订单信息。所述订单信息可以是一个具体的订单信息，供用户选择的多个订单信息等中的一种或多种。所述订单调整策略可以指向用户推送订单调整信息。所述订单调整信息可以包括但不限于订单价格的调整信息、订单类型的调整信息等。所述提示信息推送策略可以指向用户推送提示信息。所述提示信息可以包括但不限于对于交通状况、天气状况、历史订单状况等中的一种或多种。信息的形式可以包括但不限于文本、音频、视频、图片等中的一种或几种的组合。
在一些实施例中，处理模块210确定调度策略的过程可以包括但不限于对所述调度参考信息进行存储、分类、筛选、转换、就是那、检测、预测、训练等中的一种或几种的组合。
为了描述方便，以下对调度策略确定可以用到的预测模型和机器学习模型进行说明。在一些实施例中，预测模型可以是定性的，或是 定量的。定量的预测模型可以基于时序预测法，和/或基于因果分析法。时间预测法进一步可以包括平均平滑法、趋势外推法、季节变动预测法和马尔可夫时序预测法等中的一种或几种的组合。因果分析法进一步可以包括一元回归法、多元回归法和投入产出法。在一些实施例中，预测模型可以包括但不限于加权算术平均模型、趋势平均预测模型、指数平滑模型、平均发展速度模型、一元线性回归模型、高低点模型中的一种或几种的组合。另外在一些实施例中，对于信息处理所用到的公式、算法和/或模型可以通过机器学习，不断进行优化。对于机器学习的方法，根据学习方式的不同可以是监督式学习、非监督式学习、半监督式学习或强化学习；根据算法的不同，机器学习的算法可以是回归算法学习、基于实例的学习、正规化学习、决策树学习、贝叶斯学习、聚类算法学习、关联规则学习、神经网络学习、深度学习、降低维度算法学习等。具体来说，对于回归算法模型，可以是最小二乘法(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、CHAID(Chi-squared Automatic Interaction Detection)、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)等。
在步骤315，调度策略可以被发送。所述调度策略的发送可以由调度引擎110执行。在一些实施例中，所述调度策略可以通过乘客接口230发送至乘客端设备120。例如，通过乘客接口230，发送订单价格的调整信息至乘客端设备120。在一些实施例中，所述调度策略可以通过司机接口240发送给司机端设备140。例如，通过司机接口240，发送实时订单信息至司机端设备140。又例如，通过司机接口240，发送当前区域内的历史订单情况至司机端设备140。在一些实施例中，调度策略可以被发送至存储模块220、数据库130、信息源160，或由处理模块210的一个内部模块或单元发送至另外一个内部模块或单元。例如，将价格调整策略发送至处理模块210中的订单价格计算子单元(未在图3中显示)以对订单价格计算结果做出调整(例如，订单价格在原价的基础上乘以1.5倍的溢价)。
根据本申请的一些实施例，图4-A所示的是运力调度方法在用户端的一种示例性流程图。在一些实施例中，该运力调度流程可以由乘客端设备120执行。
在步骤421，可以接收来自服务器的调度策略。所述调度策略可 以包括但不限于供求密度推送策略、热点特征推送策略、统计特征推送策略、订单推送策略、订单调整策略、或提示信息推送策略等中的一种或多种(详细描述见图3)。例如，在天气状况较差的情况下，调度策略可以是订单价格在原价基础上乘以N倍溢价的订单调整策略。又例如，在车辆需求的高峰时段，调度策略可以是提醒乘客避免在高峰时段出行的提示信息推送策略。又例如，在司机相对较多的区域，调度策略可以是向乘客推送司机信息的订单推送策略。接收调度策略的通信方式可以是有线的，或是无线的。以图29所示移动设备2900为例，当该设备作为乘客端设备120时，调度策略的接收可以由天线2910实现。
在步骤423，可以显示来自服务器的调度策略。所述调度策略的显示形式可以包括但不限于语音、文字、图形、视频等中的一种或多种的组合。例如，可以通过语音的形式播报价格调整的信息。又例如，可以以文字的形式显示不同区域的车辆数。又例如，可以通过图形的形式在地图上显示当前的车辆分布，用三角形代表出租车，用正方形代表私家车。又例如，以展示框的形式显示司机的密度信息。所述调度策略的显示，可以基于乘客端设备的地图进行显示。例如，可以以颜色区分车辆的集中程度，以红色在地图上标志车辆最集中的区域，以蓝色表示车辆较少的区域。又例如，可以在地图上用不同的灰度情况显示不同的供求密度、订单密度、订单数量、用户数量等。所述调度策略的显示，可以由用户触发，也可以不由用户触发。例如，在接收到乘客发送的触发信号后，在乘客端设备的地图上显示相应的调度信息。以图29所示移动设备2900为例，当该设备作为乘客端设备120时，调度策略的显示可以由显示单元2920执行。在一些实施例中，调度策略从接收到显示，中间可能需要一些数据处理(例如，数据编码、解码、格式转换等)。所述数据处理过程可以由移动设备2900的图形处理器2930、中央处理器2940和/或内存2960执行。
在步骤425，可以接收需求信息。所述需求信息可以是乘客的订单请求信息、乘客的偏好信息、或是乘客的其他请求信息。其中，乘客的订单请求信息可以包括但不限于出发地、出发时间、期望达到时 间、愿意等待的时间、乘客人数、乘客性别、是否携带行李、携带行李的数量、是否携带宠物、携带宠物的类型和数量、里程、价格、消费方加价等中的一种或者多种。其中，乘客的偏好信息可以包括但不限于对车型的偏好、对服务提供方的偏好(例如，优先选择驾龄10年以上的司机)、对路线的偏好(例如，优先选择距离最短的路线)、对等待时间的偏好(例如，优先选择等待时间在5～10分钟左右的司机)等中的一种或者多种。其中乘客的其他请求信息可以包括但不限于向系统发送的获取天气状况的请求信息、获取某一区域司机分布的请求信息、申请价格调整的信息等中的一种或者多种。信息的形式可以包括但不限于文本、音频、视频、图片等中的一种或几种的组合。信息的输入方式可以是手写输入、手势输入、图像输入、语音输入、视频输入、电磁波输入、体感输入或者其他数据输入方式，或者以上的任意组合。所接收的需求信息可以存储在接收设备的存储单元，或直接被发送。以图29所示的移动设备2900为例，当该设备作为乘客端设备120时，输入/输出单元2950接收的需求信息，可以存储于内存2960、中央处理器2940，或者不存储而直接经由输入/输出单元2950或天线2910而被发送。
在步骤427，可以发送接收的需求信息。在一些实施例中，被发送的需求信息可以是乘客原始的需求信息，或是被处理后的需求信息。所述信息的处理可以包括但不限于对信息进行纠错、合并、筛选、转换、计算等中的一种或者多种。例如，乘客以文本形式输入信息“出发地：北京市海淀区海大街3号”，图4-A所示设备在发送这一信息时可以将信息纠正为“出发地：北京市海淀区海淀大街3号”或以该地理位置所对应的经纬度坐标的形式发送该需求信息。
根据本申请的一些实施例，图4-B所示的是运力调度方法在用户端的一种示例性流程图。在一些实施例中，该运力调度流程可以由司机端设备140执行。
在步骤431，可以接收来自调度引擎110的调度策略。所述调度策略可以包括但不限于供求密度推送策略、热点特征推送策略、统计特 征推送策略、订单推送策略、订单调整策略、或提示信息推送策略等中的一种或多种(详细描述见图3)。例如，在订单数量偏少的区域，可以是提醒司机前往其他区域接单的提示信息推送策略。又例如，在订单数量偏少的区域，可以是将订单优先推送给信用评价较高的司机的订单推送策略。又例如，在特定区域，可以是显示该区域历史订单和实时订单信息的统计特征推送策略。接收调度策略的通信方式可以是有线的，或是无线的。以图29所示移动设备2900为例，调度策略的接收可以由天线2910实现。
在步骤433，可以显示来自调度引擎110的调度策略。所述调度策略的显示形式可以包括但不限于语音、文字、图形、视频等中的一种或多种的组合。例如，可以通过语音的形式播报价格调整的信息。又例如，可以通过文字的形式显示不同区域的乘客数。又例如，可以通过图形的形式在地图上显示当前的订单分布，用圆形代表长途订单，用菱形代表短途。又例如，以展示框的形式显示订单的密度信息。所述调度策略的显示，可以基于乘客端设备的地图进行显示。例如，可以以颜色区分乘客的集中程度，以红色在地图上标志乘客最集中的区域，以蓝色表示乘客较少的区域。又例如，可以在地图上用不同的灰度情况显示不同的供求密度、订单密度、订单数量、用户数量等。所述调度策略的显示，可以由用户触发，也可以不由用户触发。例如，在接收到司机发送的触发信号后，在司机端设备的地图上显示相应的调度信息。以图29所示移动设备2900为例，调度策略的显示可以由显示单元2920执行。在一些实施例中，调度策略从接收到显示，中间可能需要一些数据处理(例如，数据编码、解码、格式转换等)。所述数据处理过程可以由移动设备2900的图形处理器2930、中央处理器2940和/或内存2960执行。
需要注意的是，以上关于运力调度流程的描述，仅为描述方便，并不能把本申请限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解本申请的基本原理后，可以在不背离这一原理的情况下，对运力调度流程作出改变。例如，可以增加或减少一些 步骤。例如，在步骤311之后可以对调度参考信息进行预处理。预处理过程可以通过数据清理、数据集成、数据变换和/或数据规约等方法去除一些失真的数据。在一些实施例中，具体的失真数据去除方法可以包括但不限于判别法、剔除法、平均值法、拉平法、比例法、移动平均法、指数平滑法、差分法等中的一种或几种的组合。再例如，在步骤423和步骤431之前可以增加判断步骤，判断服务器是否发送了新的调度策略。在检测到新的调度策略之后再继续进行调度策略的接收。又例如，在步骤427后，乘客可以通过乘客端设备120接收来自调度引擎110的关于服务请求是否被接受及相关信息。在一些实施例中，乘客还可以通过乘客端设备120对接收到的信息作出反馈。又例如，在步骤433后，司机可以通过司机端设备140对调度策略作出反馈(例如，选择，接受，拒绝等中的一种或多种)。诸如此类的变形，均在本申请的保护范围之内。
根据本申请的一些实施例，图5所示的是运力调度系统中处理模块210的一个示意图。处理模块210可以包括一个或多个订单信息提取模块510、一个或多个用户信息提取模块520、一个或多个环境信息提取模块530、一个或多个订单信息分配模块540、一个或多个调度模块550、和一个或多个计算模块570。除上述模块之外，处理模块210还可以包括一个或多个其他模块或单元。上述各个模块510-570之间可以互相通信，各个模块之间的连接方式可以是有线的，或是无线的。图5中示例性给出了各个模块间的连接方式，但并不表示各个模块间的连接方式仅限于此。
订单信息提取模块510可以提取与订单相关的直接或间接的信息。在一些实施例中，订单信息可以是实时订单信息、历史订单信息、预约订单信息，预测订单信息等中的一种或多种。作为示例，订单信息可以包括：订单发送时间、订单编号、出发地、目的地、出发时间、到达时间、愿意等待的时间、乘客人数、是否愿意拼车、选择的车型、是否携带行李、携带行李的数量、是否携带宠物、里程、价格、消费方加价、服务方调价、系统调价、红包使用情况、付款方式(如现金 支付、刷卡支付、网上支付、汇款支付等)、订单完成情况、服务方选择订单情况、消费方发送订单情况等，或者上述信息的任意组合。除上述描述外，订单信息还可以包括与订单相关的其他信息，例如乘客信息(例如性别、昵称、联系方式等)和其他不受消费方、服务方控制的信息，或者是指暂时性/突发性的信息等中的而一种或多种。例如，其他信息可以包括但不限于天气情况、环境情况、道路状况(如因安全性或者道路作业等原因封闭道路)、交通条件等，或者上述信息的任意组合。订单信息可以实时提取，或非实时提取。提取的订单信息可以存储在订单信息提取模块510、存储模块220、信息源160、数据库130、或者任何在本申请中所描述的集成在系统中或独立于系统外的存储设备中。
在一些实施例中，订单信息提取模块510还可以包括一个或多个子单元，例如时间信息提取单元(未在图5中显示)、位置信息提取单元(未在图5中显示)、解析单元(未在图5中显示)、处理单元(未在图5中显示)等。时间信息提取单元可以提取与订单相关的时间信息(例如发送订单的时间、预约出发的时间、预约出发时间所处的时段等)。位置信息提取单元可以提取与订单相关的位置信息(例如出发地、目的地、出发地所处的区域、出发地周围的交通路况、目的地周围的交通路况等)。解析单元可以分析与订单相关的时间信息、位置信息等。例如，解析单元可以将位置信息从文字描述转换为地址坐标。文字描述可以指地点的名称、门牌号、建筑名称等中的一种或几种，地址坐标可以指某个地点的坐标信息，例如经纬度坐标。处理单元可以为处理订单信息提取模块510所提取的一种或多种与订单相关的信息。处理方式可以包括但不限于计算、识别、验证、判断、筛选等中的一种或多种。
用户信息提取模块520可以提取与用户相关的直接或间接的信息。在一些实施例中，所述用户可以包括乘客或者司机。在一些实施例中，用户信息可以是历史用户信息、实时用户信息，或预测用户信息等中的一种或多种。所述用户信息可以是用户身份信息、用户终端设备信 息、用户偏好信息、用户历史订单信息、用户信用信息等中的一种或多种的组合。其中，所述用户身份信息可以包括但不限于用户的姓名、昵称、性别、国籍、职业、年龄、联系方式(电话号码、手机号码、社交账号信息(如微信号码、QQ号码和LinkedIn等)等可以联系到本人的方式等)、驾驶证、使用时间、驾龄等中的一种或多种。其中，所述用户终端设备信息可以包括但不限于通信设备信息(例如，设备型号、网络模式、设备接入网络的时间等)、交通设备信息(例如，车辆型号、车牌号、每公里油耗、剩余油量、车龄、后备箱大小、全景天窗、历史维修情况等)、其他设备信息(例如，携带的急救医疗设备的信息、灭火设备的信息)等中的一种或多种。所述用户偏好信息可以包括但不限于乘客对司机的偏好、司机对乘客的偏好、用户对于出发地、目的地、等待时间等的偏好等中的一种或多种。所述用户历史订单信息可以包括但不限于司机历史接单数量、乘客历史订单数量、用户历史订单的出发地、目的地、出发时间、等待时间等中的一种或多种。所述用户信用信息可以包括但不限于用户历史爽约比例、用户交通违章信息、用户银行信息记录、用户历史付费记录等中的一种或多种。用户信息可以实时提取，或非实时提取。例如，部分用户信息可以实时提取，部分用户信息可以非实时提取。提取的用户信息可以存储在用户信息提取模块520、存储模块220、信息源160、数据库130、或者任何在本申请中所描述的集成在系统中或独立于系统外的存储设备中。
在一些实施例中，用户信息提取模块520还可以包括一个或多个子单元，例如信息接收单元(未在图5中显示)、信息解析单元(未在图5中显示)和信息传输单元(未在图5中显示)。信息接收单元可以接收或读取用户信息。具体例如，司机所发送的信息可以是经定位技术所确定的司机当前位置、司机所行驶的速度、司机所反馈的当前服务状态(例如，载客、等待载客、空驶)、司机对服务请求的选择、确认或拒绝信息等中的一种或多种。上述信息可以是自然语言文本信息、二进制信息、音频信息(例如，包括司机的语音输入)、图 像信息(例如，静止图片或视频)以及其他类型的多媒体信息等中的一种或多种。信息解析单元可以对上述信息进行整理或分类，例如转换为可读取或可存储的格式等。信息传输单元可以接收或发送信息。信息传输单元可以包括一个或多个有线或无线的收发设备。
环境信息提取模块530可以提取与环境相关的直接或间接的信息。在一些实施例中，所述环境信息可以是实时环境信息、历史环境信息，预测环境信息等中的一种或多种。所述环境信息可以是天气信息、交通信息、事件信息、地理信息等中的一种或多种的组合。其中，所述天气信息可以包括但不限于温度(例如，最高气温、最低气温)、湿度、天气的类型(例如，晴、多云、阴、雨、雪、浮尘、扬沙、霾、风)、不同类型天气的数量指标(例如，降雨量、降雪量、雾霾指数、风速)等中的一种或多种。所述交通信息可以包括但不限于道路的位置、道路是否通畅、限速情况、是否有突发情况(例如，交通事故、养护施工、交警管制)等中的一种或多种。所述事件信息可以包括但不限于节假日信息、重大活动等中的一种或多种。所述地理信息可以包括但不限于区域划分信息、经纬度信息、建筑物信息等中的一种或多种。环境信息可以实时提取，或非实时提取。提取的环境信息可以存储在环境信息提取模块530、存储模块220、信息源160、数据库130或者任何在本申请中所描述的集成在系统中或独立于系统外的存储设备中。上述提取的订单信息、用户信息和环境信息可以实时或非实时地传输至计算模块570进行进一步的计算分析，或实时或非实时地传输至订单分配模块540或调度模块550用于订单的分配或者运力调度。例如，环境信息获取模块530在获取交通事故信息后，可以启动提示信息推送调度策略，实时地将事故信息通过乘客接口230和/或司机接口240传输给乘客和/或司机。
在一些实施例中，环境信息提取模块530还可以包括一个或多个子单元，例如信息接收单元(未在图5中显示)、信息解析单元(未在图5中显示)和信息传输单元(未在图5中显示)。信息接收单元可以接收或读取环境信息。具体例如，特定时间和特定地点的天气信 息、预测得到的未来时段道路拥堵状况、特定时间和特定地点的交通事故信息等中的一种或多种。上述信息可以是自然语言文本信息、二进制信息、音频信息(例如，包括司机的语音输入)、图像信息(例如，静止图片或视频)以及其他类型的多媒体信息等中的一种或多种。信息解析单元可以对上述信息进行整理或分类，例如转换为可读取或可存储的格式等。信息传输单元可以接收或发送信息。信息传输单元可以包括一个或多个有线或无线的收发设备。
订单分配模块540可以向用户分配待分配订单。在一些实施例中，订单分配模块540可以集成在乘客接口230和/或司机接口240中。订单分配模块540可以实时或非实时地从其他模块中读取排序结果、用户特征、订单信息、判断结果等中的一种或多种。在一些实施例中，订单分配模块540可以读取计算模块570计算获得的调度策略，根据调度策略分配订单。在一些实施例中，订单分配模块540可以和调度模块550集成在一个独立模块中，同时实现调度策略推送和订单发布的功能。
调度模块550可以向用户发送调度策略。在一些实施例中，调度策略可以来源于调度策略计算单元579的计算结果，可以是其他单元(例如，特征指标计算单元573、预测模型计算单元577)计算的结果，或直接从其他模块(例如，订单信息提取模块510、用户信息提取模块520、环境信息获取模块530)获取的信息。例如，在供求密度推送策略中，调度模块550可以直接接收来自预测模型计算单元577计算的供求密度信息，并将这些信息发送给用户。又例如，在提示信息推送策略中，环境信息获取模块530在获取交通事故信息后直接由调度模块发送给用户。在一些实施例中，调度模块550可以集成在乘客接口230和/或司机接口240中。
计算模块570可以计算调度策略。在一些实施例中，计算模块570可以包括一个或多个区域信息计算单元571、特征指标计算单元573、订单分组计算单元575、预测模型计算模块577、和调度信息计算模块579。除上述模块之外，计算模块570还可以包括一个或多个其他模块 或单元。计算模块570的内部还可以集成一个或多个存储单元(未在图5中显示)，用于存储获取的订单信息、用户信息、环境信息和/或计算得到的调度策略。计算获得的调度策略可以实时或非实时地传输至订单分配模块540或调度模块550以进行订单的分配或调度信息的发布。在一些实施例中，计算模块570所使用的计算方法可以包括但不限于最小-最大标准化、Z-score标准化、按小数定标标准化、线性函数法、对数函数法、反余切函数法、范数法、历史阈值迭代、建模法、最小二乘法、消元法、降次法、代入法、图象法、比较法、放缩法、向量法、归纳法、反证法、穷举法、配方法、待定系数法、换元法、拆项法、补项法、因式分解法、平行移动法、函数逼近法、插值法、曲线拟合法、积分法、微分法、扰动法等中的一种或多种。计算过程中所涉及的信息可以从订单信息提取模块510、用户信息提取模块520、环境信息提取模块530获取，也可以从数据库130和/或信息源160中获取。
区域信息计算单元571可以处理与区域划分相关的信息。所述处理可以包括但不限于进行区域划分、合并、拆分、查找等中的一种或多种。区域信息计算单元571还可以包括一个或多个子单元。例如，区域信息计算单元571可以包括区域划分子单元5711(未在图5中显示)、标志地点确定子单元5713(未在图5中显示)、区域归属判断子单元5715(未在图5中显示)、区域合并子单元5717(未在图5中显示)等中的一种或多种。
特征指标计算单元573可以计算特征指标。所述特征指标包括但不限于区域特征指标、用户特征指标、订单特征指标等中的一种或多种。特征指标计算单元573还可以包括一个或多个子单元。例如，特征指标计算单元573可以包括区域特征计算子单元5731(未在图5中显示)、订单特征计算子单元5732(未在图5中显示)、供求特征计算子单元5733(未在图5中显示)、用户特征计算子单元5734(未在图5中显示)、热点特征计算子单元5735(未在图5中显示)、概率计算子单元5736(未在图5中显示)、环境特征计算子单元5737(未在 图5中显示)等中的一种或多种。
订单分组计算单元575可以进行订单分组。所述订单可以包括但不限于历史订单、实时订单、预约订单、预测订单等中的一种或多种。调度策略计算单元579可以包括一个或多个子单元，例如，存储子单元(未在图5中显示)。
预测模型计算单元577可以进行各种预测。所述预测的内容可以包括但不限于对未来订单量、用户数量、供求密度、订单密度、环境信息等中的一种或多种信息的预测。预测模型计算单元577可以包括一个或多个子单元。例如，预测模型计算单元577可以包括基于区域特征的预测子单元5771(未在图5中显示)、基于环境信息的预测子单元5773(未在图5中显示)、订单接收方预测子单元5775(未在图5中显示)、和订单量预测子单元5777(未在图5中显示)等中的一种或多种。
调度策略计算单元579可以进行调度策略的计算。所述调度策略可以包括但不限于供求密度推送策略、热点特征推送策略、统计特征推送策略、订单推送策略、订单调整策略、或提示信息推送策略等中的一种或多种的组合(详细描述见图3)。调度策略计算单元579可以包括一个或多个子单元。例如，调度策略计算单元579可以包括供求调整策略判断子单元5791(未在图5中显示)、高概率用户选择子单元5792(未在图5中显示)、区域用户选择子单元5793(未在图5中显示)、高概率订单选择子单元5794(未在图5中显示)、区域订单选择子单元5795(未在图5中显示)、调度量计算子单元5796(未在图5中显示)、调度信息查找子单元5797(未在图5中显示)、和订单与用户匹配子单元5798(未在图5中显示)等中的一种或多种。
在一些实施例中，处理模块210内部可以集成一个或多个存储模块(未在图5中显示)。存储模块(未在图5中显示)可以存储其他各个模块所提取、计算、生成的各种信息及中间数据。在一些实施例中，处理模块210内部的各个子模块510-570内部可以集成各自的存储单元(未在图5中显示)，用于存储信息或中间数据。
在一些实施例中，处理模块210中的各个子模块510-570所执行的运算或处理可以是基于逻辑的运算，如与或非运算；或是基于数值的运算。处理模块210中的各个子模块510-570可以包含一个或多个处理器，处理器可以是任何通用处理器，例如，一个经过编程的可编程逻辑器件(PLD)，或者一个专用集成电路(ASIC)，或者一个微处理器，或者是一个系统芯片(SoC)等，还可以是一个数字信号处理器(DSP)等等。各个子模块510-570中的两个或者更多的单元可以被集成在一个硬件设备上，或是彼此独立的两个或者更多的硬件设备上。应当理解，处理模块210中的各个子模块510-570可以利用各种方式来实现。例如，在一些实施例中，订单引擎110或按需服务系统105可以通过硬件、软件或者软件和硬件的结合来实现，不仅可以由诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，或用例如由各种类型的处理器所执行的软件实现，还可以由上述硬件电路和软件的结合(例如，固件)来实现。
根据本申请的一些实施例，图6所示是处理模块210一个示意图。如图6中所示，处理模块210可以包括一个或多个订单信息提取模块510、用户信息提取模块520、环境信息提取模块530、订单分配模块540、调度模块550、和计算模块570等。计算模块570可以包括一个或多个区域信息计算单元571、特征指标计算单元573、预测模型计算单元577及其他单元(未在图6中显示)。其中，区域信息计算单元571可以包括区域划分子单元5711及其他子单元(未在图6中显示)。特征指标计算单元573可以包括区域特征指标计算子单元5731及其他子单元(未在图6中显示)。预测模型计算单元577可以包括基于区域特征的预测子单元5771及其他子单元(未在图6中显示)。在一些实施例中，订单信息提取模块510、用户信息提取模块520、环境信息提取模块530、订单分配模块540、调度模块550中的一个或多个模块可以分别与计算模块570相连。如图6所示，各模块及单元之间的连接方式可以是有线的或无线的，各个模块及单元之间可以 进行信息通信。
订单信息提取模块510可以获取订单信息。用户信息提取模块520可以获取用户信息。环境信息提取模块530可以获取环境信息。订单分配模块540可以向用户分配待分配订单。调度模块550可以向用户发送调度策略。相关内容在图5中有详细描述，在此不再赘述。
区域划分子单元5711可以进行区域的划分。区域划分方法可以包括按照网格的划分方法、按照簇的划分方法、按照特定规则(例如，行政区域)的划分方法等中的一种或者多种的组合(详细描述见图7-A，图7-B，图7-C)。
区域归属判断子单元5715可以用于确定特定位置所属区域，也可以用于确定特定区域内的用户情况。所述用户可以是司机或乘客。所述特定位置可以是司机的当前位置，或是订单的出发位置、订单的目的位置等。所述位置信息可以是由定位技术定位到的乘客端设备120和/或司机端设备140的位置坐标，或是乘客或司机输入的当前所在位置等。其中，所述定位技术包括但不限于全球定位系统(GPS)技术、全球导航卫星系统(GLONASS)技术、北斗导航系统技术、伽利略定位系统(Galileo)技术、准天顶卫星系统(QAZZ)技术、基站定位技术、Wi-Fi定位技术、交通工具自带的各种定位测速系统等中的一种或多种。例如，可以基于Wi-Fi定位技术获取当前位置的基本定位信息。一个无线路由器都有一个全球唯一的Media Access Control(MAC)地址，并且一般来说无线路由器在一段时间内不会移动。乘客端设备120在开启Wi-Fi的情况下，即可扫描并收集周围的路由器信号获取路由器广播出来的MAC地址。乘客端设备120可以将这些能够标示路由器的数据发送到定位模块(未显示在图6中)。定位模块(未显示在图6中)可以根据收到的数据在数据库130中检索出相关路由器的地理位置，并结合乘客端设备120所发送的其收到的不同路由器信号强弱程度，计算出乘客端设备120的位置。
区域特征指标计算子单元5731可以进行区域特征指标的计算。其中，所述区域特征指标可以包括但不限于区域的基础特征指标、历 史特征指标、实时特征指标中的一种或者多种的组合。在一些实施例中，所述基础特征指标可以包括但不限于周末信息、节假日信息、当前时间、与特定分区相关的天气信息、活动信息以及商圈信息。可以理解，工作日和周末的打车需求可能有显著不同，因此是否为周末的周末信息可以是影响运力调度基础特征指标之一。当前时间也是影响运力调度的一个基础特征指标，尤其是与特定的商圈信息相结合。例如，国贸地区在工作日的下午6：00至晚上11：00对运力的需求较大。天气信息也是影响运力调度的一个基础特征指标，对于像北京这样的大城市而言，不同区域的天气情况可能不同。例如，国贸地区已经下雨而回龙观地区仍然是晴天，国贸地区的运力需求可能因为天气而产生变化。在一些实施例中，所述历史特征指标可以包括但不限于与特定分区相关的交通工具历史同期需求、与特定分区相关的成交率数据等。例如，国贸分区在2015年1月10日19：00-20：00的历史同期需求为800辆出租车，以及在此时间段内成交600个订单(成交率为75％)。在2016年10月10日18：55仅有200辆出租车，远低于历史同期水平，据此可以考虑从其他地区调度一些出租车至国贸分区。所述实时特征可以包括但不限于与特定分区相关的在当前时间之前时间周期内的交通工具需求数量、所述需求数量的变化量等中的一种或多种。例如，国贸分区在前3个小时内的出租车需求量分布是600辆、500辆、400辆，呈现需求量降低的趋势。此时，国贸分区的出租车有800辆，则可以考虑将一部分出租车调离国贸分区。区域特征指标计算子单元5731进行区域特征指标的计算方法可以包括但不限于统计、分组、求和、聚类等中的一种或多种。在一些实施例中，将上述各类或其他历史信息进行处理时，不同时段的历史信息可以有相同的影响，也可以有不同的影响。例如，与当前订单比较接近的时段的历史信息和与当前订单间隔比较遥远的时段的历史信息可以对处理结果有相同的影响。又例如，与当前订单比较接近的时段的历史信息也可以对处理结果较多的影响，而与当前订单间隔比较遥远的时段的历史信息可以对处理结果有较少的影响或没有影响。
基于区域特征的预测子单元5771可以进行指标的预测。预测的指标可以包括但不限于特定区域在特定时间段内的订单量、需求量、成交率数据等中的一种或多种。预测所使用的数据基础可以是区域特征指标计算单元5731计算得到的历史特征指标、实时特征指标、基础特征指标中的一种或多种的组合。预测所使用的数据基础也可以是来源于订单信息提取模块510、用户信息提取模块520和/或环境信息提取模块530直接获取的数据等中的一种或多种。
调度量计算子单元5796可以计算调度相关参数。所述调度相关参数可以包括但不限于实际调度量、潜在调度量、潜在成交量增量、潜在成交增量和、最大潜在成交增量和等中的一种或多种。所述调度相关参数的计算可以是基于实时的数据，历史数据，未来的数据中的一种或多种。例如，根据未来的天气情况，确定调度量。又例如，根据历史订单情况，确定当前的调度量。调度量计算的结果可以直接用于运力的调度，例如给相应数量的司机发送调度信息。也可以根据调度量计算的结果，选择发送或者不发送调度策略。例如，计算得到的调度量小于某一阈值时，可以暂时不启动调度策略。
需要注意的是，以上对处理模块的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。上述每一个模块或单元均可通过一个或多个部件实现，每个模块或单元的功能也并不局限于此。上述各个单元可以根据具体实施场景或需要选择添加或删除。显然，对于本领域的专业人员来说，在了解运力调度流程的基本原理后，可能在不背离这一原理的情况下，对处理模块的具体实施方式与步骤进行形式和细节上的各种修正和改变，还可以做出若干简单推演或替换，在不付出创造性劳动的前提下，对各模块或单元的顺序作出一定调整或组合，但是这些修正和改变仍在以上描述的范围之内。例如，在一些实施例中，可以添加一个提示信息生成单元，用于生成提示信息。所示提示信息生成单元可以在计算模块570内，可以在计算模块570外。
根据本申请的一些实施例，图7-A，图7-B，和图7-C是区域划分的示意图。所述区域划分可以是均匀的划分、或是不均匀的划分。 例如，将一个区域以长、宽均为1千米的网格进行均分。又例如，将面积较大的湖泊等车辆无法通行的地带划分为一个区域，将陆地部分进行均匀划分。在例如，一个区域可以有一个或多个中心，从一个中心向外不均匀地划分，靠近中心的部分间隔小，远离中心的部分间隔大。在一些实施例中，区域的划分可以对应于一定的面积，也可以与面积无关。在一些实施例中，区域中的位置可以连续也可以不连续。例如，将由一条河流间隔的区域划入同一个子区域，而该河流被划入另外一个子区域。在一些实施例中，所述区域划分可以是一次完成，也可以是多次划分结果的综合。例如，在前一次划分结果的基础上，按照一些条件对区域进行合并或再划分。又例如，在使用划分结果的过程中，可以根据实际需要不断调整划分结果。区域的表示方法可以包括但不限于用坐标点进行描述、用经纬度进行描述和/或其他可以确定一个位置信息的方式进行描述。
如图7-A所示，在一些实施例中，可以按照网格进行区域划分。按照网格的区域划分方法可以包括但不限于自由网格划分、映射网格划分、线网格划分、面网格划分、体网格划分、扫掠网格划分、混合网格划分、基于自由度耦合和约束方程的网格划分、基于子区模型的网格划分等中的一种或多种。在一些实施例中，按照网格的划分方法可以包括：定义单元属性、在几何模型上定义网格属性、划分网格等步骤中的一种或多种。
如图7-B所示，在一些实施例中，可以按照簇进行区域划分。所述按照簇的区域划分方法，可以把特征点(721a-n)进行聚类，以形成不同的子区域(731a-n)。所述特征点可以是用户所对应的位置信息，订单所对应的位置信息(例如，出发地、目的地)，由其他信息所确定的位置信息等中的一种或多种。在一些实施例中，所示特定点可以代表订单的出发位置，则每一个子区域可以对应于一个订单出发位置的集中区域。所示按照簇的区域划分方法使用的算法可以是分裂聚类算法、层次聚类算法、基于密度的聚类算法、基于网格的聚类算法、基于模型的聚类算法等中的一种或多种。分裂聚类算法可以包括但不 限于K-平均聚类算法、基于随机选择的聚类算法(CLARANS)、基于划分的聚类算法(FCM)等。在一些实施例中，分裂聚类算法可以首先创建K个划分，然后利用循环定位技术通过将对象从一个划分移动到另一个划分来改善划分的结果。所述K个划分可以是自适应计算的结果，或是预先设定。其中，层次聚类算法可以包括但不限于BIRCH算法、CURE算法、ROCK算法、CHEMALOEN算法等中的一种或多种。在一些实施例中，层次聚类算法可以采用自上而下的操作方式，或自下而上的操作方式。基于密度的聚类算法可以包括但不限于DBSCAN算法、OPTICS算法等中的一种或多种。在一些实施例中，基于密度的聚类算法可以根据对象周围的密度不断增长聚类。基于网格的聚类算法可以包括但不限于STING算法、CLIQUE算法等。在一些实施例中，基于网格的聚类算法首先将空间划分为有限个单元以构成网格结构，然后利用网格结构完成聚类。其中，基于模型的聚类算法包括但不限于统计COBWEB方法、CLASSIT方法等中的一种或多种。
如图7-C所示，在一些实施例中，可以按照特定规则(例如，行政区域、地理信息)进行区域划分。其中，所述行政区域包括但不限于省、市、县、乡、镇、街道等中的一种或多种。例如，可以将海淀区划分入一个子区域。所述地理信息可以包括但不限于地貌、气象、降水、地质、水文信息等中的一种或多种。例如，可以将平均海拔在特定阈值范围内的位置划分入一个子区域。
以上对区域划分方法的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。显然，对于本领域的专业人员来说，在了解各种划分方法的基本原理后，可能在不背离这一原理的情况下，对划分方法的具体实施方式与步骤进行形式和细节上的各种修正和改变，但是这些修正和改变仍在以上描述的范围之内。例如，例如，可以采用随机的划分方式，随机选择一些位置划归如一个区域。又例如，可以直接采用其他系统中已经存在的区域划分方式等。又例如，可以根据特定时期的单位面积订单密度进行区域的划分等。
根据本申请的一些实施例，图8所示是基于调度量预测的运力调度的一个示例性流程图。
在步骤801，可以根据一定的区域划分方法，进行区域划分。在一些实施例中，区域划分可以由区域划分子单元5711执行。区域划分方法可以包括按照网格的划分方法、按照簇的划分方法、按照特定规则的划分方法等中的一种或者多种的组合(详细描述见图7-A，图7-B，和图7-C)。例如，将北京按照一周内的所有订单坐标信息进行聚类，得到937个分区以及相应的中心点。又例如，将北京按照行政区域进行划分，划分为包括东城区、西城区、崇文区、密云县等在内的18个区/县。
在步骤803，可以获取与分区相关的当前服务供给量。当前服务供给量的获取可以由区域特征计算子单元5731执行。具体地以交通服务为例，当前服务供给量可以由多个指标构成，包括但不限于当前交通工具量、交通工具的距离、交通工具的行驶速度、燃油量、剩余油量等信息中的一种或多种。在一些实施例中，区域特征计算子单元5731不仅可以计算区域的当前需求量，还可以计算一些其他指标。所述其他指标可以包括但不限于区域的实时特征指标、历史特征指标和/或基础特征指标等中的一种或多种。
在步骤805，可以获取与分区相关的预期需求量。预期需求量的计算可以由基于区域特征的预测子单元5771执行。在一些实施例中，预期需求量的计算可以是基于历史特征指标、实时特征指标、基础特征指标中的一种或者多种进行。在一些实施例中，可以用随机森林的方法进行预期需求量的预测。
在步骤807，可以基于当前服务供给量和预期需求量，确定实际调度量。实际调度量的计算可以由调度量计算子单元5796执行。在一些实施例中，实际调度量的计算可以是所述预期需求量与所述当前服务供给量的差值。例如，当前国贸分区的当前交通工具预期需求量是800辆，当前的交通工具供给量是600辆，由此可以确定国贸分区的调度量是200辆。在一些实施例中，实际调度量的计算除了与预期 需求量、当前服务供给量相关外，还可以引入其他变量(例如，时间)。
以上对基于环境信息的供求调度过程的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。显然，对于本领域的专业人员来说，在了解各种算法的基本原理后，可能在不背离这一原理的情况下，对供求调度的具体实施方式与步骤进行形式和细节上的各种修正和改变，但是这些修正和改变仍在以上描述的范围之内。例如，步骤803和805可以同时进行，同时计算当前服务供给量与预期需求量，也可以先执行步骤805再执行步骤803。在一些实施例中，在任意两个步骤之间可以加入其他选择条件，例如将任意一个步骤的结果进行存储备份等。
根据本申请的一些实施例，图9所示是处理模块210的一个示意图。如图9中所示，处理模块210可以包括一个或多个订单信息提取模块510、用户信息提取模块520、环境信息提取模块530、订单分配模块540、调度模块550、和计算模块570等。计算模块570可以包括预测模型计算单元577、调度策略计算单元579及其他单元(未在图9中显示)。预测模型计算单元577可以包括基于环境信息的预测子单元5773及其他子单元(未在图9中显示)。调度策略计算单元579可以包括供求调整策略判断子单元5791及其他子单元(未在图9中显示)。在一些实施例中，订单信息提取模块510、用户信息提取模块520、环境信息提取模块530、订单分配模块540、调度模块550中的一个或多个模块可以分别与计算模块570相连。如图9所示，各模块及单元之间的连接方式可以是有线的或无线的；各个模块及单元之间可以进行信息通信。
订单信息提取模块510可以获取订单信息。用户信息提取模块520可以获取用户信息。环境信息提取模块530可以获取环境信息。订单分配模块540可以向用户分配待分配订单。调度模块550可以向用户发送调度策略。相关内容在图5中有详细描述，在此不再赘述。
基于环境信息的预测子单元5773可以基于环境信息进行数据预测。所述环境信息可以是天气信息、交通信息、事件信息、地理信息 等中的一种或多种的组合(详细描述见图5)。所述预测可以是一次性预测，或是反复预测。预测的内容可以包括但不限于特定区域和/或特定时间的订单数量、用户数量、成交量等中的一种或多种。预测中使用的方法可以是定性的预测方法，或定量的预测方法。例如，预测方法可以包括移动平均法、指数平滑法、趋势外推法、回归预测法、灰色预测法、移动自回归预测法、蛛网模型法、层次分析法、熵权法、神经网络法、遗传算法模型法等中的一种或多种。
供求调整策略判断子单元5791可以判断是否启动调度策略。所述判断可以以一种或多种方式进行，例如，阈值比较法、代入法等。所述判断的内容还可以包括对调度策略的选择。在一些实施例中，在供不应求的情况下，可以启动刺激供给和/或抑制需求的策略。例如，将运力从空闲区域调度到繁忙区域。又例如，提醒乘客打车难。在一些实施例中，在供过于求的情况下，可以启动刺激需求和/或抑制供给的策略。例如，增发打车补助以刺激乘客的打车需求。又例如，将运力从供给过盛区域调度到空闲区域。在一些实施例中，在供求不平衡的区域，还可以启动导流的调度策略。例如，在快车、顺风车、专车、出租车、拼车之间导流乘客。
需要注意的是，以上对处理模块的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。上述每一个模块或单元均可通过一个或多个部件实现，每个模块或单元的功能也并不局限于此。上述各个单元可以根据具体实施场景或需要选择添加或删除。显然，对于本领域的专业人员来说，在了解运力调度流程的基本原理后，可能在不背离这一原理的情况下，对处理模块的具体实施方式与步骤进行形式和细节上的各种修正和改变，还可以做出若干简单推演或替换，在不付出创造性劳动的前提下，对各模块或单元的顺序作出一定调整或组合，但是这些修正和改变仍在以上描述的范围之内。例如，可以在计算模块中集成一个或者多个存储模块，用于存储计算过程中的信息等。又例如，可以将基于环境信息的预测子单元和5773和供求调整策略判断子单元5791集成在同一模块中，在进行调度参数预测的同时进行 调度策略的选择与判断。
根据本申请的一些实施例，图10所示的是基于环境信息进行运力调度的一个示例性流程图。
在步骤1010，可以获取目标区域在目标时间点的订单接收方(例如，司机)信息。订单接收方信息的获取可以由用户信息提取模块520执行。所述目标区域可以是一个任意的区域，也可以是当前司机位置所在的区域。所述目标区域可以是一个固定的区域(例如，以天安门人民英雄纪念碑为中心的方圆5公里内)，也可以是一个变化的区域(例如，基于实时订单情况聚类得到的区域)。所述目标时间可以是当前时刻，也可以是一个任意制定的时刻。具体例如，可以获天安门区域在2016年1月29日16点的司机端设备140在线数量。
在步骤1020，可以获取目标区域在一个未来时间段的环境信息。环境信息的获取可以由环境信息提取模块530执行。所述环境信息可以是天气信息、交通信息、事件信息、地理信息等中的一种或多种的组合(详细描述见图5)。具体例如，所述环境信息可以是日降雨量信息，用a表示。当日降雨量a大于等于0.05毫米且小于等于10毫米时，表示小雨；当日降雨量a大于10毫米且小于等于30毫米时，表示中雨；当日降雨量a大于30毫米时，表示大雨。所述未来时间段可以是一个或多个特定的时刻。例如，当前时刻是星期五的7：00AM，未来时段可以是当前时刻未来1小时的时刻，即8：00AM。所述未来时间段可以是一个或多个特定的时间段。例如，当前时刻是星期五的7：00AM，未来时段可以是当前时刻未来1小时的时间段，即7：00AM-8：00AM。在一些实施例中，可以获取目标区域的每一个子区域的环境信息，或部分子区域的环境信息。
在步骤1030，可以获取目标区域在历史时间段的订单信息。订单信息的获取可以由订单信息提取模块510执行。所述订单信息可以是订单时间信息、订单类型信息、订单位置信息、订单价格信息等中的一种或多种的组合(详细描述见图5)。所述历史时间段可以是一个或多个特定的时刻，也可以是一个或多个特定的时间段。例如，在步骤 1020中当前时刻是星期五7：00AM，未来1小时的时段是7：00AM-8：00AM，由于打车需求有很强的星期周期性，历史时段即可以选取过去N天中的星期五的7：00AM-8：00AM所组成的多个时间段。
在步骤1040，可以获取目标区域在历史时间段的环境信息。环境信息的获取可以由环境信息提取模块530执行。该步骤可以作为一个可选的步骤出现。在一些实施例中，历史订单信息中可以包括与该订单相关的环境信息。
在步骤1050，可以根据获取的订单接收方信息、环境信息和订单信息，判断是否需要启动调度策略。所述判断过程可以由模块5791执行。在一些实施例中，所述判断过程中可以包括对供需基准值、供需预测值等的计算等(详细内容见图11)。
在步骤1060，若需要启动调度策略，根据判断结果启动相应的调度策略。所述调度策略可以是供求密度推送策略、热点特征推送策略、统计特征推送策略、订单推送策略、订单调整策略、或提示信息推送策略中的一种或多种的组合(详见图3)。所述调度策略可以是发送给司机的调度策略，或发送给乘客的调度策略。在一些实施例中，为了应对供不应求的情况，可以给司机发送刺激供给的调度策略。例如，增加司机奖励、动态调价、将运力从空闲区域调度到繁忙区域等中的一种或多种。在一些实施例中，为应对供不应求的情况，可以给乘客发送抑制需求的调度策略。例如，提醒乘客打车难、提醒乘客等待时间长、提醒乘客加小费、动态调价、将叫车需求导流到需求不足的产品线(打车、专车、拼车、顺丰车等)等中的一种或多种。在一些实施例中，为应对供过于求的情况，可以给司机发送抑制供给的调度策略。例如，提醒司机乘客少、提醒司机等待时间长、减少司机的接单补助、动态调价、将运力从过盛区域调度到不足的区域等中的一种或多种。在一些实施例中，为应对供过于求的情况，可以给乘客发送刺激需求的调度策略。例如，增加乘客乘车优惠、动态调价、给予其他乘车补助(例如，在一天内乘车3次可以换取一次免费乘车的机会、乘车即可获得特定超市的消费代金券)、提醒乘客等待时间短(例如， 与其他出行方式，如公共交通，相比较)等中的一种或多种。
以上对基于环境信息的供求调度过程的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。显然，对于本领域的专业人员来说，在了解各种算法的基本原理后，可能在不背离这一原理的情况下，对供求调度的具体实施方式与步骤进行形式和细节上的各种修正和改变，但是这些修正和改变仍在以上描述的范围之内。例如，在一些实施例中，在步骤1020之后可以增加一个判断的步骤，如果满足预设的条件(例如，日均降雨量超过100毫米/天，达到了大暴雨的程度)可以不经过1030-1050的步骤而直接启动相应调度策略。
根据本申请的一些实施例，图11是确定是否需要启动调度策略的方法的一个示例性流程图。图11所描述的步骤1101-1113可以由供求调整策略判断子单元5791执行。
在步骤1101，可以根据订单信息和订单接收方信息，计算供求基准值。在一些实施例中，供求基准值可以用打车请求数量和在线司机数量之差表示。在一些实施例中，供求基准值可以用打车请求数量和在线司机数量的比值表示。
在步骤1103，可以根据环境信息和供求基准值，计算供求预测值。所述环境信息可以包括未来时段的环境信息，也可以包括历史时段的环境信息。
在步骤1105-1113可以基于供求预测值进行判断，根据判断的结果决定是否需要启动调度策略。如果判断的结果是不启动调度策略，步骤1113将可以被执行。如果判断的结果是需要启动供求调整策略，则处理模块210可以根据判断的结果选择启动相应的调度策略。
在步骤1105，供求调整策略判断子单元5791可以比较供求预测值和预设供不应求阈值的大小。如果供求预测值大于预设供不应求阈值，则步骤跳转至1109启动预设的供不应求情况下的调度策略。如果供求预测值小于或者等于预设供不应求阈值，则步骤跳转至1107进行进一步的判断。
根据本申请的一些实施例，步骤1105中供求预测值大于预设供不 应求阈值可以具体表示为公式(1)所示的内容：
Figure PCTCN2016073559-appb-000001
其中，a为日降雨量(例如，100毫米/天)，D为订单请求数量，S为订单接收方数量，T1为预设的供不应求阈值，
Figure PCTCN2016073559-appb-000002
为供需基准值，
Figure PCTCN2016073559-appb-000003
为供需预测值。
在步骤1107，供求调整策略判断子单元5791可以比较供求预测值和预设供过于求阈值的大小。如果供求预测值小于预设供过于求阈值，则步骤跳转至1111启动预设的供过于求情况下的调度策略。如果供求预测值大于或者等于预设的供过于求阈值，则步骤跳转至1113不启动预设调度策略。
根据本申请的一些实施例，步骤1105中供求预测值小于预设供过于求阈值可以具体表示为公式(2)所示的内容：
Figure PCTCN2016073559-appb-000004
其中，a为日降雨量(例如，100毫米/天)，D为订单请求数量，S为订单接收方数量，T2为预设的供不应求阈值，
Figure PCTCN2016073559-appb-000005
为供需基准值，
Figure PCTCN2016073559-appb-000006
为供需预测值。
以上对基于环境信息的供求调度过程的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。显然，对于本领域的专业人员来说，在了解各种算法的基本原理后，可能在不背离这一原理的情况下，对供求调度的具体实施方式与步骤进行形式和细节上的各种修正和改变，但是这些修正和改变仍在以上描述的范围之内。例如，步骤1105和1107可以同时进行，同时判断供求预测与预设供不应求阈值和预设供过于求阈值的大小关系。在一些实施例中，在任意两个步骤之间可以加入其他选择条件，例如将任意一个步骤的结果进行存储备份等
根据本申请的一些实施例，图12所示是处理模块210的一个示意图。如图12中所示，处理模块210可以包括一个或多个订单信息提取模块510、用户信息提取模块520、环境信息提取模块530、订单 分配模块540、调度模块550、和计算模块570等。计算模块570可以包括区域信息计算单元571、特征指标计算单元573、调度策略计算单元579及其他单元(未在图12中显示)。区域信息计算单元571可以包括区域合并子单元5717及其他子单元(未在图12中显示)中的一种或多种。特征指标计算单元573可以包括供求特征计算子单元5733、热点特征计算子单元5735、概率计算子单元5736及其他子单元(未在图12中显示)中的一种或多种。调度策略计算单元579可以包括区域用户选择子单元5793、区域订单选择子单元5795、高概率用户选择子单元5792、高概率订单选择子单元5794及其他子单元(未在图12中显示)中的一种或多种。在一些实施例中，订单信息提取模块510、用户信息提取模块520、环境信息提取模块530、订单分配模块540、调度模块550中的一个或多个模块可以分别与计算模块570相连。如图12所示，各模块及单元之间的连接方式可以是有线的或无线的，各个模块及单元之间可以进行信息通信。
订单信息提取模块510可以获取订单信息。用户信息提取模块520可以获取用户信息。环境信息提取模块530可以获取环境信息。订单分配模块540可以向用户分配待分配订单。调度模块550可以向用户发送调度策略。相关内容在图5中有详细描述，在此不再赘述。
区域合并子单元5717可以进行区域的合并。所述区域可以是区域划分子单元(未在图12中显示)进行区域划分的结果，或从其他信息源直接读取的区域信息(例如，订单信息中可以包含订单的区域归属信息)。在一些实施例中，根据不同的特征参数(例如，订单数量、用户数量、供求特征信息)对区域进行合并。所述合并可以是一个或者多个子区域合并为一个更大的子区域，或一个子区域拆分为一个或多个不同的子区域。合并得到的区域信息可以存储在合并区域子单元5717、存储模块220或任何在本申请中所描述的集成在调度引擎110或按需服务系统105中或独立其外的存储设备中。
供求特征计算子单元5733可以计算供求特征指标。供求特征指标可以包括实时供求特征指标、历史供求特征指标、预测供求特征指 标等中的一种或多种。供求特征可以表示为订单量与订单接收方的数量比值，订单密度，其他能反应供求关系的指标等中的一种或多种。订单量与订单接收方数量的比值中，订单量可以是实时订单量、历史订单量、预测订单量，订单接收方数量可以是实时订单接收方数量、历史订单接收方数量、预测订单接收方数量等中的一种或多种。订单密度可以是订单的面积密度、订单的时间密度、订单的面积与时间的复合密度等中的一种或多种。计算得到的供求特征信息可以存储供求特征计算子单元5733、存储模块220，任何在本申请中所描述的集成在调度引擎110或按需服务系统105中或独立其外的存储设备中。
热点特征计算子单元5735可以计算区域的热点特征指标。热点特征指标可以包括实时热点特征指标、历史热点特征指标、预测热点特征指标等中的一种或多种。热点特征指标可以是用户的热点特征，订单的热点特征等中的一种或多种。热点特征可以表示为绝对的数量(例如，用一个区域的在线司机数量表示该区域的热点特征)，或相对的数量(例如，用一个区域在多个区域中在线司机数量的排名表示该区域的热点特征)。热点特征信息可以存储在热点特征计算子单元5735、存储模块220，或任何在本申请所描述的集成在调度引擎110或按需服务系统105中或独立其外的存储设备中。
概率计算子单元5736可以计算用户选取与该用户相关的订单的概率。所述用户可以是服务提供者(例如，司机)，或服务的需求方(例如，乘客)。所述用户与订单相关联，可以是基于位置信息的关联，基于时间信息的关联，基于偏好信息的关联，基于其他信息的关联等中的一种或多种。例如，订单描述的出发位置与司机位置的距离在预设的范围(例如，1千米、3千米)内，可以确定所述订单是与所述司机相关联的订单。又例如，订单的出发时间属于司机的空闲时间，可以确定所述订单是与所述司机相关联的订单。在一些实施例中，可以基于订单的特征(出发地、出发时间、目的的、希望到达时间、行李信息、小费等)、服务提供者的特征(驾龄、年龄、性别、历史接单情况、评价等级、有无违章记录、接单偏好等)、被服务方的特 征(性别、年龄、评价等级、健康情况、订单偏好等)、环境特征(天气情况、交通情况、事件信息等)等中的一种或者多种因素来确定用户选取与该用户相关联的订单的概率。计算得到的概率可以存储在概率计算子单元5736、存储模块220、或任何在本申请所描述的集成在调度引擎110或按需服务系统105中或独立其外的存储设备中。
区域用户选择子单元5793可以在特定区域内，针对每个订单，选择将其呈现的用户。区域订单选择子单元5795可以在特定区域内针对每个用户，选择向其呈现的订单。所述选择过程可以是随机的选择，或基于一定规则的选择。其中所述规则可以包括但不限于，基于概率、位置信息、用户偏好等中的一种或多种。所述用户可以来源于特定区域内部，或特定区域与其他区域相邻的边界区域。区域用户选择子单元5793和/或区域订单选择子单元5795的选择结果可以通过订单分配单元540推送给用户，或被存储在存储单元(未在图12中显示)中以备后续的处理。
高概率用户选择子单元5792可以针对每个订单，在于该订单相关联的用户中，选择选取该订单的概率较高的用户(即有比较高的可能性或概率会接受该订单的用户)。高概率订单选择子单元5794可以在与该用户相关联的订单中，选择该用户选取其概率较高的订单(即该用户有比较高的可能性或概率会接受的订单)。所述选择过程可以以排序的方式实现。例如，从高到低排序后选取前10名，或者前10％。所述选择过程可以以阈值的方式实现。例如，设定概率的阈值为0.90，高于这一阈值的订单或者用户即为概率较高的订单或者用户。
需要注意的是，以上对处理模块的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。上述每一个模块或单元均可通过一个或多个部件实现，每个模块或单元的功能也并不局限于此。上述各个单元可以根据具体实施场景或需要选择添加或删除。显然，对于本领域的专业人员来说，在了解运力调度流程的基本原理后，可能在不背离这一原理的情况下，对处理模块的具体实施方式与步骤进行形式和细节上的各种修正和改变，还可以做出若干简单推演或替换，在不付 出创造性劳动的前提下，对各模块或单元的顺序作出一定调整或组合，但是这些修正和改变仍在以上描述的范围之内。例如，区域用户选择子单元5793和高概率用户选择子单元5792可以集成在一个子单元中。又例如，可以添加一个或者多个存储单元，用于存储热点特征计算或供求特征计算的结果。图中虚线表示的各个单元均不是必须的，可以根据具体实施场景或需要选择添加或删除。
根据本申请的一些实施例，图13所示是基于环境信息进行运力调度的一个示例性流程图。
在步骤1301，可以获取特定区域的订单信息和区域的用户信息。订单信息的获取可以由订单信息提取模块510执行。所述订单信息可以是订单时间信息、订单类型信息、订单位置信息、订单价格信息等中的一种或多种的组合(详细描述见图5)。用户信息的获取可以由用户信息提取模块520执行。所述用户信息可以是用户身份信息、用户终端设备信息、用户偏好信息、用户历史订单信息、用户信用信息等中的一种或多种的组合(详细描述见图5)。
在步骤1303，可以确定区域的用户选取与该用户相关联的订单的概率。该步骤是一个可选的步骤，即步骤1301之后可以执行步骤1303，或不执行步骤1303。该概率可以反映出用户选择订单的兴趣。
在一些实施例中，可将每个订单与相关联的多个用户进行一一配对，并为每个配对计算配对中的用户选择该订单的概率。所述概率可以相同或不同。在一些实施例中，可以将每个订单与相关联的一组用户进行一对多的配对，并为每个配对计算配对中的一组用户选择该订单的概率。所述分组中的用户量可以相同或不同。在一些实施例中，与特定区域中的用户相关联的订单可以位于该区域中，或位于该区域之外。例如，与中关村区域中的司机赵某相关联的订单可以位于海淀黄庄区域。在一些实施例中，与特定区域中订单相关联的用户可以位于该区域中，或位于该区域之外。例如，与中关村区域订单相关联的司机可以位于海淀黄庄区域。
在步骤1305，可以确定供过于求的区域和供不应求的区域。供过 于求区域和供不应求区域的确定可以由供求特征计算子单元5733执行。在一些实施例中，供过于求区域和/或供不应求区域的确定可以通过订单数与服务提供者的数量的比值与特定阈值的比较获得。所述订单数可以是实际的订单数，历史的订单数，预测的订单数等中的一种或多种。所述订单数可以包括订单需求数量(例如，1001号订单描述有5人乘车，需要同时乘坐2辆车)的信息，或不包括订单需求数量的信息。所述服务提供者数量可以包括服务提供者服务提供能力数量(例如，司机李某的车可容纳的乘客数为4人，已有1人乘车，可容纳的拼车人数为3人)的信息，或不包括服务提供者的服务提供能力数量的信息。所述特定阈值可以是任意数值。在一些实施例中，所述特定阈值可以是1。在一些实施例中，所述特定阈值可以是小于1的数值(例如，0.01、0.5、0.6、0.9)，或远小于1的数值(例如，0.0001、0.0000001)等。在一些实施例中，所述特定阈值可以是大于1的数值(例如，1.1、1.3、1.9、10)，或远大于1的数值(例如，996、10000)等。所述用于确定供过于求区域和供不应求区域的特定阈值可以相等。例如，对应于供不应求和供过于求区域的阈值可以均设置为1，订单数与服务提供者的数量的比值大于等于1的区域是供不应求的区域，小于1的区域是供过于求的区域。所述用于确定供过于求和供不应求区域的特定阈值也可以不相等。例如，对应于供不应求区域的阈值可以设定为0.7，对应于供过于求区域的阈值可以设置为2。
在步骤1307，可以确定订单热点区域和用户热点区域。所述订单热点区域和用户热点区域的确定可以由热点特征计算子单元5735执行。
在一些实施例中，可以用订单数和/或订单密度与热点阈值的比较确定订单热点区域。所述订单数可以是实际的订单数，历史的订单数，预定的订单数，预测的订单数等中的一种或多种。所述订单数可以包括订单需求数量的信息，或不包括订单需求数量的信息。订单密度可以是订单的面积密度，订单的时间密度，订单的面积和时间的复合密度等中的一种或多种。例如，订单密度的值可以是100件订单/平方千 米、80件订单/分钟、120件订单/平方千米·分钟等中的一种或多种。所述订单热点阈值，可以是一个固定的数值，或一个变化的阈值(例如，随时间变化、随区域的特征变化)等。
在一些实施例中，可以用用户数和/或用户密度与用户阈值的比较确定用户热点区域。所述用户数可以是实际的用户数，历史的用户数，预测的用户数等中的一种或多种。所述用户数，当对应于服务提供者时，可以包括用户的服务能力数量信息，或不包括用户的服务能力数量信息。用户密度可以是用户的面积密度，用户的时间密度，用户的面积和时间的复合密度等中的一种或多种。例如，用户密度的值可以是100个用户/平方米、100个用户/分钟、个78用户/平方千米·分钟等中的一种或多种。所述用户热点阈值可以是一个固定的数值，或一个变化的阈值(例如，随时间变化、随区域的特征变化)等。
在一些实施例中，可以用排序的方式确定订单热点区域和/或用户热点区域。例如，调度引擎110可以监控每个区域中每个子区域(或网格)中的订单数和用户数的分布。具体而言，调度引擎110可以以例如每两秒钟一次的频率统计一个子区域(或网格)中在线订单和/或在线用户的数目。基于统计得到的信息，调度引擎110可以对每个区域订单数和/或用户数进行排序，然后选取排序较前(例如，前10％或者前100名)的区域作为订单和/或用户的热点区域。
在步骤1308，可以在订单热点区域和用户热点区域中分别确定供过于求和供不应求的区域。所述供过于求和供不应求的区域的确定过程可以由供求特征计算子单元5733执行。
在步骤1309，可以将一定量的订单热点区域合并为一个新的订单热点区域，将一定量的用户热点区域合并为一个新的用户热点区域。所述订单热点区域和用户热点区域的合并可以由区域合并子单元5717执行。在一些实施例中，可以是相邻的区域合并为一个新的订单热点区域和/或用户热点区域，或不相邻的区域合并为一个新的订单热点区域和/或用户热点区域。在一些实施例中，可以是两个区域区域合并为一个新的订单热点区域和/或用户热点区域，或两个以上(例如， 3、8、16、100)的区域合并为一个新的订单热点区域和/或用户热点区域。
在步骤1310，可以在新的订单热点区域和新的用户热点区域中分别确定供过于求和供不应求的区域。所属供过于求区域和供不应求区域的确定可以由供求特征计算子单元5733执行。
在步骤1311，可以在供过于求的区域中，针对一个订单，选择将其呈现的用户。该步骤可以由区域用户选择子单元5793执行。用户的选择方式可以是随机的，或按照一定的规则进行。例如，可以按照步骤1303确定的概率的大小进行选择。又例如，可以按照订单出发位置与用户当前位置从近到远选择。
在步骤1313，可以在供过于求的区域中，针对一个订单，在与该订单相关的用户中选择选取该订单的概率较高的用户。该步骤可以由高概率用户选择子单元5792执行。在一些实施例中，可以在与该订单相关联的用户中，按照用户选择该订单的概率从高到低排列，然后从中选择一定数量(例如，1个、10个)或者一定比例(例如，5％、10％)的用户。在一些实施例中，可以设定一个概率的阈值(例如，0.56、0.98)，可以通过阈值的比较确定与该订单相关的用户中选择选取该订单的高概率用户有哪些。
在步骤1315，可以在供不应求的区域中，针对一个用户，选择向其呈现的订单。该步骤可以由区域订单选择单元5795执行。订单的选择方式可以是随机的，或按照一定的规则进行。例如，可以按照步骤1303确定的概率的大小进行选择。又例如，可以按照用户对订单的目的地的偏好位置从近到远选择。
在步骤1317，可以在供不应求的区域中，针对一个用户，在与该用户相关联的订单中选择该用户选取其概率较高的订单。该步骤可以由高概率订单选择子单元5794执行。在一些实施例中，可以在于该用户相关联的订单中，按照用户选择该订单的概率从高到低排列，然后从中选择一定数量(例如，1件、10件)或者一定比例(例如，5％、10％)的订单。在一些实施例中，可以设定一个概率的阈值(例如， 0.56、0.96)，可以通过阈值的比较确定与该用户相关联的订单中该用户选取其概率较高的订单有哪些。
以上对基于环境信息的供求调度过程的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。显然，对于本领域的专业人员来说，在了解各种算法的基本原理后，可能在不背离这一原理的情况下，对供求调度的具体实施方式与步骤进行形式和细节上的各种修正和改变，但是这些修正和改变仍在以上描述的范围之内。例如，在一些实施例中，步骤1301开始之前可以加入一个区域划分的步骤。在一些实施例中，步骤1307-1310和步骤1313、1317可以作为可选的步骤出现。又例如，步骤1311和步骤1315可以按照任意顺序执行，可以先后执行，可以同时执行。在一些实施例中，在任意两个步骤之间可以加入其他选择条件，例如将任意一个步骤的结果进行存储备份等。
根据本申请的一些实施例，图14所示是处理模块210的一个示意图。如图14所示，处理模块210可以包括一个或多个订单信息提取模块510、用户信息提取模块520、环境信息提取模块530、订单分配模块540、调度模块550、计算模块570等。计算模块570可以包括区域信息计算单元571、调度信息计算单元579及其他单元(未在图14中显示)。区域信息计算单元571可以包括区域划分子单元5711、区域归属判断子单元5715及其他单元(未在图14中显示)。调度量计算单元579可以包括调度量计算子单元5796及其他单元(未在图14中显示)。在一些实施例中，订单信息提取模块510、用户信息提取模块520、环境信息提取模块530、订单分配模块540、调度模块550中的一个或多个模块可以分别与计算模块570相连。如图14所示，各模块及单元之间的连接方式可以是有线的或无线的，各个模块及单元之间可以进行信息通信。
订单信息提取模块510可以获取订单信息。用户信息提取模块520可以获取用户信息。环境信息提取模块530可以获取环境信息。订单分配模块540可以向用户分配待分配订单。调度模块550可以向用户发送调度策略。相关内容在图5中有详细描述，在此不再赘述。
区域划分子单元5711可以对预定范围进行区域划分。区域划分方法可以包括按照网格的划分方法、按照簇的划分方法、按照特定规则的划分方法等中的一种或者多种的组合(详细描述见图7-A，图7-B，和图7-C)。例如，区域划分可以基于行政区(例如，海淀区、朝阳区)，按经纬度，订单分布情况、商圈、建筑、街道名称等中的一种或多种。
区域归属判断子单元5715可以确定特定位置所属区域，或确定特定区域内的用户情况。所述特定位置可以是司机的当前位置，订单的出发位置，订单的目的位置等中的一种或多种。所述用户可以是司机或乘客。例如，司机赵某的当前位置是海淀大街3号，通过区域用户归属判断子单元5715的计算，可以确定赵某所在区域为中关村区域。又例如，通过区域归属判断子单元5715可以确定中关村区域内所有的司机或者下订单的乘客数量。关于区域判断子单元5715的更多描述详见图6，在此不再赘述。
调度量计算子单元5796可以计算调度相关参数。所述调度相关参数可以包括但不限于实际调度量、潜在调度量、潜在成交量增量、潜在成交增量和、最大潜在成交增量和等中的一种或多种。所述调度相关参数的计算可以是基于实时的数据，历史数据，未来的数据等中的一种或多种。关于调度量计算子单元5796的更多描述详见图6，在此不再赘述。
需要注意的是，以上对处理模块210的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。上述每个模块或单元并不是必须的，每一个模块或单元均可通过一个或多个部件实现，每个模块或单元的功能也并不局限于此。上述各个模块或单元可以根据具体实施场景或需要选择添加或删除。显然，对于本领域的专业人员来说，在了解运力调度流程的基本原理后，可能在不背离这一原理的情况下，对处理模块的具体实施方式与步骤进行形式和细节上的各种修正和改变，还可以做出若干简单推演或替换，在不付出创造性劳动的前提下，对各模块或单元的顺序作出一定调整、组合或拆分，但是这些修正和改变仍在以上描述的范围之内。例如，在一些实施例中，可以将区域 划分子单元5711和区域归属判断子单元5715集成在一个子单元中，在进行区域划分的同时即判断特定位置所述的区域。又例如，在一些实施例中，区域划分子单元5711、区域归属判断子单元5715和调度量计算子单元5796中同时集成了存储子单元(未显示在图14中)用户存储计算的原始数据、中间数据和/或结果信息。
根据本申请的一些实施例，图15所示是基于成交量信息的运力调度方法的一个示例性流程图。在一些实施例中，可以通过调节某个或某些自变量使因变量产生变化，从而使因变量达到特定的值，以实现促进交通工具使用率的目的。其中，所述自变量可以是服务提供者的数量、司乘比(司机数/乘客数)、订单数、服务提供者的增量、司乘比(司机数/乘客数)的增量、订单的增量等中的一种或多种。所述因变量可以是成交量、成交量增量、成交增量和、用户总体好评度、服务提供者抢单成功率分布(例如，大部分服务提供者抢单成功率很高、只有少部分服务提供者抢单成功率很高等)、服务提供者成交率分布(例如，大部分服务提供者成交率很高、只有少部分服务提供者成交率很高等)。在一些实施例中，在整个运力调度过程中，服务提供者总量或订单总量可以是变化的，或不变的。
为描述方便，以下关于图15所示的运力调度方法的描述以自变量是服务提供者的增量，因变量是成交增量和，服务提供者总数不变的条件为例。可以理解，关于图15所示的运力调度方法也可以在其他条件下进行，本申请在此不作限制。
在步骤1510，可以确定多个用户的区域分布。该确定过程可以由区域划分子单元5711和/或区域归属判断子单元5715实现。在一些实施例中，所述用户可以是服务提供者，或是服务请求者。为描述方便，以下关于图15所示的运力调度方法的描述以服务提供者为例。可以理解，关于图15所示的运力调度方法中的用户可以是服务请求者，例如，当该调度方法应用于游客调度系统中时，所述用户可以是服务请求者(例如，游客)。
在一些实施例中，划分区域的方式可以基于行政区(例如，海淀 区、朝阳区等)，经纬度，订单分布情况、商圈、建筑、街道名称等标志中的一种或多种。在一些实施例中，可以根据服务提供者的位置信息确定服务提供者所属区域，从而确定服务提供者在区域内的分布情况。可以理解，交通工具与服务提供者数目通常一致，因此在本申请中，服务提供者数目也可以与交通工具数交替使用。例如，在预定范围内，当前共有m个交通工具，n个热点区域，可以定义如下矩阵：
Figure PCTCN2016073559-appb-000007
其中，交通工具编号可以从1开始，区域编号可以从0开始，0可以表示预定范围内不属于热点区域的地带。在一些实施例中，所述热点区域可以是订单总量比较多的区域，订单密度比较大的区域，司乘比比较小的区域，订单数量增长速率比较快的区域，或其他可以体现热点特征的区域等中的一种或多种。
在步骤1520，可以基于区域分布计算区域内的潜在调度量。该计算潜在调度量的过程可以由调度量计算子单元5796实现。在一些实施例中，所述潜在调度量可以表示交通工具的调入或调出量。在一些实施例中，可以用A′n×m表示调度前交通工具在区域内的分布；An×m表示调度后交通工具在区域内的分布，可以得到公式(4)：
Figure PCTCN2016073559-appb-000008
其中，
Figure PCTCN2016073559-appb-000009
可以表示一个区域经过调度后，交通工具的增量，即第i个区域经过调度后，交通工具增加Δqi，其中Δqi可正可负。根据矩阵的基本运算，可以得到公式(5)：
Figure PCTCN2016073559-appb-000010
其中，
Figure PCTCN2016073559-appb-000011
可以表示m维的单位列向量：
Figure PCTCN2016073559-appb-000012
例如，在一些实施例中，预定范围内，当前有4个交通工具适于使用，并且当前有1个热点区域。在调度前，交通工具1在区域0，交通工具2在区域0，交通工具3在区域0，交通工具4在区域1。在 调度后，交通工具1在区域0，交通工具2在区域1，交通工具3在区域1，交通工具4在区域1。此时，调度前交通工具在区域内的分布A′n×m可以用公式(7)表示：
Figure PCTCN2016073559-appb-000013
调度后，交通工具在区域内的分布An×m可以用公式(8)表示：
Figure PCTCN2016073559-appb-000014
根据公式(4)-(8)可以得到：
Figure PCTCN2016073559-appb-000015
其中，公式(9)的计算结果可以表示区域0中调出2个交通工具，区域1中调入2个交通工具。
在步骤1530，可以基于区域的潜在调度量计算区域的潜在成交量增量。该计算潜在成交量增量的过程可以由调度量计算子单元5796实现。在一些实施例中，潜在成交增量与交通工具的增量、订单量、成交率等相关。在一些实施例中，成交率与司乘比(司机数/乘客数)相关。例如，成交率E和司乘比
Figure PCTCN2016073559-appb-000016
之间的关系可以用公式(10)表示：
Figure PCTCN2016073559-appb-000017
其中，k可以表示拟合系数，q可以表示服务提供者数目(例如，司机数)或是交通工具的数目，o可以表示订单量。
在一些实施例中，成交量可以表示为成交率与订单量的函数。例如，成交量S，可以用公式(11)表示：
Figure PCTCN2016073559-appb-000018
其中，k可以表示拟合系数，q可以表示服务提供者数目(例如，司机数)或交通工具的数目，o可以表示订单量。
在一些实施例中，为实现在不改变总的交通工具数目的基础上，通过运力调度来促进使用率，可以计算针对单个区域的成交量增量与 交通工具数据增量之间的关系。例如，通过对公式(11)进行微分，可以得到公式(12)：
Figure PCTCN2016073559-appb-000019
通过公式(12)可以看出：1)成交量增量与订单量正相关，即订单越多，则交通工具增量对成交量提升越明显；2)成交量增量与交通工具量负相关，即交通工具越少，则交通工具增量对成交量提升越明显；3)成交量增量与司乘比负相关，即司乘比越小，则交通工具增量对成交量提升越明显。
在一些实施例中，可以计算成交量增量与交通工具增量之间的函数关系。例如，通过对公式(12)进行积分，可以得到公式(13)：
Figure PCTCN2016073559-appb-000020
公式(13)可以简记为公式(14)：
Figure PCTCN2016073559-appb-000021
在一些实施例中，可以基于步骤1520得到的区域的交通工具增量以及获得的区域的潜在成交量增量，获得预定范围内的潜在成交增量和。
可以理解，本申请对成交量增量与交通工具增量之间的函数关系的描述仅是一个实施例，成交量增量与交通工具增量之间的函数关系不仅限于本申请所描述的函数关系，还可以是其他函数关系，本申请在此不作限制。
可以理解，以上对步骤1520和步骤1530的描述仅针对一个潜在调度方案。如果想计算出最大潜在成交增量和，需要针对多个潜在调度方案计算出各自的潜在成交增量和。在一些实施例中，可以针对所有潜在调度方案计算各自的潜在成交增量和，也可以针对部分潜在调度方案计算各自的潜在成交增量和。例如，可以设置一些约束条件筛选掉一部分潜在调度方案从而只选择一部分潜在调度方案进行计算。所述约束条件可以是对于任何一个潜在被调度的交通工具其距离预期前往的区域的调度距离不超过某一距离(例如，不能超过4千米)， 任何一个潜在被调度的交通工具对应的服务提供者在某一时间段内未执行载客任务(例如，连续10分钟内未接收订单)，对于单个区域而言司乘比不能超过某一阈值(例如，qi+Δqi/qi＜K)，或其他约束条件等中的一种或多种。
在步骤1540，可以基于区域的潜在成交量增量计算最大潜在成交增量和。该计算最大潜在成交增量和的过程可以由调度量计算子单元5796实现。在一些实施例中，多个潜在调度方案都可以产生预定范围内区域的潜在成交量增量，从而得出针对每个潜在调度方案的潜在成交增量和。通过对这些潜在成交增量和进行对比、分析、计算等处理过程，可以得到最大潜在成交增量和。
在步骤1550，可以基于最大潜在成交增量和确定各区域的实际调度量。该确定实际调度量的过程可以由调度量计算子单元5796实现。在一些实施例中，可以选择与最大潜在成交增量和对应的调度方案，并且可以将该调度方案确定为实际调度方案。在一些实施例中，可以根据实际调度方案对潜在被调度的交通工具对应的服务提供者发送调度策略，例如，可以根据实际调度方案将调度策略发送给移动设备2900。所述调度策略可以包括但不限于供求密度推送策略、热点特征推送策略、统计特征推送策略、订单推送策略、订单调整策略、或提示信息推送策略等中的一种或多种。在一些实施例中，可以在发送调度策略的同时对服务提供者给予奖励、补贴、优惠等，从而实现对服务提供者的有效调度。
在一些实施例中，对于上述潜在成交量最大化的优化求解，可以使用一些智能搜索算法，例如遗传算法、蚁群算法等中的一种或多种。例如，在使用爬山算法求解时，可以根据上述公式生成初始解，然后变换当前解的局部，生成新解；然后判断新解是否更优。如果新解更优，则使用新解替换当前解。如果新解并非更优，则输出当前解。例如，在使用遗传算法求解时，根据规则及一定的随机性，生成初始解种群；种群中的解两两交叉，生成新解，此时种群规模翻倍；确定适应函数，采用种群的平均值，低于平均值的解淘汰；确定退出函数， 达到一定迭代次数或结果收敛则退出，否则继续两两交叉生成新解。
需要注意的是，以上关于运力调度流程的描述，仅为描述方便，并不能把本申请限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解本申请的基本原理后，可以在不背离这一原理的情况下，对运力调度流程作出改变。例如，可以增加、减少、合并或拆分一些步骤。例如，在一些实施例中，可以将步骤1510拆分成三个步骤：针对预定范围划分区域、确定用户所属区域、确定区域内用户的分布情况。例如，在一些实施例中，可以在步骤1530和步骤1540之间添加一个计算预定范围内针对潜在调度方案的潜在成交增量和的步骤。该步骤也可以与步骤1530或步骤1540合并成为一个步骤。诸如此类的变形，均在本申请的保护范围之内。
根据本申请的一些实施例，图16所示是处理模块210的一个示意图。如图16所示，处理模块210可以包括一个或多个订单信息提取模块510、用户信息提取模块520、环境信息提取模块530、订单分配模块540、调度模块550、计算模块570等。其中，调度策略计算单元579可以包括订单与用户匹配子单元5798及其他单元(未在图16中显示)。在一些实施例中，订单信息提取模块510、用户信息提取模块520、环境信息提取模块530、订单分配模块540、调度模块550中的一个或多个模块可以分别与计算模块570或调度策略计算单元579相连。如图16所示，各模块及单元之间的连接方式可以是有线的或无线的，各个模块及单元之间可以进行信息通信。
订单信息提取模块510可以获取订单信息。环境信息提取模块530可以获取环境信息。订单分配模块540可以向用户分配待分配订单。调度模块550可以向用户发送调度策略。相关内容在图5中有详细描述，在此不再赘述。
用户信息提取模块520可以获取用户信息。所述用户信息可以包括但不限于基于车载诊断系统获取用户对应的车辆状态信息(更多详细的描述见图5)等。所述车辆状态信息可以包括但不限于车速、车辆加速度、位置信息、剩余能源量(例如，剩余油量、剩余电量)、 能源消耗量、能源消耗速率、车辆运行状态(例如，发动机运行状态、水箱运行状态、刹车系统运行状态、车身稳定系统运行状态、仪表系统运行状态安全系统运行状态等)等中的一种或几种的组合。所述车辆状态信息可以是历史数据，实时数据，预测数据等中的一种或多种。在一些实施例中，所述车载诊断系统可以是用户终端的一部分，也可以与用户终端相对独立。所述车载诊断系统可以被任何一个可以实现相同功能的系统代替，也可以被多个系统的组合代替。例如，所述车载诊断系统可以被速度检测系统、定位系统、车检系统的组合代替。
订单与用户匹配子单元5798可以为订单选择至少一个可以接受该订单的用户，或将订单信息和至少一个可以接受该订单的用户的车辆状态信息进行匹配，获得匹配结果。所述用户可以是消费方，也可以是服务提供方。例如，在打车系统中，所述用户可以是司机(代表服务提供方)，订单与用户匹配子单元5798可以完成乘客订单与司机的匹配。又例如，在加油、洗车等车辆服务站点主动推送服务订单的系统中，所述用户可以是车主(代表消费方)，订单与用户匹配子单元5798可以完成服务站点订单与车主的匹配。又例如，在餐馆主动推送用餐订单的系统中，所述用户可以是乘坐交通工具的乘客(代表消费方)，订单与用户匹配子单元5798可以完成餐馆订单与乘客的匹配。
需要注意的是，以上对处理模块的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。上述每个模块或单元并不是必须的，每一个模块或单元均可通过一个或多个部件实现，每个模块或单元的功能也并不局限于此。上述各个模块或单元可以根据具体实施场景或需要选择添加或删除。显然，对于本领域的专业人员来说，在了解运力调度流程的基本原理后，可能在不背离这一原理的情况下，对处理模块的具体实施方式与步骤进行形式和细节上的各种修正和改变，还可以做出若干简单推演或替换，在不付出创造性劳动的前提下，对各模块或单元的顺序作出一定调整、组合或拆分，但是这些修正和改变仍在以上描述的范围之内。例如，在一些实施例中，订单与用户匹配 子单元5798可以分为两个单元分别用于为订单选择至少一个可以接受该订单的用户以及将订单信息和至少一个可以接受该订单的用户的车辆状态信息进行匹配，获得匹配结果。诸如此类的变形，均在本申请的保护范围之内。
根据本申请的一些实施例，图17所示是运力调度系统的一个网络环境示意图。如图17所示，所述运力调度系统的网络环境可以包括一个车辆调度装置1710、一个或多个车载诊断模组1720、一个或多个用户终端1730。在一些实施例中，所述车辆调度装置1710可以对收集的信息进行分析加工以生成结果并发送所述生成结果。在一些实施例中，所述车载诊断模组1720可以获取用户的车辆状态信息。所述车辆状态信息可以包括但不限于车速、车辆加速度、位置信息、剩余能源量、能源消耗量、能源消耗速率、车辆运行状态(例如，发动机运行状态、水箱运行状态、刹车系统运行状态、车身稳定系统运行状态、仪表系统运行状态安全系统运行状态等)等中的一种或几种的组合。所述车辆状态信息可以是历史数据，实时数据，预测数据等中的一种或多种。所述车载诊断模组1720可以是用户终端的一部分，或与用户终端相对独立。所述车载诊断模组1720可以被任何一个可以实现相同功能的一个系统或多个系统的组合代替。例如，所述车载诊断模组1720可以被速度检测系统、定位系统、车检系统的组合代替。在一些实施例中，所述用户终端1730可以发送车辆状态信息，接收订单分配信息、调度策略等信息。所述用户终端1730可以包括但不限于笔记本、平板电脑、手机、个人数码助理(PDA)、电子手表、POS机、车载电脑、电视机、智能穿戴设备等中的一种或几种的组合。如图17所示，图中各个模块或单元之间的连接可以是有线的，或是无线的。在一些实施例中，车辆调度装置1710可以将调度策略或订单分配信息直接发送给用户终端1730。在一些实施例中，车辆调度装置1710可以将调度策略或订单分配信息发送给车载诊断模组1720，所述车载诊断模组1720再将所述调度策略或订单分配信息发送给用户终端1730。
需要注意的是，以上对运力调度系统网络环境的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。上述每个模块或单元并不是必须的，每一个模块或单元均可通过一个或多个部件实现，每个模块或单元的功能也并不局限于此。上述各个模块或单元可以根据具体实施场景或需要选择添加或删除。显然，对于本领域的专业人员来说，在了解运力调度流程的基本原理后，可能在不背离这一原理的情况下，对网络环境的具体实施方式与步骤进行形式和细节上的各种修正和改变，还可以做出若干简单推演或替换，在不付出创造性劳动的前提下，对各模块或单元的顺序作出一定调整、组合或拆分，但是这些修正和改变仍在以上描述的范围之内。
根据本申请的一些实施例，图18所示是基于车载诊断系统的运力调度方法的一个示例性流程图。
在步骤1805，可以获取订单信息。订单信息的获取可以由订单提取模块510执行。所述订单可以是历史订单、实时订单、预约订单、预测订单。关于订单信息的更多描述可以参考图5，在此不再赘述。
在步骤1810，可以基于订单信息，为订单选择至少一个可以接受该订单的用户。该选择过程可以由订单与用户匹配子单元5798实现。所述订单信息可以包括但不限于订单发送时间、订单编号、出发地、目的地、出发时间、到达时间、愿意等待的时间、乘客人数、是否愿意拼车、选择的车型、选择的业务类型(例如，出租车、快车、专车、顺风车、巴士、租车、代驾等)、是否携带行李、携带行李的数量、是否携带宠物、里程、价格、消费方加价、服务方调价、系统调价、红包使用情况、付款方式(如现金支付、刷卡支付、网上支付、汇款支付等)、订单完成情况、服务方选择订单情况、消费方发送订单情况等，或者上述信息的任意组合。除上述描述外，订单信息还可以包括与订单相关的其他信息，例如服务请求者基本信息(例如性别、昵称、联系方式、硬件地址等)和其他不受消费方、服务方控制的信息，或者是指暂时性/突发性的信息。其中，其他信息可以包括但不限于天气情况、环境情况、道路状况(如因安全性或者道路作业等原因封闭 道路)、交通条件等，或者上述信息的任意组合。选择的方式可以是随机选择，也可以是根据一定指标进行选择。其中，所述指标可以包括但不限于用户与订单中的出发地之间的距离、用户与订单中的出发地之间的行驶时间、订单预期收入、订单目的地方向是否与用户的预期行驶方向一致、用户习惯/喜好、其他指标等中的一种或几种的组合。其中，所述用户习惯/喜好可以包括但不限于服务请求者对于出发地、目的地、出发时间的偏好、服务请求者对于用户的偏好、服务请求者可以接受的等待时间、服务请求者对于拼单的偏好、服务请求者对于交通工具种类(例如，飞行器、火车、船舶、地铁、出租车、公交车、摩托车、自行车、步行等)的偏好、服务请求者对于业务类型(例如，出租车、快车、专车、顺风车、巴士、租车、代驾)的偏好、服务请求者对于交通工具型号的偏好、用户对于出发地、目的地、出发时间的偏好、用户对于行车路线的偏好、用户的工作时间、用户的爽约率、用户的抢单特性、用户的抢单量、抢单成功量、成交量、抢单成功率、成交率等中的一种或几种的组合。所述至少一个可以接受该订单的用户的状态可以是空闲状态，即将完成订单服务的状态，可拼车的状态，或其他可以接受订单的状态。例如，在选择至少一个可以接收该订单的用户的过程中，可以获取位置与订单出发地距离小于预设阈值的至少一个用户，或者也可以获取订单出发地所在区域的至少一个用户。所述订单出发地所在区域可以是与该订单出发地的距离小于预设阈值的范围内的区域，也可以是该订单出发地所属的地理区域。所述该订单出发地所属的地理区域的划分可以基于行政区(例如，海淀区、朝阳区等)，经纬度，商圈、建筑、街道名称等标志等的一种或多种。
在步骤1820，可以通过车载诊断系统获取至少一个可以接受该订单的用户的车辆的状态信息。该获取过程可以由用户信息提取模块520实现。在一些实施例中，所述车辆的状态信息可以包括但不限于车速、车辆加速度、位置信息、剩余能源量、能源消耗量、能源消耗速率、车辆运行状态(例如，发动机运行状态、水箱运行状态、刹车系统运行状态、车身稳定系统运行状态、仪表系统运行状态安全系统 运行状态等)等中的一种或几种的组合。其中，所述能源可以是汽油、煤油、柴油、天然气、液化石油气、醇类燃料、二甲醚、氢燃料、生物质燃料、电池、太阳能等。所述车辆状态信息可以是历史数据，实时数据，预测数据等中的一种或多种。在一些实施例中，所述车载诊断系统可以是用户终端的一部分，也可以与用户终端相对独立。所述车载诊断系统可以被任何一个可以实现相同功能的系统代替，也可以被多个系统的组合代替。例如，所述车载诊断系统可以被速度检测系统、定位系统、车检系统的组合代替。
在步骤1830，可以将订单信息和至少一个可以接受该订单的用户的车辆状态信息进行匹配，获得匹配结果。该匹配过程可以由订单与用户匹配子单元5798实现。具体地，根据订单信息，可以获得服务请求者的需求信息(例如，出发时间、出发地、目的地、出行距离、愿意等待时间等)，从而根据服务请求者的需求信息以及车辆状态信息，采用匹配算法将服务提供者与服务请求者计算匹配度，根据匹配度将服务提供者与服务请求者进行匹配。可以理解，在匹配的过程中，匹配的指标可以不仅限于车辆状态信息，也可以是其他匹配指标，例如，用户与订单中的出发地之间的距离、用户与订单中的出发地之间的行驶时间、订单预期收入、订单目的地方向是否与用户的预期行驶方向一致、用户习惯/喜好、环境信息、其他指标等中的一种或几种的组合。其中，所述用户习惯/喜好可以包括但不限于服务请求者对于出发地、目的地、出发时间的偏好、服务请求者对于用户的偏好、服务请求者可以接受的等待时间、服务请求者对于拼单的偏好、服务请求者对于交通工具种类(例如，飞行器、火车、船舶、地铁、出租车、公交车、摩托车、自行车、步行等)的偏好、服务请求者对于业务类型(例如，出租车、快车、专车、顺风车、巴士、租车、代驾)的偏好、服务请求者对于交通工具型号的偏好、用户对于出发地、目的地、出发时间的偏好、用户对于行车路线的偏好、用户的工作时间、用户的爽约率、用户的抢单特性、用户的抢单量、抢单成功量、成交量、抢单成功率、成交率等中的一种或几种的组合。所述环境信息可以包 括但不限于天气信息、交通信息、事件信息、地理信息等中的一种或几种的组合。所述交通信息可以包括但不限于道路的位置、道路是否通畅、限速情况、是否有突发情况(例如，交通事故、养护施工、交警管制等)等中的一种或几种的组合。
在步骤1840，可以向较优匹配结果对应的用户发送调度策略。该发送过程可以由调度模块550或订单分配模块540实现。在一些实施例中，所述较优匹配结果可以是最优匹配结果，次优匹配结果，或其他满足实际情况要求的匹配结果。所述调度策略可以包括但不限于供求密度推送策略、热点特征推送策略、统计特征推送策略、订单推送策略、订单调整策略、或提示信息推送策略等中的一种或几种的组合(详细描述见图3)。其中，所述订单推送策略可以包括但不限于订单的出发地、目的地、服务请求者基本信息(例如性别、昵称、联系方式、硬件地址等)、环境信息等中的一种或几种的组合。在一些实施例中，所述调度策略可以发送给移动设备2900。
需要注意的是，以上关于运力调度流程的描述，仅为描述方便，并不能把本申请限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解本申请的基本原理后，可以在不背离这一原理的情况下，对运力调度流程作出改变。例如，可以增加、减少、合并或拆分一些步骤。例如，可以在步骤1830之后添加一个订单分配的步骤。具体地，在获得较优分配之后，向较优匹配结果对应的用户分配订单。之后进入步骤1840，向较优匹配结果对应的用户发送调度策略。可以理解，订单分配步骤也可以与步骤1840同时进行，或者在步骤1840之后进行。例如，用户接收到调度策略前往订单出发地所在地，可以在用户到达订单出发地所在地后再向该用户分配订单。若在用户前往订单出发地所在地的过程中出现意外情况而导致用户无法到达订单出发地所在地时，处理模块210可以重新进行步骤1830和步骤1840，选择其他用户与订单进行匹配。诸如此类的变形，均在本申请的保护范围之内。
根据本申请的一些实施例，图19所示是基于车载诊断系统的运 力调度方法中匹配流程的一个示例性流程图。图19所示的匹配过程可以由订单与用户匹配子单元5798实现。在步骤1910，可以根据订单信息，计算订单描述的出发地和目的地之间的路程。在一些实施例中，当从订单出发地到订单目的地有多种路线时，所述出发地和目的地之间的路程可以多种路线中最短的路程，多种路线中最长的路程，多种路线路程的平均值等。在一些实施例中，在计算出发地和目的地之间的路程时，还可以考虑环境因素对路程计算的影响。所述环境因素可以包括但不限于天气信息、交通信息、事件信息、地理信息等中的一种或几种的组合。所述交通信息可以包括但不限于道路的位置、道路是否通畅、限速情况、是否有突发情况(例如，交通事故、养护施工、交警管制等)等中的一种或几种的组合。
在步骤1920，可以根据计算得到的路程和获取的车辆状态信息(详见步骤1820)，计算所需要的能源量。在一些实施例中，可以针对所有用户计算一个需要的能源量，或针对一个用户计算一个需要的能源量。在一些实施例中，可以将用户分类，针对每类用户计算一个需要的能源量，也可以是其他计算方式。
在步骤1930，可以判断车辆的剩余能源量是否大于或等于所需要的能源量。如果车辆的剩余能源量小于所需要的能源量，则进入步骤1940，将该车辆对应的用户从至少一个可以接受该订单的用户列表中移除；如果车辆的剩余能源量大于或等于所需要的能源量，则进入步骤1950。
在步骤1950，可以获取用户与订单描述的出发地之间的路程信息。所述路程信息可以包括但不限于用户与订单描述的出发地之间的距离、用户到达订单描述的出发地的时间、环境信息等中的一种或几种的组合。
在步骤1960，可以根据路程信息，确定较优匹配结果。在一些实施例中，确定较优匹配结果可以基于用户与订单描述的出发地之间的距离，用户到达订单描述的出发地的时间等中的一种或多种。例如，可以选择用户与订单描述的出发地之间的距离最近的用户作为较优 匹配结果。再例如，可以选择用户到达订单描述的出发地的时间最短的用户作为较优匹配结果。在一些实施例中，可以计算多个可能的匹配的匹配度，并根据匹配度对这些可能的匹配进行排序。在一些实施例中，确定匹配度可以基于用户与订单描述的出发地之间的距离、用户到达订单描述的出发地的时间、路程信息，车辆状态信息、订单预期收入、订单目的地方向是否与用户的预期行驶方向一致、服务请求者对于用户的偏好、服务请求者可以接受的等待时间、服务请求者对于拼单的偏好、服务请求者对于交通工具种类(例如，飞行器、火车、船舶、地铁、出租车、公交车、摩托车、自行车、步行等)的偏好、服务请求者对于业务类型(例如，出租车、快车、专车、顺风车、巴士、租车、代驾)的偏好、服务请求者对于交通工具型号的偏好、用户对于出发地、目的地、出发时间的偏好、用户对于行车路线的偏好、用户的工作时间、用户的爽约率、用户的抢单特性、用户的抢单量、抢单成功量、成交量、抢单成功率、成交率等中的一种或几种的组合。
需要注意的是，以上关于匹配流程的描述，仅为描述方便，并不能把本申请限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解本申请的基本原理后，可以在不背离这一原理的情况下，对匹配流程作出改变。例如，可以增加、减少、合并或拆分一些步骤。诸如此类的变形，均在本申请的保护范围之内。
根据本申请一些实施例，图20是处理模块210的一个示意图。
如图20所示，处理模块210可以包括一个或多个订单信息提取模块510、用户信息提取模块520、环境信息提取模块530、订单分配模块540、调度模块550、计算模块570等。其中，计算模块570可以包括一个或多个区域信息计算单元571、特征指标计算单元573和订单分组计算单元575及其他单元(未在图20中显示)。其中，区域信息计算单元571可以包括标志地点确定子单元5713及其他单元(未在图20中显示)。特征指标计算单元573可以包括订单特征计算子单元5732及其他单元(未在图20中显示)。在一些实施例中，订单信息提取模块510、用户信息提取模块520、环境信息提取模块530、订 单分配模块540、调度模块550中的一个或多个模块可以分别与计算模块570相连。如图20所示，各模块及单元之间的连接方式可以是有线的或无线的，各个模块及单元之间可以进行信息通信。
订单信息提取模块510可以获取订单信息。用户信息提取模块520可以获取用户信息。环境信息提取模块530可以获取环境信息。订单分配模块540可以向用户分配待分配订单。调度模块550可以向用户发送调度策略。相关内容在图5中有详细描述，在此不再赘述。
标志地点确定子单元5713可以确定特定位置所对应的标志地点的确定。所述标志地点可以是一个地点或多个地点。所述标志地点可以是一个坐标位置(例如，经度109.3、纬度56.7)，某个特定的建筑物(例如，天安门广场人民英雄纪念碑)，特定范围的区域(例如，海淀区)等中的一种或多种。标志地点可以是预先设定的，或计算得到的(例如，将订单数量超过一定阈值地点确定为标志地点)。标志地点的确定过程中所使用的方法可以是定量的方法，或定性的方法。
订单特征计算子单元5732可以计算订单的特征参数。所述订单可以是一件订单的个体特征，或是多件订单(例如，一个时间段或一个区域的所有订单)的统计特征。所述订单可以是历史订单、实时订单、预约订单、预测订单等中的一种或多种。所述订单的特征参数包括但不限于订单的总数、出发时间、平均等待时间、到达时间、成交价格、平均价格、成交率等。
订单分组计算单元575可以对订单进行分组。所述分组可以是由人工指定的分组，或是基于一定规则由计算得到的分组。在一些实施例中，可以将具有一个或多个相同特征参数(例如，出发时间、所属区域)的订单分到一个组中。用于分组的特征参数可以是订单分组计算单元575计算的结果，特征指标计算单元452计算的结果，或直接从订单信息中获取而不需要计算。
需要注意的是，以上对处理模块的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。上述每个模块或单元并不是必须的，每一个模块或单元均可通过一个或多个部件实现，每个模块或单元的 功能也并不局限于此。上述各个模块或单元可以根据具体实施场景或需要选择添加或删除。显然，对于本领域的专业人员来说，在了解运力调度流程的基本原理后，可能在不背离这一原理的情况下，对处理模块的具体实施方式与步骤进行形式和细节上的各种修正和改变，还可以做出若干简单推演或替换，在不付出创造性劳动的前提下，对各模块或单元的顺序作出一定调整、组合或拆分，但是这些修正和改变仍在以上描述的范围之内。例如，可以将标志地点确定子单元5713的部分功能分别集成在订单特征计算子单元5732和用户特征计算子单元(未在图20中显示)中，用于确定订单和用户对应的标志地点。由例如，可以将订单分组单元575和订单特征计算子单元5732集成在一个子单元中，同时完成订单分组和订单特征参数的计算。
据本申请的一些实施例，图21是基于统计信息的运力调度系统的示例性流程图。
在步骤2101，可以获取出发地址在特定位置附近区域的一个或多个历史订单信息。该步骤可以由订单信息获取模块510执行。所述特定位置附近区域，可以是按照一定的区域划分方法判断后，该特定位置所属的区域。所述区域划分方法可以是按照网格的划分方法、按照簇的划分方法、按照特定规则的划分方法等中的一种或者多种的组合(详细描述见图7-A，图7-B，图7-C)。所述特定位置附近的区域可以是一定阈值范围内的区域。例如，可以是与所述特定位置的距离小于一定阈值(例如，100米、1000米)的位置所构成的区域。所述特定位置附近的区域也可以是与所述特定位置的距离在一定范围内(例如，大于10米小于100米)的位置所构成的区域。所述多个历史订单可以是连续时间段内的历史订单。例如，最近N天内的历史订单。所述历史订单也可以是离散时间段内的历史订单。例如，最近N天内每个星期一的历史订单。所述多个历史订单也可以是满足一定筛选条件(例如，订单类型、订单成交价格、订单目的地)的历史订单。
在一些实施例中，可以先获取给定时间段内(例如，最近N天)的所有历史订单，然后从中确定出发位置与所述特定位置的距离小于 特定阈值(例如，10千米)的多个历史订单。在一些实施例中，可以先获取所述特定位置所述行政区域的所有历史订单，然后从中选择所有星期一上午9：00至当日13：00的多个订单。
在步骤2103，可以确定历史订单所对应的标志地点。标志地点的确定可以由标志地点确定子单元5713执行。关于标志地点的描述可以参见图20，在此不再赘述。所述标志地点确定，可以根据订单的出发位置确定，也可以根据订单的目的地确定，也可以根据与订单相关的其他位置(例如，中间位置)确定。可以为一个订单确定一个标志地点或多个标志地点。
在一些实施例中，通过预先规划确定多个标志地点。例如，通过人工在地区上制定诸如海淀区、东城区、国贸等多个标志地点。在一些实施例中，可以基于所有历史订单的出发地址和目的地址来确定多个标志地点。例如，假设最终要选定200个标志地点，可以将最近N天的订单数据中的出发地址和目的地址的经纬度的小数点后的位数保留X位，去重后选取200个经纬度的坐标，使用这200个经纬度坐标或者经纬度坐标附近的建筑物作为标志地点。在一些实施例中，可以确定多个标志地点后，分别计算每个标志地点和每个历史订单的目的地地址之间的距离，然后将最短距离所对应的标志地点作为该订单的标志地点。
在步骤2105，可以基于标志地点和订单特征，对一个或多个历史订单进行分组。该分组过程可以由订单分组计算单元575实现。所述订单特征可以是订单的时间特征(例如，出发时间、完成时间、下达时间、预定出发时间、实际出发时间、等待时间)，或订单的其他特征(例如，订单类型、订单成交价)等中的一种或多种。所述分组中，同一组内的订单可以具有一个及多个相同特征。不同分组间的订单可以具有不同的特征，也可以具有相同的特征。
在一些实施例中，可以根据历史订单的标志地点和出发时间，对一个或多个历史订单进行分组。所述分组中的订单，发生在相同的时间段内且对应于相同的标志地点。例如，在15：00～16：00内，把去往 天安门的所有历史订单分在一个组内。又例如，在15：00～16：00内，把去往天安门的出租车类型的所有历史订单分在一个组内。
在步骤2107，可以计算各组历史订单的统计数据。该步骤中统计数据的计算可以由特征指标计算单元573执行。更具体地，可以由订单特征计算子单元5732执行。所述统计数据可以是一项统计数据，也可以是多项统计数据。所述统计数据包括但不限于订单总数、订单平均应答时间、订单发起者的总人数、订单发送的平均时间间隔和订单成交率等。
在步骤2109，可以针对特定条件，发送一组或多组历史订单的一个或多个统计数据。该发送过程可以由调度模块550执行。所述特定条件可以是特定时间段(例如，当前时间段)、特定位置(例如当前位置)、特定区域(例如，当前区域)、用户的选择等中的一种或多种。所述发送的一个或多个统计数据可以是基于用户选择的一个或多个统计数据，处理模块210规定的一个或多个统计数据等中的一种或多种。所述发送的一个或多个统计数据可以是步骤2107计算得到的全部或部分统计数据。例如，只发送当前时间段订单总数最多的前K组历史订单的统计数据。发送数据的形式可以是以文本形式、图像形式(动态形式和静态形式)或是语音形式等任意一种或是几种的组合。
在一些实施例中，可以将当前时间段内(例如，星期一的13：00-15：00)当前区域(例如，中关村)历史订单中订单类型(例如，快车、出租车、专车)的统计数据发送给乘客，以供乘客在不同订单类型之间做出选择。在一些实施例中，可以将当前时间段内不同区域的需求量信息发送给司机，以供司机在前往哪里提供运力服务做出选择。在一些实施例中，可以将特定区域内历史订单中订单总数的统计数据发送给司机，以供司机选择接单区域。在一些实施例中，图29所示移动设备2900可以接收一个或多个统计数据。
根据本申请的一些实施例，图22是基于统计信息的运力调度系统的示例性流程图。
在步骤2201，可以获取出发地址在特定位置附近区域的一个或多 个实时订单的信息。该步骤可以由订单信息获取模块510执行。关于特定位置附近区域的详细描述可以参考图21，在此不再赘述。所述实时订单，可以是满足一定筛选条件(例如，未被应答、未携带宠物)的实时订单。
在一些实施例中，可以先获取特定位置附近区域内的所有订单，然后从中选择未被应答的订单。在一些实施例中，可以先获取所有符合筛选条件的实时订单，然后从中选择订单的出发位置与司机位置在一定阈值(例如，1千米)范围内的订单。
在步骤2203，可以确定实时订单所对应的标志地点。标志地点的确定可以由标志地点确定子单元5713执行。关于标志地点的更多描述请参见图21，在此不再赘述。
在步骤2205，可以基于标志地点，对一个或多个实时订单进行分组。该分组过程可以由订单分组计算单元575实现。在一些实施例中，除标志地点外，订单分组还可以参考其他的特征，可以包括但不限于订单的时间特征(例如，出发时间、下达时间、预定出发时间、可以容忍的等待时间)，订单的附加信息特征(例如，订单类型、小费)、用户的偏好(例如，下单乘客对于司机驾龄的偏好)等中的一种或多种的组合。关于订单分组过程的更多详细描述请参见图21，在此不再赘述。
在步骤2207，可以计算各组实时订单的统计数据。该步骤中统计数据的计算可以由特征指标计算单元573执行。更具体地，可以由订单特征计算子单元5732执行。关于统计特征计算的更多描述请参考图21和图20，在此不再赘述。
在步骤2209，针对特定条件，发送一组或多组实时订单。该发送过程可以由订单分配模块540和/或调度模块550执行。在一些实施例中，订单分配模块540可以将具体订单信息发送给司机，调度模块550可以将实时订单的统计信息发送给司机。例如，将所述信息发送给移动设备2900(详见图29)。所述特定条件，可以是特定时间段(例如，当前时间段)、特定位置(例如当前位置)、特定区域(例如，当前区 域)、用户的选择等。
在一些实施例中，基于司机选择的特定标志地点(可以是司机的当前位置，也可以不是司机的当前位置)，处理模块210可以发送所述标志地点的实时未应答订单总数和订单信息。
以上对基于统计信息的运力调度过程的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。显然，对于本领域的专业人员来说，在了解各种算法的基本原理后，可能在不背离这一原理的情况下，对供求调度的具体实施方式与步骤进行形式和细节上的各种修正和改变，但是这些修正和改变仍在以上描述的范围之内。例如，步骤2103可以被省略，在步骤2101中获取的订单信息中即包括了标志地点信息。又例如，在步骤2109或步骤2209之前可以增加接收用户选择的步骤，然后基于获取的用户选择信息进行数据的发送。
据本申请的一些实施例，图23是一个处理模块210的示意图。
如图23所示，处理模块210可以包括一个或多个订单信息提取模块510、用户信息提取模块520、环境信息提取模块530、订单分配模块540、调度模块550、计算模块570等。计算模块570可以包括区域信息计算单元571、特征指标计算单元573及其他单元(未显示在图23中)。区域信息计算单元571可以包括区域划分子单元5711及其他子单元(未显示在图23中)。特征指标计算单元573可以包括订单特征计算子单元5732、用户特征计算子单元5734、供求特征计算子单元5733及其他子单元(未显示在图23中)。
订单信息提取模块510可以获取订单信息。用户信息提取模块520可以获取用户信息。环境信息提取模块530可以获取环境信息。订单分配模块540可以向用户分配待分配订单。调度模块550可以向用户发送调度策略。这些内容在图5中有详细的描述，在此不多赘述。
区域划分子单元5711可以进行区域的划分。区域划分方法可以包括按照网格的划分方法、按照簇的划分方法、按照特定规则(例如，行政区域)的划分方法等中的一种或者多种的组合(详细描述见图7-A，图7-B，图7-C)。
订单特征计算子单元5732可以计算订单的特征参数。所述订单可以是实时订单、历史订单、预约订单、预测订单等。所述特征参数包括但不限于区域内的实时订单数、历史订单数、潜在订单发起方的第三数量、潜在订单发起方的偏好、以及根据所述实时订单数、历史订单数和潜在订单发起方的数量所确定的订单需求的第一数量等。
供求特征计算子单元5733可以计算区域的供求特征指标。供求特征指标可以包括实时供求特征指标、历史供求特征指标、预测供求特征指标等。供求特征可以用订单量与服务提供者的数量比值表示，用订单密度表示，或用其他能反映供求关系的指标表示。
用户特征计算子单元5734可以计算用户的特征参数。所述特征参数可以包括但不限于区域内静态潜在订单接收方的数量、区域内动态潜在订单接收方的数量、潜在订单接收方的第二数量等中的一种或多种。
需要注意的是，以上对处理模块的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。上述每个模块或单元并不是必须的，每一个模块或单元均可通过一个或多个部件实现，每个模块或单元的功能也并不局限于此。上述各个模块或单元可以根据具体实施场景或需要选择添加或删除。显然，对于本领域的专业人员来说，在了解运力调度流程的基本原理后，可能在不背离这一原理的情况下，对处理模块的具体实施方式与步骤进行形式和细节上的各种修正和改变，还可以做出若干简单推演或替换，在不付出创造性劳动的前提下，对各模块或单元的顺序作出一定调整、组合或拆分，但是这些修正和改变仍在以上描述的范围之内。例如，区域划分子单元5711、订单特征计算子单元5732、供求特征计算子单元5733和用户特征计算子单元5734中可以集成一个或多个存储单元，用于存储获取的数据、中间数据和/或计算结果。
根据本申请的一些实施例，图24是基于供求密度信息的运力调度系统的示例性流程图。
在步骤2405，可以根据一定的区域划分方法，进行区域的划分。 所述区域划分可以由区域信息计算单元571执行。具体地，可以由区域划分子单元5711执行。区域划分方法可以包括按照网格的划分方法、按照簇的划分方法、按照特定规则(例如，行政区域、商圈信息)的划分方法等中的一种或者多种的组合(详细描述见图7-A，图7-B，图7-C)。所述区域划分可以是一次划分，或多次划分(例如，基于前一次划分的结果进行区域的再划分)。区域划分可以是固定的，或动态的(例如，根据订单或用户情况进行实时的聚类以得到区域划分的结果)。
在步骤2410，可以获取特定区域内的订单需求信息。所述订单需求信息可以是历史订单信息、实时订单信息、潜在订单信息、预测订单信息等中的一种或多种。
在步骤2415，可以基于获取的订单需求信息，计算特定区域内潜在订单需求的特征参数。所述特征参数的计算可以由订单特征计算子单元5732执行。在一些实施例中，订单需求的特征参数也可以通过订单信息获取单元510直接获取。所述订单需求的特征参数包括但不限于区域内的实时订单数、历史订单数、潜在订单发起方的第三数量、潜在订单发起方的偏好、以及根据所述实时订单数、历史订单数和潜在订单发起方的数量所确定的订单需求的第一数量等中的一种或多种。所述特征参数的计算可以由订单特征计算子单元5732执行。
在一些实施例中，根据特定区域内的实时订单数、历史订单数以及潜在订单发起方的第三数量可以计算得到所述区域内订单需求的第一数量K1。具体计算公式如下：
K1＝X+αP+βOpre，       (15)
其中，X可以是所述区域内的实时订单数，P可以是所述区域内潜在订单发起方的第三数量，Opre可以是所述区域的历史订单数量，α、β均为系数。
在一些实施例中，所述区域内的实时订单数X可以是基于某种运算规则进行处理后的实时订单数据。例如，X可以是当前实时订单数，或当前有小费的订单数等。
在一些实施例中，所述区域内潜在订单发起方的第三数量P可以是潜在有服务需求的需求方的实际数量，在线或不在线的服务终端(例如，打车软件乘客终端)数量，从第三方获取的在线或不在线其他终端数量(例如，社交软件、支付软件)，通过服务需求方的终端定位软件(例如，GPS)获取的数量，或通过服务需求方的终端入网接口的基站位置信息获取的数量等。
在一些实施例中，所述区域的历史订单数量Opre可以是一个对应时段全部的历史订单数量，或基于某种运算规则进行处理后的历史订单数量等。例如，所述区域的历史订单数量Opre可以是前一天该时段的实际订单数，N天前该时段的实际订单数的平均数，或者是N天前该时段的实际订单数的总数等。
在一些实施例中，系数α、β可以是任何数值。系数α与β的数值可以相等或不相等。例如，当α、β取值均为1时，K1可以反映服务需求的程度。又例如，系数α可以为0.4-0.6之间的值，系数β可以为1。系数α与β的数值可以保持不变，或动态调整。例如，系数α、β的值可通过K1的值向实际服务需求量逼近进行不断调整，最终，使得系数α、β的取值可以使得K1的值更加接近真实的服务需求量。
在一些实施例中，订单需求的第一数量与乘客用车需求正相关。例如，当α与β取确定的数值时，K1越大代表乘客用车需求也越高。
在步骤2420，可以获取特定区域内的订单接收方信息。所述订单接收方信息可以是实时订单接收方信息，或历史订单接收方信息。所述订单接收方信息可以包括但不限于与订单接收方相关的订单信息、用户信息、环境信息(例如，路况信息)等中的一种或多种。
在步骤2425，可以基于获取的订单接收方信息，计算潜在订单接收方的特征参数。所述特征参数可以包括但不限于区域内静态潜在订单接收方的数量、区域内动态潜在订单接收方的数量、潜在订单接收方的第二数量等中的一种或多种。所述特征参数的计算可以由用户特征计算子单元5734执行。
在一些实施例中，所述静态潜在订单接收方数量可以是指在某时 间段内静止不动订单接收方数量。例如，所述静态潜在订单接收方数量可以是静止不动等待乘客的可用车数量。所述静止不动可以是在较长时间内(例如，5分钟)移动了较短的距离(例如，500米)或没有移动。
在一些实施例中，指在某时间段内移动中的订单接收方数量。例如，所述动态潜在订单接收方数量可以是移动中的可用车数量。所述动态潜在订单接收方数量可以由多种方式获得。例如，根据所述区域的历史或当前时段路面行车拥堵状况可以预测的当前行使在所述区域中的潜在订单接收方数量。所述历史或当前时段路面行车拥堵状况可以由其他路况信息系统获取。例如，所述历史或当前时段路面行车拥堵状况可以通过环境信息获取模块530获取。所述历史时段可以是前N天的对应时段。例如，当前时段是上午8：00-9：00，则可以选择前一天的上午8：00-9：00作为历史时段。所述历史时段也可以是具有相同特征的N天对应的时段。例如，当前时段是星期一上午8：00-9：00，则可以选择前N个星期一的上午8：00-9：00作为历史时段。在一些实施例中，将上述各类或其他历史信息进行处理时，不同时段的历史信息可以有相同的影响，也可以有不同的影响。例如，与当前订单比较接近的时段的历史信息和与当前订单间隔比较遥远的时段的历史信息可以对处理结果有相同的影响。又例如，与当前订单比较接近的时段的历史信息也可以对处理结果较多的影响，而与当前订单间隔比较遥远的时段的历史信息可以对处理结果有较少的影响或没有影响。以上述N个星期一的上午8：00-9：00作为历史时段为例。在一些实施例中，所述N个历史时段的信息对所述区域中的潜在订单接收方数量的预测可以起到相同的影响。在一些实施例中，所述N个历史时段的信息对所述历史或当前时段路面行车拥堵状况的预测或估算可以起到不同的影响。例如，所述N个历史时段中，与当前时段比较接近的历史时段的信息可以对所述区域中的潜在订单接收方数量的预测有较多的影响，而与当前时段间隔比较遥远的历史时段的信息可以对所述区域中的潜在订单接收方数量预测有较少的影响。又例如，所述N个 历史时段中，与当前时段有一个或多个相同特征的历史时段(如相同或类似的天气、相同或类似的特别路况(例如，修路、封路、限行等)的信息对所述区域中的潜在订单接收方数量的预测有较多的影响。
在一个具体的实施例中，可以根据该区域内历史时段移动中的潜在订单接收方数量、历史时段路面的拥堵状况和当前时段路面拥堵状况预测该时段内动态潜在订单接收方的数量。例如，当前时段内动态潜在订单接收方数量Dpre可以用如下公式表示：
Dpre＝Dh1×(δ2/δ1)，        (16)
其中，Dh1可以是该区域内历史时段动态潜在订单接收方的数量；δ1可以是该区域历史时段路面拥堵情况系数；δ2可以是当前时段路面拥堵情况系数。
可以理解的，Dpre也可以是采用其他方式计算得到的，或者采用对照查找表的形式来获取(例如，某路面的拥堵程度对应某拥堵系数)。只要能反映Dpre与路面情况的相对关系，以此反映动态潜在服务提供方数量的，都在本描述的范围内。
在一些实施例中，所述潜在订单接收方的第二数量可以表示为区域内静态潜在订单接收方的数量与区域内动态潜在订单接收方的数量的函数。例如，可以用公式(17)中的K2表示潜在订单接收方的第二数量：
K2＝Ds+Dpre，      (17)
其中，K2可以是潜在订单接收方的第二数量；Ds可以是所述区域内的静态潜在订单接收方的数量；Dpre可以是所述区域内的动态潜在订单接收方的数量。
在一些实施例中，可以用区域内历史时段的可用车数量Dh1来估计动态的潜在订单接收方数量Dpre，并据此粗略估计潜在订单接收方的第二数量K2。例如，区域内历史时段的可用车数量Dh1和动态的潜在订单接收方数量Dpre可以用公式(18)表示：
Dpre＝Dh1，         (18)
在步骤2430，可以根据订单需求的特征参数和潜在订单接收方的特征参数，确定区域内的订单供求密度。所述订单供求密度的计算，可以由供求特征计算子单元5733执行。
在一些实施例中，订单供求密度可以表示为订单需求的第一数量与潜在订单接收方的第二数量的比值。具体地，订单供求密度K可以用公式(19)表示：
K＝K1/K2，     (19)
进一步，结合所述公式(15)-(18)，订单供求密度K可以表示为：
Figure PCTCN2016073559-appb-000022
其中，X、P、Opre、Ds、Dpre、α和β在上述公式(15)-(19)中已有相应描述，此处不再赘述。
在步骤2435，可以发送计算得到的订单供求密度。订单供求密度发送对象可以是任何信息需求端设备(120和/或140)，也可以是数据库130，存储模块220等。
以上对基于统计信息的运力调度过程的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。显然，对于本领域的专业人员来说，在了解各种算法的基本原理后，可能在不背离这一原理的情况下，对供求调度的具体实施方式与步骤进行形式和细节上的各种修正和改变，但是这些修正和改变仍在以上描述的范围之内。例如，步骤2405可以被省略，在订单信息被获取的过程中，可以包含了区域划分的信息。又例如，在步骤2425之前可以增加环境信息获取步骤，可以获取与订单信息相关的路况等环境信息。
根据本申请的一些实施例，图25所示是处理模块210的一个示意图。如图25中所示，计算模块570可以包括区域信息计算单元571、和/或调度策略计算单元579及其他单元(未在图25中显示)。其中，区域信息计算单元571可以包括区域归属判断子单元5715及其他单元(未在图25中显示)。调度策略计算单元579可以包括调度信息查找子单元5797及其他单元(未在图25中显示)。在一些实施例中，订单信息提取模块510、用户信息提取模块520、环境信息提取模块 530、订单分配模块540、调度模块550中的一个或多个模块可以分别与计算模块570相连。如图25所示，各模块及单元之间的连接方式可以是有线的或无线的，各个模块及单元之间可以进行信息通信。
如图25中所示，在一些实施例中，区域归属判断子单元5715可以确定用户发送的位置信息所属的区域。在一些实施例中，所述用户可以是服务请求者(例如，乘客)，或是服务提供者(例如，司机)。所述位置信息所属的区域可以是与该位置的距离小于第一预设阈值的范围内的区域，或是该位置信息所属的地理区域。
在一些实施例中，调度信息查找子单元5797可以查找区域内在预设时间段内的调度策略。信息查找来源可以包括但不限于数据库130、信息源160、存储模块220、其他存储设备等中的一种或几种的组合。在一些实施例中，所述预设时间段的长度可以是固定不变的，或随实际情况变化。查找的调度策略所属区域可以是用户发送的位置信息的所属区域，或用户发送的位置信息的所属区域的临近区域。在一些实施例中，所述调度策略可以包括但不限于供求密度推送策略、热点特征推送策略、统计特征推送策略、订单推送策略、订单调整策略、或提示信息推送策略等中的一种或几种的组合。所述统计特征推送策略可以包括但不限于订单信息、订单交互信息、分布信息、环境信息等中的一种或几种的组合。所述订单信息可以包括但不限于订单总数量、订单的下单时间、出发地、目的地、出发时间、乘客人数、是否愿意拼车、有无行李等中的一种或几种的组合。所述订单信息可以是实时订单信息，预约订单信息，历史订单信息等中的一种或多种。所述订单交互信息、所述分布信息以及所述环境信息可以是历史数据，实时数据，预测数据等中的一种或多种。
需要注意的是，以上对处理模块的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。上述每个模块或单元并不是必须的，每一个模块或单元均可通过一个或多个部件实现，每个模块或单元的功能也并不局限于此。上述各个模块或单元可以根据具体实施场景或需要选择添加或删除。显然，对于本领域的专业人员来说，在了解运 力调度流程的基本原理后，可能在不背离这一原理的情况下，对处理模块的具体实施方式与步骤进行形式和细节上的各种修正和改变，还可以做出若干简单推演或替换，在不付出创造性劳动的前提下，对各模块或单元的顺序作出一定调整、组合或拆分，但是这些修正和改变仍在以上描述的范围之内。例如，在一些实施例中，可以添加一个提示信息生成单元，用于生成提示信息。所示提示信息生成单元可以在计算模块570内，可以在计算模块570外。在一些实施例中，所述提示信息单元也可以存在于用户终端中。再例如，在一些实施例中，可以添加一个判断单元。判断单元可以判断所述订单总数量是否小于第二预设阈值。若订单总数量小于第二预设阈值，则生成第一提示信息用于提示用户该区域订单数量较少；若订单总数量大于第二预设阈值，则生成第二提示信息用于提示用户该区域订单资源充裕。判断单元还可以判断区域内所述订单总数量是否大于第三预设阈值。如果所述订单总数量大于第三预设阈值，则调度模块550执行发送调度策略至用户终端的步骤；如果所述订单总数量小于或等于第三预设阈值，则调度模块550不执行发送调度策略至用户终端的步骤。所述判断单元可以在计算模块570内，或计算模块570外。另外，一个或多个单元可以集成在同一个单元中，实现一个或多个单元的功能。诸如此类的变形，均在本申请的保护范围之内。
根据本申请的一些实施例，图26所示是基于订单交互信息和分布信息的运力调度方法的一个示例性流程图。
在步骤2610，可以获取用户发送的位置信息。获取用户发送的位置信息的过程可以由用户信息提取模块520实现。在一些实施例中，所述用户可以是服务请求者(例如，乘客)，也可以是服务提供者(例如，司机)。所述用户可以主动向调度引擎110发送位置信息，或在收到调度引擎110的发送请求后再发送位置信息。所述用户可以在需要时向调度引擎110发送位置信息，或授权调度引擎110或其他位置信息获取装置随时随地获取用户位置信息而不考虑用户是否有需求。所述用户可以定期发送位置信息，或不定期发送位置信息。位置信息 的输入方式可以由用户主动输入，或用户终端自动获取。用户主动输入的方式可以包括但不限于文本输入、图片输入、语音输入、视频输入、体感输入等中的一种或几种的组合。用户终端自动获取的方式可以是通过定位技术获取的方式。所述定位技术可以包括但不限于全球定位系统(GPS)技术、全球导航卫星系统(GLONASS)技术、北斗导航系统技术、伽利略定位系统(Galileo)技术、准天顶卫星系统(QAZZ)技术、基站定位技术、Wi-Fi定位技术等中的一种或几种的组合。在一些实施例中，所述位置信息可以是位置点，或是位置范围。
在步骤2620，可以根据位置信息，确定该位置信息所属的区域。确定该位置信息所属的区域的过程可以由区域归属判断子单元5715实现。在一些实施例中，所述位置信息所属的区域可以是与该位置的距离小于第一预设阈值的范围内的区域，或是该位置信息所属的地理区域。所述第一预设阈值可以固定不变，或根据实际情况变化。在一些实施例中，所述第一预设阈值可以根据地理位置的不同而变化，可以根据时间段的不同而变化，或是两种方式的组合。例如，针对位置信息是天安门的第一预设阈值可以小于针对位置信息是亦庄工业园区的第一预设阈值。例如，针对上下班高峰期的第一预设阈值可以小于针对凌晨时段的第一预设阈值。针对非节假日的第一预设阈值可以小于针对春节期间的第一预设阈值。针对天气恶劣时段或有重大活动时段的第一预设阈值可以小于针对平时的第一预设阈值。所述该位置信息所属的地理区域的划分可以基于行政区(例如，海淀区、朝阳区等)，经纬度，商圈、建筑、街道名称等标志等的一种或多种。本申请在此不作限制。
在步骤2630，可以查找区域内在预设时间段内的调度策略。查找过程可以由调度信息查找子单元5797实现。信息查找来源可以包括但不限于数据库130、信息源160、存储模块220、其他存储设备等中的一种或几种的组合。在一些实施例中，所述预设时间段的长度可以是固定不变的，也可以随实际情况变化。查找的调度策略所属区域可以是用户发送的位置信息的所属区域，也可以是用户发送的位置信息 的所属区域的临近区域。在一些实施例中，所述调度策略可以包括但不限于供求密度推送策略、热点特征推送策略、统计特征推送策略、订单推送策略、订单调整策略、或提示信息推送策略等中的一种或几种的组合。所述统计特征推送策略可以包括但不限于订单信息、订单交互信息、分布信息、环境信息等中的一种或几种的组合。所述订单信息可以包括但不限于订单总数量、订单的下单时间、出发地、目的地、出发时间、乘客人数、是否愿意拼车、有无行李等中的一种或几种的组合。所述订单信息可以是实时订单信息，预约订单信息，历史订单信息等中的一种或多种。所述订单交互信息可以包括但不限于抢同一订单的终端数量、订单成交数量、订单未成交数量、订单状态(例如，订单已成交、订单未成交等)、订单成交率、订单的竞争概率等中的一种或几种的组合。所述分布信息可以包括但不限于订单服务提供者的总数量、可以接单的服务提供者的数量、供求密度、订单密度、服务提供者密度等中的一种或几种的组合。可以接单的服务提供者的状态可以是空载，即将完成订单服务，可拼车，或其他可接单状态等。所述订单密度和所述服务提供者密度可以是单位区域面积的数量(例如，10件订单/平方米、20个司机/平方千米)，或单位时段的数量(例如，10订单/分钟)等。所述环境信息可以包括但不限于天气信息、交通信息、事件信息、地理信息等中的一种或几种的组合。所述交通信息可以包括但不限于道路的位置、道路是否通畅、限速情况、是否有突发情况(例如，交通事故、养护施工、交警管制等)等中的一种或几种的组合。所述订单交互信息、所述分布信息以及所述环境信息可以是历史数据，实时数据，预测数据中的一种或多种。
在步骤2640，可以发送调度策略至用户终端。发送调度策略至用户终端的过程可以由调度模块550实现。在一些实施例中，发送的调度策略可以是用户发送的位置信息所属区域的调度策略，用户发送的位置信息所属区域的临近区域的调度策略，或以上两种调度策略的组合。发送的调度策略的形式可以是文本、图片、视频、音频等中的一种或几种的组合。在一些实施例中，所述调度策略可以发送给移动设 备2900(在图29中显示)。
需要注意的是，以上关于运力调度流程的描述，仅为描述方便，并不能把本申请限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解本申请的基本原理后，可以在不背离这一原理的情况下，对运力调度流程作出改变。例如，可以增加、减少、合并或拆分一些步骤。例如，在一些实施例中，步骤2630还可以包括生成提示信息的步骤。将订单总数量与第二预设阈值进行比较。若订单总数量小于第二预设阈值，则生成第一提示信息用于提示用户该区域订单数量较少；若订单总数量大于第二预设阈值，则生成第二提示信息用于提示用户该区域订单资源充裕。在一些实施例中，所述生成提示信息的步骤也可以由用户终端实现。再例如，在一些实施例中，在步骤2640之前，可以添加判断步骤用来判断区域内所述订单总数量是否大于第三预设阈值。如果所述订单总数量大于第三预设阈值，则进入步骤2640；如果所述订单总数量小于或等于第三预设阈值，则不进入步骤2640，结束该流程。其中，第二预设阈值或第三预设阈值可以是固定不变的，也可以随着实际情况变化。在一些实施例中，所述第二预设阈值或第三预设阈值可以根据地理位置的不同而变化，可以根据时间段的不同而变化，也可以是两种方式的组合。例如，针对天安门的第二预设阈值或第三预设阈值可以小于针对亦庄工业园区的第二预设阈值或第三预设阈值。例如，针对上下班高峰期的第二预设阈值或第三预设阈值可以小于针对凌晨时段的第二预设阈值或第三预设阈值。针对平时的第二预设阈值或第三预设阈值可以小于针对春节期间的第二预设阈值或第三预设阈值。针对天气恶劣时段或有重大活动时段的第二预设阈值或第三预设阈值可以小于针对平时的第二预设阈值或第三预设阈值。在一些实施例中，第二预设阈值可以大于第三预设阈值。诸如此类的变形，均在本申请的保护范围之内。
根据本申请的一些实施例，图27是处理模块210的一个示意图。
如图27所示，在一些实施例中，处理模块210可以包括一个或多个订单信息提取模块510、用户信息提取模块520、环境信息提取 模块530、订单分配模块540、调度模块550、计算模块570。其中，计算模块570可以包括特征指标计算单元573、订单分组计算单元575、和预测模型计算单元577及其他单元(未在图27中显示)。特征指标计算单元573可以包括环境特征计算子单元5737、供求特征计算子单元5733及其他子单元(未在图27中显示)。预测模型计算单元577可以包括订单接收方预测子单元5775、订单量预测子单元5777及其他子单元(未在图27中显示)。
订单信息提取模块510可以获取订单信息。用户信息提取模块520可以获取用户信息。环境信息提取模块530可以获取用户环境信息。订单分配模块540可以向用户分配待分配订单。调度模块550可以向用户发送调度策略。这些内容在图5中有详细的描述，在此不再赘述。
供求特征计算子单元5733可以计算供求特征指标。供求特征指标可以包括实时供求特征指标、历史供求特征指标、预测供求特征指标等中一种或多种。供求特征可以表示为订单量与订单接收方的数量比值，订单密度，或其他能反应供求关系的指标中的一种或多种。订单量与订单接收方数量的比值中，订单量可以是实时订单量、历史订单量、预测订单量等中一种或多种；订单接收方数量可以是实时订单接收方数量、历史订单接收方数量、预测订单接收方数量等中一种或多种。订单密度可以是订单的面积密度、订单的时间密度、订单的面积与时间的复合密度等中一种或多种。
环境特征计算子单元5737可以计算环境信息的特征。环境信息可以是历史环境信息、实时环境信息、预测环境信息。所述环境信息可以是天气信息、交通信息、事件信息、地理信息等中的一种或多种的组合。
订单接收方预测子单元5775可以预测订单接收方的数量。所述预测可以是基于历史数据、实时数据、预测数据中的一种或多种的组合进行。例如，基于预测的订单量进行订单接收方数量的预测。
订单量预测子单元5777可以预测订单量。所述预测可以基于历 史数据、实时数据、预测数据中的一种或多种的组合进行。例如，可以基于特定区域历史时段的订单量进行订单量的预测。又例如，可以基于预测的天气情况，进行订单量的预测。
订单分组计算单元575可以对订单进行分组。所述分组可以是由人工指定的分组，或基于一定规则由计算得到的分组。在一些实施例中，可以将具有一个或多个相同特征参数(例如，出发时间、所属区域)的订单分到一个组中。
需要注意的是，以上对处理模块的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。上述每个模块或单元并不是必须的，每一个模块或单元均可通过一个或多个部件实现，每个模块或单元的功能也并不局限于此。上述各个模块或单元可以根据具体实施场景或需要选择添加或删除。显然，对于本领域的专业人员来说，在了解运力调度流程的基本原理后，可能在不背离这一原理的情况下，对处理模块的具体实施方式与步骤进行形式和细节上的各种修正和改变，还可以做出若干简单推演或替换，在不付出创造性劳动的前提下，对各模块或单元的顺序作出一定调整、组合或拆分，但是这些修正和改变仍在以上描述的范围之内。
根据本申请的一些实施例，图28是基于供求特征的运力调度系统的示例性流程图。
在步骤2810，可以预测在特定时间和特定区域的订单量。所述特定时间和特定区域可以是系统预先设定的，基于用户需求设定的，随机设定的，或基于特定条件设定的。所述时间可以是时间点或时间段。所述时间可以是可以是连续的时间点和/或时间段，或离散的时间点和/或时间段。时间标准可以是通用的时间标准，或基于一个订单设定的时间标准。特定区域可以是任何空间区域，例如，可以是某位置点，或某方位区域。特定区域可以是连续的位置点和/或区域，或离散的位置点和/或区域。特定区域的形状，大小都没有任何限定。具体地，一些实施例中，特定时间可以是订单量特征为设定条件，将订单量相对稳定的持续时间设定为特定时间。
预测所述特定时间和区域的订单量可以是满足某设定条件的预测。所述预测的设定条件可以包括但不限于基于订单的分类进行预测，基于订单的相关统计数据进行预测等。
订单的分类可以是满足某设定条件的分类。所述分类设定条件可以是基于特定区域和特定时间的订单统计数据的(例如，基于订单类型的)，或基于用户的数据的(例如，用户的偏好的)等其中的一种或几种组合。所述订单类型可以是以时间基准的订单时间类型，例如，早上订单，中午订单，深夜订单等。所述订单类型可以是以距离基准的订单距离类型，例如，短途订单、长途订单等。所述订单类型可以是以重要活动或节假日为基准的订单特殊类型，例如，假日订单、工作日订单等。在一些实施例中，订单类型可以是短途订单、长途订单等。所述用户偏好可是基于用户相关信息，进行分析处理得到的，能体现一定规律或意义的数据处理结果。所述用户偏好可以是结合订单类型的用户偏好分析结果。例如，所述用户偏好可以包括但不限于基于订单的目的地、出发地、短途订单、长途订单和/或订单时间信息等。所述用户偏好可以经过对服务需求方的偏好分析得到，或经过对服务提供方的偏好分析得到。一些实施例中，服务提供方的偏好分析可以包括司机群体的偏好特征，个体司机的偏好特征等中的一种或多种。所述司机群体的偏好特征可以体现为优质目的地订单。例如，可以将目的地聚类，以分析群体司机共同偏好的订单。在聚类时，按照订单距离及订单时间的各个维度聚类，从而确定在同一距离和时间段内司机的反应情况，从而反映该目的地受欢迎程度，以便确定司机群体的偏好特征。所述个体司机的偏好特征可以是基于司机抢单数据信息，分析司机抢单时间、订单距离、订单费用、订单目的地属性等实现对个体司机的偏好特征分析。一些实施例中，订单可划分为长途订单、短途订单和偏好订单。所述步骤的信息来源于包括但不限于数据库130、信息源160和/或存储模块220等。所述步骤可以由订单信息提取模块510、用户信息提取模块520、订单分组计算单元575等中一种或多种模块或单元实现。
基于订单的相关统计数据进行预测可以是订单的相关数据基于某条件进行数据处理，其处理结果可起到预测作用的处理过程。订单的相关统计数据可以是订单时间相关数据，订单空间相关数据，订单费用，订单业务类型等中的一种或多种。订单时间相关数据可以是历史订单数据，实时订单数据，未来订单数据(例如，预定的订单数据)中的一种或几种的组合。在一些实施例中，可以基于某特定区域的前一天或前几天某时间点或某时间段的历史订单数据进行数据分析，对该区域在特定时间的订单量进行预测。在一些实施例中，可以基于实时订单数据来预测订单量。在一些实施例中，可以是基于历史数据预测的订单量与当前实时的订单量赋予一定的加权值，由两者共同确定订单量。所述步骤的信息来源于包括但不限于数据库130、信息源160和/或存储模块220等。所述步骤可以由订单信息提取模块510、用户信息提取模块520、订单分组计算单元575和/或订单接收方预测子单元5775等中一种或多种模块或单元实现。
在步骤2820，可以是计算在特定时间和特定区域内潜在的订单接收方的数量。特定时间和特定区域与步骤2810中的相关解释对应，此处不再赘述。步骤2820中的特定时间和特定区域与步骤2810中的特定时间和特定区域可以是相同的，或不相同的。一些实施例中，所述特定时间和特定区域可以是与步骤2810中的相关解释对应相同的。潜在的订单接收方可以是服务提供方。计算在特定时间和特定区域内的潜在的订单接收方数量可以是与步骤2420与步骤2425相应的描述的计算方式，此处不再赘述，只要其数据处理目的在于统计在特定时间和特定区域内的潜在的接收订单的用户数量，都在描述范围内。所述步骤的信息可以来源于数据库130、信息源160和/或存储模块220等。所述步骤可以由用户信息提取模块520、订单信息提取模块510、环境信息提取模块530、订单接收方预测子单元5777等中一种或多种模块或单元实现。
在步骤2830，可以基于预测的订单量和潜在的订单接收方数量，确定特定区域的供求特征。可以理解的，通过一定的数据处理过程， 最终得到特定区域的供求特征的任何数据处理方式，都在步骤2830的描述范围内。所述供求特征可以是反映特定时间和特定区域内的订单量和潜在的接收订单的用户数量之间供求关系的特征。数据处理过程可以是与步骤2430相应的，或其他数据处理方式。与步骤2430相同的处理方式，此处不再赘述。有关其他的数据处理方式，一些实施例中，供求特征值可以是所述订单量与所述潜在的接收订单的用户数量之比值，再乘以一个平滑函数。设置平滑函数可以优化数据处理，可以更有效反映供求特征。在一些实施例中，所述平滑函数可以是以任何数值为底的对数函数。例如，所述对数函数是以2为底的对数函数可以参考公式(21)：
Figure PCTCN2016073559-appb-000023
其中，Q可以是供求特征值；N可以是订单量；O可以是潜在的订单接收方的数量；D可以是某订单类型的数据量。
在一些实施例中，D(可以是某订单类型的数据量)可以是步骤2810中对应的关于订单类型的任一一种或多种的描述，此处不再赘述。例如，D可以是短途订单的数据量，长途订单的数据量，用户偏好订单的数据量等其中的一种或几种的组合。
在步骤2830的信息可以来源于包括但不限于所述步骤的信息可以来源于数据库130、信息源160和/或存储模块220等。所述步骤可以由供求特征计算子单元5733实现。
以上对基于统计信息的运力调度过程的描述仅仅是具体的示例，不应被视为是唯一可行的实施方案。显然，对于本领域的专业人员来说，在了解各种算法的基本原理后，可能在不背离这一原理的情况下，对供求调度的具体实施方式与步骤进行形式和细节上的各种修正和改变，但是这些修正和改变仍在以上描述的范围之内。例如，在2810之前，可以增加关于获取订单信息和用户信息的步骤。
根据本申请的一些实施例，图29是一种移动设备的结构，该移动设备能够实现实施本申请中披露的特定系统。在本例中，用于显示 和交互位置相关信息的用户设备是一个移动设备2900，可以包括但不限于，智能手机、平板电脑、音乐播放器、便携游戏机、全球定位系统(Global Positioning System，GPS)接收器、可穿戴计算设备(如眼镜、手表等)，或者其他形式。本例中的移动设备2900可以包括一个或多个中央处理器(CPUs)2940、图形处理器(Graphical Processing Units，GPUs)2930、显示单元2920、内存2960、天线2910(例如，无线通信单元)、存储单元2990，以及一个或多个输入/输出(input output(I/O))单元2950。任何其他合适的组件，可以包括但不限于系统总线或控制器(图上未显示)，也可能被包括在移动设备2900中。如图29所示，一个移动操作系统2970，如iOS、Android、Windows Phone等，以及一个或多个应用2980可以从存储单元2990加载进内存2960中，并被中央处理器2940所执行。应用2980可以包括一个浏览器或其他适合在移动设备2900上接收并处理位置相关信息的移动应用。乘客/司机关于位置相关信息的交互可以通过输入/输出系统设备2950获得并提供给调度引擎110，以及/或系统100的其他组件，例如：通过网络150。
为了实现不同的模块、单元以及在之前的披露中所描述的他们的功能，计算机硬件平台可以被用作以上描述的一个或多个元素的硬件平台(例如：调度引擎110，和/或图1-28中描述的系统100的其他组件)。这类计算机的硬件元素、操作系统和程序语言在自然界中是常见的，可以假定本领域技术人员对这些技术都足够熟悉，能够利用这里描述的技术提供按需服务所需要的信息。一台包含用户界面元素的计算机能够被用作个人计算机(personal computer(PC))或其他类型的工作站或终端设备，被适当程序化后也可以作为服务器使用。可以认为本领域技术人员对这样的结构、程序以及这类计算机设备的一般操作都是熟悉的，因此所有附图也都不需要额外的解释。
根据本申请的一些实施例，图30是一种计算机设备的架构，这种计算机设备能够实现实施本申请中披露的特定系统。本实施例中的特定系统利用功能框图解释了一个包含用户界面的硬件平台。这种计 算机可以是一个通用目的的计算机，或是一个有特定目的的计算机。两种计算机都可以实现本实施例中的特定系统。计算机3000可以实施当前描述地提供按需服务所需要的信息的任何组件。例如：调度引擎110能够被如计算机3000的计算机通过其硬件设备、软件程序、固件以及他们的组合所实现。为了方便起见，图30中只绘制了一台计算机，但是本实施例所描述的提供按需服务所需要的信息的相关计算机功能是可以以分布的方式、由一组相似的平台所实施的，分散系统的处理负荷。
计算机3000可以包括通信端口3050，与之相连的是实现数据通信的网络。计算机3000还可以包括一个中央处理系统(CPU)单元用于执行程序指令，由一个或多个处理器组成。示例的计算机平台包括一个内部通信总线3010，不同形式的程序储存单元以及数据储存单元，例如硬盘3070，只读存储器(ROM)3030，随机存取存储器(RAM)3040，可以被配置为计算机处理和/或通信使用的各种数据文件，以及CPU所执行的可能的程序指令。计算机3000还可以包括一个输入/输出组件3060，支持计算机与其他组件(如用户界面3080)之间的输入/输出数据流。计算机3000也可以通过通信网络接受程序及数据。
以上概述了提供按需服务所需要的信息的方法的不同方面和/或通过程序实现其他步骤的方法。技术中的程序部分可以被认为是以可执行的代码和/或相关数据的形式而存在的“产品”或“制品”，是通过计算机可读的介质所参与或实现的。有形的、永久的储存介质可以包括任何计算机、处理器、或类似设备或相关的模块所用到的内存或存储器。例如各种半导体存储器、磁带驱动器、磁盘驱动器或者类似任何时间能够为软件提供存储功能的设备。
所有软件或其中的一部分有时可能通过网络进行通信，如互联网或其他通信网络。此类通信能够将软件从一个计算机设备或处理器加载到另一个。例如：从按需服务系统的一个管理服务器或主机计算机加载至一个计算机环境的硬件平台，或其他实现系统的计算机环境，或与提供按需服务所需要的信息相关的类似功能的系统。因此，另一 种能够传递软件元素的介质也可以被用作局部设备之间的物理连接，例如光波、电波、电磁波等，通过电缆、光缆或者空气实现传播。用来载波的物理介质如电缆、无线连接或光缆等类似设备，也可以被认为是承载软件的介质。在这里的用法除非限制了有形的“储存”介质，其他表示计算机或机器“可读介质”的术语都表示在处理器执行任何指令的过程中参与的介质。
因此，一个计算机可读的介质可能有多种形式，包括但不限于，有形的存储介质，载波介质或物理传输介质。稳定的储存介质可以包括：光盘或磁盘，以及其他计算机或类似设备中使用的，能够实现图中所描述的系统组件的存储系统。不稳定的存储介质包括动态内存，例如计算机平台的主内存。有形的传输介质包括同轴电缆、铜电缆以及光纤，包括计算机系统内部形成总线的线路。载波传输介质可以传递电信号、电磁信号，声波信号或光波信号，这些信号可以由无线电频率或红外数据通信的方法所产生的。通常的计算机可读介质包括硬盘、软盘、磁带、任何其他磁性介质；CD-ROM、DVD、DVD-ROM、任何其他光学介质；穿孔卡、任何其他包含小孔模式的物理存储介质；RAM、PROM、EPROM、FLASH-EPROM，任何其他存储器片或磁带；传输数据或指令的载波、电缆或传输载波的连接装置、任何其他可以利用计算机读取的程序代码和/或数据。这些计算机可读介质的形式中，可以有很多种出现在处理器在执行指令、传递一个或更多结果的过程之中。
本领域技术人员能够理解，本申请所披露的内容可以出现多种变型和改进。例如，以上所描述的不同系统组件都是通过硬件设备所实现的，但是也可能只通过软件的解决方案得以实现。例如：在现有的服务器上安装系统。此外，这里所披露的位置信息的提供可能是通过一个固件、固件/软件的组合、固件/硬件的组合或硬件/固件/软件的组合得以实现。
以上内容描述了本申请和/或一些其他的示例。根据上述内容，本申请还可以作出不同的变形。本申请披露的主题能够以不同的形式和 例子所实现，并且本申请可以被应用于大量的应用程序中。后文权利要求中所要求保护的所有应用、修饰以及改变都属于本申请的范围。

Claims (27)

  1. 一种用于基于位置信息的服务的调度方法，包括：
    获取调度参考信息；
    根据所述调度参考信息确定调度策略；以及
    向订单发起者或订单接收方发送所述调度策略。
  2. 根据权利要求1所述的方法，所述调度参考信息包括：历史订单信息、实时订单信息、历史天气信息、实时天气信息、未来天气信息、交通信息、历史服务提供者信息、或实时服务提供者信息或由车载诊断系统采集的车辆信息。
  3. 根据权利要求1所述的方法，所述调度策略的确定过程包括：
    根据所述调度参考信息确定实际调度量；
    根据所述实际调度量确定调度策略。
  4. 根据权利要求3所述的方法，所述根据所述调度参考信息确定实际调度量包括：
    确定多个订单接收方的区域分布；
    基于所述区域分布计算针对各个区域的潜在调度量；
    基于针对各个区域的潜在调度量计算针对各个区域的潜在成交量；
    基于针对各个区域的潜在成交量计算最大潜在成交增量和；以及
    基于所述最大潜在成交增量和来确定针对各个区域的实际调度量。
  5. 根据权利要求3所述的方法，所述根据所述调度参考信息确定实际调度量包括：
    确定基于地理信息的区域划分；
    计算与所述区域划分相关的服务提供者的当前需求数量；
    计算与所述区域划分相关的服务提供者的预期需求数量；以及
    基于所述当前需求数量和所述预期需求数量确定实际调度量。
  6. 根据权利要求1所述的方法，所述调度策略包括：供求密度推送策略、热点特征推送策略、统计特征推送策略、订单推送策略、订单调整策略、和/或提示信息推送策略。
  7. 根据权利要求6所述的方法，所述供求密度推送策略的确定过程包括：
    获取在给定时间和给定区域内的订单数量；
    计算在所述给定时间和所述给定区域内潜在地接收所述订单的服务提供者的数量；以及
    基于所述预测的订单量和所述潜在地接收所述订单的服务提供者的数量，确定所述给定区域的供求密度。
  8. 根据权利要求6所述的方法，所述统计特征推送策略的确定过程包括：
    根据获取的所述调度参考信息，提取服务提供者所在的位置信息；
    根据获取的所述服务提供者所在的位置信息，提取所述服务提供者所在位置附近的多个订单信息；
    确定所述多个订单中每个订单对应的标志地点；
    基于所述标志地点和订单时间信息，对所述多个订单进行分组；以及
    计算每组订单的统计特征。
  9. 根据权利要求6所述的方法，进一步包括：
    针对特定的标志地点，选择对应于所述标志地点的一组实时订单。
  10. 根据权利要求6所述的方法，所述订单推送策略确定过程包括：
    确定订单需求与服务提供者服务能力的比值小于第一阈值的第一区域以及订单需求与服务提供者服务能力的比值大于第二阈值的第二区域；
    在所述第一区域中，针对每个订单，选择向其呈现的用户；以及
    在所述第二区域中，针对每个用户，选择向其呈现的订单。
  11. 根据权利要求6所述的方法，所述订单调整策略确定过程包括：
    根据获取的所述参考信息，提取目标区域在第一预设时间段的天气信息；
    根据获取的所述参考信息，提取所述目标区域中第二预设时间段的订单信息，以及当前时刻的服务提供者信息；以及
    根据所述天气信息、所示第二预设时间段内的订单信息和所述服务提供者信息，确定订单调整策略。
  12. 一种用于基于位置信息的服务的调度系统，包括：
    一种计算机可读的存储媒介，存储可执行模块，包括：
    订单信息提取模块；
    用户信息提取模块；
    环境信息提取模块；
    其中，所述订单信息提取模块、所述用户信息提取模块、所述环境信息提取模块用于获取调度参考信息；
    计算模块，用于根据所述调度参考信息确定调度策略；及
    调度模块，用于发送所述调度策略；
    一个处理器，所述处理器能够执行所述计算机可读的存储媒介存储的可执行模块。
  13. 根据权利要求12所述的系统，所述调度参考信息包括：历史订单信息、实时订单信息、历史天气信息、实时天气信息、未来天气信息、交通信息、历史服务提供者信息、或实时服务提供者信息或由车载诊断系统采集的车辆信息。
  14. 根据权利要求12所述的系统，所述调度策略的确定过程包括：
    根据所述调度参考信息确定实际调度量；
    根据所述实际调度量确定调度策略。
  15. 根据权利要求14所述的系统，所述根据所述调度参考信息确定实际调度量包括：
    确定多个服务提供者的区域分布；
    基于所述区域分布计算针对各个区域的潜在调度量；
    基于针对各个区域的潜在调度量计算针对各个区域的潜在成交量；
    基于针对各个区域的潜在成交量计算最大潜在成交增量和；以及
    基于所述最大潜在成交增量和来确定针对各个区域的实际调度量。
  16. 根据权利要求14所述的系统，所述根据所述调度参考信息确定实际调度量包括：
    确定基于地理信息的区域划分；
    计算与所述区域划分相关的服务提供者的当前需求数量；
    计算与所述区域划分相关的服务提供者的预期需求数量；以及
    基于所述当前需求数量和所述预期需求数量确定实际调度量。
  17. 根据权利要求12所述的系统，所述调度策略包括：供求密度推送策略、热点特征推送策略、统计特征推送策略、订单推送策略、订单调整策略、或提示信息推送策略。
  18. 根据权利要求17所述的系统，所述供求密度推送策略的确定过程包括：
    获取在给定时间和给定区域内的订单数量；
    计算在所述给定时间和所述给定区域内潜在地接收所述订单的服务提供者的数量；以及
    基于所述预测的订单量和所述潜在地接收所述订单的服务提供者的数量，确定所述给定区域的供求密度。
  19. 根据权利要求17所述的系统，所述统计特征推送策略的确定过程包括：
    根据获取的所述调度参考信息，提取服务提供者所在的位置信息；
    根据获取的所述服务提供者所在的位置信息，提取所述服务提供者所在位置附近的多个订单信息；
    确定所述多个订单中每个订单对应的标志地点；
    基于所述标志地点和订单时间信息，对所述多个订单进行分组；以及
    计算每组订单的统计特征。
  20. 根据权利要求17所述的系统，进一步包括：
    针对特定的标志地点，选择对应于所述标志地点的一组实时订单。
  21. 根据权利要求17所述的系统，所述订单推送策略确定过程包括：
    确定订单需求与服务提供者服务能力的比值小于第一阈值的第一区域以及订单需求与服务提供者服务能力的比值大于第二阈值的第二区域；
    在所述第一区域中，针对每个订单，选择向其呈现的用户；以及
    在所述第二区域中，针对每个用户，选择向其呈现的订单。
  22. 根据权利要求17所述的系统，所述订单调整策略确定过程包括：
    根据获取的所述参考信息，提取目标区域在第一预设时间段的天气信息；
    根据获取的所述参考信息，提取所述目标区域中第二预设时间段的订单信息，以及当前时刻的服务提供者信息；以及
    根据所述天气信息、所示第二预设时间段内的订单信息和所述服务提供者信息，确定订单调整策略。
  23. 一种基于位置信息的服务的使用方法，包括：
    终端向根据权利要求12所述的系统发送位置信息；
    所述终端接收所述系统产生的基于位置信息的调度策略。
  24. 根据权利要求23所述的方法，所述终端可以包括：乘客终端、司机终端。
  25. 根据权利要求23所述的方法，所述调度策略包括：供求密度推送策略、热点特征推送策略、统计特征推送策略、订单推送策略、订单调整策略、或提示信息推送策略。
  26. 根据权利要求23所述的方法，所述终端可以显示所述调度策略，显示形式可以包括语音、文字、图形、视频。
  27. 根据权利要求26所述的方法，所述图形显示形式可以是基于所述终端的地图显示不同的供求密度、订单密度、订单数量、用户数量。
PCT/CN2016/073559 2015-02-13 2016-02-04 一种运力调度方法及系统 WO2016127918A1 (zh)

Priority Applications (7)

Application Number Priority Date Filing Date Title
KR1020177025673A KR20180011053A (ko) 2015-02-13 2016-02-04 운송 능력 스케줄링을 위한 방법들 및 시스템들
EP16748719.8A EP3258430A4 (en) 2015-02-13 2016-02-04 Transport capacity scheduling method and system
KR1020197005368A KR20190020852A (ko) 2015-02-13 2016-02-04 운송 능력 스케줄링을 위한 방법들 및 시스템들
SG11201706602RA SG11201706602RA (en) 2015-02-13 2016-02-04 Methods and systems for transport capacity scheduling
US15/550,169 US20180032928A1 (en) 2015-02-13 2016-02-04 Methods and systems for transport capacity scheduling
PH12017501450A PH12017501450A1 (en) 2015-02-13 2017-08-11 Methods and system for transport capacity scheduling
HK18106920.2A HK1247422A1 (zh) 2015-02-13 2018-05-28 運力調度方法和系統

Applications Claiming Priority (18)

Application Number Priority Date Filing Date Title
CN201510079087.0 2015-02-13
CN201510079087.0A CN104599088A (zh) 2015-02-13 2015-02-13 基于订单的调度方法和调度系统
CN201510088837.0A CN104616119A (zh) 2015-02-26 2015-02-26 用于提供历史订单数据和实时订单列表的方法及设备
CN201510088837.0 2015-02-26
CN201510097280.7 2015-03-04
CN201510097280.7A CN104657933A (zh) 2015-03-04 2015-03-04 用于通知订单供需密度的方法及设备
CN201510303334.0A CN104867065B (zh) 2015-06-05 2015-06-05 处理订单的方法和设备
CN201510303334.0 2015-06-05
CN201510428931.6A CN105096588B (zh) 2015-07-20 2015-07-20 一种基于obd模组的车辆调度方法、装置及系统
CN201510428931.6 2015-07-20
CN201510516164.4A CN105139089A (zh) 2015-08-20 2015-08-20 一种平衡出行供需的方法及设备
CN201510516164.4 2015-08-20
CN201510737743.1 2015-11-02
CN201510737743.1A CN106657199A (zh) 2015-11-02 2015-11-02 订单密度的确定方法、终端及服务器
CN201510990222.7A CN105575105B (zh) 2015-12-24 2015-12-24 用于交通工具的调度方法和设备
CN201510990222.7 2015-12-24
CN201610046769.6 2016-01-21
CN201610046769.6A CN105608886A (zh) 2016-01-21 2016-01-21 用于调度交通工具的方法和设备

Publications (1)

Publication Number Publication Date
WO2016127918A1 true WO2016127918A1 (zh) 2016-08-18

Family

ID=56614144

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/073559 WO2016127918A1 (zh) 2015-02-13 2016-02-04 一种运力调度方法及系统

Country Status (7)

Country Link
US (1) US20180032928A1 (zh)
EP (1) EP3258430A4 (zh)
KR (2) KR20190020852A (zh)
HK (1) HK1247422A1 (zh)
PH (1) PH12017501450A1 (zh)
SG (1) SG11201706602RA (zh)
WO (1) WO2016127918A1 (zh)

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107437146A (zh) * 2017-08-01 2017-12-05 北京同城必应科技有限公司 一种订单供需调度方法、系统、计算机设备和存储介质
CN107919012A (zh) * 2016-10-09 2018-04-17 北京嘀嘀无限科技发展有限公司 一种运力调度的方法和系统
CN107948290A (zh) * 2017-11-28 2018-04-20 上海与德科技有限公司 一种拼车信息发布方法以及服务器
CN108256707A (zh) * 2016-12-28 2018-07-06 平安科技（深圳）有限公司 保单回访管理方法和装置
CN108960544A (zh) * 2017-05-19 2018-12-07 北京嘀嘀无限科技发展有限公司 运力调度方法、装置、服务器和计算机可读存储介质
CN109478265A (zh) * 2017-06-19 2019-03-15 北京嘀嘀无限科技发展有限公司 运输服务安全评估的系统和方法
CN111160589A (zh) * 2019-12-27 2020-05-15 华能左权煤电有限责任公司 一种基于数字化精准匹配的燃煤车辆调度管理系统及方法
CN111210094A (zh) * 2020-03-06 2020-05-29 青岛海信网络科技股份有限公司 一种基于实时客流预测的机场出租车自动调度方法及装置
CN111310956A (zh) * 2018-12-11 2020-06-19 北京嘀嘀无限科技发展有限公司 调度策略的确定方法、装置及电子设备
CN111815096A (zh) * 2019-07-31 2020-10-23 北京嘀嘀无限科技发展有限公司 共享汽车投放方法、电子设备及存储介质
CN111861086A (zh) * 2020-02-14 2020-10-30 北京嘀嘀无限科技发展有限公司 一种资源配置方法和系统
CN111967698A (zh) * 2020-10-23 2020-11-20 北京国新智电新能源科技有限责任公司 基于移动充电桩调度的电动汽车充电系统及装置
CN112016771A (zh) * 2020-10-23 2020-12-01 北京国新智电新能源科技有限责任公司 基于电动汽车需求预测的移动充电桩调度方法及系统
CN112288152A (zh) * 2020-10-22 2021-01-29 武汉大学 一种基于蚁群算法和多目标函数模型的应急资源调度方法
CN112633987A (zh) * 2020-12-30 2021-04-09 北京瞰瞰科技有限公司 车辆的动态调度方法及服务器
US11107135B2 (en) 2017-11-20 2021-08-31 Advanced New Technologies Co., Ltd. Assessing shared vehicle popularities
CN113537722A (zh) * 2021-06-23 2021-10-22 西安交通大学 一种调度规划方法及应用
US20210380108A1 (en) * 2018-10-26 2021-12-09 Hitachi Astemo, Ltd. Driving assistance device
CN114493036A (zh) * 2022-02-15 2022-05-13 深圳佳利达供应链管理有限公司 一种多车型的物流运输规划方法
CN114676574A (zh) * 2022-03-28 2022-06-28 北京理工大学 基于滑模控制的可重复使用运载火箭燃料计算方法
TWI771615B (zh) * 2019-09-17 2022-07-21 英業達股份有限公司 訂單預測方法
WO2022272005A1 (en) * 2021-06-25 2022-12-29 Daniel Kogan System and method for optimizing home-visit appointments and related travel

Families Citing this family (94)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SG11201706149XA (en) * 2015-01-27 2017-08-30 Beijing Didi Infinity Tech And Dev Co Ltd Methods And Systems For Providing Information For An On-Demand Service
US10453020B2 (en) * 2015-07-31 2019-10-22 Nec Corporation Method for providing a typical load profile of a vehicle for a public transport system
US10157436B2 (en) 2015-10-09 2018-12-18 Gt Gettaxi Limited System for navigating vehicles associated with a delivery service
CN108475375A (zh) * 2015-10-29 2018-08-31 阿克森维伯股份公司 用于基于位置的被动支付的系统和方法
US10794713B2 (en) 2015-12-31 2020-10-06 Lyft, Inc. System for navigating drivers to passengers based on start times of events
US10796238B2 (en) * 2016-04-07 2020-10-06 Cognitive Scale, Inc. Cognitive personal assistant
US10733518B2 (en) * 2016-04-07 2020-08-04 Cognitive Scale, Inc. Cognitive personal procurement assistant
US10885472B2 (en) * 2016-06-28 2021-01-05 International Business Machines Corporation Dynamic transportation pooling
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
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
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
US10657383B1 (en) * 2016-09-23 2020-05-19 Amazon Technologies, Inc. Computer vision to enable services
CN108022140A (zh) * 2016-11-02 2018-05-11 北京嘀嘀无限科技发展有限公司 一种用车订单推荐方法、装置及服务器
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
JPWO2018097047A1 (ja) * 2016-11-25 2019-10-17 日本電気株式会社 交通制御システム、交通情報出力装置、交通制御方法、及び、記録媒体
US11334959B2 (en) * 2016-12-05 2022-05-17 Conduent Business Services, Llc Method and system for managing allocation of transportation services
US10915941B2 (en) 2017-03-26 2021-02-09 Shopfulfill IP LLC System for integrated retail and ecommerce shopping platforms
US20200134450A1 (en) * 2017-03-26 2020-04-30 Shopfulfill IP LLC Predicting storage need in a distributed network
TWI678675B (zh) * 2017-05-12 2019-12-01 宏碁股份有限公司 乘車熱點預測的方法及其伺服器與電腦程式產品
US10628903B2 (en) * 2017-05-22 2020-04-21 Uber Technologies, Inc. Network computer system to implement counter values for arranging services
EP3446469B1 (en) * 2017-06-23 2021-09-29 Beijing Didi Infinity Technology And Development Co., Ltd. Method of user behavior based service dispatch
US10706487B1 (en) 2017-11-11 2020-07-07 Lyft, Inc. Dynamically generating and updating multipliers for a transportation matching system using machine learning
CN111868763A (zh) * 2018-03-16 2020-10-30 福特汽车公司 优化和预测共享车辆环境中的资源可用性
WO2019195996A1 (en) * 2018-04-10 2019-10-17 Beijing Didi Infinity Technology And Development Co., Ltd. Systems and methods for vehicle scheduling
US20190332975A1 (en) * 2018-04-30 2019-10-31 Jetsmarter Inc. Dynamic segment access optimization
US20190339087A1 (en) * 2018-05-03 2019-11-07 Didi Research America, Llc Deep reinforcement learning for optimizing carpooling policies
CN112384937A (zh) 2018-05-12 2021-02-19 地质探索系统公司 地震数据解释系统
US11288609B2 (en) 2018-12-04 2022-03-29 Schlumberger Technology Corporation Systems and methods for executing a plan associated with multiple equipment by using rule-based inference
JP2021525412A (ja) 2018-05-18 2021-09-24 アシュラント インコーポレイテッドＡｓｓｕｒａｎｔ，Ｉｎｃ． リソース配分の予測およびモデリングならびにリソース入手オファーの生成、調整、および承認のための装置および方法
US20210192410A1 (en) * 2018-07-04 2021-06-24 Sony Corporation Information processing device, information processing method, and program
CN110826741A (zh) 2018-08-14 2020-02-21 北京高德云图科技有限公司 一种网络约车和发票开具方法、系统和装置
JP7253041B2 (ja) 2018-08-31 2023-04-05 グラブタクシー ホールディングス プライベート リミテッド 輸送サービスプロバイダを管理する方法、当該方法を実施するための命令を含むコンピュータプログラム、当該方法を実行させる命令を記憶する非一時記憶媒体、及び輸送サービスプロバイダを管理するための装置
US10552773B1 (en) 2018-09-07 2020-02-04 Lyft, Inc. Efficiency of a transportation matching system using geocoded provider models
CN111192071B (zh) * 2018-11-15 2023-11-17 北京嘀嘀无限科技发展有限公司 发单量预估方法及装置、训练发单概率模型的方法及装置
CN111291772B (zh) * 2018-12-06 2024-04-16 北京嘀嘀无限科技发展有限公司 信息的推送方法、装置、电子设备和计算机可读存储介质
CN111310961A (zh) * 2018-12-12 2020-06-19 北京嘀嘀无限科技发展有限公司 数据预测方法、装置、电子设备和计算机可读存储介质
FR3091392B1 (fr) * 2018-12-28 2021-01-29 Vulog Procédé et système de gestion d’une flotte de véhicules partagés
CN111476588B (zh) * 2019-01-24 2023-10-24 北京嘀嘀无限科技发展有限公司 订单需求预测方法、装置、电子设备及可读存储介质
US11282394B2 (en) * 2019-03-01 2022-03-22 Here Global B.V. Methods and systems for spatial clustering based on mobility data
CN110047279B (zh) * 2019-04-04 2020-07-31 东南大学 一种基于订单数据确定共享单车调度量的方法
CN110334975A (zh) * 2019-04-12 2019-10-15 郑州时空隧道信息技术有限公司 订单配送费用调价方法、装置及终端
US11783403B2 (en) * 2019-04-24 2023-10-10 Walmart Apollo, Llc Systems, non-transitory computer readable mediums, and methods for grocery order batching and customer experience
CN110472826B (zh) * 2019-07-09 2022-11-18 大连理工大学 一种考虑日电量偏差的梯级水电站负荷变化实时自适应方法
CN110569181A (zh) * 2019-08-27 2019-12-13 神华包神铁路集团有限责任公司 系统能力评估方法及装置、计算机设备
CN111833088A (zh) * 2019-09-17 2020-10-27 北京嘀嘀无限科技发展有限公司 一种供需预测方法及装置
US11157881B2 (en) * 2019-10-10 2021-10-26 Capital One Services, Llc Distributed system for test drive conflict rescheduling
CN110852505B (zh) * 2019-11-08 2022-07-15 闽江学院 基于量子遗传优化lvq神经网络的智慧城市交通流预测方法
CN112819266B (zh) * 2019-11-15 2023-04-18 北京三快在线科技有限公司 配送参数调整方法、装置、存储介质及电子设备
WO2021107860A1 (en) * 2019-11-29 2021-06-03 Hitachi, Ltd. Method, system, and device for matching deliveries
CN111242349B (zh) * 2019-12-30 2023-08-18 北京顺达同行科技有限公司 配送员调度方法、装置、可读存储介质和计算机设备
CN111160654B (zh) * 2019-12-31 2022-06-24 哈工汇智(深圳)科技有限公司 一种基于模糊c均值-模拟退火算法减小总成本的运输路径优化方法
CN113222308B (zh) * 2020-01-21 2023-05-30 北京三快在线科技有限公司 订单分配方法、装置、电子设备及存储介质
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
US11665281B2 (en) 2020-02-27 2023-05-30 Byung Kwan Jung Call recommendation system and call recommendation method based on artificial intelligence
KR102377402B1 (ko) * 2020-02-27 2022-03-22 주식회사 그로비 인공지능에 기반하는 콜 추천 시스템 및 콜 추천 방법
US20220405787A1 (en) * 2020-03-06 2022-12-22 Grabtaxi Holding Pte. Ltd. Demand notification device, computing device and demand notification method
WO2021194412A1 (en) * 2020-03-23 2021-09-30 Grabtaxi Holdings Pte. Ltd. Allocation system, allocation device and allocation method
CN111563657B (zh) * 2020-04-10 2022-11-15 福建电子口岸股份有限公司 一种通过蚁群算法结合多维度策略解决港口拖轮调度的方法
US11532059B2 (en) * 2020-04-20 2022-12-20 International Business Machines Corporation Geo-spatial analysis to determine boundaries of traffic regions and classifications of the boundaries for controlling drop-off/pick-up traffic
CN111582590B (zh) * 2020-05-12 2021-12-21 上海乐享似锦科技股份有限公司 一种调度预测方法、装置、设备及存储介质
CN113723721B (zh) * 2020-05-20 2024-04-09 百度在线网络技术（北京）有限公司 基于物流运输的智能调度方法、装置、设备及存储介质
CN111882093A (zh) * 2020-06-16 2020-11-03 北京嘀嘀无限科技发展有限公司 一种拼车方法和系统
KR102488785B1 (ko) * 2020-06-24 2023-01-17 트러스틸 주식회사 철강재 거래를 위한 운송 스케쥴링 방법 및 그 방법을 수행하는 서버
WO2022025704A1 (ko) * 2020-07-30 2022-02-03 주식회사 알티캐스트 수요 예측 기반 수요 공급 분산 처리를 위한 운송 서비스 서버, 복합 구독권 결정 시스템 및 그를 위한 방법
CN111880540B (zh) * 2020-07-31 2023-11-03 杭州海康机器人股份有限公司 一种agv交通管制方法、系统、装置及存储介质
KR102540446B1 (ko) * 2020-10-27 2023-06-05 현대자동차 주식회사 차량 승하차장 결정 방법 및 이를 이용한 운영 서버
CN112257936B (zh) * 2020-10-27 2022-06-07 南京领行科技股份有限公司 一种接单区域的推荐方法、装置、电子设备及存储介质
US20220129967A1 (en) * 2020-10-28 2022-04-28 Beijing Didi Infinity Technology And Development Co., Ltd. Systems and methods for providing transaction services
CN112382363A (zh) * 2020-11-20 2021-02-19 陕西中医药大学 一种中药复方质量标志物的筛选方法
KR102327009B1 (ko) * 2020-12-09 2021-11-16 주식회사 엔터프라이즈블록체인 긱근로자의 잡 스케쥴링 방법 및 장치
US11587004B2 (en) * 2020-12-10 2023-02-21 Honda Motor Co., Ltd. System and method for placement optimization of public electric vehicle charging stations using telematics data
CN112836978A (zh) * 2021-02-08 2021-05-25 北京嘀嘀无限科技发展有限公司 一种数据处理方法、装置、设备、介质和产品
CN112926875B (zh) * 2021-03-23 2023-12-19 广州宸祺出行科技有限公司 一种缓解高峰期拥堵的智能调度方法及系统
CN112990324A (zh) * 2021-03-23 2021-06-18 李光伟 基于大数据线上模式的资源推送方法及深度学习服务系统
CN113222373A (zh) * 2021-04-28 2021-08-06 广州宸祺出行科技有限公司 一种基于价值选择的司机调度方法及系统
WO2022232237A1 (en) * 2021-04-28 2022-11-03 GoBrands, Inc. Capacity management for a fleet routing service
CN113269340A (zh) * 2021-05-12 2021-08-17 广州宸祺出行科技有限公司 一种网约车区域热度值的计算及展示的方法及系统
CN116783604A (zh) * 2021-05-19 2023-09-19 格步计程车控股私人有限公司 用于确定非对称商家可见性的系统和方法
CN113541168A (zh) * 2021-05-31 2021-10-22 国网江苏省电力有限公司电力科学研究院 一种电动汽车集群可调控能力确定方法、调度方法及系统
CN113515099B (zh) * 2021-07-31 2023-06-27 康美特(厦门)智控科技有限公司 一种针织纬编机数字化智慧工厂
CN113673931B (zh) * 2021-08-23 2024-04-16 北京京东振世信息技术有限公司 用于物品的车辆调度方法、装置、设备和计算机可读介质
CN113704643B (zh) * 2021-09-03 2022-10-18 北京百度网讯科技有限公司 确定目标物体状态的方法、装置、电子设备以及存储介质
CN113743797B (zh) * 2021-09-08 2023-08-04 北京化工大学 基于大数据的无桩共享单车运营调度策略优化方法及系统
US20230104122A1 (en) * 2021-10-05 2023-04-06 At&T Intellectual Property I, L.P. Facilitating achievement of equilibrium between supply and demand of resources
CN113887635B (zh) * 2021-10-08 2022-07-01 河海大学 一种流域相似性分类方法及分类装置
CN113935528B (zh) * 2021-10-13 2023-07-21 广州市钱大妈信息科技有限公司 智能调度方法、装置、计算机设备及存储介质
CN113792945B (zh) * 2021-11-17 2022-02-08 西南交通大学 一种营运车辆的派遣方法、装置、设备及可读存储介质
CN114169703B (zh) * 2021-11-22 2022-08-19 北京白龙马云行科技有限公司 一种基于多租户的网约车调度方法及装置
WO2023107000A2 (en) * 2021-12-10 2023-06-15 Grabtaxi Holdings Pte. Ltd. Service request allocation system and method under lack of available service providers condition
CN114446006B (zh) * 2022-01-21 2022-08-26 东莞致远物流有限公司 一种基于5g时代轨迹监测的危险品运输监控方法及系统
CN115566740B (zh) * 2022-12-05 2023-04-07 广东电网有限责任公司江门供电局 一种分布式可再生能源集群聚合调控潜力评估方法和装置
CN115660383B (zh) * 2022-12-12 2023-03-10 成都工业职业技术学院 农产品产销资源均衡分配分析方法、系统、终端及介质
CN115689259B (zh) * 2023-01-04 2023-06-30 交通运输部公路科学研究所 路段车路协同场景优先级确定方法、设备及介质
CN116343461B (zh) * 2023-04-03 2023-11-17 北京白驹易行科技有限公司 一种车辆调度方法、装置及设备

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011014076A1 (en) * 2009-07-31 2011-02-03 Trond Paulsen Method and system for ordering a vehicle
CN102063691A (zh) * 2011-01-07 2011-05-18 北京东方车云信息技术有限公司 一种智能调度车辆的方法与系统
CN103985247A (zh) * 2014-04-24 2014-08-13 北京嘀嘀无限科技发展有限公司 基于城市叫车需求分布密度的出租车运力调度系统
CN104599088A (zh) * 2015-02-13 2015-05-06 北京嘀嘀无限科技发展有限公司 基于订单的调度方法和调度系统
CN104616119A (zh) * 2015-02-26 2015-05-13 北京嘀嘀无限科技发展有限公司 用于提供历史订单数据和实时订单列表的方法及设备
CN104657933A (zh) * 2015-03-04 2015-05-27 北京嘀嘀无限科技发展有限公司 用于通知订单供需密度的方法及设备
CN104867065A (zh) * 2015-06-05 2015-08-26 北京嘀嘀无限科技发展有限公司 处理订单的方法和设备
CN105096588A (zh) * 2015-07-20 2015-11-25 北京嘀嘀无限科技发展有限公司 一种基于obd模组的车辆调度方法、装置及系统
CN105139089A (zh) * 2015-08-20 2015-12-09 北京嘀嘀无限科技发展有限公司 一种平衡出行供需的方法及设备

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6931308B2 (en) * 2001-10-12 2005-08-16 Lewis C. Read Viable alternative to private vehicles in urban areas
GB0505443D0 (en) * 2005-03-17 2005-04-20 Dmist Technologies Ltd Image processing methods
JP5129799B2 (ja) * 2009-11-24 2013-01-30 株式会社エヌ・ティ・ティ・ドコモ 需要予測装置及び需要予測方法
US20120239452A1 (en) * 2011-03-17 2012-09-20 Aarjav Trivedi Fleet Management Systems and Processes
US9424515B2 (en) * 2011-12-05 2016-08-23 FasterFare, LLC Predicting taxi utilization information
US9066206B2 (en) * 2012-07-03 2015-06-23 Uber Technologies, Inc. System and method for providing dynamic supply positioning for on-demand services
US20150161554A1 (en) * 2013-12-11 2015-06-11 Uber Technologies, Inc. Intelligent dispatch system for selecting service providers

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011014076A1 (en) * 2009-07-31 2011-02-03 Trond Paulsen Method and system for ordering a vehicle
CN102063691A (zh) * 2011-01-07 2011-05-18 北京东方车云信息技术有限公司 一种智能调度车辆的方法与系统
CN103985247A (zh) * 2014-04-24 2014-08-13 北京嘀嘀无限科技发展有限公司 基于城市叫车需求分布密度的出租车运力调度系统
CN104599088A (zh) * 2015-02-13 2015-05-06 北京嘀嘀无限科技发展有限公司 基于订单的调度方法和调度系统
CN104616119A (zh) * 2015-02-26 2015-05-13 北京嘀嘀无限科技发展有限公司 用于提供历史订单数据和实时订单列表的方法及设备
CN104657933A (zh) * 2015-03-04 2015-05-27 北京嘀嘀无限科技发展有限公司 用于通知订单供需密度的方法及设备
CN104867065A (zh) * 2015-06-05 2015-08-26 北京嘀嘀无限科技发展有限公司 处理订单的方法和设备
CN105096588A (zh) * 2015-07-20 2015-11-25 北京嘀嘀无限科技发展有限公司 一种基于obd模组的车辆调度方法、装置及系统
CN105139089A (zh) * 2015-08-20 2015-12-09 北京嘀嘀无限科技发展有限公司 一种平衡出行供需的方法及设备

Non-Patent Citations (1)

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

Cited By (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107919012A (zh) * 2016-10-09 2018-04-17 北京嘀嘀无限科技发展有限公司 一种运力调度的方法和系统
CN108256707B (zh) * 2016-12-28 2021-06-22 平安科技（深圳）有限公司 保单回访管理方法和装置
CN108256707A (zh) * 2016-12-28 2018-07-06 平安科技（深圳）有限公司 保单回访管理方法和装置
CN108960544A (zh) * 2017-05-19 2018-12-07 北京嘀嘀无限科技发展有限公司 运力调度方法、装置、服务器和计算机可读存储介质
EP3461294A4 (en) * 2017-06-19 2019-04-03 Beijing Didi Infinity Technology And Development Co., Ltd. SYSTEM AND METHODS FOR TRANSPORTATION SERVICE SECURITY ASSESSMENT
CN109478265A (zh) * 2017-06-19 2019-03-15 北京嘀嘀无限科技发展有限公司 运输服务安全评估的系统和方法
CN109478265B (zh) * 2017-06-19 2021-04-06 北京嘀嘀无限科技发展有限公司 运输服务安全评估的系统和方法
CN107437146A (zh) * 2017-08-01 2017-12-05 北京同城必应科技有限公司 一种订单供需调度方法、系统、计算机设备和存储介质
CN107437146B (zh) * 2017-08-01 2021-03-09 北京同城必应科技有限公司 一种订单供需调度方法、系统、计算机设备和存储介质
US11107135B2 (en) 2017-11-20 2021-08-31 Advanced New Technologies Co., Ltd. Assessing shared vehicle popularities
CN107948290A (zh) * 2017-11-28 2018-04-20 上海与德科技有限公司 一种拼车信息发布方法以及服务器
US20210380108A1 (en) * 2018-10-26 2021-12-09 Hitachi Astemo, Ltd. Driving assistance device
US11878686B2 (en) * 2018-10-26 2024-01-23 Hitachi Astemo, Ltd. Driving assistance device
CN111310956A (zh) * 2018-12-11 2020-06-19 北京嘀嘀无限科技发展有限公司 调度策略的确定方法、装置及电子设备
CN111815096A (zh) * 2019-07-31 2020-10-23 北京嘀嘀无限科技发展有限公司 共享汽车投放方法、电子设备及存储介质
CN111815096B (zh) * 2019-07-31 2024-02-20 北京嘀嘀无限科技发展有限公司 共享汽车投放方法、电子设备及存储介质
TWI771615B (zh) * 2019-09-17 2022-07-21 英業達股份有限公司 訂單預測方法
CN111160589A (zh) * 2019-12-27 2020-05-15 华能左权煤电有限责任公司 一种基于数字化精准匹配的燃煤车辆调度管理系统及方法
CN111861086A (zh) * 2020-02-14 2020-10-30 北京嘀嘀无限科技发展有限公司 一种资源配置方法和系统
CN111210094A (zh) * 2020-03-06 2020-05-29 青岛海信网络科技股份有限公司 一种基于实时客流预测的机场出租车自动调度方法及装置
CN112288152A (zh) * 2020-10-22 2021-01-29 武汉大学 一种基于蚁群算法和多目标函数模型的应急资源调度方法
CN112288152B (zh) * 2020-10-22 2022-05-13 武汉大学 一种基于蚁群算法和多目标函数模型的应急资源调度方法
CN111967698B (zh) * 2020-10-23 2021-01-29 北京国新智电新能源科技有限责任公司 基于移动充电桩调度的电动汽车充电系统及装置
CN112016771A (zh) * 2020-10-23 2020-12-01 北京国新智电新能源科技有限责任公司 基于电动汽车需求预测的移动充电桩调度方法及系统
CN111967698A (zh) * 2020-10-23 2020-11-20 北京国新智电新能源科技有限责任公司 基于移动充电桩调度的电动汽车充电系统及装置
CN112633987A (zh) * 2020-12-30 2021-04-09 北京瞰瞰科技有限公司 车辆的动态调度方法及服务器
CN113537722A (zh) * 2021-06-23 2021-10-22 西安交通大学 一种调度规划方法及应用
CN113537722B (zh) * 2021-06-23 2023-08-01 西安交通大学 一种调度规划方法及应用
WO2022272005A1 (en) * 2021-06-25 2022-12-29 Daniel Kogan System and method for optimizing home-visit appointments and related travel
CN114493036A (zh) * 2022-02-15 2022-05-13 深圳佳利达供应链管理有限公司 一种多车型的物流运输规划方法
CN114676574A (zh) * 2022-03-28 2022-06-28 北京理工大学 基于滑模控制的可重复使用运载火箭燃料计算方法

Also Published As

Publication number Publication date
EP3258430A1 (en) 2017-12-20
KR20190020852A (ko) 2019-03-04
PH12017501450A1 (en) 2018-01-15
SG11201706602RA (en) 2017-09-28
HK1247422A1 (zh) 2018-09-21
EP3258430A4 (en) 2018-07-11
US20180032928A1 (en) 2018-02-01
KR20180011053A (ko) 2018-01-31

Similar Documents

Publication Publication Date Title
WO2016127918A1 (zh) 一种运力调度方法及系统
JP6918087B2 (ja) オン・デマンドサービスの情報を提供する方法及びシステム
US11315170B2 (en) Methods and systems for order processing
US20210232984A1 (en) Order allocation system and method
AU2020201991B2 (en) Systems and methods for recommending an estimated time of arrival
CN109478364B (zh) 确定预计到达时间的方法及系统
TWI670677B (zh) 用於推薦預估到達時間的系統和方法
US20200050938A1 (en) Systems and methods for improvement of index prediction and model building
WO2016138863A1 (zh) 一种订单配对系统及方法
TWI689744B (zh) 用於確定預估到達時間的系統和方法及相關的非暫時性機器可讀取儲存媒體
WO2017016517A1 (zh) 确定交通服务费用的方法及系统
CN110869953A (zh) 推荐交通出行服务的系统和方法

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

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 12017501450

Country of ref document: PH

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2016748719

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 11201706602R

Country of ref document: SG

ENP Entry into the national phase

Ref document number: 20177025673

Country of ref document: KR

Kind code of ref document: A