CN110956524A - Service information pushing method and device, electronic equipment and computer storage medium - Google Patents

Service information pushing method and device, electronic equipment and computer storage medium Download PDF

Info

Publication number
CN110956524A
CN110956524A CN201811135229.0A CN201811135229A CN110956524A CN 110956524 A CN110956524 A CN 110956524A CN 201811135229 A CN201811135229 A CN 201811135229A CN 110956524 A CN110956524 A CN 110956524A
Authority
CN
China
Prior art keywords
service type
service
information
order
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201811135229.0A
Other languages
Chinese (zh)
Inventor
杨宝通
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Didi Infinity Technology and Development Co Ltd
Original Assignee
Beijing Didi Infinity Technology and Development Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Didi Infinity Technology and Development Co Ltd filed Critical Beijing Didi Infinity Technology and Development Co Ltd
Priority to CN201811135229.0A priority Critical patent/CN110956524A/en
Publication of CN110956524A publication Critical patent/CN110956524A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635—Processing of requisition or of purchase orders
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Primary Health Care (AREA)
  • Tourism & Hospitality (AREA)
  • Traffic Control Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

The application provides a service information pushing method, a service information pushing device, electronic equipment and a computer storage medium, wherein the method comprises the following steps: receiving a travel order corresponding to a first service type sent by a user side; in the process of matching the driver end of the first service type with the user end, judging whether a driver end of a second service type can take an order or not according to the departure place information and the destination information in the travel order; and if the driver end with the second service type can take the order, pushing service information corresponding to the second service type to the user end. According to the embodiment of the application, after the user side initiates the travel order aiming at a certain service type, the service information of other service types capable of meeting the travel requirement of the user can be pushed to the user side in the service waiting process of the user, so that the service efficiency is improved.

Description

