WO2020113626A1

WO2020113626A1 - Systems and methods for determining estimated time of arrival

Info

Publication number: WO2020113626A1
Application number: PCT/CN2018/120448
Authority: WO
Inventors: Kun Fu; Zheng Wang
Original assignee: Beijing Didi Infinity Technology And Development Co., Ltd.
Priority date: 2018-12-03
Filing date: 2018-12-12
Publication date: 2020-06-11
Also published as: CN110782648B; CN110782648A

Abstract

Disclosed are systems and methods for determining an estimated time of arrival (ETA). The systems may perform the methods to receive, via a network, a service request from a requestor terminal associated with a service requestor (410); obtain a pick-up location, a destination and request-related information from the service request (420); determine at least one request-related feature vector based on the request-related information (430); determine at least one link-related feature vector by searching a pre-generated link table stored in a database based on the pick-up location and the destination (440); and determine the ETA based on the at least one request-related feature vector and the at least one link-related feature vector (450).

Description

SYSTEMS AND METHODS FOR DETERMINING ESTIMATED TIME OF ARRIVAL

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to Chinese Application No. 201811468237.7 filed on December 3, 2018, the contents of which are incorporated herein by reference in their entirety.

TECHNICAL FIELD

The present disclosure generally relates to systems and methods for online to offline service, and in particular, to systems and methods for determining an estimated time of arrival (ETA) .

BACKGROUND

Online to offline services (e.g., a taxi hailing service, food delivery service) utilizing Internet technology have become increasingly popular because of their convenience. When a service request initiated by a requestor is received, a system has to promptly provide information in response to the service request before the actual online to offline service is provided to the service requestor. For example, the system may determine at least one travel route with associated ETA between a pick-up location and a destination designated by the requestor, and display the at least one travel route with the associated ETA on a terminal of the requestor and/or the provider. However, existing technology may repeatedly compute the ETA based on factors that rarely change with time, causing a slow response speed to the requestor. Therefore, it is desirable to provide systems and methods for determining an ETA more efficiently.

SUMMARY

According to an aspect of the present disclosure, a system for determining an estimated time of arrival (ETA) is provided. The system may include at least one storage device including a set of instructions, a data exchange port communicatively connected to a network, and at least one processor in communication with the at least one storage device. When the at least one processor executes the set of instructions, the at least one processor may be configured to cause the system to perform one or more of the following operations. The at least one processor may receive, via the network, a service request from a requestor terminal associated with a service requestor. The at least one processor may obtain a pick-up location, a destination and request-related information from the service request. The at least one processor may determine at least one request-related feature vector based on the request-related information. The at least one processor may determine at least one link-related feature vector by searching a pre-generated link table stored in a database based on the pick-up location and the destination. The at least one processor may further determine the ETA based on the at least one request-related feature vector and the at least one link-related feature vector.

In some embodiments, the request-related information may further include at least one of time information, weather information, or a type of the service request.

In some embodiments, the request-related information may include at least one of: personal information of the service requestor; preference settings of the service requestor; or travel habit of the service requestor.

In some embodiments, the request-related information may include at least one of: personal information of a service provider; vehicle information of the service provider; or driving habit of the service provider.

In some embodiments, wherein to determine at least one link-related feature vector by searching a pre-generated link table stored in a database based on the pick-up location and the destination, the at least one processor may be configured to cause the system further to: determine a target route from the pick- up location to the destination location; determine a link sequence based on the target route, wherein the link sequence includes at least one link; and retrieve the link-related feature vector for each of the at least one link by searching the pre-generated link table stored in the database.

In some embodiments, the link table may include a plurality of feature vectors pre-generated with respect to a plurality of links corresponding to roads of an area, and be periodically updated by an Artificial Neural Network model.

In some embodiments, wherein to determine the ETA based on the at least one request-specific feature vector and the at least one link-related feature vector, the at least one processor may be configured to cause the system further to: determine the ETA by designating the at least one request-related feature vector and the at least one link-related feature vector as an input of an ETA determination model.

In some embodiments, the ETA determination model may be an Artificial Neural Network model.

In some embodiments, the ETA determination model may be trained by a process comprising: obtaining information related to a set of historical service requests, wherein the information related to the set of historical service requests includes sample link-related feature vectors, sample request-related feature vectors, and sample ETAs associated with the sample link-related feature vectors and the sample request-related feature vectors, respectively; determining a predicted ETA with respect to each of the set of historical service requests by designating a corresponding sample link-related feature vector and a corresponding sample request-related feature vector as an input of the ETA determination model; and iteratively training the ETA determination model by minimizing a difference between a corresponding sample ETA and the predicted ETA with respect to each of the set of historical service requests.

In some embodiments, the at least one processor may be configured to cause the system further to: transmit, via the network, the ETA to the requestor terminal associated with the service requestor.

According to another aspect of the present disclosure, a method for determining an ETA is provided. The method may be implemented on a computing device having at least one processor, at least one storage device, and a data exchange port communicatively connected to a network. The method may include one or more of the following operations. The method may include receiving, via the network, a service request from a requestor terminal associated with a service requestor. The method may include obtaining a pick-up location, a destination and request-related information from the service request. The method may include determining at least one request-related feature vector based on the request-related information. The method may also include determining at least one link-related feature vector by searching a pre-generated link table stored in a database based on the pick-up location and the destination. The method may further include determining the ETA based on the at least one request-related feature vector and the at least one link-related feature vector.

In some embodiments, the request-related information may further include at least one of time information, weather information or a type of the service request.

In some embodiments, the request-related information may include at least one of: personal information of a service provider, vehicle information of the service provider; or driving habit of the service provider.

In some embodiments, wherein determining the at least one link-related feature vector by searching the pre-generated link table stored in the database based on the pick-up location and the destination may comprise: determining a target route from the pick-up location to the destination location; determining a link sequence based on the target route, wherein the link sequence includes at least one link; and retrieving the link-related feature vector for each of the at least one link by searching the pre-generated link table stored in the database.

In some embodiments, wherein determining the ETA based on the at least one request-specific feature vector and the at least one link-related feature vector may comprise: determining the ETA by designating the at least one request-related feature vector and the at least one link-related feature vector as an input of an ETA determination model.

In some embodiments, the method may further include: transmitting, via the network, the ETA to the requestor terminal associated with the service requestor.

According to yet another aspect of the present disclosure, a non-transitory computer-readable storage medium is provided. The non-transitory computer-readable storage medium may include a set of instructions for determining an ETA. When the set of instructions is executed by at least one processor, the set of instructions may be configured to cause the system to perform one or more of the following operations. The at least one processor may receive, via the network, a service request from a requestor terminal associated with a service requestor. The at least one processor may obtain a pick-up location, a destination and request-related information from the service request. The at least one processor may determine at least one request-related feature vector based on the request-related information. The at least one processor may determine at least one link-related feature vector by searching a pre-generated link table stored in a database based on the pick-up location and the destination. The at least one processor may further determine the ETA based on the at least one request-related feature vector and the at least one link-related feature vector.

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

BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

FIG. 4A is a flowchart illustrating an exemplary process for determining an estimated time of arrival (ETA) according to some embodiments of the present disclosure;

FIG. 4B is a schematic diagram illustrating an exemplary format of an electronic signal encoding a service request according to some embodiments of the present disclosure;

FIG. 5 is a block diagram illustrating an exemplary training module according to some embodiments of the present disclosure;

FIG. 6 is a flowchart illustrating an exemplary process for training an ETA determination model according to some embodiments of the present disclosure;

FIG. 7 is a block diagram illustrating an exemplary link-related feature vector determination module according to some embodiments of the present disclosure;

FIG. 8 is a flowchart illustrating an exemplary process for determining a link-related feature vector according to some embodiments of the present disclosure;

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

FIG. 9B is a schematic diagram illustrating an exemplary user interface presenting an ETA related to a service request according to some embodiments of the present disclosure;

FIG. 9C is a schematic diagram illustrating an exemplary user interface presenting an ETA related to a service request according to some embodiments of the present disclosure; and

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

DETAILED DESCRIPTION

