用于在移动装置上呈现提示消息的人工智能系统和方法与流程

本申请要求于2017年6月28日提交的中国专利申请号为201710511712.3和2017年9月15日提交的中国专利申请号为201710840389.4的优先权，其内容通过引用结合于此。

本申请一般涉及互联网的技术领域，更具体地，涉及用于在移动装置上呈现提示信息的系统和方法。

背景技术：

在现代社会中，线上到线下服务应用程序正变得越来越普遍。用户可以通过安装在用户的用户移动终端中的应用程序发出请求线上到线下服务的命令。通过应用程序，用户可以与服务提供者进行通信，这提高了服务效率。在应用程序的用户界面上，应用程序经常为用户显示与服务有关的信息。现有技术的一个问题是用户显示的信息无法满足用户的需求。因此，希望提供用于在线上到线下服务期间在移动装置上呈现提示信息的系统和方法。

技术实现要素：

本申请的一个方面介绍了一种系统，被配置用于在用户终端的线上到线下服务应用程序的用户界面上呈现提示信息。该系统可以包括：至少一个存储介质，包括用于在用户终端的线上到线下服务应用程序的用户界面上呈现提示信息的一组指令；至少一个与存储介质通信的处理器，其中当执行该组指令时。该至少一个处理器可以用于：从用户终端获取第一服务类型的服务请求，其中服务请求包括用户终端的位置；根据用户终端的位置确定第一服务类型的第一供需比；确定第一供需比是否大于第一比例阈值；并且响应于确定第一供需比不大于第一比例阈值，向用户终端发送在用户终端的用户界面上呈现的第一气泡提醒信息，其中第一气泡提醒信息包括第二服务类型和所述第二服务类型的响应时间。

在一些实施例中，第一气泡提醒信息还可以包括显示第二服务类型的用户界面的链接，或者第一服务类型的第一供需比的视图。

在一些实施例中，第二服务类型可以在与用户终端的位置相关联的至少两个服务类型中具有最大的供需比。

在一些实施例中，从用户终端获取第一出行订单，其中第一出行订单包括目标服务类型和第一出行订单的第一发送时间；在目标服务类型的待分配的订单队列中获取至少一个第二出行订单，每个第二出行订单包括第二出行订单的第二发送时间；根据第一发送时间和至少一个第二发送时间确定第一出行订单的排队编号和等待时间；将用户终端的用户界面上呈现的第二气泡提醒信息发送给用户终端，其中第二气泡提醒信息包括第一出行订单的排队编号和等待时间。

在一些实施例中，所述至少一个处理器还可以用于：确定所述第一出行订单的等待时间是否小于时间阈值；并且响应于确定第一出行订单的等待时间不小于时间阈值，向用户终端发送在用户终端的用户界面上呈现的第一气泡提醒信息。

在一些实施例中，至少一个处理器还可以用于：基于第一出行订单将车辆分配给用户终端；在用户终端的用户界面上呈现第三气泡提醒信息，其中第三气泡提醒信息包括与分配的车辆有关的信息。

在一些实施例中，第三气泡提醒信息可包括以下中的至少一个：分配的车辆的颜色、分配的车辆的车牌号、或分配的车辆的车型。

在一些实施例中，至少一个处理器还可以用于：从用户终端获取第一出行订单，第一出行订单包括目标服务类型和起始地点，并且由用户在用户终端的线上线下服务应用程序的用户界面上触发；确定第一出行订单未被成功分配车辆；将用户终端的用户界面上呈现的卡片提醒信息发送给用户终端，其中卡片提醒信息包括推荐的服务类型和推荐的服务类型的响应时间。

在一些实施例中，卡片提醒信息还可包括以下中的至少一个：触发推荐的服务类型的推荐出行订单的操作选项、推荐的服务类型是推荐的出行订单的预估费用、或推荐的服务类型的推荐出行订单的预估费用与目标服务类型的第一出行订单的预估费用之间的费用差。

在一些实施例中，第一出行订单可以包括起始地点，并且为了确定该至少一个处理器可以进一步指向：根据起始地点确定目标服务类型的第二供需比；判断第二供需比是否大于第二比例阈值；并且响应于确定第二供需比不大于第二比例阈值，确定第一出行订单未被成功分配车辆。

在一些实施例中，为了确定所述至少一个处理器还可以用于：从用户终端获取第一出行订单的取消请求；并确定第一个出行订单未被成功分配车辆。

在一些实施例中，第一出行订单可以包括以下中的至少一个：用户终端的起始时间、起始地点、目的地或历史出行信息。

在一些实施例中，至少一个处理器还可以用于：基于第一出行订单确定提示给用户终端的推荐的服务类型。

根据本申请的另一方面，一种用于在用户终端的线上到线下服务应用程序的用户界面上呈现提示信息的方法，可以包括：从用户终端获取第一服务类型的服务请求，其中服务请求包括用户终端的位置；根据用户终端的位置确定第一服务类型的第一供需比；确定第一供需比是否大于第一比例阈值；以及响应于确定第一供需比不大于第一比例阈值，向用户终端发送用户终端的用户界面上呈现的第一气泡提醒信息，其中第一气泡提醒信息包括第二服务类型和所述第二服务类型的响应时间。

在一些实施例中，第一气泡提醒信息还可以包括到显示第二服务类型的用户界面的链接，或者第一服务类型的第一供需比的视图。

在一些实施例中，第二服务类型可以在与用户终端的位置相关联的至少两个服务类型中具有最大的供需比。

在一些实施例中，该方法还可以包括：从用户终端获取第一出行订单，其中第一出行订单包括目标服务类型和第一出行订单的第一发送时间；在目标服务类型的待分配的订单队列中获取至少一个第二出行订单，每个第二出行订单包括第二出行订单的第二发送时间；根据第一发送时间和至少一个第二发送时间确定第一出行订单的排队编号和等待时间；将用户终端的用户界面上呈现的第二气泡提醒信息发送给用户终端，其中第二气泡提醒信息包括第一出行订单的排队编号和等待时间。

在一些实施例中，该方法还可以包括：确定第一出行订单的等待时间是否小于时间阈值；并且响应于确定第一出行订单的等待时间不小于时间阈值，向用户终端发送在用户终端的用户界面上呈现的第一气泡提醒信息。

在一些实施例中，该方法还可以包括：基于第一出行订单将车辆分配给用户终端；在用户终端的用户界面上呈现的第三气泡提醒信息，其中第三气泡提醒信息包括与分配的车辆有关的信息。

在一些实施例中，第三气泡提醒信息可包括以下中的至少一个：分配的车辆的颜色、分配的车辆的车牌号、或分配的车辆的车型。

在一些实施例中，该方法还可以包括：从用户终端获取第一出行订单，其中，第一出行订单包括目标服务类型和起始地点，并且由用户在用户终端的线上线下服务应用程序的用户界面上触发；确定第一出行订单未被成功分配车辆；将用户终端的用户界面上呈现的卡片提醒信息发送给用户终端，其中卡片提醒信息包括推荐的服务类型和推荐的服务类型的响应时间。

在一些实施例中，卡片提醒信息还可包括以下中的至少一个：触发推荐的服务类型的推荐出行订单的操作选项、推荐的服务类型是推荐的出行订单的预估费用、或推荐的服务类型的推荐出行订单的预估费用与目标服务类型的第一出行订单的预估费用之间的费用差。

在一些实施例中，第一出行订单可以包括起始地点，并且确定第一出行订单可以包括：基于起始地点确定目标服务类型的第二供需比；确定第二供需比是否大于第二比例阈值；以及响应于确定第二供需比不大于第二比例阈值，确定第一出行订单未被成功分配车辆。

在一些实施例中，确定第一出行订单未被成功分配车辆可以包括：从用户终端获取第一出行订单的取消请求；并确定第一个出口订单未被成功分配车辆。

在一些实施例中，第一出行订单可以包括以下中的至少一个：用户终端的起始时间、起始地点、目的地或历史出行信息。

在一些实施例中，该方法还可以包括：基于第一出行订单确定提示给用户终端的推荐的服务类型。

根据本申请的另一方面，一种非暂时性计算机可读介质，包括至少一组指令，用于在用户终端的线上到线下服务应用程序的用户界面上呈现提示信息，其中，当由计算机装置的至少一个处理器执行时，所述至少一组指令可以指示所述至少一个处理器：从用户终端获取第一服务类型的服务请求，其中服务请求包括用户终端的位置；根据用户终端的位置确定第一服务类型的第一供需比；确定第一供需比是否大于第一比例阈值；并且响应于确定第一供需比不大于第一比例阈值，向用户终端发送在用户终端的用户界面上呈现的第一气泡提醒信息，其中第一气泡提醒信息包括第二服务类型和所述第二服务类型的响应时间。

根据本申请的另一方面，系统被配置为在用户终端的线上到线下服务应用程序的用户界面上呈现提示信息，可以包括：接收模块被配置为从用户终端获取第一服务类型的服务请求，其中服务请求包括用户终端的位置；确定模块被配置用于根据用户终端的位置确定第一服务类型的第一供需比，并确定第一供需比是否大于第一比例阈值；推送模块被配置为响应于确定第一供需比不大于第一比例阈值，向用户终端发送在用户终端的用户界面上呈现的第一气泡提醒信息，其中第一气泡提醒信息包括第二服务类型和所述第二服务类型的响应时间。

其他特征将在以下部分描述中进行阐述，并且在检视以下及随附图标之后，部分特征对于本领域的普通技术人员来讲是显而易见地，或可以通过实例的生产及操作来了解。本申请的特征可以通过实践或使用以下实例中详细讨论的方法、手段及组合的各个方面来达成。