Service information pushing method and device, electronic equipment and computer storage medium
Technical Field
The present application relates to the field of data processing technologies, and in particular, to a service information pushing method and apparatus, an electronic device, and a computer storage medium.
Background
With the popularization of vehicles, the use of car calling software for calling cars is more and more popular. The taxi calling software is a smart phone application, passengers can submit orders through the taxi calling software, and a driver can send and receive the passengers according to the positions set by the passengers through the orders submitted by the passengers, so that the taxi calling efficiency is greatly improved, the communication cost between the driver and the passengers is saved, the empty driving rate is reduced, and the resources and time of the driver and the passenger are saved to the maximum extent. Therefore, taxi calling software is gradually becoming popular.
At present, when passengers use the car calling software to call cars in a car calling peak period, the phenomenon of car calling queuing can occur due to more passengers calling the cars, and particularly in some road sections with traffic jam, the waiting time of the passengers can be longer.
Disclosure of Invention
In view of the above, an object of the present invention is to provide a method and an apparatus for pushing service information, an electronic device, and a computer storage medium, so as to improve service efficiency.
In a first aspect, an embodiment of the present application provides a service information pushing method, where the method includes:
receiving a travel order corresponding to a first service type sent by a user side;
in the process of matching the driver end of the first service type with the user end, judging whether a driver end of a second service type can take an order or not according to the departure place information and the destination information in the travel order;
and if the driver end with the second service type can take the order, pushing service information corresponding to the second service type to the user end.
In combination with the first aspect, the present examples provide a first possible implementation manner of the first aspect, where,
the first service type is a non-car-sharing car-calling service type, and the second service type is a car-sharing car-calling service type.
In combination with the first possible implementation manner of the first aspect, the present application provides a second possible implementation manner of the first aspect, wherein,
if the driver end with the second service type can take orders, pushing service information corresponding to the second service type to the user end, wherein the service information comprises:
and if the driver end with the second service type can take orders and the travel order currently meets the preset order splicing prompt condition, pushing service information corresponding to the second service type to the user end.
In combination with the second possible implementation manner of the first aspect, the present application provides a third possible implementation manner of the first aspect, wherein,
the order-matching prompt condition comprises one or more of the following conditions:
the current taxi calling ranking of the travel order is behind a preset ranking;
the predicted order receiving time of a driver end of the first service type corresponding to the travel order is larger than the preset time;
the user side does not select the taxi calling service of other service types.
In combination with the first possible implementation manner of the first aspect, the present application provides a fourth possible implementation manner of the first aspect, wherein,
judging whether a carpool order which is in the same way as the travel order exists in carpool orders which are served by each driver side or not according to the departure place information and the destination information in the travel order;
and if the carpooling order which is in the same way as the travel order exists, determining that the driver end with the second service type can take the order.
In combination with the fourth possible implementation manner of the first aspect, the present application provides a fifth possible implementation manner of the first aspect, wherein,
judging whether a car sharing order which is in the same way as the travel order exists in car sharing orders which are served by each driver side, wherein the judgment comprises the following steps:
and judging whether the car sharing orders which are in the same way as the travel orders and can be picked up within a preset time length exist in the car sharing orders which are served by each driver.
In combination with the fourth possible implementation manner or the fifth possible implementation manner of the first aspect, the present application provides a sixth possible implementation manner of the first aspect, wherein,
the step of judging whether a car sharing order which is in the same way as the travel order exists in car sharing orders which are served by each driver side according to the departure place information and the destination information in the travel order comprises the following steps:
determining a travel route from the departure place information to the destination information;
searching for a travel order of which the forward degree with the travel route is greater than a preset forward degree threshold value in car sharing orders which are served by each driver;
and if the ride share order with the travel route is found to be larger than the preset ride share threshold value, determining that the ride share order in the same way as the travel order currently exists.
With reference to the sixth possible implementation manner or the fifth possible implementation manner of the first aspect, this application example provides a seventh possible implementation manner of the first aspect, where,
the pushing the service information corresponding to the second service type to the user side includes:
and pushing the service information carrying the forward road degree to the user side.
In combination with the first aspect, the present application provides an eighth possible implementation manner of the first aspect, where,
after the service information corresponding to the second service type is pushed to the user side, the method further includes:
based on the remaining service resources of the driver end of the second service type capable of receiving orders, locking the remaining service resources for the user end;
and if the response message of receiving the service message of the second service type sent by the user side is not received within the preset locking time, unlocking the locked residual service resources.
In combination with the eighth possible implementation manner of the first aspect, the present application provides a ninth possible implementation manner of the first aspect, wherein,
after the service information corresponding to the second service type is pushed to the user side, the method further includes:
if response information which is sent by the user side and receives the service information of the second service type is received, whether response time corresponding to the response information exceeds the locking time is detected;
and if the response time does not exceed the locking time, distributing the travel order to a driver end of the second service type.
With reference to the ninth possible implementation manner of the first aspect, an embodiment of the present application provides a tenth possible implementation manner of the first aspect, where the method further includes:
and if the response time exceeds the locking time, sending overtime reminding information to the user side.
In combination with the tenth possible implementation manner of the first aspect, the present application provides an eleventh possible implementation manner of the first aspect, wherein,
if the response time exceeds the locking time, sending overtime reminding information to the user side, wherein the overtime reminding information comprises:
detecting whether the driver end of the current second service type can provide services for the user end; and if the user terminal can not be provided with the service, sending overtime reminding information to the user terminal.
In combination with the first aspect, the present examples provide a twelfth possible implementation manner of the first aspect, wherein,
after the pushing the service information corresponding to the second service type to the user side, the method further includes:
and after the user side receives the taxi calling service of the second service type, returning the waiting driving page information to the user side, wherein the waiting driving page information carries driver side information of the second service type of the order.
In combination with the first aspect, the present application provides a thirteenth possible implementation manner of the first aspect, where,
after the service information corresponding to the second service type is pushed to the user side, the method further includes:
and if response information which is sent by the user side and refuses to accept the service information of the second service type is received, the service information corresponding to the second service type is not pushed to the user side within preset silent time.
In combination with the first aspect, the present application provides a fourteenth possible implementation manner of the first aspect, wherein,
after receiving the travel order corresponding to the first service type sent by the user side, the method further includes:
sending first waiting response page information corresponding to the first service type to the user side, wherein the first waiting response page information carries prompt information for selecting a second service type simultaneously;
and if the user side confirms that the second service type is selected at the same time, returning second waiting reply page information corresponding to the second service type to the user side.
In a second aspect, an embodiment of the present application further provides a service information pushing method, where the method includes:
sending a travel order corresponding to the first service type to a server;
receiving service information of a second service type pushed by the server based on the departure place information and the destination information in the travel order in the process of waiting for the driver of the first service type to pick up the order;
and displaying the service information of the second service type to prompt a user to confirm whether to accept the service of the second service type.
With reference to the second aspect, an embodiment of the present application provides a first possible implementation manner of the second aspect, where the service information carries forward route degree information.
With reference to the second aspect, embodiments of the present application provide a second possible implementation manner of the second aspect, where the method further includes:
and if the response information of the service of the second service type is received back to the server after the preset locking time is exceeded, receiving the overtime reminding information fed back by the server.
In combination with the second aspect, the present examples provide a third possible implementation manner of the second aspect, wherein,
after the service information of the second service type is displayed, the method further includes:
and after the feedback that the user receives the service of the second service type is fed back to the server, receiving the page information of waiting for pickup returned by the server, wherein the page information of waiting for pickup carries driver end information of the second service type of pickup.
In combination with the second aspect, the present examples provide a fourth possible implementation manner of the second aspect, wherein,
after the travel order corresponding to the first service type is sent to the server, the method further comprises the following steps:
receiving first waiting response page information corresponding to the first service type fed back by the server, wherein the first waiting response page information carries prompt information for selecting a second service type simultaneously;
and after the user confirms that the second service type is selected at the same time, receiving second waiting response page information corresponding to the second service type returned by the server.
In a third aspect, an embodiment of the present application further provides a service information pushing apparatus, where the apparatus includes: the device comprises a receiving module, a judging module and a pushing module; wherein the content of the first and second substances,
the receiving module is used for receiving the travel order corresponding to the first service type and sent by the user side;
the judging module is used for judging whether a driver end with a second service type can take an order or not according to the departure place information and the destination information in the travel order in the process of matching the driver end with the first service type for the user end;
the pushing module is used for pushing service information corresponding to the second service type to the user side if the driver side with the second service type can take orders.
With reference to the third aspect, embodiments of the present application provide a first possible implementation manner of the third aspect, where:
the first service type is a non-car-sharing car-calling service type, and the second service type is a car-sharing car-calling service type.
In combination with the first possible implementation manner of the third aspect, the present application provides a second possible implementation manner of the third aspect, wherein,
the pushing module is specifically configured to push service information corresponding to the second service type to the user side according to the following steps:
and if the driver end with the second service type can take orders and the travel order currently meets the preset order splicing prompt condition, pushing service information corresponding to the second service type to the user end.
In combination with the second possible implementation manner of the third aspect, the present application provides a third possible implementation manner of the third aspect, wherein,
the order-matching prompt condition comprises one or more of the following conditions:
the current taxi calling ranking of the travel order is behind a preset ranking;
the predicted order receiving time of a driver end of the first service type corresponding to the travel order is larger than the preset time;
the user side does not select the taxi calling service of other service types.
In combination with the first possible implementation manner of the third aspect, the present application provides a fourth possible implementation manner of the third aspect, wherein,
the judging module is specifically used for judging whether a driver end with a second service type can take an order according to the following steps:
judging whether a carpool order which is in the same way as the travel order exists in carpool orders which are served by each driver side or not according to the departure place information and the destination information in the travel order;
and if the carpooling order which is in the same way as the travel order exists, determining that the driver end with the second service type can take the order.
In combination with the fourth possible implementation manner of the third aspect, the present application provides a fifth possible implementation manner of the third aspect, wherein,
the judging module is specifically configured to judge whether a car pooling order in front of the travel order exists in car pooling orders served by each driver:
and judging whether the car sharing orders which are in the same way as the travel orders and can be picked up within a preset time length exist in the car sharing orders which are served by each driver.
With reference to the fourth possible implementation manner or the fifth possible implementation manner of the third aspect, the present application provides a sixth possible implementation manner of the third aspect, where,
the judging module is specifically configured to judge whether a car pooling order in front of the travel order exists in car pooling orders served by each driver:
determining a travel route from the departure place information to the destination information;
searching for a travel order of which the forward degree with the travel route is greater than a preset forward degree threshold value in car sharing orders which are served by each driver;
and if the ride share order with the travel route is found to be larger than the preset ride share threshold value, determining that the ride share order in the same way as the travel order currently exists.
In combination with the sixth possible implementation manner of the third aspect, the present application provides a seventh possible implementation manner of the third aspect, wherein,
the pushing module is specifically configured to push service information corresponding to the second service type to the user side according to the following steps:
and pushing the service information carrying the forward road degree to the user side.
In combination with the third aspect, the present application provides an eighth possible implementation manner of the third aspect, where,
the device further comprises a locking module, a receiving module and a processing module, wherein the locking module is used for locking the residual service resources for the user side based on the residual service resources of the driver side of the second service type capable of receiving orders; and if the response message of receiving the service message of the second service type sent by the user side is not received within the preset locking time, unlocking the locked residual service resources.
In combination with the eighth possible implementation manner of the third aspect, the present application provides a ninth possible implementation manner of the third aspect, wherein,
the device further comprises: the processing module is used for detecting whether response time corresponding to the response information exceeds the locking time or not if the response information which is sent by the user side and used for receiving the service information of the second service type is received; and if the response time does not exceed the locking time, distributing the travel order to a driver end of the second service type.
In combination with the ninth possible implementation manner of the third aspect, the present application provides a tenth possible implementation manner of the third aspect, where,
and the processing module is further used for sending overtime reminding information to the user side if the response time exceeds the locking time.
In combination with the tenth possible implementation manner of the third aspect, the present application provides an eleventh possible implementation manner of the third aspect, wherein,
the processing module is specifically configured to send timeout reminding information to the user side according to the following steps:
detecting whether the driver end of the current second service type can provide services for the user end; and if the user terminal can not be provided with the service, sending overtime reminding information to the user terminal.
In combination with the third aspect, the present application provides a twelfth possible implementation manner of the third aspect, wherein,
the pushing module is further configured to return to the user side page information of waiting for pickup after the user side receives the taxi calling service of the second service type, where the page information of waiting for pickup carries driver side information of the second service type of pickup.
In combination with the third aspect, the present application provides a thirteenth possible implementation manner of the third aspect, where,
the pushing module is further configured to, if response information sent by the user side and rejecting accepting of the service information of the second service type is received, no longer push the service information corresponding to the second service type to the user side within a preset silent time.
In combination with the third aspect, the present application provides a fourteenth possible implementation manner of the third aspect, where,
the pushing module is further configured to send first waiting response page information corresponding to the first service type to the user side, where the first waiting response page information carries prompt information for selecting a second service type at the same time; and if the user side confirms that the second service type is selected at the same time, returning second waiting reply page information corresponding to the second service type to the user side.
In a fourth aspect, an embodiment of the present application further provides a service information pushing apparatus, where the apparatus includes: the device comprises a sending module, a receiving module and a display module; wherein the content of the first and second substances,
the sending module is used for sending the travel order corresponding to the first service type to the server;
the receiving module is used for receiving service information of a second service type pushed by the server based on the departure place information and the destination information in the travel order in the process of waiting for the driver of the first service type to take an order;
and the display module is used for displaying the service information of the second service type so as to prompt a user to confirm whether to accept the service of the second service type.
In combination with the fourth aspect, the present application provides a first possible implementation manner of the fourth aspect, wherein,
the service information carries the forward degree information.
In combination with the fourth aspect, the present application provides a second possible implementation manner of the fourth aspect, wherein,
the receiving module is further configured to receive the timeout reminding information fed back by the server if the response information of receiving the service of the second service type is fed back to the server after the preset locking time is exceeded.
In combination with the fourth aspect, the present examples provide a third possible implementation manner of the fourth aspect, wherein,
the receiving module is further configured to receive, after the user receives the service of the second service type and feeds back the service of the second service type to the server, the page information of waiting for pickup returned by the server, where the page information of waiting for pickup carries driver-side information of the second service type of pickup.
In combination with the fourth aspect, the present examples provide a fourth possible implementation manner of the fourth aspect, wherein,
the receiving module is further configured to receive first waiting response page information corresponding to the first service type and fed back by the server, where the first waiting response page information carries prompt information for selecting a second service type at the same time; and after the user confirms that the second service type is selected at the same time, receiving second waiting response page information corresponding to the second service type returned by the server.
In a fifth aspect, an embodiment of the present application further provides an electronic device, including: the service information pushing system comprises a processor, a memory and a bus, wherein the memory stores machine-readable instructions executable by the processor, the processor and the memory are communicated through the bus when an electronic device runs, and the processor executes the machine-readable instructions to realize the steps of the service information pushing method.
In a sixth aspect, the present application further provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the steps of the car pooling prompting method are performed as described above.
The service information pushing method, the service information pushing device, the electronic device and the computer storage medium provided by the embodiment of the application can receive a travel order corresponding to a first service type sent by a user side, can judge whether a driver side with a second service type can receive orders according to departure place information and destination information in the travel order in the process of matching the user side with the driver side with the first service type, and pushes service information corresponding to the second service type to the user side if the driver side with the second service type can receive orders. Therefore, after a user side initiates a trip order aiming at a certain service type, service information of other service types capable of meeting trip requirements of the user can be pushed to the user side in the process that the user waits for service, so that the service efficiency is improved, the trip experience of the user is improved, for example, a car sharing service type capable of timely going out can be pushed for a user waiting for non-car sharing service in a queuing mode in a car taking peak period, the car calling time of the user in the car taking peak period is reduced, and convenience is brought to the user in the trip.
In order to make the aforementioned objects, features and advantages of the present application more comprehensible, preferred embodiments accompanied with figures are described in detail below.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required to be used in the embodiments will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and for those skilled in the art, other related drawings can be obtained from the drawings without inventive effort.
Fig. 1 is a flowchart illustrating a service information pushing method according to an embodiment of the present application;
fig. 2 is a schematic diagram illustrating a display interface of a user end showing a user a prompt carrying a second service type according to an embodiment of the present application;
fig. 3 is a schematic diagram illustrating a display interface provided in an embodiment of the present application and carrying second waiting reply page information corresponding to a second service type;
fig. 4 is a flowchart illustrating a service information pushing process provided in the second embodiment of the present application;
fig. 5 is a flowchart illustrating a process of determining whether a car pool order is available in the same way as a travel order according to a third embodiment of the present application;
fig. 6 is a schematic diagram illustrating a display interface presented by a user end to a user according to service information pushed by a software platform according to a third embodiment of the present application;
fig. 7 is a flowchart illustrating a service information pushing method according to a fourth embodiment of the present application;
fig. 8 is a schematic diagram illustrating a display interface presented by the user end to the user according to the timeout reminding information sent by the software platform according to the fourth embodiment of the present application;
fig. 9 is a flowchart illustrating a service information pushing process provided in a fifth embodiment of the present application;
fig. 10 is a flowchart illustrating a service information pushing process according to a sixth embodiment of the present application;
fig. 11 is a schematic diagram illustrating a service information pushing apparatus according to a seventh embodiment of the present application;
fig. 12 is a schematic diagram illustrating a service information pushing apparatus according to an eighth embodiment of the present application;
fig. 13 is a schematic structural diagram of a server according to a ninth embodiment of the present application;
fig. 14 shows a schematic structural diagram of a terminal device provided in an embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all the embodiments. The components of the embodiments of the present application, generally described and illustrated in the figures herein, can be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the present application, presented in the accompanying drawings, is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments of the application. All other embodiments, which can be derived by a person skilled in the art from the embodiments of the present application without making any creative effort, shall fall within the protection scope of the present application.
The method, the device, the electronic device or the computer storage medium in the embodiment of the present application can be applied to any scene that requires service information pushing to a user side, for example, can be applied to taxi taking software, a trip service system, and the like. The embodiment of the present application does not limit a specific application scenario, and any scheme for pushing service information to a user by using the method provided by the embodiment of the present application is within the protection scope of the present application.
In the embodiment of the application, the travel order corresponding to the first service type sent by the user terminal can be received, in the process of matching the driver end of the first service type for the user end, whether the driver end of the second service type can take orders or not can be judged according to the departure place information and the destination information in the travel order, if the driver end of the second service type can take orders, the service information corresponding to the second service type can be pushed to the user terminal to prompt the user to travel in time by the second service type, therefore, after the user side initiates a travel order aiming at a certain service type, the user can start the trip order in the process of waiting for the service, the service information of other service types capable of satisfying the user travel demand is pushed to the user terminal to improve the service efficiency, for example, the taxi sharing service capable of timely going out can be pushed for the user side waiting for the non-taxi sharing service in line in the taxi taking peak period. The scheme provided by the embodiment of the application can be used for pushing the service of the service type which can meet the travel requirement of the user and is not actively selected by the user for the user side, so that a more efficient travel scheme is provided for the user, and the time for queuing and calling the vehicle for the user is reduced.
For the convenience of understanding the present embodiment, a detailed description is first given of the service information pushing method disclosed in the embodiment of the present application.
The following embodiments a to a fifth specifically describe the scheme of the embodiment of the present application from the perspective of the server of the platform.
Example one
As shown in fig. 1, a method for pushing service information provided in an embodiment of the present application includes:
s101, a trip order corresponding to the first service type sent by the user side is received.
In a specific implementation, a software platform (such as a taxi taking software platform) may receive a travel order corresponding to a first service type sent by a user terminal, and obtain departure place information and destination information set by the user in the travel order. Here, the first service type may be a taxi service type selected by the user, for example, any one of taxi service types such as a taxi, a car pool, a special car (providing a special car pickup service for the user), a vehicle providing a quick travel service (hereinafter, referred to as a express car, i.e., neither a car pool nor a special car pickup), and the like. Specifically, the software platform receives a travel order sent by the user side, and may determine a first service type corresponding to the travel order according to order information of the travel order, where the order information may further include user information, departure place information, destination information, current location information of the user, and the like.
And S102, in the process of matching the driver end of the first service type for the user end, judging whether the driver end of the second service type can take an order or not according to the departure place information and the destination information in the travel order.
In specific implementation, after receiving a travel order corresponding to a first service type sent by a user terminal, a software platform may match a driver terminal of the first service type that may provide a service for the user according to the first service type and departure location information in the travel order. In the process of matching the driver end of the first service type with the user end, the software platform can judge whether the driver end of the second service type can take an order or not according to the departure place information and the destination information in the travel order. When judging whether the order can be received by the driver end with the second service type exists, the driver end with the second service type capable of receiving the order can be searched in a preset distance range from the departure place information, or a travel order matched with the departure place information and the destination information in the travel order corresponding to the first service type sent by the user end can be searched in the travel order which is received by the driver end with the current second service type, and whether the order can be received by the driver end with the second service type exists is judged. The driver end of the second service type capable of receiving orders can comprise: there is currently no driver side of the travel order being served, there is currently a travel order being served but there are remaining service resources that can serve the user, where the remaining service resources may include remaining seats.
Here, the second service type may be a taxi calling service type different from the first service type, and accordingly, the second service type may include any one of taxis, carpools, special cars, express trains, and the like, which is different from the first service type.
S103, if the driver end with the second service type can receive orders, service information corresponding to the second service type is pushed to the user end.
In a specific implementation, in the process of matching the user side with the driver side of the first service type, if it is determined that the driver side of the second service type can receive the order, the software platform may push service information corresponding to the second service type to the user side. Therefore, the user side can display the service information which is pushed by the software platform and corresponds to the second service type to the user, the user can select to take the vehicle of the second service type for going out in time according to the service information, the time for the user to call the vehicle is saved, and the platform service efficiency is improved.
Here, when the service information corresponding to the second service type is pushed to the user side, the service information corresponding to the second service type may be pushed on a software interface of the user side, or the service information corresponding to the second service type may be directly pushed on a current display interface of the user side, so as to prompt that the user can travel at present.
In specific implementation, after the service information corresponding to the second service type is pushed to the user side, if the user side receives the taxi service of the second service type, the page information waiting for taxi pickup can be returned to the user side, and the page information waiting for taxi pickup can carry driver side information of the second service type of the order pickup. And if response information which is sent by the user side and refuses to accept the service information of the second service type is received, no service information corresponding to the second service type is pushed to the user side within the preset silent time.
In specific implementation, after receiving a travel order corresponding to a first service type sent by a user, the platform may send first waiting response page information corresponding to the first service type to the user. In an optional implementation manner, the first waiting response page information may carry prompt information for simultaneously selecting the second service type, so that the user terminal presents a display interface carrying the prompt information of the second service type to the user, as shown in fig. 2, for example, the first service type is a taxi calling service type of express taxi, the second service type is a taxi calling service type of carpooling, and a call key for simultaneously calling the carpooling may be displayed in the display interface presented by the user terminal to the user. The first waiting page information can also carry the taxi calling and ranking of the trip order of the current user end corresponding to the first service type and the estimated order receiving time of the trip order corresponding to the first service type.
And if the user side selects the second service type while confirming the display interface of the first service type, returning second waiting reply page information carrying the second service type to the user side. For example, if the user clicks "call going" at the car sharing location called simultaneously in fig. 2, the user side may display the display interface shown in fig. 3 to the user, fig. 3 shows (1) and (2) two display interfaces carrying second waiting-to-answer page information corresponding to the second service type respectively, the user side may display the second waiting-to-answer page information in the car sharing location called simultaneously in the display interface shown to the user, and meanwhile, the second waiting-to-answer page information may further include ranking of the car sharing and predicted order receiving time. In fig. 3 (1), the second waiting page information carries the taxi calling rank of the express train and the predicted order receiving time of the express train corresponding to the travel order of the current user, and also carries the taxi calling rank of the carpool and the predicted order receiving time of the carpool corresponding to the travel order of the current user. In (2) of fig. 3, the second waiting page information carries the taxi calling ranking of the carpool and the expected order receiving time of the carpool corresponding to the trip order of the current user terminal.
It should be noted that, in the embodiment of the present application, even when the user does not actively select the service of the second service type, the service information of the second service type is actively pushed to the user, and only the second waiting reply page information is not pushed; if the user selects the second service type after initiating the travel request of the first service type, the information of pushing the second waiting reply page can be provided to the user terminal at this time.
By adopting the scheme, in the process of matching the driver end of the first service type with the user end, when the driver end of the second service type can receive orders, the service information corresponding to the second service type is pushed to the user end, so that the problem that the user queues and waits for long time because the service resources of the driver end of the first service type are in short supply and cannot immediately provide service for the user can be avoided; for example, during the peak time of calling, the user pushes the car pooling service capable of going out in time to the user in the process of waiting for the express service, so that the calling pressure during the peak time of calling can be reduced, and the outgoing efficiency of the user is improved.
Example two
In the first embodiment, in the process of matching the driver end of the first service type with the user end, it may be determined whether there is an order that can be accepted by the driver end of the second service type, and under the condition that it is determined that there is an order that can be accepted by the driver end of the second service type, the service information corresponding to the second service type may be pushed to the user end, so as to provide a mode that a user can go out in time.
Based on this, as shown in fig. 4, taking the first service type as a non-car-sharing car-calling service type and the second service type as a car-sharing car-calling service type as an example, the following describes a service information pushing process in this application scenario, including:
s201, receiving a trip order corresponding to the non-carpooling taxi calling service type and sent by the user side.
In specific implementation, the software platform may receive a travel order corresponding to the non-car-sharing car calling service type sent by the user terminal, and obtain departure place information and destination information set by the user in the travel order. Here, the taxi calling service type of the non-carpool may include taxi calling service types such as a taxi, a express car, a special car, and the like. Specifically, for example, the software platform receives a travel order sent by the user end, may obtain a taxi calling service type corresponding to the travel order according to order information of the travel order, and may execute step S201 when determining that the taxi calling service type of the travel order is a non-taxi sharing taxi calling service type.
S202, in the process of matching the driver end of the first service type for the user end, judging whether the carpool order in the path following the travel order exists in the carpool orders which are served by the driver end according to the departure place information and the destination information in the travel order.
In specific implementation, after receiving a travel order corresponding to the non-car-sharing car-calling service type sent by the user side, the software platform can match the travel order with the driver side of the non-car-sharing car-calling service type. In the process of matching the driver end of the non-carpool taxi-calling service type, whether a carpool order following the travel order exists in the carpool orders served by each driver end can be judged according to the departure place information and the destination information in the travel order.
When judging whether the car sharing orders which are in the same way as the travel orders exist in the car sharing orders served by each driver, judging whether the car sharing orders which are in the same way as the travel orders and can be picked up within a preset time length exist in the car sharing orders served by each driver, and thus ensuring that a user can timely travel. Specifically, for example, the software platform may obtain the current car pooling order served by each driver, match the departure location information and the destination information of the car pooling order served by each driver with the departure location information and the destination information in the travel order sent by the user terminal, predict the pickup time for the car pooling vehicle to be picked up according to the current location information of the car pooling vehicle corresponding to each driver terminal and the departure location information in the travel order sent by the user terminal, determine whether the car pooling order which is in the same way as the travel order and can be picked up within a preset time length exists in the car pooling order served by each driver terminal, and determine whether the car pooling order which is in the same way as the travel order exists in the car pooling order served by each driver terminal exists, if the car pooling order which is in the same way as the travel order and the destination information in the travel order match, and the predicted pickup time is within the preset time length, determine whether the car pooling order which is in the same way as the travel order exists in the car pooling order served by each driver terminal exists, And the taxi sharing orders can be picked up within the preset time, otherwise, whether the taxi sharing orders which are in the same way with the travel orders and can be picked up within the preset time exist in the taxi sharing orders which are served by the driver terminals or not is judged.
And S203, if the car sharing order which is in the same way as the travel order exists, determining that the driver end with the second service type can receive the order.
In a specific implementation, if the software platform determines that a carpool order in the same way as the travel order exists, it may be determined that the driver end having the second service type can take the order. Here, the driver end capable of taking orders may be understood as that the driver end currently has remaining service resources or can take orders within a preset time period, where the remaining service resources may be resources, such as remaining idle seats, for the service vehicle corresponding to the driver end to be capable of providing travel services for the user.
And S204, if the driver end with the second service type can take orders and the travel order currently meets the preset order splicing prompt condition, pushing service information corresponding to the second service type to the user end.
In specific implementation, if a driver end with a taxi pooling calling service type can receive an order, whether a travel order currently meets a preset taxi pooling prompt condition can be judged according to order information in the travel order sent by a user. And if the travel order currently meets the preset order-sharing prompt condition, pushing service information of the calling service type corresponding to the car sharing to the user side.
Here, the condition of the order-sharing cue includes one or more of the following conditions:
1) the current taxi calling ranking of the travel order is behind a preset ranking; 2) the predicted order receiving time of a driver end of the first service type corresponding to the travel order is larger than the preset time; 3) the user side does not select the taxi calling service of other service types.
In the condition 1), after the taxi calling ranking of the first service type corresponding to the trip order sent by the user side is in the preset ranking, it indicates that there are more users calling the service vehicle of the first service type currently, and the trip order of the user side needs to perform taxi calling queuing. In condition 2), the expected order receiving time of the travel order sent by the user side at the driver side of the currently corresponding first service type is longer than the preset time, which indicates that the service vehicle of the current first service type is in tension, and the travel order of the user side needs a longer time to be received. In condition 3), the user terminal does not select the car calling service of other service types, which indicates that the user terminal does not select the car calling service of other car calling service types for traveling in the process of waiting for the driver terminating order of the first service type, such as the car calling service of pricing dispatching a distant vehicle or a fast aisle is not selected. And if the driver end with the second service type can receive the order, the software service platform pushes the service information of the taxi calling service type corresponding to the order sharing to the user end when judging that the travel order sent by the user end meets one or more of the order sharing prompt conditions.
EXAMPLE III
In the second embodiment, in the process of matching the driver end of the first service type for the user end, whether a car pool order following the travel order exists in the car pool orders being served by each driver end can be judged according to the departure place information and the destination information in the travel order, so as to determine whether the driver end of the car pool calling service type can receive an order.
As shown in fig. 5, the process of determining whether a car pooling order in front of a travel order exists in car pooling orders served by each driver end according to the embodiment of the present application includes:
and S301, determining a travel route from the departure place information to the destination information.
In specific implementation, the software platform receives a travel order corresponding to the first service type sent by the user terminal, and determines a travel route from the departure information to the destination information according to the departure information and the destination information in the travel order in the process of matching the user terminal with the driver terminal of the first service type. Here, the travel route from the departure place information to the destination information may include a plurality of pieces.
S302, searching for a travel order, the forward degree of which with the travel route is greater than a preset forward degree threshold value, in the car sharing orders which are served by each driver.
In a specific implementation, after determining a travel route from the departure information to the destination information, the software platform may match a carpool travel route corresponding to a carpool order served by each driver with the travel route determined in step S301, and search for a travel order having a degree of following the determined travel route greater than a preset degree of following threshold. Here, when matching the carpool travel route corresponding to the carpool order being served by each driver with the determined travel route, the degree of overlap of the carpool travel route with the determined travel route may be matched, and the degree of overlap may be taken as the degree of following the travel route.
And S303, if the ride share order with the travel route is found to be larger than the preset ride share threshold, determining that the ride share order in the same way as the travel order currently exists.
In a specific implementation, if a car pooling order with a trip degree greater than a preset threshold value of the trip degree is found, it indicates that the car pooling order in line with the trip order exists in the car pooling orders currently served by each driver in the process of matching the user terminal with the driver terminal of the first service type, and the trip service can be immediately provided for the user at the user terminal.
Here, after determining that there is currently a carpool order in-route with the travel order, service information corresponding to the second service type may be pushed to the user terminal. When the service information corresponding to the second service type is pushed to the user side, the service information carrying the in-route degree can be pushed to the user side, a display interface displayed by the user side to the user according to the service information pushed by the software platform can be shown in fig. 6, the display interface can prompt the user that a passenger with an in-route position can be dispatched immediately when passing with the user, the user can also prompt the in-route degree of a car-sharing order and a trip order of the user on the display interface, such as prompt of 'degree 90%', and the user can continue to wait for a driver end-receiving order corresponding to the first service type according to the selection of a reject key on the display interface, or select a passenger corresponding to the car-sharing order in-route with the trip order to trip together according to an agreement key on the display interface.
Example four
In the above implementation, in order to avoid that the service vehicle resource of the first service type selected by the user is in shortage, the user waits for too long time for going out, it may be determined whether there is a driver end of the second service type capable of receiving orders in the process of matching the driver end of the first service type with the user end, and if there is a driver end of the second service type capable of receiving orders, the service information corresponding to the second service type is pushed to the user end, so that a scheme capable of going out in time may be provided to the user of the user end.
After pushing the service information corresponding to the second service type to the user side, the service information pushing method provided in the embodiment of the present application is shown in fig. 7, and includes:
s401, based on the residual service resources of the driver end of the second service type capable of receiving orders, locking the service resources for the user end.
In a specific implementation, after the software platform pushes the service information corresponding to the second service type to the user terminal, the software platform may lock the service resource for the user terminal based on the remaining service resource of the driver terminal of the second service type capable of receiving the order. The remaining service resources may be resources capable of providing travel services for the user, such as remaining seats. For example, the software platform may determine the number of remaining seats existing in the driver's end of the second service type capable of taking orders, may randomly select one or more of the remaining seats to be locked as the current user end, and after the remaining seats are locked, the remaining seats may be reserved for the user end and not be accepted by other user ends for occupying the locked remaining seats.
S402, if the response message of receiving the service message of the second service type sent by the user side is not received within the preset locking time, unlocking the locked residual service resources.
Here, the software platform may lock the remaining service resources of the driver's end of the second service type for a preset locking time. If the response message sent by the user side is not received within the preset locking time, the locked residual service resources can be unlocked for the users of other user sides to select.
S403, if a response message for accepting the service information of the second service type sent by the user end is received, detecting whether a response time corresponding to the response message exceeds a preset locking time.
In a specific implementation, the software platform can lock the remaining service resources of the driver side of the second service type at a preset locking time. And if the software platform receives response information which is sent by the user side and used for receiving the service of the second service type after pushing the service information corresponding to the second service type to the user side, detecting whether the response time corresponding to the response information exceeds the preset locking time.
S404, if the response time does not exceed the locking time, distributing the travel order to a driver end of the second service type.
Here, if the software platform detects that the response time of the user terminal for sending the response information does not exceed the preset locking time, the software platform may directly distribute the travel order sent by the user terminal to the driver terminal of the second service type, and may return the information of the waiting driving page to the user terminal.
S405, if the response time exceeds the locking time, sending overtime reminding information to the user side.
Here, if the software platform detects that the response time of the user terminal for sending the response message exceeds the preset locking time, the software platform may send an overtime reminding message to the user terminal to prompt the user of the user terminal that the response time of the user terminal for sending the response message is already overtime.
In a specific implementation, the software platform may further detect whether the driver end of the current second service type can also provide services for the user end, and send an overtime reminding message to the user end if the driver end of the current second service type cannot provide services for the user end, as shown in fig. 8, the user end may prompt the user that the remaining service resources of the driver end of the second service type locked by the user are robbed according to the overtime reminding message sent by the software platform.
EXAMPLE five
As shown in fig. 9, taking the first service type as a car-calling service type of express cars and the second service type as a car-calling service type of carpools as an example, the service information pushing process provided in this embodiment of the present application is described, which may include the following steps:
s501, a travel order corresponding to the express service type sent by the user side is received.
In specific implementation, the software platform may receive a travel order sent by the user terminal, and obtain a taxi calling service type, departure location information, and destination information set by the user in the travel order. When the taxi calling service type of the travel order is determined to be the taxi calling service type of the express bus, a driver end of the taxi calling service type of the express bus can be matched for the user.
And S502, in the process of matching the driver end of the taxi calling service type of the express bus for the user end, judging whether the driver end with the taxi calling service type of the carpooling can receive the order or not according to the departure place information and the destination information in the travel order.
In a specific implementation, the software platform may determine a travel route from the departure point information to the destination information according to the departure point information and the destination information in the travel order. Here, the travel route from the departure place information to the destination information may include a plurality of pieces. After determining the travel route from the departure information to the destination information, matching the carpool travel route corresponding to the carpool order served by each driver with the determined travel route, and searching for the travel order of which the degree of following the determined travel route is greater than the preset degree threshold value of following the road. If the ride share order with the travel route of which the ride share degree is greater than the preset ride share degree threshold value is found, the fact that the ride share order with the travel order exists in the ride share orders currently served by each driver in the process of matching the driver of the first service type for the user side is indicated, and the travel service can be immediately provided for the user at the user side.
And S503, if the order can be received by the driver end without the taxi-calling service type of the carpool, continuously searching the driver end of the taxi-calling service type of the carpool which can be received in the process of matching the driver end of the taxi-calling service type of the express bus for the user end.
In specific implementation, if the software platform judges that no carpooling order in the same way as the travel order exists, the driver end of the taxi calling service type of the express train can be continuously matched with the user end, and meanwhile, the driver end of the taxi calling service type of the carpooling which can be accepted is continuously searched for the user end. The driver end of the taxi service type of the taxi sharing capable of receiving the order can be the driver end with the current residual service resource, and the residual service resource can be the residual seat.
S504, if the driver end with the taxi sharing calling service type can receive the order, whether the travel order meets the preset order sharing prompt condition is judged.
In specific implementation, if a driver end with a taxi pooling calling service type can receive an order, whether a travel order currently meets a preset taxi pooling prompt condition can be judged according to order information in the travel order sent by a user.
Here, the condition of the order-sharing cue includes one or more of the following conditions:
the current taxi calling ranking of the travel order is behind a preset ranking; the estimated order receiving time of a driver end of the taxi calling service type of the express train corresponding to the travel order currently is more than the preset time; the user side does not select the taxi calling service of other service types.
And S505, if the travel order does not meet the preset order splicing prompt condition currently, ending the current process.
And S506, if the travel order currently meets the preset order-sharing prompt condition, pushing service information of the taxi-calling service type corresponding to the shared taxi to the user side, and locking the service resources for the user side based on the residual service resources of the driver side of the taxi-calling service type of the shared taxi capable of receiving the order.
Here, the remaining service resources may be remaining seats. For example, the software platform may determine the number of remaining seats existing at a driver end of a taxi calling service type of the taxi sharing capable of receiving orders, may randomly select one or more of the remaining seats to be locked for a user at the user end, and during the locking process of the remaining seats, the remaining seats are reserved for the user at the user end and are not accepted to be occupied by other user ends.
And S507, if response information of the service information which refuses to accept the carpooling and is sent by the user terminal is received, the service information of the taxi calling service type corresponding to the carpooling is not pushed to the user terminal within the preset silent time.
In specific implementation, if the software platform receives the response information of the service information of refusing to accept the car sharing sent by the user side, it indicates that the user of the user side does not need the service of pushing the car sharing travel scheme provided by the software platform, and can not push the service information of the car calling service type corresponding to the car sharing to the user side within the preset silent time.
And S508, if response information of the service information of the taxi calling service type sent by the user side and used for receiving the taxi sharing is received, detecting whether response time corresponding to the response information exceeds preset locking time.
In a specific implementation, the software platform can lock the remaining service resources of the driver side of the second service type at a preset locking time. If the software platform receives response information which is sent by the user end and used for receiving the service of the second service type after pushing the service information corresponding to the second service type to the user end, whether the response time corresponding to the response information exceeds the preset locking time or not is detected
And S509, if the response time does not exceed the locking time, distributing the travel order to a driver end of the taxi sharing calling service type, and returning the information of the waiting driving receiving page to the user end.
Here, if the software platform detects that the response time of the user side for sending the response information does not exceed the preset locking time, the software platform can directly distribute the travel order sent by the user side to the driver side of the taxi sharing calling service type, and can return the information of the waiting driving receiving page to the user side.
And S510, if the response time exceeds the locking time, sending overtime reminding information to the user terminal.
Here, if the software platform detects that the response time of the user terminal for sending the response message exceeds the preset locking time, the software platform may send an overtime reminding message to the user terminal to prompt the user of the user terminal that the response time of the user terminal for sending the response message is already overtime.
By adopting the service information pushing mode, the problem that the service resources of the driver end of the first service type are in short supply and cannot immediately provide service for the user, so that the user queues up and waits for a long time can be solved; on the other hand, in the process of matching the driver end of the first service type with the user end, when the driver end with the second service type can receive an order, the service information corresponding to the second service type is pushed to the user end, for example, the service information of the car sharing service type capable of going out in time is pushed to the user end in the peak time of calling the car, so that the pressure of calling the car in the peak time of calling the car can be reduced, and the efficiency of the user going out is improved.
The foregoing embodiment describes the service information pushing method according to the embodiment of the present application from the perspective of a server of a platform, and corresponding descriptions are made below from the perspective of a user side, and a specific implementation process corresponds to the foregoing embodiment, and details of the implementation process are not described in detail.
EXAMPLE six
As shown in fig. 10, an embodiment of the present application further provides a service information pushing method, which can be applied to a user side, and includes:
s601, sending a travel order corresponding to the first service type to a server.
In specific implementation, when the user uses the software to call the car, the user side can send the travel order corresponding to the first service type to the server according to the user operation. Here, the first service type may be a taxi calling service type selected by the user, for example, a taxi calling service type such as a taxi, a express bus, a special bus, and the like.
S602, in the process of waiting for a driver terminating order of a first service type, receiving service information of a second service type pushed by the server based on the departure place information and the destination information in the travel order.
In a specific implementation, the user terminal may receive the service information of the second service type pushed by the server based on the departure place information and the destination information in the travel order while waiting for the driver terminating order of the first service type. Here, the second service type may be a taxi calling service type different from the first service type, and accordingly, the second service type may include taxi calling service types such as taxies, express buses, carpools, and special cars. The service information of the second service type received by the user side may also carry the forward degree information.
S603, displaying the service information of the second service type to prompt a user to confirm whether to accept the service of the second service type.
Here, taking the first service type as the non-car-sharing car-calling service type and the second service type as the car-sharing car-calling service type as an example, the display interface for the user side to display the service information of the second service type may be as shown in fig. 6. The display interface can prompt the user that the passenger has a position to move along the road and can immediately dispatch the vehicle when passing through the passenger, and can prompt the user of the forward degree of the car sharing order and the trip order on the display interface, such as prompting the forward degree of 90% ", the user can select to continue waiting for the driver corresponding to the first service type to terminate the order according to a refusing key on the display interface, or select the passenger corresponding to the car sharing order of the trip order to move along with the trip order according to an agreeing key on the display interface.
In a specific implementation, after the service information of the second service type is presented, response information may be sent to the server according to a user operation. Specifically, if the response information of the service of the second service type is received back from the server after the preset locking time is exceeded, the timeout reminding information fed back by the server is received. And if the user receives the service of the second service type after feeding back the service of the second service type to the server, receiving the page information of waiting for pickup returned by the server, wherein the page information of waiting for pickup carries the driver end information of the second service type of the pickup.
In specific implementation, if the user side operates according to a user, the user side may send a service request of a first service type to the server, and may receive first waiting response page information corresponding to the first service type, which is fed back by the server, where the first waiting response page information may carry prompt information for simultaneously selecting a second service type, and as shown in fig. 2, a display interface displayed by the user side to the user carries prompt information for simultaneously calling a car pool. And after the user confirms that the second service type is selected at the same time, receiving second waiting reply page information corresponding to the second service type returned by the server. As shown in (1) and (2) of fig. 3, the user displays a prompt message for calling the carpool to the user.
By adopting the service information pushing mode, the service information of the second service type pushed by the server can be received in the process of waiting for the driver terminal order of the first service type, so that the user is prompted to go out in time through the taxi calling service of the second service type. For example, during the peak time of calling the car, service information of the car sharing service type capable of going out in time is pushed for the user side, so that the pressure of calling the car during the peak time of calling the car can be reduced, and the efficiency of the user going out is improved.
Based on the same application concept, a service information pushing device corresponding to the service information pushing method is further provided in the embodiment of the present application, and as the principle of solving the problem of the device in the embodiment of the present application is similar to that of the service information pushing method in the embodiment of the present application, the implementation of the device may refer to the implementation of the method, and repeated details are not repeated.
EXAMPLE seven
Referring to fig. 11, which is a schematic diagram of a service information pushing apparatus 70 according to a seventh embodiment of the present application, where the apparatus 70 includes: a receiving module 71, a judging module 72 and a pushing module 73.
The receiving module 71 is configured to receive a travel order corresponding to the first service type sent by the user side;
the judging module 72 is configured to, in a process of matching the driver end of the first service type for the user end, judge whether there is a driver end of the second service type that can take an order according to the departure place information and the destination information in the travel order;
the pushing module 73 is configured to push service information corresponding to a second service type to the user side if there is a driver side with the second service type that can take an order.
In specific implementation, the first service type is a non-car-sharing car-calling service type, and the second service type is a car-sharing car-calling service type.
In a specific implementation, the pushing module 73 is specifically configured to push the service information corresponding to the second service type to the user side according to the following steps:
and if the driver end with the second service type can take orders and the travel order currently meets the preset order splicing prompt condition, pushing service information corresponding to the second service type to the user end.
Here, the order-matching prompt condition includes one or more of the following conditions:
the current taxi calling ranking of the travel order is behind a preset ranking;
the predicted order receiving time of a driver end of the first service type corresponding to the travel order is larger than the preset time;
the user side does not select the taxi calling service of other service types.
In an implementation, the determining module 72 is specifically configured to determine whether there is a driver-side order taking capability of the second service type according to the following steps:
judging whether a carpool order which is in the same way as the travel order exists in carpool orders which are served by each driver side or not according to the departure place information and the destination information in the travel order;
and if the carpooling order which is in the same way as the travel order exists, determining that the driver end with the second service type can take the order.
In a specific implementation, the determining module 72 is specifically configured to determine whether a car pooling order following the travel order exists in car pooling orders served by each driver:
and judging whether the car sharing orders which are in the same way as the travel orders and can be picked up within a preset time length exist in the car sharing orders which are served by each driver.
In a specific implementation, the determining module 72 is specifically configured to determine whether a car pooling order following the travel order exists in car pooling orders served by each driver:
determining a travel route from the departure place information to the destination information;
searching for a travel order of which the forward degree with the travel route is greater than a preset forward degree threshold value in car sharing orders which are served by each driver;
and if the ride share order with the travel route is found to be larger than the preset ride share threshold value, determining that the ride share order in the same way as the travel order currently exists.
In a specific implementation, the pushing module 73 is specifically configured to push the service information corresponding to the second service type to the user side according to the following steps:
and pushing the service information carrying the forward road degree to the user side.
In a specific implementation, the apparatus 70 further includes a locking module 74, configured to lock a remaining service resource for the user side based on the remaining service resource of the driver side of the second service type capable of receiving orders; and if the response message of receiving the service message of the second service type sent by the user side is not received within the preset locking time, unlocking the locked residual service resources.
In a specific implementation, the apparatus 70 further comprises: a processing module 75, configured to detect whether response time corresponding to the response information exceeds the locking time if response information that is sent by the user side and accepts the service information of the second service type is received; and if the response time does not exceed the locking time, distributing the travel order to a driver end of the second service type.
In a specific implementation, the processing module 75 is further configured to send an overtime reminding message to the user side if the response time exceeds the locking time.
In a specific implementation, the processing module 75 is specifically configured to send the timeout reminding message to the user end according to the following steps:
detecting whether the driver end of the current second service type can provide services for the user end; and if the user terminal can not be provided with the service, sending overtime reminding information to the user terminal.
In a specific implementation, the pushing module 73 is further configured to return, to the user side, information of a page to be picked up after the user side receives the taxi calling service of the second service type, where the information of the page to be picked up carries driver side information of the second service type of the pickup order.
In a specific implementation, the pushing module 73 is further configured to, if response information sent by the user end and rejecting to accept the service information of the second service type is received, no longer push the service information corresponding to the second service type to the user end within a preset silent time.
In a specific implementation, the pushing module 73 is further configured to send first waiting response page information corresponding to the first service type to the user side, where the first waiting response page information carries prompt information for selecting a second service type at the same time; and if the user side confirms that the second service type is selected at the same time, returning second waiting reply page information corresponding to the second service type to the user side.
Example eight
As shown in fig. 12, a schematic diagram of a service information pushing apparatus 90 according to an eighth embodiment of the present application, where the apparatus 90 includes: a sending module 91, a receiving module 92 and a display module 93; wherein the content of the first and second substances,
the sending module 91 is configured to send a travel order corresponding to the first service type to the server;
the receiving module 92 is configured to receive, in a process of waiting for a driver of a first service type to pick up an order, service information of a second service type pushed by the server based on departure location information and destination information in the travel order;
the displaying module 93 is configured to display the service information of the second service type to prompt a user to determine whether to accept the service of the second service type.
Here, the service information carries forward route degree information.
In a specific implementation, the receiving module 92 is further configured to receive the timeout reminding information fed back by the server if response information for receiving the service of the second service type is fed back to the server after the preset locking time is exceeded.
In a specific implementation, the receiving module 92 is further configured to receive, after the feedback that the user receives the service of the second service type is sent back to the server, the page information of waiting for pickup returned by the server, where the page information of waiting for pickup carries driver-side information of the second service type of the pickup.
In a specific implementation, the receiving module 92 is further configured to receive first waiting response page information corresponding to the first service type and fed back by the server, where the first waiting response page information carries prompt information for selecting a second service type at the same time; and after the user confirms that the second service type is selected at the same time, receiving second waiting response page information corresponding to the second service type returned by the server.
Example nine
As shown in fig. 13, a schematic structural diagram of a server 1000 according to a ninth embodiment of the present application includes: a processor 1001, a memory 1002, and a bus 1003.
The memory 1002 stores machine-readable instructions executable by the processor 1001, the processor 1001 and the memory 1002 communicate via a bus when the electronic device is operated, and the processor 1001 executes the machine-readable instructions to implement the following processes:
receiving a travel order corresponding to a first service type sent by a user side;
in the process of matching the driver end of the first service type with the user end, judging whether a driver end of a second service type can take an order or not according to the departure place information and the destination information in the travel order;
and if the driver end with the second service type can take the order, pushing service information corresponding to the second service type to the user end.
In a specific implementation, in the processing executed by the processor 1001, the first service type is a non-car-sharing car-calling service type, and the second service type is a car-sharing car-calling service type.
In a specific implementation, in the processing executed by the processor 1001, if there is a second service type driver's end available for order pickup, the pushing service information corresponding to the second service type to the user end includes:
and if the driver end with the second service type can take orders and the travel order currently meets the preset order splicing prompt condition, pushing service information corresponding to the second service type to the user end.
In a specific implementation, in the processing performed by the processor 1001, the order-matching prompt condition includes one or more of the following conditions:
the current taxi calling ranking of the travel order is behind a preset ranking;
the predicted order receiving time of a driver end of the first service type corresponding to the travel order is larger than the preset time;
the user side does not select the taxi calling service of other service types.
In a specific implementation, the processing executed by the processor 1001, to determine whether there is a driver's end capable of taking an order of the second service type according to the departure place information and the destination information in the travel order, includes:
judging whether a carpool order which is in the same way as the travel order exists in carpool orders which are served by each driver side or not according to the departure place information and the destination information in the travel order;
and if the carpooling order which is in the same way as the travel order exists, determining that the driver end with the second service type can take the order.
In a specific implementation, the determining, in the processing executed by the processor 1001, whether a car pool order that follows the travel order exists in car pool orders served by each driver side includes:
and judging whether the car sharing orders which are in the same way as the travel orders and can be picked up within a preset time length exist in the car sharing orders which are served by each driver.
In a specific implementation, in the processing executed by the processor 1001, the determining, according to departure information and destination information in the travel order, whether a carpool order following the travel order exists in carpool orders being served by each driver, includes:
determining a travel route from the departure place information to the destination information;
searching for a travel order of which the forward degree with the travel route is greater than a preset forward degree threshold value in car sharing orders which are served by each driver;
and if the ride share order with the travel route is found to be larger than the preset ride share threshold value, determining that the ride share order in the same way as the travel order currently exists.
In a specific implementation, in the processing executed by the processor 1001, the pushing, to the ue, the service information corresponding to the second service type includes:
and pushing the service information carrying the forward road degree to the user side.
In a specific implementation, after the processor 1001 pushes the service information corresponding to the second service type to the ue, the method further includes:
based on the remaining service resources of the driver end of the second service type capable of receiving orders, locking the remaining service resources for the user end;
and if the response message of receiving the service message of the second service type sent by the user side is not received within the preset locking time, unlocking the locked residual service resources.
In a specific implementation, after the processor 1001 pushes the service information corresponding to the second service type to the ue, the method further includes:
if response information which is sent by the user side and receives the service information of the second service type is received, whether response time corresponding to the response information exceeds the locking time is detected;
and if the response time does not exceed the locking time, distributing the travel order to a driver end of the second service type.
In a specific implementation, in the processing performed by the processor 1001, the method further includes:
and if the response time exceeds the locking time, sending overtime reminding information to the user side.
In a specific implementation, in the processing executed by the processor 1001, if the response time exceeds the lock time, sending an timeout reminding message to the user side includes:
detecting whether the driver end of the current second service type can provide services for the user end; and if the user terminal can not be provided with the service, sending overtime reminding information to the user terminal.
In a specific implementation, in the processing executed by the processor 1001, after the pushing the service information corresponding to the second service type to the ue, the method further includes:
and after the user side receives the taxi calling service of the second service type, returning the waiting driving page information to the user side, wherein the waiting driving page information carries driver side information of the second service type of the order.
In a specific implementation, after the processor 1001 pushes the service information corresponding to the second service type to the ue, the method further includes:
and if response information which is sent by the user side and refuses to accept the service information of the second service type is received, the service information corresponding to the second service type is not pushed to the user side within preset silent time.
In a specific implementation, after receiving the travel order corresponding to the first service type sent by the user end in the processing executed by the processor 1001, the method further includes:
sending first waiting response page information corresponding to the first service type to the user side, wherein the first waiting response page information carries prompt information for selecting a second service type simultaneously;
and if the user side confirms that the second service type is selected at the same time, returning second waiting reply page information corresponding to the second service type to the user side.
Example ten
As shown in fig. 14, a schematic structural diagram of a terminal device 1100 provided in the ninth embodiment of the present application includes: a processor 1101, a memory 1102, and a bus 1103.
The memory 1102 stores machine-readable instructions executable by the processor 1101, the processor 1101 and the memory 1102 communicating via a bus when the electronic device is operating, the processor 1101 executing the machine-readable instructions implementing the following:
sending a travel order corresponding to the first service type to a server;
receiving service information of a second service type pushed by the server based on the departure place information and the destination information in the travel order in the process of waiting for the driver of the first service type to pick up the order;
and displaying the service information of the second service type to prompt a user to confirm whether to accept the service of the second service type.
In a specific implementation, in the processing executed by the processor 1101, the service information carries forward path degree information.
In a specific implementation, in the processing performed by the processor 1101, the method further includes:
and if the response information of the service of the second service type is received back to the server after the preset locking time is exceeded, receiving the overtime reminding information fed back by the server.
In a specific implementation, in the processing executed by the processor 1101, after the displaying the service information of the second service type, the method further includes:
and after the feedback that the user receives the service of the second service type is fed back to the server, receiving the page information of waiting for pickup returned by the server, wherein the page information of waiting for pickup carries driver end information of the second service type of pickup.
In a specific implementation, the processing executed by the processor 1101 further includes, after sending the travel order corresponding to the first service type to the server:
receiving first waiting response page information corresponding to the first service type fed back by the server, wherein the first waiting response page information carries prompt information for selecting a second service type simultaneously;
and after the user confirms that the second service type is selected at the same time, receiving second waiting response page information corresponding to the second service type returned by the server.
In addition, an embodiment of the present application further provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the computer program performs the steps of the service information pushing method in the foregoing method embodiment.
The computer program product of the service information pushing method provided in the embodiment of the present application includes a computer-readable storage medium storing a program code, where instructions included in the program code may be used to execute the steps of the service information pushing method in the foregoing method embodiment, which may be referred to in the foregoing method embodiment specifically, and are not described herein again.
It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the system and the apparatus described above may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again. In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one logical division, and there may be other divisions when actually implemented, and for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection of devices or units through some communication interfaces, and may be in an electrical, mechanical or other form.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit.
The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a non-volatile computer-readable storage medium executable by a processor. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read-only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.
The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (42)

