CN110856452A

CN110856452A - Transport capacity scheduling method and system

Info

Publication number: CN110856452A
Application number: CN201880002355.0A
Authority: CN
Inventors: 赵永凯
Original assignee: Beijing Didi Infinity Technology and Development Co Ltd
Current assignee: Beijing Didi Infinity Technology and Development Co Ltd
Priority date: 2018-06-20
Filing date: 2018-06-20
Publication date: 2020-02-28
Also published as: WO2019241928A1

Abstract

A transport capacity scheduling method comprises the steps of obtaining a target area; obtaining information associated with a service provider in the target area; determining whether the target area is a busy area or a non-busy area based on information associated with the service provider in the target area; acquiring one or more service intents from one or more requester terminals via a network in response to a determination that the target area is a non-busy area, each of the one or more service intents indicating an interest in initiating a service request having an origin located in the target area; determining an offer for at least one of the one or more service intents; and transmitting the at least one offer to at least one requestor terminal via the network, at least one of the one or more service intents from the at least one requestor terminal.

Description

Transport capacity scheduling method and system

Technical Field

The invention relates to the field of online-to-offline service, in particular to a method and a system for scheduling capacity.

Background

In an online-to-offline service, such as an online taxi service, the demand for taxi service may vary from region to region. For example, taxi service requirements may be higher in areas near subway stations or bus stations (also referred to as busy areas) than in remote areas (also referred to as non-busy areas). It is therefore desirable to provide a system and method of capacity scheduling to increase the demand for taxi service in less busy areas.

Disclosure of Invention

According to one aspect of the present application, a capacity scheduling system is provided. The system may include at least one storage medium and at least one processor in communication with the at least one storage medium. The at least one storage medium includes a set of instructions. The at least one processor may retrieve a target area when the at least one processor executes the instructions. The at least one processor may obtain information associated with a service provider in the target area. The at least one processor may determine whether the target area is a busy area or a non-busy area based on information associated with the service provider in the target area. The at least one processor may be configured to obtain one or more service intents from one or more requester terminals via a network in response to a determination that the target area is a non-busy area, each of the one or more service intents indicating an interest in initiating a service request having an origin located in the target area. The at least one processor may determine an offer for at least one of the one or more service intents. The at least one processor may transmit the at least one offer to at least one requesting terminal via the network, at least one of the one or more service intents from the at least one requesting terminal.

In some embodiments, the information associated with the service provider in the target area may include an average idle period.

In some embodiments, the average idle period may be determined according to the following operations: selecting one or more service order sets associated with the target area; obtaining an idle period for each of the one or more service order sets; and determining an average idle period based on the one or more idle periods of the one or more serving order sets and the number of the one or more serving order sets.

In some embodiments, each of the one or more groups of service orders may include two service orders, a first of the two service orders may be completed by the service provider at a first point in time, a second of the two service orders is accepted by the service provider at a second point in time following the first service order, a start of the second service order is located in the target area, and the idle period for each of the one or more groups of service orders is from the first point in time to the second point in time.

In some embodiments, to determine whether the target area is a busy area or a non-busy area based on information associated with a service provider in the target area, the at least one processor is to: judging whether the average idle time period is greater than a time threshold value; determining that the target area is a busy area in response to a determination that the average idle period is less than or equal to the time threshold; and in response to the average idle period being greater than the time threshold, determining that the target area is a non-busy area.

In some embodiments, to determine the offer for at least one of the one or more service intents, the at least one processor is to: determining an initial offer for the at least one of the one or more service intents; estimating a service intent count of the one or more service intents to be converted into a service order based on the initial offer; determining whether the count of service intents to be converted into a service order is less than a count threshold; and determining the initial offer of at least one of the one or more service intents as the offer of at least one of the one or more service intents in response to a determination that the count of service intents to be converted into a service order is less than the count threshold.

In some embodiments, to estimate a service intent count of the one or more service intents to be converted into a service order based on the initial offer, the at least one processor is to: for each of the one or more service intents, determining a probability that the service intent will be converted into a service order based on the initial offer; judging whether the probability is greater than a probability threshold value; and determining that the service intention is to be converted into a service order in response to a determination that the probability is greater than the probability threshold.

In some embodiments, the count threshold is equal to the sum of a count of service providers located in the target area that are not providing service and a count of service providers that are providing service whose destination is located in the target area and whose distance from the destination is within a distance threshold.

In some embodiments, to determine an offer for at least one of the one or more service intents, the at least one processor is to: determining an initial offer for the at least one of the one or more service intents; determining a sum of values of the at least one initial offer; determining whether the sum of values is less than or equal to a value threshold; and in response to the sum of values being less than or equal to the value threshold, determining the initial offer of the at least one of the one or more service intents as the offer of the at least one of the one or more service intents.

In some embodiments, the offer includes a price discount for the service for at least one of the one or more service intents.

According to another aspect of the present application, a capacity scheduling method is provided. The capacity scheduling method may include at least one of the following operations. The at least one processor may acquire a target region. The at least one processor may obtain information associated with a service provider in the target area. The at least one processor may determine whether the target area is a busy area or a non-busy area based on information associated with the service provider in the target area. The at least one processor may be configured to obtain one or more service intents from one or more requester terminals via a network in response to a determination that the target area is a non-busy area, each of the one or more service intents indicating an interest in initiating a service request having an origin located in the target area. The at least one processor may determine an offer for at least one of the one or more service intents. The at least one processor may transmit the at least one offer to at least one requesting terminal via the network, at least one of the one or more service intents from the at least one requesting terminal.

According to another aspect of the present application, a capacity scheduling system is provided. The capacity scheduling system may include a region acquisition module for acquiring a target region; a provider information acquisition module for acquiring information associated with a service provider in the target area; a region information determination module to determine whether the target region is a busy region or a non-busy region based on information associated with the service provider in the target region; an intention acquisition module, configured to acquire, via a network, one or more service intents from one or more requester terminals in response to a determination that the target area is a non-busy area, each of the one or more service intents indicating an interest in initiating a service request having a start point located in the target area; the preference determining module is used for determining a preference for at least one service intention in the one or more service intentions; and a transmission module to transmit the at least one offer to at least one requestor terminal via the network, at least one of the one or more service intents from the at least one requestor terminal.

According to another aspect of the present application, a computer-readable medium may include at least one set of instructions for capacity scheduling, the at least one set of instructions being executable by at least one processor of a computing device. The at least one processor may acquire a target region. The at least one processor may obtain information associated with a service provider in the target area. The at least one processor may determine whether the target area is a busy area or a non-busy area based on information associated with the service provider in the target area. The at least one processor may be configured to obtain one or more service intents from one or more requester terminals via a network in response to a determination that the target area is a non-busy area, each of the one or more service intents indicating an interest in initiating a service request having an origin located in the target area. The at least one processor may determine an offer for at least one of the one or more service intents. The at least one processor may transmit the at least one offer to at least one requesting terminal via the network, at least one of the one or more service intents from the at least one requesting terminal.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings used in the description of the embodiments will be briefly introduced below. It is obvious that the drawings in the following description are only some embodiments of the application, and that it is also possible for a person skilled in the art to apply the application to other similar scenarios without inventive effort on the basis of these drawings. Unless otherwise apparent from the context of language or otherwise indicated, like reference numerals in the figures refer to like structures and operations.

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

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

FIG. 3 is a schematic diagram of exemplary hardware and software components of a mobile device according to some embodiments of the application;

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

FIG. 5 is an exemplary flow diagram of capacity scheduling, shown in accordance with some embodiments of the present application;

FIG. 6 is an exemplary flow diagram for determining an average idle period, shown in accordance with some embodiments of the present application;

FIG. 7 is an exemplary flow diagram for determining offers, shown in accordance with some embodiments of the present application; and

FIG. 8 is an exemplary flow diagram for determining offers, shown in accordance with some embodiments of the present application.

Detailed Description

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings used in the description of the embodiments will be briefly introduced below. It is obvious that the drawings in the following description are only examples or embodiments of the application, from which the application can also be applied to other similar scenarios without inventive effort for a person skilled in the art. Unless otherwise apparent from the context, or otherwise indicated, like reference numbers in the figures refer to the same structure or operation.

As used in this application and the appended claims, the terms "a," "an," "the," and/or "the" are not intended to be inclusive in the singular, but rather are intended to be inclusive in the plural unless the context clearly dictates otherwise. In general, the terms "comprises" and "comprising" merely indicate that steps and elements are included which are explicitly identified, that the steps and elements do not form an exclusive list, and that a method or apparatus may include other steps or elements.

Although various references are made herein to certain modules or units in a system according to embodiments of the present application, any number of different modules or units may be used and run on a client and/or server. The modules are merely illustrative and different aspects of the systems and methods may use different modules.