附图说明

本申请将结合示例性实施例进一步进行描述。这些示例性的实施例将结合参考图示进行详细描述。这些实施例并非限制性的，在这些实施例中，相同的组件符号表示相同的结构，其中：

图1是根据本申请的一些实施例所示的示例性线上到线下服务系统的示意图；

图2是根据本申请的一些实施例所示的计算装置的示例性硬件和/或软件组件的示意图；

图3是根据本申请的一些实施例所示的移动装置的示例性硬件和/或软件组件的示意图；

图4a是根据本申请的一些实施例所示的用于呈现提示信息的示例性第一系统的模块图。

图4b是根据本申请的一些实施例所示的用于呈现提示信息的示例性第一系统的模块图。

图4c是根据本申请的一些实施例所示的用于呈现提示信息的示例性第二系统的模块图。

图4d是根据本申请的一些实施例所示的用于呈现提示信息的示例性第二系统的模块图；

图5是根据本申请的一些实施例所示的用户终端上的应用程序的示例性用户界面；

图6是根据本申请的一些实施例所示的用于呈现第一气泡提醒信息的示例性流程的流程图。

图7是根据本申请的一些实施例所示的用户终端上的应用程序的示例性用户界面；

图8是根据本申请的一些实施例所示的用于呈现第二气泡提醒信息的示例性流程的流程图。

图9是根据本申请的一些实施例所示的用户终端上的应用程序的示例性用户界面；

图10是根据本申请的一些实施例所示的用户终端上的应用程序的示例性用户界面；

图11是根据本申请的一些实施例所示的用于呈现第三气泡提醒信息的示例性流程的流程图。

图12是根据本申请的一些实施例所示的用户终端上的应用程序的示例性用户界面；

图13是根据本申请的一些实施例所示的用户终端上的应用程序的示例性用户界面；

图14是根据本申请的一些实施例所示的用户终端上的应用程序的示例性用户界面；

图15是根据本申请的一些实施例所示的用于呈现第三气泡提醒信息的示例性流程的流程图。

图16是根据本申请的一些实施例所示的用户终端上的应用程序的示例性用户界面；

图17是根据本申请的一些实施例所示的用户终端上的应用程序的示例性用户界面；和

图18是根据本申请的一些实施例所示的用于在用户终端上呈现卡片提醒信息的指令的流程图。

具体实施方式

下述描述是为了使本领域技术人员能制造和使用本申请，并且该描述是在特定的应用场景及其要求的背景下提供的。对于本领域的技术人员来讲，对本申请披露的实施例进行的各种修改是显而易见的，并且本申请定义的通则可以适用于其他实施例和应用，而不背离本申请的精神和范围。因此，本申请不限于所示的实施例，而是符合与权利要求一致的最广泛范围。

本文中所使用的术语仅用于描述特定示例性实施例，并不限制本申请的范围。如本文使用的单数形式“一”、“一个”及“该”可以同样包括复数形式，除非上下文明确提示例外情形。将进一步理解，当在本说明书中使用时，术语“包括”、“包含”、“包括”和/或“包括”指定所述特征、整体、步骤、操作、元素和/或的存在。组件，但不排除一个或以上其他特征、整体、步骤、操作、元素、组件和/或组的存在或添加。

在考虑了作为本申请一部分的附图的描述内容后，本申请的特征和特点以及操作方法、结构的相关元素的功能、各部分的组合、制造的经济性变得显而易见。然而，应当理解，附图仅仅是为了说明和描述的目的，并不旨在限制本申请的范围。应当理解的是附图并不是按比例的。

本申请中使用了流程图用来说明根据本申请的实施例的系统所执行的操作。应当理解的是，前面或下面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各种步骤。同时，也可以将一个或以上其他操作添加到这些流程图中，或者从这些流程图中移除某一步或数步操作。一个或以上操作也可以从流程图中删除。

本申请的一个方面涉及用于在移动装置上呈现提示信息的系统和方法。为此，该系统和方法可以确定移动装置的用户请求的服务类型的供需比，并且分析供需比以确定是否向用户推荐另一类服务类型。与其相关的推荐的服务类型可以以气泡提醒信息的格式在移动装置的用户界面上显示。该系统和方法还可以确定用户是否未被分配给服务提供者，并且分析确定结果以确定是否向用户推荐另一类服务类型。推荐的服务类型及其相关信息可以以卡片提醒信息的格式在移动装置的用户界面上显示。该系统和方法可以提供与服务有关的更多信息，并改善用户体验。

图1是根据本申请的一些实施例所示的示例性线上到线下服务系统100的示意图。例如，线上线下服务系统100可以是用于运输服务的线上到线下服务平台，例如汽车呼叫、司机服务、运送车辆、拼车、公共汽车服务、司机雇佣、班车服务和在线导航服务。线上线下服务系统100可以是包括服务器110和用户终端120的在线平台。在一些实施例中，系统100还可包括存储装置，网络和服务提供者终端(未示出)。

服务器110可以被配置为处理与服务请求和/或服务订单有关的信息和/或数据。例如，服务器110可以响应于服务请求和/或服务订单，发送在用户终端响应的用户界面上呈现的提示信息。在一些实施例中，服务器110可以是单一服务器或服务器组。该服务器组可以是集中式或分布式的(例如，服务器110可以是一分布式系统)。在一些实施例中，服务器110可以是本地的或远程的。例如，服务器110可以经由网络访问存储在用户终端120中的信息和/或数据，和/或存储。又例如，服务器110可以连接用户终端120和/或存储装置以访问存储的信息和/或数据。在一些实施例中，服务器110可以在云平台上实施。仅作为示例，所述云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。在一些实施例中，服务器110可以在本申请中的图2描述的包含了一个或以上组件的计算装置200上执行。

在一些实施例中，服务器110可包括处理引擎(未示出)。处理引擎可以处理与服务请求和/或服务订单有关的信息和/或数据，以执行本申请中描述的一个或以上的功能。例如，处理引擎可以响应于服务请求和/或服务订单，发送在用户终端响应的用户界面上呈现的提示信息。在一些实施例中，所述处理引擎可包括一个或以上处理引擎(例如，单芯片处理引擎或多芯片处理引擎)。仅作为示例，处理引擎112可以包括一个或以上硬件处理器，例如中央处理单元(cpu)、特定应用集成电路(asic)、特定应用指令集处理器(asip)、图像处理单元(gpu)、物理运算处理单元(ppu)、数字信号处理器(dsp)、现场可程序门阵列(fpga)、可程序逻辑装置(pld)、控制器、微控制器单元、精简指令集计算机(risc)、微处理器等或上述举例的任意组合。

用户终端120可以是用户用来请求线上到线下服务，例如打车的移动装置。在一些实施例中，用户终端120可以是移动装置、平板电脑、笔记本电脑、机动车辆中的内置装置、用户装置(ue)、移动站(ms)、终端等，或其任何组合。在一些实施例中，移动装置可以是可穿戴装置、智能移动装置、虚拟现实装置、增强现实装置等，或其任何组合。在一些实施例中，该可穿戴装置可包括智能手环、智能鞋袜、智能眼镜、智能头盔、智能手表、智能穿着、智能背包、智能配件等或其任意组合。在一些实施例中，智能移动装置可以包括智能电话、个人数字助理(pda)、游戏装置、导航装置、销售点(pos)等，或其任意组合。在一些实施例中，虚拟现实装置和/或增强型虚拟现实装置可以包括虚拟现实头盔、虚拟现实眼镜、虚拟现实眼罩、增强型虚拟现实头盔、增强型虚拟现实眼镜、增强型虚拟现实眼罩等，或其任意组合。例如，虚拟现实装置和/或增强现实装置可以包括googleglass^tm、riftcon^tm、fragments^tm、gearvr^tm等。在一些实施例中，机动车辆中的内置装置可以是车载计算机、车载电视等。

在一些实施例中，用户终端120可以是具有定位技术的装置，用于定位用户和/或用户终端120的位置。本申请中使用的定位技术可以包括全球定位系统(gps)、全球卫星导航系统(glonass)、北斗导航系统(compass)、伽利略定位系统、准天顶卫星系统(qzss)、无线保真(wifi)定位技术等或上述举例的任意组合。以上定位技术中的一个或多个可以在本申请中交换使用。在一些实施例中，用户终端120还可包括至少一个网络端口。所述至少一个网络端口可以被配置为经由网络向系统100中的一个或以上组件(例如，服务器110、存储装置)发送信息和/或从其接收信息。在一些实施例中，用户终端120可以在具有图2中所示的一个或以上组件的计算装置200上实现，或者在本申请中具有图3中所示的一个或以上组件的移动装置300上实现。在一些实施例中，用户终端120可以包括安装在其中的应用程序。服务器110可以是应用程序提供的服务的服务器。

存储装置可以存储数据和/或指令。例如，存储装置可以存储从用户终端120获取的数据。又例如，存储装置可以存储服务器110可以执行或使用的数据和/或指令，以执行本申请中描述的示例性方法。在一些实施例中，存储装置可包括大容量储存器、可抽取式储存器、挥发性读写内存、只读存储器(rom)等或其任意组合。示例性的大容量储存器可以包括磁盘、光盘、固态驱动等。示例性可移动存储器可以包括闪存驱动器、软盘、光盘、存储卡、压缩盘、磁带等。示例性易失性读写存储器可以包括随机存取存储器(ram)。示例性的ram可包括动态ram(dram)、双倍速率同步动态ram(ddrsdram)、静态ram(sram)、闸流体ram(t-ram)和零电容ram(z-ram)等。示例性的rom可以包括掩模rom(mrom)、可编程rom(prom)、可擦除可编程rom(eprom)、电子可擦除可编程rom(eeprom)、光盘rom(cd-rom)和数字通用磁盘rom等。在一些实施例中，所述存储装置可以在云平台上实现。仅作为示例，所述云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。

