CN112862131A - 信息处理方法及装置 - Google Patents

Abstract

本说明书提供一种信息处理方法及装置；该方法应用于打车服务端，可以包括：获取用户当前的打车行程路径；获取兴趣点集合，所述兴趣点集合中任一兴趣点对应一实体门店，所述实体门店的门店位置与所述打车行程路径相匹配；向所述用户的用户客户端推送所述兴趣点集合的兴趣点信息。

Description

信息处理方法及装置

技术领域

本说明书一个或多个实施例涉及数据处理技术领域，尤其涉及一种信息处理方法及装置。

背景技术

在相关技术中，网络打车平台向用户提供网络打车服务。具体而言，用户可通过用户客户端发布行程，由网络打车平台的服务端根据行程生成打车订单，并向在网络打车平台注册的司机派发打车订单。司机通过司机客户端接单后，开车前往用户行程的起点接用户上车。

在打车过程中，用户可通过用户客户端查询订单详情，比如用户客户端的页面可展示司机信息、价格、行驶路线等信息。

发明内容

有鉴于此，本说明书一个或多个实施例提供一种信息处理方法及装置。

为实现上述目的，本说明书一个或多个实施例提供技术方案如下：

根据本说明书一个或多个实施例的第一方面，提出了一种信息处理方法，应用于打车服务端，所述方法包括：

获取用户当前的打车行程路径；

获取兴趣点集合，所述兴趣点集合中任一兴趣点对应一实体门店，所述实体门店的门店位置与所述打车行程路径相匹配；

向所述用户的用户客户端推送所述兴趣点集合的兴趣点信息。

可选的，所述兴趣点信息至少包括相应的目标实体门店的门店名称和预设触发控件的信息；其中，所述兴趣点信息与打车引导页面位于所述用户客户端的同一页面上。

可选的，所述预设触发控件用于响应用户针对所述目标实体门店的预约下单触发操作，将所述打车引导页面跳转至预约下单操作页面，所述预约下单操作页面为所述目标实体门店的用户客户端页面。

可选的，还包括：根据所述打车行程路径确定对应的时间信息，所述时间信息包括到达行程终点的到达时间信息和至少一个行程途经地点的途经时间信息；获取所述兴趣点集合中兴趣点对应的实体门店的营业状态信息，并过滤出营业状态信息与所述途经时间信息或所述到达时间信息相匹配的实体门店；

所述向所述用户的用户客户端推送所述兴趣点集合的兴趣点信息，包括：向所述用户客户端推送过滤出的实体门店对应的兴趣点信息。

可选的，还包括：

接收所述用户客户端发送的针对第一预约商品的预约下单请求，所述第一预约商品为与任一行程途经地点相匹配的实体门店提供的商品；预估所述第一预约商品的制作完成时间信息，并将预估得到的制作完成时间信息和对应于所述任一行程途经地点的途经时间信息作为第一预估结果返回至所述用户客户端；指示预约订单服务端实施针对所述第一预约商品的预约下单操作；

和/或，接收所述用户客户端发送的针对第二预约商品的预约下单请求，所述第二预约商品为与所述到达行程终点相匹配的实体门店提供的商品；预估所述第二预约商品的制作完成时间信息，并将预估得到的制作完成时间信息和所述到达时间信息作为第二预估结果返回至所述用户客户端；指示预约订单服务端实施针对所述第二预约商品的预约下单操作。

可选的，

所述指示预约订单服务端实施针对所述第一预约商品的预约下单操作，包括：在预估得到的制作完成时间信息早于所述任一行程途经地点的途经时间信息的情况下，指示预约订单服务端实施针对所述第一预约商品的预约下单操作；在预估得到的制作完成时间信息晚于所述任一行程途经地点的途经时间信息的情况下，若接收到所述用户客户端发送的针对所述第一预估结果的确认请求，则指示预约订单服务端实施针对所述第一预约商品的预约下单操作；

所述指示预约订单服务端实施针对所述第二预约商品的预约下单操作，包括：在预估得到的制作完成时间信息早于所述到达时间信息的情况下，指示预约订单服务端实施针对所述第二预约商品的预约下单操作；在预估得到的制作完成时间信息晚于所述到达时间信息的情况下，若接收到所述用户客户端发送的针对所述第二预估结果的确认请求，则指示预约订单服务端实施针对所述第二预约商品的预约下单操作。

可选的，还包括：

响应于所述用户客户端发送的针对所述兴趣点信息指示的目标实体门店的预约下单请求，实施相应的预约下单操作；

根据所述目标实体门店的门店位置重新规划打车行程路径；其中，重新规划后的打车行程路径的到达行程终点为所述目标实体门店的门店位置，重新规划后的打车行程路径的行程途经地点相比于重新规划前的行程途经地点更靠近于所述目标实体门店的门店位置。

可选的，还包括：

获取所述兴趣点信息指示的目标实体门店的虚拟权益，并向所述用户客户端发送所述虚拟权益；

响应于所述用户客户端发送的虚拟权益领取请求，向所述用户客户端对应的用户账号发放所述虚拟权益领取请求指示的虚拟权益；其中，所述用户账号关联的虚拟权益用于作为生成与所述用户账号对应的预约订单的依据。

可选的，还包括：

确定打车高峰时间段，并在所述打车高峰时间段内降低向任一用户账号发放虚拟权益的频率和/或数量。

可选的，还包括：

接收所述用户客户端发送的针对所述兴趣点信息指示的目标实体门店的预约下单请求，所述预约下单请求包含预约下单信息；

向预约订单服务端发送所述预约下单信息，以由所述预约订单服务端根据所述预约下单信息生成预约订单；

获取所述预约订单服务端返回的针对所述预约订单的预约下单结果，并将所述预约下单结果转发至所述用户客户端。

可选的，在生成所述预约订单后，所述打车行程路径对应的打车订单的第一订单标识与所述预约订单的第二订单标识之间被建立有映射关系；所述方法还包括：

在接收到所述用户客户端发送的针对所述预约订单的订单查询请求的情况下，向所述预约订单服务端发送所述第一订单标识，以由所述预约订单服务端根据所述第一订单标识和所述映射关系确定出所述第二订单标识，并根据所述第二订单标识获取所述预约订单的预约订单信息；

获取所述预约订单服务端返回的预约订单信息，并将所述预约订单信息转发至所述用户客户端。

可选的，还包括：

接收所述用户客户端发送的包含修改后到达行程终点的修改请求；

根据所述修改后到达行程终点重新确定打车行程路径，以重新确定出兴趣点集合；

向所述用户客户端推送重新确定出的兴趣点集合的兴趣点信息，以由所述用户客户端将接收到的兴趣点信息指示的目标实体门店的门店位置作为到达行程终点的修改建议进行展示。