Flow charts are used herein to illustrate operations performed by systems according to embodiments of the present application. It should be understood that the preceding or following operations are not necessarily performed in the exact order in which they are performed. Rather, various steps may be processed in reverse order or simultaneously. Meanwhile, other operations may be added to the processes, or a certain step or several steps of operations may be removed from the processes.

Further, while the system and method described herein are primarily directed to processing service orders, it should be understood that this is merely one exemplary embodiment. The system or method of the present application is also applicable to other types of online-to-offline services. For example, the systems and methods of the present application may be applied to different transportation systems, including terrestrial, marine, aerospace, and the like, or any combination of the above. The vehicles used in the transportation system may include taxis, private cars, tailplanes, buses, trains, bullet trains, high speed railways, subways, ships, airplanes, spacecraft, hot air balloons, unmanned vehicles, bicycles, tricycles, motorcycles, and the like, or any combination thereof. The transportation system may also include a transportation system to which management and/or distribution is applied, such as a delivery/receipt system, or a take-away system. Application scenarios of the system or method of the present application may include a web page, a browser plug-in, a client terminal, a customization system, an internal analysis system, an artificial intelligence robot, and the like, or any combination thereof.

The terms "passenger," "requestor," "service requestor," and "customer," etc. are used interchangeably herein to refer to a party that needs or orders a service, either individually or as a tool. Likewise, "driver," "provider," "service provider," "supplier," and the like, as described herein, are interchangeable and refer to an individual, tool, or other entity, etc. that provides a service or assists in providing a service. In addition, a "user" as described herein may be a party that needs or subscribes to a service, or a party that provides or assists in providing a service. For example, the user may be a passenger, a driver, an operator, etc., or any combination thereof. In this application, "passenger" and "passenger terminal" are used interchangeably, and "driver" and "driver terminal" are used interchangeably.

In this application, the term "service request" may refer to a request initiated by a passenger, a requestor, a service requestor, a customer, a driver, a provider, a service provider, a supplier, and the like, or any combination of the foregoing. The service request may be accepted by any of a passenger, a requestor, a service requestor, a customer, a driver, a provider, a service provider, or a supplier. The service request may be for a fee or free of charge. In this application, the terms "service request" and "service order" may be used interchangeably.

The positioning technology used in the present application may include one of a Global Positioning System (GPS), a global satellite navigation system (GLONASS), a COMPASS navigation system (COMPASS), a galileo positioning system, a quasi-zenith satellite system (QZSS), a wireless fidelity (Wi-Fi) positioning technology, and the like, or the like or any combination thereof. One or more of the above positioning techniques may be used interchangeably in this application.

One aspect of the present application relates to systems and methods for adjusting transport capacity in connection with an online-to-offline service (e.g., an online taxi service). For areas where taxi service demand is relatively low (e.g., a less busy region), the online-to-offline service platform may send an offer to at least one passenger who wants to initiate a service order (e.g., a passenger enters the origin of the region and a predetermined destination in his/her phone, but does not formally make a taxi service request). By virtue, passengers who intend to place a service order in the region are more likely to make taxi service requests, so as to increase the demand for taxi service in less busy regions.

It should be noted that online-to-offline services, such as online ride-sharing services, are a new form of service that exists only in the post-internet era. It provides users and service providers with a solution that is only possible in the late internet era. In an era prior to the internet, users may receive discounts, e.g. related to newspapers, television advertisements, telephone calls or flyers, as offers. It is difficult to notify users of offers related to services in a timely manner. In addition, the traditional preferential recommendation mode in the era before the internet can cover a limited range of users. However, the online-to-offline service system provides offers to more users through the internet and ensures that users do not miss offers. Therefore, through the internet, an online-to-offline service system may provide a more efficient and accurate recommendation platform for users not encountered in the previous era of the internet.

Fig. 1 is a schematic diagram of an exemplary online-to-offline service system, shown in accordance with some embodiments of the present application. For example, the online-to-offline service system 100 may be an online transportation service platform that provides transportation services, such as taxi reservations, designated driving services, express delivery vehicles, ride sharing, bus service, takeaway service, driver recruitment service, and pickup service. For the sake of brevity, the methods and/or systems described in this application are exemplified by a taxi service. It should be noted that the taxi service described above is provided for illustrative purposes only, and is not intended to limit the scope of the present application. It will be apparent to one of ordinary skill in the art that the methods and/or systems described herein may be applied to other similar situations, such as delivering services, etc.

The online-to-offline service system 100 may include a server 110, a network 120, a requester terminal 130, a provider terminal 140, a storage device 150, and a location system 160.

In some embodiments, the server 110 may be a single server or a group of servers. The server farm can be centralized or distributed (e.g., server 110 can be a distributed system). In some embodiments, the server 110 may be local or remote. For example, the server 110 may obtain information and/or data stored within the requester terminal 130, the provider terminal 140, and/or the storage device 150 via the network 120. In another example, the server 110 may be directly connected with the requestor terminal 130, the provider terminal 140, and/or the storage device 150 and access information and/or data stored therein. In some embodiments, the server 110 may be implemented on a cloud platform. In some embodiments, the storage 140 may be implemented on a cloud platform. By way of example only, the cloud platform may include a private cloud, a public cloud, a hybrid cloud, a cell cloud, a distributed cloud, an internal cloud, a multi-tiered cloud, and the like, or any combination thereof. In some embodiments, server 110 may execute on a computing device 200 having one or more components described in fig. 2 of the present application.