1. A service information pushing method is characterized by comprising the following steps:
receiving a travel order corresponding to a first service type sent by a user side;
in the process of matching the driver end of the first service type with the user end, judging whether a driver end of a second service type can take an order or not according to the departure place information and the destination information in the travel order;
and if the driver end with the second service type can take the order, pushing service information corresponding to the second service type to the user end.
2. The method of claim 1, wherein the first service type is a non-car-pooling taxi service type and the second service type is a car-pooling taxi service type.
3. The method of claim 2, wherein if there is a driver-side order-receiving capability of a second service type, pushing service information corresponding to the second service type to the user side comprises:
and if the driver end with the second service type can take orders and the travel order currently meets the preset order splicing prompt condition, pushing service information corresponding to the second service type to the user end.
4. The method of claim 3, wherein the spelling prompt condition comprises one or more of the following conditions:
the current taxi calling ranking of the travel order is behind a preset ranking;
the predicted order receiving time of a driver end of the first service type corresponding to the travel order is larger than the preset time;
the user side does not select the taxi calling service of other service types.
5. The method of claim 2, wherein determining whether a driver's end of the second service type can take an order according to the departure place information and the destination information in the travel order comprises:
judging whether a carpool order which is in the same way as the travel order exists in carpool orders which are served by each driver side or not according to the departure place information and the destination information in the travel order;
and if the carpooling order which is in the same way as the travel order exists, determining that the driver end with the second service type can take the order.
6. The method of claim 5, wherein determining whether a ride share order exists in the ride share orders being served by each driver side, the ride share order being in-route with the travel order, comprises:
and judging whether the car sharing orders which are in the same way as the travel orders and can be picked up within a preset time length exist in the car sharing orders which are served by each driver.
7. The method according to claim 5 or 6, wherein the determining whether a car pool order which is in-route with the travel order exists in car pool orders which are served by each driver terminal according to the departure place information and the destination information in the travel order comprises:
determining a travel route from the departure place information to the destination information;
searching for a travel order of which the forward degree with the travel route is greater than a preset forward degree threshold value in car sharing orders which are served by each driver;
and if the ride share order with the travel route is found to be larger than the preset ride share threshold value, determining that the ride share order in the same way as the travel order currently exists.
8. The method of claim 7, wherein the pushing the service information corresponding to the second service type to the user side comprises:
and pushing the service information carrying the forward road degree to the user side.
9. The method of claim 1, wherein after pushing the service information corresponding to the second service type to the user side, further comprising:
based on the remaining service resources of the driver end of the second service type capable of receiving orders, locking the remaining service resources for the user end;
and if the response message of receiving the service message of the second service type sent by the user side is not received within the preset locking time, unlocking the locked residual service resources.
10. The method of claim 9, wherein after pushing the service information corresponding to the second service type to the user side, further comprising:
if response information which is sent by the user side and receives the service information of the second service type is received, whether response time corresponding to the response information exceeds the locking time is detected;
and if the response time does not exceed the locking time, distributing the travel order to a driver end of the second service type.
11. The method of claim 10, further comprising:
and if the response time exceeds the locking time, sending overtime reminding information to the user side.
12. The method of claim 11, wherein sending a timeout reminder message to the user side if the response time exceeds the lock time comprises:
detecting whether the driver end of the current second service type can provide services for the user end; and if the user terminal can not be provided with the service, sending overtime reminding information to the user terminal.
13. The method of claim 1, wherein after the pushing the service information corresponding to the second service type to the user side, further comprising:
and after the user side receives the taxi calling service of the second service type, returning the waiting driving page information to the user side, wherein the waiting driving page information carries driver side information of the second service type of the order.
14. The method of claim 1, wherein after pushing the service information corresponding to the second service type to the user side, further comprising:
and if response information which is sent by the user side and refuses to accept the service information of the second service type is received, the service information corresponding to the second service type is not pushed to the user side within preset silent time.
15. The method of claim 1, wherein after receiving the travel order corresponding to the first service type sent by the user terminal, the method further comprises:
sending first waiting response page information corresponding to the first service type to the user side, wherein the first waiting response page information carries prompt information for selecting a second service type simultaneously;
and if the user side confirms that the second service type is selected at the same time, returning second waiting reply page information corresponding to the second service type to the user side.
16. A service information pushing method is characterized by comprising the following steps:
sending a travel order corresponding to the first service type to a server;
receiving service information of a second service type pushed by the server based on the departure place information and the destination information in the travel order in the process of waiting for the driver of the first service type to pick up the order;
and displaying the service information of the second service type to prompt a user to confirm whether to accept the service of the second service type.
17. The method of claim 16, wherein the service information carries forward route degree information.
18. The method of claim 16, further comprising:
and if the response information of the service of the second service type is received back to the server after the preset locking time is exceeded, receiving the overtime reminding information fed back by the server.
19. The method of claim 16, wherein after presenting the service information of the second service type, further comprising:
and after the feedback that the user receives the service of the second service type is fed back to the server, receiving the page information of waiting for pickup returned by the server, wherein the page information of waiting for pickup carries driver end information of the second service type of pickup.
20. The method of claim 16, further comprising, after sending the travel order corresponding to the first service type to the server:
receiving first waiting response page information corresponding to the first service type fed back by the server, wherein the first waiting response page information carries prompt information for selecting a second service type simultaneously;
and after the user confirms that the second service type is selected at the same time, receiving second waiting response page information corresponding to the second service type returned by the server.
21. A service information pushing apparatus, comprising: the device comprises a receiving module, a judging module and a pushing module; wherein the content of the first and second substances,
the receiving module is used for receiving the travel order corresponding to the first service type and sent by the user side;
the judging module is used for judging whether a driver end with a second service type can take an order or not according to the departure place information and the destination information in the travel order in the process of matching the driver end with the first service type for the user end;
the pushing module is used for pushing service information corresponding to the second service type to the user side if the driver side with the second service type can take orders.
22. The apparatus of claim 21, wherein the first service type is a non-car-pooling taxi service type and the second service type is a car-pooling taxi service type.
23. The apparatus of claim 22, wherein the pushing module is specifically configured to push the service information corresponding to the second service type to the user side according to the following steps:
and if the driver end with the second service type can take orders and the travel order currently meets the preset order splicing prompt condition, pushing service information corresponding to the second service type to the user end.
24. The apparatus of claim 23, wherein the order-matching prompt condition comprises one or more of the following conditions:
the current taxi calling ranking of the travel order is behind a preset ranking;
the predicted order receiving time of a driver end of the first service type corresponding to the travel order is larger than the preset time;
the user side does not select the taxi calling service of other service types.
25. The apparatus of claim 22, wherein the determining module is specifically configured to determine whether there is a driver-side order available for the second service type according to the following steps:
judging whether a carpool order which is in the same way as the travel order exists in carpool orders which are served by each driver side or not according to the departure place information and the destination information in the travel order;
and if the carpooling order which is in the same way as the travel order exists, determining that the driver end with the second service type can take the order.
26. The apparatus according to claim 25, wherein the determining module is specifically configured to determine whether a car pool order that follows the travel order exists in the car pool orders being served by each driver end according to the following steps:
and judging whether the car sharing orders which are in the same way as the travel orders and can be picked up within a preset time length exist in the car sharing orders which are served by each driver.
27. The apparatus according to claim 25 or 26, wherein the determining module is specifically configured to determine whether a car pool order following the travel order exists in the car pool orders being served by each driver:
determining a travel route from the departure place information to the destination information;
searching for a travel order of which the forward degree with the travel route is greater than a preset forward degree threshold value in car sharing orders which are served by each driver;
and if the ride share order with the travel route is found to be larger than the preset ride share threshold value, determining that the ride share order in the same way as the travel order currently exists.
28. The apparatus of claim 27, wherein the pushing module is specifically configured to push the service information corresponding to the second service type to the user side according to the following steps:
and pushing the service information carrying the forward road degree to the user side.
29. The apparatus of claim 21, further comprising a locking module configured to lock a remaining service resource for the user side based on the remaining service resource of the driver side of the second service type capable of receiving orders; and if the response message of receiving the service message of the second service type sent by the user side is not received within the preset locking time, unlocking the locked residual service resources.
30. The apparatus of claim 29, further comprising: the processing module is used for detecting whether response time corresponding to the response information exceeds the locking time or not if the response information which is sent by the user side and used for receiving the service information of the second service type is received; and if the response time does not exceed the locking time, distributing the travel order to a driver end of the second service type.
31. The apparatus of claim 30,
and the processing module is further used for sending overtime reminding information to the user side if the response time exceeds the locking time.
32. The apparatus of claim 31, wherein the processing module is specifically configured to send the timeout reminding message to the user side according to the following steps:
detecting whether the driver end of the current second service type can provide services for the user end; and if the user terminal can not be provided with the service, sending overtime reminding information to the user terminal.
33. The apparatus of claim 21, wherein the pushing module is further configured to return a waiting-to-pick-up page message to the user side after the user side receives the taxi calling service of the second service type, where the waiting-to-pick-up page message carries driver side information of the second service type of the pick-up order.
34. The apparatus of claim 21, wherein the pushing module is further configured to, if a response message sent by the ue and rejecting to accept the service information of the second service type is received, no longer push the service information corresponding to the second service type to the ue within a preset silence time.
35. The apparatus according to claim 21, wherein the pushing module is further configured to send first waiting response page information corresponding to the first service type to the user side, where the first waiting response page information carries a prompt message for selecting a second service type at the same time; and if the user side confirms that the second service type is selected at the same time, returning second waiting reply page information corresponding to the second service type to the user side.
36. A service information pushing apparatus, comprising: the device comprises a sending module, a receiving module and a display module; wherein the content of the first and second substances,
the sending module is used for sending the travel order corresponding to the first service type to the server;
the receiving module is used for receiving service information of a second service type pushed by the server based on the departure place information and the destination information in the travel order in the process of waiting for the driver of the first service type to take an order;
and the display module is used for displaying the service information of the second service type so as to prompt a user to confirm whether to accept the service of the second service type.
37. The apparatus of claim 36, wherein the service information carries forward route degree information.
38. The apparatus of claim 36, wherein the receiving module is further configured to receive a timeout reminding message fed back by the server if a response message for accepting the service of the second service type is fed back to the server after a preset lock time is exceeded.
39. The apparatus of claim 36, wherein the receiving module is further configured to receive, after the feedback that the user accepts the service of the second service type is sent back to the server, the waiting-to-drive page information returned by the server, where the waiting-to-drive page information carries driver-side information of the second service type of the pickup.
40. The apparatus according to claim 36, wherein the receiving module is further configured to receive first waiting response page information corresponding to the first service type and fed back by the server, where the first waiting response page information carries prompt information for selecting a second service type at the same time; and after the user confirms that the second service type is selected at the same time, receiving second waiting response page information corresponding to the second service type returned by the server.
41. An electronic device, comprising: a processor, a memory and a bus, wherein the memory stores machine-readable instructions executable by the processor, the processor and the memory communicate with each other through the bus when the electronic device is running, and the processor executes the machine-readable instructions to implement the steps of the service information pushing method according to any one of claims 1 to 15 or the steps of the service information pushing method according to any one of claims 16 to 20.
42. A computer-readable storage medium, characterized in that the computer-readable storage medium has stored thereon a computer program, which, when being executed by a processor, performs the steps of the service information pushing method according to any one of claims 1 to 15, or the steps of the service information pushing method according to any one of claims 16 to 20.
CN201811135229.0A 2018-09-27 2018-09-27 Service information pushing method and device, electronic equipment and computer storage medium Pending CN110956524A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811135229.0A CN110956524A (en) 2018-09-27 2018-09-27 Service information pushing method and device, electronic equipment and computer storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811135229.0A CN110956524A (en) 2018-09-27 2018-09-27 Service information pushing method and device, electronic equipment and computer storage medium