根据本说明书一个或多个实施例的第二方面，提出了一种信息处理方法，应用于用户的用户客户端，所述方法包括：

接收打车服务端推送的兴趣点集合的兴趣点信息，所述兴趣点集合中任一兴趣点对应一实体门店，所述实体门店的门店位置与用户当前的打车行程路径相匹配；

展示所述兴趣点集合的兴趣点信息。

可选的，所述兴趣点信息至少包括相应的目标实体门店的门店名称和预设触发控件的信息；所述展示所述兴趣点集合的兴趣点信息，包括：

在同一页面上展示所述兴趣点信息与打车引导页面。

可选的，还包括：

响应于用户针对所述目标实体门店的预约下单触发操作，通过所述预设触发控件将所述打车引导页面跳转至预约下单操作页面，所述预约下单操作页面为所述目标实体门店的用户客户端页面。

可选的，所述兴趣点信息指示的实体门店由所述打车服务端从兴趣点集合对应的实体门店中过滤出营业状态信息与用户当前的打车行程路径对应的时间信息相匹配的实体门店而得到，所述时间信息包括到达行程终点的到达时间信息和至少一个行程途经地点的途经时间信息；

可选的，还包括：

接收所述打车服务端发送的所述兴趣点信息指示的目标实体门店的虚拟权益；

在检测到用户针对所述虚拟权益的领取触发操作的情况下，向所述打车服务端发送虚拟权益领取请求，以由所述打车服务端向所述用户客户端对应的用户账号发放所述虚拟权益领取请求指示的虚拟权益；

其中，所述用户账号关联的虚拟权益用于作为生成与所述用户账号对应的预约订单的依据。

可选的，还包括：

向所述打车服务端发送针对所述兴趣点信息指示的目标实体门店的预约下单请求，以由所述打车服务端向预约订单服务端发送所述预约下单请求包含的预约下单信息，所述预约订单服务端用于根据所述预约下单信息生成预约订单；

接收所述打车服务端返回的从所述预约订单服务端处获取到的针对所述预约订单的预约下单结果。

可选的，在生成所述预约订单后，所述打车行程路径对应的打车订单的第一订单标识与所述预约订单的第二订单标识之间被建立有映射关系；所述方法还包括：

向所述打车服务端发送针对所述预约订单的订单查询请求，以由所述打车服务端向所述预约订单服务端发送所述第一订单标识，所述预约订单服务端用于根据所述第一订单标识和所述映射关系确定出所述第二订单标识，并根据所述第二订单标识获取所述预约订单的预约订单信息；

接收所述打车服务端返回的从所述预约订单服务端处获取到的预约订单信息。

可选的，还包括：

根据检测到的用户针对所述打车行程路径的修改操作生成相应的修改请求，所述修改请求包含所述修改操作指示的修改后行程终点；

向所述打车服务端发送包含修改后到达行程终点的修改请求，以由所述打车服务端根据所述修改后到达行程终点重新确定打车行程路径，以重新确定出兴趣点集合；

接收所述打车服务端推送的重新确定出的兴趣点集合的兴趣点信息，并将接收到的兴趣点信息指示的目标实体门店的门店位置作为到达行程终点的修改建议进行展示。

根据本说明书一个或多个实施例的第三方面，提出了一种信息处理装置，应用于打车服务端，所述装置包括：

信息获取单元，获取用户当前的打车行程路径；

兴趣点获取单元，获取兴趣点集合，所述兴趣点集合中任一兴趣点对应一实体门店，所述实体门店的门店位置与所述打车行程路径相匹配；

推送单元，向所述用户的用户客户端推送所述兴趣点集合的兴趣点信息。

根据本说明书一个或多个实施例的第四方面，提出了一种信息处理装置，应用于用户的用户客户端，所述装置包括：

接收单元，接收打车服务端推送的兴趣点集合的兴趣点信息，所述兴趣点集合中任一兴趣点对应一实体门店，所述实体门店的门店位置与用户当前的打车行程路径相匹配；

展示单元，展示所述兴趣点集合的兴趣点信息。

根据本说明书一个或多个实施例的第五方面，提出了一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器通过运行所述可执行指令以实现如上述任一实施例中所述的方法。

根据本说明书一个或多个实施例的第六方面，提供一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如上述实施例中任一所述方法的步骤。

由以上实施例可见，针对需要用户到店的实体门店，本说明书的技术方案可在打车过程中为用户提供该类实体门店的在线预约下单服务。具体而言，根据用户的打车行程路径查询可为用户提供预约下单服务的实体门店，并向用户推送查询到的实体门店对应的兴趣点信息以供用户选择。

一方面，查询到的实体门店的地理位置与用户的整个打车过程相匹配，那么用户针对这些实体门店进行预约下单并到店，与用户打车的行程安排不会冲突，即不影响用户的打车体验；并且，方便用户到店，用户到店之前已完成下单操作，减少用户的等待时间。另一方面，向用户客户端推送查询到的兴趣点信息以供用户触发相应的预约下单操作，使得用户无需通过搜索操作来查询兴趣点，可简化用户预约下单的操作，从而提高用户预约下单的效率。

附图说明

图1是一示例性实施例提供的一种信息处理系统的架构示意图。

图2是一示例性实施例提供的一种信息处理方法的流程图。

图3是一示例性实施例提供的另一种信息处理方法的流程图。

图4是一示例性实施例提供的一种信息处理方法的交互图。

图5是一示例性实施例提供的一种用户客户端页面的示意图。

图6A-6C是一示例性实施例提供的另一种用户客户端页面的示意图。

图7是一示例性实施例提供的另一种用户客户端页面的示意图。

图8是一示例性实施例提供的一种电子设备的结构示意图。

图9是一示例性实施例提供的一种信息处理装置的框图。

图10是一示例性实施例提供的另一种信息处理装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。

需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。

图1是一示例性实施例提供的一种信息处理系统的架构示意图。如图1所示，该系统可以包括服务器11、服务器12、若干电子设备(比如手机13、手机14和手机15等)和网络16。

服务器11和服务器12可以为包含一独立主机的物理服务器，或者服务器11-12可以为主机集群承载的虚拟服务器。在运行过程中，服务器11-12可以运行某一应用的服务器侧的程序，以作为相应的服务端实现该应用的相关业务功能。比如，服务器11可运行打车应用的服务器侧程序，以实现为打车平台的打车服务端；服务器12可运行预约下单应用的服务器侧程序，以实现为下单平台的预约下单服务端。