在一些实施例中，线上线下服务系统100的一个或以上组件(例如，服务器110、用户终端120)可以访问存储装置。在一些实施例中，当满足一个或以上条件时，线上线下服务系统100的一个或以上组件可以读取和/或修改与用户和/或公众有关的信息。例如，在完成一个服务后，服务器110可以读取和/或修改一个或以上用户的信息。

网络可以促进信息和/或数据交换。在一些实施例中，线上线下服务系统100的一个或以上组件(例如，服务器110、用户终端120和存储装置)可以通过网络将信息和/或数据发送到线上线下服务系统100中的其他组件。例如，服务器110可以通过网络从用户终端120接收服务请求。在一些实施例中，网络可以是有线网络、无线网络或其任意组合中的任一类型。仅作为示例，网络130可以包括缆线网络、有线网络、光纤网络、远程通信网络、内部网络、互联网、局域网络(lan)、广域网络(wan)、无线局域网络(wlan)、城域网(man)、公共开关电话网络(pstn)、蓝牙网络、紫蜂网络、近场通信(nfc)网络等或上述举例的任意组合。在一些实施例中，网络可以包括一个或以上网络接入点。例如，网络可以包括有线或无线网络接入点，例如基站和/或互联网交换点，线上线下服务系统100的一个或以上组件可以通过其连接到网络以在它们之间交换数据和/或信息。

在一些实施例中，线上线下服务系统100的一个或以上组件(例如，服务器110、用户终端120和存储装置)可以通过有线和/或无线通信以电子和/或电磁信号的形式彼此通信。在一些实施例中，系统100还可包括至少一个信息交换端口。所述至少一个交换端口可以被配置为接收信息和/或在系统100中的任何电子装置之间发送与服务请求有关的信息(例如，以电子信号和/或电磁信号的形式)。例如，至少一个信息交换端口可以通过服务器110和用户终端120之间的无线通信从用户终端120接收服务请求。又例如，所述至少一个信息交换端口可以通过无线通信向用户终端120发送包括提示信息的电磁信号。在一些实施例中，至少一个信息交换端口可以是天线、网络接口、网络端口等的一个或以上，或其任何组合。例如，至少一个信息交换端口可以是连接到服务器110以向其发送信息和/或接收从其发送的信息的网络端口。

图2示出了计算装置200的示例性硬件和软件组件的示意图，在该计算装置200上可以根据本申请的一些实施例实现服务器110和/或用户终端130。例如，处理引擎112可以在计算装置200上实现，并且被配置用于执行本申请中公开的服务器或处理引擎的功能。

计算装置200可用于实现本申请的系统100。计算装置200可用于实现执行本申请中公开的一个或以上功能的系统100的任何组件。例如，处理引擎可以在计算装置200上通过其硬件、软件程序、固件或其组合实现。尽管仅示出了一个这样的计算机，但是为了方便，与本文所述的线上线下服务有关的计算机功能可以在多个类似平台上以分布式方式实现，以分配处理负荷。

计算装置200可以例如包括与网络相连接并促进数据通信的通信(com)端口250。com端口250可以是任何网络端口或信息交换端口，以便于数据通信。计算装置200还可以包括处理器(例如，处理器220)，其形式为一个或以上处理器(例如，逻辑电路)，用于执行程序指令。例如，处理器可以包括接口电路和其中的处理电路。接口电路可以被配置为从总线210接收电子信号，其中电子信号编码结构化数据和/或指令以供处理电路处理。处理电路可以进行逻辑计算，然后确定结果，结果和/或编码为电子信号的指令。处理电路还可以生成包括结论或结果的电子信号(例如，文字目的地)和触发代码。在一些实施例中，触发代码可以是由ai系统100中的电子装置(例如，用户终端130)的操作系统(或其中安装的应用程序)可识别的格式。例如，触发代码可以是指令、代码、标记、符号等，或其任何组合，可以激活移动电话的某些功能和/或操作，或者让移动电话执行预定的程序。在一些实施例中，触发代码可以被配置为电子装置的操作系统(或应用程序)，以在电子装置的接口上产生结论或结果(例如，文字目的地)的表示。然后，接口电路可以经由总线210从处理电路发出电子信号。

示例性计算装置可以包括内部通信总线210，程序存储和不同形式的数据存储，包括例如磁盘270，以及只读存储器(rom)230或随机存取存储器(ram)240，用于由计算装置处理和/或发送的各种数据文件。示例性计算装置也可以包括储存于rom230、ram240和/或其他形式的非暂时性存储介质中的能够被处理器220执行的程序指令。本申请的方法和/或流程可以以程序指令的方式实现。示例性计算装置还可以包括存储在rom230、ram240和/或由处理器220执行的其他类型的非暂时性存储介质中的操作系统。程序指令可以与用于提供线上线下服务的操作系统兼容。计算装置200还包括i/o组件260，支持计算机和其他组件之间的输入/输出。计算装置200也可以通过网络通信接收程序设计和数据。

仅用于说明，图2中仅示出了一个处理器。还考虑了多个处理器；因此，由本申请中描述的一个处理器执行的操作和/或方法步骤也可以由多个处理器联合或单独执行。例如，如果在本申请中，计算装置200的处理器执行步骤a和步骤b，应当理解的是，步骤a和步骤b也可以由计算装置200的两个不同的处理器共同地或独立地执行(例如，第一处理器执行步骤a，第二处理器执行步骤b，或者第一和第二处理器共同地执行步骤a和步骤b)。

图3示出了根据本申请的一些实施例的可在其上实现用户终端120的示例性移动装置300的示例性硬件和/或软件组件的示意图。

如图3所示，移动装置300可以包括通信模块310、显示器320、图形处理单元(gpu)330、中央处理单元(cpu)340、i/o350、内存360和存储器390。cpu可以包括接口电路和类似于处理器220的处理电路。在一些实施例中，任何其他合适的组件，包括但不限于系统总线或控制器(未示出)，也可包括在移动装置300内。在一些实施例中，移动操作系统370(例如，ios^tm、android^tm、windowsphone^tm等)和一个或以上应用程序380可以从存储器390加载到内存360中，以便由cpu340执行。应用程序380可以包括浏览器或任何其他合适的移动应用程序，用于接收和呈现与服务的语音请求有关的信息。用户与信息流的交互可以通过i/o装置350实现，并通过网络提供给处理引擎和/或系统100的其他组件。

为了实现本申请中描述的各种模块、单元及其功能，计算机硬件平台可以用作一个或多个本文所述元件的硬件平台(例如，线上线下服务系统100，和/或关于图1-18描述的线上线下服务系统100的其他组件)。这种计算机的硬件元件，操作系统和编程语言本质上是传统的，并且假设本领域技术人员对其进行了充分的熟悉以使这些技术适应于在此描述的语音请求中提供服务响应。一台包含用户界面元素的计算机能够被用作个人计算机(personalcomputer(pc))或其他类型的工作站或终端装置，被适当程序化后也可以作为服务器使用。可知，本领域技术人员应熟悉该计算机装置的结构、程序设计和一般操作，因此，图对其应是不解自明的。

本领域普通技术人员将理解，当线上线下服务系统100的元件执行时，该元件可以通过电信号和/或电磁信号执行。例如，当服务器110处理任务时，例如获取服务请求或服务订单，服务器110可以在其处理器中操作逻辑电路以处理这样的任务。当服务器110接收到服务请求或服务订单时，服务器110的处理器可以生成编码服务请求的电信号。然后，服务器110的处理器可以将电信号发送到与服务器110相关联的目标系统的至少一个信息交换端口。服务器110通过有线网络与目标系统通信，所述至少一个信息交换端口可以物理地连接到电缆，所述电缆还可以将电信号发送到用户终端120的输入端口(例如，信息交换端口)。如果服务器110经由无线网络与目标系统通信，则目标系统的至少一个信息交换端口可以是一个或以上天线，其可以将电信号转换为电磁信号。在电子装置内，例如用户终端120和/或服务器110，当处理器处理指令，发出指令和/或执行动作时，指令和/或动作通过电信号进行。例如，当处理器从存储介质(例如，存储装置)检索或保存数据时，它可以将电信号发送到存储介质的读/写装置，该读/写装置可以在存储介质中读取或写入结构化数据。该结构数据可以通过电子装置的总线，以电信号的形式传输至处理器。这里，电信号可以是一个电信号，一系列电信号和/或至少两个分立的电信号。

图4a示出了根据本申请的一些实施例的用于呈现提示信息的示例性第一系统的模块图。如图4a所示，第一系统410可以包括接收模块411、确定模块412和推送模块413。

接收模块411可以被配置以获取与服务请求和/或订单有关的信息。例如，接收模块411可以从用户终端120获取第一服务类型的服务请求。在一些实施例中，服务请求包括用户终端的位置、起始地点、目的地、请求时间、起始时间、服务类型等，或其任何组合。在一些实施例中，服务请求可以是使用第一服务类型进行出行的意图。又例如，接收模块411可以从用户终端120获取第一出行订单。在一些实施例中，第一出行订单可包括目标服务类型、第一出行订单的第一发送时间、起始地点、目的地、起始时间等，或其任何组合。

确定模块412可以是配置用于确定与服务请求和/或订单有关的结果。例如，确定模块412可以基于用户终端120的位置确定第一服务类型的第一供需比。在一些实施例中，第一供需比可以是在距用户终端120(或用户的起始地点)的位置预定距离内的区域中的可用车辆(或可用服务提供者)的数量与用户终端(或请求目标服务类型的服务请求者)的数量的比例。