In some embodiments, the server 110 may include a processing engine 112. Processing engine 112 may process information and/or data related to the online-to-offline service. For example, processing engine 112 may determine an offer for the intent of the service. In some embodiments, the processing engine 112 may include one or more processing engines (e.g., a single chip processing engine or a multi-chip processing engine). Merely by way of example, the processing engine 112 may include one or more hardware processors such as a Central Processing Unit (CPU), an Application Specific Integrated Circuit (ASIC), an application specific instruction set processor (ASIP), an image processing unit (GPU), a physical arithmetic processing unit (PPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a controller, a microcontroller unit, a Reduced Instruction Set Computer (RISC), a microprocessor, or the like, or any combination of the above.

Network 120 may facilitate the exchange of information and/or data. In some embodiments, one or more components of the online-to-offline service system 100 (e.g., the server 110, the requestor terminal 130, the provider terminal 140, and the storage device 150) may communicate information to other components of the online-to-offline service system 100 over the network 120. For example, the server 110 may obtain/obtain a service request from the requestor terminal 130 via the network 120. In some embodiments, the network 120 may be any one of, or a combination of, a wired network or a wireless network. By way of example only, network 120 may include a cable network, a wired network, a fiber optic network, a telecommunications network, an intranet, the internet, a Local Area Network (LAN), a Wide Area Network (WAN), a Wireless Local Area Network (WLAN), a Metropolitan Area Network (MAN), a Public Switched Telephone Network (PSTN), a bluetooth network, a ZigBee network, a Near Field Communication (NFC) network, the like, or any combination of the above. For example, the network 120 may include wired or wireless network access points, such as base stations and/or Internet access points 120-1, 120-2 … …. Through which one or more components of the online-to-offline service system 100 may connect to the network 120 to exchange information and/or data.

In some embodiments, the requestor may be a user of the requestor terminal 130. In some embodiments, the user of the requestor terminal 130 may be someone other than the requestor. For example, user a of the requesting terminal 130 may send a service request to user B through the requesting terminal 130 or receive services and/or information or instructions from the server 110. In some embodiments, the provider may be a user of the provider terminal 140. In some embodiments, the user of the provider terminal 130 may be a person other than the provider. For example, user C of provider terminal 140 may receive a service request for user D via provider terminal 140 and/or information or instructions from server 110. In some embodiments, "requestor" and "requestor terminal" may be used interchangeably, and "provider" and "provider terminal" may be used interchangeably.

In some embodiments, the requestor terminal 130 may include a mobile device 130-1, a tablet computer 130-2, a laptop computer 130-3, a built-in device 130-4, the like, or any combination thereof. In some embodiments, the mobile device 130-1 may include a smart home device, a wearable device, a mobile device, a virtual reality device, an augmented reality device, the like, or any combination of the above. In some embodiments, the smart home devices may include smart lighting devices, control devices for smart appliances, smart monitoring devices, smart televisions, smart video cameras, interphones, and the like, or any combination thereof. In some embodiments, the wearable device may include a bracelet, footwear, glasses, helmet, watch, clothing, backpack, smart accessory, the like, or any combination of the above. In some embodiments, the mobile device may comprise a mobile phone, a Personal Digital Assistant (PDA), a gaming apparatus, a navigation device, a POS machine, a laptop computer, a desktop computer, or the like, or any combination of the above. In some embodiments, the virtual reality device and/or augmented reality device may include a virtual reality helmet, virtual reality glasses, virtual reality eyecups, augmented reality helmets, augmented reality glasses, augmented reality eyecups, and the like, or any combination thereof. For example, the virtual reality device and/or augmented reality device may include a Google Glass^{M position}，Oculus Rift^TM，Hololens^TM，Gear VR^TMAnd the like. In some embodiments, the in-vehicle device 130-4 may include an on-board computer, an on-board television, or the like. In some embodiments, the requesting terminal 130 may be a device with location technology that may be used to locate the user of the requesting terminal 130 (e.g., a service requester) and/or the location of the requesting terminal 130.

In some embodiments, the provider terminal 140 may be a similar or identical device as the requestor terminal 130. In some embodiments, the provider terminal 140 may be a device with location technology to locate a user of the provider terminal 140 (e.g., a service provider) and/or a location of the provider terminal 140. In some embodiments, the requester terminal 130 and/or the provider terminal 140 may communicate with one or more other locating devices to determine the location of the requester, requester terminal 130, provider, and/or provider terminal 140. In some embodiments, the requestor terminal 130 and/or the provider terminal 140 may transmit the location information to the server 110.

Storage device 150 may store data and/or instructions. In some embodiments, the storage device 150 may store data obtained from the requester terminal 130 and/or the provider terminal 140. For example, the storage device 150 may store the real-time location of the service provider obtained from the provider terminal 140. In some embodiments, storage device 150 may store data and/or instructions that server 110 uses to perform or use to perform the exemplary methods described in this application. For example, the storage device 150 may store instructions used by the server 110 to execute or to determine offers for service intent. In some embodiments, storage device 150 may include a mass storage, removable storage, volatile read-write memory, read-only memory (ROM), or the like, or any combination thereof. Exemplary removable storage may include flash drives, floppy disks, optical disks, memory cards, compact disks, magnetic tape, and the like. Exemplary volatile read and write memory can include Random Access Memory (RAM). Exemplary RAM may include Dynamic RAM (DRAM), double-data-Rate synchronous dynamic RAM (DDR SDRAM), Static RAM (SRAM), thyristor RAM (T-RAM), zero-capacitance RAM (Z-RAM), and the like. Exemplary ROMs may include Mask ROM (MROM), Programmable ROM (PROM), erasable programmable ROM (PEROM), Electrically Erasable Programmable ROM (EEPROM), compact disk ROM (CD-ROM), digital versatile disk ROM, and the like. In some embodiments, the storage device 150 may be implemented on a cloud platform. By way of example only, the cloud platform may include a private cloud, a public cloud, a hybrid cloud, a cell cloud, a distributed cloud, an internal cloud, a multi-tiered cloud, and the like, or any combination thereof.

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

The positioning system 160 may determine information associated with an object, such as the requestor terminal 130, the provider terminal 140, and the like. For example, the location system 160 may determine the real-time location of the requester terminal 130. In some embodiments, the positioning system 160 may be a Global Positioning System (GPS), global navigation satellite system (GLONASS), COMPASS navigation system (COMPASS), beidou navigation satellite system (BDS), galileo positioning system, quasi-zenith satellite system (QZSS), or the like. The information may include the subject's position, elevation, velocity or acceleration, or the current time. The location may be in the form of coordinates, such as latitude and longitude coordinates, and the like. Positioning system 160 may include one or more satellites, such as satellite 160-1, satellite 160-2, and satellite 160-3. The satellites 160-1 to 160-3 may independently or collectively determine the above information. The location system 160 may transmit the above information to the network 120, the requester terminal 130 or the provider terminal 140 via a wireless connection.

In some embodiments, the exchange of information between one or more components of the online-to-offline service system 100 may be accomplished by requesting or intending to request a service. The object of the service request may be any product. In some embodiments, the product may be a tangible product or an intangible product. Tangible products may include food, pharmaceuticals, commodities, chemical products, appliances, clothing, automobiles, homes, luxury goods, and the like, or any combination thereof. Intangible products may include service products, financial products, knowledge products, internet products, and the like, or any combination thereof. The internet products may include personal host products, web products, mobile web products, business host products, embedded products, and the like, or any combination thereof. The mobile internet product may be used for software, programs, systems, etc. of the mobile terminal or any combination of the above examples. The mobile terminal may include a tablet computer, laptop computer, mobile phone, Personal Digital Assistant (PDA), smart watch, POS device, on-computer, on-television, wearable device, and the like, or any combination thereof. For example, the product may be any software and/or application used on a computer or mobile phone. The software and/or applications may be related to social interaction, shopping, transportation, entertainment, learning, investment, etc., or any combination thereof. In some embodiments, the software and/or applications associated with the transportation may include travel software and/or applications, vehicle scheduling software and/or applications, mapping software and/or applications, and the like. For vehicle scheduling software and/or applications, the vehicle may be a horse, a carriage, a human powered vehicle (e.g., a cart, a bicycle, a tricycle, etc.), an automobile (e.g., a taxi, a bus, a personal car, etc.), a train, a subway, a ship, an aircraft (e.g., an airplane, a helicopter, a space shuttle, a rocket, a hot air balloon, etc.), etc., or any combination thereof.

FIG. 2 is a diagram illustrating exemplary hardware and software components of a computing device on which the processing engine described herein may be implemented, according to some embodiments of the application. As shown in fig. 2, computing device 200 may include a processor 210, a memory 220, an input/output interface 230, and a communication port 240.

The processor 210 (e.g., logic circuitry) may execute computer instructions (e.g., program code) and perform the functions of the processing engine 112 in accordance with the techniques described herein. For example, the processor 210 may include interface circuitry 210-a and processing circuitry 210-b therein. The interface circuit may be configured to receive electronic signals from a bus (not shown in fig. 2), where the electronic signals encode structured data and/or instructions for processing by the processing circuit. The processing circuitry may perform logical computations and then determine conclusions, results and/or instructions encoded into electronic signals. The interface circuit may then send electrical signals from the processing circuit via a bus.

The computer instructions may include, for example, routines, programs, objects, components, data structures, procedures, modules, and functions that perform the particular functions described herein. For example, the processor 210 may determine an offer for the intent of the service. In some embodiments, processor 210 may include one or more hardware processors, such as microcontrollers, microprocessors, Reduced Instruction Set Calculators (RISC), Application Specific Integrated Circuits (ASICs), application specific instruction set processors (ASIPs), Central Processing Units (CPUs), Graphics Processing Units (GPUs), Physical Processing Units (PPUs), microcontroller units, Digital Signal Processors (DSPs), Field Programmable Gate Arrays (FPGAs), Advanced RISC Machines (ARMs), Programmable Logic Devices (PLDs), any circuit or processor capable of executing one or more functions, or the like, or any combination thereof.

For illustration only, only one processor is depicted in computing device 200. It should be noted, however, that the computing device 200 in the present disclosure may also include multiple processors, whereby operations and/or method steps performed by one processor as described herein may also be performed by multiple processors, either jointly or separately. For example, if in the present application the processors of computing device 200 perform steps a and B, it should be understood that steps a and B may also be performed by two different processors of computing device 200, either collectively or independently (e.g., a first processor performing step a, a second processor performing step B, or a first and second processor performing steps a and B collectively).

Memory 220 may store data/information obtained from requester terminal 130, provider terminal 140, and/or any other component of online-to-offline service system 100. In some embodiments, memory 220 may include mass storage, removable storage, volatile read-write memory, read-only memory (ROM), the like, or any combination thereof. For example, mass storage may include magnetic disks, optical disks, solid state drives, and the like. Removable storage may include flash drives, floppy disks, optical disks, memory cards, compact disks, magnetic tape, and the like. Volatile read and write memory may include Random Access Memory (RAM). Exemplary RAM may include Dynamic RAM (DRAM), double-data-rate synchronous dynamic RAM (DDR SDRAM), Static RAM (SRAM), thyristor RAM (T-RAM), zero-capacitance RAM (Z-RAM), and the like. Exemplary ROMs may include Mask ROM (MROM), Programmable ROM (PROM), erasable programmable ROM (PEROM), Electrically Erasable Programmable ROM (EEPROM), optical disk ROM, or digital versatile disk ROM, among others. In some embodiments, memory 220 may store one or more programs and/or instructions to perform the example methods described herein. For example, memory 220 may store a program that processing engine 112 uses to determine offers for service intent.

The input/output interface 230 may input and/or output signals, data, information, and the like. In some embodiments, the input/output interface 230 may enable user interaction with the processing engine 112. For example, an operator of the server 110 may input instructions related to an offer to determine service intent through the input/output interface 230. In some embodiments, input/output interface 230 may include an input device and an output device. Exemplary input devices may include a keyboard, mouse, touch screen, microphone, etc., or any combination thereof. Exemplary output devices may include a display device, speakers, printer, projector, etc., or any combination thereof. Examples of a display device may include a Liquid Crystal Display (LCD), a Light Emitting Diode (LED) based display, a flat panel display, a curved screen, a television device, a Cathode Ray Tube (CRT), a touch screen, and the like, or any combination thereof.

The communication port 240 may be connected to a network (e.g., network 120) to facilitate data communication. The communication port 240 may establish a connection between the processing engine 112, the requestor terminal 130, the provider terminal 140, and/or the data storage device 150. For example, processing engine 112 may send the offer to requester terminal 130 through communication port 240. The connection may be a wired connection, a wireless connection, any other communication connection that may enable data transmission and/or reception, and/or any combination of these connections. The wired connection may include, for example, an electrical cable, an optical cable, a telephone line, etc., or any combination thereof. The wired connection may include a metal cable, an optical cable, a hybrid cable, etc., or any combination thereof. The wireless connection may include, for example, one or more of bluetooth, Wi-Fi, WiMax, WLAN, ZigBee, mobile networks (e.g., 3G, 4G, 5G, etc.), and the like, in combination. In some embodiments, the communication port 240 may be and/or include a standardized communication port, such as RS232, RS485, and the like.

FIG. 3 is a diagram illustrating exemplary hardware and software components of a mobile device on which a requestor terminal and/or a provider terminal may be implemented according to some embodiments of the application. As shown in fig. 3, the mobile device 300 may include a communication platform 310, a display 320, a Graphics Processor (GPU)330, a Central Processing Unit (CPU)340, an input/output interface 350, a memory 360, and a storage 390. In some embodiments, any other suitable component, including but not limited to a system bus or a controller (not shown), may also be included in the mobile device 300. In some embodiments, the operating system 370 is mobile (e.g., iOS)^TM、Android^TM、Windows Phone^TMEtc.) and one or more application programs 380 may be loaded from storage 390 into memory 360 for execution by CPU 340. The application 380 may include a browserOr any other suitable mobile application for receiving and presenting information related to the online transport service or other information from the processing engine 112 and sending information related to the online transport service or other information to the processing engine 112 user interaction with the information flow may be obtained via the input/output interface 350 and provided to the processing engine 112, and/or other components of the online-to-offline service system 100, via the network 120. For example, the service requester may input the origin and/or destination through the input/output interface 350 of the requester terminal 130. The origin and destination can be communicated to the processing engine 112 through the communication platform 310. The offers may be received through the communication platform 310. The offers may be stored in memory 390 and/or displayed on display 320.