手机13-15表示用户可以使用的一种类型的电子设备。实际上，用户显然还可以使用诸如下述类型的电子设备：平板设备、笔记本电脑、掌上电脑(PDAs，Personal DigitalAssistants)、可穿戴设备(如智能眼镜、智能手表等)等，本说明书一个或多个实施例并不对此进行限制。在运行过程中，该电子设备可以运行某一应用的客户端侧的程序，以实现该应用的相关业务功能。比如，手机13-15可运行打车应用的客户端侧程序，以实现为打车平台的用户客户端。

而对于手机13-15与服务器11、服务器11与服务器12之间进行交互的网络16，可以包括多种类型的有线或无线网络。比如，网络16可以包括公共交换电话网络(PublicSwitched Telephone Network，PSTN)和因特网。其中，服务器11与手机13-15之间可以通过网络16建立长连接，使得服务器11通过该长连接向手机13-15发送推送消息等。或者，尤其是对于服务器11与手机13-15之间并未(或无法)建立长连接的情况下，服务器11可以根据手机13-15上运行的操作系统，向相应的操作系统服务器发送推送消息，并由该操作系统服务器将该推送消息进一步发送至手机13-15。

请参见图2，图2是一示例性实施例提供的一种信息处理方法的流程图。如图2所示，该推送方法应用于打车服务端，可以包括以下步骤：

步骤202，获取用户当前的打车行程路径。

可由用户的用户客户端向打车服务端发送打车行程。比如，在用户通过用户客户端输入打车的出发行程起点和到达行程终点后，用户客户端可将该起点和终点发送至打车服务端，即在用户上车之前完成获取打车行程路径的操作以用于后续的信息处理。在该情况下，还可进一步根据所述打车行程路径确定对应的时间信息，所述时间信息包括到达行程终点的到达时间信息和至少一个行程途经地点的途经时间信息。比如，打车服务端可根据出发行程起点和到达行程终点规划打车行程路径，并确定相应的时间信息，从而确定到达行程终点的到达时间信息(比如预计到达时刻)和行程途经地点的途经时间信息(比如预计途经时刻)。其中，打车服务端规划行程路径并确定相应行程时长的过程可参考相关技术中的记载，本说明书并不对此进行限制。

除此之外，可在用户上车之后由用户客户端(或者司机客户端)实时向打车服务端上传用户的位置信息(即当前用户位置)，那么打车服务端可根据当前用户位置和行程路线确定实时的时间信息，进而在用户的打车过程中实时地进行信息处理。当然，用户的位置信息也可由司机客户端来实时上传，本说明书并不对此进行限制。

步骤204，获取兴趣点集合，所述兴趣点集合中任一兴趣点对应一实体门店，所述实体门店的门店位置与所述打车行程路径相匹配。

为了保证推送的兴趣点信息指示的实体门店(以下称为目标实体门店)能够向用户提供预约下单服务，还可进一步获取所述实体门店的营业状态信息，过滤出营业状态信息与所述途经时间信息或所述到达时间信息相匹配的目标实体门店。

实体门店可向用户提供预约下单服务，同时打车服务端可接入电商平台，从而在注册至电商平台的实体门店中查询实体门店以得到兴趣点集合，进而从兴趣点集合对应的实体门店中过滤出目标实体门店。比如，电商平台可提供实体门店查询接口以供打车服务端查询实体门店的实体门店位置和营业状态信息，查询门店位置与打车行程路径(到达行程终点或行程途经地点)相匹配的实体门店，并将查询得到的实体门店对应的兴趣点添加至兴趣点集合。然后，从兴趣点集合中过滤出营业状态信息与时间信息(途经时间信息或到达时间信息)相匹配的目标实体门店，进而将过滤得到的目标实体门店对应的兴趣点信息推送至用户客户端。当然，获取兴趣点集合和过滤得到目标实体门店的操作可由电商平台来执行，然后由电商平台将目标实体门店的兴趣点信息发送至打车服务端。

在一种情况下，本说明书的技术方案可在用户的到达行程终点附近向该用户推送兴趣点。在该情况下，打车行程路径可以包括到达行程终点，确定出的到达时间信息可包括到达行程终点对应的预计到达时刻；其中，兴趣点集合中任一兴趣点对应的实体门店的门店位置在到达行程终点的预设范围内。进一步的，打车服务端可仅向用户客户端推送距离到达行程终点最近的目标实体门店的兴趣点信息，以供用户在目标实体门店预约下单。当然，也可选取门店位置与到达行程终点的距离在预设排名之前的实体门店。

在另一种情况下，本说明书的技术方案可在用户的整个行程路径上的任意位置附近向该用户推送兴趣点。在该情况下，打车行程路径可包括至少一个行程途经地点，确定出的行程时间信息可包括打车行程路径中任意位置对应的预计到达时刻(即途经时间信息)；其中，兴趣点集合中任一兴趣点对应的实体门店的门店位置在该任意位置的预设范围内。

需要说明的是，上述各个预设范围的取值均可根据实际情况灵活设定，比如200米、500米、50米等等，本说明书并不对此进行限制。

除上述在营业状态和门店位置的维度上确定兴趣点之外，还可从兴趣点类型(即门店类型)这一维度来确定待推送的兴趣点。比如，可根据以下信息中至少之一确定兴趣点集合包含的兴趣点类型：预设兴趣点类型、用户的历史行为信息、当前时间信息；其中，历史行为信息包括针对兴趣点的历史搜索关键词和/或针对预约下单服务的历史预约订单。下面结合举例进行说明。

可预先设置特定的兴趣点类型，后续在查询兴趣点集合时，仅在属于该特定兴趣点类型的兴趣点中执行查询匹配操作。比如，咖啡店、奶茶店、理发店等。甚至，可以指定某一特定品牌的实体门店；比如，与网络打车平台合作的门店品牌。

可根据用户的历史行为信息来确定该用户的潜在需求，从而根据潜在需求来选取相应类型的兴趣点。其中，历史行为信息可以包括用户针对兴趣点的历史搜索关键词和/或针对预约下单服务的历史预约订单。比如，用户在网络打车平台(或者接入网络打车平台的其他网络平台)的历史搜索关键词(搜索门店的关键词，比如为门店名称、门店类型等)能够在一定程度上反映该用户的需求；又如，用户针对预约下单服务的历史预约订单也能够在一定程度上反映该用户的需求。举例而言，用户曾经在打车过程中搜索过咖啡店，或者曾经在打车过程中预约下单了某一实体门店的咖啡，则可将咖啡店作为待推送的兴趣点的类型。

可根据当前时间信息来确定用户的潜在需求，从而根据潜在需求来选取相应类型的兴趣点。比如，在18:00-20:00这一时间段用户可能存在用餐需求，那么可以将餐饮店作为待推送的兴趣点的类型。

进一步的，针对兴趣点类型存在多个的情况，可针对各类兴趣点设置优先级，以将匹配命中的兴趣点中优先级相对较高的兴趣点添加至兴趣点集合。同时，针对推送同一类型兴趣点下多个不同兴趣点的情况，原理与上述类似。