The following description is presented to enable any person skilled in the art to make and use the present disclosure, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present disclosure. Thus, the present disclosure is not limited to the embodiments shown, but is to be accorded the widest scope consistent with the claims.

The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. As used herein, the singular forms “a, ” “an, ” and “the” may be intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprise, ” “comprises, ” and/or “comprising, ” “include, ” “includes, ” and/or “including, ” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

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

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

Moreover, while the system and method in the present disclosure is described primarily regarding an online to offline service, it should also be understood that this is only one exemplary embodiment. The system or method of the present disclosure may be applied to any other kind of on demand service. For example, the system or method of the present disclosure may be applied to transportation systems of different environments including land, ocean, aerospace, or the like, or any combination thereof. The vehicle of the transportation systems may include a taxi, a private car, a hitch, a bus, a train, a bullet train, a high-speed rail, a subway, a vessel, an aircraft, a spaceship, a hot- air balloon, a driverless vehicle, or the like, or any combination thereof. The transportation system may also include any transportation system for management and/or distribution, for example, a system for sending and/or receiving an express. The application of the system or method of the present disclosure may include a web page, a plug-in of a browser, a client terminal, a custom system, an internal analysis system, an artificial intelligence robot, or the like, or any combination thereof.

The term “passenger, ” “requestor, ” “service requestor, ” and “customer” in the present disclosure are used interchangeably to refer to an individual, an entity or a tool that may request or order a service. Also, the term “driver, ” “provider, ” “service provider, ” and “supplier” in the present disclosure are used interchangeably to refer to an individual, an entity or a tool that may provide a service or facilitate the providing of the service. The term “user” in the present disclosure may refer to an individual, an entity or a tool that may request a service, order a service, provide a service, or facilitate the providing of the service. For example, the user may be a passenger, a driver, an operator, or the like, or any combination thereof. In the present disclosure, “passenger” and “passenger terminal” may be used interchangeably, and “driver” and “driver terminal” may be used interchangeably.

The term “service request” and “order” in the present disclosure are used interchangeably to refer to a request that may be initiated by a passenger, a requestor, a service requestor, a customer, a driver, a provider, a service provider, a supplier, or the like, or any combination thereof. The service request may be accepted by any one 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 chargeable or free.

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

An aspect of the present disclosure relates to systems and methods for determining an estimated time of arrival (ETA) based on a pick-up location, a destination and request-related information obtained from a service request. The ETA may refer to an estimated time period for driving from the pick-up location of the service request or a current location of a service requestor and/or a service provider to the destination of the service request. According to the present disclosure, when the systems receive a service request for a transportation service and obtain the pick-up location, the destination and the request-related information from the service request, the systems may determine at least one request-related feature vector based on the request-related information and determine at least one link-related feature vector by searching a pre-generated link table stored in a database based on the pick-up location and the destination. The pre-generated link table may include a plurality of link-related feature vectors. The systems may further determine the ETA based on the at least one request-related feature vector and the at least one link-related feature vector. By pre-generating the link table to store the link-related features, the systems only need to analyze the order-related features, and thus, improving the speed and the efficiency of determining the ETA.

It should be noted that determining the ETA, overall, is a technology deeply rooted in Internet world. Determining a target route for a service request and determining the ETA corresponding to the target route may be impossible without the possibility of real-time GPS positioning and real-time communication between a terminal and a server. Therefore, the technical solution disclosed in the present disclosure is also a technology deeply rooted in Internet era.

FIG. 1 is a schematic diagram illustrating an exemplary online to offline service system according to some embodiments of the present disclosure. For example, the online to offline service system 100 may be an online to offline service platform for transportation services such as taxi hailing, chauffeur services, delivery vehicles, carpool, bus service, driver hiring, shuttle services, and product (e.g., food, medicine, electrical appliance, clothing etc. ) delivery services. The online to offline service system 100 may be an online platform including a server 110, a network 120, a requestor terminal 130, a provider terminal 140, and a storage 150.

In some embodiments, the server 110 may be a single server or a server group. The server group may be centralized, or distributed (e.g., server 110 may be a distributed system) . In some embodiments, the server 110 may be local or remote. For example, the server 110 may access information and/or data stored in the requestor terminal 130, the provider terminal 140, and/or the storage 150 via the network 120. As another example, the server 110 may be directly connected to the requestor terminal 130, the provider terminal 140, and/or the storage 150 to access stored information and/or data. In some embodiments, the server 110 may be implemented on a cloud platform. Merely by way of example, the cloud platform may include a private cloud, a public cloud, a hybrid cloud, a community cloud, a distributed cloud, an inter-cloud, a multi-cloud, or the like, or any combination thereof. In some embodiments, the server 110 may be implemented on a computing device 200 having one or more components illustrated in FIG. 2 in the present disclosure.

In some embodiments, the server 110 may include a processing engine 112. The processing engine 112 may process information and/or data relating to a service request to perform one or more functions described in the present disclosure. For example, the processing engine 112 may obtain a pick-up location, a destination and request-related information from a service request and determine an ETA based on the pick-up location, the destination and the request-related information. In some embodiments, the processing engine 112 may include one or more processing engines (e.g., single-core processing engine (s) or multi-core processor (s) ) . 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) , a graphics processing unit (GPU) , a physics processing unit (PPU) , a digital signal processor (DSP) , a field-programmable gate array (FPGA) , a programmable logic device (PLD) , a controller, a microcontroller unit, a reduced instruction-set computer (RISC) , a microprocessor, or the like, or any combination thereof.

The network 120 may facilitate the exchange of information and/or data. In some embodiments, one or more components in the online to offline service system 100 (e.g., the server 110, the requestor terminal 130, the provider terminal 140, the storage 150, and the positioning system 160) may send information and/or data to other component (s) in the online to offline service system 100 via the network 120. For example, the server 110 may obtain/acquire service request from the requestor terminal 130 via the network 120. In some embodiments, the network 120 may be any type of wired or wireless network, or a combination thereof. Merely by way of example, the network 130 may include a cable network, a wireline network, an optical fiber 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 telephone switched network (PSTN) , a Bluetooth network, a ZigBee network, a near field communication (NFC) network, or the like, or any combination thereof. In some embodiments, the network 120 may include one or more network access points. For example, the network 120 may include wired or wireless network access points such as base stations and/or internet exchange points 120-1, 120-2, …, through which one or more components of the online to offline service system 100 may be connected to the network 120 to exchange data and/or information.

In some embodiments, a 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, a user A of the requestor terminal 130 may use the requestor terminal 130 to send a service request for a user B, or receive service and/or information or instructions from the server 110. In some embodiments, a provider may be a user of the provider terminal 140. In some embodiments, the user of the provider terminal 140 may be someone other than the provider. For example, a user C of the provider terminal 140 may use the provider terminal 140 to receive a service request for a user D, and/or information or instructions from the server 110. In some embodiments, “requestor, ” “service requestor, ” and “requestor terminal” may be used interchangeably, and “provider, ” “service 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 in a motor vehicle 130-4, or the like, or any combination thereof. In some embodiments, the mobile device 130-1 may include a smart home device, a wearable device, a mobile device, a virtual reality device, an augmented reality device, or the like, or any combination thereof. In some embodiments, the smart home device may include a smart lighting device, a control device of an intelligent electrical apparatus, a smart monitoring device, a smart television, a smart video camera, an interphone, or the like, or any combination thereof. In some embodiments, the wearable device may include a bracelet, footgear, glasses, a helmet, a watch, clothing, a backpack, a smart accessory, or the like, or any combination thereof. In some embodiments, the mobile device may include a mobile phone, a personal digital assistance (PDA) , a gaming device, a navigation device, a point of sale (POS) device, a laptop, a desktop, or the like, or any combination thereof. In some embodiments, the virtual reality device and/or the augmented reality device may include a virtual reality helmet, a virtual reality glass, a virtual reality patch, an augmented reality helmet, augmented reality glasses, an augmented reality patch, or the like, or any combination thereof. For example, the virtual reality device and/or the augmented reality device may include a Google Glass ^TM, a RiftCon ^TM, a Fragments ^TM, a Gear VR ^TM, etc. In some embodiments, a built-in device in the motor vehicle 130-4 may include an onboard computer, an onboard television, etc. In some embodiments, the requestor terminal 130 may be a device with positioning technology for locating the position of the requestor and/or the requestor terminal 130.

