著录项信息
专利名称 | 一种提供打车服务的方法、装置及系统 |
申请号 | CN201310751822.9 | 申请日期 | 2013-12-31 |
法律状态 | 权利终止 | 申报国家 | 中国 |
公开/公告日 | 2014-03-26 | 公开/公告号 | CN103680134A |
优先权 | 暂无 | 优先权号 | 暂无 |
主分类号 | G08G1/00 | IPC分类号 | G;0;8;G;1;/;0;0;;;H;0;4;L;2;9;/;0;8查看分类表>
|
申请人 | 北京东方车云信息技术有限公司 | 申请人地址 | 北京市丰台区南四环西路188号总部基地二区10号楼3层(园区)
变更
专利地址、主体等相关变化,请及时变更,防止失效 |
权利人 | 北京东方车云信息技术有限公司 | 当前权利人 | 北京东方车云信息技术有限公司 |
发明人 | 汤鹏 |
代理机构 | 北京中强智尚知识产权代理有限公司 | 代理人 | 姜精斌 |
摘要
本发明实施例提供了一种提供打车服务的方法、装置及系统,其中方法包括:将携带有语音打车请求信息的打车服务订单推送至符合设定条件的至少一个司机侧的车载终端;所述语音打车请求信息包含乘客的出发地信息和目的地信息;接收司机侧的车载终端返回的语音响应消息;当识别出所述语音响应信息的内容为确认接单时,将打车服务订单成功消息返回至乘客客户端。本发明采用了司机侧车载终端语音接单的方式,能够解决现有打车软件在使用过程中对出租车司机来说造成的交通安全隐患和不够便捷的问题。
1.一种提供打车服务的方法,其特征在于,包括:
将携带有语音打车请求信息的打车服务订单推送至符合设定条件的至少一个司机侧的车载终端;所述语音打车请求信息包含乘客的出发地信息和目的地信息;
接收司机侧的车载终端返回的语音响应消息;
采用语音识别技术对所述语音响应消息中的内容进行识别;
当识别出所述语音响应消息的内容为确认接单时,将打车服务订单成功消息返回至乘客客户端。
2.如权利要求1所述的方法,其特征在于,所述打车服务订单中的语音打车请求信息,具体通过下述方式得到:
当接收到所述乘客客户端发出的打车请求信息为音频形式时,将所述乘客客户端发出的打车请求信息作为所述打车服务订单中的语音打车请求信息;
当接收到的所述乘客客户端发出的打车请求信息为文本形式时,将所述文本形式的打车请求信息转换成音频形式,并将所述转换后的打车请求信息作为所述打车服务订单中的语音打车请求信息。
3.如权利要求1或2所述的方法,其特征在于,所述打车服务订单中还包括:乘客的起始地址信息,所述乘客的起始地址信息用于在所述司机侧的车载终端上显示当前乘客的地理位置。
4.如权利要求1或2所述的方法,其特征在于,将所述订单推送至符合设定条件的至少一个司机侧的车载终端,包括:
根据本地保存的各司机侧的车载终端当前的地理位置信息,确定当前距离发送打车请求信息的乘客的起始地址在预设的地理范围内的各司机侧的车载终端;
根据确定出各司机侧的车载终端与所述乘客的起始地址的距离,估算确定出的各司机侧的车载终端到达所述乘客的起始地址的时间;
根据估算出的各司机侧的车载终端到达所述乘客的起始地址的时间的长短,对各司机侧的车载终端的订单推送优先级进行排序;所述到达所述乘客起始地址时间短的司机侧的车载终端,较到达所述乘客的起始地址时间长的车载终端优先级高;
根据订单推送优先级排序的结果,向将所述订单依次推送至确定出的各司机侧的车载终端。
5.如权利要求1或2所述的方法,其特征在于,当对所述语音响应消息中的内容识别失败时,还包括:
向发出该语音响应消息的所述司机侧的车载终端发送重复输入所述语音响应消息的命令。
6.一种提供打车服务的服务器,其特征在于,包括:
订单生成模块,用于生成携带有语音打车请求信息的打车服务订单;所述语音打车请求信息包含乘客的出发地信息和目的地信息;
推送模块,用于将所述携带有语音打车请求信息的打车服务订单推送至符合设定条件的至少一个司机侧的车载终端;
识别模块,用于接收司机侧的车载终端返回的语音响应消息并识别其内容;其中具体用于采用语音识别技术对所述语音响应消息中的内容进行识别;
订单响应模块,用于当所述识别模块识别出所述语音响应信息的内容为确认接单时,将打车服务订单成功消息返回至乘客客户端。
7.如权利要求6所述的服务器,其特征在于,还包括:打车请求接收模块,用于接收乘客客户端发出的打车请求信息,所述打车请求信息为音频形式或者文本形式;
所述订单生成模块,还用于当所述乘客客户端发出的打车请求信息为音频形式时,将所述乘客客户端发出的打车请求信息作为所述打车服务订单中的语音打车请求信息;以及当所述乘客客户端发出的打车请求信息为文本形式时,将所述文本形式的打车请求消息转换成音频形式,并将所述转换后的打车请求信息作为所述打车服务订单中的语音打车请求信息。
8.如权利要求6或7所述的服务器,其特征在于,所述打车服务订单中还包括:乘客的起始地址信息,所述乘客的起始地址信息用于在所述司机侧的车载终端侧显示当前乘客的地理位置。
9.如权利要求6或7所述的服务器,其特征在于,所述推送模块,具体用于根据本地保存的各司机侧的车载终端当前的地理位置信息,确定当前距离发送打车请求信息的乘客的起始地址在预设的地理范围内的各司机侧的车载终端;根据确定出各司机侧的车载终端与所述乘客的起始地址的距离,估算确定出的各司机侧的车载终端到达所述乘客的起始地址的时间;根据估算出的各司机侧的车载终端到达所述乘客的起始地址的时间的长短,对各司机侧的车载终端的订单推送优先级进行排序;所述到达所述乘客起始地址时间短的司机侧的车载终端,较到达所述乘客的起始地址时间长的车载终端优先级高;根据订单推送优先级排序的结果,向将所述订单依次推送至确定出的各司机侧的车载终端。
10.如权利要求6或7所述的服务器,其特征在于,所述识别模块,还用于当对所述语音响应消息中的内容识别失败时,向发出该语音响应消息的司机侧的车载终端发送重复输入所述语音响应消息的命令。
11.一种提供打车服务的系统,其特征在于,包括:
服务器,用于将携带有语音打车请求信息的打车服务订单推送至符合设定条件的至少一个司机侧的车载终端;所述语音打车请求信息包含乘客的出发地信息和目的地信息;接收司机侧的车载终端返回的语音响应消息,采用语音识别技术对所述语音响应消息中的内容进行识别;当识别出所述语音响应信息的内容为确认接单时,将打车服务订单成功消息返回至发出打车请求的乘客客户端;
至少一个司机侧的车载终端,用于接收所述服务器推送的打车服务订单并播放所述语音打车请求信息,接收司机发出的语音响应消息并返回给所述服务器;
至少一个乘客客户端,用于将乘客打车请求信息发送至服务器,以及接收服务器返回的打车服务订单成功消息。
12.如权利要求11所述的系统,其特征在于,所述乘客客户端,具体用于将音频形式或文本形式的乘客打车请求信息发送给服务器;音频形式或文本形式的乘客打车请求信息中包含乘客的出发地信息和目的地信息;
所述服务器,具体用于当所述乘客打车请求信息为音频形式时,将所述乘客打车请求信息作为所述打车服务订单中的语音打车请求信息;以及当所述乘客打车请求信息为文本形式时,将所述文本形式的打车请求消息转换成音频形式,并将所述转换后的乘客打车请求信息作为所述打车服务订单中的语音打车请求信息。
一种提供打车服务的方法、装置及系统\n技术领域\n[0001] 本发明涉及智能终端的应用领域,尤其涉及一种提供打车服务的方法、装置及系统。\n背景技术\n[0002] 在当前人口密集的城市之中,由于交通状况的复杂性,经常出现下述情况:大量的出租车空驶不断寻找需要打车的乘客,另外一方面,有打车需求的乘客在出发地附近又很难等到空驶的车辆,这种打车信息的不对称,导致了城市打车难的问题,同时也浪费了有限的公共资源、能源资源以及乘客和出租车司机的时间资源,为了解决这一难题,目前不断涌现出许多基于手持智能终端的应用即打车软件,这些打车软件安装于乘客的手持智能终端上(以下简称乘客客户端),提供打车服务的流程如下:\n[0003] 乘客客户端向服务器端发送需要打车的请求,服务器端根据该请求,生成订单信息向符合一定条件的出租车的车载终端进行推送,当使用车载终端的出租车司机根据自身运营情况选择接单时,则订单完成,乘客和出租车司机之间完成打车交易。\n[0004] 现有的打车软件在使用过程中,司机经常需要腾出时间在车载终端提供的界面上手工选择是否接单,这种方式,对于经常在路上行驶的出租车司机来说,一方面会造成交通安全的隐患,同时对于出租车司机来说,也不够便捷。\n发明内容\n[0005] 本发明实施例提供了一种提供打车服务的方法、装置及系统,用以解决现有打车软件在使用过程中对出租车司机来说造成的交通安全隐患和不够便捷的问题。\n[0006] 基于上述问题,第一方面,本发明实施例提供了一种提供打车服务的方法,包括:\n[0007] 将携带有语音打车请求信息的打车服务订单推送至符合设定条件的至少一个司机侧的车载终端;所述语音打车请求信息包含乘客的出发地信息和目的地信息;\n[0008] 接收司机侧的车载终端返回的语音响应消息;\n[0009] 当识别出所述语音响应消息的内容为确认接单时,将打车服务订单成功消息返回至乘客客户端。\n[0010] 进一步地,上述打车服务订单中的语音打车请求信息,具体通过下述方式得到:\n[0011] 当接收到所述乘客客户端发出的打车请求信息为音频形式时,将所述乘客客户端发出的打车请求信息作为所述打车服务订单中的语音打车请求信息;\n[0012] 当接收到的所述乘客客户端发出的打车请求信息为文本形式时,将所述文本形式的打车请求信息转换成音频形式,并将所述转换后的打车请求信息作为所述打车服务订单中的语音打车请求信息。\n[0013] 所述打车服务订单中还包括:乘客的起始地址信息,所述乘客的起始地址信息用于在所述司机侧的车载终端上显示当前乘客的地理位置。\n[0014] 进一步地,所述将所述订单推送至符合设定条件的至少一个司机侧的车载终端,包括:\n[0015] 根据本地保存的各司机侧的车载终端当前的地理位置信息,确定当前距离发送打车请求信息的乘客的起始地址在预设的地理范围内的各司机侧的车载终端;\n[0016] 根据确定出各司机侧的车载终端与所述乘客的起始地址的距离,估算确定出的各司机侧的车载终端到达所述乘客的起始地址的时间;\n[0017] 根据估算出的各司机侧的车载终端到达所述乘客的起始地址的时间的长短,对各司机侧的车载终端的订单推送优先级进行排序;所述到达所述乘客起始地址时间短的司机侧的车载终端,较到达所述乘客的起始地址时间长的车载终端优先级高;\n[0018] 根据订单推送优先级排序的结果,向将所述订单依次推送至确定出的各司机侧的车载终端。\n[0019] 进一步地,采用语音合识别技术对所述语音响应消息中的内容进行识别。\n[0020] 进一步地,当对所述语音响应消息中的内容识别失败时,还包括:\n[0021] 向发出该语音响应消息的所述司机侧的车载终端发送重复输入所述语音响应消息的命令。\n[0022] 第二方面,本发明实施例提供的一种提供打车服务的服务器,包括:\n[0023] 订单生成模块,用于生成携带有语音打车请求信息的打车服务订单;所述语音打车请求信息包含乘客的出发地信息和目的地信息;\n[0024] 推送模块,用于将所述携带有语音打车请求信息的打车服务订单推送至符合设定条件的至少一个司机侧的车载终端;\n[0025] 识别模块,用于接收司机侧的车载终端返回的语音响应消息并识别其内容;\n[0026] 订单响应模块,用于当所述识别模块识别出所述语音响应信息的内容为确认接单时,将打车服务订单成功消息返回至乘客客户端。\n[0027] 进一步地,上述提供打车服务的服务器,还包括:打车请求接收模块,用于接收乘客客户端发出的打车请求信息,所述打车请求信息为音频形式或者文本形式;\n[0028] 所述订单生成模块,还用于当所述乘客客户端发出的打车请求信息为音频形式时,将所述乘客客户端发出的打车请求信息作为所述打车服务订单中的语音打车请求信息;以及当所述乘客客户端发出的打车请求信息为文本形式时,将所述文本形式的打车请求消息转换成音频形式,并将所述转换后的打车请求信息作为所述打车服务订单中的语音打车请求信息。\n[0029] 所述打车服务订单中还包括:乘客的起始地址信息,所述乘客的起始地址信息用于在所述司机侧的车载终端侧显示当前乘客的地理位置。\n[0030] 进一步地,上述推送模块,具体用于根据本地保存的各司机侧的车载终端当前的地理位置信息,确定当前距离发送打车请求信息的乘客的起始地址在预设的地理范围内的各司机侧的车载终端;根据确定出各司机侧的车载终端与所述乘客的起始地址的距离,估算确定出的各司机侧的车载终端到达所述乘客的起始地址的时间;根据估算出的各司机侧的车载终端到达所述乘客的起始地址的时间的长短,对各司机侧的车载终端的订单推送优先级进行排序;所述到达所述乘客起始地址时间短的司机侧的车载终端,较到达所述乘客的起始地址时间长的车载终端优先级高;根据订单推送优先级排序的结果,向将所述订单依次推送至确定出的各司机侧的车载终端。\n[0031] 进一步地,上述识别模块,具体用于采用语音识别技术对所述语音响应消息中的内容进行识别。\n[0032] 进一步地,上述识别模块,还用于当对所述语音响应消息中的内容识别失败时,向发出该语音响应消息的司机侧的车载终端发送重复输入所述语音响应消息的命令。\n[0033] 第三方面,本发明实施例提供了一种提供打车服务的系统,包括:\n[0034] 服务器,用于将携带有语音打车请求信息的打车服务订单推送至符合设定条件的至少一个司机侧的车载终端;所述语音打车请求信息包含乘客的出发地信息和目的地信息;接收司机侧的车载终端返回的语音响应消息;当识别出所述语音响应信息的内容为确认接单时,将打车服务订单成功消息返回至发出打车请求的乘客客户端;\n[0035] 至少一个司机侧的车载终端,用于接收所述服务器推送的打车服务订单并播放所述语音打车请求信息,接收司机发出的语音响应消息并返回给所述服务器;\n[0036] 至少一个乘客客户端,用于将乘客打车请求信息发送至服务器,以及接收服务器返回的打车服务订单成功消息。\n[0037] 进一步地,所述乘客客户端,具体用于将音频形式或文本形式的乘客打车请求信息发送给服务器;音频形式或文本形式的乘客打车请求信息中包含乘客的出发地信息和目的地信息;\n[0038] 所述服务器,具体用于当所述乘客打车请求信息为音频形式时,将所述乘客打车请求信息作为所述打车服务订单中的语音打车请求信息;以及当所述乘客打车请求信息为文本形式时,将所述文本形式的打车请求消息转换成音频形式,并将所述转换后的乘客打车请求信息作为所述打车服务订单中的语音打车请求信息。\n[0039] 本发明实施例的有益效果包括:\n[0040] 本发明实施例提供的提供打车服务的方法、装置及系统,在服务器侧对乘客客户端发出的打车请求进行处理,将语音形式的打车请求信息携带在打车服务订单中,推送给司机侧车载终端,使得司机侧车载终端可采用播放音频的方式让司机知晓乘客的出发地和目的地,并且,也无需采用现有在车载终端的界面上进行手工选择是否接单的方式,也就是说,司机也可采用语音接单的方式来实现打车交易的完成,在提供打车服务的整个流程中,出租车司机不用在驾驶车辆时分心查看车载终端上显示的乘客出发地和目的地,也无需采用手工输入是否接单的操作,因此,提高了司机在行驶过程中的安全性,同时也为出租车司机提供了相当的便利。\n附图说明\n[0041] 为了更清楚地说明本发明实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简要介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域的普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。\n[0042] 图1为本发明实施例提供的提供打车服务的方法的流程图;\n[0043] 图2为本发明实施例提供的提供打车服务的服务器的结构示意图;\n[0044] 图3为本发明实施例提供的提供打车服务的系统的结构示意图。\n具体实施方式\n[0045] 为了使本发明的目的、技术方案和优点更加清楚,下面将结合附图对本发明作进一步地详细描述,显然,所描述的实施例仅仅是本发明一部份实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例,都属于本发明保护的范围。\n[0046] 本发明实施例提供的一种提供打车服务的方法,如图1所示,具体包括以下步骤:\n[0047] S101、将携带有语音打车请求信息的打车服务订单推送至符合设定条件的至少一个司机侧的车载终端;该语音打车请求信息包含乘客的出发地信息和目的地信息;\n[0048] S102、接收司机侧的车载终端返回的语音响应消息;\n[0049] S103、当识别出语音响应信息的内容为确认接单时,将打车服务订单成功消息返回至乘客客户端。\n[0050] 下面对上述各步骤进行进一步地的说明。\n[0051] 上述步骤S101中,服务器端推送给车载终端的语音打车请求信息,在具体实施时,可以有下述两个来源:\n[0052] 第一个:\n[0053] 当乘客客户端发出的打车请求信息为音频形式时,这种情况下可以直接将乘客客户端发出的打车请求信息就作为打车服务订单中的语音打车请求信息;\n[0054] 第二个:\n[0055] 当乘客客户端发出的打车请求信息为文本形式时,这种情况下可以将文本形式的打车请求信息转换成音频形式,将转换后的打车请求信息作为打车服务订单中的语音打车请求信息。\n[0056] 换言之,在乘客客户端侧,可以提供给乘客两种发出打车请求的方式,一种是乘客打开打车软件,根据打车软件界面的提示在界面上点击相应语音输入按钮,说出自身的出发地和想要去的目的地,即语音方式的打车请求,例如语音输入:“我在甲地,我需要去乙地”。另一种是乘客打开打车软件,根据打车软件的提示,通过键盘输入或手写输入方式输入自身的出发地(也可通过乘客客户端采集地理信息后自动生成供用户选择)和想去的目的地,形成文本形式的打车请求。\n[0057] 上述将文本形式打车请求信息转换成音频形式的打车请求信息,具体可以采用例如语音合成技术(又称为“从文本到语音”,Text To Speech,TTS)等方式进行转换。\n[0058] 较佳地,为了提高数据传输效率,节省用户数据流量,乘客客户端采用语音方式发送打车请求时,可以对该语音打车请求进行压缩再发送给服务器侧,由服务器侧可将其携带在打车服务订单中发送给司机侧的车载终端,当乘客客户端采用文本形式发送的打车请求时,服务器侧将其转换成音频形式的打车请求信息后,也可以对其进行压缩,将压缩后的音频形式的打车请求携带在打车服务订单之中发给司机侧的车载终端,接收到打车服务订单的司机侧的车载终端可以对其进行解压缩处理后再进行播放。\n[0059] 上述压缩和解压缩的技术,可以采用现有技术中多种音频压缩和解压缩的技术,例如基于开源代码的FFmpeg(Fast Forward Moving Pictures Experts Group)的压缩和解压缩算法等。\n[0060] 较佳地,上述步骤S101中,乘客客户端侧还可以将乘客的起始地址信息与发送语音打车请求(或文本打车请求)一同发送给服务器侧,在这里,乘客的起始地址信息与前述乘客语音输入或者文本输入的出发地信息的含义不同,乘客一般会使用通用地名来表述自身的出发地(比如甲地),而乘客的起始地址信息是指乘客客户端获取到的自身经纬度信息,乘客客户端侧将乘客的起始地址信息发送至服务器侧之后,服务器将其携带在订单中发送给司机侧的车载终端。\n[0061] 司机侧的车载终端接收到订单后,会形成一个语音形式的条目,由司机选择播放或者自动播放,同时,还可根据该订单中携带的乘客的起始地址信息,将当前发出打车请求的乘客所在的地理位置通过在电子地图上标示出来,这样的设计方式,在司机侧的车载终端上可以实时显示当前发出打车请求的所有乘客所在的地理位置,司机可结合听到的语音打车请求信息以及乘客所在的地理位置来决定是否要接单。\n[0062] 进一步地,上述乘客客户端可以采用多种方式进行自我定位来确定自身的起始地址信息,例如采用全球定位系统(Global Positioning System,GPS)或无线保真(Wireless Fidelity,WIFI)定位的方式(例如用户可以选择在有WIFI信号的情况下,使用WIFI定位的方式,如果没有WIFI信号,则采用GPS定位的方式)。\n[0063] 进一步地,上述步骤S101中,服务器侧可通过下述方式将订单推送至符合设定条件的至少一个司机侧的车载终端:\n[0064] 1、根据服务器本地保存的各司机侧的车载终端当前的地理位置信息,确定当前距离发送语音打车请求信息的乘客的起始地址在预设的地理范围内的各司机侧的车载终端;\n[0065] 司机侧的车载终端会实时地告知服务器侧,服务器侧会记录各司机侧的车载终端当前的地理位置并实时更新,这样,根据各司机侧的车载终端的当前的地理位置,以及请求打车的乘客所在的起始地址(即乘客客户端的起始位置),可以确定距离该乘客在设定的范围内(例如3公里范围内)所有的司机侧的车载终端。\n[0066] 2、根据确定出各司机侧的车载终端与所述乘客的起始地址之间的距离,估算确定出的各司机侧的车载终端到达所述乘客的起始地址的时间;\n[0067] 确定出在设定范围内的司机侧的车载终端之后,根据每个车载终端与该乘客的起始地址之间的距离,可以估算出各司机侧的车载终端到达乘客起始地址的时间;\n[0068] 具体估算时,可以根据车辆在该路段通常的车速来计算到达的时间长短,较佳地,还可以考虑各个司机侧的车载终端与该乘客之间经过的路径的交通状况,动态估计每个司机侧的车载终端到达乘客起始地址的时间。\n[0069] 3、根据估算出的各司机侧的车载终端到达乘客的起始地址之间的距离,各司机侧的车载终端到达乘客的起始地址的时间的长短,对各司机侧的车载终端的订单推送优先级进行排序,排序的原则为:到达所述乘客起始地址时间短的司机侧的车载终端,较到达乘客的起始地址时间长的车载终端优先级高;\n[0070] 4、根据订单推送优先级排序的结果,向将所述订单依次推送至确定出的各司机侧的车载终端。\n[0071] 本发明实施例在具体实施时,在进行订单推送优先级排序时,可以将一定时间范围内的司机侧的车载终端都设置于同一个优先级内,举例来说,司机侧的车载终端到达乘客的起始地址的时间在5分钟以内的是第一优先级的,最先推送,司机侧的车载终端到达乘客的起始地址的时间在5-10分钟以内的是第二优先级的,次优先级推送,司机侧的车载终端到达乘客的起始地址的时间在10-15分钟以内的是第三优先级的,最晚推送。\n[0072] 进一步地,上述S102中,车载终端返回的语音响应消息是司机根据车载终端播放的音频形式的打车请求信息返回的语音形式的响应消息,也就是说,在司机侧的车载终端播放完毕音频形式的打车请求信息之后,将在设定的时间内等待司机语音输入是否接单的相关信息(例如自动开启麦克风,采集司机的语音响应消息),当司机发出“接单”、“不接单”、“接受”、“拒绝”或者其他类似的语音响应消息时,车载终端将其进行压缩处理后传输至服务器侧。\n[0073] 进一步地,上述步骤S103中,服务器侧需要对司机发出的语音响应消息的内容进行语义识别,当识别出该语音响应的内容为确认接单时,将打车服务订单成功消息(携带有司机侧的联系方式)返回给乘客客户端,乘客客户端接到该订单成功消息后,改变该订单的状态为交易成功状态,乘客在打车软件的界面上就可以看到接单成功的消息,并且通过界面显示的司机侧的联系方式与出租车司机进行直接联系。\n[0074] 较佳地,服务器侧对司机发出的语音响应消息的内容进行语义识别,可以采用语音识别技术(ASR,Automatic Speech Recognition)等技术来实现。\n[0075] 当订单成功消息返回给乘客客户端后,服务器侧就不再将该语音打车请求信息向其他司机侧车载终端推送。\n[0076] 如果在设定的时长内,没有司机侧车载终端返回确认接单的语音响应消息时,需要向乘客客户端返回“订单失败”的消息。\n[0077] 较佳地,如果在服务器侧对语音响应消息中的内容识别失败时,还需要向发出该语音响应消息司机侧的车载终端发送重复输入所述语音响应消息的命令。\n[0078] 基于同一发明构思,本发明实施例还提供了一种提供打车服务的服务器及系统,由于该服务器和系统所解决问题的原理与前述提供打车服务的方法相似,因此该服务器和系统的实施可以参见前述方法的实施,重复之处不再赘述。\n[0079] 本发明实施例提供的提供打车服务的服务器,如图2所示,包括:\n[0080] 订单生成模块201,用于生成携带有语音打车请求信息的打车服务订单;所述语音打车请求信息包含乘客的出发地信息和目的地信息;\n[0081] 推送模块202,用于将所述携带有语音打车请求信息的打车服务订单推送至符合设定条件的至少一个司机侧的车载终端;\n[0082] 识别模块203,用于接收司机侧的车载终端返回的语音响应消息并识别其内容;\n[0083] 订单响应模块204,用于当所述识别模块识别出所述语音响应信息的内容为确认接单时,将打车服务订单成功消息返回至乘客客户端。\n[0084] 进一步地,上述提供打车服务的服务器,还包括:打车请求接收模块205,用于接收乘客客户端发出的打车请求信息,所述打车请求信息为音频形式或者文本形式;\n[0085] 相应地,上述订单生成模块201,还用于当乘客客户端发出的打车请求信息为音频形式时,将所述乘客客户端发出的打车请求信息作为所述打车服务订单中的语音打车请求信息;以及当所述乘客客户端发出的打车请求信息为文本形式时,将所述文本形式的打车请求消息转换成音频形式,并将所述转换后的打车请求信息作为所述打车服务订单中的语音打车请求信息。\n[0086] 进一步地,上述打车服务订单中还包括:乘客的起始地址信息,所述乘客的起始地址信息用于在所述司机侧的车载终端侧显示当前乘客的地理位置。\n[0087] 进一步地,上述推送模块202,具体用于根据本地保存的各司机侧的车载终端当前的地理位置信息,确定当前距离发送打车请求信息的乘客的起始地址在预设的地理范围内的各司机侧的车载终端;根据确定出各司机侧的车载终端与所述乘客的起始地址的距离,估算确定出的各司机侧的车载终端到达所述乘客的起始地址的时间;根据估算出的各司机侧的车载终端到达所述乘客的起始地址的时间的长短,对各司机侧的车载终端的订单推送优先级进行排序;所述到达所述乘客起始地址时间短的司机侧的车载终端,较到达所述乘客的起始地址时间长的车载终端优先级高;根据订单推送优先级排序的结果,向将所述订单依次推送至确定出的各司机侧的车载终端。\n[0088] 进一步地,上述识别模块203,具体用于采用语音识别技术对所述语音响应消息中的内容进行识别。\n[0089] 进一步地,上述识别模块203,还用于当对语音响应消息中的内容识别失败时,向发出该语音响应消息的司机侧的车载终端发送重复输入所述语音响应消息的命令。\n[0090] 本发明实施例提供的一种提供打车服务的系统,如图3所示,包括:\n[0091] 服务器301,用于将携带有语音打车请求信息的打车服务订单推送至符合设定条件的至少一个司机侧的车载终端;所述语音打车请求信息包含乘客的出发地信息和目的地信息;接收司机侧的车载终端返回的语音响应消息;当识别出所述语音响应信息的内容为确认接单时,将打车服务订单成功消息返回至发出打车请求的乘客客户端;\n[0092] 至少一个司机侧的车载终端302,用于接收所述服务器推送的打车服务订单并播放所述语音打车请求信息,接收司机发出的语音响应消息并返回给所述服务器;\n[0093] 至少一个乘客客户端303,用于将乘客打车请求信息发送至服务器,以及接收服务器返回的打车服务订单成功消息。\n[0094] 进一步地,上述提供打车服务的系统,上述乘客客户端303,具体用于将音频形式或文本形式的乘客打车请求信息发送给服务器;音频形式或文本形式的乘客打车请求信息中包含乘客的出发地信息和目的地信息;\n[0095] 相应地,服务器301,具体用于当所述乘客打车请求信息为音频形式时,将所述乘客打车请求信息作为所述打车服务订单中的语音打车请求信息;以及当所述乘客打车请求信息为文本形式时,将所述文本形式的打车请求消息转换成音频形式,并将所述转换后的乘客打车请求信息作为所述打车服务订单中的语音打车请求信息。\n[0096] 本发明实施例提供的提供打车服务的方法、装置及系统,在服务器侧对乘客客户端发出的打车请求进行处理,将语音形式的打车请求信息携带在打车服务订单中,推送给司机侧车载终端,使得司机侧车载终端可采用播放音频的方式让司机知晓乘客的出发地和目的地,并且,也无需采用现有在车载终端的界面上进行手工选择是否接单的方式,也就是说,司机也可采用语音接单的方式来实现打车交易的完成,在提供打车服务的整个流程中,出租车司机不用在驾驶车辆时分心查看车载终端上显示的乘客出发地和目的地,也无需采用手工输入是否接单的操作,因此,提高了司机在行驶过程中的安全性,同时也为出租车司机提供了相当的便利。\n[0097] 通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到本发明实施例可以通过硬件实现,也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解,本发明实施例的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述的方法。\n[0098] 本领域技术人员可以理解附图只是一个优选实施例的示意图,附图中的模块或流程并不一定是实施本发明所必须的。\n[0099] 本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述进行分布于实施例的装置中,也可以进行相应变化位于不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块,也可以进一步拆分成多个子模块。\n[0100] 上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。\n[0101] 显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。
法律信息
- 2018-12-21
未缴年费专利权终止
IPC(主分类): G08G 1/00
专利号: ZL 201310751822.9
申请日: 2013.12.31
授权公告日: 2016.08.24
- 2016-08-24
- 2014-04-23
实质审查的生效
IPC(主分类): G08G 1/00
专利申请号: 201310751822.9
申请日: 2013.12.31
- 2014-03-26
引用专利(该专利引用了哪些专利)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 |
1
| |
2005-10-12
|
2004-12-16
| | |
2
| |
2004-03-24
|
2003-08-13
| | |
3
| |
2009-09-02
|
2008-03-31
| | |
4
| |
2013-11-13
|
2012-05-09
| | |
5
| |
2013-01-02
|
2011-06-30
| | |
被引用专利(该专利被哪些专利引用)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 | 该专利没有被任何外部专利所引用! |