It will be understood by those of ordinary skill in the art that when a component of the online-to-offline service system 100 performs a function, the component may perform the function via electrical and/or electromagnetic signals. For example, when processing engine 112 processes a task such as making a determination or identifying information, processing engine 112 may operate logic circuits in its processor to process such a task. When processing engine 112 transmits data (e.g., offers) to requester terminal 130 and/or provider terminal 140, a processor of processing engine 112 may generate an electrical signal encoding/including the data. The processor of the processing engine 112 may then send the electrical signal to an output port of the processing engine 112. If the requestor terminal 130 and/or the provider terminal 140 are in communication with the processing engine 112 via a wired network, an output port of the processing engine 112 may be physically connected to a cable that may further transmit electrical signals to an input port of the requestor terminal 130 and/or the provider terminal 140. If the requestor terminal 130 and/or the provider terminal 140 communicate with the processing engine 112 via a wireless network, the output port of the processing engine 112 may be one or more antennas that can convert electrical signals into electromagnetic signals. In an electronic device, such as requester terminal 130, provider terminal 140, and/or server 110, when a processor of the electronic device processes instructions, sends instructions, and/or performs an action, the instructions and/or action are conducted via electrical signals. For example, when the processor retrieves or obtains data from a storage medium (e.g., storage device 150, memory 220, memory 390), an electrical signal may be sent to a read/write device of the storage medium that can read or write structured data in or to the storage medium. The structured data may be transmitted to the processor in the form of electrical signals via a bus of the electronic device. Herein, an electrical signal may refer to one electrical signal, a series of electrical signals, and/or a plurality of discrete electrical signals.

FIG. 4 is a block diagram of an exemplary processing engine shown in accordance with some embodiments of the present application. The processing engine 112 may include an area acquisition module 410, a provider information acquisition module 420, an area information determination module 430, an intent acquisition module 440, a coupon determination module 450, and a transmission module 460.

The region acquisition module 410 may be configured to acquire a target region. In some embodiments, processing engine 112 may divide a region (e.g., Beijing) into a plurality of sub-regions. In some embodiments, processing engine 112 may divide a region (e.g., Beijing) into a plurality of sub-regions. In some embodiments, the area may be divided into a plurality of sub-areas according to geographical conditions. For example, a region may be divided into two sub-regions by a river. In some embodiments, the region may be divided into a plurality of sub-regions according to a management boundary. For example, Beijing may be classified as an east region, a west region, a sunny region, a Hai lake region, and the like. In some embodiments, a region may be divided into multiple geometrically shaped sub-regions. The geometry of the sub-regions may be regular or irregular. Regular geometric shapes may include triangles, squares, rectangles, pentagons, octagons, circles, hexagons, etc., or any combination thereof. In some embodiments, the multiple sub-regions may be the same or different. For example, each of the plurality of sub-regions may be hexagonal in shape having a side length of 300, 500, 700, 1000, 1500 meters, or the like. As another example, one of the plurality of sub-regions may be a hexagon having a side of 300 meters, and another of the plurality of sub-regions may be a hexagon having a side of 500 meters. For another example, one of the plurality of sub-regions may be hexagonal and another of the plurality of sub-regions may be square.

In some embodiments, information related to the region divided into a plurality of sub-regions may be stored in the memory device 150 and/or the memory 220. The region acquisition module 410 may acquire information about the region divided into a plurality of sub-regions from the storage device 150 and/or the memory 220 and determine one of the plurality of sub-regions as the target region.

The provider information acquisition module 420 may be configured to acquire information associated with service providers in the target area (e.g., see the description of fig. 6 herein for more details). In some embodiments, the information associated with the service provider in the target area may include an average idle period for the service provider associated with the target area.

In some embodiments, the requestor terminal 130 and/or the provider terminal 140 may establish communication (e.g., wireless communication) with the server 110 through an application (e.g., application 380 in fig. 3) installed in the requestor terminal 130 and/or the provider terminal 140 via the network 120. The application may be associated with an online-to-offline service system 100. For example, the application may be a call taxi application associated with the online-to-offline service system 100. In some embodiments, when a service provider accepts (or completes) a service order, a terminal associated with the service provider (e.g., provider terminal 140) may transmit a point in time to accept (or complete) the service order when the service provider accepts (or completes) the service order. For example, the service provider may press a button in an application interface in the provider terminal 140 to accept (or complete) the service order. After the service provider presses the button, the provider terminal 140 may transmit a point in time at which the service provider accepts (or completes) the service order to the processing engine 112, and/or the storage device 150. Alternatively or additionally, the service provider may send a message to the server 110 via the provider terminal 140 indicating that he/she has accepted or completed the service order. The server 110 (e.g., processing engine 112) may record the point in time at which the server 110 receives a message indicating that the service provider has accepted or completed the service order.

In some embodiments, a service order may refer to information of a transportation service formally requested by a service requester and sent to server 110 by requester terminal 130. For example, when the service requester sends information of the transportation service to the server 110, the service requester may do so by pressing a button on an application interface installed in the requester terminal 130. Upon receiving the information for the transport service, server 110 may determine that the information for the transport service was formally placed and determine the information for the transport service as a service order.

In some embodiments, if one service provider completes a service order (also referred to as a first service order in this example) at a certain point in time (also referred to as a first point in time in this example), and, after the first service order, subsequently accepts another service order (also referred to as a second service order in this example) having an origin located in the target area at another point in time (also referred to as a second point in time in this example), the time interval between the first point in time and the second point in time may be referred to as an idle period of the service provider. In some embodiments, the average idle period associated with the target region may be equal to the average of the one or more idle periods associated with the target region.