打车服务端在获取到打车行程路径后，可生成相应的打车订单，并向司机客户端派发打车订单以由司机通过司机客户端接单。那么，在接收到任一司机客户端针对该打车订单的接单确认消息时，可向该任一司机客户端分配打车订单。经上述过程可完成“发布行程”以及“司机接单”的过程。进一步的，打车服务端可在“司机接单”后，再执行获取兴趣点集合的操作。比如，打车服务端可在向司机客户端分配打车订单后，再获取兴趣点集合。由于在“司机接单”后，用户的打车行程路径相对“司机接单”之前更为稳定(比如，没有司机接单则无需执行后续推送兴趣点的操作；又如，用户可能取消打车，改为其他交通方式等)，通过在“司机接单”后再执行获取兴趣点集合的操作，可减少不必要的信息处理操作的次数，从而减少对打车服务端处理资源的占用。除此之外，通常情况下相比于上车之后，用户在上车之前通过用户客户端查看打车页面的概率更高(或者是查看的时间更长)，那么可仅在用户上车之前实施本说明书中的信息处理过程，从而减少对打车服务端处理资源的占用。

步骤206，向所述用户的用户客户端推送所述兴趣点集合的兴趣点信息。

向用户客户端推送的兴趣点信息可包括目标实体门店的门店名称和预设触发控件的信息。用户客户端在接收到兴趣点信息后，可在同一页面上展示兴趣点信息与打车引导页面(用于引导用户执行打车操作和查看打车信息的页面)，从而在不影响用户打车体验的前提下为用户推送兴趣点。换言之，兴趣点信息与打车引导页面位于用户客户端的同一页面上。

比如，可通过触发控件来展示目标实体门店的兴趣点信息。例如，用户客户端通过按钮、气泡、卡片、tips等触发控件来展示兴趣点信息，从而协助用户对目标实体门店提供的预约下单服务进行预约下单。其中，触发控件可用于响应用户针对目标实体门店的预约下单触发操作(触发进入下单流程)，将打车引导页面跳转至预约下单操作页面，预约下单操作页面为目标实体门店的用户客户端页面。那么，用户便可在预约下单操作页面进行预约下单。

下面以实体门店向用户提供预约商品为例进行说明。

对于目标实体门店中与任一行程途经地点相匹配的实体门店提供的商品(以下简称为第一预约商品)，用户可通过用户客户端实施针对第一预约商品的预约下单。具体而言，打车服务端可接收用户客户端发送的针对第一预约商品的预约下单请求，然后预估第一预约商品的制作完成时间信息，并将预估得到的制作完成时间信息和对应于该任一行程途经地点的途经时间信息作为第一预估结果返回至用户客户端，以由用户进行确认。同时，打车服务端可指示预约订单服务端实施针对第一预约商品的预约下单操作。

其中，在指示预约订单服务端实施预约下单操作的过程中，可根据制作完成时间信息与该任一行程途经地点的途经时间信息之间在时间顺序上的关系，执行不同的操作。具体而言，在预估得到的制作完成时间信息早于该任一行程途经地点的途经时间信息的情况下，指示预约订单服务端实施针对第一预约商品的预约下单操作。而在预估得到的制作完成时间信息晚于该任一行程途经地点的途经时间信息的情况下(说明用户到达之后可能需要等待第一预约商品制作完成，那么需要用户确认是否等待)，若接收到用户客户端发送的针对第一预估结果的确认请求，则指示预约订单服务端实施针对第一预约商品的预约下单操作。

对于目标实体门店中与到达行程终点相匹配的实体门店提供的商品(以下简称为第二预约商品)，用户可通过用户客户端实施针对第二预约商品的预约下单。具体而言，打车服务端可接收用户客户端发送的针对第二预约商品的预约下单请求，然后预估第二预约商品的制作完成时间信息，并将预估得到的制作完成时间信息和到达时间信息作为第二预估结果返回至用户客户端以由用户进行确认。同时，打车服务端可指示预约订单服务端实施针对第二预约商品的预约下单操作。

其中，在指示预约订单服务端实施预约下单操作的过程中，可根据制作完成时间信息与到达时间信息之间在时间顺序上的关系，执行不同的操作。具体而言，在预估得到的制作完成时间信息早于到达时间信息的情况下，指示预约订单服务端实施针对第二预约商品的预约下单操作。而在预估得到的制作完成时间信息晚于到达时间信息的情况下(说明用户到达之后可能需要等待第二预约商品制作完成，那么需要用户确认是否等待)，若接收到用户客户端发送的针对第二预估结果的确认请求，则指示预约订单服务端实施针对第二预约商品的预约下单操作。

若用户确认针对目标实体门店进行预约下单，则说明用户决定前往目标实体门店的门店位置。那么，可结合目标实体门店的门店位置来重新规划打车行程路径。具体而言，打车服务端可响应于用户客户端发送的针对目标实体门店的预约下单请求，实施相应的预约下单操作。然后，根据目标实体门店的门店位置重新规划打车行程路径。其中，重新规划后的打车行程路径的到达行程终点为目标实体门店的门店位置；重新规划后的打车行程路径的行程途经地点相比于重新规划前的行程途经地点更靠近于目标实体门店的门店位置，从而便于用户前往目标实体门店，提高用户便捷性。例如，相比于重新规划前，重新规划后的打车行程路径更利用于前往目标实体门店。比如，沿途路径为目标实体门店的外延街边，或者沿途路径的交通状况更为畅通等。

可结合实体门店的虚拟权益进行信息处理。具体而言，打车服务端可获取目标实体门店的虚拟权益，以添加至目标实体门店对应的兴趣点信息中以供用户领取虚拟权益进行下单消费。用户客户端在接收到兴趣点信息后，可在页面上通过触发控件向用户展示兴趣点信息，那么用户可通过触发(比如通过点击、触摸操作)该信息的内容来发起相应的请求。比如，用户可实施针对虚拟权益的领取触发操作，那么用户客户端在检测到该领取触发操作后，可向打车服务端发送虚拟权益领取请求，使得打车服务端响应于虚拟权益领取请求，向用户客户端对应的用户账号发放虚拟权益领取请求指示的虚拟权益。其中，用户账号关联的虚拟权益用于在用户客户端发起针对目标实体门店所提供的预约下单服务的预约下单请求时，作为生成与用户账号对应的预约订单的依据(比如，可根据虚拟权益在确定预约订单的支付金额)。需要说明的是，上述发放虚拟权益的操作，除由打车服务端来执行以外，还可由其他网络平台的服务端来执行，并向打车服务端返回执行结果。比如，由支付平台或者电商平台的服务端来执行，或者向打车服务端提供发放虚拟权益的接口。

针对上述发放虚拟权益的场景，本说明书还提供发放虚拟权益的风控策略。例如，限制向同一用户发放的虚拟权益的数量。具体而言，可确定与用户客户端的用户账号关联的虚拟权益的权益数量，从而在权益数量达到预设权益数量阈值的情况下，禁止执行向该用户账号发放虚拟权益的操作。以优惠券为例，可限制同一用户可领取优惠券的数量，从而防止黄牛刷单；其中，可结合手机号、登录打车平台的账号、用户客户端的设备号、支付账号等来判断是否为同一用户。例如，将用户领取的虚拟权益与上述信息均建立绑定关系，那么只要领取虚拟权益的请求方的上述任一信息与已领取虚拟权益存在绑定关系，则判定该请求方已领取过虚拟权益，即当前请求领取的虚拟权益需计入该请求方已领取虚拟权益的数量中。

除此之外，还可在打车高峰时间段内限制请求领取虚拟权益或者发放虚拟权益的频率和/或数量，从而限制与虚拟权益关联的流量。比如，打车服务端可确定打车高峰时间段(比如，上下班高峰期、天气恶劣的时间段等，可预先配置或者根据打车订单的数量来实时判断)，并在打车高峰时间段内降低向任一用户账号发放虚拟权益的频率和/或数量。由于在打车高峰时间段内打车服务端的压力较大，通过上述限制流量的方式，可减少对打车服务端处理资源的占用，缓解打车服务端的压力，保证打车业务顺利进行。

基于打车服务端向用户客户端推送了兴趣点信息，用户可通过触发该信息来实施针对目标实体门店提供的预约下单服务的预约下单操作。具体而言，用户客户端可通过触发控件来展示兴趣点信息，该触发控件可被触发以实施预约下单操作，因此用户客户端可根据检测到的预约下单操作生成针对目标实体门店所提供的预约下单服务的预约下单请求，并将其发送至打车服务端；其中，预约下单请求包含预约下单操作指示的预约下单信息。那么，打车服务端在接收到用户客户端发送的预约下单请求的情况下，读取预约下单请求中包含的预约下单信息，并向预约订单服务端发送预约下单信息，以由预约订单服务端根据预约下单信息生成预约订单。然后，打车服务端可获取预约订单服务端返回的针对预约订单的预约下单结果，并将预约下单结果转发至用户客户端。

其中，打车服务端在向预约订单服务端发送预约下单信息时，可关联发送用户的打车订单(与用户的打车行程路径相对应)的第一订单标识，比如将预约下单信息和第一订单标识添加至同一预约下单请求中。那么，预约订单服务端在生成预约订单后，可将第一订单标识与预约订单的第二订单标识建立映射关系，以供后续用户查询预约订单的预约订单信息。其中，预约订单信息包括订单金额、预约服务名称、订单进展情况等等。

具体而言，用户可通过用户客户端发起针对预约订单的订单查询请求，该订单查询请求中包含打车订单的第一订单标识；比如，打车服务端可在生成打车订单后，在向用户客户端返回的打车订单信息中添加第一订单标识。那么，打车服务端在接收到用户客户端发送的订单查询请求的情况下，向预约订单服务端发送第一订单标识，以由预约订单服务端根据第一订单标识和映射关系确定出第二订单标识，并根据第二订单标识获取预约订单的预约订单信息。然后，打车服务端获取预约订单服务端返回的预约订单信息，并将预约订单信息转发至用户客户端以由用户客户端进行展示。其中，用户客户端可在打车引导页面上关联展示预约订单信息和打车订单的打车订单信息，从而简化用户查看预约订单信息和打车订单信息的操作。

在完成预约订单的下单操作之后，打车服务端可向预约订单服务端提供预计到达时刻，以由预约订单服务端根据预计到达时刻来安排预约订单的实施进度，确保用户在到店时预约订单已经完成，从而避免用户到店后等待预约订单完成。具体而言，打车服务端可向预约订单服务端发送用户的预计到达时刻，以由预约订单服务端根据预计到达时刻确定预约订单的完成时刻，完成时刻不晚于预计到达时刻。通过上述确定预约订单完成时刻的方式，可为相应实体门店的工作人员提供安排预约订单实施进度的参考。以预约下单咖啡为例，假定用户的预计到达时刻为8:00，那么需保证咖啡订单的完成时刻不晚于8:00，即保证用户预约点单的咖啡在到达8:00时已经制作完成。比如制作该咖啡需要花费6分钟，那么工作人员则可在7:54或者7:54之前开始制作该咖啡。当然，完成时刻与预计到达时刻之间的时长间隔可根据实际情况灵活设定，本说明书并不对此进行限制。

用户在打车过程中可能会因行程安排发生变化而修改到达行程终点，那么打车服务端可根据修改后行程终点附近的门店位置来向用户推荐最终的到达行程终点，从而可在用户需要修改到达行程终点的情况下，在保证不影响用户的打车体验的同时，仍然可向用户提供实体门店的在线预约下单服务。

具体而言，用户可在用户客户端上输入修改后到达行程终点，从而通过用户客户端向打车服务端发送相应的修改请求，该修改请求包含修改后到达行程终点。打车服务端响应于用户客户端发送的修改请求，根据修改后到达行程终点重新确定打车行程路径和相应的时间信息，以重新确定出目标实体门店，并向用户客户端推送重新确定出的目标实体门店对应的兴趣点信息，以由用户客户端将目标实体门店的门店位置作为到达行程终点的修改建议进行展示。其中，确定目标实体门店的具体实施过程与上述过程类似，在此不再赘述。

例如，用户客户端可展示包含如下选项的触发控件“建议将终点修改为目标兴趣点的位置”，该触发控件用于触发用户客户端与打车服务端进行交互以完成将到达行程终点修改为目标兴趣点的位置的操作。当然，该触发控件上还可包括“不采纳上述修改建议”的选项供用户选择，即保持将到达行程终点修改为用户输入的修改后行程终点。

对应于上述打车服务端侧的实施例，本说明书还提供了用户客户端侧的实施例，在打车服务端侧实施例中所涉及的描述同样可以适用于用户客户端侧的实施例，下文中不再对此进行赘述。

请参见图3，图3是一示例性实施例提供的另一种信息处理方法的流程图。如图3所示，该推送方法应用于用户客户端，可以包括以下步骤：

步骤302，接收打车服务端推送的兴趣点集合的兴趣点信息，所述兴趣点集合中任一兴趣点对应一实体门店，所述实体门店的门店位置与用户当前的打车行程路径相匹配。

步骤304，展示所述兴趣点集合的兴趣点信息。