Publications (1)

Publication Number Publication Date
CN110956524A true CN110956524A (en) 2020-04-03

Family

ID=69975295

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811135229.0A Pending CN110956524A (en) 2018-09-27 2018-09-27 Service information pushing method and device, electronic equipment and computer storage medium

Country Status (1)

Country Link
CN (1) CN110956524A (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112001516A (en) * 2020-09-21 2020-11-27 北京嘀嘀无限科技发展有限公司 Information processing method and device, electronic equipment and storage medium
CN112561164A (en) * 2020-12-16 2021-03-26 北京嘀嘀无限科技发展有限公司 Car pooling service providing method and device and electronic equipment
CN113268674A (en) * 2021-05-18 2021-08-17 北京白龙马云行科技有限公司 Return auxiliary method and device
CN114422580A (en) * 2021-12-03 2022-04-29 浙江吉利控股集团有限公司 Information processing method and device, electronic equipment and storage medium

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SG134995A1 (en) * 2002-11-06 2007-09-28 Inventio Ag Method of and device for controlling a lift installation with zonal control
CN103685504A (en) * 2013-12-11 2014-03-26 南京大学 Car sharing system based on Android platform and working method of car sharing system based on Android platform
CN105117777A (en) * 2015-07-28 2015-12-02 北京嘀嘀无限科技发展有限公司 Order distributing method and apparatus
CN107145992A (en) * 2016-03-01 2017-09-08 滴滴（中国）科技有限公司 A kind of order allocation method and device
CN108009650A (en) * 2017-03-29 2018-05-08 北京嘀嘀无限科技发展有限公司 Net about car service request processing method, device and server

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SG134995A1 (en) * 2002-11-06 2007-09-28 Inventio Ag Method of and device for controlling a lift installation with zonal control
CN103685504A (en) * 2013-12-11 2014-03-26 南京大学 Car sharing system based on Android platform and working method of car sharing system based on Android platform
CN105117777A (en) * 2015-07-28 2015-12-02 北京嘀嘀无限科技发展有限公司 Order distributing method and apparatus
CN107145992A (en) * 2016-03-01 2017-09-08 滴滴（中国）科技有限公司 A kind of order allocation method and device
CN108009650A (en) * 2017-03-29 2018-05-08 北京嘀嘀无限科技发展有限公司 Net about car service request processing method, device and server

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112001516A (en) * 2020-09-21 2020-11-27 北京嘀嘀无限科技发展有限公司 Information processing method and device, electronic equipment and storage medium
CN112001516B (en) * 2020-09-21 2024-05-03 北京嘀嘀无限科技发展有限公司 Information processing method, device, electronic equipment and storage medium
CN112561164A (en) * 2020-12-16 2021-03-26 北京嘀嘀无限科技发展有限公司 Car pooling service providing method and device and electronic equipment
CN113268674A (en) * 2021-05-18 2021-08-17 北京白龙马云行科技有限公司 Return auxiliary method and device
CN113268674B (en) * 2021-05-18 2024-05-14 北京白龙马云行科技有限公司 Return auxiliary method and device
CN114422580A (en) * 2021-12-03 2022-04-29 浙江吉利控股集团有限公司 Information processing method and device, electronic equipment and storage medium
CN114422580B (en) * 2021-12-03 2024-02-02 浙江吉利控股集团有限公司 Information processing method, device, electronic equipment and storage medium

Similar Documents

Publication Publication Date Title
CN110956524A (en) Service information pushing method and device, electronic equipment and computer storage medium
US10991254B2 (en) User vehicle dispatch dealing system and storage medium
TWI696977B (en) Method and system for providing transportation service
WO2016074538A1 (en) Sent order ranking system and method for reducing no-load running and waiting time in online taxi renting
CN104464274A (en) Car-sharing taxi taking method and server
CN107844843B (en) Order processing method and server
CN107767322B (en) Carpooling method and device
JP2012088925A (en) Ecological taxi dispatch support system
CN110287214B (en) Information processing apparatus, ride share user selection method, and storage medium
CN108985896B (en) Carpooling method, carpooling route recommendation method, device, medium and electronic equipment
CN102426780A (en) Paging system used for summoning taxis and paging method thereof
JP2004362271A (en) Ride sharing riding system, riding information processor and ride sharing riding method
CN110472912B (en) Method and system for providing express delivery same-city delivery service by using network appointment vehicle
CN110765367A (en) Information pushing method and device, electronic equipment and computer storage equipment
GB2535719A (en) Telephone call placement
CN111860902A (en) Order processing method, device, equipment and computer readable storage medium
CN110956515A (en) Order processing method and device, electronic equipment and computer storage medium
CN101236625A (en) Mobile positioning communications terminal logistic information systems and goods distribution method
CN114372714A (en) Automatic vehicle allocation method, device, equipment, medium and program product
US20210118082A1 (en) Shared vehicle managing system
CN105279953A (en) Internet method and system for vehicles to pick up passengers at appointed stops
CN106297269A (en) Riding information sharing method and system
CN110910202B (en) Order processing method and device
CN109508806B (en) Order processing method and device for network appointment vehicle application
CN111260840B (en) Information pushing method and device, electronic equipment and computer storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination