一种服务预订方法、装置、系统、介质和电子设备与流程

1.本说明书一个或多个实施例涉及基于位置的信息服务技术领域，尤其涉及一种服务预订方法、装置、系统、介质和电子设备。


背景技术：

2.相关业务场景中，用户在使用服务提供端提供的服务之前，可以预订使用服务的时间。例如，去餐厅就餐之前，可以提前预订餐厅的座位；又例如，在去咖啡店取咖啡之前，可以提前预订自提时间。这种提前预订使用服务的时间的方式，极大的方便了用户。
3.但是，现实中存在用户无法在预订时间到达服务地点的问题。以餐厅订座为例：用户可以提前预订餐厅的座位，比如，可以将座位预订在中午12点，但是，可能出现用户在驾车前往餐厅的过程中遇到了道路拥堵，导致到店时间延迟到12点半甚至更晚。相关技术中，如果用户遇到此类问题，一种情况是，用户不做任何操作，实际到店时间晚于预订时间，被取消订座或者被延期；另一种情况是，用户主动电话告知餐厅自己的到达情况，但餐厅并无法核实用户的实际情况，导致不同意给用户延期订座时间。


技术实现要素：

4.有鉴于此，本说明书一个或多个实施例提供一种服务预订方法、装置、系统、介质和电子设备。
5.为实现上述目的，本说明书一个或多个实施例提供技术方案如下：
6.根据本说明书一个或多个实施例的第一方面，提出了一种服务预订方法，包括：
7.响应于接收到用户对目标兴趣点的目标操作，展示与所述目标兴趣点对应的服务选项；
8.根据用户对所述服务选项的选择操作，确定对所述目标兴趣点的预订服务请求；
9.显示所述预订服务请求对应的初始服务时间；
10.响应于用户触发导航至所述目标兴趣点的操作，开始路线导航；
11.在导航过程中，若预计到达时间与所述初始服务时间之间发生偏差，则接收并展示预订服务变更信息，其中，所述预订服务变更信息包括所述初始服务时间更新后的目标服务时间。
12.根据本说明书一个或多个实施例的第二方面，提出了一种服务预订方法，所述方法由目标兴趣点的服务提供端执行；所述方法包括：
13.接收对所述目标兴趣点的目标服务请求，其中，所述目标服务请求包括初始服务时间；
14.响应于对所述目标服务请求的确认操作，发送预订成功的确认信息；
15.接收对所述目标兴趣点的预订服务变更请求，其中，所述预订服务变更请求用于将所述初始服务时间更新为目标服务时间。
16.根据本说明书一个或多个实施例的第三方面，提供了一种服务预订方法，包括：
17.响应于接收到服务请求客户端发送的对目标兴趣点的预订服务请求，确定所述预订服务请求对应的初始服务时间；
18.在导航过程中，持续计算到达所述目标兴趣点的预计到达时间；
19.若检测到所述预计到达时间与所述初始服务时间之间发生偏差，则向所述目标兴趣点的服务提供端发送预订服务变更请求，所述预订服务变更请求用于将所述初始服务时间更新为目标服务时间。
20.根据本说明书一个或多个实施例的第四方面，提出了一种服务预订方法，包括：
21.服务请求客户端在接收到用户对目标兴趣点的目标操作时，展示与所述目标兴趣点对应的服务选项；
22.所述服务请求客户端接收用户对所述服务选项的选择操作，向服务器发送对目标兴趣点的预订服务请求；
23.所述服务器向所述目标兴趣点的服务提供端发送目标服务请求，所述目标服务请求包括所述预订服务请求对应的初始服务时间；
24.所述服务提供端向所述服务器反馈预订成功的确认信息；
25.所述服务器根据所述确认信息，指示所述服务请求客户端展示预订服务成功信息；
26.所述服务器若检测到到达目标兴趣点的预计到达时间与所述初始服务时间之间发生偏差，则向所述服务提供端发送预订服务变更请求，所述预订服务变更请求用于将所述初始服务时间更新为目标服务时间。
27.根据本说明书一个或多个实施例的第五方面，提供了一种服务预订装置，该装置包括：
28.选项展示模块，用于响应于接收到用户对目标兴趣点的目标操作，展示与所述目标兴趣点对应的服务选项；
29.请求确定模块，用于根据用户对所述服务选项的选择操作，确定对所述目标兴趣点的预订服务请求；
30.信息显示模块，用于显示所述预订服务请求对应的初始服务时间；并且响应于用户触发导航至所述目标兴趣点的操作，开始路线导航；
31.更新处理模块，用于在导航过程中，若预计到达时间与所述初始服务时间之间发生偏差，则接收并展示预订服务变更信息，其中，所述预订服务变更信息包括所述初始服务时间更新后的目标服务时间。
32.根据本说明书一个或多个实施例的第六方面，提供了一种服务预订装置，该装置包括：
33.请求接收模块，用于接收对目标兴趣点的目标服务请求，其中，所述目标服务请求包括初始服务时间；
34.请求确认模块，用于响应于对所述目标服务请求的确认操作，发送预订成功的确认信息；
35.变更处理模块，用于接收对所述目标兴趣点的预订服务变更请求，其中，所述预订服务变更请求用于将所述初始服务时间更新为目标服务时间。
36.根据本说明书一个或多个实施例的第七方面，提供了一种服务预订装置，该装置
包括：
37.时间确定模块，用于响应于接收到服务请求客户端发送的对目标兴趣点的预订服务请求，确定所述预订服务请求对应的初始服务时间；
38.时间监测模块，用于在导航过程中，持续计算到达所述目标兴趣点的预计到达时间；
39.变更处理模块，用于若检测到所述预计到达时间与所述初始服务时间之间发生偏差，则向所述目标兴趣点的服务提供端发送预订服务变更请求，所述预订服务变更请求用于将所述初始服务时间更新为目标服务时间。
40.根据本说明书一个或多个实施例的第八方面，提供了一种服务预订系统，所述系统包括：服务请求客户端、服务器和服务提供端；
41.所述服务请求客户端，用于接收用户对目标兴趣点的目标操作，展示与所述目标兴趣点对应的服务选项；并接收用户对所述服务选项的选择操作，向服务器发送对所述目标兴趣点的预订服务请求；
42.所述服务器，用于向所述目标兴趣点的服务提供端发送目标服务请求，所述目标服务请求包括所述预订服务请求对应的初始服务时间；以及，根据所述服务提供端反馈的确认信息，指示所述服务请求客户端展示预订服务成功信息；还用于若检测到到达目标兴趣点的预计到达时间与所述初始服务时间之间发生偏差，则向所述服务提供端发送预订服务变更请求，所述预订服务变更请求用于将所述初始服务时间更新为目标服务时间；
43.所述服务提供端，用于在接收到所述服务器发送的目标服务请求时，向所述服务器反馈预订成功的确认信息。
44.根据本说明书一个或多个实施例的第九方面，提供了一种电子设备，包括：
45.处理器；
46.用于存储处理器可执行指令的存储器；
47.其中，所述处理器通过运行所述可执行指令以实现本说明书任一实施例的方法。
48.根据本说明书一个或多个实施例的第十方面，提供了一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现本说明书任一实施例的方法。
49.本说明书实施例的一种服务预订方法、装置、系统、介质和电子设备，通过根据导航过程中的预计到达时间调整服务时间，使得能够将服务时间适应预计到达时间的变化而更新，从而使得服务提供更加灵活；用户也不需要再自己通知服务提供端自己的到达情况，就可以实现服务时间的动态调整，不仅得到了便利，而且还能根据自己的预计到达时间随到随使用服务，也较为方便。
附图说明
50.为了更清楚地说明本公开一个或多个实施例或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开一个或多个实施例中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
51.图1是一示例性实施例提供的一种服务预订方法的流程图；
52.图2是一示例性实施例提供的路线规划界面示意图；
53.图3是一示例性实施例提供的服务选项显示示意图；
54.图4是一示例性实施例提供的协商状态的提示示意图；
55.图5是一示例性实施例提供的预订成功的示意图；
56.图6是一示例性实施例提供的导航终点的服务提示的示意图；
57.图7是一示例性实施例提供的一种服务预订方法的流程图；
58.图8是一示例性实施例提供的一种服务预订方法的流程图；
59.图9是一示例性实施例提供的一种服务预订方法的流程图；
60.图10是一示例性实施例提供的一种服务预订装置的结构示意图；
61.图11是一示例性实施例提供的一种服务预订装置的结构示意图；
62.图12是一示例性实施例提供的一种服务预订装置的结构示意图；
63.图13是一示例性实施例提供的一种服务预订系统的架构示意图。
具体实施方式
64.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。
65.需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。
66.poi(point of interest，兴趣点)可以是地图上的位置点，可以包括但不限于：景点、政府机构、办公大厦、商场、餐厅等位置点。在本说明书实施例中，用户感兴趣的兴趣点可以称为目标兴趣点。本说明书实施例提供了一种服务预订方法，通过该方法，用户可以预订所述目标兴趣点的服务时间，并且在用户到达目标兴趣点的预计到达时间发生变化时，也可以通过该方法基于预计到达时间实现对服务时间的自动更新。
67.图1是一示例性实施例提供的一种服务预订方法的流程图，其中，所述的服务可以是目标兴趣点或者其周边提供的服务，可以通过该方法预订服务时间。例如，用户可以是驾车或者乘车前往目标兴趣点使用服务，目标兴趣点可以位于该用户的导航过程的终点。比如，目标兴趣点可以是餐厅，用户可以是去餐厅就餐，通过本方法预订餐厅的留座时间。又比如，目标兴趣点可以是咖啡店，用户可以通过该方法预约去该咖啡店自提咖啡的自提时间。
68.如图1所示，该方法可以包括如下处理，该方法可以由包括服务请求客户端、服务器和服务提供端的服务预订系统实现。其中，需要说明的是，本说明书实施例不限制如下各个步骤之间的执行顺序，如下描述中的步骤序号不作为对步骤顺序的限制：
69.在步骤100中，服务请求客户端接收到用户对目标兴趣点的目标操作，展示与该目标兴趣点对应的服务选项。
70.本步骤中，所述的服务请求客户端，可以是发起服务时间预订的客户端。示例性的，假如用户要预订餐厅的留座时间，可以在去往餐厅的导航过程开始前，在手机地图应用中操作对该餐厅的留座时间的预订的相关处理，那么此时手机地图应用可以称为服务请求客户端。
71.例如，所述的目标操作，可以是选定操作，或者是路线规划操作。
72.比如，用户可以是在服务请求客户端选定了一个目标兴趣点，或者，用户在服务请求客户端进行从用户的起点位置到该目标兴趣点的路线规划操作。此时，服务请求客户端接收到上述目标操作后，就可以展示与该目标兴趣点对应的服务选项。
73.在一个示例中，服务请求客户端可以是在接收到目标操作时直接展示服务选项，也可以是通过其他的入口跳转到展示服务选项。比如，如果采用通过其他入口跳转的方式，服务请求客户端可以在接收到对目标兴趣点的目标操作时，先展示与目标兴趣点对应的服务预订入口，再在接收到用户对该服务预订入口的触发操作后，展示目标兴趣点对应的服务选项。
74.示例性的，以餐厅订座的场景为例，当服务请求客户端检测到用户选定了某个餐厅a时，可以先在服务请求客户端的客户端页面中展示该餐厅订座的服务预订入口，例如，该服务预订入口可以是“a餐厅订座”。用户可以点击该选项“a餐厅订座”，则服务请求客户端检测到对该服务预订入口的触发操作，继而，客户端页面可以跳转至该餐厅订座的详细的服务选项的页面。例如，该餐厅订座的服务选项的页面可以包括“就餐人数”、“座位类型”、“留座时间”等多种类型的服务选项供用户选择。
75.在步骤102中，服务请求客户端根据用户对服务选项的选择操作，确定对目标兴趣点的预订服务请求，并向服务器发送该预订服务请求。
76.本步骤中，用户可以对步骤100中展示的服务选项进行选择操作。例如，在餐厅订座的场景中，用户可以选择自己的就餐人数、想要预订的座位类型等服务选项，服务请求客户端据此确定预订服务请求，该请求中可以携带用户选择的服务选项的信息。例如，所述预订服务请求中可以携带上述用户选择好的就餐人数、预订座位类型等信息。
77.服务请求客户端可以将该预订服务请求发送至服务器，以使得服务器据此向服务提供端请求预订服务时间。所述的服务器可以是服务请求客户端对应的服务器。示例性的，假如服务请求客户端是地图应用，对应的服务器可以是地图服务器。
78.在一个示例中，服务请求客户端展示的服务选项中，可以包括智能预订选项，该智能预订选项用于指示根据到达目标兴趣点的预计到达时间自动调整初始服务时间。即如果用户选择了该智能预订选项，那么用户可以不做介入操作，本说明书实施例的服务预订系统就可以自动实现对初始服务时间的调整，而且是基于预计到达时间进行自动调整。其中，所述的初始服务时间可以是用户原本预订的服务时间。
79.比如，在上述餐厅订座的例子中，该餐厅订座的服务选项的页面中，其中的“留座时间”选项也可以包括多种类型，例如，11:30、12:00、12:30等固定时间供用户选择，并且还可以包括“智能订座(根据预计到达时间调整留座时间)”的选项，该选项就相当于上述的智能预订选项。如果用户选择了该智能预订选项，就表示希望启用根据预计到达时间动态调整餐厅留座时间的功能。对于服务请求客户端来说，如果用户选择了上述“智能订座”选项，那么服务请求客户端可以接收到用户对所述智能预订选项的选择操作，就可以在预订服务
请求中携带所述智能预订选项的标识信息，以使得服务器根据该智能预订选项的标识信息，执行根据预计到达时间调整初始服务时间的处理。
80.但可以理解的是，即使初始时用户选择了类似11:30这种固定时间作为留座时间，后续也可以启用根据预计到达时间动态调整餐厅留座时间。比如，服务请求客户端可以在导航过程中提示用户“您是否要启用智能订座的功能？”，这样用户就可以启用该功能，这种情况下，上述的启用智能订座功能的提示信息就相当于上述的智能预订选项。也即是说，本实施例不限制服务选项的展示时机和展示方式，在用户到达目标兴趣点之前都可以。又比如，还可以是，初始时用户选择了类似11:30这种固定时间作为留座时间，并同时勾选了客户端页面中展示的一个智能预订选项“允许动态调整”，那么后续也可以自动根据预计到达时间调整初始服务时间。再比如，还可以是，初始时用户选择了类似11:30这种固定时间作为留座时间，则默认可以“允许动态调整”，那么后续可以自动根据预计到达时间调整初始服务时间。
81.此外，在另一个示例中，服务请求客户端是否要展示上述的服务选项，可以根据预设的条件来判断。如下示例两种条件，但实际实施中不局限于此：
82.1)到达目标兴趣点的预计到达时间对应的时间范围内，存在可用的服务；所述时间范围是包括所述预计到达时间的一段时间。
83.该条件的意思是，例如，目标兴趣点是用户的导航过程的终点，可以判断在包括预计到达时间在内的一段时间内，服务提供端是否存在可用的服务。该步骤可以由服务请求客户端对应的服务器来执行。比如，服务器与服务提供端之间可以进行信息的交互，使得服务器能够获知服务提供端的可用服务的剩余情况。
84.例如，以餐厅订座为例，所述的服务提供端可以包括餐厅侧的服务器，服务器可以与餐厅侧的服务器进行信息交互，获知餐厅侧的剩余可订座位的情况。假如预计到达时间是12点，可以查看“11点50至12点15的时间范围内”(该时间范围内包括预计到达时间12点)是否有剩余座位可订。如果餐厅侧的座位都被订完了，没有剩余座位，那么服务器可以指示服务请求客户端不在服务请求客户端侧显示该餐厅的服务选项。如果餐厅仍有可订座位，就可以接受预订。
85.2)目标兴趣点的类型属于预设终点类型。
86.该条件的意思是，并不是所有的目标兴趣点都可以显示本说明书实施例的服务选项，可以设置特定类型的目标兴趣点才可以。
87.这里所述的预设终点类型具有比较宽泛的含义，例如，包括但不限于如下情况：
88.例如，目标兴趣点是预设的餐饮商家a或b。
89.又例如，预设的餐饮商家a的位置是位于某个商场中，而用户选定的目标兴趣点是该商场，那么，由于该商场中包括商家a，也可以在服务请求客户端的客户端页面中显示商家a的订座的服务选项。此时，要预订的服务时间是商家a的服务时间。
90.在步骤104中，服务器向目标兴趣点的服务提供端发送目标服务请求，该目标服务请求中包括预订服务请求对应的初始服务时间。
91.本步骤中，服务器在接收到服务请求客户端发送的预订服务请求时，可以确定该预订服务请求对应的初始服务时间。
92.在一个示例中，用户在服务请求客户端可以选择的是固定的服务时间(例如，11:
30)，即用户期望在该固定的服务时间使用目标兴趣点的服务，并且所述的预订服务请求中携带上述的固定的服务时间。那么，这种情况下，服务器在接收到预订服务请求时，可以将预订服务请求中携带的上述服务时间，作为初始服务时间。
93.在另一个示例中，用户在服务请求客户端并没有选择固定的服务时间，而是选择了智能预订选项。这种情况下，服务器接收到的预订服务请求中可以没有服务时间，服务器可以根据预订服务请求中携带的用户的起点和终点等信息，计算用户本次导航行程到达目标兴趣点的预计到达时间，并基于该预计到达时间确定所述初始服务时间。
94.例如，假设服务器计算的预计到达时间是中午12点，那么可以将初始服务时间确定为12点10分。具体的预计到达时间与初始服务时间之间的关系，可以由服务器根据实际业务需求确定，本说明书实施例对此不做限制，初始服务时间可以是预计到达时间，也可以是基于预计到达时间确定的时间。
95.示例性的，可以设置初始服务时间的设置规则是：12点、12点10分，12点20分,12点30分这样的每隔10分钟的时间，都可以选择为初始服务时间。如果预计到达时间位于两个服务时间可选项的中间，则选择靠后的可选项作为初始服务时间。比如，假如用户的预计到达时间是12点23分，则可以选择12点30分作为初始服务时间。
96.如上所述，服务器在接收到服务请求客户端发送的预订服务请求之后，可以确定该预订服务请求对应的初始服务时间，并向目标兴趣点的服务提供端发送目标服务请求，该目标服务请求中可以携带所述初始服务时间。当然，该目标服务请求中还可以携带其他信息，比如前述的就餐人数、预订的座位类型等用户选择的服务选项的信息。
97.在步骤106中，服务提供端向服务器反馈预订成功的确认信息。
98.其中，所述的服务提供端可以是服务提供侧的设备，例如，服务提供端可以是提供端客户端，或者是提供端服务器，或者是提供端客户端和提供端服务器，本实施例对此不做限制。例如，在餐厅订座的例子中，提供端服务器可以是用于为一家或多家餐厅提供餐厅座位的预订、餐厅菜单的信息管理等服务，服务器可以是将上述的目标服务请求发送至该提供端服务器。此外，在其他的例子中，如果服务提供端是提供端客户端，那么服务器也可以直接与提供端客户端进行交互。在本说明书实施例的描述中，将以提供端客户端和提供端服务器的架构为例，服务器可以将上述的目标服务请求发送至该提供端服务器。
99.服务提供端可以拒绝所述的初始服务时间，也可以接受初始服务时间。示例性的，服务提供端在接收到目标服务请求后，可以响应于对所述目标服务请求的确认操作，向服务器反馈预订成功的确认信息。
100.例如，上述的提供端服务器在接收到目标服务请求后，可以将该请求中携带的初始服务时间、以及就餐人数和预订的座位类型等信息，发送至提供端客户端。在餐厅订座的场景中，该提供端客户端可以是餐厅的预订台系统或者语音系统。提供端客户端可以语音提示或者页面显示“您有留座订单，就餐人数6-8人，订座类型大厅座位，预计留座时间是12点30分，请确认”。上述的12点30分即初始服务时间。餐厅服务员可以在预订台系统中点击页面选项接受该订单，或者也可以通过语音电话按键确认该初始服务时间的留座订单，那么相当于提供端客户端就接收到对所述目标服务请求的确认操作，则提供端客户端可以向提供端服务器反馈已经对目标服务请求进行了确认，再由提供端服务器向服务器反馈预订成功的确认信息。此外，在其他的例子中，对目标服务请求的确认操作，还可以是在提供端
服务器执行。比如，提供端服务器在接收到目标服务请求后，可以判断该请求要预订的初始服务时间是否满足预设的某些条件，若满足则提供端服务器可以反馈服务器上述的预订成功的确认信息。
101.在步骤108中，服务器根据所述确认信息，指示服务请求客户端展示预订服务成功信息。
102.服务器可以将服务提供端的确认信息转发至服务请求客户端，指示服务请求客户端展示预订服务成功信息，该预订服务成功信息中可以包括上述预订服务请求对应的初始服务时间。
103.其中，在服务器返回该确认信息之前，服务请求客户端也可以在向服务器发送了预订服务请求之后，就在客户端页面中提示用户“正在与商家协商为您留座至12:30”，其中，该提示中的12:30可以是服务器根据预计到达时间确定的初始服务时间，即提示用户正在等待商家确认初始服务时间。比如，服务请求客户端向服务器发送的预订服务请求中携带了智能预订选项的标识信息，服务器据此根据预计到达时间确定了初始服务时间12:30，并将该初始服务时间返回给服务请求客户端，服务请求客户端就可以展示上述的正在协商的提示信息。
104.当服务请求客户端接收到了上述确认信息之后，就可以将上述的正在协商的提示信息更改为“已经为您成功预订了餐厅b的座位，留座时间是12:30”，该更改后的信息即为预订服务成功信息，其中包括了所述初始服务时间12:30。
105.在步骤110中，在导航过程中，服务器持续计算到达目标兴趣点的预计到达时间。
106.在服务请求客户端侧，响应于用户触发导航至所述目标兴趣点的操作，开始路线导航。
107.例如，用户在开始导航行程之前，可以先通过服务请求客户端选择服务选项，发送预订服务请求等操作，然后用户可以触发导航至目标兴趣点的操作，服务请求客户端开始路线导航。在导航过程中，服务器可以持续计算到达目标兴趣点的预计到达时间。
108.但可以理解的是，本实施例中，服务请求客户端发送预订服务请求不一定是在导航行程开始前，也可以是在导航行程中。比如，在导航行程开始前，用户在通过服务请求客户端进行到目标兴趣点的路线规划操作时，客户端可以显示服务选项，接收用户对服务选项的选择操作并发起预订服务请求。又比如，在导航过程中，用户也可以随时选择目标兴趣点的服务选项，并通过服务请求客户端发起预订服务请求，例如，用户在导航行程开始前启用的是普通订座功能，在导航过程中，服务请求客户端可以在客户端页面弹窗提示用户“您是否要启用智能订座，随时动态调整留座时间？”，这种弹窗提示的信息也相当于智能预订选项。用户点击启用后，就可以将初始的普通订座功能切换为智能预订模式。比如，用户点击了上述客户端提示的切换为智能订座后，服务请求客户端也相当于接收到了用户对智能预订选项的选择操作，向服务器发送该智能预订选项的标识信息，服务器据此就可以开始根据预计到达时间自动调整初始服务时间了，该初始服务时间可以是普通订座功能时用户选择的固定时间。
109.本步骤中，服务器可以持续计算到达目标兴趣点的预计到达时间，所述的持续计算表示服务器在实时的监测预计到达时间的变化，计算的间隔时长本实施例不做限制，例如，可以每分钟计算一次预计到达时间。本步骤通过服务器持续计算预计到达时间，以备后
续步骤根据该计算得到的预计到达时间与初始服务时间进行比较，以确定是否要调整初始服务时间。
110.在步骤112中，若服务器检测到预计到达时间与初始服务时间之间发生偏差，则服务器向服务提供端发送对目标兴趣点的预订服务变更请求，所述预订服务变更请求用于将所述初始服务时间更新为目标服务时间。
111.本步骤中，可以由服务器将计算得到的预计到达时间与初始服务时间进行比较，判断所述的预计到达时间与所述初始服务时间之间是否发生偏差。
112.在一个例子中，可以通过设定时间阈值的方式来判断两者是否发生偏差。例如，若检测到预计到达时间晚于所述初始服务时间的时间偏差达到第一时间阈值，则可以确认发生偏差。又比如，若检测到预计到达时间早于所述初始服务时间的时间偏差达到第二时间阈值，则可以确认发生偏差。上述的第一时间阈值和第二时间阈值可以相同，也可以不同，本实施例不做限制。示例性的，假设第一时间阈值和第二时间阈值相同，都为30分钟，举例来说，假设初始服务时间是12:00，那么当预计到达时间为12:31时，则确定预计到达时间与所述初始服务时间之间发生偏差；或者，若预计到达时间为11:25，也可以确定预计到达时间与所述初始服务时间之间发生偏差。
113.本步骤中，服务器检测到预计到达时间与所述初始服务时间之间发生偏差时，可以根据预计到达时间确定目标服务时间，并向所述目标兴趣点的服务提供端发送预订服务变更请求，请求服务提供端的确认，请求中携带上述的目标服务时间。
114.例如，在上述的例子中，假设初始服务时间是12:00，预计到达时间为12:31，则服务器可以根据预计到达时间确定目标服务时间，该目标服务时间可以为12:40，服务器可以向服务提供端发送预订服务变更请求，携带上述的目标服务时间12:40，对初始服务时间进行了延后。或者，若预计到达时间是11:25，则服务器可以根据预计到达时间确定目标服务时间，该目标服务时间可以为11:40，对初始服务时间进行了提前。
115.其中，服务器根据预计到达时间确定目标服务时间的方式，与前述的基于该预计到达时间确定所述初始服务时间的方式可以相同，不再赘述。
116.另外，如果检测到预计到达时间与所述初始服务时间之间发生了时间偏差，但是该时间偏差并没有达到所述时间阈值，则可以保持初始服务时间不变，即不变更该初始服务时间。此外，对于服务器向服务提供端发送预订服务变更请求的条件，上述的通过时间偏差和时间阈值的比较来确定是一种示例的方式，实际实施中不局限于此，比如，除了发生偏差，还可以综合其他因素来确定是否要请求变更初始服务时间，例如可以包括但不限于用户的时间偏好、就餐人数等因子，可以根据实际业务需求来确定。
117.此外，服务器向服务提供端发送预订服务变更请求，请求服务提供端将初始服务时间更新为目标服务时间的过程中，服务器还可以指示在服务请求客户端展示服务时间的调整协商通知，例如可以提示“检测到您的预计到达时间延迟，正在与商家协调将您的服务时间调整为12点45分”，该12点45分即为上述的目标服务时间。
118.在步骤114中，服务提供端向服务器反馈对应所述预订服务变更请求的变更确认信息。
119.例如，在上述的步骤112中，服务器可以是将预订服务变更请求发送至服务提供端的提供端服务器，并由提供端服务器转发至提供端客户端，可以在提供端客户端进行语音
提示或者页面显示上述的预订服务变更请求中的信息。例如，以提供端客户端是餐厅侧的预订台系统为例，预订台系统可以提示“订单号**的用户王小姐，请求将留座时间由12点更改为12点20分”，其中的12点为初始服务时间，12点20分即目标服务时间，并可以同时辅以语音播报。
120.本步骤中，服务提供端可以反馈变更确认信息，例如，可以是在提供方端客户端进行对变更的确认，具体可以是餐厅侧的服务员通过语音电话按键或者预订台系统的页面选项，接受将初始服务时间更新为目标服务时间，比如，服务员点击了预订台系统的页面选项确认了该变更后，预订台系统可以向提供端服务器反馈对变更的确认，再由提供端服务器向服务器反馈对应所述预订服务变更请求的变更确认信息。同理，服务提供端的变更确认还可以是在提供端服务器侧自动完成，提供端服务器在接收到所述预订服务变更请求时，可以根据预设的一些规则条件判断该变更请求是否满足条件，如果满足所述的规则条件，则提供端服务器可以自动确认该变更，反馈给服务器变更确认信息，并可以通知提供端客户端，例如，可以在预订台系统通知“订单号**的用户王小姐，已经将留座时间由12点更改为12点20分”，使得商家知晓该变更。
121.此外，服务提供端还可以实时的接收和显示预计到达时间，比如在提供端客户端显示预计到达时间，每隔5分钟可以刷新一次。这样便于商家及时的了解到用户的到达情况。示例性的，服务器在向服务提供端发送预订服务变更请求时，也可以在该预订服务变更请求中携带用户的预计到达时间，这样服务提供端就可以同时得到预计到达时间和目标服务时间，对用户调整服务时间的原因也能够更清楚的了解，对用户的到达情况更好的知晓。
122.在步骤116中，服务器根据所述变更确认信息，指示服务请求客户端在导航界面展示预订服务变更信息，所述预订服务变更信息至少包括所述目标服务时间。
123.本步骤中，服务器可以向服务请求客户端反馈变更确认，并指示服务请求客户端在导航界面展示预订服务变更信息，携带目标服务时间。
124.在步骤118中，服务请求客户端接收并展示预订服务变更信息，所述预订服务变更信息包括所述初始服务时间更新后的目标服务时间。
125.本步骤中，服务请求客户端可以展示预订服务变更信息，所述预订服务变更信息包括所述初始服务时间更新后的目标服务时间。例如，预订服务变更信息可以是“已经将您的留座时间更新为12：20”，其中的12:20即为目标服务时间。通过自动为用户变更服务预订信息，并在服务请求客户端进行展示，降低了对用户导航驾驶的影响。
126.此外，本说明书实施例的服务时间在导航过程中可以多次更新。
127.例如，当接收到目标服务时间后，可以将所述目标服务时间作为新的初始服务时间；并且继续上述的对预计到达时间的监测过程，比如，若监测到预计到达时间相比于所述新的初始服务时间之间发生偏差，则服务器可以基于预计到达时间确定目标服务时间，并请求服务提供端确认，在服务提供端确认后，可以在服务请求客户端展示将上述新的初始服务时间更新后的目标服务时间。
128.在步骤120中，在导航行程到达距离终点预设距离范围内时，在服务请求客户端显示服务信息。
129.本步骤中，在距离终点预设距离范围内时，可以在服务请求客户端侧显示服务信息。其中，所述的预设距离范围内可以是临近到达终点，也可以是已经到达终点。所述服务
的服务信息，以餐饮订座为例，可以是“您预订了留座时间12点15分、人数7人、菊花厅包厢、最低消费2000的座位”此类提示信息。
130.此外，对于服务提供端来说，可以接收到实时的用户的预计到达时间的更新，例如，可以每隔5分钟更新一次用户的预计到达时间，这样服务提供端可以更好的知晓用户的状况。而如果用户的预计到达时间超过预设时间段未更新，比如已经20分钟没更新，则服务提供端可以接收到服务风险通知，该服务风险通知用于提示用户具有不再使用终点服务的爽约风险。此时，商家可以电话联系一下导航用户进行确认。
131.本实施例的服务预订方法，通过在导航行程中监测预计到达时间，并根据该预计到达时间调整服务时间，使得能够将服务时间适应预计到达时间的变化而更新，从而使得服务提供更加灵活；对于服务提供端来说，还通过提示用户的预计到达时间，能够更清楚的了解用户的到达情况，方便服务提供端灵活控制服务的提供；对于用户来说，用户也不需要再自己通知服务提供端自己的到达情况，就可以实现服务时间的动态调整，不仅得到了便利，而且还能根据自己的预计到达时间随到随使用服务，也较为方便。
132.如下以通过本说明书实施例的方法进行美食餐厅的订座为例，描述在导航场景中，用户进行餐厅订座的过程。但可以理解的是，本说明书实施例的方法不局限于餐厅订座的场景。其中，在本例子中，服务请求客户端可以是用户手机上的地图应用app，服务器可以是导航系统，服务提供端可以包括用于对餐厅的座位预订或菜单等信息进行管理的提供端服务器、以及面向餐厅服务员的提供端客户端。
133.假设用户小王要驾车去餐厅吃饭，所述的驾车可以是自驾车，也可以是打车等其他形式。如图2的示意，小王在地图应用的页面中输入了自己的起点和将要去的终点，终点是餐厅b，查询从起点至餐厅b的导航路径，即进行从起点到餐厅b的路线规划。
134.该导航路径计算的请求可以由地图应用发送至导航系统。导航系统接收到从小王的起点至餐厅b的导航路径计算请求之后，一方面可以计算餐厅b的预计到达时间，例如，图2中示意了餐厅b的预计到达时间是12点。另一方面，导航系统还可以查询终点是否满足预设终点类型。例如，若导航系统通过与餐厅b侧的提供端服务器进行信息交互，获知餐厅b在小王的预计到达时间对应的时间范围内(如，11点50至12点20的时间段)具有剩余的可订座位，则导航系统可以指示在地图应用的导航页面显示餐厅b的订座选项。
135.具体实现中，可以是先在页面中显示“智能订座，到店开吃”的服务预订入口21。接着，如图2的示意，用户小王点击了服务预订入口21，地图应用客户端检测到对服务预订入口的触发操作后，页面可以跳转到显示餐厅b订座的多个服务选项。请继续参见图3的示意，例如，可以显示多个服务选项，包括需要订座的人数、座位类型、留座时间等。如图3所示，用户小王选择了“6-8人、智能订座、包厢b”等选项，并选择立即订座。其中，所述的“智能订座”选项31即可以称作智能预订选项，用户选择该智能预订选项，表明希望根据预计到达时间动态调整餐厅的留座时间。由图3还可以看到，用户小王不需要选择类似11:30/12:30等明确的留座时间，而只需要选择“智能订座”，就可以实现根据预计到达时间给小王动态留座。
136.当然，可选的，在其他的示例性方式中，用户也可以选择一个初始的自己期望的留座时间11:30，并允许导航系统根据预计到达时间自动调整该留座时间。还可以是，用户初始选择了期望留座时间11:30，在起点到终点的导航行程中，可以弹出提示“您是否要更改为智能留座，可以根据您的预计到达时间调整留座时间？”，通过此类方式实现中途修改也
可以。
137.如图3所示，当用户点击了立即订座后，地图应用客户端可以向导航系统发送请求在该餐厅b留座的预订服务请求。导航系统可以根据用户的预计到达时间(12点)，确定在餐厅b留座的留座时间，该留座时间可以称为初始服务时间。例如，根据预设的留座时间的设置规则，如果预计到达时间是12点，可以将留座时间自动设为12点15分。当然，这只是示例，也可以将预计到达时间12点作为留座时间。在其他的例子中，如果用户在选择服务选项时，选择的11:30这样的固定的服务时间，并携带在服务预订请求中发给导航系统，那么导航系统也可以将该服务时间作为初始服务时间。接着，导航系统可以向商家-餐厅b的提供端服务器发送目标服务请求，该目标服务请求中携带：导航用户就餐的留座时间12点15分，请求商家侧对该留座请求及留座时间进行确认，所述的12点15分即初始服务时间。
138.其中，对于餐厅b的可订座位，在一个示例中，该可订座位中可以包括商家分配给导航系统侧的独占库存，这种类型的库存，导航系统侧可以直接扣除座位，进行锁定。在另一个示例中，该可订座位中没有导航系统侧的独占库存，那么对于非独占库存，导航系统可以向商家请求确认非独占的座位。
139.在导航系统侧请求商家确认留座时间的时候，为了方便用户知晓其订座订单的实时状态和进展情况，可以在导航用户的地图应用客户端侧展示该协商留座时间的状态。例如，请参见图4的示意，区域41中可以提示“12点座位预订待商家确认”此类表示正在等待商家确认该留座订单的状态。
140.同时，在商家-餐厅b侧，用户小王的留座订单通知商家的形式包括但不限于：语音通知或者预订台系统通知等方式。比如，如果是语音电话通知商家，则可以语音向餐厅b播报订座信息，例如“用户王小姐想要预订6-8人座位、包厢b，预计到达时间12点，留座时间12点”等。商家可以通过电话键盘按键的方式进行接单或者拒单。又比如，如果是预订台系统通知商家，则商家可以在预订台系统内进行接单或者拒单。
141.如果商家接单，则服务提供端可以向导航系统反馈预订成功的确认信息，那么在导航用户的地图应用客户端侧，可以在图4的区域41的位置，将“12点座位预订待商家确认”修改为“已为您成功预订12点的座位，6-8人，包厢b”此类预订服务成功信息，该预订服务成功信息中包括初始服务时间(即留座时间)12点，这样小王就知晓餐厅b的座位已经预留好了。如果商家拒单，则可以在导航用户的地图应用客户端侧提示“您的订单因商家取消/拒绝关闭”或者“您的订单因商家超时未接单关闭”的信息，以使得小王知晓她的留座订单没有成功。
142.用户小王进入导航行程中之后，导航系统可以监控该导航订单的状态，根据小王的路途中的路况，持续计算终点的预计到达时间。并且，导航系统可以将该实时的预计到达时间同步至商家侧，使得商家侧实时知晓小王的路途状况。例如，导航系统可以每隔5分钟向餐厅b推送一次小王的预计到达时间，这样餐厅b就可以知晓小王的预计到达时间有没有变化，是否有较大的偏差。当然，导航系统向商家侧推送的信息不限于预计到达时间，也可以包括其他信息，比如用户的路途是否一路顺畅，是否遇到拥堵等。
143.在一个例子中，假设用户小王在驾车过程中遇到了修路，或者是由于拥堵/绕路的原因，导致预计到达时间与初始服务时间相比发生了较大的偏差。例如，导航系统经过计算发现预计到达时间是12点35分，该12点35分相比于初始的留座时间12点(即初始服务时间)
延迟了35分钟。而假设预设的时间阈值是30分钟，那么确定小王的预计到达时间与初始服务时间之间的时间偏差已经超过了时间阈值，此时导航系统可以执行对留座时间的更新处理。具体的，比如，导航系统可以向商家侧的提供端服务器发送预订服务变更请求，该预订服务变更请求中携带新的留座时间“12点45分”，该新的留座时间可以称为目标服务时间，请求商家确认该更新的留座时间。
144.在导航系统请求餐厅b侧的服务提供端确认更新的留座时间的过程中，可以在导航用户的地图应用客户端侧展示对留座时间的调整协商通知，该通知中包括上述的更新的留座时间。例如，图4示意的小王的客户端页面的区域41可以更改显示成“检测到店时间变更，正与商家协商调整留座时间至12点45分”。这样小王就可以知晓导航系统正在为其协商调整留座时间。此外，考虑到用户小王正在导航行程中，可以采用提示窗加辅助语音播报的形式，提示上述信息，这样小王更加方便的知晓留座时间协商更改的状态，降低对驾驶的影响。
145.而在餐厅b侧，同上面的描述，可以语音通知或者预订台系统通知商家要协商调整小王的留座时间，比如可以在预订台系统提示“由于道路拥堵，用户王小姐想要将留座时间由12点调整为12点45分，请确认”。商家可以通过电话按键或者预订台系统接单或者拒单。不论商家是接单还是拒单，导航系统都会将本次修改留座时间的订单状态通知给小王的地图应用客户端侧。例如，假设商家接受了本次留座时间的调整，那么小王的地图应用客户端侧可以通过页面提示和语音播报的方式提示已经为其成功留座至新的时间12点45分。参见图5的示意，可以在导航页面中提示用户小王“检测到前方拥堵，已为您智能留座至12：45”，该提示信息即预订服务变更信息，其中包括了初始服务时间更新后的目标服务时间12:45。具体的提示方式，本实施例不做限制，例如，可以是图5示意的10秒钟自动消失的提示窗，或者也可以是语音提示，或者还可以是靠用户点击退出才消失的提示窗，等。
146.此外，对于上述的留座时间的调整，商家侧给予确认的方式，除了上述的通过预订台系统或语音电话按键进行确认，还可以采取商家侧的提供端服务器自动确认的方式，比如，提供端服务器可以设置一个规则，示例性的，该规则可以是“对于偏差50分钟以内的留座时间，自动予以确认”，那么，本实施例的例子中，初始的留座时间是12，后来修改为12:45，留座时间延迟符合上述的确认规则，所以可以由商家侧的提供端服务器自动给予确认，即提供端服务器可以给导航系统自动发送确认该更新的留座时间的通知(即变更确认信息)。不过，提供端服务器也会将该更新的留座时间通知至提供端客户端侧，以使得商家知晓该更新的留座时间。比如可以在预订台系统提示商家“订单***：王小姐的留座时间由12:00分调整为12:45”。
147.本实施例中，预计到达时间与初始服务时间之间发生偏差，不仅可以包括上述例子所述的延迟了一段时间，也可以是早到了一段时间。比如，初始的预计到达时间是12点，结果由于用户绕了一条近路，使得预计到达时间提早至11点25，该11:25相比于初始的留座时间12:00提早了35分钟，也同样超过了时间偏差的时间阈值，那么导航系统也可以向商家侧发送预订服务变更请求，携带更新的留座时间作为目标服务时间，只不过此时更新的留座时间可以提前，比如提前至11点30。
148.本实施例并不限制在用户小王的整个导航行程中发生了几次留座时间的变更，比如一次、两次甚至更多次都可以，只要满足上述的预计到达时间与初始服务时间之间的时
间偏差达到了相应的时间阈值即可。
149.例如，初始时小王的导航终点的预计到达时间是12:00，留座时间是12:00(可以称为初始服务时间)。继而，由于道路拥堵，小王的终点预计到达时间改成了12:35，该预计到达时间相比于初始服务时间12:00的时间偏差是延迟了35分钟，如果时间阈值是30分钟，那么导航系统需要与商家协商调整留座时间，而如果时间阈值是40分钟，那么该时间偏差仍然在时间阈值的范围内，则可以保持留座时间仍然是12:00，导航系统不用与服务提供端协商调整留座时间，不过，如前所述的，导航系统可以实时的将用户小王的预计到达时间通知给服务提供端，这样商家能够实时知晓用户的预计到达时间。
150.当小王到达终点附近时，地图应用客户端侧可以显示终点的服务信息，具体到本例子中，可以在小王的地图应用客户端弹出餐厅b订座订单的相关信息，比如，参见图6的示意，可以给王小姐在客户端提示她本次就餐的座位预留时间、包厢等订单信息。
151.此外，图6所示意的服务信息的提示，可以是在导航行程到达距离终点预设距离范围内时，所述的预设距离范围内包括临近终点的位置，也可以包括已经到达终点。比如，可以在用户小王距离终点0.5公里处弹出该提示，辅助语音播报；或者也可以在检测到小王已经到达终点时进行提示。商家侧也可以进行提示，提示用户已经到达或者临近到达。
152.如果用户小王的预计到达时间超过了预设时间段未更新，比如，从餐厅b侧来看，本来小王的预计到达时间是每5分钟更新一次，结果已经15分钟未进行更新，则餐厅b侧的服务提供端可以接收到服务风险通知，该通知用于提示餐厅b用户小王具有爽约的风险。该服务风险通知可以是语音播报的形式，也可以是预订台系统显示的形式，本实施例不做限制。示例性的，可以是既进行预订台系统显示，也同时进行语音播报“订单号***的用户小王已经15分钟未更新预计到达时间，具有一定风险，请联系用户确认是否可到店”。
153.本说明书实施例的服务预订方法，采用基于导航用户的预计到达时间动态调整服务时间。这种方式可以使得用户能够随到随用，比如就餐场景下，用户能够随到随吃，系统就能够自动帮用户调整好适应预计到达时间的服务时间，对于用户来说非常方便，获得了更好的服务体验；从商家侧来看，商家也能够获知用户的实时可到达状态，知晓用户是否将要到达，并在用户存在爽约风险时，也能够及时的收到通知，从而及时灵活的对服务进行调整。
154.图7是一示例性实施例提供的一种服务预订方法的流程图，该方法可以由服务请求客户端执行。如图7所示，该方法可以包括如下处理，其中，各个步骤的序号不表示对步骤间顺序的限制；此外，如下的步骤描述中，涉及到与前述实施例相同的步骤，将简单描述，详细的处理可以结合参见前述实施例。
155.在步骤700中，响应于接收到用户对目标兴趣点的目标操作，展示与所述目标兴趣点对应的服务选项。
156.本步骤中，用户可以在服务请求客户端执行对目标兴趣点的目标操作。例如，所述的目标兴趣点可以是商场、餐馆、办公大厦等。所述的目标操作例如可以是选定操作或者路线规划操作，比如，用户可以在服务请求客户端选定一个目标兴趣点，或者请求执行从用户的起点至目标兴趣点的路线规划操作。
157.当服务请求客户端接收到上述目标操作后，可以在客户端页面展示目标兴趣点的服务选项，以供用户选择自己需要的服务选项。示例性的，在餐厅订座的场景中，所述的服
务选项可以包括就餐人数、预订的座位类型等。
158.在步骤702中，根据用户对服务选项的选择操作，确定对目标兴趣点的预订服务请求。
159.本步骤中，服务请求客户端可以接收用户对上述展示的服务选项的选择操作，比如，用户选择了就餐人数“6-8人”，也选择了座位类型“10人包间”等。并且，服务请求客户端可以据此确定对目标兴趣点的预订服务请求，该预订服务请求中可以携带上述用户选择的服务选项的信息，例如就餐人数“6-8人”、座位类型“10人包间”等信息。
160.此外，在一些例子中，服务请求客户端显示的服务选项中可以包括多个固定的服务时间，用户可以从中选择一个自己期望的服务时间，该服务时间可以携带在上述的预订服务请求中。
161.在另一些例子中，服务请求客户端显示的服务选项中还可以包括智能预订选项，该智能预订选项用于指示根据所述预计到达时间自动调整初始服务时间。如果用户没有选择上述的固定的服务时间，而是选择了该智能预订选项，那么预订服务请求中可以携带所述智能预订选项的标识信息，并没有携带固定的服务时间。
162.本步骤中，服务请求客户端在确定预订服务请求后，可以如前述的实施例所述的，将该预订服务请求发给服务器，再由服务器据此向服务提供端发送目标服务请求，以请求服务提供端对本次的服务预订给予确认。但是，需要说明的是，本实施例不局限于此实现方式，服务请求客户端在确定预订服务请求后，可以通过某种方式将该预订服务请求中的信息传输至服务提供端，并向服务提供端请求预订本次服务。
163.在步骤704中，显示所述预订服务请求对应的初始服务时间。
164.本步骤中，服务请求客户端可以显示所述预订服务请求对应的初始服务时间。
165.在一些例子中，该初始服务时间可以是用户选择的固定的服务时间；在另一些例子中，该初始服务时间可以是服务器根据预计到达时间确定的时间。
166.此外，服务请求客户端显示该初始服务时间，可以是在服务提供端确认之前就显示，例如前述实施例所述的，服务器在向服务提供端发送目标服务请求之后，尚未收到服务提供端反馈的确认信息之前，就可以在服务请求客户端显示“12点座位预订待商家确认”。或者，也可以在服务请求客户端接收到服务提供端的确认信息之后，显示该初始服务时间，该初始服务时间可以是包括在预订服务成功信息中，例如“已为您成功预订12点的座位”。
167.在步骤706中，响应于用户触发导航至所述目标兴趣点的操作，开始路线导航。
168.本步骤中，服务请求客户端在检测到用户触发导航至所述目标兴趣点的操作后，开始路线导航。例如，可以在服务请求客户端的客户端页面中显示导航路线。
169.在步骤708中，在导航过程中，若预计到达时间与所述初始服务时间之间发生偏差，则接收并展示预订服务变更信息，其中，所述预订服务变更信息包括所述初始服务时间更新后的目标服务时间。
170.本步骤中，如果在导航过程中，预计到达时间与所述初始服务时间之间发生偏差，服务请求客户端还可以接收并展示预订服务变更信息，该预订服务变更信息包括所述初始服务时间更新后的目标服务时间。例如，在上述的例子中，可以将“已为您成功预订12点的座位”更改提示为“已将您的留座时间由12点调整至12点20分”，其中的12点20分即目标服务时间。
171.此外，本实施例中的展示预订服务变更信息，所述的展示包括但不限于文字显示或语音提示等方式。
172.本实施例的服务预订方法，说明了服务请求客户端侧的执行处理，需要说明的是，前述的图1所示的实施例，是一种示例的实现方式，本说明书实施例不局限于此，比如，只要服务请求客户端的执行处理是本实施例方法描述的处理，则本实施例不限制其他设备如何配合服务请求客户端来实现该服务预订方法。从服务请求客户端侧来看，该服务预订方法实现了对服务时间的自动调整，服务请求客户端不仅可以显示初始服务时间，还能够在预计到达时间与所述初始服务时间之间发生偏差时，在客户端展示预订服务变更信息，包括提示更新后的目标服务时间，这是一种服务时间自动调整的过程展示，用户不再需要自己发起对服务时间的调整，便利了用户，而且也降低了对用户驾驶过程的影响。
173.图8是一示例性实施例提供的一种服务预订方法的流程图，该方法可以由服务提供端执行。例如，服务提供端可以是提供端服务器，或者是提供端客户端，或者是提供端服务器和提供端客户端的组合。如图8所示，该方法可以包括如下处理，其中，各个步骤的序号不表示对步骤间顺序的限制；此外，如下的步骤描述中，涉及到与前述实施例相同的步骤，将简单描述，详细的处理可以结合参见前述实施例。
174.在步骤800中，接收对目标兴趣点的目标服务请求，其中，所述目标服务请求包括初始服务时间。
175.本步骤中，服务提供端可以接收到对目标兴趣点的目标服务请求，请求中可以包括用户预订的初始服务时间。例如，服务提供端可以在提供端客户端提示该初始服务时间。
176.在步骤802中，响应于对所述目标服务请求的确认操作，发送预订成功的确认信息。
177.本步骤中，服务提供端可以接收到对目标服务请求的确认操作，并发送预订成功的确认信息。其中，服务提供端可以是向目标服务请求的发送方反馈该确认信息，例如，若该目标服务请求是服务器发送，则服务提供端可以向服务器反馈上述的确认信息。
178.所述的确认操作，包括但不限于：例如，可以是提供端客户端接收到的用户通过按键确认或者页面选项选择确认的方式触发的确认操作；又例如，还可以是提供端服务器自动执行的确认操作，比如，提供端服务器将目标服务请求中的信息与预设的规则条件比较，若确认该信息符合所述规则条件，则可以由提供端服务器反馈确认信息。
179.在步骤804中，接收对所述目标兴趣点的预订服务变更请求，其中，所述预订服务变更请求用于将所述初始服务时间更新为目标服务时间。
180.本步骤中，服务提供端还可以接收到对目标兴趣点的预订服务变更请求，该请求是用于请求将所述初始服务时间更新为目标服务时间，并且该请求中可以携带所述目标服务时间。
181.本实施例的服务预订方法，说明了服务提供端侧的执行处理，需要说明的是，前述的图1所示的实施例，是一种示例的实现方式，本说明书实施例不局限于此，比如，只要服务提供端的执行处理是本实施例方法描述的处理，则本实施例不限制其他设备如何配合服务提供端来实现该服务预订方法。从服务提供端侧来看，该服务预订方法使得在服务提供端能够自动接收到服务时间的变更请求，实现了对服务时间的自动调整，该方法使得服务提供端能够及时的获知到用户的时间变更需求，更灵活的进行服务提供。
182.图9是一示例性实施例提供的一种服务预订方法的流程图，该方法可以由服务请求客户端对应的服务器执行。如图9所示，该方法可以包括如下处理，其中，各个步骤的序号不表示对步骤间顺序的限制；此外，如下的步骤描述中，涉及到与前述实施例相同的步骤，将简单描述，详细的处理可以结合参见前述实施例。
183.在步骤900中，响应于接收到服务请求客户端发送的对目标兴趣点的预订服务请求，确定所述预订服务请求对应的初始服务时间。
184.本步骤中，服务器可以接收到服务请求客户端发送的预订服务请求，并据此确定初始服务时间。例如，若预订服务请求中携带了服务时间，则服务器可以将该服务时间作为初始服务时间。又例如，若预订服务请求中没有携带固定的服务时间，而携带了智能预订选项的标识信息，则服务器可以根据预计到达时间确定初始服务时间。
185.此外，服务器可以在确定初始服务时间后，向服务提供端发送目标服务请求，携带该初始服务时间，以请求服务提供端确认本次的服务预订。
186.在步骤902中，在导航过程中，持续计算到达所述目标兴趣点的预计到达时间。
187.本实施例中，服务器可以在导航过程中持续计算预计到达时间，例如，每2分钟计算一次预计到达时间。并且，每次计算得到预计到达时间后，都可以执行一次预计到达时间与初始服务时间之间的比较。
188.在一个示例中，假设设定了时间阈值，若预计到达时间与初始服务时间之间的时间偏差达到了该时间阈值，则可以认为预计到达时间与初始服务时间之间发生了偏差，继续执行步骤904。而如果预计到达时间与初始服务时间之间的时间偏差在所述时间阈值的范围内，则可以认为预计到达时间与初始服务时间之间未发生偏差，不执行步骤904，而是继续保持初始服务时间不变。
189.在步骤904中，若检测到所述预计到达时间与所述初始服务时间之间发生偏差，则向所述目标兴趣点的服务提供端发送预订服务变更请求，所述预订服务变更请求用于将所述初始服务时间更新为目标服务时间。
190.本步骤中，服务器可以在预计到达时间与所述初始服务时间之间发生偏差的情况下，向服务提供端发送预订服务变更请求，请求将初始服务时间变更为目标服务时间。该目标服务时间可以是服务器根据最新计算的预计到达时间确定。
191.此外，如果服务器接收到服务提供端对上述预订服务变更请求的变更确认信息，则可以指示服务请求客户端在导航界面展示预订服务变更信息，包括展示目标服务时间。
192.本实施例的服务预订方法，说明了服务器侧的执行处理，从服务器侧来看，该服务预订方法使得服务器能够实时监测预计到达时间的变化，并能够在预计到达时间与初始服务时间之间发生了较大的偏差时，自动触发对服务时间的调整，比如服务器能够自动计算出目标服务时间，并自动向服务提供端发送预订服务变更请求，请求将初始服务时间更新为目标服务时间；正是由于服务器的上述处理，使得能够自动触发服务时间的自动调整。
193.图10是一示例性实施例提供的一种服务预订装置，该装置可以应用于服务请求客户端，并可以应用于实现本说明书任一实施例的方法，如图10所示，该装置可以包括：选项展示模块1001、请求确定模块1002、信息显示模块1003和更新处理模块1004。
194.选项展示模块1001，用于响应于接收到用户对目标兴趣点的目标操作，展示与所述目标兴趣点对应的服务选项。
195.请求确定模块1002，用于根据用户对所述服务选项的选择操作，确定对所述目标兴趣点的预订服务请求。
196.信息显示模块1003，用于显示所述预订服务请求对应的初始服务时间；并且响应于用户触发导航至所述目标兴趣点的操作，开始路线导航。
197.更新处理模块1004，用于在导航过程中，若预计到达时间与所述初始服务时间之间发生偏差，则接收并展示预订服务变更信息，其中，所述预订服务变更信息包括所述初始服务时间更新后的目标服务时间。
198.图11是一示例性实施例提供的一种服务预订装置，该装置可以应用于服务提供端，并可以应用于实现本说明书任一实施例的方法，如图11所示，该装置可以包括：请求接收模块1101、请求确认模块1102和变更处理模块1103。
199.请求接收模块1101，用于接收对目标兴趣点的目标服务请求，其中，所述目标服务请求包括初始服务时间。
200.请求确认模块1102，用于响应于对所述目标服务请求的确认操作，发送预订成功的确认信息。
201.变更处理模块1103，用于接收对所述目标兴趣点的预订服务变更请求，其中，所述预订服务变更请求用于将所述初始服务时间更新为目标服务时间。
202.图12是一示例性实施例提供的一种服务预订装置，该装置可以应用于服务器，并可以应用于实现本说明书任一实施例的方法，如图12所示，该装置可以包括：时间确定模块1201、时间监测模块1202和变更处理模块1203。
203.时间确定模块1201，用于响应于接收到服务请求客户端发送的对目标兴趣点的预订服务请求，确定所述预订服务请求对应的初始服务时间。
204.时间监测模块1202，用于在导航过程中，持续计算到达目标兴趣点的预计到达时间。
205.变更处理模块1203，用于若检测到所述预计到达时间与所述初始服务时间之间发生偏差，则向所述目标兴趣点的服务提供端发送预订服务变更请求，所述预订服务变更请求用于将所述初始服务时间更新为目标服务时间。
206.图13是一示例性实施例提供的一种服务预订系统的架构示意图，该服务预订系统可以用于实现本说明书任一实施例的服务预订方法。如下对该系统做简单描述，该系统的各个组成部分的详细处理可以结合参见前述的任一方法实施例。如图13所示，该服务预订系统可以包括：服务请求客户端1301、服务器1302和服务提供端1303。
207.其中，所述服务请求客户端1301，用于接收用户对目标兴趣点的目标操作，展示与所述目标兴趣点对应的服务选项；并接收用户对所述服务选项的选择操作，向服务器发送对所述目标兴趣点的预订服务请求。
208.例如，该服务请求客户端可以是用户的手机地图应用。所述的目标兴趣点可以是餐厅、商场、办公大厦等用户感兴趣的位置点。例如，在餐厅订座的场景中，该服务请求客户端可以用于展示就餐人数、订座的座位类型等服务选项，并根据用户对服务选项的选择，确定预订服务请求，该预订服务请求可以携带服务选项的信息，并发送给服务器1302处理。
209.所述服务器1302，用于向所述目标兴趣点的服务提供端发送目标服务请求，所述目标服务请求包括所述预订服务请求对应的初始服务时间；以及，根据所述服务提供端反
馈的确认信息，指示所述服务请求客户端展示预订服务成功信息；还用于若检测到到达目标兴趣点的预计到达时间与所述初始服务时间之间发生偏差，则向所述服务提供端发送预订服务变更请求，所述预订服务变更请求用于将所述初始服务时间更新为目标服务时间。
210.所述服务提供端1303，用于在接收到所述服务器发送的目标服务请求时，向所述服务器反馈预订成功的确认信息。例如，所述的服务提供端1303可以是服务提供侧的设备。在一些例子中，该服务提供端1303可以包括提供端客户端，例如，该提供端客户端可以是餐厅的预订台系统。
211.本实施例的服务预订系统，通过服务请求客户端、服务器和服务提供端的交互和配合，实现了对服务请求客户端侧的用户预订服务时间的自动调整，能够基于用户的预计到达时间，将用户预订的初始服务时间自动调整为目标服务时间，不仅方便了用户，用户不再需要主动与服务提供端交互，降低了对用户驾驶过程的影响，而且也便利了服务提供端的商家，商家能够及时的获知到用户的到达情况，并且根据用户的到达情况自动调整服务时间，使得服务的提供更加灵活，便于商家灵活安排。
212.本说明书实施例还提供了一种电子设备，在硬件层面，该设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。本说明书一个或多个实施例可以基于软件方式来实现，比如由处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行。当然，除了软件实现方式之外，本说明书一个或多个实施例并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。其中，电子设备中的存储器中可以存储可执行指令，处理器可以用于通过运行所述的可执行指令以实现本说明书任一实施例所述的方法。
213.上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
214.在一个典型的配置中，计算机包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
215.内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
216.本说明书实施例还提供了一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现本说明书任一实施例所述的方法。
217.计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的
存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
218.还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
219.上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
220.在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
221.应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在
……
时”或“当
……
时”或“响应于确定”。
222.以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。