In some embodiments, the provider terminal 140 may be a device that is similar to, or the same as the requestor terminal 130. In some embodiments, the provider terminal 140 may be a device utilizing positioning technology for locating the position of a user of the provider terminal 140 (e.g., a service provider) and/or the provider terminal 140. In some embodiments, the requestor terminal 130 and/or the provider terminal 140 may communicate with one or more other positioning devices to determine the position of the requestor, the requestor terminal 130, the provider, and/or the provider terminal 140. In some embodiments, the requestor terminal 130 and/or the provider terminal 140 may send positioning information to the server 110.

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

In some embodiments, the storage 150 may be connected to the network 120 to communicate with one or more components in 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 in the online to offline service system 100 may access the data or instructions stored in the storage 150 via the network 120. In some embodiments, the storage 150 may be directly connected to or communicate with one or more components in the online to offline service system 100 (e.g., the server 110, the requestor terminal 130, the provider terminal 140, etc. ) . In some embodiments, the storage 150 may be part of the server 110.

In some embodiments, one or more components in the online to offline service system 100 (e.g., the server 110, the requestor terminal 130, the provider terminal 140, etc. ) may have permission to access the storage 150. In some embodiments, one or more components in the online to offline service system 100 may read and/or modify information relating to the requestor, provider, and/or the public when one or more conditions are met. For example, the server 110 may read and/or modify one or more users’information after a service is completed. As another example, the provider terminal 140 may access information relating to the requestor when receiving a service request from the requestor terminal 130, but the provider terminal 140 may not modify the relevant information of the requestor.

In some embodiments, information exchanging of one or more components in the online to offline service system 100 may be achieved by way of requesting a service. The object of the service request may be any product. In some embodiments, the product may be a tangible product or an immaterial product. The tangible product may include food, medicine, commodity, chemical product, electrical appliance, clothing, car, housing, luxury, or the like, or any combination thereof. The immaterial product may include a servicing product, a financial product, a knowledge product, an internet product, or the like, or any combination thereof. The internet product may include an individual host product, a web product, a mobile internet product, a commercial host product, an embedded product, or the like, or any combination thereof. The mobile internet product may be used in a software of a mobile terminal, a program, a system, or the like, or any combination thereof. The mobile terminal may include a tablet computer, a laptop computer, a mobile phone, a personal digital assistance (PDA) , a smart watch, a point of sale (POS) device, an onboard computer, an onboard television, a wearable device, or the like, or any combination thereof. For example, the product may be any software and/or application used in the computer or mobile phone. The software and/or application may relate to socializing, shopping, transporting, entertainment, learning, investment, or the like, or any combination thereof. In some embodiments, the software and/or application relating to transporting may include a traveling software and/or application, a vehicle scheduling software and/or application, a mapping software and/or application, etc. In the vehicle scheduling software and/or application, the vehicle may include a horse, a carriage, a rickshaw (e.g., a wheelbarrow, a bike, a tricycle, etc. ) , a car (e.g., a taxi, a bus, a private car, etc. ) , a train, a subway, a vessel, an aircraft (e.g., an airplane, a helicopter, a space shuttle, a rocket, a hot-air balloon, etc. ) , or the like, or any combination thereof.

One of ordinary skill in the art would understand that when an element of the online to offline service system 100 performs, the element may perform through electrical signals and/or electromagnetic signals. For example, when a requestor terminal 130 processes a task, such as making a determination, identifying or selecting an object, the requestor terminal 130 may operate logic circuits in its processor to process such task. When the requestor terminal 130 sends out a service request to the server 110, a processor of the service requestor terminal 130 may generate electrical signals encoding the service request. The processor of the requestor terminal 130 may then send the electrical signals to an output port. If the requestor terminal 130 communicates with the server 110 via a wired network, the output port may be physically connected to a cable, which may further transmit the electrical signals to an input port of the server 110. If the requestor terminal 130 communicates with the server 110 via a wireless network, the output port of the requestor terminal 130 may be one or more antennas, which may convert the electrical signals to electromagnetic signals. Similarly, a provider terminal 140 may process a task through operation of logic circuits in its processor, and receive an instruction and/or service request from the server 110 via electrical signals or electromagnet signals. Within an electronic device, such as the requestor terminal 130, the provider terminal 140, and/or the server 110, when a processor thereof processes an instruction, sends out an instruction, and/or performs an action, the instruction and/or action is conducted via electrical signals. For example, when the processor retrieves or saves data from a storage medium (e.g., the storage 150) , it may send out electrical signals to a read/write device of the storage medium, which may read or write structured data in 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. Here, an electrical signal may refer to one electrical signal, a series of electrical signals, and/or a plurality of discrete electrical signals.

FIG. 2 is a schematic diagram illustrating exemplary hardware and software components of a computing device on which the server 110, the requestor terminal 130, and/or the provider terminal 140 may be implemented according to some embodiments of the present disclosure. For example, the processing engine 112 may be implemented on the computing device 200 and configured to perform functions of the processing engine 112 disclosed in this disclosure.

The computing device 200 may be used to implement any component of the online to offline service system 100 as described herein. For example, the processing engine 112 may be implemented on the computing device 200, via its hardware, software program, firmware, or a combination thereof. Although only one such computer is shown, for convenience, the computer functions relating to the online to offline service as described herein may be implemented in a distributed fashion on a number of similar platforms, to distribute the processing load.

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

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

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

FIG. 3 is a block diagram illustrating an exemplary processing engine according to some embodiments of the present disclosure. The processing engine 112 may include an obtaining module 310, a request-related feature vector determination module 320, a link-related feature vector determination module 330, an ETA determination module, a training module 350 and a communication module 360.

The obtaining module 310 may be configured to receive a service request from a requestor terminal 130 associated with a service requestor. The service request may be an electronic signal including 6 portions (e.g., see, FIG. 4B and the description thereof) sent from the requestor terminal 130. The obtaining module 310 may also be configured to obtain a pick-up location, a destination and request-related information from the service request.

The service requestor may initiate the service request by designating a pick-up location and/or a destination. In some embodiments, the service requestor may input the pick-up location and/or the destination on a user interface (UI) (e.g., see, FIG. 9A and the description thereof) of an application executed by the requestor terminal 130. In some embodiments, the online to offline service system 100 may automatically recommend one or more candidate pick-up locations and/or one or more candidate destinations to display on the UI for the service requestor to choose.

The request-related feature vector determination module 320 may be configured to determine at least one request-related feature vector based on the request-related information. In some embodiments, the processing engine 112 may determine the at least one request-related feature vector by designating the request-related information as an input of an artificial neural network (ANN) model such as a deep neural network (DNN) model. In some embodiments, a feature database including a plurality of request-related feature vectors may be predetermined based on a DNN. The processing engine 112 may determine the at least one request-related feature vector by searching the feature database and retrieving the at least one request-related feature vector based on the request-related information.

The link-related feature vector determination module 330 may be configured to determine at least one link-related feature vector by searching a pre-generated link table stored in a database (e.g., the storage 150) based on the pick-up location and the destination. The link-related feature vector determination module 330 may be configured to determine a target route from the pick-up location to the destination that includes at least one link, and retrieve a link-related feature vector for each of the at least one link of the target route by searching the pre-generated link table. More descriptions regarding the determination of the at least one link-related feature vector may be found elsewhere in the present disclosure (e.g., see FIG. 8 and the relevant descriptions thereof) .

The ETA determination module 340 may be configured to determine an ETA based on the at least one request-specific related feature vector and the at least one link-related feature vector. The ETA may refer to an estimated time period for driving from the pick-up location of the service request or a current location of the service requestor and/or the service provider to the destination of the service request. In some embodiments, the ETA determination module 340 may determine the ETA by designating the at least one request-specific related feature vector and the at least one link-related feature vector as an input of an ETA determination model. The ETA determination model may output an ETA in response to its input. The ETA determination model may be an ANN model such as a DNN model.