如前所述，所述兴趣点信息至少包括相应的目标实体门店的门店名称和预设触发控件的信息，那么用户客户端可在同一页面上展示所述兴趣点信息与打车引导页面。

如前所述，用户客户端可响应于用户针对所述目标实体门店的预约下单触发操作，通过所述触发控件将所述打车引导页面跳转至预约下单操作页面，所述预约下单操作页面为所述目标实体门店的用户客户端页面。

如前所述，所述兴趣点信息指示的实体门店由所述打车服务端从兴趣点集合对应的实体门店中过滤出营业状态信息与用户当前的打车行程路径对应的时间信息相匹配的实体门店而得到，所述时间信息包括到达行程终点的到达时间信息和至少一个行程途经地点的途经时间信息。

如前所述，用户客户端可接收所述打车服务端发送的所述兴趣点信息指示的目标实体门店的虚拟权益；在检测到用户针对所述虚拟权益的领取触发操作的情况下，可向所述打车服务端发送虚拟权益领取请求，以由所述打车服务端向所述用户客户端对应的用户账号发放所述虚拟权益领取请求指示的虚拟权益；

其中，所述用户账号关联的虚拟权益用于作为生成与所述用户账号对应的预约订单的依据。

如前所述，用户客户端可向所述打车服务端发送针对所述兴趣点信息指示的目标实体门店的预约下单请求，以由所述打车服务端向预约订单服务端发送所述预约下单请求包含的预约下单信息，所述预约订单服务端用于根据所述预约下单信息生成预约订单；然后，接收所述打车服务端返回的从所述预约订单服务端处获取到的针对所述预约订单的预约下单结果。

如前所述，在生成所述预约订单后，所述打车行程路径对应的打车订单的第一订单标识与所述预约订单的第二订单标识之间被建立有映射关系；用户客户端可向所述打车服务端发送针对所述预约订单的订单查询请求，以由所述打车服务端向所述预约订单服务端发送所述第一订单标识，所述预约订单服务端用于根据所述第一订单标识和所述映射关系确定出所述第二订单标识，并根据所述第二订单标识获取所述预约订单的预约订单信息；接收所述打车服务端返回的从所述预约订单服务端处获取到的预约订单信息。

如前所述，用户客户端可根据检测到的用户针对所述打车行程路径的修改操作，生成相应的修改请求，所述修改请求包含所述修改操作指示的修改后行程终点；向所述打车服务端发送包含修改后到达行程终点的修改请求，以由所述打车服务端根据所述修改后到达行程终点重新确定打车行程路径，以重新确定出兴趣点集合；然后，接收所述打车服务端推送的重新确定出的兴趣点集合的兴趣点信息，并将接收到的兴趣点信息指示的目标实体门店的门店位置作为到达行程终点的修改建议进行展示。

由以上实施例可见，针对需要用户到店的实体门店，本说明书的技术方案可在打车过程中为用户提供该类实体门店的在线预约下单服务。具体而言，根据用户的打车行程路径和对应的时间信息进行匹配，查询可为用户提供预约下单服务的实体门店，并向用户推送查询到的实体门店对应的兴趣点信息以供用户选择。

一方面，查询到的实体门店的地理位置与营业状态均与用户的整个打车过程相匹配，那么用户针对这些实体门店进行预约下单并到店，与用户打车的行程安排不会冲突，即不影响用户的打车体验；并且，方便用户到店，用户到店之前已完成下单操作，减少用户的等待时间。另一方面，向用户客户端推送查询到的兴趣点信息以供用户触发相应的预约下单操作，使得用户无需通过搜索操作来查询兴趣点，可简化用户预约下单的操作，从而提高用户预约下单的效率。

为了便于理解，下面结合附图4-7对本说明书的信息处理方案进行详细说明。

请参见图4，图4是一示例性实施例提供的一种信息处理方法的交互图。如图4所示，该交互过程可以包括以下步骤：

步骤402，用户客户端获取用户当前的打车行程。

图4所示实施例以在打车过程中为用户提供位于到达行程终点附近实体门店的在线预约下单服务为例进行说明，针对行程途经地点进行推送的原理与此类似。在本实施例的应用场景下，用户当前的打车行程包括出发行程起点和到达行程终点。

步骤404，用户客户端向打车服务端发送打车行程。

步骤406，打车服务端根据打车行程生成打车订单。

步骤408，打车服务端确定时间信息。

打车服务端可根据出发行程起点和到达行程终点规划打车行程路径，并确定相应的时间信息，从而确定预计到达时刻以作为到达时间信息。其中，打车服务端规划打车行程路径并确定相应时间信息的过程可参考相关技术中的记载，本说明书并不对此进行限制。

需要说明的是，本说明书的打车场景包括实时打车和预约打车，而上述两种场景下计算预计到达时刻的方式也不同。在实时打车的场景下，整个打车过程时长＝接单时长+预计接驾时长+行驶时长，那么可根据当前时刻和打车过程时长确定预计到达时刻。当然，若在司机接单后执行确定预计到达时刻的操作，则不存在接单时长；类似的，若在用户上车后执行确定预计到达时刻的操作，则不存在预计接驾时长。在预约打车的场景下，整个打车过程时长即为行驶时长，那么可根据打车出发时刻和行驶时长确定预计到达时刻。

步骤410，打车服务端查询目标实体门店和相应的虚拟权益。

在本实施例中，打车服务端可接入电商平台，从而在注册至电商平台的实体门店中查询实体门店以得到兴趣点集合，进而从兴趣点集合对应的实体门店中过滤出目标实体门店。比如，电商平台可提供实体门店查询接口以供打车服务端查询实体门店的实体门店位置和营业状态信息，查询门店位置与打车行程路径(到达行程终点或行程途经地点)相匹配的实体门店，并将查询得到的实体门店对应的兴趣点添加至兴趣点集合。然后，从兴趣点集合中过滤出营业状态信息与时间信息(途经时间信息或到达时间信息)相匹配的目标实体门店，进而将过滤得到的目标实体门店对应的兴趣点信息推送至用户客户端。当然，获取兴趣点集合和过滤得到目标实体门店的操作可由电商平台来执行，然后由电商平台将目标实体门店的兴趣点信息发送至打车服务端。为了便于说明，以下以实体店为指定品牌的咖啡店为例进行说明。

营业状态信息可以包括实体门店是否开业、营业时间段、预约下单服务是否可用等等。相应的，营业状态信息与时间信息相匹配，可理解为：实体门店开业，预计到达时刻在营业时间段内，以及预约下单服务可用。当然，还可根据实体门店类型来进一步划分营业状态信息，进而灵活设定判断营业状态信息是否与行程时间信息相匹配的具体实现方式。以预点餐服务为例，需判断当前时刻是否在实体门店的可点餐时间段内。比如，可点餐时间段＝营业时间段-点餐提前量X分钟；假设营业时间为8:00-20:00，点餐提前量为30分钟，则可点餐时间段为7:30-19:30。还可判断预计到达时刻是否在可取餐时间段内。比如，可取餐时间段＝最早营业时间-最晚营业时间-延误时长Y分钟；假设营业时间为8:00-20:00，Y＝30，则可取餐时间段为8:00-19:30。通过设置延误时长，可降低用户因行程延误导致无法取餐的风险。当然，上述X、Y等参数的具体取值可根据实际情况灵活设定，本说明书并不对此进行限制。

以咖啡店为例进行说明，如图5所示，用户客户端可在页面A的地图上展示兴趣点信息，页面A上同时还包含打车引导页面50。比如，在地图上标注兴趣点51的位置，同时采用触发控件52在该位置处标注兴趣点对应咖啡店的信息，该信息可以包括咖啡店的品牌logo(图中未示出)、描述文案(嗨，来杯咖啡吗？)、用于跳转至咖啡店小程序的url(uniformresource locator，统一资源定位器)等。当用户客户端检测到针对触发控件52的触发操作时，用户客户端可根据触发控件52包含的url跳转至咖啡店的小程序(用于预约点单)。当然，还可额外配置其他触发控件53来提示用户可在该咖啡店预约点单，该其他触发控件53同样可用于跳转至上述小程序。

需要说明的是，该小程序的url也可配置于打车服务端侧，由打车服务端根据url读取小程序的数据并转发至用户客户端以由用户客户端进行渲染展示小程序的页面。

步骤412，打车服务端向用户客户端返回打车订单信息和兴趣点信息。

步骤414，用户客户端展示打车订单信息和兴趣点信息。

打车订单信息可包含司机信息、车辆信息、打车订单id等。

步骤416，用户客户端生成虚拟权益领取请求。

步骤418，用户客户端向打车服务端发送虚拟权益领取请求。

步骤420，打车服务端发放虚拟权益。

在本实施例中，还可结合实体门店的虚拟权益进行信息处理。比如，打车服务端可获取咖啡店的优惠券以添加至兴趣点信息中以供用户领取。如图6A所示，用户客户端可在打车引导页面50的地图上标注兴趣点51的位置，同时采用触发控件52在该位置处标注兴趣点对应咖啡店的优惠券信息，该优惠券信息可以包括咖啡店的品牌logo(图中未示出)、描述文案(嗨，今日点单立减5元)、用于跳转至咖啡店小程序的url等。

进一步的，如图6B所示，用户可通过触发触发控件52来领取优惠券，当用户客户端检测到针对触发控件52的触发操作时，用户客户端可通过触发控件52展示优惠券的详细内容，用户可通过点击按钮“一键领取”来实现对优惠券的领取。如图6C所示，在用户完成对优惠券的领取后，触发控件52可显示文案“已领取优惠券，请尽快使用”，从而提示用户优惠券的领取情况。

通过上述过程，用户可完成优惠券的领取，进而进一步利用优惠券来预约下单；当然，用户即便领取了优惠券，后续也可不预约下单。下面结合步骤422-438对预约订单的过程进行详细说明。

步骤422，用户客户端生成预约下单请求。

承接于图6C，用户可通过触发触发控件52来使得用户客户端跳转至相应咖啡店的小程序。其中，可由打车服务端来与预约订单服务端进行交互以获取小程序的数据，然后转发至用户客户端进行渲染展示。

步骤424，用户客户端向打车服务端发送预约下单请求。

用户客户端生成的预约下单请求中可包含预约下单信息(比如，用户选取的咖啡信息、咖啡数量、口味等)和打车订单id。

步骤426，打车服务端读取预约下单请求中的预约下单信息。

步骤428，打车服务端向预约订单服务端发送预约下单信息。

步骤430，预约订单服务端根据预约下单信息生成预约订单。

步骤432，预约订单服务端建立打车订单id和预约订单id的映射关系。

步骤434，预约订单服务端向打车服务端返回预约下单结果。

步骤436，打车服务端向用户客户端返回预约下单结果。

步骤438，用户客户端展示预约下单结果。

需要说明的是，用户可通过用户客户端来完成预约订单的支付过程，在此不再赘述。

用户在通过小程序完成预约点单后，后续还存在查看预约订单的订单实施情况的需求。基于上述建立的映射关系将打车订单和预约订单绑定，后续则可通过打车订单来查看相关联预约订单的预约订单信息。下面结合步骤440-456对查看预约订单信息的过程进行详细说明。

步骤440，用户客户端生成订单查询请求。

需要说明的是，用户客户端可按照预设周期自动查询预约订单信息，也可由用户主动触发查询预约订单信息的操作。

步骤442，用户客户端向打车服务端发送订单查询请求。

步骤444，打车服务端读取订单查询请求中包含的打车订单id。

步骤446，打车服务端向预约订单服务端发送打车订单id。

步骤448，预约订单服务端根据映射关系查询预约订单id。

步骤450，预约订单服务端根据预约订单id查询预约订单信息。

步骤452，预约订单服务端向打车服务端返回预约订单信息。

步骤454，打车服务端向用户客户端返回预约订单信息。

步骤456，用户客户端展示预约订单信息。

如图7所示，用户客户端展可通过触发控件52展示预约订单信息，例如，假定查询到的预约订单信息为“制作完成，待取餐”的订单状态码，则触发控件52可展示该订单状态码对应的描述文案“制作完成，待取餐”。当然，还可通过其他触发控件53协助展示预约订单信息。

与上述方法实施例相对应，本说明书还提供了一种信息处理装置的实施例。

图8是一示例性实施例提供的一种电子设备的结构示意图。请参考图8，在硬件层面，该设备包括处理器802、内部总线804、网络接口806、内存808以及非易失性存储器810，当然还可能包括其他业务所需要的硬件。处理器802从非易失性存储器810中读取对应的计算机程序到内存808中然后运行，在逻辑层面上形成信息处理装置。当然，除了软件实现方式之外，本说明书一个或多个实施例并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图9，在一软件实施方式中，该信息处理装置应用于打车服务端，可以包括：

信息获取单元91，获取用户当前的打车行程路径；

兴趣点获取单元92，获取兴趣点集合，所述兴趣点集合中任一兴趣点对应一实体门店，所述实体门店的门店位置与所述打车行程路径相匹配；

推送单元93，向所述用户的用户客户端推送所述兴趣点集合的兴趣点信息。

请参考图10，在另一软件实施方式中，该信息处理装置应用于用户的用户客户端，可以包括：

接收单元1001，接收打车服务端推送的兴趣点集合的兴趣点信息，所述兴趣点集合中任一兴趣点对应一实体门店，所述实体门店的门店位置与用户当前的打车行程路径相匹配；

展示单元1002，展示所述兴趣点集合的兴趣点信息。

上述信息处理装置的实施例的具体实现过程与上述信息处理方法的实施例类似，在此不再赘述。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

在一个典型的配置中，计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。

Claims (13)

1.一种信息处理方法，其特征在于，应用于打车服务端，所述方法包括：

获取用户当前的打车行程路径；

获取兴趣点集合，所述兴趣点集合中任一兴趣点对应一实体门店，所述实体门店的门店位置与所述打车行程路径相匹配；

向所述用户的用户客户端推送所述兴趣点集合的兴趣点信息。

2.根据权利要求1所述的方法，其特征在于，所述兴趣点信息至少包括相应的目标实体门店的门店名称和预设触发控件的信息；其中，所述兴趣点信息与打车引导页面位于所述用户客户端的同一页面上。

3.根据权利要求2所述的方法，其特征在于，所述预设触发控件用于响应用户针对所述目标实体门店的预约下单触发操作，将所述打车引导页面跳转至预约下单操作页面，所述预约下单操作页面为所述目标实体门店的用户客户端页面。

4.根据权利要求1所述的方法，其特征在于，

还包括：根据所述打车行程路径确定对应的时间信息，所述时间信息包括到达行程终点的到达时间信息和至少一个行程途经地点的途经时间信息；获取所述兴趣点集合中兴趣点对应的实体门店的营业状态信息，并过滤出营业状态信息与所述途经时间信息或所述到达时间信息相匹配的实体门店；

所述向所述用户的用户客户端推送所述兴趣点集合的兴趣点信息，包括：向所述用户客户端推送过滤出的实体门店对应的兴趣点信息。

5.根据权利要求4所述的方法，其特征在于，还包括：

接收所述用户客户端发送的针对第一预约商品的预约下单请求，所述第一预约商品为与任一行程途经地点相匹配的实体门店提供的商品；预估所述第一预约商品的制作完成时间信息，并将预估得到的制作完成时间信息和对应于所述任一行程途经地点的途经时间信息作为第一预估结果返回至所述用户客户端；指示预约订单服务端实施针对所述第一预约商品的预约下单操作；

和/或，接收所述用户客户端发送的针对第二预约商品的预约下单请求，所述第二预约商品为与所述到达行程终点相匹配的实体门店提供的商品；预估所述第二预约商品的制作完成时间信息，并将预估得到的制作完成时间信息和所述到达时间信息作为第二预估结果返回至所述用户客户端；指示预约订单服务端实施针对所述第二预约商品的预约下单操作。

6.根据权利要求5所述的方法，其特征在于，

所述指示预约订单服务端实施针对所述第一预约商品的预约下单操作，包括：在预估得到的制作完成时间信息早于所述任一行程途经地点的途经时间信息的情况下，指示预约订单服务端实施针对所述第一预约商品的预约下单操作；在预估得到的制作完成时间信息晚于所述任一行程途经地点的途经时间信息的情况下，若接收到所述用户客户端发送的针对所述第一预估结果的确认请求，则指示预约订单服务端实施针对所述第一预约商品的预约下单操作；

所述指示预约订单服务端实施针对所述第二预约商品的预约下单操作，包括：在预估得到的制作完成时间信息早于所述到达时间信息的情况下，指示预约订单服务端实施针对所述第二预约商品的预约下单操作；在预估得到的制作完成时间信息晚于所述到达时间信息的情况下，若接收到所述用户客户端发送的针对所述第二预估结果的确认请求，则指示预约订单服务端实施针对所述第二预约商品的预约下单操作。

7.根据权利要求1所述的方法，其特征在于，还包括：

响应于所述用户客户端发送的针对所述兴趣点信息指示的目标实体门店的预约下单请求，实施相应的预约下单操作；

根据所述目标实体门店的门店位置重新规划打车行程路径；其中，重新规划后的打车行程路径的到达行程终点为所述目标实体门店的门店位置，重新规划后的打车行程路径的行程途经地点相比于重新规划前的行程途经地点更靠近于所述目标实体门店的门店位置。

8.根据权利要求1所述的方法，其特征在于，还包括：

获取所述兴趣点信息指示的目标实体门店的虚拟权益，并向所述用户客户端发送所述虚拟权益；

响应于所述用户客户端发送的虚拟权益领取请求，向所述用户客户端对应的用户账号发放所述虚拟权益领取请求指示的虚拟权益；其中，所述用户账号关联的虚拟权益用于作为生成与所述用户账号对应的预约订单的依据。

9.根据权利要求8所述的方法，其特征在于，还包括：

确定打车高峰时间段，并在所述打车高峰时间段内降低向任一用户账号发放虚拟权益的频率和/或数量。

10.根据权利要求1所述的方法，其特征在于，还包括：

接收所述用户客户端发送的针对所述兴趣点信息指示的目标实体门店的预约下单请求，所述预约下单请求包含预约下单信息；

向预约订单服务端发送所述预约下单信息，以由所述预约订单服务端根据所述预约下单信息生成预约订单；

获取所述预约订单服务端返回的针对所述预约订单的预约下单结果，并将所述预约下单结果转发至所述用户客户端。

11.根据权利要求10所述的方法，其特征在于，在生成所述预约订单后，所述打车行程路径对应的打车订单的第一订单标识与所述预约订单的第二订单标识之间被建立有映射关系；所述方法还包括：

在接收到所述用户客户端发送的针对所述预约订单的订单查询请求的情况下，向所述预约订单服务端发送所述第一订单标识，以由所述预约订单服务端根据所述第一订单标识和所述映射关系确定出所述第二订单标识，并根据所述第二订单标识获取所述预约订单的预约订单信息；

获取所述预约订单服务端返回的预约订单信息，并将所述预约订单信息转发至所述用户客户端。

12.根据权利要求1所述的方法，其特征在于，还包括：

接收所述用户客户端发送的包含修改后到达行程终点的修改请求；

根据所述修改后到达行程终点重新确定打车行程路径，以重新确定出兴趣点集合；

向所述用户客户端推送重新确定出的兴趣点集合的兴趣点信息，以由所述用户客户端将接收到的兴趣点信息指示的目标实体门店的门店位置作为到达行程终点的修改建议进行展示。

13.一种信息处理装置，其特征在于，应用于打车服务端，所述装置包括：

信息获取单元，获取用户当前的打车行程路径；

兴趣点获取单元，获取兴趣点集合，所述兴趣点集合中任一兴趣点对应一实体门店，所述实体门店的门店位置与所述打车行程路径相匹配；

推送单元，向所述用户的用户客户端推送所述兴趣点集合的兴趣点信息。

Images