WO2020098383A1

WO2020098383A1 - 一种网络约车和发票开具方法、系统和装置

Info

Publication number: WO2020098383A1
Application number: PCT/CN2019/106758
Authority: WO
Inventors: 杨少航; 童遥; 杨光; 张永昊; 周琳娅; 李新华
Original assignee: 北京高德云图科技有限公司
Priority date: 2018-08-14
Filing date: 2019-09-19
Publication date: 2020-05-22
Also published as: US11946755B2; CN110826741A; US20210262812A1; US20240200955A1

Abstract

一种网络约车和发票开具方法、系统和装置，包括：接收用户终端发送的第一约车请求，其中携带至少一种运力类型、提供相应运力类型的至少一个网约车服务商及约车起终点；根据运力类型和网约车服务商，向相应网约车服务商的网约车服务平台发送第二约车请求，其中至少携带了约车起终点；接收网约车服务平台响应于第二约车请求返回的第二约车应答消息；基于第二约车应答消息，向用户终端返回响应于第一约车请求的第一约车应答消息。上述方法、系统和装置能够向多个服务商进行多种运力类型的车辆预约，提高约车的成功率，减少约车等待时间，使约车操作更简单、方便。

Description

一种网络约车和发票开具方法、系统和装置

本申请要求2018年11月12日递交的申请号为201811341981.0、发明名称为“一种网络约车和发票开具方法、系统和装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

本发明涉及网络约车技术领域，特别涉及一种网络约车和和发票开具方法、系统和装置。

背景技术

随着移动互联网技术的发展，出行用户(以下简称用户)越来越习惯在出行前通过网约车应用软件呼叫/预约车辆，而提供网约车服务的服务商(以下简称服务商)不止一家，每一家服务商提供给用户呼叫/预约的车辆类型也不止一种。

目前，一般服务商都是使用自己的网约车应用软件为用户提供网约车服务，用户通过一个服务商提供的网约车应用软件只能在呼叫/预约在该服务商平台上运营的车辆，如果用户通过一个服务商提供的网约车应用软件无法呼叫到车辆，则需要打开另一服务商提供的网约车应用软件重新呼叫/预约车辆，这样的约车方式会增加用户的约车操作成本，造成用户使用不便。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种网络约车方法、系统和装置。

本发明实施例提供一种网络约车方法，包括：

接收用户终端发送的第一约车请求，所述第一约车请求携带至少一种运力类型、提供相应运力类型的至少一个网约车服务商、及约车起终点；

根据所述运力类型和所述网约车服务商，向相应网约车服务商的网约车服务平台发送第二约车请求，所述第二约车请求至少携带所述约车起终点；

接收网约车服务平台响应于所述第二约车请求返回的第二约车应答消息；

基于所述第二约车应答消息，向所述用户终端返回响应于所述第一约车请求的第一约车应答消息。

在一些可选的实施例中，根据所述运力类型和所述网约车服务商，确定每个所述网约车服务商提供相应运力类型的车辆类型，包括：

根据所述运力类型和所述网约车服务商，确定每个所述网约车服务商提供相应运力类型的车辆类型；或解析出所述第一约车请求中的运力类型和网络约车服务商，得到每个所述网约车服务商所有的车辆类型；

根据每个网约车服务商的所有车辆类型，向相应网约车服务商的网约车服务平台发送第二约车请求，所述第二约车请求至少携带所述约车起终点。

在一些可选的实施例中，所述接收用户终端发送的第一约车请求，所述第一约车请求携带至少一种运力类型、提供所述运力类型的至少一个网约车服务商、及约车起终点，包括：

接收用户终端发送的第一约车请求，所述第一约车请求至少携带两种以上的运力类型、针对每种运力类型提供该种运力类型的至少一个网约车服务商、及约车起终点；

或者，

接收用户终端发送的第一约车请求，所述第一约车请求携带至少一种运力类型、针对每种运力类型提供该种运力类型的两个以上的网约车服务商、及约车起终点。

从所述第一约车请求中，解析出携带的网约车服务商和运力类型；

从预置的运力类型与网约车服务商的车辆类型的配置表中，查找到每个网约车服务商提供相应运力类型的车辆类型。

在一些可选的实施例中，如果网约车服务商的网约车服务平台用一个接口接收所有的车辆类型的约车请求，则向所述网约车服务商的网约车服务平台的接口发送的第二约车请求为一个，且所述第二约车请求中还携带车辆类型；

如果网约车服务商的网约车服务平台一个接口接收一种车辆类型的约车请求，则向所述网约车服务商的网约车服务平台的接口发送的第二约车请求个数与车辆类型的个数相同，所述第二约车请求中不携带车辆类型；

如果网约车服务商的网约车服务平台的第一接口接收两种以上车辆类型的约车请求，第二接口接收一种车辆类型的约车请求，则向所述网约车服务商的网约车服务平台的第一接口发送的第二约车请求还携带车辆类型，向第二接口发送的第二约车请求不携带车辆类型。

在一些可选的实施例中，基于所述第二约车应答消息，向所述用户终端返回响应于所述第一约车请求的第一约车应答消息，包括：

若响应于所述第二约车请求返回的第二约车应答消息仅一个，将所述第二约车应答消息作为响应于所述第一约车请求的第一约车应答消息返回给所述用户终端；

若响应于所述第二约车请求返回的第二约车应答消息有两个以上，按照预设的推荐策略，从接收到的第二约车应答消息中选择预设个数的第二约车应答消息作为响应于所述第一约车请求的第一约车应答消息返回给所述用户终端。

本发明实施例还提供一种网络约车方法，包括：

获取用户输入的约车起终点和通过约车用户交互界面选择的至少一种运力类型及提供相应运力类型的至少一个网约车服务商；

发送第一约车请求至约车服务器，以使所述约车服务器向相应的网约车服务商的网约车服务平台请求承运车辆，所述第一约车请求至少携带了所述用户选择的至少一种运力类型、提供相应运力类型的至少一个网约车服务商、及约车起终点。

在一些可选的实施例中，所述获取所述用户通过约车用户交互界面选择的至少一种运力类型及提供相应运力类型的至少一个网约车服务商具体包括：

获取所述用户通过约车用户交互界面选择的两种以上的运力类型及提供相应运力类型的至少一个网约车服务商或者所述用户通过约车用户交互界面选择的至少一种运力类型及提供相应运力类型的两种以上的网约车服务商。