又例如，确定模块412可以根据目标服务类型的待分配的订单队列中的第一发送时间和至少一个第二出行订单的至少一个第二发送时间，确定第一出行订单的排队编号和等待时间。在一些实施例中，至少一个第二出行订单可以包括由用户终端120的区域内的至少两个其他用户终端发送的至少两个出行订单。该至少一个第二出行订单可以包括与第一出行订单相同的目标服务类型。

推送模块413可以被配置为向用户终端120发送信息。例如，推送模块413可以向用户终端120发送在用户终端120的用户界面上呈现的第一气泡提醒信息。在一些实施例中，第一气泡提醒信息可包括第二服务类型的响应信息。第二服务类型的响应信息可以包括第二服务类型和所述第二服务类型的响应时间。

又例如，推送模块413可以向用户终端120发送在用户终端120的用户界面上呈现的第二气泡提醒信息。在一些实施例中，第二气泡提醒信息可包括第一出行订单的排队编号和等待时间。

作为又一示例，推送模块413可以向用户终端120发送在用户终端120的用户界面上呈现的第三气泡提醒信息。在一些实施例中，第三气泡提醒信息可包括与分配的车辆有关的信息。

图4b示出了根据本申请的一些实施例的用于呈现提示信息的示例性第一系统的模块图。如图4b所示，第一系统410还可以包括记录模块414和分配模块415。

在接收到用户终端120发送的第一出行订单后，记录模块414可以被配置为记录第一出行订单的等待时间。在一些实施例中，第一出行订单的等待时间可以是服务器110即将处理第一个订单所花费的时间。

分配模块415可以被配置为基于第一出行订单将车辆分配给用户终端120。在一些实施例中，分配模块415可以分配最靠近用户终端120的车辆，其能够基于用户终端120(或用户的起始地点)的位置来接用户，并且所述车辆具有与第一出行订单中相同的服务类型。

如图4a和/或图4b所示的第一系统410中的模块可以通过有线连接或无线连接彼此连接或通信。有线连接可以包括金属线缆、光缆、混合电缆等或其任意组合。无线连接可以包括局域网络(lan)、广域网络(wan)、蓝牙、紫蜂网络、近场通信(nfc)等或上述举例的任意组合。两个或以上模块可以合并成一个模块，以及任意一个模块可以被拆分成两个或以上单元。例如，接收模块411和推送模块412可以组合为单个模块，其可以获取和发送信息。又如例，处理引擎112可包括用于存储模型和/或文字目的地的数据和/或信息的存储模块(未示出)。

图4c示出了根据本申请的一些实施例的用于呈现提示信息的示例性第二系统的模块图。如图4b所示，第二系统420可以包括发送模块421、接收模块422和显示模块423。

发送模块421可以被配置为向用户终端120发送信息。例如，发送模块421可以向用户终端120发送在用户终端120的用户界面上呈现的卡片提醒信息。在一些实施例中，卡片提醒信息可包括推荐的服务类型的属性信息。例如，推荐的服务类型的属性信息可以包括推荐的服务类型、推荐的服务类型的标志(例如，其名称或图像)、推荐的服务类型的响应时间等，或其任何组合。推荐的服务类型的响应时间可以是推荐的服务类型的车辆到达用户的起始地点所花费的时间，这也称为接载时间。

接收模块422可以被配置用于获取与服务请求和/或订单有关的信息。例如，接收模块422可以从用户终端120获取第一出行订单。在一些实施例中，第一出行订单可以由用户在用户终端120中的线上到线下服务应用程序的用户界面上触发。在一些实施例中，第一出行订单可以包括目标服务类型、第一出行订单的第一发送时间、起始地点、目的地、起始时间、用户终端的位置等，或其任何组合。

显示模块423可以被配置为指示用户终端120在用户终端120的用户界面上显示卡片提醒信息。

图4d示出了根据本申请的一些实施例的用于呈现提示信息的示例性第二系统的模块图。如图4d所示，第二系统420还可包括处理模块424。

处理模块424可以是配置用于确定与第一出行订单相关的结果。例如，处理模块424可以基于来自用户终端的取消请求来确定第一出行订单未被成功分配车辆。又例如，处理模块424可以确定目标服务类型的第二供需比以及第二供需比是否大于第二比例阈值。如果第二供需比不大于第二比例阈值，则处理模块424可以确定第一出行订单未被分配给车辆。作为又一示例，处理模块424可以确定推荐的服务类型。

如图4c和/或图4d所示的第二系统420中的模块可以通过有线连接或无线连接彼此连接或通信。有线连接可以包括金属线缆、光缆、混合电缆等或其任意组合。无线连接可以包括局域网络(lan)、广域网络(wan)、蓝牙、紫蜂网络、近场通信(nfc)等或上述举例的任意组合。两个或以上模块可以合并成一个模块，以及任意一个模块可以被拆分成两个或以上单元。例如，接收模块411和推送模块412可以组合为单个模块，其可以获取和发送信息。作为又一示例，处理引擎112可包括用于存储模型和/或文字目的地的数据和/或信息的存储模块(未示出)。

图5是根据本申请的一些实施例所示的用户终端上的应用程序的示例性用户界面。如图5所示，应用程序可以是汽车服务的应用程序。在应用程序中，可以存在至少两个服务类型，例如，拼车服务、出租车服务、快车服务、公共汽车服务等，或其任何组合。在一些实施例中，当用户在用户终端120上使用应用程序时，服务器110可以获取用户终端120的定位信息。响应于从用户终端120接收特定服务类型的服务请求，服务器110可以基于用户终端120的定位信息确定相应服务类型的响应时间。服务器110还可以将携带响应时间的气泡消息推送到用户终端120。在一些实施例中，用户终端120可以在对应于服务类型的用户界面上显示的地图上标记用户或用户终端120的当前位置，并通过用户标记的当前位置或用户终端120处的气泡消息提醒用户这种服务类型的响应时间。响应时间可以是这种服务类型的车辆到达用户的起始地点的时间，其也可以被称为接载时间。例如，气泡消息可能是“在这里上车2分钟”。图5是示例性用户界面，示出了当用户选择快车服务时的气泡消息。

在一些实施例中，当服务器110确定车辆的服务类型在距用户的起始地点或用户的当前位置预定距离内的区域中供应不足时，服务器110可以将包括“附近没有可用车辆”的气泡消息推送到用户终端120。然而，借助于上述气泡消息，用户可能只知道这种服务类型的车辆供不应求。用户可能无法获取便于用户出行的其他信息，从而导致用户体验相对较差。

考虑到上述问题，提供了用于在本申请中呈现气泡提醒信息的系统和方法，以解决现有技术中气泡消息可能不满足用户实际使用需求的问题。

需要说明的是，本申请中涉及打车程序的服务类型具体涉及打车程序的设计。例如，在一些打车应用程序中，服务类型可以包括拼车服务、出租车服务、快车服务、公共汽车服务、私家车等，或其任何组合。每个服务类型可以对应于一个用户界面。在一些打车应用程序中，可以根据不同的车型确定服务类型。例如，服务类型可以包括官方汽车服务、具有七个座位的商用车辆服务、豪华轿车服务等，或其任何组合。服务类型包括本申请中的打车程序中所示的拼车服务、出租车服务、快车服务和公交服务，仅用于描述和介绍目的。对于具有本领域普通技能的人员应该理解，在本申请中用于呈现气泡提醒信息的系统和方法不限于应用程序方案。任何提供许多其他服务类车辆的应用程序都可以采用本申请提供的气泡提醒信息，从而改善用户体验。还应该注意的是，任何线上到线下服务应用程序也可以采用本申请提供的气泡提醒信息。

图6示出了根据本申请的一些实施例的用于呈现第一气泡提醒信息的示例性流程的流程图。流程600可以由线上线下服务系统100或集成线上线下服务系统100的服务器执行。例如，流程600可以实现为存储在存储rom230或ram240中的一组指令(例如，应用程序)。处理器220可以执行该组指令，并且当执行该指令时，可以将其配置为执行该流程600。以下呈现的所示过程的操作旨在说明。在一些实施例中，流程600可以通过未描述的一个或多个以上附加操作和/或没有一个或以上所讨论的操作来完成。另外，如图6所示和下面描述的过程操作的顺序不是限制性的。

流程600可以包括：响应于从用户终端120获取某个服务类型的服务请求，服务器110可以当某个服务类型的供需比不大于预定比例阈值时，将包括其他服务类型的第一气泡提醒信息推送到用户终端120。

在610中，服务器110(例如，处理器220、接收模块411)可以从用户终端120获取第一服务类型的服务请求。在一些实施例中，服务请求包括用户终端的位置、起始地点、目的地、请求时间、起始时间、服务类型等，或其任何组合。在一些实施例中，服务请求可以是使用第一服务类型进行出行的意图。

在一些实施例中，当用户在打车程序的用户界面上选择第一服务类型时(用户尚未发送出行订单)，用户终端120可以将第一服务类型的服务请求发送到服务器110，服务器110指示服务器110存在对用户终端120的第一服务类型的需求。服务器110可以从用户终端120获取第一服务类型的服务请求。

在一些实施例中，用户终端120可以通过服务请求消息将第一服务类型的服务请求发送到服务器110。用户终端120还可以通过任何现有方式向服务器110发送第一服务类型的服务请求。

在一些实施例中，用户终端120还可以通过其他现有消息向服务器110发送第一服务类型的服务请求。例如，在打车程序中，每个服务类型可以对应于用户界面。因此，用户终端120可以向网络装置发送请求对应于第一服务类型的用户界面的数据的网络请求，以通过网络请求隐含地向网络装置指示用户终端120的第一服务类型的服务请求。