The training module 350 may be configured to train an ETA determination model. The ETA determination model may be an ANN model such as a DNN model. The training module 350 may train the ETA determination model by a training process (e.g., see, FIG. 6 and the description thereof) .

The communication module 360 may be configure to transmit the ETA to a receiving device (e.g., the requestor terminal 130, the provider terminal 140) . In some embodiments, the ETA may be presented on the requestor terminal 130 and/or the provider terminal 140 in a format of text, image, video content, audio content, graphics, etc. (e.g., see, FIG. 9B-D and the description thereof) . In some embodiments, the information associated with the at least one route may be transmitted and/or received via a message using any suitable communication protocol (e.g., the Hypertext Transfer Protocol (HTTP) , Address Resolution Protocol (ARP) , Dynamic Host Configuration Protocol (DHCP) , File Transfer Protocol (FTP) , etc. ) .

The modules in the processing engine 112 may be connected to or communicate with each other via a wired connection or a wireless connection. The wired connection may include a metal cable, an optical cable, a hybrid cable, or the like, or any combination thereof. The wireless connection may include a Local Area Network (LAN) , a Wide Area Network (WAN) , a Bluetooth, a ZigBee, a Near Field Communication (NFC) , or the like, or any combination thereof. Two or more of the modules may be combined as a single module, and any one of the modules may be divided into two or more units. For example, the obtaining module 310 and the communication module 360360 may be combined as a single module which may both obtain the service request and information related to the service request and send the ETA to a receiving device. As another example, the processing engine 112 may include a storage module (not shown in FIG. 3) which may be configured to store any information and/or data (e.g., the pick-up location , the destination, the request-related information related to the service request, etc. ) associated with the ETA.

FIG. 4A is a flowchart illustrating an exemplary process for determining an estimated time of arrival (ETA) according to some embodiments of the present disclosure. The process 400 may be implemented as a set of instructions (e.g., an application) stored in the storage ROM 230 or RAM 240. The processor 220 and/or the modules illustrated in FIG. 3 may execute the set of instructions, and when executing the instructions, it may be configured to perform the process 400. The operations of the illustrated process presented below are intended to be illustrative. In some embodiments, the process 400 may be accomplished with one or more additional operations not described and/or without one or more of the operations discussed. Additionally, the order in which the operations of the process as illustrated in FIG. 4 and described below is not intended to be limiting.

In 410, the processing engine 112 (e.g., the obtaining module 310) (e.g., the interface circuits of the processor 220) may receive a service request from a requestor terminal 130 associated with a service requestor. The service requestor may initiate the service request by designating a pick-up location and/or a destination. In some embodiments, the service requestor may input the pick-up location and/or the destination on a user interface (UI) (e.g., see, FIG. 9A and the description thereof) of an application executed by the requestor terminal 130. In some embodiments, the online to offline service system 100 may automatically recommend one or more candidate pick-up locations and/or one or more candidate destinations to display on the UI for the service requestor to choose.

The service request may be a transportation service request which will be allocated to a service provider who provides a transportation service for the service requestor by a vehicle. For example, the service requestor may initiate a request for a taxi hailing service on a requestor terminal 130, such as a mobile phone of the service requestor. The online to offline service system 100 may allocate the request to a service provider (e.g., an available driver nearest the servicer requestor) and send information (e.g., a pick-up location, a destination) associated with the request to a provider terminal 140 of the service provider. The service provider may then pick up the service requestor at the pick-up location and transport the service request to the destination. As another example, the service requestor may initiate a request for food delivery service from a restaurant on the requestor terminal 130. The online to offline service system 100 may allocate the request to a service provider (e.g., an available deliver nearest the restaurant) and send information (e.g., a location of the restaurant, a location of the service requestor) associated with the request to a provider terminal 140 of the service provider. The service provider may then pick up the food at the restaurant and deliver to the service requestor.

The service request may be encoded in an electronic signal sent from the requestor terminal 130. Further, the format of the electronic signal may include six portions, as shown in FIG. 4B. The first portion (also referred as to portion 1) of the format of the electronic signal may encode a data head indicating a start of the service request itself. The second portion (also referred as to portion 2) of the format of the electronic signal may encode data indicating an identity number associated with the service requestor, such as a phone number, an ID card number, a user ID of the service requestor, etc. The third portion (also referred as to portion 3) of the format of the electronic signal may encode information relating to a pick-up location and a destination of the requested transportation service. The fourth portion (also referred as to portion 4) of the format of the electronic signal may include time information associated with the service request. The fifth portion (also referred as to portion 5) of the format of the electronic signal may include data with respect to a type of the service request (also referred as to a service type) . For example, if the service requestor agrees to share the transportation service with other requestors, the type of the service request may be a carpool type. The sixth portion (also referred as to portion 6) of the format of the electronic signal may indicate the end of the electronic signal. It should be noted that the six portions of the electronic signal are only provided for illustration, the format of the electronic signal may include any arbitrary number of portions. For example, the fifth portion may be omitted. As another example, the format of the electronic signal may further include one portion include weather information showing a weather condition when the service request is initiated.

In some embodiments, the online to offline service system 100 may create a unique identity number and correspondingly allocate a storage space of a storage device (e.g., the storage 150) for each user (e.g., a requestor or a provider) when the user first request a service on the online to offline service system 100. Each storage space may be configured to store information associated with a user. Based on the identity number of a user, the online to offline service system 100 may access the storage space corresponding to the user and retrieve more request-related information such as personal information, preference settings, vehicle information, travel habit, driving habit, of the user, etc. The personal information of the service requestor may include but not limited to a name, a nickname, nationality, profession, age, gender, contact information (e.g., a mobile phone number, a social media account such as a WeChat ^TM number, a QQ ^TM number, a LinkedIn ^TM account, or other information that may be used to contact the user) , or the like, or any combination thereof. The preference settings of the service requestor may refer to one or more preferences set by a user, based on which the online to offline service system 100 determines a route and/or assigns a service provider for a service requestor. For example, a service requestor may prefer to choose a tollway during a morning rush hour. As another example, a service requestor may prefer a service provider with a rating score higher than 4.8 out of 5. The preference settings may be preset on a terminal (e.g., the requestor terminal 130, the provider terminal 140) by the user. The vehicle information may include information related to a vehicle of a service provider such as a license plate number, a brand, a model, a purchase date, a hardware condition, maintenance records, etc. Both the travel habit and the driving habit may be extracted form information related to historical service requests (also referred as to historical service orders) of the user. For example, based on information related to historical service requests of the service requestor, the online to offline service system 100 may extract that the service requestor has a habit of being two to ten minutes later than the scheduled pick-up time. As another example, based on information related to historical service requests of the service provider, the online to offline service system 100 may extract that the service provider is an experienced driver who drives faster and more safely than others.

The above portions in the electronic signal may be placed in a predetermined order. The predetermined order may be a sequential order from portion 1 to portion 6 (e.g., portion 1, portion 2, portion 3, portion 4, portion 5, portion 6) . Alternatively, except the portion 1 and the portion 6, other portions of the electronic signal may be randomly arranged (e.g., portion 1, portion 3, portion 4, portion 2, portion 5, portion 6) .

In 420, the processing engine 112 (e.g., the obtaining module 310) (e.g., the interface circuits of the processor 220) may obtain a pick-up location, a destination and request-related information from the service request. As used herein, the pick-up location may refer to a starting location where a service provider (e.g., a driver) picks up a service requestor (e.g., a passenger) , or a location where a service provider (e.g., a deliver) picks up a product ordered by a service requestor. The request-related information may refer to information related to the service request that affects determining an ETA for the service request. The ETA may refer to an estimated time period for driving from the pick-up location of the service request or a current location of the service requestor and/or the service provider to the destination of the service request. In some embodiments, the request-related information may include but not limited to time information, weather information, a service type, information associated with the service requestor such as personal information, preference settings and travel habit, information associated with the service provider such as personal information, vehicle information and driving habit, or the like, or any combination thereof.

In some embodiments, the processing engine 112 may obtain the pick-up location, the destination and the request-related information from the service request by decoding the service request directly from the electric signal. For example, the processing engine 112 may decode the service request and obtain the pick-up location and the destination from the third portion of the service request described above. As another example, the processing engine 112 may obtain time information associated with the service requestor form the fourth portion of the decoded service request, and may obtain a service type form the fifth portion of the decoded service request. In some embodiments, the processing engine 112 obtain the request-related information from the service request by decoding the service request from the electric signal and accessing a storage device (e.g., the storage 150) for retrieving more request-related information based on at least one portion of the decoded service. For example, the processing engine 112 may obtain identity information of the service requestor from the second portion of the decoded service request. The processing engine 112 may retrieve more request-related information from a storage device (e.g., the storage 150) based on the identity information of the service requestor. In some embodiments, the processing engine 112 may access an external system for retrieving more request-related information based on the decoded service request. For example, the processing engine 112 may access a weather forecast system and retrieve weather information in a future time period (e.g., a next 15 minutes, a next 1 hour) based on time information obtained from the fourth portion of the decoded service request.

In some embodiments, after receiving the service request, the processing engine 112 may allocate the service request to a service provider. Based on an identity number of the service provider, the processing engine 112 may access a storage device (e.g., the storage 150) and retrieve more request-related information related to the service provider such as vehicle information and driving habit of the service provider.

In some embodiments, the pick-up location, the destination and at least one portion of the request-related information may be associated with determining a target route and an ETA corresponding to the target route. For example, there may be a plurality of candidate route from the pick-up location to the destination. The processing engine 112 may determine a candidate route including at least one tollway as the target route based on time information (e.g., 8: 30 am on a workday) and a preference setting of the service requestor that the service requestor prefers to pay the toll fee to save time during morning rush hour. The request-related information may affect the ETA corresponding to the target route. In some embodiments, the time information and the weather information may affect a traffic condition, which further affects a driving speed of the service provider. For example, whether it is morning and/or evening rush hour or non-rush hour affects the traffic conditions. As another example, whether it is sunny, raining, or snowing affects the traffic conditions. In some embodiments, the service type (e.g., a carpool type) may increase the waiting time for other service requestors. In yet another embodiment, the travel habit of the service requestor may increase the waiting time for the service requestor and affect a driving speed of the service provider. For example, whether the service requestor was always on time or late affects the waiting time. As another example, whether the service requestor asked the service provider to drive slowly affects the waiting time. In yet another embodiment, the vehicle information (e.g., a brand, a model, a purchase date, a hardware condition, maintenance records) may affect a driving speed of the service provider. For example, a newly purchased or well-maintained sports car may have faster driving speed than a ten years old sedan. In yet another example, the driving habit of the service provider may affect a driving speed of the service provider. For example, when the service provider is very familiar with road conditions of a specific area, he/she may drive faster in the specific area than in other areas.

In 430, the processing engine 112 (e.g., the request-related feature vector determination module 320 (e.g., the processing circuits of the processor 220) may determine at least one request-related feature vector based on the request-related information. In some embodiments, the processing engine 112 may determine the at least one request-related feature vector by designating the request-related information as an input of an artificial neural network (ANN) model such as a deep neural network (DNN) model. In some embodiments, a feature database may be predetermined based on a DNN. The feature database may include a plurality of request-related feature vectors. The processing engine 112 may determine the at least one request-related feature vector by searching the feature database and retrieving the at least one request-related feature vector based on the request-related information.

In some embodiments, a request-related feature vector may include a plurality of elements. Each element of the request-related vector may represent a feature of the request-related information. The feature of the request-related information may include but not limited to a time feature, a weather feature, a service type, a preference feature and a travel habit feature of a service provider, a vehicle feature and a driving habit feature of a service provider.

In 440, the processing engine 112 (e.g., the link-related feature vector determination module 330) (e.g., the interface circuits of the processor 220) may determine at least one link-related feature vector by searching a pre-generated link table stored in a database (e.g., the storage 150) based on the pick-up location and the destination. The processing engine 112 may determine a target route from the pick-up location to the destination that includes at least one link, and retrieve a link-related feature vector for each of the at least one link of the target route by searching the pre-generated link table. More descriptions regarding the determination of the at least one link-related feature vector may be found elsewhere in the present disclosure (e.g., see FIG. 8 and the relevant descriptions thereof) .

The link table may include a plurality of link-related feature vectors. The plurality of link-related feature vectors may be pre-generated with respect to a plurality of links corresponding to roads of an area (e.g., a town, a county, a district of a city, a city, a province) . Each of the plurality of link-related feature vectors may correspond to one of the plurality of links. As used herein, a “link” may refer to a segment linking two locations (e.g., see, FIG. 8 and the description thereof) in a route. In some embodiments, a route may be represented by a link sequence including a plurality of links. The plurality of links may have a same or different length. In some embodiments, a link-related feature vector may include a plurality of elements. Each element of the link-related vector may represent a feature of a link. The feature of the link may include static features and dynamic features. The static features may refer to factors that rarely vary according to time, and thus, having less effect on the ETA. The static features may include but not limited to a length, a number of lanes, a speed limit, a road level, a road toll, of the link, or the like, or any combination thereof. The dynamic features may refer to factors that vary with time, and thus, having more effect on the ETA. The dynamic features may include but not limited to a current time, a congestion level, a traffic-light waiting time of an intersection included in the link, or the like, or any combination thereof.

The plurality of link-related feature vectors of the link table may be pre-generated based on a model. The model may be an ANN such as a DNN model. As used herein, the plurality of link-related feature vectors may be determined based on an output of the model, and the output of the model may represent features associated with the plurality of links. For example, the features may include static features and dynamic features. In some embodiments, the output of the model may represent each of the features associated with the plurality of links by characters, vectors, etc. For example, the congestion level of the link may be represented by 0, 1, and 2. 0 may represent the link is not congested (i.e., smooth) , 1 may represent the link is slightly congested (i.e., vehicles along the link move ahead slowly, e.g., an average speed is 10 km/h) , and 2 may represent the link is heavily congested (i.e., vehicles along the link can barely move ahead, e.g., an average speed is 0 km/h) . As another example, the congestion level of the link may be represented by (0, 0, 0) , (0, 1, 0) and (0, 0, 1) . (0, 0, 0) may represent the link is not congested, (0, 1, 0) represent the link is slightly congested, and (0, 0, 1) may represent the link is heavily congested. In some embodiments, the plurality of link-related feature vectors may be periodically updated by the model. More descriptions regarding the updating of the link table may be found elsewhere in the present disclosure (e.g., see FIG. 8 and the relevant descriptions thereof) .

In 450, the processing engine 112 (e.g., the ETA determination module 340) (e.g., the processing circuits of the processor 220) may determine the ETA based on the at least one request-specific related feature vector and the at least one link-related feature vector. The processing engine 112 may determine the ETA by designating the at least one request-specific related feature vector and the at least one link-related feature vector as an input of an ETA determination model. The ETA determination model may output an ETA in response to its input. The ETA determination model may be an ANN model such as a DNN model.

The ETA determination model may be trained based on information related to historical service requests. As used herein, a historical service request is also referred to as a historical service order which is a completed transaction (e.g., a service provider has transport a service requestor or a product ordered by the service requestor to a designated destination) between a service requestor and a service provider. More descriptions regarding the training of the ETA determination model may be found elsewhere in the present disclosure (e.g., see FIG. 6 and the relevant descriptions thereof) .

In 460, the processing engine 112 (e.g., the communication module 360) (e.g., the interface circuits of the processor 220) may transmit the ETA to a receiving device (e.g., the requestor terminal 130, the provider terminal 140) . In some embodiments, the ETA may be presented on the requestor terminal 130 and/or the provider terminal 140 in a format of text, image, video content, audio content, graphics, etc. (e.g., see, FIG. 9B-D and the description thereof) . In some embodiments, the information associated with the at least one route may be transmitted and/or received via a message using any suitable communication protocol (e.g., the Hypertext Transfer Protocol (HTTP) , Address Resolution Protocol (ARP) , Dynamic Host Configuration Protocol (DHCP) , File Transfer Protocol (FTP) , etc. ) .

In some embodiments, information associated with the at least one route may be presented on the requestor terminal 130 and/or the provider terminal 140 in a format of text, image, video content, audio content, graphics, etc. In some embodiments, the information associated with the at least one route may be transmitted and/or received via a message using any suitable communication protocol (e.g., the Hypertext Transfer Protocol (HTTP) , Address Resolution Protocol (ARP) , Dynamic Host Configuration Protocol (DHCP) , File Transfer Protocol (FTP) , etc. ) .

For illustration purposes, the present disclosure describes an application scenario in which the processing engine 112 receives a service request for a transportation service and the requestor agrees to share the transportation service with other requestors. Further, the processing engine 112 determines a target route for the service request and determines at least one route similar to the target route. It should be noted that the application scenario is only provided for the purpose of illustration, the present disclosure may be applied in any other application scenario.

It should be noted that the above description is merely provided for the purposes of illustration, and not intended to limit the scope of the present disclosure. For persons having ordinary skills in the art, multiple variations and modifications may be made under the teachings of the present disclosure. However, those variations and modifications do not depart from the scope of the present disclosure. For example, operation 410 and operation 420 may be combined as a single operation in which the processing engine 112 may both receive the service request and obtain the pick-up location, the destination location and the request-related information from the service request. As another example, one or more other optional operations (e.g., a storing operation) may be added elsewhere in the exemplary process 400. In the storing operation, the processing engine 112 may store information and/or data (e.g., the pick-up location, the destination, the request-related information related to the service request, etc. ) associated with the ETA.

FIG. 5 is a block diagram illustrating an exemplary training module according to some embodiments of the present disclosure. The training module 350 may include a setting unit 510, a sample obtaining unit 520, a determination unit 530, and a modification unit 540.

The setting unit 510 may be configured to set initial parameters of an ETA determination model (e.g., a DNN model) . The ETA determination model may include an input layer, at least one hidden layer, and an output layer. The initial parameters may include at least a first initial parameter associated with the input layer, at least a second initial parameter associated with the at least one hidden layer, or at least a third initial parameter associated with the output layer. The initial parameters may be default settings of the system 100, or may be adjustable under different situations.

The sample obtaining unit 520 may be configured to obtain information related to a set of historical service requests. As used herein, a historical service request is also referred to as a historical service order which is a completed transaction (e.g., a service provider has transported a service requestor or a product ordered by the service requestor to a designated destination) between a requestor and a provider. The processing engine 112 may obtain the information related to a set of historical service requests from a storage device (e.g., the storage 150) disclosed elsewhere in the present disclosure.

The determination unit 530 may be configured to determine a predicted ETA with respect to each of the set of historical service requests by designating a corresponding sample link-related feature vector and a corresponding sample request-related feature vector as an input of the ETA determination model.

The modification unit 540 may be configured to iteratively train the ETA determination model by minimizing a difference between the sample ETA and the predicted ETA with respect to each of the set of historical service requests. For example, the processing engine 112 may modify/update the initial parameter and by using a backpropagation algorithm or a gradient descent algorithm. The gradient descent algorithm may include Stochastic Gradient Descent, Batch Gradient Descent, Mini-batch Gradient Descent, etc.

The units in the training module 350 may be connected to or communicate with each other via a wired connection or a wireless connection. The wired connection may include a metal cable, an optical cable, a hybrid cable, or the like, or any combination thereof. The wireless connection may include a Local Area Network (LAN) , a Wide Area Network (WAN) , a Bluetooth, a ZigBee, a Near Field Communication (NFC) , or the like, or any combination thereof. Two or more of the units may be combined as a single module, and any one of the units may be divided into two or more sub-units. For example, the training module 350 may include a storage unit (not shown) used to store any information (e.g., the initial parameters) associated with the ETA determination model. As another example, the units in the training module 350 may include a storage sun-unit (not shown) respectively.

FIG. 6 is a flowchart illustrating an exemplary process for training an ETA determination model according to some embodiments of the present disclosure. The process 600 may be implemented as a set of instructions (e.g., an application) stored in the storage ROM 230 or RAM 240. The processor 220 and/or the units in FIG. 5 may execute the set of instructions, and when executing the instructions, it may be configured to perform the process 600. The operations of the illustrated process presented below are intended to be illustrative. In some embodiments, the process 600 may be accomplished with one or more additional operations not described and/or without one or more of the operations discussed. Additionally, the order in which the operations of the process as illustrated in FIG. 6 and described below is not intended to be limiting.

In 610, the processing engine 112 (e.g., the setting unit 510) (e.g., the processing circuits of the processor 220) may set initial parameters of an ETA determination model (e.g., a DNN model) . The ETA determination model may include an input layer, at least one hidden layer, and an output layer. The initial parameters may include at least a first initial parameter associated with the input layer, at least a second initial parameter associated with the at least one hidden layer, or at least a third initial parameter associated with the output layer. The initial parameters may be default settings of the system 100, or may be adjustable under different situations.

In 620, the processing engine 112 (e.g., the sample obtaining unit 520) (e.g., the interface circuits of the processor 220) may obtain information related to a set of historical service requests. As used herein, a historical service request is also referred to as a historical service order which is a completed transaction (e.g., a service provider has transport a service requestor or a product ordered by the service requestor to a designated destination) between a requestor and a provider. The processing engine 112 may obtain the information related to a set of historical service requests from a storage device (e.g., the storage 150) disclosed elsewhere in the present disclosure.

The information related to the set of historical service requests may include sample link-related feature vectors, sample request-related feature vectors, and sample ETAs associated with the sample link-related feature vectors and the sample request-related feature vectors, respectively. As used herein, information related to each of the set of historical service requests may include at least one corresponding sample link-related feature vector, a corresponding sample request-related vector and a corresponding sample ETA. A sample ETA may refer to an actual time for driving along at least one link corresponding to the least one corresponding sample link-related feature vector.

In 630, the processing engine 112 (e.g., the determination unit 530) (e.g., the processing circuits of the processor 220) may determine a predicted ETA with respect to each of the set of historical service requests by designating a corresponding sample link-related feature vector and a corresponding sample request-related feature vector as an input of the ETA determination model. As described in operation 620, the corresponding sample link-related feature vector and the corresponding sample request-related feature vector may correspond to a sample ETA which is an actual time of arriving at a destination.

In 640, the processing engine 112 (e.g., the modification unit 540) (e.g., the processing circuits of the processor 220) may iteratively train the ETA determination model by minimizing a difference between the sample ETA and the predicted ETA with respect to each of the set of historical service requests. In some embodiments, the difference between the sample ETA and the predicted ETA may be assessed in terms of a loss function. The loss function may include but not limited to an L1 norm loss function, an L2 norm loss function, a quadratic cost function, a cross-entropy loss function, a log-likelihood cost function, or the like, or any combination thereof. In some embodiments, the processing engine 112 may modify/update parameters of the ETA determination model by using a backpropagation algorithm or a gradient descent algorithm in each iteration. The gradient descent algorithm may include Stochastic Gradient Descent, Batch Gradient Descent, Mini-batch Gradient Descent, etc. The parameters of the ETA determination model may be modified/updated by different strategies. For example, if the difference between the sample ETA and the predicted ETA in a present iteration is greater than a threshold (e.g., a difference determined in a preceding iteration) , part or all parameters of the ETA determination model may be modified/updated. If the difference between the sample ETA and the predicted ETA in the present iteration is smaller than the difference in the preceding iteration, the parameters of the ETA determination model may be not modified/updated in the present iteration. In some embodiments, the processing engine 112 may terminate the iterations and determine a trained ETA determination model until all training data are traversed or a preset condition is satisfied. An exemplary preset condition may include that the difference between a sample ETA and its corresponding predicted ETA is smaller than a preset threshold in one or more consecutive iterations.

It should be noted that the above description is merely provided for the purposes of illustration, and not intended to limit the scope of the present disclosure. For persons having ordinary skills in the art, multiple variations and modifications may be made under the teachings of the present disclosure. However, those variations and modifications do not depart from the scope of the present disclosure. For example, one or more other optional operation (e.g., a storing operation) may be added elsewhere in the exemplary process 600. In the storing operation, the processing engine 112 may store any information and/or data (e.g., the initial parameters, the set of historical service requests, etc. ) associated with the ETA determination model.

FIG. 7 is a block diagram illustrating an exemplary link-related feature vector determination module according to some embodiments of the present disclosure. The link-related feature vector determination module 330 may include a route determination unit 710, a link sequence determination unit 720, and a vector determination unit 730.

The route determination unit 710 may be configured to determine a target route from a pick-up location to a destination. There may be more than one candidate routes from the pick-up location to the destination. In some embodiments, the processing engine 112 may determine the target route from the candidate routes based on at least one portion of request-related information.

The link sequence determination unit 720 may be configured to determine a link sequence based on the target route. The link sequence may include at least one link and may correspond to a direction of the target route. As described in connection with operation 420, a “link” may refer to a segment linking two locations of a route (e.g., the target route) .

The vector determination unit 730 may be configured to retrieve a link-related feature vector for each of the at least one link of the target route by searching a pre-generated link table stored in a database (e.g., the storage 150) . The link table may include a plurality of link-related feature vectors. The plurality of link-related feature vectors may be pre-generated with respect to a plurality of links corresponding to roads of an area (e.g., a town, a county, a district of a city, a city, a province) .

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

FIG. 8 is a flowchart illustrating an exemplary process for determining a link-related feature vector according to some embodiments of the present disclosure. The process 800 may be implemented as a set of instructions (e.g., an application) stored in the storage ROM 230 or RAM 240. The processor 220 and/or the units in FIG. 7 may execute the set of instructions, and when executing the instructions, it may be configured to perform the process 800. The operations of the illustrated process presented below are intended to be illustrative. In some embodiments, the process 800 may be accomplished with one or more additional operations not described and/or without one or more of the operations discussed. Additionally, the order in which the operations of the process as illustrated in FIG. 8 and described below is not intended to be limiting.

In 810, the processing engine 112 (e.g., the route determination unit 710) (e.g., the interface circuits of the processor 220) may determine a target route from a pick-up location to a destination. There may be more than one candidate routes from the pick-up location to the destination. In some embodiments, the processing engine 112 may determine the target route from the candidate routes based on at least one portion of request-related information. As described in connection with operation 420, the request-related information may include but not limited to time information, weather information, a service type, information associated with a service requestor such as personal information, preference settings and travel habit, information associated with a service provider such as personal information, vehicle information and driving habit, or the like, or any combination thereof. For example, during a morning rush hour of a particular workday, the service provider is allowed to drive on a tollway according to a license plate number of the service provider’s vehicle and the service requestor prefers to pay a toll fee to save time, the processing engine 112 may determine a target route along one or more tollways to save time for the service requestor. In some embodiments, the processing engine 112 may directly determine the target route based on historical service requests of the service requestor. For example, the service requestor may designate his house as the pick-up location and his workplace as the destination during a morning rush hour of a workday (e.g., 8: 00 am of a Monday) . The processing engine 112 may directly obtain the target route from a storage device (e.g., the storage 150) because the target route is stored as a regular route of the service requestor.

In 820, the processing engine 112 (e.g., the link sequence determination unit 820) (e.g., the processing circuits of the processor 220) may determine a link sequence based on the target route. The link sequence may include at least one link and may correspond to a direction of the target route. As described in connection with operation 420, a “link” may refer to a segment linking two locations of a route (e.g., the target route) .

For example, for a specific target route, the target route may include a plurality of locations illustrated below:

TR = [W ₁, W ₂, … ,W _i … ,W _m] , (1≤i≤m) (1)

TR refers to the target route. m refers to a number of the plurality of locations in the target route TR, W _i refers to geographic information of a specific location i in the target route TR, and a sequence of the plurality of locations corresponds to a direction of the target route TR. The geographic information of a specific location i may include longitude-latitude coordinates of the location i.

Accordingly, the target route may be represented by a link sequence illustrated below:

In 830, the processing engine 112 (e.g., the vector determination unit 730) (e.g., the processing circuits of the processor 220) may retrieve a link-related feature vector for each of the at least one link of the target route by searching a pre-generated link table stored in a database (e.g., the storage 150) . For example, for a link

the processing engine 112 may search the link

in the pre-generated link table and retrieve a link-related feature vector of the link

The link table may include a plurality of link-related feature vectors. The plurality of link-related feature vectors may be pre-generated with respect to a plurality of links corresponding to roads of an area (e.g., a town, a county, a district of a city, a city, a province) . In some embodiments, a link-related feature vector may include a plurality of elements. Each element of the link-related vector may represent a feature of a link. The feature of the link may include static features and dynamic features. The static features may refer to factors that rarely vary according to time, and thus, having less effect on the ETA. The static features may include but not limited to a length, a number of lanes, a speed limit, a road level, a road toll of the link, or the like, or any combination thereof. The dynamic features may refer to factors that vary with time, and thus having more effect on the ETA. The dynamic features may include but not limited to a current time, a congestion level, a traffic-light waiting time of an intersection included in the link, or the like, or any combination thereof.

The plurality of link-related feature vectors of the link table may be pre-generated based on a model. The model may be an ANN such as a DNN model. As used herein, the plurality of link-related feature vectors may be determined based on an output of the model, and the output of the model may represent features associated with the plurality of links. For example, the features may include static features and dynamic features. In some embodiments, the output of the model may represent each of the features associated with the plurality of links by characters, vectors, etc. For example, the congestion level of the link may be represented by 0, 1, and 2. 0 may represent the link is not congested (i.e., smooth) , 1 may represent the link is slightly congested (i.e., vehicles along the link move ahead slowly, e.g., an average speed is 10 km/h) , and 2 may represent the link is heavily congested (i.e., vehicles along the link can barely move ahead, e.g., an average speed is 0 km/h) . As another example, the congestion level of the link may be represented by (0, 0, 0) , (0, 1, 0) and (0, 0, 1) . (0, 0, 0) may represent the link is not congested, (0, 1, 0) represent the link is slightly congested, and (0, 0, 1) may represent the link is heavily congested. In some embodiments, the plurality of link-related feature vectors may be periodically updated by the model. The updating period may be an arbitrary value such as 30 seconds, 2 minutes, 5 minutes, half an hour, or the like. In some embodiments, the plurality of link-related feature vectors may be updated based on information uploaded by terminals of a plurality of users (e.g., the requestor terminal 130, the provider terminal 140) . For example, a road accident may happen on an intersection, leading to a severe congestion. Based on location information (e.g., GPS information) uploaded periodically (e.g., per five seconds) or in real time by terminals of a plurality of users, the processing engine 112 may find that lots of vehicles are stuck on the intersection and update a congestion level of a link corresponding to the intersection. In some embodiments, the plurality of link-related feature vectors may be updated based on information obtained form an external system. For example, the transportation department of a city may release a notification on its website that a green light time of an intersection will be adjusted temporarily. The processing engine 112 may learn this notification and update a traffic-light waiting time of a link corresponding to the intersection. The processing engine 112 may determine a link-related feature vector closer to an actual condition of a link by periodically updating of the link table.

Determining a link-related feature vector by searching a pre-generated link table may increase a response time of determining an ETA for the online to offline service system 100. The response time of determining an ETA may refer to a time from the moment receiving a request for an ETA to the moment determining the ETA. The response time of determining an ETA using a process disclosed elsewhere in the present disclosure may be increased to a microsecond level.

FIG. 9A is a schematic diagram illustrating an exemplary user interface presenting a service request according to some embodiments of the present disclosure. The user interface 900A may be presented by a terminal (e.g., the requestor terminal 130, the provider terminal 140) . The user interface 900 may include one or more user interface elements (also referred to as the "UI elements" ) for presenting information associated with a service request. Each of the UI elements may be and/or include, for example, one or more buttons, icons, checkboxes, message boxes, text fields, data fields, search fields, etc.

For example, as illustrated, the user interface 900A may include a UI element 902 for presenting a service type (e.g. Express, Taxi, Premier, Carpool) . The user interface 900 may also include a UI element 904 for presenting an input box used for receiving an input associated with a pick-up location and a UI element 906 for presenting an input box used for receiving an input associated with a destination. Further, the user interface 900 may also include a UI element 908 for presenting an option (e.g., “ExpressPool, ” “No ExpressPool” ) for agreeing to share a transportation service with other requestors or not.

FIG. 9B is a schematic diagram illustrating an exemplary user interface presenting an ETA related to a service request according to some embodiments of the present disclosure. The user interface 900B may be shown on a requestor terminal 130 of a service requestor (e.g., a passenger) , presenting that the service requestor is waiting for a pick-up from a service provider (e.g., driver) Wu. The user interface 900B may also present an ETA 27: 35, including a waiting time 2 minutes, determined by the online to offline service system 100.

FIG. 9C is a schematic diagram illustrating an exemplary user interface presenting an ETA related to a service request according to some embodiments of the present disclosure. The user interface 900C may be shown on a provider terminal 140 of a service provider (e.g., a driver) , presenting that the service provider has arrived the pick-up location and is waiting for a service provider (e.g., passenger) Hu. The user interface 900C may also present an ETA 30: 17, including a waiting time 5 minutes, determined by the online to offline service system 100.

FIG. 9D is a schematic diagram illustrating an exemplary user interface presenting an ETA related to a service request according to some embodiments of the present disclosure. The user interface 900D may be shown on a requestor terminal 130 of a service requestor (e.g., a passenger) and/or a provider terminal 140 of a service provider (e.g., a driver) , presenting that the service requestor and the service provider are on their way to the destination. The user interface 900D may also present their current location and an ETA 12: 17 determined by the online to offline service system 100.

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

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

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

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

Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C++, C#, VB. NET, Python or the like, conventional procedural programming languages, such as the "C" programming language, Visual Basic, Fortran 2003, Perl, COBOL 2002, PHP, ABAP, dynamic programming languages such as Python, Ruby and Groovy, or other programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN) , or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider) or in a cloud computing environment or offered as a service such as a Software as a Service (SaaS) .

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

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

Claims

A system for determining an estimated time of arrival (ETA) , comprising:

at least one storage device including a set of instructions;

a data exchange port communicatively connected to a network;

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

receive, via the network, a service request from a requestor terminal associated with a service requestor;

obtain a pick-up location, a destination and request-related information from the service request;

determine at least one request-related feature vector based on the request-related information;

determine at least one link-related feature vector by searching a pre-generated link table stored in a database based on the pick-up location and the destination; and

determine the ETA based on the at least one request-related feature vector and the at least one link-related feature vector.
The system of claim 1, wherein the request-related information further includes at least one of time information, weather information, or a type of the service request.
The system of claim 1 or 2, wherein the request-related information includes at least one of:

personal information of the service requestor;

preference settings of the service requestor; or

travel habit of the service requestor.
The system of any of claims 1-3, wherein the request-related information includes at least one of:

personal information of a service provider;

vehicle information of the service provider; or

driving habit of the service provider.
The system of claim 1, wherein to determine at least one link-related feature vector by searching a pre-generated link table stored in a database based on the pick-up location and the destination, the at least one processor is configured to cause the system further to:

determine a target route from the pick-up location to the destination location;

determine a link sequence based on the target route, wherein the link sequence includes at least one link; and

retrieve the link-related feature vector for each of the at least one link by searching the pre-generated link table stored in the database.
The system of claim 1 or 5, wherein the link table includes a plurality of feature vectors pre-generated with respect to a plurality of links corresponding to roads of an area, and are periodically updated by an Artificial Neural Network model.
The system of claim 1, wherein to determine the ETA based on the at least one request-specific feature vector and the at least one link-related feature vector, the at least one processor is configured to cause the system further to:

determine the ETA by designating the at least one request-related feature vector and the at least one link-related feature vector as an input of an ETA determination model.
The system of claim 7, wherein the ETA determination model is an Artificial Neural Network model.
The system of claim 7 or 8, wherein the ETA determination model is trained by a process comprising:

obtaining information related to a set of historical service requests, wherein the information related to the set of historical service requests includes sample link-related feature vectors, sample request-related feature vectors, and sample ETAs associated with the sample link-related feature vectors and the sample request-related feature vectors, respectively;

determining a predicted ETA with respect to each of the set of historical service requests by designating a corresponding sample link-related feature vector and a corresponding sample request-related feature vector as an input of the ETA determination model; and

iteratively training the ETA determination model by minimizing a difference between a corresponding sample ETA and the predicted ETA with respect to each of the set of historical service requests.
The system of any of claims 1-9, wherein the at least one processor is configured to cause the system further to:

transmit, via the network, the ETA to the requestor terminal associated with the service requestor.
A method for determining an estimated time of arrival (ETA) , implemented on a computing device having at least one processor, at least one storage device, and a data exchange port communicatively connected to a network, the method comprising:

receiving, via the network, a service request from a requestor terminal associated with a service requestor;

obtaining a pick-up location, a destination and request-related information from the service request;

determining at least one request-related feature vector based on the request-related information;

determining at least one link-related feature vector by searching a pre-generated link table stored in a database based on the pick-up location and the destination; and

determining the ETA based on the at least one request-related feature vector and the at least one link-related feature vector.
The method of claim 11, wherein the request-related information further includes at least one of time information, weather information or a type of the service request.
The method of claim 11 or 12, wherein the request-related information includes at least one of:

personal information of the service requestor;

preference settings of the service requestor; or

travel habit of the service requestor.
The method of any of claims 11-13, wherein the request-related information includes at least one of:

personal information of a service provider,

vehicle information of the service provider; or

driving habit of the service provider.
The method of claim 11, wherein determining the at least one link-related feature vector by searching the pre-generated link table stored in the database based on the pick-up location and the destination comprises:

determining a target route from the pick-up location to the destination location;

determining a link sequence based on the target route, wherein the link sequence includes at least one link; and

retrieving the link-related feature vector for each of the at least one link by searching the pre-generated link table stored in the database.
The method of claim 11 or 15, wherein the link table includes a plurality of feature vectors pre-generated with respect to a plurality of links corresponding to roads of an area, and are periodically updated by an Artificial Neural Network model.
The method of claim 11, wherein determining the ETA based on the at least one request-specific feature vector and the at least one link-related feature vector comprises:

determining the ETA by designating the at least one request-related feature vector and the at least one link-related feature vector as an input of an ETA determination model.
The method of claim 17, wherein the ETA determination model is an Artificial Neural Network model.
The method of claim 17 or 18, wherein the ETA determination model is trained by a process comprising:

obtaining information related to a set of historical service requests, wherein the information related to the set of historical service requests includes sample link-related feature vectors, sample request-related feature vectors, and sample ETAs associated with the sample link-related feature vectors and the sample request-related feature vectors, respectively;

determining a predicted ETA with respect to each of the set of historical service requests by designating a corresponding sample link-related feature vector and a corresponding sample request-related feature vector as an input of the ETA determination model; and

iteratively training the ETA determination model by minimizing a difference between a corresponding sample ETA and the predicted ETA with respect to each of the set of historical service requests.
The method of any of claims 11-19, further comprising:

transmitting, via the network, the ETA to the requestor terminal associated with the service requestor.
A non-transitory computer readable medium comprising a set of instructions for determining an estimated time of arrival (ETA) that, when executed by at least one processor, cause the at least one processor to effectuate a method comprising:

receiving, via a network, a service request from a requestor terminal associated with a service requestor;

obtaining a pick-up location, a destination and request-related information from the service request;

determining at least one request-related feature vector based on the request-related information;

determining at least one link-related feature vector by searching a pre-generated link table stored in a database based on the pick-up location and the destination; and

determining the ETA based on the at least one request-related feature vector and the at least one link-related feature vector.