Patent Application
20240169462
The present disclosure relates to the field of computer application technologies, and in particular, to big data computing and deep learning technologies in the field of artificial intelligence technologies.
With the development of mobile Internet, the emergence of an online ride-hailing platform has greatly changed people's lives. The online ride-hailing platform puts drivers in need of receiving orders with passengers in need of ride hailing on an online platform. After a passenger sends an order (hereinafter referred to as “order sending”), the online ride-hailing platform may effectively match a driver within a certain distance from the passenger, and the matched driver receives the order and picks up the passenger to a destination designated in the order. Online ride hailing has advantages of being ready to go, efficient and in no need of worrying about parking.
Passengers may inevitably consider costs of online ride hailing in practical scenarios. For example, at present, an online ride-hailing client may give a user an estimated cost of ride hailing at a current time for a passenger's reference after the passage enters an origin and a destination. However, the passenger can only consider accordingly whether to perform ride hailing currently. If current ride hailing is at a high cost due to road conditions or other problems, the passenger may either give up or try to acquire an estimated ride-hailing cost later. This inevitably brings inconvenience to the passenger and is inefficient, and the users' repeated attempts to estimate the ride-hailing cost also waste network resources and put pressure on system performance.
In view of the above, the present disclosure provides an online ride-hailing information processing method, a device, and a computer storage medium.
According to a first aspect of the present disclosure, an online ride-hailing information processing method is provided, including:
According to a second aspect of the present disclosure, an online ride-hailing information processing method is provided, including:
According to a third aspect of the present disclosure, an electronic device is provided, including:
According to a fourth aspect of the present disclosure, a non-transitory computer-readable storage medium storing computer instructions is provided, and the computer instructions are configured to cause a computer to perform the method as described above.
It should be understood that the content described in this part is neither intended to identify key or significant features of the embodiments of the present disclosure, nor intended to limit the scope of the present disclosure. Other features of the present disclosure will be made easier to understand through the following description.
The accompanying drawings are intended to provide a better understanding of the solutions and do not constitute a limitation on the present disclosure. In the drawings,
Exemplary embodiments of the present disclosure are illustrated below with reference to the accompanying drawings, which include various details of the present disclosure to facilitate understanding and should be considered only as exemplary. Therefore, those of ordinary skill in the art should be aware that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present disclosure. Similarly, for clarity and simplicity, descriptions of well-known functions and structures are omitted in the following description.
As shown in
A user may interact with the server 104 through the network 103 with the terminal devices 101 and 102. The terminal devices 101 and 102 may be provided with clients of online ride-hailing applications or clients that can display online ride-hailing information, especially clients used by passengers in the present application. Other terminal devices may also be provided with clients used by drivers.
The terminal devices 101 and 102 may be a variety of mobile electronic devices, including, but not limited to, smart phones, tablets, laptops, wearable devices, vehicle-mounted terminals, and so on. One online ride-hailing information processing apparatus according to the present application may be arranged and run in the server 104. Another online ride-hailing information processing apparatus according to the present application may be arranged and run in the terminal devices 101 and 102. The apparatus may be implemented as a plurality of software or software modules (for example, to provide distributed services) or as a single software or software module, which is not specifically limited herein.
The server 104 may be a single server or a server group composed of a plurality of servers.
It is to be understood that numbers of the terminal device, the network, and the server in
In existing online ride-hailing services, a user can only select whether to perform ride hailing now after querying for cost information from an origin to a destination, such as a price or a route duration. If the cost is high due to factors such as road conditions, the user may give up ride hailing. However, the road conditions may improve in a short time, and the user may lose an opportunity to improve ride-hailing experience later, which also inhibits the development of the online ride-hailing industry. In some cases, in some ride-hailing peak periods, many users choose to set out now not because of a requirement of a trip, but because of worry about the shortage of transport capacity, so they are anxious to queue up. This will make it more expensive and harder to successfully perform ride hailing in the peak periods. In view of this, the present disclosure provides a new idea, which can recommend an order-sending time for a user, so that the user wanting a reduced cost or not rushing to set out now can choose to send an order later according to the recommended order-sending time. The present disclosure is described in detail below with reference to embodiments.
In 201, an online ride-hailing query condition sent by a client is acquired, the query condition including information of an origin and a destination.
In 202, a query time range is determined according to the query condition.
In 203, cost information of arrival at the destination departing at a plurality of times in the query time range is calculated respectively.
In 204, a time meeting the query condition is determined as a recommended departure time according to the cost information of arrival at the destination departing at the plurality of times.
In 205, a recommended order-sending time is determined according to the recommended departure time.
In 206, a query result is returned to the client, the query result including the recommended order-sending time, or the query result including the recommended order-sending time and cost information corresponding to the recommended order-sending time.
As can be seen from the above technical solution, according to the present disclosure, a recommended order-sending time can be determined in a query time range based on cost information departing at a plurality of times in the query time range, and the recommended order-sending time is returned in a query result or cost information corresponding to the recommended order-sending time is further returned. So, a user can select a low-cost order-sending time according to the recommended order-sending time or in further combination with the cost information. Firstly, the loss of ride-hailing experience due to the high cost of departure at the current time is prevented. Secondly, frequent attempts to query for cost information of ride hailing by the user in a short time are also prevented, and user efficiency and experience are improved. Thirdly, the user's ride-hailing cost is also reduced, and the cost is saved for the user. Fourthly, the problem of unreasonable distribution of transport capacity caused by the concentration of users in ride-hailing peak periods can also be alleviated. Fifthly, the user can acquire a low-cost order-sending time at one time without multiple attempts, saving network resources and reducing the influence on system pressure. Many things can be achieved at one stroke.
The steps in the above embodiment are described in detail below. Firstly, step 201 “acquiring an online ride-hailing query condition sent by a client, the query condition including information of an origin and a destination” is described in detail with reference to embodiments.
The online ride-hailing query condition is from the client, including at least information of an origin and a destination. The information of the origin may be information entered by a user or obtained according to a current location of the client. The information of the destination is generally information entered by the user. The “user” referred to in this embodiment refers to a passenger intended to use online ride hailing.
Furthermore, the query condition in the present disclosure may further include query time range information or further include a cost range.
A query time range is generally a future period of time set by the user, for example, in one hour in the future, in half an hour in the future, in two hours in the future, and so on, which is set according to the user's order-sending requirement. This reflects an acceptable period of time in which the user performs ride hailing. If the user is not anxious about the trip, a longer time range may be set. If the user is anxious about the trip, a shorter time range may be set.
The cost range may be an acceptable ride-hailing cost set by the user. It may be expressed as a price range, such as within 60 RMB. It may also be expressed as a route duration, that is, a time range, for example, within 40 minutes, and so on.
Specific functions of the query time range information and the cost range may be reflected in the following steps.
Step 202 “determining a query time range according to the query condition” is described in detail below with reference to embodiments.
If the query condition includes a query time range set by the user, in this step, the query time range set by the user is directly adopted. That is, the query time range is determined from the query condition.
If the query condition includes no user-set query time range, in this step, a default query time range may be adopted. For example, one hour in the future is set as the query time range by default.
Step 203 “calculating cost information of arrival at the destination departing at a plurality of times in the query time range respectively” is described in detail below with reference to embodiments.
In the present disclosure, a plurality of times may be selected in the query time range according to preset granularity. The granularity may be a set fixed value, or granularity corresponding to a length of the query time range. For example, if the query time range set by the user is half an hour, the granularity is 1 minute. If the query time range set by the user is 24 hours, the granularity is 10 minute.
As one implementation, the following processing may be performed for each of the plurality of times in the query time range, so as to obtain cost information of arrival at the destination departing at each time.
For time ti, a route is planned from the origin to the destination based on a road condition estimation result at the time ti, estimated duration information of arrival at the destination departing at the time ti is obtained as the cost information of arrival at the destination departing at the time ti.
That is, firstly, a route from the origin to the destination is planned, road conditions at the time ti may be predicted in conjunction with a road condition prediction method during the route planning, the route is planned based on a road condition prediction result, and an estimated duration of arrival at the destination departing at the time ti is obtained. The route planning and the road condition prediction method may be performed in any practicable manner, which is not limited in the present disclosure.
As another implementation, the following processing may be performed for each of the plurality of times in the query time range, so as to obtain cost information of arrival at the destination departing at each time.
For time ti, a route is planned from the origin to the destination based on a road condition estimation result at the time ti to obtain a route length and an estimated duration of arrival at the destination departing at the time ti, a price is calculated using an online ride-hailing pricing rule, and the price calculated is taken as the cost information of arrival at the destination departing at this time.
The online ride-hailing pricing rule is generally relatively fixed, taking into account the interests of drivers, passengers and enterprises. Different regions or online ride-hailing platforms may have some differences, and specific pricing rules may be pre-acquired from the online ride-hailing platforms and recorded.
The online ride-hailing pricing rule is mostly composed of three aspects: a starting price, mileage and a duration. Generally, the starting price includes specific mileage and a duration, such as 3 km and 10 minutes. When the driving mileage exceeds 3 km, accumulation is performed at a fixed rate per kilometer. When the driving duration exceeds 10 minutes, accumulation is performed at a fixed rate per minute. A final sum is the calculated price. A driving duration is related to a road condition, and the road condition varies at different times, so the price for the same starting point and destination may vary at different times. The specific content of the online ride-hailing pricing rule is not limited in the present application, which is only illustrated herein for ease of understanding.
Step 204 “determining, according to the cost information of arrival at the destination departing at the plurality of times, a time meeting the query condition as a recommended departure time” is described in detail below with reference to embodiments.
In this step, if the query condition includes a query time range set by the user, N times corresponding to minimum costs in the query time range may be used as recommended departure times.
In the above step, the cost information corresponding to each time in the query time range are determined, so the time(s) with relatively low cost(s) may be preferably used as the recommended departure time(s). N may be a preset positive integer.
If the query condition includes a price range set by the user, a time corresponding to a cost in line with the cost range set by the user in the query time range may be used as the recommended departure time. For example, if the user sets a price range within 40 RMB, a time/times corresponding to a price/prices below 40 RMB may be selected from the plurality of times.
It is to be noted that one or more recommended departure times may be determined in this step.
The steps in the above embodiment are described in detail below. Firstly, step 205 “determining a recommended order-sending time according to the recommended departure time” is described in detail below with reference to embodiments.
The recommended departure time refers to an actual departure time recommended to the user, that is, a departure time from a starting point of a route. However, for the user, an order-sending time is more intuitive and desirable. Therefore, there is a need to determine the recommended order-sending time.
As one implementation, a specific implementation process of this step may include the following steps.
In step S1, an online ride-hailing pickup duration is estimated according to the recommended departure time, to obtain an estimated order-receiving time.
In step S2, an order-receiving time is estimated according to the estimated order-receiving time, to obtain the recommended order-sending time.
Between a user's sending an order and departure from a starting point of a route, there is a process of an online ride-hailing driver's receiving the order and picking up the user. The so-called “an online ride-hailing driver's receiving the order” refers to a process in which an online ride-hailing platform delivers a user's order to a matched online ride-hailing driver after the user sends the order, and the online ride-hailing driver takes the order. The so-called “picking up the user” refers to a process in which the online ride-hailing driver arrives at the passenger's location from the location of the driver after taking the order.
In step S1, the estimated order-receiving time is obtained by reversely deducing a required pickup time according to the recommended departure time. As shown in
In step 301, a first duration which is preset initially is acquired.
The first duration initially preset may be a preset time unit, for example, 1 minute.
In step 302, a time earlier than the recommended departure time by the first duration is determined as a candidate order-receiving time.
Assuming that the recommended departure time is expressed as Td and the time earlier than the recommended departure time by the first duration is expressed as Td-n, then the candidate order-receiving time is Td-n.
In step 303, a pickup duration required at the candidate order-receiving time is estimated.
In this step, when the pickup duration (expressed as Tpickup) required by the candidate order-receiving time Td-n, is estimated, a pickup duration estimation model may be used. Specific implementation will be described in detail in the following.
In step 304, it is judged whether the estimated pickup duration is less than or equal to the first duration. If yes, step 305 is performed. Otherwise, step 306 is performed.
It is judged whether Tpickup is less than or equal to the first duration. That is, it is judged whether Td-n+Tpickup≤Td.
In step 305, the candidate order-receiving time is determined as the estimated order-receiving time, and the current estimation process is ended.
In this case, the current Td-n is the estimated order-receiving time Tt.
In step 306, the first duration is extended, and return to step 302.
In this case, the first duration may be extended, for example, by 1 minute, the first duration becomes 2 minutes, and step 302 is performed. In this case, Td-n is the time earlier than Td by 2 minutes. By analogy, the above steps are performed until the estimated order-receiving time is determined.
In step S2, the order-receiving time is reversely deduced according to the estimated order-receiving time, so as to obtain the recommended order-sending time.
A specific process includes the following steps as shown in
In step 401, a second duration which is initially preset is acquired.
Similar to the first duration, the second duration initially preset may be a preset time unit, for example, 1 minute.
In step 402, a time earlier than the estimated order-receiving time by the second duration is determined as a candidate order-sending time.
The estimated order-receiving time is Tt, and the time earlier than the estimated order-receiving time by the second duration is expressed as Tt-m; in this case, the candidate order-sending time is Tt-m.
In step 403, an order-receiving duration required at the candidate order-sending time is estimated.
In this step, when the order-receiving duration (expressed as Torder) required by the candidate order-sending time Tt-m is estimated, an order-receiving duration estimation model may be used. Specific implementation will be described in detail in the following.
In step 404, it is judged whether the estimated order-receiving duration is less than or equal to the second duration. If yes, step 405 is performed. Otherwise, step 406 is performed.
It is judged whether Torder is less than or equal to the second duration. That is, it is judged whether Tt-m+Torder≤Tt.
In step 405, the candidate order-sending time is determined as the recommended order-sending time, and the current estimation process is ended.
In this case, the current Tt-m is the recommended order-sending time Tc.
In step 406, the second duration is extended, and return to step 402.
In this case, the second duration may be extended, for example, by 1 minute, the second duration becomes 2 minutes, and step 402 is performed. In this case, Tt-m is the time earlier than Tt by 2 minutes. By analogy, the above steps are performed until the recommended order-sending time is determined.
The pickup duration estimation model and the order-receiving duration estimation model are described in detail below with reference to embodiments.
The pickup duration estimation model may be a regression model. When the candidate order-receiving time Td-n is inputted into the model, the model can output a corresponding pickup duration Tpickup.
As an exemplary implementation, the pickup duration estimation model may have a structure as shown in
In addition to the candidate order-receiving time Td-n, the features inputted to the pickup duration estimation model further include at least one of a user's position, a destination, cost information of the recommended departure time, a route length, weather information, and road condition information. For example, all such information is included in
The order-receiving duration estimation model may also be a regression model. When the candidate order-sending time Tt-m is inputted into the model, the model can output a corresponding order-receiving duration Torder.
As an exemplary implementation, the order-receiving duration estimation model may have a structure as shown in
In addition to the candidate order-sending time Tt-m, the features inputted to the order-receiving duration estimation model further include at least one of a user's position, a destination, cost information of the recommended departure time, a route length, or weather information. For example, all such information is included in
In the pickup duration estimation model and the order-receiving duration estimation model, when the user's position and destination are embedded, the features used may be POI information. The POI information may include a POI name, attributes, coordinate information, and the like. The embedding is actually a semantic representation of the POI information. The POI name may have characteristics of POI heat and functions, so the POI name may be word-segmented and then vectorized. The POI attribute information mainly adopts categories, such as public transit hubs and residential areas, etc., which may be represented by discrete numerical values. The attribute information describes spatial heat information, so the whole region may be divided into grids and then serialized and numbered, and the numbers of the grids where coordinates are located may be represented as features.
Time features such as the recommended departure time and the candidate order-sending time may be represented by continuous values. For example, a specific time may include an hour value x, a minute value 12, and a second value z, which may be represented by defining two features
Such a representation may limit a value range to [−1,1].
The time features may also be represented by discrete information such as whether it is a working day or a day of the week.
The price, the estimated duration and the route length are all discrete values, which may be directly inputted into the model after normalization.
Weather features may be represented discretely by onehot to express and distinguish weather such as sunny, cloudy, fog, rain (light rain, moderate rain, heavy rain, rainstorm), and snow (light rain, moderate rain, heavy rain, rainstorm).
Road condition features are introduced into the pickup duration estimation model, because they have a high impact on the pickup duration, and nearby road condition features are not adequately expressed in other features. Road condition features near the user are intended mainly to describe the density of traffic flow within a certain physical range. Therefore, neural networks such as Convolutional Neural Networks (CNNs) and Graph Convolutional Neural Networks (GCNs) may be adopted for encoding. For example, a preset range may be extended outward with the user's location as a central area, for example, by 2 km, to obtain a square area of 4 km*4 km, and then this area is divided into 16 small areas of 1 km*1 km. A traffic flow feature in the area may be represented by an average value of a road congestion coefficient weighted a road length, for example,
where lx denotes the traffic flow feature in the area, li denotes a road length in an ith small area, and ji denotes a congestion coefficient of the ith small area.
When the pickup duration estimation model is pre-trained, training data used may be acquired from a log of the online ride-hailing platform. A duration from a driver's receiving an order to a passenger's getting on, that is, a pickup duration, is recorded on the online ride-hailing platform. The regression model is trained by extracting the passenger's position, destination, price, route length, weather information, road condition information and the driver's order-receiving time from such data as input and using an actual pickup duration as target output, to obtain the pickup duration estimation model. That is, when a loss is designed, an absolute value of a difference between the output of the pickup duration estimation model and the actual pickup duration is minimized.
When the order-receiving duration estimation model is pre-trained, the training data used may also be acquired from a log of the online ride-hailing platform. A duration from a passenger's sending an order to a driver's receiving the order, that is, an order-receiving duration, is recorded on the online ride-hailing platform. The regression model is trained by extracting the passenger's position, destination, price, route length, weather information and the passenger's order-sending time from such data as input and using an actual order-receiving duration as target output, to obtain the order-receiving duration estimation model. That is, when the loss is designed, an absolute value of a difference between the output of the order-receiving duration estimation model and the actual order-receiving duration is minimized.
The pickup duration estimation model and the order-receiving duration estimation model may be trained respectively or trained by multi-task learning.
In the case of the training by multi-task learning, as shown in
In 801, an online ride-hailing query condition entered by a user is acquired, the query condition including information of an origin and a destination.
In the embodiment of the present disclosure, the client may be a client of an online ride-hailing application or a client integrating other applications of online ride-hailing functions, for example, a client integrating map applications of online ride-hailing functions.
The client may provide a first interface for the user to allow the user to enter information of an origin and a destination for ride hailing.
Furthermore, a component to set a query time range or cost range may also be provided for the user. For example, an input box may be provided on the first interface to allow the user to enter a query time range or cost range. In another example, an option such as a drop-down box may be provided on the first interface to allow the user to choose to enter a query time range or cost range. The cost range may be a price range or a duration range of a route (i.e., a ride-hailing trip).
In 802, the query condition is sent to a server, and a query result returned by the server is acquired, the query result including a recommended order-sending time, or the query result including a recommended order-sending time and cost information corresponding to the recommended order-sending time.
After the client sends the query condition to the server, the server performs the process in the embodiment shown in
The cost information corresponding to the recommended order-sending time may include estimated duration information of arrival at the destination departing at the recommended order-sending time, or price information of arrival at the destination departing at the recommended order-sending time.
In 803, the query result is displayed.
The client may provide a second interface for the user, and display the query result on the second interface. At least a recommended order-sending time is is displayed on the second interface. One or more recommended order-sending times may be provided. When the recommended order-sending time is displayed, only the recommended order-sending time or various times in the query time range may be displayed, but the recommended order-sending time is highlighted.
Cost information corresponding to the recommended order-sending time may be displayed while the recommended order-sending time is displayed. Only one type of cost information or more types of cost information may be provided for the user to select.
Furthermore, a component to set a departure time may be displayed on the second interface, for example, the component to “set a departure time” shown in
Furthermore, a component to appoint order sending may be displayed on the second interface, for example, the component to “appoint ride hailing” shown in
The above is a detailed description about the method according to the present is disclosure. The following is a detailed description about the apparatus according to the present disclosure with reference to embodiments.
The condition receiving unit 1010 is configured to acquire an online ride-hailing query condition sent by a client, the query condition including information of an origin and a destination.
The time range determination unit 1020 is configured to determine a query time range according to the query condition.
The cost calculation unit 1030 is configured to calculate cost information of arrival at the destination departing at a plurality of times in the query time range respectively.
The first recommendation unit 1040 is configured to determine, according to the cost information of arrival at the destination departing at the plurality of times, a time meeting the query condition as a recommended departure time.
The second recommendation unit 1050 is configured to determine a recommended order-sending time according to the recommended departure time.
The result return unit 1060 is configured to return a query result to the client, the query result including the recommended order-sending time, or the query result including the recommended order-sending time and cost information corresponding to the recommended order-sending time.
As one implementation, the query condition further includes a query time range, and the first recommendation unit 1040 is specifically configured to use N times corresponding to minimum costs in the query time range as recommended departure is times, N being a preset positive integer.
As another implementation, the query condition further includes a cost range, and the first recommendation unit 1040 is specifically configured to use a time corresponding to a cost in line with the cost range set by a user in the query time range as the recommended departure time.
The time range determination unit 1020 is specifically configured to adopt the query time range set by a user if the query condition includes the query time range set by the user; otherwise, adopt a default query time range.
The cost calculation unit 1030 is specifically configured to perform the following operations for each time of the plurality of times:
Specifically, the second recommendation unit 1050 may include: a first estimation subunit 1051 and a second estimation subunit 1052.
The first estimation subunit 1051 is configured to estimate an online ride-hailing pickup duration according to the recommended departure time, to obtain an estimated order-receiving time.
The second estimation subunit 1052 is configured to estimate an order-receiving time according to the estimated order-receiving time, to obtain the recommended order-sending time.
The first estimation subunit 1051 is specifically configured to:
As an exemplary implementation, when estimating the pickup duration required at the candidate order-receiving time, the first estimation subunit 1051 is specifically configured to input the candidate order-receiving time and at least one of a user's position, a destination, the cost information, a route length, weather information, or road condition information to a pickup duration estimation model to obtain the pickup duration required at the candidate order-receiving time.
The second estimation subunit 1052 is specifically configured to:
As an exemplary implementation, when estimating the order-receiving duration required at the candidate order-sending time, the second estimation subunit 1052 is specifically configured to input the candidate order-sending time and at least one of a user's position, a destination, the cost information, a route length, or weather information to an order-receiving duration estimation model to obtain the order-receiving duration required at the candidate order-sending time.
The condition acquisition unit 1101 is configured to acquire an online ride-hailing query condition entered by a user, the query condition including information of an origin and a destination.
The server interaction unit 1102 is configured to send the query condition to a server, and acquire a query result returned by the server, the query result including a recommended order-sending time, or the query result including a recommended order-sending time and cost information corresponding to the recommended order-sending time.
The result display unit 1103 is configured to display the query result.
The cost information corresponding to the recommended order-sending time may include estimated duration information of arrival at the destination departing at this time, or price information of arrival at the destination departing at this time.
Furthermore, the result display unit 1103 may also be configured to display a component to set a departure time on an interface.
The first component response unit 1104 is configured to record the departure time set by the user after an event that the component is triggered is acquired; and display a reminder message to the user through the result display unit 1103 when the departure time set by the user arrives or at a time earlier than the departure time set by the user by a preset duration.
Furthermore, the result display unit 1103 is further configured to display a component to appoint order sending on the interface.
The second component response unit 1105 is configured to record a order-sending time set by the user after an event that the component is triggered is is acquired; and send an online ride-hailing order from the origin to the destination through the server interaction unit 1102 when the order-sending time set by the user arrives.
Various embodiments in the specification are described progressively. Same and similar parts among the embodiments may be referred to one another, and each embodiment focuses on differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description thereof is relatively simple. Related parts may be obtained with reference to the corresponding description in the method embodiments.
According to embodiments of the present disclosure, the present disclosure further provides an electronic device, a readable storage medium and a computer program product.
As shown in
A plurality of components in the device 1200 are connected to the I/O interface 1205, including an input unit 1206, such as a keyboard and a mouse; an output unit 1207, such as various displays and speakers; a storage unit 1208, such as disks and discs; and a communication unit 1209, such as a network card, a modem and a wireless communication transceiver. The communication unit 1209 allows the device 1200 to exchange information/data with other devices over computer networks such as the Internet and/or various telecommunications networks.
The computing unit 1201 may be a variety of general-purpose and/or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1201 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various artificial intelligence (AI) computing chips, various computing units that run machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller or microcontroller, etc. The computing unit 1201 performs the methods and processing described above, such as the online ride-hailing information processing method. For example, in some embodiments, the online ride-hailing information processing method may be implemented as a computer software program that is tangibly embodied in a machine-readable medium, such as the storage unit 1208.
In some embodiments, part or all of a computer program may be loaded and/or installed on the device 1200 via the ROM 1202 and/or the communication unit 1209. One or more steps of the online ride-hailing information processing method described above may be performed when the computer program is loaded into the RAM 1203 and executed by the computing unit 1201. Alternatively, in other embodiments, the computing unit 1201 may be configured to perform the online ride-hailing information processing method by any other appropriate means (for example, by means of firmware).
Various implementations of the systems and technologies disclosed herein can be realized in a digital electronic circuit system, an integrated circuit system, a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system on chip (SOC), a complex programmable logic device (CPLD), computer hardware, firmware, software, and/or combinations thereof. Such implementations may include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which can be special or general purpose, configured to receive data and instructions from a storage system, at least one input device, and at least one output device, and to transmit data and instructions to the storage system, the at least one input device, and the at least one output device.
Program codes configured to implement the methods in the present disclosure may be written in any combination of one or more programming languages. Such program codes may be supplied to a processor or controller of a general-purpose computer, a special-purpose computer, or another programmable data processing device to enable the function/operation specified in the flowchart and/or block diagram to be implemented when the program codes are executed by the processor or controller. The program codes may be executed entirely on a machine, partially on a machine, partially on a machine and partially on a remote machine as a stand-alone package, or entirely on a remote machine or a server.
In the context of the present disclosure, machine-readable media may be tangible media which may include or store programs for use by or in conjunction with an instruction execution system, apparatus or device. The machine-readable media may be machine-readable signal media or machine-readable storage media. The machine-readable media may include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses or devices, or any suitable combinations thereof. More specific examples of machine-readable storage media may include electrical connections based on one or more wires, a portable computer disk, a hard disk, an RAM, an ROM, an erasable programmable read only memory (EPROM or flash memory), an optical fiber, a compact disk read only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.
To provide interaction with a user, the systems and technologies described here is can be implemented on a computer. The computer has: a display device (e.g., a cathode-ray tube (CRT) or a liquid crystal display (LCD) monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or trackball) through which the user may provide input for the computer. Other kinds of devices may also be configured to provide interaction with the user. For example, a feedback provided for the user may be any form of sensory feedback (e.g., visual, auditory, or tactile feedback); and input from the user may be received in any form (including sound input, voice input, or tactile input).
The systems and technologies described herein can be implemented in a computing system including background components (e.g., as a data server), or a computing system including middleware components (e.g., an application server), or a computing system including front-end components (e.g., a user computer with a graphical user interface or web browser through which the user can interact with the implementation schema of the systems and technologies described here), or a computing system including any combination of such background components, middleware components or front-end components. The components of the system can be connected to each other through any form or medium of digital data communication (e.g., a communication network). Examples of the communication network include: a local area network (LAN), a wide area network (WAN) and the Internet.
The computer system may include a client and a server. The client and the server are generally far away from each other and generally interact via the communication network. A relationship between the client and the server is generated through computer programs that run on a corresponding computer and have a client-server relationship with each other. The server may be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system to solve the problems of difficult management and weak business scalability in the traditional physical host and a virtual private server (VPS). The server may also be a distributed system server, or a server combined with blockchain.
It should be understood that the steps can be reordered, added, or deleted using the various forms of processes shown above. For example, the steps described in the present application may be executed in parallel or sequentially or in different sequences, provided that desired results of the technical solutions disclosed in the present disclosure are achieved, which is not limited herein.
The above specific implementations do not limit the protection scope of the present disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and replacements can be made according to design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principle of the present disclosure all should be included in the protection scope of the present disclosure.
| Number | Date | Country | Kind |
|---|---|---|---|
| 202110633451.9 | Jun 2021 | CN | national |
This application is a national application and, pursuant to 35 U.S.C. § 371, is entitled to and claims the right of priority based on PCT Application No. PCT/CN2021/131178, filed on Nov. 17, 2021, which claims priority to Chinese Patent Application No. 202110633451.9, filed on Jun. 7, 2021, and entitled “ONLINE RIDE-HAILING INFORMATION PROCESSING METHOD AND APPARATUS, DEVICE, AND COMPUTER STORAGE MEDIUM”, which are hereby incorporated by reference in their entireties.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/CN2021/131178 | 11/17/2021 | WO |