图7是根据本申请的一些实施例所示的用户终端上的应用程序的示例性用户界面。如图7所示，当用户在打车程序的用户界面上选择快车(即第一服务类型)时，用户终端120可以向网络装置发送请求对应于该快车的用户界面的数据的网络请求，通过该网络请求隐含地指示用户终端120的第一服务类型的服务请求。

在620中，服务器110(例如，处理器220、确定模块412)可以基于用户终端的位置来确定第一服务类型的第一供需比。在一些实施例中，服务器110可以基于起始地点确定第一服务类型的第一供需比。

在一些实施例中，服务器110可以从用户终端120获取用户终端120或用户的位置。服务器110可以在距用户终端120的位置(或用户的起始地点)预定距离内的区域中确定第一服务类型的第一供需比。在一些实施例中，第一供需比可以是可用车辆(或可用服务提供者)的数量与该区域中的用户终端(或请求目标服务类型的服务请求者)的数量的比例。在一些实施例中，该区域可以包括以用户终端120(或用户的起始地点)的位置为中心的圆形区域、正方形区域、六边形区域等。可以根据服务器的配置来确定预定距离，该配置在本申请中没有定义。

例如，服务器110可以基于用户终端或用户(或用户的起始地点)的位置，预定区域形状和预定区域大小来确定区域。服务器110可以计算在所确定的区域内提供服务的第一服务类型的可用车辆的数量，以及期望在所确定的区域内使用第一服务类型的用户终端的数量。服务器110可以将两个数量的计算比例作为用户终端120的区域中的第一服务类型的第一供需比。

在一些实施例中，将用户终端120或用户(或用户的起始地点)的位置从用户终端120发送到服务器110的方式可以不受限制。例如，用户终端120可以将服务器请求中的位置(或起始地点)发送到服务器110，如610所示。又例如，用户终端120可以通过单独的消息或任何其他现有方式将位置(或起始地点)发送到服务器110。

返回图7，当用户在打车程序的用户界面上选择快车(即，第一服务类型)时，服务器110可以获取快车服务的服务请求。服务器110可以获取用户终端或用户(或用户的起始地点)的位置。然后，服务器110可以计算在所确定的区域内提供服务的第一服务类型的可用车辆的数量，以及期望在所确定的区域内使用第一服务类型的用户终端的数量。服务器110可以将两个数量计算的比例作为用户终端120的区域中的第一服务类型的第一供需比。

在630，响应于确定第一供需比不大于第一比例阈值，服务器110(例如，处理器220、推送模块413)可以向用户终端120发送在用户终端120的用户界面上呈现的第一气泡提醒信息。在一些实施例中，第一气泡提醒信息可包括第二服务类型的响应信息。第二服务类型的响应信息可以包括第二服务类型和所述第二服务类型的响应时间。

在一些实施例中，第一比例阈值可用于测量第一服务类型是否供应短缺。在一些实施例中，服务器110可以确定第一供需比是否大于第一比例阈值。例如，服务器110可以比较第一供需比和第一比例阈值。在一些实施例中，第一比例阈值可以由服务器110或其用户确定。例如，第一比例阈值可以是由服务器110或其用户确定的预设值。又例如，第一比例阈值可以根据不同的应用程序场景确定，例如不同的城市、不同的区域、不同的区域、不同的时间等，或者它们的任何组合。

当第一服务类型的第一供需比不大于第一比例阈值时，它表示第一服务类型在用户终端120的区域内供应短缺。在这种情况下，服务器110可以将第一气泡提醒信息中的第二服务类型的响应信息发送到用户终端120。用户终端120可以在其用户界面上显示第一气泡提醒信息。在一些实施例中，第二服务类型的响应信息可以包括第二服务类型和所述第二服务类型的响应时间。在一些实施例中，第二服务类型的第二供需比大于用户终端120的区域内的第一服务类型的第一供需比。例如，第二服务类型的第二供需比是用户终端120的区域内的至少两个服务类型的供需比中最大的。

通过这种方式，当第一服务类型供应不足时，用户可以通过第一气泡提醒信息获取当前具有最大供需比的车辆的响应信息。用户可以决定是否继续选择第一服务类型或者基于第一气泡提醒信息选择比第一服务类型具有更大供需比的服务类型，以提高用户的出行效率并改善用户体验。另外，服务器110可以引导用户在所选择的服务类型的供需比不足时选择其他服务类型以降低用户的流失率。

返回图7，当用户在打车程序的用户界面上选择快车(即，第一服务类型)时，服务器110可以根据用户终端120(或用户的起始地点)的位置在获取用户终端120的区域内的快车的第一供需比之后，确定快车的第一供需比是否大于预设阈值。在一些实施例中，预设阈值可以由服务器110或其用户确定。例如，当前阈值可以是由服务器110或其用户确定的预设值。又如，预设阈值可以根据不同的应用程序场景确定，例如不同的城市、不同的区域、不同的区域、不同的时间等，或者它们的任意组合。

当快车的第一供需比不大于第一比例阈值时，表示快车在用户终端120的区域内供应短缺。服务器110可以确定在用户终端120的区域内具有最大供需比的车辆(即，第二服务类型)。例如，第二服务类型的车辆可以是公共汽车。服务器110可以将包括公共汽车的响应信息的第一气泡提醒信息推送到用户终端120。用户终端120可以在快车的相应用户界面上显示第一气泡提醒信息。例如，第一气泡提醒信息可能包括“快车正忙！试试公交车？1分钟”。第一气泡提醒信息表示第二服务类型是总线服务，第二服务类型的响应时间是1分钟。总线服务的总线可能需要1分钟才能到达用户终端或用户(或用户的起始地点)的位置。

通过这种方式，当快车服务短缺时，用户可以通过第一气泡提醒信息快速获取当前具有最大供需比的公交服务的响应信息。用户可以基于第一气泡提醒信息来决定是继续选择快车服务还是选择公交服务，以提高用户的出行效率并改善用户体验。另外，服务器110可以引导用户在所选择的服务类型的供需比不足时选择其他服务类型以降低用户的流失率。

在一些实施例中，第一气泡提醒信息还可以包括到显示第二服务类型的用户界面的链接。在服务器110将第一气泡提醒信息发送到用户终端120之后，用户终端120可以在第一服务类型对应的用户界面上显示对应于第二服务类型的用户界面的链接，同时以气泡的格式显示第二服务类型的响应信息。这样，用户通过第一气泡提醒信息获取第二服务类型的响应信息后，如果用户决定使用第二服务类型旅行，他/她可以点击第一气泡提醒信息上显示的链接，快速从对应于第一服务类型的用户界面跳转到对应于第二服务类型的用户界面。提高了用户的出行效率和用户体验。

返回图7，例如，第二服务类型是总线服务。服务器110可以将包括总线服务和链接的响应信息的第一气泡提醒信息发送到对应于总线的用户界面到用户终端120。例如，第一气泡提醒信息可能包括“快车正忙！试试公交车？1分钟>“。符号“>”可以是到公共汽车服务的用户界面的链接的视觉图标。在一些实施例中，如果用户决定选择公共汽车服务，则用户可以点击第一气泡提醒信息中的符号“>”。用户终端120可以快速跳转到公交服务的用户界面，进一步提高了用户的出行效率，改善了用户体验。

在一些实施例中，第一气泡提醒信息还可包括与第一服务类型的第一供需比有关的数据。与第一供需比有关的数据可以指示用户终端120生成第一服务类型的第一供需比的视图。在服务器110将第一气泡提醒信息发送到用户终端120之后，用户终端120可以在用户界面上以气泡的格式显示第一服务类型的第一供需比的视图和对应于第一服务类型的第二服务类型的响应信息。通过这种方式，用户可以通过第一供需比的可视化视图来感知第一服务类型的第一供需比。提高了用户的出行效率和用户体验。

在一些实施例中，第一供需比的视图可以包括能够提供第一供需比的可视化的任何视图。图7示出了类似于仪表板的视图格式的第一供需比的视图。应注意，图7仅用于说明目的，第一气泡提醒信息可以包括第二服务类型的响应信息，对应于第二服务类型的用户界面的链接，以及第一服务类型的第一供需比的视图，或其任何组合。

图8示出了根据本申请的一些实施例的用于呈现第二气泡提醒信息的示例性流程的流程图。流程800可以由线上线下服务系统100或集成线上线下服务系统100的服务器执行。例如，流程800可以实现为存储在存储rom230或ram240中的一组指令(例如，应用程序)。处理器220可以执行该组指令，并且当执行指令时，可以将其配置为执行流程800。以下呈现的所示过程的操作旨在说明。在一些实施例中，流程800可以通过未描述的一个或多个以上附加操作和/或没有所讨论的操作的一个或以上来完成。另外，如图8所示和下面描述的过程操作的顺序不是限制性的。

流程800可以包括：响应于从用户终端120获取第一出行订单，服务器110可以将包括第一出行订单的排队编号的第二气泡提醒信息推送到用户终端120。

在810中，服务器110(例如，处理器220、接收模块411)可以从用户终端120获取第一出行订单。在一些实施例中，第一出行订单可包括目标服务类型、第一出行订单的第一发送时间、起始地点、目的地、起始时间等，或其任何组合。

在一些实施例中，当用户终端120的用户通过打车程序的用户界面发送具有起始地点和目的地的第一出行订单时，服务器110可以获取第一出行订单。

在820中，服务器110(例如，处理器220、确定模块412)可以根据目标服务类型的待分配的订单队列中的第一发送时间和至少一个第二出行订单的至少一个第二发送时间，确定第一出行订单的排队编号和等待时间。

在一些实施例中，至少一个第二出行订单可以包括用户终端120的区域内的至少两个其他用户终端发送的至少两个出行订单。该至少一个第二出行订单可以包括与第一出行订单相同的目标服务类型。

在一些实施例中，在服务器110从用户终端120获取第一出行订单之后，服务器110可以根据其发送时间的降序，对第一出行订单和在用户终端120的区域内的至少两个未处理的出行订单(也称为至少一个第二出行订单)进行排序。服务器110可以获取第一出行订单的排队编号。在一些实施例中，未处理的出行订单可以是服务器110没有分配的车辆的出行订单。未处理的出行订单的用户尚未分配给车辆以接载相应的用户。

在一些实施例中，第一出行订单的等待时间可以是服务器110将处理第一个订单所花费的时间。确定第一出行订单的等待时间的方式可以不限于本申请。例如，服务器110可以基于预定的出行订单的平均处理时间和第一出行订单的排队编号来确定等待时间。

在830中，服务器110(例如，处理器220、推送模块413)可以向用户终端120发送在用户终端120的用户界面上呈现的第二气泡提醒信息。在一些实施例中，第二气泡提醒信息可包括第一出行订单的排队编号和等待时间。

在一些实施例中，用户终端120可以以气泡的格式显示在至少两个未处理的出行订单的列表中的第一出行订单的排队编号和等待时间。当使用打车程序时，用户可以关注气泡。因此，用户可以通过第二气泡提醒信息及时获取用户的出行订单的处理状态。用户体验得到改善。

图9是根据本申请的一些实施例所示的用户终端上的应用程序的示例性用户界面。当用户在打车程序的用户界面上发送出行订单时，如图9所示，用户终端120可以在用户界面上以气泡的格式显示出行订单的状态和可以处理出行订单的累积时间。例如，气泡提醒信息可以包括“等待00:20。正在为你搜索车辆”。“等待00:20”可以是可以处理出行订单的累积时间。“正在为您搜索车辆”可能是出行订单的状态。

图9中所示的气泡提醒信息既不能向用户提供服务器110是否已经处理了他/她的出行订单，也不是用户等待的时间。用户体验很差。

图10是根据本申请的一些实施例所示的用户终端上的应用程序的示例性用户界面。如图10所示，在用户终端120向服务器110发送用于呼叫快车服务的第一出行订单之后，服务器110可以将包括第一出行订单的排队编号和等待时间的第二气泡提醒信息发送到用户终端120。这样，用户终端120可以以气泡的格式在用户界面上显示第一出行订单的排队编号和等待时间。例如，第二气泡提醒信息可能包括“你在队列中排第3位，请等待1分钟”。“第3位”可能是至少两个未处理的出行订单列表中第一出行订单的排队编号。“1分钟”可能是第一出行订单的等待时间。在一些实施例中，第二气泡提醒信息还可以包括原始气泡消息，例如，“你在队列中”的第一出行订单的状态，如图10所示。

因此，用户可以通过第二气泡提醒信息及时获取用户的第一出行订单的处理状态。用户体验得到改善。

在一些实施例中，服务器110可以设置时间阈值。时间阈值可以用于测量第一出行订单的等待时间是否太长。在一些实施例中，时间阈值可以由服务器110或其用户确定。例如，时间阈值可以是由服务器110或其用户确定的预设值。又例如，时间阈值可以根据不同的应用程序场景确定，例如不同的城市、不同的区域、不同的区域、不同的时间等，或者它们的任何组合。因此，服务器110(例如，处理器220、记录模块414)可以在接收到用户终端120发送的第一出行订单之后记录第一出行订单的等待时间。服务器110可以确定第一出行订单的等待时间是否小于时间阈值。当第一出行订单的等待时间不小于时间阈值时，可以指示在用户终端120的区域内对应于第一出行订单的可用车辆很少。因此，服务器110可能很长一段时间内都无法将对应于第一出行订单的车辆分配给用户终端120。在一些实施例中，服务器110可以将与第一出行订单相对应的车辆视为第一服务类型。如图7所示，服务器110可以将第二服务类型的响应信息的第一气泡提醒信息推送到用户终端120。相应地，用户终端120可以在接收到第一气泡提醒信息后在用户界面上显示第一气泡提醒信息。

图11示出了根据本申请的一些实施例的用于呈现第三气泡提醒信息的示例性流程的流程图。流程1100可以由线上线下服务系统100或集成线上线下服务系统100的服务器执行。例如，流程1100可以实现为存储在存储rom230或ram240中的一组指令(例如，应用程序)。处理器220可以执行该组指令，并且当执行该指令时，可以将其配置为执行该流程1100。以下呈现的所示过程的操作旨在说明。在一些实施例中，流程1100可以通过未描述的一个或多个以上附加操作和/或没有一个或以上所讨论的操作来完成。另外，如图11所示和下面描述的过程操作的顺序不是限制性的。

流程1100可以包括：响应于从用户终端120获取第一出行订单，服务器110可以将包括与第一出行订单相对应的车辆信息的第三气泡提醒信息推送到用户终端120。

在1110中，服务器110(例如，处理器220、分配模块415)可以基于第一出行订单将车辆分配给用户终端120。

在一些实施例中，服务器110可以基于用户终端120(或用户的起始地点)的位置来分配离用户终端120最近的车辆，其能够接载用户并且与用户终端120的第一出行订单中具有相同的服务类型。

在1120中，服务器110(例如，处理器220、推送模块413)可以向用户终端120发送在用户终端120的用户界面上呈现的第三气泡提醒信息。在一些实施例中，第三气泡提醒信息可包括与分配的车辆有关的信息。

在一些实施例中，与分配的车辆有关的信息可包括分配的车辆的颜色、分配的车辆的车牌号、分配的车辆的车型等，或其任何组合。在一些实施例中，与分配的车辆有关的信息可以进一步包括分配的车辆的司机名称、分配的车辆的司机的电话号码、分配的车辆可以到达用户终端120(或用户的起始地点)的位置的等待时间等，或其任何组合。

在一些实施例中，用户终端120可以以气泡的格式显示与分配的车辆有关的信息。当使用打车程序时，用户可以关注气泡。因此，用户可以及时获取与分配的车辆有关的信息(也指的是将接载用户的车辆)。用户体验得到改善。

图12是根据本申请的一些实施例所示的用户终端上的应用程序的示例性用户界面。如图12所示，在用户终端120向服务器110发送用于呼叫快车服务的第一出行订单之后，服务器110可以为用户终端分配快车。用户终端120可以在用户界面的底部显示快车的部分信息。例如，用户终端120可以在用户界面的底部显示快车的车牌号。

用户可能无法通过图12所示的用户界面获取快车的所有信息。当用户需要了解有关快车的更多信息时，用户必须操作更多以获取更多信息。用户体验很差。

图13是根据本申请的一些实施例所示的用户终端上的应用程序的示例性用户界面。如图13所示，在服务器110为用户终端120分配快车之后，服务器110可以将包括与快车有关的信息的第三气泡提醒信息发送到用户终端120。用户终端120可以以气泡的格式在用户界面上显示与快车有关的信息。例如，第三气泡提醒信息可包括“黑色、本田雅阁、jh4mf66”。“黑色”可能是快车的颜色。“本田雅阁”可能是快车的车型。“jh4mf66”可能是快车的车牌号。在一些实施例中，第三气泡提醒信息还可以包括原始气泡消息，例如，快车的等待时间(也指快车可以拿起用户的时间)是“1分钟”，如图13所示。

用户可以通过在用户终端120的用户界面上显示的第三气泡提醒信息获取分配的车辆的所有信息。用户体验得到改善。

图14是根据本申请所示的一些实施例的用户终端上的应用程序的示例性用户界面。如图14所示，可以存在至少两个服务类型，例如拼车服务、出租车服务、快车服务、公共汽车服务等，或其任何组合。在一些实施例中，用户可以在快车服务的用户界面上触发快车服务的出行订单。在一些实施例中，当在距离用户终端120的位置(或用户的起始地点)预定距离内的区域内的快车服务的车辆不足(快车服务短缺)时，服务器110可能无法为用户终端120匹配或分配快车。在一些实施例中，用户终端120可以在应用程序的用户界面上显示卡片消息。例如，卡片消息可以包括“取消为您呼叫车辆”。通过图14中所示的用户界面，用户可能只知道快车服务在该区域内供不应求，但可能无法获取便于用户出行的其他信息。用户体验相对较差。

图15示出了根据本申请的一些实施例的用于呈现第三气泡提醒信息的示例性流程的流程图。流程1500可以由线上线下服务系统100或集成线上线下服务系统100的服务器执行。例如，流程1500可以实现为存储在存储rom230或ram240中的一组指令(例如，应用程序)。处理器220可以执行该组指令，并且当执行该指令时，可以将其配置为执行该流程1500。以下呈现的所示过程的操作旨在说明。在一些实施例中，流程1500可以通过未描述的一个或多个以上附加操作和/或没有一个或以上所讨论的操作来完成。另外，如图15所示和下面描述的过程操作的顺序不是限制性的。

流程1500可以包括：响应于获取用户终端120的用户触发的第一出行订单，当用户终端120未被成功分配车辆时，服务器110可以将包括推荐的服务类型的属性信息的卡片提醒信息推送到用户终端120。

在1510中，服务器110(例如，处理器220、接收模块422)可以从用户终端120获取第一出行订单。在一些实施例中，第一出行订单可以由用户在用户终端120中的线上到线下服务应用程序的用户界面上触发。在一些实施例中，第一出行订单可包括目标服务类型、第一出行订单的第一发送时间、起始地点、目的地、起始时间、用户终端的位置等，或其任何组合。在一些实施例中，如果起始时间在发送第一出行订单时是默认的，则第一出行订单的第一发送时间可以与起始时间相同。在一些实施例中，如果起始地点默认在用户终端所在的位置，则起始地点可以与用户终端的位置相同。

在一些实施例中，用户可以点击对应于叫车服务应用程序的目标服务类型的用户界面上的叫车按钮，以触发目标服务类型的第一出行订单。在一些实施例中，用户还可以通过输入起始地点、目的地、出行时间等或其任何组合来触发目标服务类型的第一出行订单。用户还可以采用两种方式的组合来触发目标服务类型的第一出行订单。

在1520，响应于确定第一出行订单未被成功分配车辆，服务器110(例如，处理器220、发送模块421)可以向用户终端120发送在用户终端120的用户界面上呈现的卡片提醒信息。在一些实施例中，服务器110(例如，处理器220、显示模块423)可以指示用户终端120在用户终端120的用户界面上显示卡片提醒信息。在一些实施例中，卡片提醒信息可包括推荐的服务类型的属性信息。例如，推荐的服务类型的属性信息可以包括推荐的服务类型、推荐的服务类型的徽标(例如，其名称或图像)、推荐的服务类型等的响应时间，或其任何组合。推荐的服务类型的响应时间可以是推荐的服务类型的车辆到达用户的起始地点所花费的时间，这也称为接载时间。

在一些实施例中，服务器110可以基于起始地点确定目标服务类型的第二供需比。例如，服务器110可以在距离起始地点的预定距离内确定用户终端120的区域。服务器110可以确定该区域内的目标服务类型的第二供需比。第二供需比可以是可用车辆(或可用服务提供者)的数量与该区域中的用户终端(或请求目标服务类型的服务请求者)的数量的比例。服务器110可以确定第二供需比是否大于第二比例阈值。如果第二供需比不大于第二比例阈值，则服务器110可能不匹配目标服务类型的车辆给用户终端120。因此，服务器110可以确定第一出行订单未能被分配给车辆。在一些实施例中，该区域可以包括以用户终端120(或用户的起始地点)的位置为中心的圆形区域、正方形区域、六边形区域等。可以根据服务器的配置来确定预定距离，该配置在本申请中没有定义。在一些实施例中，第二比例阈值可以由服务器110或其用户确定。例如，第二比例阈值可以是由服务器110或其用户确定的预设值。又例如，第二比例阈值可以根据不同的应用程序场景确定，例如不同的城市、不同的区域、不同的区域、不同的时间等，或者它们的任何组合。在一些实施例中，第二比例阈值可以与第一比例阈值相同。或者，第二比例阈值可以与第一比例阈值不同。

在一些实施例中，如果服务器110从用户终端120获取第一出行订单的取消请求，则服务器110可以确定第一出行订单未被成功分配车辆。在一些实施例中，取消请求可以是用户在打车程序的用户界面上的触发。在一些实施例中，在服务器110将目标服务类型的车辆分配给用户终端120之前，取消请求可以是用户触发的取消请求(即，没有目标服务类型的车辆获取第一出行订单)。在一些实施例中，取消请求可以是用户在服务器110将目标服务类型的车辆分配给用户终端120之后，但是在相应的车辆接到用户终端120的用户之前(即，在用户上车之前)，触发的取消请求。

在一些实施例中，推荐的服务类型的响应时间可以小于目标服务类型的响应时间。例如，推荐的服务类型的可用车辆(或推荐的服务类型的可用服务提供者)可以比目标服务类型的用户更快地接载用户终端的用户。在一些实施例中，推荐的服务类型的第三供需比可以大于目标服务类型的第二供需比。例如，在该区域中可能存在比目标服务类型更多的可用车辆服务类型(或者推荐的服务类型的可用服务提供者)。在一些实施例中，推荐的服务类型的预估费用可小于目标服务类型的预估费用。例如，使用推荐的服务类型，用户可能比使用目标服务类型的成本更低。

图16是根据本申请的一些实施例所示的用户终端上的应用程序的示例性用户界面。如图16所示，用户在用户终端120的车载应用程序的用户界面上触发用于快车服务的第一出行订单之后，如果第一出行订单未能分配给快车，则用户终端120可以在用户界面上显示包括推荐的服务类型的属性信息的卡片提醒信息。例如，推荐的服务类型是公交服务，显示的卡片提醒信息可能包括“表示附近很少，试试公交车？1分钟接送”。“公交车”可能是推荐的服务类型的标志。“1分钟”可能是推荐的服务类型的响应时间。

例如，用户a可以在快车服务的用户界面上触发用于快车服务的第一出行订单。服务器110可以确定用户终端的区域中的快车服务的第二供需。如果第二供需不大于第二比例阈值，则服务器110可以确定该区域中快车服务的可用车辆不足。服务器110可能无法向用户a分配快车。用户a的用户终端可以显示卡片提醒信息，包括“附近的快车很少，尝试公交车？1分钟接送”。卡片提醒信息可以引导用户a选择公交车服务(也称为推荐的服务类型)。目的是引导用户选择其他类型的服务，以降低用户的流失率。

又例如，用户b可以在快车服务的用户界面上触发用于快车服务的第一出行订单。由于等待很长时间被分配到快车(即，快车的匹配时间长)或者计划选择其他出行模式，用户b可以主动取消第一出行订单。用户b的用户终端可以显示卡片提醒信息，包括“附近的快车很少，尝试公交车？1分钟接送”。卡片提醒信息可以指导用户b选择公交车服务(也称为推荐的服务类型)。目的是引导用户选择其他类型的服务，以降低用户的流失率。

卡片提醒信息可以直观且快速地向用户提供推荐的服务类型的属性信息。目的是引导用户选择其他类型的服务以降低用户的流失率。相应地，用户还可以基于其他服务类型的属性信息快速决定是否选择其他服务类型。提高了用户的出行效率和用户体验。

在一些实施例中，卡片提醒信息可以包括触发针对推荐的服务类型的推荐出行订单的操作选项。在一些实施例中，触发推荐的服务类型的推荐出行订单的操作选项可以包括用于触发推荐的服务类型的操作按钮，用于推荐的服务类型的用户界面的链接，用于触发推荐的服务类型的链接，或其任何组合。这样，用户通过卡片提醒信息获取推荐的服务类型的属性信息后，如果用户决定使用推荐的服务类型出行，他/她可以通过单击卡片提醒信息上显示的操作选项快速触发推荐的服务类型的推荐出行订单。提高了用户的出行效率和用户体验。

在一些实施例中，卡片提醒信息可以包括推荐的服务类型的推荐出行订单的预估费用，用于推荐的服务类型的推荐出行订单的预估费用与用于目标服务类型的第一出行订单的预估费用之间的费用差等，或其任何组合。以这种方式，卡片提醒信息可以直观且快速地向用户提供推荐的服务类型的预估费用。用户还可以获取两个服务类型之间的费用差。用户可以基于推荐的服务类型的费用差和预估费用来确定是否选择推荐的服务类型。提高了用户的出行效率和用户体验。

在一些实施例中，卡片提醒信息可以包括推荐的服务类型、推荐的服务类型的响应时间、为推荐的服务类型触发推荐的出行订单的操作选项、推荐的服务类型的预估费用、用于推荐的服务类型的推荐出行订单的预估费用与用于目标服务类型的第一出行订单的预估费用之间的费用差等，或其任何组合。图17是根据本申请的一些实施例的用户终端上的应用程序的示例性用户界面。如图17所示，卡片提醒信息可以包括推荐的服务类型的属性信息，用于触发推荐的服务类型的操作按钮，用于推荐的服务类型的推荐出行订单的预估费用，以及推荐的服务类型推荐出行订单的预估费用与目标服务类型的第一出行订单的预估费用之间的费用差。

如图17所示，“公交车”可以是推荐的服务类型的标志。“1分钟”可能是推荐的服务类型的响应时间。“呼叫”按钮可以是用于触发推荐的服务类型的操作选项按钮。“为你节省6元”可能是推荐的服务类型推荐出行订单与目标服务类型的预估费用之间的费用差。“约17元”可能是推荐的服务类型的预估费用。

在一些实施例中，为了使用户能够快速获取有效信息，卡片提醒信息可以包括两个区域。第一区域可能包括运营广告提示信息，例如，“附近的快车很少，试试公交车？1分钟接送，为您节省6元”。在一些实施例中，可以突出显示第一区域中的运营广告提示信息，使得用户可以快速捕获提示信息。第二区域可以包括推荐的服务类型的详细信息。例如，第二区域可以包括第二服务类型的属性，用于触发推荐的服务类型的操作按钮以及推荐的服务类型的推荐出行订单的预估费用。第二区域中的详细信息可以直观且快速地提供推荐服务类型的相关信息。提高了用户的出行效率和用户体验。

在一些实施例中，卡片提醒信息还可以包括推荐的服务类型的车辆可以到达目的地的总预估时间、推荐的服务类型的广告等，或其任何组合。如图17所示，卡片提醒信息可包括“34分钟到达”和“随机免费”。用户可以获取推荐的服务类型的综合相关信息。

应注意，图17仅用于说明目的。例如，图17中所示的卡片提醒信息中的所有内容的布局，分布和表示仅是示意性的，并且不限于本申请。例如，卡可以通过从底部向顶部飞出而显示在用户界面上，或者可以以其他形式显示在用户界面上，如从左到右剥落、从右向左飞出、从顶部飞到底部、旋转飞出。本申请未定义上述卡片提醒信息在用户界面上显示的位置。

在一些实施例中，可以从用户终端120描述用于呈现包括推荐的服务类型的属性信息的卡片提醒信息的过程。或者，可以从服务器110描述该过程。

图18示出了根据本申请的一些实施例的用于在用户终端上呈现卡片提醒信息的指令的流程图。如图18所示，指令可以包括在用户终端120将第一出行订单发送到服务器110之后。响应于服务器未能将目标服务类型的车辆分配给用户终端120的情况，服务器110可以将卡片提醒信息推送到用户终端120。

在1810中，用户终端120可以向服务器110发送第一出行订单。在一些实施例中，第一出行订单可用于指示服务器110匹配用户终端120的目标服务类型的车辆。第一出行订单可以包括用户选择的目标服务类型的标识、起始地点、起始时间、目的地等，或其任何组合。

在1820，服务器110可以获取第一出行订单。

在1830，响应于确定第一出行订单未被成功分配车辆，服务器110可以向用户终端120发送卡片提醒信息。

在一些实施例中，如果用户终端120的用户在用户终端120的用户界面上触发对第一出行订单的取消请求，服务器110从用户终端120获取第一出行订单的取消请求。服务器110(例如，处理器220、处理模块424)可以确定第一出行订单未被成功分配车辆。

在一些实施例中，服务器110(例如，处理器220、处理模块424)可以基于起始地点确定目标服务类型的第二供需比。例如，服务器110可以在距离起始地点的预定距离内确定用户终端120的区域。服务器110可以确定该区域内的目标服务类型的第二供需比。第二供需比可以是可用车辆(或可用服务提供者)的数量与该区域中的用户终端(或请求目标服务类型的服务请求者)的数量的比例。服务器110(例如，处理器220、处理模块424)可以确定第二供需比是否大于第二比例阈值。如果第二供需比不大于第二比例阈值，则服务器110可能不匹配目标服务类型的车辆给用户终端120。因此，服务器110(例如，处理器220、处理模块424)可以确定第一出行订单未被分配给车辆。在一些实施例中，该区域可以包括以用户终端120(或用户的起始地点)的位置为中心的圆形区域、正方形区域、六边形区域等。可以根据服务器的配置来确定预定距离，该配置在本申请中没有定义。

在一些实施例中，服务器110(例如，处理器220、处理模块424)可以基于打车程序的操作策略来确定推荐的服务类型。例如，推荐的服务类型可以是打车程序带来的最新服务类型。在一些实施例中，服务器110可以基于打车程序的用户终端120的用户行为数据或历史出行信息来确定推荐的服务类型。例如，推荐的服务类型可以是用户终端120的用户在历史中最常使用的服务类型。

在一些实施例中，历史出行信息可以包括用户终端120的历史出行时间、用户终端120的历史开始信息、用户终端120的历史目的地、历史目标服务类型、用户终端120的历史出行记录等，或其任何组合。

在一些实施例中，服务器110可以确定具有比目标服务类型的供需比更大的供需比的服务类型，并且将该服务类型分配为推荐的服务类型。例如，目标服务类型是快车服务。服务器110可以基于用户终端120的起始地点确定用户终端120的区域内的专车服务的供需比大于快车服务的供需比。专车服务可以被指定为推荐的服务类型，以推荐给用户终端120。

在一些实施例中，服务器110可以确定到达起始地点的相应距离比目标服务类型的相应距离短的服务类型，并且将相应的服务类型分配为推荐的服务类型。在一些实施例中，服务器110可以确定响应时间小于目标服务类型的服务类型，并将相应的服务类型分配为推荐的服务类型。例如，目标服务类型是快车服务。服务器110可以获取用户终端120的区域内的至少两个服务类型的多个车辆的定位信息。如果服务器110确定专车比该区域内的最近快车更靠近用户终端120。服务器110可以将专车服务分配为推荐的服务类型以推荐给用户终端120。

在一些实施例中，服务器110可以基于起始地点，目的地和起始时间确定对应的预估费用在该区域内的至少两个服务类型中最少的服务类型。服务器110可以将所确定的服务类型分配为推荐的服务类型。例如，目标服务类型是快车服务。服务器110确定该区域中的出租车服务的预估费用小于快车服务的预估费用。服务器110可以将出租车服务分配为推荐的服务类型以推荐给用户终端120。

在一些实施例中，服务器110可以确定用户的出行偏好。服务器110可以基于出行偏好确定服务类型。例如，目标服务类型是快车服务。服务器110基于用户终端120的历史出行信息确定用户可能打算以经济和快速的服务类型(例如公共汽车服务)旅行。服务器110可以将公共汽车服务分配为推荐的服务类型以推荐给用户终端120。

在1840年，用户终端120可以获取卡片提醒信息。

用户可以通过用户终端120的用户界面上显示的卡片提醒信息获取其他服务类型的属性信息。目的是引导用户选择其他类型的服务以降低用户的流失率。另外，用户可以基于属性信息确定是否选择其他服务类型。提高了用户的出行效率和用户体验。

上文已对基本概念做了描述，显然，对于阅读此申请后的本领域的普通技术人员来讲，上述详细揭露仅作为示例，而并不构成对本申请的限制。虽然此处并未明确说明，但本领域的普通技术人员可以进行各种变更、改良和修改。该类修改、改进和修正在本申请中被建议，所以该类修改、改进、修正仍属于本申请示范实施例的精神和范围。

同时，本申请使用了特定词语来描述本申请的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本申请至少一个实施例相关之某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一替代性实施例”并不一定是指同一实施例。此外，本申请的一个或多个实施例中的某些特征、结构或特性可以进行适当的组合。

此外，本领域技术人员可以理解，本申请的各方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的工序、机器、产品或物质的组合，或对他们的任何新的和有用的改进。相应地，本申请的各个方面可以完全由硬件执行、可以完全由软件(包括固件、常驻软件、微码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“数据块”、“模块”、“引擎”、“单元”、“组件”或“系统”。此外，本申请的各方面可以采取体现在一个或以上计算机可读介质中的计算机程序产品的形式，其中计算机可读程序代码包含在其中。

计算机可读信号介质可以包括传播的数据信号，其中包含计算机可读程序代码，例如，在基带中或作为载波的一段。此类传播信号可以有多种形式，包括电磁形式、光形式等或任何合适的组合形式。计算机可读信号介质可以是除计算机可读存储介质之外的任何计算机可读介质，该介质可以通过连接至一个指令执行系统、装置或装置以实现通信、传播或传输供使用的程序。位于计算机可读信号介质上的程序代码可以通过任何合适的介质进行传播，包括无线电、电缆、光纤电缆、rf、或类似介质、或任何上述介质的组合。

本申请各部分操作所需的计算机程序代码可以用任意一种或以上程序设计语言编写，包括面向对象程序设计语言如java、scala、smalltalk、eiffel、jade、emerald、c++、c#、vb.net、python等，常规程序化程序设计语言如c程序设计语言、visualbasic、fortran1703、perl、cobol1702、php、abap，动态程序设计语言如python、ruby和groovy，或其他程序设计语言等。程序代码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机上运行、或完全在远程计算机或服务器上运行。在后种情况下，远程计算机可以通过任何网络形式与用户计算机连接，比如局域网(lan)或广域网(wan)，或连接至外部计算机(例如，通过互联网使用互联网服务提供者)，或在云计算环境中，或作为服务使用如软件即服务(saas)。

然而，这些修正和改变仍然在本申请的保护范围之内。此外，处理元素或者序列的列举顺序、数字、字母或者其他名称的使用不是用于限制要求的过程和方法的。尽管上述申请中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解，此类细节仅起说明的目的，附加的申请专利范围并不仅限于申请的实施例，相反，申请专利范围旨在覆盖所有符合本申请实施例精神和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件装置实现，但是也可以只通过软件的解决方案得以实现，如在现有的服务器或移动装置上安装所描述的系统。

同理，应当注意的是，为了简化本申请揭示的表述，从而帮助对一个或以上发明实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。然而，本申请的该方法不应被解释为反映所声称的待扫描对象物质需要比每个权利要求中明确记载的更多特征的意图。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

一些实施例中使用了描述成分、属性数量的数字，应当理解的是，此类用于实施例描述的数字，在一些示例中使用了修饰词“大约”、“近似”或“大体上”来修饰。除非另外说明，“大约”、“近似”或“大体上”表明所述数字允许有±20％的变化。相应地，在一些实施例中，说明书和权利要求中使用的数值参数均为近似值，该近似值根据个别实施例所需特点可以发生改变。在一些实施例中，数值参数应考虑规定的有效数位并采用一般位数保留的方法。尽管本申请一些实施例中用于确认其范围广度的数值域和参数为近似值，在具体实施例中，此类数值的设定在可行范围内尽可能精确。

每项专利、专利申请程序、专利申请程序的出版物和其他材料，本文引用的诸如文章、书籍、规范、出版物、文档、事物和/或类似物的内容在此通过引用整体并入本文用于所有目的，除与本文件有关或与本文件有冲突的任何相同的起诉档案历史外，或者对于现在或以后与本文件相关的权利要求的最宽范围可能具有限制性影响的任何相同的内容。举例来说，如果与任何合并材料相关的术语的描述、定义和/或使用与本文件相关的术语之间存在任何不一致或冲突，以本文件中的术语的描述、定义和/或用法为准。

最后，应当理解的是，本申请中所述实施例仅用以说明本申请实施例的原则。其他的变形也可能属于本申请的范围。因此，作为示例而非限制，本申请实施例的替代配置可视为与本申请的教导一致。因此，本应用程序的实施例不限于本申请明确介绍和描述的实施例。