在一些可选的实施例中，所述方法进一步包括：

发送携带所述约车起终点的估价请求至约车服务器，以使所述约车服务器向网约车服务商的网约服务平台请求出行预估费用；

在约车用户交互界面，将所述约车服务器返回的其请求来的出行预估费用，按照相应的运力类型及网约车服务商进行展示。

在一些可选的实施例中，所述方法进一步包括：

发送携带所述约车起终点的估价请求至约车服务器，以使所述约车服务器按照所述约车起终点确定相应的出行预估费用；

在约车用户交互界面，将所述约车服务器返回的其确定的出行预估费用，按照相应的运力类型及网约车服务商进行展示。

本发明实施例还提供一种发票开具方法，包括：

接收用户终端发送的第一发票开具请求，所述发票开具请求至少携带了至少一个网约车服务商的至少一条开票数据；

向所述发票开具请求携带的网约车服务商的网约车服务平台发送第二发票开具请求，所述第二约车请求至少携带了一条开票数据；

接收网约车服务平台响应于所述第二发票开具请求返回的第二发票开具应答消息；

基于接收到的第二发票开具应答消息，向所述用户终端返回响应于所述第一发票开具请求的第一发票开具应答消息。

本发明实施例还提供一种发票开具方法，包括：

获取所述用户通过发票开具交互界面选择的至少一个网约车服务商的至少一条开票数据；

发送第一发票开具请求至约车服务器，以使所述约车服务器向相应的网约车服务商的网约车服务平台请求发票，所述第一发票开具请求至少一个网约车服务商的至少一条开票数据。

本发明实施例还提供一种网络约车装置，包括：

第一接收模块，用于接收用户终端发送的第一约车请求，所述第一约车请求携带至少一种运力类型、提供相应运力类型的至少一个网约车服务商、及约车起终点；

第一发送模块，用于根据所述运力类型和所述网约车服务商，向相应网约车服务商的网约车服务平台发送第二约车请求，所述第二约车请求至少携带所述约车起终点；

第二接收模块，用于接收网约车服务平台响应于所述第二约车请求返回的第二约车应答消息；

第二发送模块，用于基于所述第二约车应答消息，向所述用户终端返回响应于所述第一约车请求的第一约车应答消息。

在一些可选的实施例中，上述装置还包括：

确定模块，用于根据所述运力类型和所述网约车服务商，确定每个所述网约车服务商提供相应运力类型的车辆类型；或解析出所述第一约车请求中的运力类型和网络约车服务商，得到每个所述网约车服务商所有的车辆类型；

所述第一发送模块，具体用于根据每个网约车服务商的所有车辆类型，向相应网约车服务商的网约车服务平台发送第二约车请求，所述第二约车请求至少携带所述约车起终点。

在一些可选的实施例中，所述第一接收模块，具体用于：

或者，

在一些可选的实施例中，所述确定模块，具体用于：

在一些可选的实施例中，所述第一发送模块，具体用于：

如果网约车服务商的网约车服务平台用一个接口接收所有的车辆类型的约车请求，则向所述网约车服务商的网约车服务平台的接口发送的第二约车请求为一个，且所述第二约车请求中还携带车辆类型；

在一些可选的实施例中，所述第二发送模块，具体用于：

本发明实施例还提供一种约车客户端，包括：

信息获取模块，用于获取用户输入的约车起终点和通过约车用户交互界面选择的至少一种运力类型及提供相应运力类型的至少一个网约车服务商；

第三发送模块，用于发送第一约车请求至约车服务器，以使所述约车服务器向相应的网约车服务商的网约车服务平台请求承运车辆，所述第一约车请求至少携带了所述用户选择的至少一种运力类型、提供相应运力类型的至少一个网约车服务商、及约车起终点。

在一些可选的实施例中，所述信息获取模块，具体用于：

在一些可选的实施例中，上述约车客户端，还包括：

估价模块，用于发送携带所述约车起终点的估价请求至约车服务器，以使所述约车服务器向网约车服务商的网约服务平台请求出行预估费用；在约车用户交互界面，将所述约车服务器返回的其请求来的出行预估费用，按照相应的运力类型及网约车服务商进行展示。

在一些可选的实施例中，上述约车客户端，还包括：

估价模块，用于发送携带所述约车起终点的估价请求至约车服务器，以使所述约车服务器按照所述约车起终点确定相应的出行预估费用；在约车用户交互界面，将所述约车服务器返回的其确定的出行预估费用，按照相应的运力类型及网约车服务商进行展示。

本发明实施例还提供一种网络约车系统，包括：用户终端、约车服务器和至少两个网约车服务平台；

所述用户终端中设置上述的约车客户端；

所述约车服务器中设置上述的网络约车装置；

所述网约车服务平台用于接收约车服务器发送的第二约车请求，当有承运车辆响应所述第二约车请求时，向约车服务器返回第二约车应答消息。

本发明实施例还提供一种发票开具装置，包括：

第四接收模块，用于接收用户终端发送的第一发票开具请求，所述发票开具请求至少携带了至少一个网约车服务商的至少一条开票数据；

第四发送模块，用于向所述发票开具请求携带的网约车服务商的网约车服务平台发送第二发票开具请求，所述第二约车请求至少携带了一条开票数据；

第五接收模块，用于接收网约车服务平台响应于所述第二发票开具请求返回的第二发票开具应答消息；

第五发送模块，用于基于接收到的第二发票开具应答消息，向所述用户终端返回响应于所述第一发票开具请求的第一发票开具应答消息。

本发明实施例还提供一种开票客户端，包括：

数据获取模块，用于获取所述用户通过发票开具交互界面选择的至少一个网约车服务商的至少一条开票数据；

第六发送模块，用于发送第一发票开具请求至约车服务器，以使所述约车服务器向相应的网约车服务商的网约车服务平台请求发票，所述第一发票开具请求至少一个网约车服务商的至少一条开票数据。

本发明实施例还提供一种发票开具系统，包括：用户终端、开票服务器和至少两个网约车服务平台；

所述用户终端中设置上述的开票客户端；

所述约车服务器中设置上述的发票开具装置；

所述网约车服务平台用于接收开票服务器发送的第二发票开具请求，向开票服务器返回第二发票开具应答消息。

本发明实施例还提供一种计算机存储介质，所述计算机存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器执行时实现上述的网络约车方法或实现上述的发票开具方法。

本发明实施例还提供一种服务器，包括：存储器、处理器及存储于存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述的网络约车方法或实现上述的发票开具方法。

本发明实施例还提供一种用户终端，包括：存储器、处理器及存储于存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述的网络约车方法或实现上述的发票开具方法。

本发明实施例提供的上述技术方案的有益效果至少包括：

采用本发明提供的技术方案，用户在进行网络约车时，可以通过用户终端上安装的一个约车应用软件选择多种运力类型以及为每种运力类型选择多个网约车服务商，并将用户选择的多种运力类型以及为每种运力类型通过一个第一约车请求发送给约车服务器，而约车服务器可以根据用户终端发送的第一约车请求，确定用户选择运力类型和网约车服务商，从而确定涉及到的每个网约车服务商提供相应运力类型的车辆类型，因此，本发明实现了用户通过用户终端上安装的一个约车应用软件同时向不同的网约车服务商请求不同网约车服务商不同类型的承运车辆，在这种情况下，只要有任何一个网约车服务商有响应，用户就能成功约到承运车辆，对于用户而言，能够更方便、快捷的约到合适的承运车辆，减少约车等待时间，提高约车的成功率，且用户不再需要安装多个约车软件，减少用户终端的系统资源开销，通过一个约车应用软件即可同时向不同的网约车服务商请求承运车辆，降低了用户操作的复杂度及约车操作成本，使约车操作更简单。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：

图1a为本发明实施例一中网络约车方法的流程图；

图1b为本发明实施例一中网络约车方法的一种具体实现流程图；

图2为本发明实施例一中用户交互界面的示例图之一；

图3为本发明实施例一中用户交互界面的示例图之二；

图4为本发明实施例一中另一种网络约车方法的流程图；

图5为本发明实施例一中网络约车系统的结构示意图；

图6a为本发明实施例一中网络约车装置的结构示意图；

图6b为本发明实施例一中网络约车装置的一种具体实现结构示意图；

图7为本发明实施例一中约车客户端的结构示意图；

图8为本发明实施例二中发票开具方法的流程示例图；

图9为本发明实施例二中另一种发票开具方法的流程示例图；

图10为本发明实施例二中发票开具系统的结构示意图；

图11为本发明实施例二中发票开具装置的结构示意图；

图12为本发明实施例二中开票客户端的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

为了解决现有技术用户通过一个服务商提供的网约车应用软件无法呼叫到车辆时，需要打开另一服务商提供的网约车应用软件重新呼叫/预约车辆，所存在的增加用户约车操作成本，造成用户使用不便的问题，本发明实施例提供了一种网络约车方法，能够更方便、快捷的进行网络约车，且约车操作简单、快捷、成本低，并能提高约车成功率，减少用户约车等待时间。

实施例一

本发明实施例一提供一种网络约车方法，其流程如图1a所示，包括如下步骤：

步骤S01：接收用户终端发送的第一约车请求，第一约车请求携带至少一种运力类型、提供相应运力类型的至少一个网约车服务商、及约车起终点。

具体参见步骤S101的描述。

步骤S02：根据运力类型和网约车服务商，向相应网约车服务商的网约车服务平台发送第二约车请求，第二约车请求至少携带约车起终点。

约车服务器接收到第一约车请求后，对第一约车请求进行解析，从中解析出携带的至少一种运力类型、提供相应运力类型的至少一个网约车服务商、及约车起终点等信息。

第一约车请求中携带的运力类型可以不是车辆类型，此时可以根据预置的运力类型与网约车服务商的车辆类型的配置表来确定各网约车服务商提供相应运力类型的车辆类型；第一约车请求中携带的运力类型是车辆类型，可以直接解析出车第一约车请求中携带的运力类型，从而得到车辆类型。

根据运力类型和网约车服务商，向相应网约车服务商的网约车服务平台发送第二约车请求的实现过程，包括：

根据运力类型和网约车服务商，确定每个网约车服务商提供相应运力类型的车辆类型；或，解析出第一约车请求中的运力类型和网络约车服务商，得到每个所述网约车服务商所有的车辆类型；

根据每个网约车服务商的所有车辆类型，向相应网约车服务商的网约车服务平台发送第二约车请求，第二约车请求至少携带所述约车起终点。

具体参见步骤S102和步骤S103的描述。

步骤S03：接收网约车服务平台响应于第二约车请求返回的第二约车应答消息。

具体参见步骤S104的描述。

步骤S04：基于第二约车应答消息，向用户终端返回响应于第一约车请求的第一约车应答消息。

具体参见步骤S105的描述。

上述网络约车方法的一种具体实现过程如图1b所示，包括如下步骤：

步骤S101：约车服务器接收用户终端发送的第一约车请求。

需要说明的是，用户终端可以是智能手机等用户终端，该用户终端上安装了一个约车应用软件，该约车应用软件可以是专用于网约车的网约车应用软件，也可以是集成了网约车功能的其他类应用软件(如地图导航类应用软件)。用户通过约车应用软件提供的约车用户交互界面，选择运力类型、网约车服务商和约车起终点等信息，约车应用软件根据用户选择的信息生成第一约车请求，第一约车请求中包括至少一种运力类型、提供相应运力类型的至少一个网约车服务商、及约车起终点，并通过安装该约车应用软件的用户终端向约车服务器发送所述第一约车请求。在实际应用中，所述约车应用软件和约车服务器可以由同一个服务提供者提供并运营。

如图2和图3所示的约车用户交互界面的示例图，其中，图3为图2中运力类型和网约车服务商选择部分的展开示例图。其中，约车起终点中的起点为我的位置，终点为首开广场，运力类型可以包括运力类型1、运力类型2、运力类型3、……等，网约车服务商可以包括服务商1、服务商2、服务商3、……等。

可以通过约车用户交互界面向用户提供可选择的至少一种运力类型和提供每个运力类型的至少一个网约车服务商。例如：在实际应用中，运力类型可以是出租车、经济、舒适、豪华、商务等等，则可以向用户展示这些运力类型供用户根据自身需要进行选择。

第一约车请求可以是当前立即进行预约的实时约车请求，或者指定时间预约的定时约车请求，如果是定时约车请求，该第一约车请求中可以进一步包括预约时间。

步骤S102：约车服务器根据第一约车请求中包括的运力类型和网约车服务商，确定每个网约车服务商提供相应运力类型的车辆类型。

约车服务器接收到第一约车请求后，对第一约车请求进行解析，从中解析出携带的至少一种运力类型、提供相应运力类型的至少一个网约车服务商、及约车起终点等信息。然后根据解析出的信息确定第一约车请求中涉及到的各个网约车服务商提供相应运力类型的车辆类型或根据解析出的信息得到每个网约车服务商所有的车辆类型。

可选的，第一约车请求中携带的运力类型与车辆类型是一一对应的，或者运力类型即为车辆类型，则可以从第一约车请求中直接获取到各网约车服务商提供相应运力类型的车辆类型。

可选的，还可以根据预置的运力类型与网约车服务商的车辆类型的配置表来确定各网约车服务商提供相应运力类型的车辆类型，即：从接收到的第一约车请求中，解析出携带的网约车服务商和运力类型；从预置的运力类型与网约车服务商的车辆类型的配置表中，查找到每个网约车服务商提供相应运力类型的车辆类型。尤其是运力类型与车辆类型并不是完全一一对应的情况下，优选这种确定方式。

步骤S103：约车服务器根据每个网约车服务商的所有车辆类型，向相应网约车服务商的网约车服务平台发送第二约车请求。

约车服务器确定出每个网约车服务商的所有车辆类型后，可以向每个网约车服务商请求预约车辆，例如，可以针对每个网约车服务商生成至少一条第二约车请求，分别向各个网约车服务平台发送，生成的第二约车请求至少携带了约车起终点。

约车服务器向网约车服务商的网约车服务平台发送第二约车请求时，可以根据网约车服务平台中接收约车请求的接口的类型来确定第二约车请求中是否携带车辆类型。

如果网约车服务商的网约车服务平台用一个接口接收所有的车辆类型的约车请求，则向网约车服务商的网约车服务平台的接口发送的第二约车请求为一个，且第二约车请求中进一步携带了车辆类型；

如果网约车服务商的网约车服务平台一个接口接收一种车辆类型的约车请求，则向网约车服务商的网约车服务平台的接口发送的第二约车请求个数与车辆类型的个数相同，第二约车请求中不携带车辆类型；

如果网约车服务商的网约车服务平台的第一接口可以接收两种以上车辆类型的约车请求，第二接口可以接收一种车辆类型的约车请求，则向网约车服务商的网约车服务平台的第一接口发送的第二约车请求需要进一步携带车辆类型，向第二接口发送的第二约车请求不携带车辆类型。

步骤S104：约车服务器接收网约车服务平台响应于第二约车请求返回的第二约车应答消息。

网约车服务平台根据接收到的第二约车请求，向相应车辆类型的广播车辆预约消息，当有车辆响应车辆预约消息时，向约车服务器返回第二约车应答消息。返回的第二约车应答消息至少包括响应车辆信息，响应车辆信息中至少包括联系方式，还可以包括车牌号、车辆类型、车辆颜色等信息中的至少一项。

步骤S105：约车服务器基于第二约车应答消息，向用户终端返回响应于第一约车请求的第一约车应答消息。

约车服务器接收到第二约车应答消息，根据接收到的第二约车应答消息向用户终端返回第一约车应答消息。

可选的，若响应于第二约车请求返回的第二约车应答消息仅一个，将第二约车应答消息作为响应于第一约车请求的第一约车应答消息返回给用户终端。

可选的，若响应于第二约车请求返回的第二约车应答消息有两个以上，按照预设的推荐策略，从接收到的第二约车应答消息中选择预设个数的第二约车应答消息作为响应于第一约车请求的第一约车应答消息返回给用户终端。其中预设的推荐策略可以包括价格最便宜的几个应答消息、响应最快的几个应答消息等等。

第一约车应答消息至少包括响应车辆信息，响应车辆信息中至少包括联系方式，还可以包括返回第二约车应答消息的网约车服务商，还可以包括车牌号、车辆类型、车辆颜色等信息中的至少一项。

步骤S101中，用户终端发送的第一约车请求可以有不同的情形，比如携带的运力类型至少有两种，或携带的网约车服务商至少有两个。相应的，约车服务器接收用户终端发送的第一约车请求时，包括：

接收用户终端发送的第一约车请求，第一约车请求至少携带了两种以上的运力类型、针对每种运力类型提供该种运力类型的至少一个网约车服务商、及约车起终点；

或者，

接收用户终端发送的第一约车请求，第一约车请求至少携带了至少一种运力类型、针对每种运力类型提供该种运力类型的两个以上的网约车服务商、及约车起终点。

上述从约车服务器的角度描述了网络约车方法，此外本发明实施例一还提供一种网络约车方法，从用户终端的角度描述本实施例的网络约车方法，其流程如图4所示，包括如下步骤：

步骤S201：用户终端获取用户输入的约车起终点和通过约车用户交互界面选择的至少一种运力类型及提供相应运力类型的至少一个网约车服务商。

获取用户通过约车用户交互界面选择的两种以上的运力类型及提供相应运力类型的至少一个网约车服务商或者用户通过约车用户交互界面选择的至少一种运力类型及提供相应运力类型的两种以上的网约车服务商。

步骤S202：用户终端发送第一约车请求至约车服务器，以使约车服务器向相应的网约车服务商的网约车服务平台请求承运车辆。

其中，第一约车请求至少携带了用户选择的至少一种运力类型、提供相应运力类型的至少一个网约车服务商、及约车起终点。

上述方法还包括：

步骤S203：用户终端接收约车服务器返回的第一约车应答消息。其中第一约车应答消息为约车服务器基于第二约车应答消息向用户终端返回的。

约车服务器的处理流程参见图1a的相关描述的相关描述。

上述实施例一所述的方法还包括针对约车起终点进行估价的过程：

可选的，一种估价过程包括：用户终端发送携带约车起终点的估价请求至约车服务器，约车服务器向网约车服务商的网约服务平台请求出行预估费用，约车服务器返回的其请求来的出行预估费用，用户终端在约车用户交互界面，将约车服务器返回的出行预估费用，按照相应的运力类型及网约车服务商进行展示。

可选的，另一种估价过程包括：发送携带约车起终点的估价请求至约车服务器，以使约车服务器按照约车起终点确定相应的出行预估费用；在约车用户交互界面，将约车服务器返回的其确定的出行预估费用，按照相应的运力类型及网约车服务商进行展示。

基于同一发明构思，本发明实施例一还提供一种网络约车系统，该系统结构如图5所示，包括：用户终端51、约车服务器52和至少两个网约车服务平台53。其中，用户终端51和网约车服务平台53都可以有多个，约车服务器52根据需求设置一个或者多个。

网约车服务平台53用于接收约车服务器发送的第二约车请求，当有承运车辆响应所述第二约车请求时，向约车服务器52返回第二约车应答消息。

约车服务器52中设置网络约车装置，该装置的一种结构可以如图6a所示，包括：第一接收模块521、第一发送模块523、第二接收模块524和第二发送模块525。

第一接收模块521，用于接收用户终端发送的第一约车请求，其中，第一约车请求携带至少一种运力类型、提供相应运力类型的至少一个网约车服务商、及约车起终点；

第一发送模块523，用于根据所述运力类型和所述网约车服务商，向相应网约车服务商的网约车服务平台发送第二约车请求，其中，第二约车请求至少携带所述约车起终点；

第二接收模块524，用于接收网约车服务平台响应于第二约车请求返回的第二约车应答消息；

第二发送模块525，用于基于第二约车应答消息，向用户终端返回响应于第一约车请求的第一约车应答消息。

约车服务器52中设置网络约车装置，该装置的另一种结构可以如图6b所示，包括：第一接收模块521、确定模块522、第一发送模块523、第二接收模块524和第二发送模块525。

确定模块522，用于根据第一约车请求携带的运力类型和网约车服务商，确定每个网约车服务商提供相应运力类型的车辆类型；或解析出所述第一约车请求中的运力类型和网络约车服务商，得到每个所述网约车服务商所有的车辆类型；

第一发送模块523，用于根据每个网约车服务商的所有车辆类型，向相应网约车服务商的网约车服务平台发送第二约车请求，其中，第二约车请求至少携带所述约车起终点；

可选的，上述第一接收模块521，具体用于：

或者，

可选的，上述确定模块522，具体用于：

可选的，上述第一发送模块523，具体用于：

可选的，上述第二发送模块525，具体用于：

用户终端51中设置约车客户端，该约车客户端的结构如图7所示，包括：信息获取模块511和第三发送模块512。

信息获取模块511，用于获取用户输入的约车起终点和通过约车用户交互界面选择的至少一种运力类型及提供相应运力类型的至少一个网约车服务商。

第三发送模块512，用于发送第一约车请求至约车服务器，以使所述约车服务器向相应的网约车服务商的网约车服务平台请求承运车辆，所述第一约车请求至少携带了所述用户选择的至少一种运力类型、提供相应运力类型的至少一个网约车服务商、及约车起终点。

可选的，上述信息获取模块511，具体用于：

可选的，上述约车客户端，还包括：估价模块513，

估价模块513，用于发送携带所述约车起终点的估价请求至约车服务器，以使所述约车服务器向网约车服务商的网约服务平台请求出行预估费用；在约车用户交互界面，将所述约车服务器返回的其请求来的出行预估费用，按照相应的运力类型及网约车服务商进行展示。

或

估价模块513，用于发送携带所述约车起终点的估价请求至约车服务器，以使所述约车服务器按照所述约车起终点确定相应的出行预估费用；在约车用户交互界面，将所述约车服务器返回的其确定的出行预估费用，按照相应的运力类型及网约车服务商进行展示。

本发明实施例的上述方法和装置，可以根据用户终端发送的第一约车请求，确定用户选择运力类型和网约车服务商，从而确定涉及到的每个网约车服务商提供相应运力类型的车辆类型，实现能够同时向不同的网约车服务商请求预约不同网约车服务商不同类型的承运车辆，只要有任何一个网约车服务商有响应，用户就能成功预约到承运车辆；由于用户可以选择多个网约车服务商多种运力类型进行预约，能够更方便、快捷的预约到合适的承运车辆，减少车辆预约的等待时间，提高约车的成功率，能够尽可能的避免重复约车现象的发生，优化车辆资源的分配。且用户不再需要安装多个约车软件，减少用户设备的系统资源开销，使用一个约车客户端即可，降低了用户操作的复杂度，使约车操作更简单。

实施例二

本发明实施例二提供一种发票开具方法，其流程如图8所示，包括如下步骤：

步骤S301：约车服务器接收用户终端发送的第一发票开具请求。发票开具请求至少携带了至少一个网约车服务商的至少一条开票数据。

用户可以通过用户终端的发票开具交互界面选择要开票的约车订单作为开票数据，用户终端根据用户选择的开票数据生成第一发票开具请求，第一发票开具请求中至少包括约车订单涉及到的网约车服务商和至少一条开票数据，开票数据中可以包括订单的相关信息，比如开票金额等，第一发票开具请求中还可以包括开票信息，比如用户名称、用户代码等等，开票信息可以单独设置，也可以包括在开票数据中。

步骤S302：约车服务器向发票开具请求携带的网约车服务商的网约车服务平台发送第二发票开具请求，其中，第二约车请求至少携带了一条开票数据。

约车服务器根据涉及到的网约车服务商向相应的网约车服务平台发送第二发票开具请求，第二发票开具请求包括的至少一条开票数据中可以包括订单的相关信息，比如开票金额等，第一发票开具请求中还可以包括开票信息，比如用户名称、用户代码等等，开票信息可以单独设置，也可以包括在开票数据中。

步骤S303：约车服务器接收网约车服务平台响应于第二发票开具请求返回的第二发票开具应答消息。

网约车服务平台接收到第二发票开具请求可以向约车服务器返回第二发票开具应答消息。

步骤S304：约车服务器基于接收到的第二发票开具应答消息，向用户终端返回响应于第一发票开具请求的第一发票开具应答消息。

约车服务器接收到第二发票开具应答消息后，可以向用户终端返回第一发票开具应答消息。

上述从约车服务器的角度描述了发票开具方法，此外，本发明实施例二提供一种发票开具方法，从用户终端的角度描述本实施例的发票开具方法，其流程如图9所示，包括如下步骤：

步骤S401：用户终端获取用户通过发票开具交互界面选择的至少一个网约车服务商的至少一条开票数据。

用户可以通过用户终端的发票开具交互界面选择要开票的约车订单作为开票数据，可以选择一个或多个网约车服务商的至少一条开票数据。

步骤S402：用户终端发送第一发票开具请求至约车服务器，以使约车服务器向相应的网约车服务商的网约车服务平台请求发票，其中，第一发票开具请求至少一个网约车服务商的至少一条开票数据。

用户终端根据用户选择的开票数据生成第一发票开具请求发送给约车服务器。

上述方法还包括：

步骤S403：用户终端接收约车服务器返回的响应于第一发票开具请求的第一发票开具应答消息。

约车服务器的处理流程参照上述图8相关的描述。

基于同一发明构思，本发明实施例还提供一种发票开具系统，该系统结构如图10所示，包括：用户终端11、开票服务器12和至少两个网约车服务平台13。

网约车服务平台13用于接收开票服务器发送的第二发票开具请求，向开票服务器返回第二发票开具应答消息。

开票服务器12中设置发票开具装置，该装置的结构如图11所示，包括：第四接收模块121、第四发送模块122、第五接收模块123和第五发送模块124。

第四接收模块121，用于接收用户终端发送的第一发票开具请求，所述发票开具请求至少携带了至少一个网约车服务商的至少一条开票数据；

第四发送模块122，用于向所述发票开具请求携带的网约车服务商的网约车服务平台发送第二发票开具请求，所述第二约车请求至少携带了一条开票数据；

第五接收模块123，用于接收网约车服务平台响应于所述第二发票开具请求返回的第二发票开具应答消息；

第五发送模块124，用于基于接收到的第二发票开具应答消息，向所述用户终端返回响应于所述第一发票开具请求的第一发票开具应答消息。

用户终端11中设置开票客户端，该开票客户端的结构如图12所示，包括：数据获取模块111和第六发送模块112。

数据获取模块111，用于获取所述用户通过发票开具交互界面选择的至少一个网约车服务商的至少一条开票数据；

第六发送模块112，用于发送第一发票开具请求至约车服务器，以使所述约车服务器向相应的网约车服务商的网约车服务平台请求发票，所述第一发票开具请求至少一个网约车服务商的至少一条开票数据。

本发明实施例的上述方法和装置，可以根据用户终端发送的第一开票请求，确定涉及到的每个网约车服务商，分别向各个网约车服务商的网约车服务平台发送开票请求，能够更方便、快捷向多个不同的网约车服务商同时请求开具发票，简化开票操作，减少开票操作时间。

关于上述各实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

除非另外具体陈述，术语比如处理、计算、运算、确定、显示等等可以指一个或更多个处理或者计算系统、或类似设备的动作和/或过程，所述动作和/或过程将表示为处理系统的寄存器或存储器内的物理(如电子)量的数据操作和转换成为类似地表示为处理系统的存储器、寄存器或者其他此类信息存储、发射或者显示设备内的物理量的其他数据。信息和信号可以使用多种不同的技术和方法中的任何一种来表示。例如，在贯穿上面的描述中提及的数据、指令、命令、信息、信号、比特、符号和码片可以用电压、电流、电磁波、磁场或粒子、光场或粒子或者其任意组合来表示。

应该明白，公开的过程中的步骤的特定顺序或层次是示例性方法的实例。基于设计偏好，应该理解，过程中的步骤的特定顺序或层次可以在不脱离本公开的保护范围的情况下得到重新安排。所附的方法权利要求以示例性的顺序给出了各种步骤的要素，并且不是要限于所述的特定顺序或层次。

在上述的详细描述中，各种特征一起组合在单个的实施方案中，以简化本公开。不应该将这种公开方法解释为反映了这样的意图，即，所要求保护的主题的实施方案需要清楚地在每个权利要求中所陈述的特征更多的特征。相反，如所附的权利要求书所反映的那样，本发明处于比所公开的单个实施方案的全部特征少的状态。因此，所附的权利要求书特此清楚地被并入详细描述中，其中每项权利要求独自作为本发明单独的优选实施方案。

本领域技术人员还应当理解，结合本文的实施例描述的各种说明性的逻辑框、模块、电路和算法步骤均可以实现成电子硬件、计算机软件或其组合。为了清楚地说明硬件和软件之间的可交换性，上面对各种说明性的部件、框、模块、电路和步骤均围绕其功能进行了一般地描述。至于这种功能是实现成硬件还是实现成软件，取决于特定的应用和对整个系统所施加的设计约束条件。熟练的技术人员可以针对每个特定应用，以变通的方式实现所描述的功能，但是，这种实现决策不应解释为背离本公开的保护范围。

结合本文的实施例所描述的方法或者算法的步骤可直接体现为硬件、由处理器执行的软件模块或其组合。软件模块可以位于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、移动磁盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质连接至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。该ASIC可以位于用户终端中。当然，处理器和存储介质也可以作为分立组件存在于用户终端中。

对于软件实现，本申请中描述的技术可用执行本申请所述功能的模块(例如，过程、函数等)来实现。这些软件代码可以存储在存储器单元并由处理器执行。存储器单元可以实现在处理器内，也可以实现在处理器外，在后一种情况下，它经由各种手段以通信方式耦合到处理器，这些都是本领域中所公知的。

上文的描述包括一个或多个实施例的举例。当然，为了描述上述实施例而描述部件或方法的所有可能的结合是不可能的，但是本领域普通技术人员应该认识到，各个实施例可以做进一步的组合和排列。因此，本文中描述的实施例旨在涵盖落入所附权利要求书的保护范围内的所有这样的改变、修改和变型。此外，就说明书或权利要求书中使用的术语“包含”，该词的涵盖方式类似于术语“包括”，就如同“包括，”在权利要求中用作衔接词所解释的那样。此外，使用在权利要求书的说明书中的任何一个术语“或者”是要表示“非排它性的或者”。

Claims

一种网络约车方法，其特征在于，包括：

接收用户终端发送的第一约车请求，所述第一约车请求携带至少一种运力类型、提供相应运力类型的至少一个网约车服务商、及约车起终点；

根据所述运力类型和所述网约车服务商，向相应网约车服务商的网约车服务平台发送第二约车请求，所述第二约车请求至少携带所述约车起终点；

接收网约车服务平台响应于所述第二约车请求返回的第二约车应答消息；

基于所述第二约车应答消息，向所述用户终端返回响应于所述第一约车请求的第一约车应答消息。
根据权利要求1所述的方法，其特征在于，根据所述运力类型和所述网约车服务商，确定每个所述网约车服务商提供相应运力类型的车辆类型，包括：

根据所述运力类型和所述网约车服务商，确定每个所述网约车服务商提供相应运力类型的车辆类型；或，解析出所述第一约车请求中的运力类型和网络约车服务商，得到每个所述网约车服务商所有的车辆类型；

根据每个网约车服务商的所有车辆类型，向相应网约车服务商的网约车服务平台发送第二约车请求，所述第二约车请求至少携带所述约车起终点。
根据权利要求2所述的方法，其特征在于，所述接收用户终端发送的第一约车请求，所述第一约车请求携带至少一种运力类型、提供所述运力类型的至少一个网约车服务商、及约车起终点，包括：

接收用户终端发送的第一约车请求，所述第一约车请求至少携带两种以上的运力类型、针对每种运力类型提供该种运力类型的至少一个网约车服务商、及约车起终点；

或者，

接收用户终端发送的第一约车请求，所述第一约车请求携带至少一种运力类型、针对每种运力类型提供该种运力类型的两个以上的网约车服务商、及约车起终点。
根据权利要求2所述的方法，其特征在于，根据所述运力类型和所述网约车服务商，确定每个所述网约车服务商提供相应运力类型的车辆类型，包括：

从所述第一约车请求中，解析出携带的网约车服务商和运力类型；

从预置的运力类型与网约车服务商的车辆类型的配置表中，查找到每个网约车服务商提供相应运力类型的车辆类型。
根据权利要求1所述的方法，其特征在于，

如果网约车服务商的网约车服务平台用一个接口接收所有的车辆类型的约车请求，则向所述网约车服务商的网约车服务平台的接口发送的第二约车请求为一个，且所述第二约车请求中还携带车辆类型；

如果网约车服务商的网约车服务平台一个接口接收一种车辆类型的约车请求，则向所述网约车服务商的网约车服务平台的接口发送的第二约车请求个数与车辆类型的个数相同，所述第二约车请求中不携带车辆类型；

如果网约车服务商的网约车服务平台的第一接口接收两种以上车辆类型的约车请求，第二接口接收一种车辆类型的约车请求，则向所述网约车服务商的网约车服务平台的第一接口发送的第二约车请求还携带车辆类型，向第二接口发送的第二约车请求不携带车辆类型。
根据权利要求1-5任一所述的方法，其特征在于，基于所述第二约车应答消息，向所述用户终端返回响应于所述第一约车请求的第一约车应答消息，包括：

若响应于所述第二约车请求返回的第二约车应答消息仅一个，将所述第二约车应答消息作为响应于所述第一约车请求的第一约车应答消息返回给所述用户终端；

若响应于所述第二约车请求返回的第二约车应答消息有两个以上，按照预设的推荐策略，从接收到的第二约车应答消息中选择预设个数的第二约车应答消息作为响应于所述第一约车请求的第一约车应答消息返回给所述用户终端。
一种网络约车方法，其特征在于，包括：

获取用户输入的约车起终点和通过约车用户交互界面选择的至少一种运力类型及提供相应运力类型的至少一个网约车服务商；

发送第一约车请求至约车服务器，以使所述约车服务器向相应的网约车服务商的网约车服务平台请求承运车辆，所述第一约车请求至少携带了所述用户选择的至少一种运力类型、提供相应运力类型的至少一个网约车服务商、及约车起终点。
根据权利要求7所述的方法，其特征在于，所述获取所述用户通过约车用户交互界面选择的至少一种运力类型及提供相应运力类型的至少一个网约车服务商具体包括：

获取所述用户通过约车用户交互界面选择的两种以上的运力类型及提供相应运力类型的至少一个网约车服务商或者所述用户通过约车用户交互界面选择的至少一种运力类型及提供相应运力类型的两种以上的网约车服务商。
根据权利要求7或8所述的方法，其特征在于，所述方法进一步包括：

发送携带所述约车起终点的估价请求至约车服务器，以使所述约车服务器向网约车服务商的网约服务平台请求出行预估费用；

在约车用户交互界面，将所述约车服务器返回的其请求来的出行预估费用，按照相应的运力类型及网约车服务商进行展示。
根据权利要求7或8所述的方法，其特征在于，所述方法进一步包括：

发送携带所述约车起终点的估价请求至约车服务器，以使所述约车服务器按照所述约车起终点确定相应的出行预估费用；

在约车用户交互界面，将所述约车服务器返回的其确定的出行预估费用，按照相应的运力类型及网约车服务商进行展示。
一种发票开具方法，其特征在于，包括：

接收用户终端发送的第一发票开具请求，所述第一发票开具请求至少携带了至少一个网约车服务商的至少一条开票数据；

向所述第一发票开具请求携带的网约车服务商的网约车服务平台发送第二发票开具请求，所述第二发票开具请求至少携带了一条开票数据；

接收网约车服务平台响应于所述第二发票开具请求返回的第二发票开具应答消息；

基于接收到的第二发票开具应答消息，向所述用户终端返回响应于所述第一发票开具请求的第一发票开具应答消息。
一种发票开具方法，其特征在于，包括：

获取用户通过发票开具交互界面选择的至少一个网约车服务商的至少一条开票数据；

发送第一发票开具请求至约车服务器，以使所述约车服务器向相应的网约车服务商的网约车服务平台请求发票，所述第一发票开具请求至少一个网约车服务商的至少一条开票数据。
一种网络约车装置，其特征在于，包括：

第一接收模块，用于接收用户终端发送的第一约车请求，所述第一约车请求携带至少一种运力类型、提供相应运力类型的至少一个网约车服务商、及约车起终点；

第一发送模块，用于根据所述运力类型和所述网约车服务商，向相应网约车服务商的网约车服务平台发送第二约车请求，所述第二约车请求至少携带所述约车起终点；

第二接收模块，用于接收网约车服务平台响应于所述第二约车请求返回的第二约车应答消息；

第二发送模块，用于基于所述第二约车应答消息，向所述用户终端返回响应于所述第一约车请求的第一约车应答消息。
如权利要求13所述的装置，其特征在于，还包括：

确定模块，用于根据所述运力类型和所述网约车服务商，确定每个所述网约车服务商提供相应运力类型的车辆类型；或解析出所述第一约车请求中的运力类型和网络约车服务商，得到每个所述网约车服务商所有的车辆类型；

所述第一发送模块，具体用于根据每个网约车服务商的所有车辆类型，向相应网约车服务商的网约车服务平台发送第二约车请求，所述第二约车请求至少携带所述约车起终点。
如权利要求14所述的装置，其特征在于，所述第一接收模块，具体用于：

接收用户终端发送的第一约车请求，所述第一约车请求至少携带两种以上的运力类型、针对每种运力类型提供该种运力类型的至少一个网约车服务商、及约车起终点；

或者，

接收用户终端发送的第一约车请求，所述第一约车请求携带至少一种运力类型、针对每种运力类型提供该种运力类型的两个以上的网约车服务商、及约车起终点。
如权利要求14所述的装置，其特征在于，所述确定模块，具体用于：

从所述第一约车请求中，解析出携带的网约车服务商和运力类型；

从预置的运力类型与网约车服务商的车辆类型的配置表中，查找到每个网约车服务商提供相应运力类型的车辆类型。
如权利要求13所述的装置，其特征在于，所述第一发送模块，具体用于：

如果网约车服务商的网约车服务平台用一个接口接收所有的车辆类型的约车请求，则向所述网约车服务商的网约车服务平台的接口发送的第二约车请求为一个，且所述第二约车请求中还携带车辆类型；

如果网约车服务商的网约车服务平台一个接口接收一种车辆类型的约车请求，则向所述网约车服务商的网约车服务平台的接口发送的第二约车请求个数与车辆类型的个数相同，所述第二约车请求中不携带车辆类型；

如果网约车服务商的网约车服务平台的第一接口接收两种以上车辆类型的约车请求，第二接口接收一种车辆类型的约车请求，则向所述网约车服务商的网约车服务平台的第一接口发送的第二约车请求还携带车辆类型，向第二接口发送的第二约车请求不携带车辆类型。
如权利要求13-17任一所述的装置，其特征在于，所述第二发送模块，具体用于：

若响应于所述第二约车请求返回的第二约车应答消息仅一个，将所述第二约车应答消息作为响应于所述第一约车请求的第一约车应答消息返回给所述用户终端；

若响应于所述第二约车请求返回的第二约车应答消息有两个以上，按照预设的推荐策略，从接收到的第二约车应答消息中选择预设个数的第二约车应答消息作为响应于所述第一约车请求的第一约车应答消息返回给所述用户终端。
一种约车客户端，其特征在于，包括：

信息获取模块，用于获取用户输入的约车起终点和通过约车用户交互界面选择的至少一种运力类型及提供相应运力类型的至少一个网约车服务商；

第三发送模块，用于发送第一约车请求至约车服务器，以使所述约车服务器向相应的网约车服务商的网约车服务平台请求承运车辆，所述第一约车请求至少携带了所述用户选择的至少一种运力类型、提供相应运力类型的至少一个网约车服务商、及约车起终点。
如权利要求19所述的约车客户端，其特征在于，所述信息获取模块，具体用于：

获取所述用户通过约车用户交互界面选择的两种以上的运力类型及提供相应运力类型的至少一个网约车服务商或者所述用户通过约车用户交互界面选择的至少一种运力类型及提供相应运力类型的两种以上的网约车服务商。
如权利要求19或20所述的约车客户端，其特征在于，还包括：

估价模块，用于发送携带所述约车起终点的估价请求至约车服务器，以使所述约车服务器向网约车服务商的网约服务平台请求出行预估费用；在约车用户交互界面，将所述约车服务器返回的其请求来的出行预估费用，按照相应的运力类型及网约车服务商进行展示。
如权利要求19或20所述的约车客户端，其特征在于，还包括：

估价模块，用于发送携带所述约车起终点的估价请求至约车服务器，以使所述约车服务器按照所述约车起终点确定相应的出行预估费用；在约车用户交互界面，将所述约车服务器返回的其确定的出行预估费用，按照相应的运力类型及网约车服务商进行展示。
一种网络约车系统，其特征在于，包括：用户终端、约车服务器和至少两个网约车服务平台；

所述用户终端中设置如权利要求19-22任一所述的约车客户端；

所述约车服务器中设置如权利要求13-18任一所述的网络约车装置；

所述网约车服务平台用于接收约车服务器发送的第二约车请求，当有承运车辆响应所述第二约车请求时，向约车服务器返回第二约车应答消息。
一种发票开具装置，其特征在于，包括：

第四接收模块，用于接收用户终端发送的第一发票开具请求，所述第一发票开具请求至少携带了至少一个网约车服务商的至少一条开票数据；

第四发送模块，用于向所述第一发票开具请求携带的网约车服务商的网约车服务平台发送第二发票开具请求，所述第二发票开具请求至少携带了一条开票数据；

第五接收模块，用于接收网约车服务平台响应于所述第二发票开具请求返回的第二发票开具应答消息；

第五发送模块，用于基于接收到的第二发票开具应答消息，向所述用户终端返回响应于所述第一发票开具请求的第一发票开具应答消息。
一种开票客户端，其特征在于，包括：

数据获取模块，用于获取用户通过发票开具交互界面选择的至少一个网约车服务商的至少一条开票数据；

第六发送模块，用于发送第一发票开具请求至约车服务器，以使所述约车服务器向相应的网约车服务商的网约车服务平台请求发票，所述第一发票开具请求至少一个网约车服务商的至少一条开票数据。
一种发票开具系统，其特征在于，包括：用户终端、开票服务器和至少两个网约车服务平台；

所述用户终端中设置如权利要求25所述的开票客户端；

所述约车服务器中设置如权利要求24所述的发票开具装置；

所述网约车服务平台用于接收开票服务器发送的第二发票开具请求，向开票服务器返回第二发票开具应答消息。
一种计算机存储介质，其特征在于，所述计算机存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器执行时实现权利要求1-10任一所述的网络约车方法或实现权利要求11-12任一所述的发票开具方法。
一种服务器，其特征在于，包括：存储器、处理器及存储于存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现权利要求1-6任一所述的网络约车方法或实现权利要求11所述的发票开具方法。
一种用户终端，其特征在于，包括：存储器、处理器及存储于存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现权利要求7-10任一所述的网络约车方法或实现权利要求12所述的发票开具方法。