In some embodiments, for each of the one or more idle periods used to determine the average idle period, the first point in time (e.g., the point in time at which the service provider completed the first service order) and the second point in time (e.g., the point in time at which the service provider subsequently accepted the second service order starting in the target area after the first service order) may be between the current time (e.g., the point in time at which the area acquisition module 410 acquired the target area) and a point in time before the current time. For example, if the area acquisition module 410 acquires the target area at 10:00 am on monday, the first and second points in time may be between the 9 am to 10 am periods of monday for each of the one or more idle periods used to determine the average idle period. For another example, if the area acquisition module 410 acquires the target area at 10:00 am on monday, the first and second points in time may be between the 9 am to 10 am periods of the last month for each of the one or more idle periods used to determine the average idle period.

The area information determination module 430 may be configured to determine whether the target area is a busy area or a non-busy area based on information associated with the service provider in the target area.

In some embodiments, the region information determination module 430 may determine whether the target region is a busy region or a non-busy region based on an average idle period of the target region. The region information determination module 430 may determine whether the average idle period is greater than a time threshold (e.g., 1 minute, 2 minutes, 3 minutes, 5 minutes, 8 minutes, 10 minutes). The area information determination module 430 may determine that the target area is a busy area in response to a determination that the average idle period is less than or equal to the time threshold. The region information determination module 430 may determine that the target region is a non-busy region in response to a determination that the average idle period is greater than the time threshold.

The intent acquisition module 440 may be configured to acquire one or more service intents from one or more requestor terminals (e.g., requestor terminal 130) via a network (e.g., network 120). Each of the one or more service intents may represent an interest in requesting a transport service. The origin (e.g., expected departure location) of each of the plurality of intents may be in the target area.

An application installed in the requestor terminal 130 may instruct the requestor terminal 130 to continuously or periodically monitor input from the service requestor and send the input to the online-to-offline service system 100 via the network 120. Accordingly, the service requester terminal 130 can inform the online-to-offline service system 100 of the input of the service requester in real time or substantially real time. Therefore, when a service requester inputs an origin and/or destination, the online-to-offline service system 100 may receive sufficient information to determine the intent of the service requester. For example, when the service requester inputs the origin and destination, the online-to-offline service system 100 may have received the origin and destination and determined that the service requester intends to request the transportation service before transmitting the origin and destination to the online-to-offline service system 100.

In some embodiments, the origin and/or destination may be a specified location input by the service requestor through the requestor terminal 130 (e.g., input/output interface 350 in fig. 3). In some embodiments, the requestor terminal 130 may automatically obtain the origin and/or destination. For example, "a meeting at a location of 10 a am on wednesday" is recorded in the calendar of the service requester terminal 130. The requester terminal 130 may automatically determine location a as a destination based on an event in the calendar. In some embodiments, the requesting terminal 130 may obtain its location (which is referred to as the location of the service requester) through a combination of one or more of positioning technologies in the requesting terminal 130, such as GPS, GLONASS, COMPASS, QZSS, BDS, WiFi positioning technologies, and the like.

In some embodiments, the point in time at which the server 110 receives the origin and/or destination of the one or more service intents for the one or more service intents obtained by the intent obtaining module 440 may be within a certain time period (e.g., 10 minutes) before the current time.

The offer determination module 450 may be configured to determine an offer for at least one of the one or more service intentions. The offer may be used as an incentive for the service requestor to translate the intent of the service into a service order. In some embodiments, the offer may include a discount on the cost of a service order, a red envelope, a discount coupon, a cash coupon, a credit, a cash refund, or the like, or any combination thereof. In some embodiments, the greater the value of the offer, the more likely the service requestor receiving the offer will translate the service intent into a service order.

In some embodiments, the at least one offer for at least one of the one or more service intents may be the same or different. For example, the offer may be a $ 1 cash coupon. As another example, the offer for one service intent may be a $ 1 cash coupon and the offer for another service intent may be a $ 3 cash coupon. As another example, the offer for one service intent may be a $ 1 cash coupon and the offer for another service intent may be a 50% discount off of the cost of the service order.

In some embodiments, offer determination module 450 may determine an initial offer for at least one of the one or more service intents. For each of the one or more service intents, offer determination module 450 may determine whether to determine an initial offer for the service intent and/or which initial offer to determine for the service intent.

In some embodiments, offer determination module 450 may determine an initial offer for the service intent based on the destination of the service intent. For example, when the destination of the service intent is located in a busy area (e.g., Beijing monozone), indicating that the probability that the service intent translates into a service order is relatively large (e.g., 60%, 70%, 80%, 90%) even without an offer, offer determination module 450 may determine an initial offer for the service intent that has a relatively small value (e.g., a $ 1 cash coupon) or not determine an initial offer for the service intent. When the destination of the service intent is located in a remote area (e.g., Yanqing district, Beijing), the likelihood that the service intent will be converted into a service order is relatively small if there is no offer, and offer determination module 450 may determine an initial offer for the service intent that has a relatively large value (e.g., a $ 5 cash coupon).

In some embodiments, offer determination module 450 may determine an initial offer for the service intent based on historical information associated with the service requestor for the service intent. For example, if the service requestor has a historical number of service orders for the same destination as the service intent that is greater than a threshold number over a period of time (e.g., the past month), indicating that the service requestor is frequently traveling to the destination, the probability that the service intent will translate into a service order is relatively high (e.g., 60%, 70%, 80%, 90%) even without an offer, and offer determination module 450 may determine an initial offer with a relatively low value (e.g., a $ 1 cash coupon) for the service intent.

Offer determination module 450 may determine whether at least one initial offer for at least one of the one or more service intents satisfies a condition. In response to a determination that the at least one initial offer satisfies the condition, offer determination module 450 may determine the at least one initial offer as at least one offer for transmission to requestor terminal 130, the requestor terminal 130 associated with at least one service requestor in one or more service intents. In response to a determination that the at least one initial offer does not satisfy the condition, offer determination module 450 may re-determine the initial offer for the at least one of the one or more service intents.

For example, offer determination module 450 may determine whether the number of service intents that would be converted to a service order due to the initial offer is greater than a first threshold among the one or more service intents. In response to a determination that the number of service intents because the initial offer translates into a service order is greater than a first threshold, offer determination module 450 may determine at least one initial offer as at least one offer for transmission to requestor terminal 130, the requestor terminal 130 associated with at least one service requestor of the one or more service intents. In response to a determination that the number of service intents for which the initial offer translates into a service order is less than or equal to the first threshold, offer determination module 450 may re-determine the initial offer for at least one of the one or more service intents.

For another example, offer determination module 450 may determine whether a number of service intents, of the one or more service intents, that may translate into a service order because of the initial offer is less than a second threshold (also referred to as a count threshold) (e.g., as described in detail herein in connection with fig. 7). In response to a determination that the number of service intents because the initial offer translates into a service order is less than the second threshold, offer determination module 450 may determine at least one initial offer as at least one offer for transmission to requestor terminal 130, the requestor terminal 130 associated with at least one service requestor of the one or more service intents. In response to a determination that the number of service intents for which the initial offer is converted into the service order is greater than or equal to the second threshold, offer determination module 450 may re-determine the initial offer for at least one of the one or more service intents.

Alternatively or additionally, offer determination module 450 may determine whether a sum of values of at least one initial offer is less than a value threshold (e.g., as described in detail herein in connection with fig. 8). In response to a determination that the sum of values is less than the value threshold, offer determination module 450 may determine at least one initial offer as at least one offer for transmission to requestor terminal 130, the requestor terminal 130 associated with at least one service requestor in one or more service intents. In response to a determination that the sum of values is greater than or equal to the value threshold, offer determination module 450 may re-determine an initial offer for at least one of the one or more service intents.

The transmission module 460 may be configured to transmit the at least one offer to at least one requesting terminal (e.g., the requesting terminal 130) from which at least one of the one or more service intents originated. In some embodiments, the transmission module 460 may transmit the offer to the requestor terminal 130 via the network 120. The received offer may be displayed on an interface of an application installed in the requester terminal 130. For example, the discounted price may be displayed along with the original price, which may stimulate the service requester to translate the service intent into a service order.

The modules in the processing engine 112 may be connected or in communication with each other by wired or wireless connections. The wired connection may include a metal cable, an optical cable, a hybrid cable, etc., or any combination thereof. The wireless connection may include a Local Area Network (LAN), a Wide Area Network (WAN), bluetooth, ZigBee network, Near Field Communication (NFC), etc., or any combination of the above. Two or more modules may be combined into one module and any one module may be split into two or more units. For example, the provider information acquisition module 420 may be integrated in the area information determination module 430 as a single module that can determine both the average idle period and whether the target area is a non-busy area.

It should be noted that the foregoing is provided for illustrative purposes only and is not intended to limit the scope of the present application. Many variations and modifications may be made to the teachings of the present application by those of ordinary skill in the art in light of the present disclosure. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the protection scope of the present application and in some embodiments, the processing engine 112 may further include a memory module (not shown in fig. 2). The storage module may be configured to store data generated by any component in the processing engine 112 during any processing performed. As another example, each component of processing engine 112 may include a storage device. Additionally or alternatively, the components of the processing engine 112 may share a common memory device.

Fig. 5 is a flow diagram of an exemplary flow of capacity scheduling, shown in accordance with some embodiments of the present application. The flow 500 may be implemented in the online-to-offline service system 100 shown in fig. 1. For example, flow 500 may be stored as instructions (e.g., an application program) in storage device 150 and/or memory 220 and invoked and/or executed by server 110 (e.g., processing engine 112 of server 110, processor 210 shown in fig. 2, or one or more modules in processing engine 112 shown in fig. 4). The operations of the flow/method described below are merely exemplary. In some embodiments, flow 500 may be implemented with one or more additional operations not described, and/or with one or more operations described herein being omitted. Further, the order in which the operations in flow 500 are illustrated in FIG. 5 and described below is not intended to be limiting.

In 510, the region acquisition module 410 (or the processing engine 112, and/or the interface circuitry 210-a) may acquire a target region. In some embodiments, processing engine 112 may divide a region (e.g., Beijing) into a plurality of sub-regions. In some embodiments, the area may be divided into a plurality of sub-areas according to geographical conditions. For example, a region may be divided into two sub-regions by a river. In some embodiments, the region may be divided into a plurality of sub-regions according to a management boundary. For example, Beijing may be classified as an east region, a west region, a sunny region, a Hai lake region, and the like. In some embodiments, a region may be divided into multiple geometrically shaped sub-regions. The geometry of the sub-regions may be regular or irregular. Regular geometric shapes may include triangles, squares, rectangles, pentagons, octagons, circles, hexagons, etc., or any combination thereof. In some embodiments, the multiple sub-regions may be the same or different. For example, each of the plurality of sub-regions may be hexagonal in shape having a side length of 300, 500, 700, 1000, 1500 meters, or the like. As another example, one of the plurality of sub-regions may be a hexagon having a side of 300 meters, and another of the plurality of sub-regions may be a hexagon having a side of 500 meters. For another example, one of the plurality of sub-regions may be hexagonal and another of the plurality of sub-regions may be square.

In 520, the provider information acquisition module 420 (or the processing engine 112, and/or the processing circuitry 210-b) may acquire information associated with the service provider in the target area (e.g., for more detailed description, refer to the description of fig. 6 in this application). In some embodiments, the information associated with the service provider in the target area may include an average idle period for the service provider associated with the target area.

In 530, the area information determination module 430 (or the processing engine 112, and/or the processing circuitry 210-b) may determine whether the target area is a busy area or a non-busy area based on information associated with the service provider in the target area.

A busy region may indicate that the number of service orders initiated in the target region (e.g., the start of a service order in the target region) is relatively large for a certain period of time. The less busy region may indicate that the number of service orders initiated in the target region is relatively small for a certain period of time. In some embodiments, in response to determining that the target area is a non-busy area, the processing engine 112 may adjust the transportation capacity of the non-busy area (e.g., increase the number of service orders placed in the non-busy area) by performing 540 along with 560.

At 540, the intent acquisition module 440 (or the processing engine 112, and/or the processing circuitry 210-b) may acquire one or more service intents from one or more requestor terminals (e.g., the requestor terminal 130) via a network (e.g., the network 120). Each of the one or more service intents may represent an interest in requesting a transport service. The origin (e.g., expected departure location) of each of the plurality of intents may be in the target area.

In 550, offer determination module 450 (or processing engine 112, and/or processing circuitry 210-b) may determine an offer for at least one of the one or more service intents. The offer may be used as an incentive for the service requestor to translate the intent of the service into a service order. In some embodiments, the offer may include a discount on the cost of a service order, a red envelope, a discount coupon, a cash coupon, a credit, a cash refund, or the like, or any combination thereof. In some embodiments, the greater the value of the offer, the more likely the service requestor receiving the offer will translate the service intent into a service order.

At 560, the transmission module 460 (or the processing engine 112, and/or the processing circuitry 210-b) may transmit the at least one offer to at least one requesting terminal (e.g., the requesting terminal 130) from which at least one of the one or more service intents originated. In some embodiments, the transmission module 460 may transmit the offer to the requestor terminal 130 via the network 120. The received offer may be displayed on an interface of an application installed in the requester terminal 130. For example, the discounted price may be displayed along with the original price, which may stimulate the service requester to translate the service intent into a service order.

In some embodiments, the processing engine 112 may perform the flow 500 periodically. For example, processing engine 112 may execute process 500 every two hours.

It should be noted that the foregoing is provided for illustrative purposes only and is not intended to limit the scope of the present application. Many variations and modifications may be made to the teachings of the present application by those of ordinary skill in the art in light of the present disclosure. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the present application, for example, when a specific preference is determined, step 520 and step 530 may be omitted regardless of whether the target area is a busy area or a non-busy area.

Fig. 6 is an exemplary flow diagram for determining an average idle period, shown in accordance with some embodiments of the present application. The flow 600 may be implemented in the online-to-offline service system 100 shown in fig. 1. For example, flow 600 may be stored as instructions (e.g., an application program) in storage device 150 and/or memory 220 and invoked and/or executed by server 110 (e.g., processing engine 112 of server 110, processor 210 shown in fig. 2, or one or more modules in processing engine 112 shown in fig. 4). The operations of the flow/method described below are merely exemplary. In some embodiments, flow 600 may be implemented with one or more additional operations not described, and/or with one or more operations described herein being omitted. Further, the order in which the operations are performed in flow 600 shown in FIG. 6 and described below is not intended to be limiting. In some embodiments, step 520 of flow 500 may be performed based on flow 600.

In 610, the provider information acquisition module 420 (or the processing engine 112, and/or the processing circuitry 210-b) may select one or more service order sets associated with the target area. In some embodiments, each of the one or more service order sets may include two service orders. One of the two service orders (also referred to as the first service order in this example) may be completed by the service provider at a certain point in time (also referred to as the first point in time in this example). The service provider may accept the other of the two service orders (also referred to as the second service order in this example) that originates in the target area at another point in time (also referred to as the second point in time in this example) following the first service order.

In some embodiments, the first and second points in time may be within a time period between a current time (e.g., a point in time at which the region acquisition module 410 acquires the target region) and a point in time prior to the current time. For example, if the area acquisition module 410 acquires the target area at 10:00 am on monday, the first and second points in time may be between the 9 am to 10 am periods of monday for each of the one or more idle periods used to determine the average idle period. For another example, if the area acquisition module 410 acquires the target area at 10:00 am on monday, the first and second points in time may be between the 9 am to 10 am periods of the last month for each of the one or more idle periods used to determine the average idle period.

At 620, the provider information acquisition module 420 (or the processing engine 112, and/or the processing circuitry 210-b) may acquire an idle period for each of the one or more service order sets. In some embodiments, for a set of service orders, the time period between a first point in time (e.g., the point in time at which the service provider completes a first service order) and a second point in time (e.g., the point in time at which the service provider follows the first service order, followed by acceptance of a second service order originating in the target area) may be referred to as an idle period for the service provider corresponding to the set of service orders.

In 630, the provider information acquisition module 420 (or the processing engine 112, and/or the processing circuitry 210-b) may determine an average idle period for the target area based on the one or more idle periods for the service order set and the number of the one or more service order sets. In some embodiments, the provider information acquisition module 420 may determine the average idle period for the target area by dividing the sum of the one or more idle periods for the one or more service order sets by the number of the one or more service order sets.

FIG. 7 is an exemplary flow diagram for determining offers, shown in accordance with some embodiments of the present application. The process 700 may be implemented in the online-to-offline service system 100 shown in fig. 1. For example, flow 700 may be stored as instructions (e.g., an application program) in storage device 150 and/or memory 220 and invoked and/or executed by server 110 (e.g., processing engine 112 of server 110, processor 210 shown in fig. 2, or one or more modules in processing engine 112 shown in fig. 4). The operations of the flow/method described below are merely exemplary. In some embodiments, flow 700, when implemented, may add one or more additional operations not described, and/or delete one or more of the operations described herein. Further, the order in which the operations in flow 700 are illustrated in FIG. 7 and described below is not intended to be limiting. In some embodiments, step 550 in flow 500 may be performed based on flow 700.

In 710, offer determination module 450 (or processing engine 112, and/or processing circuitry 210-b) may determine an initial offer for at least one of the one or more service intents. For each of the one or more service intents, offer determination module 450 may determine whether to determine an initial offer for the service intent and/or which initial offer to determine for the service intent.

In some embodiments, offer determination module 450 may determine an initial offer for an intent of service based on a destination for the intent of service. For example, when the destination of the service intent is located in a busy area (e.g., Beijing monozone), indicating that the probability that the service intent translates into a service order is relatively large (e.g., 60%, 70%, 80%, 90%) even without an offer, offer determination module 450 may determine an initial offer for the service intent that has a relatively small value (e.g., a $ 1 cash coupon) or not determine an initial offer for the service intent. When the destination of the service intent is located in a remote area (e.g., Yanqing district, Beijing), the likelihood that the service intent will be converted into a service order is relatively small if there is no offer, and offer determination module 450 may determine an initial offer for the service intent that has a relatively large value (e.g., a $ 5 cash coupon).

In 720, offer determination module 450 (or processing engine 112, and/or processing circuitry 210-b) may estimate, among the one or more service intents, a number of service intents that will be converted into a service order based on the at least one initial offer.

In some embodiments, for each of the one or more service intents, offer determination module 450 may determine a probability that the service intent will be converted into a service order. Offer determination module 450 may determine whether the probability is greater than a probability threshold (e.g., 40%, 50%, 60%). In response to a determination that the probability is greater than the probability threshold, offer determination module 450 may determine that the intent to service will be converted into a service order. In response to a determination that the probability is less than or equal to the probability threshold, offer determination module 450 may determine that the intent to service is not to be converted into a service order.

In some embodiments, for service intents for which no initial offer is assigned, offer determination module 450 may determine a probability that the service intent will be converted into a service order based on, for example, the origin of the service intent, the destination of the service intent, and/or historical service orders of service requesters corresponding to the service intent. In some embodiments, for a service intent corresponding to the initial offer, offer determination module 450 may determine a probability that the service intent will be converted into a service order based on the initial offer, a starting point of the service intent, a destination of the service intent, and/or historical service orders of service requesters corresponding to the service intent, among other things.

In some embodiments, for a service intent corresponding to an initial offer, offer determination module 450 may determine a probability that the service intent will be converted into a service order based on the same historical service intent as the service intent. The historical service intent that is the same as the service intent may have the same origin, destination, and initial offer as the service intent. For example, if 8 of 10 historical service intents that are the same as the service intention would be converted into a service order, the probability that the service intention is converted into a service order may be determined to be 80% according to the initial offer.

In 730, offer determination module 450 (or processing engine 112, and/or processing circuitry 210-b) may determine whether the number of service intents to be converted into a service order is less than a count threshold. In some embodiments, the count threshold may be equal to the sum of a count of service providers located in the target area that are not providing service and a count of service providers that are providing service whose destination is located in the target area and within a distance threshold (e.g., 1 kilometer) from the destination.

In some embodiments, if the number of service intents to be converted into a service order is less than the count threshold, then the process 700 may proceed to 740. If the count of service intents to be converted into a service order is greater than or equal to the count threshold, the process 700 may proceed to 710 to re-determine an initial offer for at least one of the one or more service intents.

In 740, offer determination module 450 (or processing engine 112, and/or processing circuitry 210-b) may determine the at least one initial offer as at least one offer for transmission to at least one requestor terminal from which at least one of the one or more service intents came.

FIG. 8 is an exemplary flow diagram for determining offers, shown in accordance with some embodiments of the present application. The process 800 may be implemented in the online-to-offline service system 100 shown in fig. 1. For example, flow 800 may be stored as instructions (e.g., an application program) in storage device 150 and/or memory 220 and invoked and/or executed by server 110 (e.g., processing engine 112 of server 110, processor 210 shown in fig. 2, or one or more modules in processing engine 112 shown in fig. 4). The operations of the flow/method described below are merely exemplary. In some embodiments, flow 800 may be implemented with one or more additional operations not described, and/or with one or more operations described herein. Further, the order in which the operations in flow 800 are illustrated in FIG. 7 and described below is not limiting. In some embodiments, step 550 in flow 500 may be performed based on flow 800.

In 810, offer determination module 450 (or processing engine 112, and/or processing circuitry 210-b) may determine an initial offer for at least one of the one or more service intents. In some embodiments, the process for determining an initial offer for at least one of the one or more service intents may be the same as the corresponding description in 550 of process 500 and/or 710 of process 700.

In 820, offer determination module 450 (or processing engine 112, and/or processing circuitry 210-b) may determine a sum of values of at least one initial offer. For example, the at least one initial offer may include one $ 1 cash coupon and two $ 5 cash coupons. The sum of the values of the at least one initial offer may equal $ 11.

At 830, offer determination module 450 (or processing engine 112, and/or processing circuitry 210-b) may determine whether the sum of values is less than or equal to a value threshold. In some embodiments, a value threshold may be set to ensure that at least one initial offer does not result in a loss of corporate interest to the online-to-offline service system 100.

In some embodiments, if the sum of values is less than the value threshold, flow 800 may proceed to 840. If the sum of values is greater than or equal to the value threshold, process 800 may proceed to 810 to redetermine the initial offer for at least one of the one or more service intents.

In 840, offer determination module 450 (or processing engine 112, and/or processing circuitry 210-b) may determine the at least one initial offer as at least one offer for transmission to at least one requestor terminal from which at least one of the one or more service intents came.

Having thus described the basic concept, it will be apparent to those skilled in the art that the foregoing disclosure is by way of example only, and is not intended to limit the present application. Various modifications, improvements and adaptations to the present application may occur to those skilled in the art, although not explicitly described herein. Such modifications, improvements and adaptations are proposed in the present application and thus fall within the spirit and scope of the exemplary embodiments of the present application.

Also, this application uses specific language to describe embodiments of the application. Reference throughout this specification to "one embodiment," "an embodiment," and/or "some embodiments" means that a particular feature, structure, or characteristic described in connection with at least one embodiment of the present application is included in at least one embodiment of the present application. Therefore, it is emphasized and should be appreciated that two or more references to "an embodiment" or "one embodiment" or "an alternative embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, some features, structures, or characteristics of one or more embodiments of the present application may be combined as appropriate.

Moreover, those skilled in the art will appreciate that aspects of the present application may be illustrated and described in terms of several patentable species or situations, including any new and useful combination of processes, machines, manufacture, or materials, or any new and useful improvement thereon. Accordingly, various aspects of the present application may be embodied entirely in hardware, entirely in software (including firmware, resident software, micro-code, etc.) or in a combination of hardware and software. The above hardware or software may be referred to as "data block," module, "" engine, "" unit, "" component, "or" system. Furthermore, aspects of the present application may be represented as a computer product, including computer readable program code, embodied in one or more computer readable media.

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

Computer program code required for operation of various portions of the present application may be written in any one or more programming languages, including an object oriented programming language such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C + +, C #, VB.NET, Python, and the like, a conventional programming language such as C, Visual Basic, Fortran 2003, Perl, COBOL 2002, PHP, ABAP, a dynamic programming language such as Python, Ruby, and Groovy, or other programming languages, and the like. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any network format, such as a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet), or in a cloud computing environment, or as a service, such as a software as a service (SaaS).

Additionally, the order in which elements and sequences of the present application are processed, the use of numerical letters, or the use of other names in the present application is not intended to limit the order in which the processes and methods of the present application may be performed, unless explicitly stated in the claims. While various presently contemplated embodiments of the invention have been discussed in the foregoing disclosure by way of example, it is to be understood that such detail is solely for that purpose and that the appended claims are not limited to the disclosed embodiments, but, on the contrary, are intended to cover all modifications and equivalent arrangements that are within the spirit and scope of the embodiments herein. For example, although the system components described above may be implemented by hardware devices, they may also be implemented by software-only solutions, such as installing the described system on an existing server or mobile device.

Similarly, it should be noted that in the preceding description of embodiments of the application, various features are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the embodiments. This method of disclosure, however, is not intended to require more features than are expressly recited in the claims. Indeed, the embodiments may be characterized as having less than all of the features of a single embodiment disclosed above.

Numerals describing the number of components, attributes, etc. are used in some embodiments, it being understood that such numerals used in the description of the embodiments are modified in some instances by the use of the modifier "about", "approximately" or "substantially", etc. Unless otherwise indicated, "about", "approximately" or "substantially" indicates that the number allows a variation of ± 20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximations that may vary depending upon the desired properties of the individual embodiments. In some embodiments, the numerical parameter should take into account the specified significant digits and employ a general digit preserving approach. Notwithstanding that the numerical ranges and parameters setting forth the broad scope of the range are approximations, in the specific examples, such numerical values are set forth as precisely as possible within the scope of the application.

Each patent, patent application, publication of a patent application, and other material, such as articles, books, descriptions, publications, documents, things, etc., in the referenced document is hereby incorporated by reference in its entirety for all purposes, except for any prosecution history associated therewith, and any equivalent document that is inconsistent with or conflicts with this document or that may have a limiting effect on the broadest scope of claims now or later relating thereto. For example, if there is any inconsistency or conflict between the description, definition, and/or use of a term associated with any of the combined materials and a term associated with the present document, the terms described, defined, and/or used in this document shall prevail.

Finally, it should be understood that the embodiments described herein are merely illustrative of the principles of the embodiments of the present application. Other variations are also possible within the scope of the present application. Thus, by way of example, and not limitation, alternative configurations of the embodiments of the present application can be viewed as being consistent with the teachings of the present application. Accordingly, the embodiments of the present application are not limited to only those embodiments explicitly described and depicted herein.

Claims

1. A capacity scheduling system, comprising:

a storage device for storing a set of instructions; and

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

acquiring a target area;

obtaining information associated with a service provider in the target area;

determining whether the target area is a busy area or a non-busy area based on information associated with the service provider in the target area;

acquiring one or more service intents from one or more requester terminals via a network in response to a determination that the target area is a non-busy area, each of the one or more service intents indicating an interest in initiating a service request having an origin located in the target area;

determining an offer for at least one of the one or more service intents; and

transmitting the at least one offer to at least one requestor terminal via the network, at least one of the one or more service intents from the at least one requestor terminal.

2. The capacity scheduling system of claim 1, wherein the information associated with the service provider in the target area comprises an average idle period.

3. The capacity scheduling system of claim 2, wherein the average idle period is determined according to:

selecting one or more service order sets associated with the target area;

obtaining an idle period for each of the one or more service order sets; and

determining an average idle period based on the one or more idle periods of the one or more serving order sets and the number of the one or more serving order sets.

4. The capacity scheduling system of claim 3, wherein each of the one or more groups of service orders comprises two service orders, a first of the two service orders completed by the service provider at a first point in time, a second of the two service orders accepted by the service provider at a second point in time subsequent to the first service order, a start of the second service order located in the target area, the idle period for each of the one or more groups of service orders being from the first point in time to the second point in time.

5. The capacity scheduling system of any one of claims 2 to 4, wherein to determine whether the target area is a busy area or a non-busy area based on information associated with a service provider in the target area, the at least one processor is configured to:

judging whether the average idle time period is greater than a time threshold value;

determining that the target area is a busy area in response to a determination that the average idle period is less than or equal to the time threshold; and

in response to the average idle period being greater than the time threshold, determining that the target region is a non-busy region.

6. The capacity scheduling system according to any one of claims 1 to 5, wherein to determine the offer for at least one of the one or more service intents, the at least one processor is configured to:

determining an initial offer for the at least one of the one or more service intents;

estimating a service intent count of the one or more service intents to be converted into a service order based on the initial offer;

determining whether the count of service intents to be converted into a service order is less than a count threshold; and

determining the initial offer of at least one of the one or more service intents as the offer of at least one of the one or more service intents in response to a determination that the count of service intents to be converted into a service order is less than the count threshold.

7. The capacity scheduling system of claim 6, wherein to estimate a service intent count of the one or more service intents to be converted into a service order based on the initial offer, the at least one processor is configured to:

for each of the one or more service intents,

determining a probability that the service intent will be converted into a service order based on the initial offer;

judging whether the probability is greater than a probability threshold value; and

determining that the service intent is to be converted into a service order in response to a determination that the probability is greater than the probability threshold.

8. A capacity scheduling system according to any of claims 6 to 7 wherein the count threshold is equal to the sum of the count of service providers located in the target area that are not providing service and the count of service providers whose destination is located in the target area and whose distance from the destination is within a distance threshold.

9. The capacity scheduling system according to any one of claims 1 to 5, wherein to determine an offer for at least one of the one or more service intents, the at least one processor is configured to:

determining a sum of values of the at least one initial offer;

determining whether the sum of values is less than or equal to a value threshold; and

in response to the sum of values being less than or equal to the value threshold, determining the initial offer of the at least one of the one or more service intents as the offer of the at least one of the one or more service intents.

10. The capacity scheduling system of any one of claims 1 to 9, wherein the offer comprises a price discount for the service for at least one of the one or more service intents.

11. A capacity scheduling method implemented on a computing device comprising at least one processor and at least one storage device, the method comprising:

acquiring a target area;

obtaining information associated with a service provider in the target area;

determining an offer for at least one of the one or more service intents; and

12. The capacity scheduling method of claim 11, wherein the information associated with the service provider in the target area comprises an average idle period.

13. The capacity scheduling method of claim 12, wherein the average idle period is determined according to the following operations:

selecting one or more service order sets associated with the target area;

obtaining an idle period for each of the one or more service order sets; and

14. The capacity scheduling method of claim 13, wherein each of the one or more groups of service orders comprises two service orders, a first of the two service orders being completed by the service provider at a first point in time, a second of the two service orders being accepted by the service provider at a second point in time subsequent to the first service order, a start of the second service order being located in the target area, the idle period for each of the one or more groups of service orders being from the first point in time to the second point in time.

15. The capacity scheduling method of any of claims 12 to 14, wherein said determining whether the target area is a busy area or a non-busy area based on information associated with a service provider in the target area comprises:

16. The capacity scheduling method according to any one of claims 11 to 15, wherein the determining the offer for at least one of the one or more service intents comprises:

17. The capacity scheduling method of claim 16, wherein estimating a service interest count of the one or more service interests to be converted into a service order based on the initial offer comprises:

for each of the one or more service intents,

18. The capacity scheduling method according to any one of claims 16 to 17, wherein the count threshold is equal to the sum of a count of service providers located in the target area and not providing services and a count of service providers having an endpoint located in the target area and within a distance threshold from the endpoint being provided.

19. The capacity scheduling method according to any one of claims 11 to 15, wherein the determining an offer for at least one of the one or more service intents comprises:

determining a sum of values of the at least one initial offer;

20. The capacity scheduling method according to any one of claims 11 to 19, wherein the offer comprises a price discount for the service for at least one of the one or more service intents.

21. A capacity scheduling system, comprising:

the region acquisition module is used for acquiring a target region;

a provider information acquisition module for acquiring information associated with a service provider in the target area;

a region information determination module to determine whether the target region is a busy region or a non-busy region based on information associated with the service provider in the target region;

an intention acquisition module, configured to acquire, via a network, one or more service intents from one or more requester terminals in response to a determination that the target area is a non-busy area, each of the one or more service intents indicating an interest in initiating a service request having a start point located in the target area;

the preference determining module is used for determining a preference for at least one service intention in the one or more service intentions; and

a transmission module to transmit the at least one offer to at least one requestor terminal via the network, at least one of the one or more service intents from the at least one requestor terminal.

22. The capacity scheduling system of claim 21, wherein the information associated with the service provider in the target area comprises an average idle period.

23. The capacity scheduling system of claim 22, wherein the average idle period is determined according to:

selecting one or more service order sets associated with the target area;

obtaining an idle period for each of the one or more service order sets; and

24. The capacity scheduling system of claim 23, wherein each of the one or more groups of service orders comprises two service orders, a first of the two service orders being completed by the service provider at a first point in time, a second of the two service orders being accepted by the service provider at a second point in time subsequent to the first service order, a start of the second service order being located in the target area, the idle period for each of the one or more groups of service orders being from the first point in time to the second point in time.

25. The capacity scheduling system of any one of claims 22 to 24, wherein said determining whether the target area is a busy area or a non-busy area based on information associated with a service provider in the target area comprises:

26. The capacity scheduling system according to any of claims 21-25, wherein the determining the offer for at least one of the one or more service intents comprises:

27. The capacity scheduling system of claim 26, wherein estimating a service interest count of the one or more service interests to be converted into a service order based on the initial offer comprises:

for each of the one or more service intents,

28. The capacity scheduling system of any one of claims 26 to 27 wherein the count threshold is equal to the sum of the count of service providers located in the target area that are not providing service and the count of service providers whose destination is located in the target area and whose distance from the destination is within a distance threshold.

29. The capacity scheduling system according to any of claims 21 to 25, wherein the determining an offer for at least one of the one or more service intents comprises:

determining a sum of values of the at least one initial offer;

30. The capacity scheduling system of any of claims 21 to 29 wherein the offer comprises a price discount for the service for at least one of the one or more service intents.

31. A computer-readable medium comprising at least one set of instructions for capacity scheduling, which when executed by one or more processors of a computing device, causes the one or more processors to perform a method, the method comprising:

acquiring a target area;

obtaining information associated with a service provider in the target area;

determining an offer for at least one of the one or more service intents; and