一种服务信息获取方法及装置与流程

本申请涉及互联网技术领域，尤其涉及一种服务信息获取方法及装置。

背景技术：

在一些应用场景下，可能会存在由第三方用户代替实际服务请求方向服务提供方请求某种服务的情况。例如，在打车场景下，目前提出一种代叫车服务，叫车方可以使用终端发起代叫车订单，其中，代叫车订单中记录有实际的乘车方信息，服务器在接收到乘车订单后可以将代叫车订单分配给提供乘车服务的司机方，后续司机方可以根据代叫车订单中记录的乘车方信息，与实际的乘车方取得联系并提供乘车服务。

但是，在诸如上述由第三方用户代叫某种服务的情况下，第三方用户由于并不是实际的服务请求方，故很难及时获知服务提供方提供服务过程中的实际服务状况，由此可能会带来一定的安全隐患。

技术实现要素：

有鉴于此，本申请实施例提供一种服务信息获取方法及装置，可以使代叫方能够实时关注服务订单的服务信息，从而能够有效避免服务过程中可能出现的安全隐患，并提升用户体验度。

主要包括以下几个方面：

第一方面，本申请实施例提供了一种服务信息获取方法，应用于服务器中，包括：

接收第一服务请求端发送的为第二服务请求端请求服务的服务请求，并派发所述服务请求对应的服务订单；

若检测到所述第一服务请求端请求获取所述服务订单被执行过程中产生的服务信息，则在检测到所述服务订单被服务提供端执行后，从所述服务提供端中获取所述服务信息；

将获取的所述服务信息通知给所述第一服务请求端。

在一种可能的实施方式中，在检测到所述第一服务请求端请求获取所述服务订单被执行过程中产生的服务信息之后，还包括：

向所述第二服务请求端发送授权请求，其中，所述授权请求用于请求授权所述第一服务请求端获取所述服务信息；

在从所述服务提供端中获取所述服务信息之前，还包括：

接收所述第二服务请求端回复的同意授权指示。

在一种可能的实施方式中，根据以下方式检测所述第一服务请求端请求获取所述服务订单被执行过程中产生的服务信息：

确定接收的所述服务请求中携带有所述服务信息的获取请求信息。

在一种可能的实施方式中，若确定接收的所述服务请求中未携带有所述服务信息的获取请求信息，还包括：

向所述第一服务请求端发送提示界面信息，所述提示界面信息用于提示是否请求获取所述服务信息；

接收所述第一服务请求端针对所述提示界面信息发送的所述服务信息的获取请求信息。

在一种可能的实施方式中，在向所述第一服务请求端发送提示界面信息之后，还包括：

若在所述服务订单被所述服务提供端执行后，仍未接收到所述第一服务请求端针对所述提示界面信息发送的所述服务信息的获取请求信息，则指示所述第一服务请求端取消展示基于所述提示界面信息生成的提示界面。

在一种可能的实施方式中，所述方法还包括：

若接收到所述第一服务请求端发送的功能说明获取请求，则向所述第一服务请求端发送功能说明界面信息，所述功能说明界面信息用于描述所述服务信息的获取方式。

在一种可能的实施方式中，所述方法还包括：

向所述第一服务请求端发送第一申请授权提示，所述第一申请授权提示用于提示在所述服务请求成功发送后所述服务器向所述第二服务请求端发送所述授权请求。

在一种可能的实施方式中，在向所述第二服务请求端发送授权请求之后，还包括：

向所述第一服务请求端发送第二申请授权提示，所述第二申请授权提示用于提示已向所述第二服务请求端发送所述授权请求。

在一种可能的实施方式中，在接收所述第二服务请求端回复的同意授权指示之后，还包括：

向所述第一服务请求端发送第一授权成功提示，以及，向所述第二服务请求端发送第二授权成功提示。

在一种可能的实施方式中，在接收到所述第二服务请求端回复的同意授权指示之后，还包括：

向所述服务提供端发送第三授权成功提示，所述第三授权成功提示用于提示在所述服务订单被执行过程中上报所述服务信息。

在一种可能的实施方式中，所述将获取的所述服务信息通知给所述第一服务请求端，包括：

在所述服务订单执行结束且结束时间超出所述第一设定时长之前，若检测到所述第一服务请求端发送用于获取所述服务信息的获取请求，则将获取的所述服务信息通知给所述第一服务请求端。

在一种可能的实施方式中，所述方法还包括：

在所述服务订单执行结束且结束时间超出所述第一设定时长之后，向所述第一服务请求端发送禁止获取提示，所述禁止获取提示用于提示禁止获取所述服务信息；和/或，

指示所述第一服务请求端隐藏用于获取所述服务信息的触发选项。

在一种可能的实施方式中，所述将获取的所述服务信息通知给所述第一服务请求端，包括：

向所述第一服务请求端发送所述服务信息以及所述服务信息的展示页面信息，其中，所述展示页面信息包括所述服务信息的标识、生成时间、以及文件大小中的至少一种。

在一种可能的实施方式中，所述方法还包括：

每隔设定时间段从所述服务提供端中获取所述设定时间段的服务信息，更新所述服务信息的展示页面信息，并将更新后的展示页面信息通知给所述第一服务请求端。

在一种可能的实施方式中，所述方法还包括：

在所述服务订单被执行的过程中，若在第二设定时长内无法从所述服务提供端中获取所述服务信息，则向所述第一服务请求端发送第一异常提示，所述第一异常提示用于提示所述服务信息获取失败。

在一种可能的实施方式中，所述方法还包括：

若检测到所述服务订单提前执行结束，或检测到所述服务订单执行过程中的行程位置在第三设定时长内未发生变化，则向所述第一服务请求端发送第二异常提示，所述第二异常提示用于提示查看所述服务信息。

在一种可能的实施方式中，所述服务信息包括录音内容。

第二方面，本申请实施例提供了一种服务信息获取方法，应用于第一服务请求端中，包括：

向服务器发送为第二服务请求端请求服务的服务请求，以及，向所述服务器请求获取服务信息，所述服务信息为所述服务请求对应的服务订单被执行过程中产生的；

在所述服务订单被服务提供端执行后，从所述服务器中获取所述服务信息。

在一种可能的实施方式中，所述向所述服务器请求获取服务信息，包括：

检测所述第一服务请求端的订单展示界面中的第一获取选项是否被触发，所述第一获取选项用于请求获取所述服务信息；

若检测到所述第一获取选项被触发，则将携带所述服务信息的获取请求信息的服务请求发送给所述服务器。

在一种可能的实施方式中，若检测到所述第一获取选项未被触发，还包括：

接收所述服务器发送的提示界面信息，所述提示界面信息用于提示是否请求获取所述服务信息；

在基于所述提示界面信息生成提示界面并展示后，检测所述提示界面中的第二获取选项是否被触发，所述第二获取选项用于请求获取所述服务信息；

若检测到所述第二获取选项被触发，则向所述服务器发送所述服务信息的获取请求信息。

在一种可能的实施方式中，所述方法还包括：

若检测到所述订单展示界面中的功能说明选项被触发，则向所述服务器发送功能说明获取请求；

接收所述服务器发送的功能说明界面信息，并展示基于所述功能说明界面信息生成的功能说明界面，其中，所述功能说明界面信息用于描述所述服务信息的获取方式。

在一种可能的实施方式中，所述方法还包括：

接收所述服务器发送的第一申请授权提示，所述第一申请授权提示用于提示在所述服务请求成功发送后所述服务器向所述第二服务请求端发送所述授权请求。

在一种可能的实施方式中，在向所述服务器请求获取服务信息之后，还包括：

接收所述服务器发送的第二申请授权提示，所述第二申请授权提示用于提示已向所述第二服务请求端发送所述授权请求。

在一种可能的实施方式中，在从所述服务器中获取所述服务信息之前，还包括：

接收所述服务器发送的授权成功提示，所述授权成功提示用于提示所述第二服务请求端已授权所述第一服务请求端获取所述服务信息。

在一种可能的实施方式中，从所述服务器中获取所述服务信息，包括：

在所述服务订单执行结束且结束时间超出所述第一设定时长之前，向所述服务器发送用于获取所述服务信息的获取请求；

接收所述服务器发送的所述服务信息。

在一种可能的实施方式中，所述方法还包括：

在所述服务订单执行结束且结束时间超出所述第一设定时长之后，接收所述服务器发送的禁止获取提示，所述禁止获取提示用于提示禁止获取所述服务信息；和/或，

在所述服务器的指示下隐藏用于获取所述服务信息的触发选项。

在一种可能的实施方式中，所述接收所述服务器发送的所述服务信息，包括：

接收所述服务器发送的所述服务信息以及所述服务信息的展示页面信息，其中所述展示页面信息包括所述服务信息的标识、生成时间、以及文件大小中的至少一种；

基于所述展示页面信息生成展示页面。

在一种可能的实施方式中，在基于所述展示页面信息生成展示页面之后，所述方法还包括：

在所述服务器的指示下更新所述展示页面中展示的内容。

在一种可能的实施方式中，所述服务信息包括录音内容。

第三方面，本申请实施例提供了一种服务信息获取装置，包括：

接收模块，用于接收第一服务请求端发送的为第二服务请求端请求服务的服务请求；

派单模块，用于派发所述服务请求对应的服务订单；

处理模块，用于若检测到所述第一服务请求端请求获取所述服务订单被执行过程中产生的服务信息，则在检测到所述服务订单被服务提供端执行后，从所述服务提供端中获取所述服务信息；

发送模块，用于将获取的所述服务信息通知给所述第一服务请求端。

其中，上述各模块的具体交互流程可参见第一方面或第一方面任一种可能的实施方式中涉及的内容。

第四方面，本申请实施例提供了一种服务信息获取装置，包括：

发送模块，用于向服务器发送为第二服务请求端请求服务的服务请求，以及，向所述服务器请求获取服务信息，所述服务信息为所述服务请求对应的服务订单被执行过程中产生的；

接收模块，用于在所述服务订单被服务提供端执行后，从所述服务器中获取所述服务信息。

其中，上述各模块的具体交互流程可参见第二方面或第二方面任一种可能的实施方式中涉及的内容。

第五方面，本申请实施例还提供一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行上述第一方面，或第一方面的任一种可能的实施方式中所述的服务信息获取方法的步骤。

第六方面，本申请实施例还提供一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行上述第二方面，或第二方面的任一种可能的实施方式中所述的服务信息获取方法的步骤。

第七方面，本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述第一方面，或第一方面的任一种可能的实施方式中所述的服务信息获取方法的步骤，或者，该计算机程序被处理器运行时执行上述第二方面，或第二方面的任一种可能的实施方式中所述的服务信息获取方法的步骤。

本申请提供的上述方式，服务器可以接收第一服务请求端为第二服务请求端请求服务的服务请求，并派发服务请求对应的服务订单，若检测到第一服务请求端请求获取服务信息，那么在服务订单处于被执行状态时，可以从服务提供端获取服务信息并及时通知给第一服务请求端，由此可以使得第一服务请求端可以及时获知代叫的服务订单的服务信息，及时获知服务订单执行过程中的状况，从而既可以有效避免安全隐患，也可以改善第三方用户的操作体验，提升用户体验度。

为使本申请实施例的上述目的、特征和优点能更明显易懂，下面将结合实施例，并配合所附附图，作详细说明。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它相关的附图。

图1示出了本申请实施例提供的一种服务系统的示意图；

图2示出了本申请实施例提供的服务信息获取方法的流程示意图；

图3示出了本申请实施例提供的检测到第一服务请求端请求获取服务信息的流程示意图一；

图4示出了本申请实施例提供的第一服务请求端的订单展示界面的示意图；

图5示出了本申请实施例提供的检测到第一服务请求端请求获取服务信息的流程示意图二；

图6示出了本申请实施例提供的第一服务请求端的等待接单界面的示意图；

图7示出了本申请实施例提供的第一服务请求端的录音内容的展示界面的示意图；

图8示出了本申请实施例提供的第一服务请求端的行程状态界面的示意图；

图9示出了本申请实施例提供的触发功能说明界面的交互流程示意图；

图10示出了本申请实施例提供的异常情况下第一服务请求端的行程状态界面的示意图；

图11示出了本申请实施例提供的服务信息获取装置的结构示意图一；

图12示出了本申请实施例提供的服务信息获取装置的结构示意图二；

图13示出了本申请实施例提供的电子设备的结构示意图一；

图14示出了本申请实施例提供的电子设备的结构示意图二。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。以下对本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其它实施例，都属于本申请保护的范围。

首先，对本申请可适用的应用场景进行说明。本申请实施例可适用在由第三方用户代替实际服务请求方向服务提供方请求某种服务的应用场景下。示例性的，本申请实施例可以适用在由第三方用户代替实际乘车人向司机请求乘车服务的场景下，或者，也可以适用在由第三方用户代替实际订餐人向外送员请求外送服务的场景下，或者，还可以适用在第三方用户代替实际寄件人向快递员请求寄件服务的场景下等。当然，在其它涉及到由第三方用户代替实际服务请求方来请求某种服务的场景下，均可以适用在本申请实施例中，本申请对此并不限定。

值得注意的是，在上述由第三方用户代替实际服务请求方来请求某种服务的场景下，由于第三方用户并不是实际的服务请求方，若想获知服务提供方提供服务过程中的实际服务状况，还需要自行联系实际的服务请求方或者服务提供方，这可能出现获取实际服务状况不及时或获取失败的问题，一方面可能会带来一定的安全隐患，如因服务提供方和第二服务提供方可能发生冲突而带来的安全隐患等，另一方面也可能影响第三方用户的操作体验，造成用户体验度较差。

针对上述问题，本申请实施例提供了一种服务信息获取方法及装置，服务器可以接收第一服务请求端为第二服务请求端请求服务的服务请求，并派发服务请求对应的服务订单，若检测到第一服务请求端请求获取服务信息，那么在服务订单处于被执行状态时，可以从服务提供端获取服务信息并及时通知给第一服务请求端，由此可以使得第一服务请求端可以及时获知代叫的服务订单的服务信息，及时获知服务订单执行过程中的状况，从而既可以有效避免安全隐患，也可以改善第三方用户的操作体验，提升用户体验度。

一示例中，在打车场景下，服务信息例如为行程录音，第一服务请求端在为第二服务请求端代叫乘车订单之后，服务器可以在服务提供端执行乘车订单期间，从服务提供端获取行程录音，由此可以使第一服务请求端能实时关注订单信息，从而能够有效避免服务过程中出现的安全隐患，也能提升用户体验度。

在介绍本申请提供的具体实施例之前，首先对本申请实施例中应用到的相关术语以及本申请实施例可适用的服务系统进行说明。

(1)本申请中的术语“第一服务请求方”、“第三方用户”、或“代叫方”可互换使用，“第一服务请求端”、“第三方用户终端”、或“代叫方端”可互换使用，用于指代能够代替实际服务请求方来请求或订购服务的个人、实体设备或工具等。

(2)本申请中的术语“第二服务请求方”、“服务实际需求者”或者“实际服务请求方”可互换使用，“第二服务请求端”或者“实际服务请求端”可互换使用，用于指代实际具有服务需求并接受服务的个人、实体设备或工具等。一示例中，在打车场景下，第二服务提供方为乘客，第二服务提供端为乘车使用的终端。

(3)本申请中的术语“服务提供方”或“服务提供端”，用于指代可以提供服务的个人、实体或工具。一示例中，在打车场景下，服务提供方为司机，服务提供端为司机使用的终端。

(4)本申请中的术语“服务订单”，为基于第一服务请求端发送的服务请求中包括的信息而生成服务订单，随着服务场景的不同，服务订单的类型也不相同，例如服务订单可以是乘车订单、外送订单、寄件订单等，本申请对此并不限定。另外，针对同一服务场景，服务订单的类型也有所区分，例如，在打车场景下，乘车订单包括但不限于如下几种订单类型：快车订单、出租车订单、专车订单、顺风车订单、拼车订单。

(5)本申请中的术语“服务信息”，随着服务场景和服务订单的不同，服务信息也有所区别。一示例中，在打车场景下，服务订单为乘车订单，那么服务信息例如为乘车订单执行过程中产生的录音内容。

另外，需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。本申请实施例中将会用到“第一”、“第二”等序数词，仅起到区分一些技术特征的目的，并不暗示前后顺序、优先级或者重要程度等。

参照图1所示，为本申请实施例提供的一种服务系统的示意图。示例性的，服务系统可以是诸如出租车、代驾服务、快车、拼车、公共汽车服务、驾驶员租赁、或班车服务之类的运输服务、或其任意组合的在线运输服务平台。在本申请实施例的应用场景下，服务系统100可以包括服务器110、网络120、第一服务请求端130、服务提供端140、数据库150和第二服务请求端160中的一种或多种，服务器110中可以包括执行指令操作的处理器。

服务器110可以是单个服务器，也可以是服务器组。服务器组可以是集中式的，也可以是分布式的(例如，服务器110可以是分布式系统)。在一些实施例中，服务器110相对于上述几种终端，可以是本地的、也可以是远程的。一示例中，服务器110可以经由网络120访问存储在第一服务请求端130、服务提供端140、数据库150、或第二服务请求端160、或其任意组合中的信息和/或数据。另一示例中，服务器110可以直接连接到第一服务请求端130、服务提供端140、数据库150和第二服务请求端160中的至少一个，以访问存储的信息和/或数据。

网络120可以用于信息和/或数据的交换。在一些实施例中，服务系统100中的一个或多个组件(例如，服务器110，第一服务请求端130，服务提供端140、数据库150、第二服务请求端160)可以向其它组件发送信息和/或数据。例如，服务器110可以经由网络120从第一服务请求端130获取服务请求。在一些实施例中，网络120可以是任何类型的有线或者无线网络，或者是它们的结合，本申请对此并不限定。

第一服务请求端130可以是代替服务实际需求者来发送服务请求的终端。第二服务请求端160可以是服务实际需求者使用的终端。示例性的，第一服务请求端130的用户a可以使用第一服务请求端130来为服务实际需求者b(即第二服务请求端160)发起服务请求，例如，用户a可以为服务实际需求者b发起乘车请求，第一服务请求端130也可以从服务器110接收服务信息或指令等。

服务提供端140可以是与第一服务请求端130或第二服务请求端160类似或相同的设备。在一些实施例中，服务提供端140还可以用于采集服务订单执行过程中产生的服务信息，并将采集的服务信息发送给服务器110，例如，服务提供端140可以采集订单执行过程中的录音内容，并将采集的录音内容发送给服务器110。在一些实施例中，服务提供端140可以是具有定位技术的设备，可以定位第二服务提供方和/或服务提供端的位置，并将定位信息发送给服务器110。

数据库150可以存储数据和/或指令。在一些实施例中，数据库150可以存储从第一服务请求端130、第二服务请求端160和/或服务提供端140获得的数据，也可以存储在本申请中描述的示例性方法的数据和/或指令。在一些实施例中，服务系统100中的一个或多个组件可以经由网络120访问存储在数据库150中的数据或指令。在一些实施例中，数据库150也可以是服务器110的一部分。

结合上述应用场景、本申请使用的术语以及本申请提供的服务系统的描述，下面对本申请实施例提供的服务信息获取方法进行详细说明。

参照图2所示，为本申请实施例提供的服务信息获取方法的流程示意图，该流程图中描述了服务器与服务系统中的第一服务请求端、第二服务请求端、服务提供端之间在执行服务信息获取方法时的交互流程，包括如下步骤：

步骤201、第一服务请求端向服务器发送为第二服务请求端请求服务的服务请求。

其中，服务请求中携带有第二服务请求端的联系信息、以及所请求的服务内容等信息。联系信息例如包括第二服务请求方的姓名或手机号等，以便服务提供端接单之后可以与第二服务提供端取得联系。所请求的服务内容例如包括服务类型、具体服务事项中的至少一种，以打车场景为例，服务类型可以为代叫车服务，具体服务事项例如包括起始位置、目的位置等信息。

步骤202、服务器接收第一服务请求端发送的为第二服务请求端请求服务的服务请求，并派发服务请求对应的服务订单。

在一些实施例中，服务器在接收到服务请求后，可以基于服务请求中携带的信息，生成服务请求对应的服务订单并派发给服务提供端。并且，服务器在识别出第一服务请求端所请求的服务是为第二服务请求端请求的，也就是说，第一服务请求端所请求的服务为代叫服务，那么可以执行后续步骤，以进一步确定是否需要向第一服务请求端提供服务订单被执行过程中产生的服务信息。

步骤203、服务器检测到第一服务请求端请求获取服务订单被执行过程中产生的服务信息。

其中，服务信息为服务订单被执行过程中产生的，例如包括执行服务订单过程中的录音内容等。以打车场景为例，考虑到服务提供端(即司机)在接单之后需要将第二服务提供端(即乘客)由起始位置送到目的位置，故在送乘车去往目的位置的行程中，可以采集行程中的录音内容，以便使用第一服务请求端的第三方用户能够通过获取录音内容来了解行程状况。

需要说明的是，步骤202和步骤203在具体实施中可以不分先后，也就是说，服务器检测到第一服务请求端请求获取服务订单既可以在接收服务请求时检测，也可以在接收到服务请求后并开始派发服务订单的过程中检测。

在一些实施例中，服务器检测到第一服务请求端请求服务信息的方式包括但不限于以下实施方式：

实施方式一、在接收服务请求时检测到第一服务请求端请求获取服务信息。

具体检测过程参照图3所示的流程示意图，包括如下步骤：

步骤301、第一服务请求端检测第一服务请求端的订单展示界面中的第一获取选项是否被触发，第一获取选项用于请求获取服务信息。

其中，在订单展示界面上可以由第三方用户输入第二服务请求端的联系信息、以及所请求的服务内容等信息。并且，订单展示界面上还可以配置有第一获取选项，以便第三方用户选择是否请求获取服务信息。

步骤302、第一服务请求端若检测到第一获取选项被触发，则将携带服务信息的获取请求信息的服务请求发送给服务器。

步骤303、服务器接收服务请求并确定接收的服务请求中携带有服务信息的获取请求信息。

示例性的，以代叫车服务为例，服务订单即为代叫车订单，服务请求即为代叫车请求，第一服务请求端的订单展示界面如图4所示，订单展示界面400可以包括乘车人信息填写区域401、个性化选项区域402、服务请求触发选项403，其中，乘车人信息填写区域401中可以用于填写乘车人信息，也就服务实际需求者的信息，例如可以填写乘车人姓名、联系方式等；个性化选项区域402中设置有第一获取选项4021。此外，订单展示界面400还可以包括服务内容填写区域404，用于填写服务内容，例如包括乘车起始位置，乘车目的位置等。

若第一服务请求端检测到第一获取选项4021被触发，可以确定需要请求获取服务信息，在进一步检测到服务请求触发选项403被触发后，可以向服务器发送服务请求，其中携带有服务信息的获取请求信息。

实施方式二、在接收到服务请求后并开始派发服务订单的过程中检测到第一服务请求端请求获取服务信息。

具体检测过程参照图5所示的流程示意图，包括如下步骤：

步骤501、服务器若确定接收的服务请求中未携带有服务信息的获取请求信息，则向第一服务请求端发送提示界面信息，提示界面信息用于提示是否请求获取服务信息。

步骤502、第一服务请求端接收服务器发送的提示界面信息后，基于提示界面信息生成提示界面并展示。

步骤503、第一服务请求端检测提示界面中的第二获取选项是否被触发，第二获取选项用于请求获取服务信息。

步骤504、第一服务请求端若检测到第二获取选项被触发，则向服务器发送服务信息的获取请求信息。

步骤505、服务器在接收到服务信息的获取请求信息后，确定第一服务请求端请求获取服务信息。

此外，如果在服务订单被服务提供端执行后，如果服务器仍未接收到第一服务请求端针对提示界面信息发送的服务信息的获取请求信息，则服务器还可以指示第一服务请求端取消展示基于提示界面信息生成的提示界面。

示例性的，继续沿用上例，以代叫车服务为例，服务订单即为代叫车订单，服务器在接收到服务请求并派发服务请求对应的服务订单期间，第一服务请求端的显示界面中可以展示等待接单界面，参照图6所示，等待接单界面600中显示有地图信息，其中地图信息中例如可以显示乘车起始点位置p。如果第一服务请求端在发起服务请求时，订单展示界面400中的第一获取选项4021未被触发，那么在第一服务请求端跳转到等待接单界面600中后，服务器可以推送提示界面信息，相应地，第一服务请求端可以基于提示界面信息生成提示界面601，其中提示界面601的展示方式例如采用半屏弹窗的方式，这样提示界面601和等待接单界面600可以同时显示在显示界面中。提示界面601中包括提示信息区域6011和选择区域6012，选择区域中包括第二获取选项6013，还可以包括不获取选项6014。其中，提示信息区域6011显示的提示信息例如为“您是否需要获取服务信息？”。若第一服务请求端检测到第二获取选项6013被触发，则可以向服务器发送服务信息的获取请求信息。

上述两种实施方式中，实施方式一中可以由第三方用户在发起服务请求的过程中自主地选择是否请求获取服务信息，如果第三方用户在发起服务请求的过程中没有选择请求获取服务信息，那么还可以启用上述实施方式二中，服务器对第一服务请求端进行再次提示，以便第一服务请求端确认是否需要获取服务信息。

在一些实施例中，服务器是否允许向第一服务请求端提供服务信息，还可以向第二服务提供端申请授权。具体授权过程如下述步骤：

步骤204、服务器向第二服务请求端发送授权请求，其中，授权请求用于请求授权第一服务请求端获取服务信息。

示例性的，服务器发送授权请求的方式包括但不限于短信、邮件、客户端内推送消息等。

示例性的，以代叫车服务为例，若采用短信方式来向第二服务请求端发送授权请求，那么短信内容例如为“您好，为了更好地关注您的行程状态，<代叫方>为您代叫的订单中向您发起了【获取服务信息】的授权请求。同意授权请回复1，不同意授权无需回复。”

步骤205、服务器接收第二服务请求端回复的同意授权指示。

步骤206、服务器向第一服务请求端发送第一授权成功提示。

步骤207、服务器向第二服务请求端发送第二授权成功提示。

步骤208、服务器向服务提供端发送第三授权成功提示。

其中，上述步骤206至步骤208在执行顺序上可以不分先后，第一授权成功提示和第二授权成功提示用于提示第一服务请求端和第二服务请求端授权生效，第三授权成功提示用于提示在服务订单被执行过程中上报服务信息。

服务器发送上述三种授权成功提示的方式包括但不限于短信、邮件、在客户端内推送消息等。

示例性的，以代叫车服务为例，以服务信息为录音内容为例，服务器向第一服务请求端发送的第一授权成功提示，提示内容例如为“乘车人已同意授权，您可以在行程开始后获取行程录音。”；服务器向第二服务请求端发送的第二授权成功提示，提示内容例如为“您已同意<代叫方>向您发起的【获取行程录音】的授权请求，代叫方可以在行程结束30分钟之内听取行程录音。”；服务器向服务提供端发送的第三授权成功提示，提示内容例如为“代叫方已成功授权获取行程录音，行程开始后需要上报行程录音。”。

需要说明的是，上述授权流程是可选的，具体实施中可以根据实际需求来确定是否需要上述授权流程。并且，对于授权成功后的提示过程也是可选的，同样可以根据实际需求来配置，本申请对此并不限定。

步骤209、服务器在检测到服务订单被服务提供端执行后，从服务提供端中获取服务信息。

在一些实施例中，服务器确定服务订单被服务提供端执行的方式有多种。示例性的，以打车场景为例，在将服务订单派发给司机使用的服务提供端之后，要执行接单、接驾、乘客上车后确认行程开始的流程。一种可能的实施方式中，服务提供端在确认接单之后，服务器可以确定服务订单被服务提供端执行，另一种可能的实施方式中，司机在确认乘客上车后可以点击服务提供端中展示的行程开始选项，服务提供端在确认行程开始选项被触发后，可以向服务器发送行程开始指示，服务器在接收到行程开始指示后，确定服务订单被服务提供端执行。当然，实际应用中并不限定于上述示例中给出的方式，在其它应用场景下，服务提供端还可以采用其他方式来指示服务订单被执行，本申请对此并不限定。

在一些实施例中，在向服务提供端获取服务信息之前，首先要确认服务提供端已开启上传服务信息的功能。示例性的，如果服务信息为录音内容，那么在服务提供端开始接单之前，服务器可以指示服务提供端开启录音功能，并指示服务提供端授权服务器获取录音内容。另外，需要说明的是，在一些应用场景下，服务器也可以向第二服务请求端(即实际接受服务方的终端)获取服务信息，具体获取方式与上述从服务提供端中获取服务信息的方式类似，这里不再展开说明。

在一些实施例中，服务器在向服务提供端获取服务信息的过程中，可以每隔设定时间段采集该设定时间段内产生的服务信息，并可以在每次采集到设定时间段内的服务信息之后，缓存在数据库中或者通知给第一服务请求端。

步骤210、在服务器在服务订单执行结束且结束时间超出第一设定时长之前，第一服务请求端向服务器发送用于获取服务信息的获取请求。

步骤211、服务器接收到获取请求后，将从服务提供端获取的服务信息通知给第一服务请求端。

示例性的，服务器在将服务信息通知给第一服务请求端的过程中，具体可以向第一服务请求端发送服务信息以及服务信息的展示页面信息，其中，展示页面信息包括但不限于服务信息的标识、生成时间、以及文件大小等中的至少一种。

相应地，第一服务请求端在接收到展示界面信息后，可以基于展示界面信息生成服务信息的展示界面。其中，服务信息的展示界面中可以展示服务信息的标识、生成时间、以及文件大小等中的至少一种。例如，第一服务请求端若检测到第一服务请求方选中了某个服务信息的标识之后，可以将选中的服务信息的标识匹配的服务信息提供给第一服务请求方。

具体实施中，服务器若每隔设定时间段从服务提供端中获取设定时间段的服务信息，那么在每次获取到设定时间段内的服务信息之后，还可以更新服务信息的展示页面信息，并将更新后的展示页面信息通知给第一服务请求端，以便第一服务请求端更新更新展示页面中展示的内容。

示例性的，参照图7所示，以代叫车服务为例，假设服务信息为录音内容，那么录音内容的展示界面700中可以展示每隔设定时间段(例如5分钟)采集到的录音内容的信息，例如包括“录音内容a”、“录音内容b”、“录音内容c”、“录音内容d”，且可以展示每段录音内容的生成时间和文件大小，例如在“录音内容a”的下方展示生成时间为“2019/1/107:00至7:05”、文件大小为5m，在“录音内容b”的下方展示生成时间为“2019/1/107:05至7:10”、文件大小为5m，以此类推。

此外，录音内容的展示界面700中还可以展示录音状态，例如服务器仍在获取行程中的录音内容，那么录音内容的展示界面700中还可以展示录音状态“行程持续录音中”。另外，如果服务器中断获取行程中的录音内容时，那么录音内容的展示界面700中展示的录音状态可以变更为“行程录音停止”。

步骤212、服务器在服务订单执行结束且结束时间超出第一设定时长之后，向第一服务请求端发送禁止获取提示，禁止获取提示用于提示禁止获取服务信息。

在一些实施例中，考虑到服务信息的时效性、以及保障服务提供方和第二服务请求方的隐私，可以仅允许第一服务请求端在服务订单执行结束且结束时间超出第一设定时长之前具有获取服务信息的权限。

示例性的，可以在第一服务请求端的展示界面中展示获取服务信息的触发选项，该触发选项仅在规定时间段内生效，本申请实施例中规定时间段即为在服务订单执行结束且结束时间超出第一设定时长之前对应的时间段。在规定时间段内，第一服务请求端具备获取服务信息的权限，第三方用户可以使用第一服务请求端选中该触发选项，进而第一服务请求端可以向服务器发送获取请求。

进一步地，当超出规定时间段之后，第一服务请求端不具备获取服务信息的权限，这种情况下，服务器提示第一服务请求端禁止获取服务信息。在一些实施例中，服务器还可以指示第一服务请求端隐藏用于获取服务信息的触发选项，或者，指示该触发选项失效，由此禁止第一服务请求端发起获取服务信息的流程。

示例性的，以代叫车服务为例，服务订单即为代叫车订单，服务信息例如为录音内容，服务提供端在接单后，服务提供端和第一服务请求端中可以展示行程状态界面。参照图8所示，行程状态界面800中包括行程导航区域801，行程导航区域801中包括车辆当前行驶位置、以及与乘车目的位置之间的导航路径等。行程状态界面800中还包括行程状态展示区域802，例如可以展示行程状态为“行程中”，还包括服务提供端的信息区域803，可以展示服务提供端驾驶的车辆的车牌号、车型号、外观、司机名称、评价值、接单数量中的一种或多种。

行程状态界面800中还可以包括触发选项804，该触发选项804在上述规定时间段内生效，该触发选项804生效时，可以展示为“听取行程录音”，该触发选项804被触发时，可以展示上述图7中所示的录音内容的展示界面700。

上述实施流程中描述了服务器与服务系统中的第一服务请求端、第二服务请求端、服务提供端之间在执行服务信息获取方法时的大体交互流程。通过上述实施流程，第一服务请求端可以及时获知代叫的服务订单的服务信息，及时获知服务订单执行过程中的状况，从而既可以有效避免安全隐患，也可以改善第三方用户的操作体验，提升用户体验度。

在一些实施例中，在服务器和第一服务请求端之间的交互流程中还可以增加一些提示内容，以便进一步提升用户体验度。

一示例中，服务器在接收到服务信息的获取请求信息并确定第一获取选项被触发后，还可以向第一服务请求端发送第一申请授权提示，第一申请授权提示用于提示在服务请求成功发送后服务器向第二服务请求端发送授权请求。由此可以提示第三方用户在发起服务请求后还需要进行授权流程。

又一示例中，服务器在向第二服务请求端发送授权请求之后，还可以向第一服务请求端发送第二申请授权提示，第二申请授权提示用于提示已向第二服务请求端发送授权请求。

在一些实施例中，考虑到第三方用户可能不太了解获取服务信息的具体操作流程，故第一服务请求端的订单展示界面中还可以配置有功能说明选项，该功能说明选项被触发时，第一服务请求端中可以展示服务信息的获取方式，以便告知第三方用户服务信息的获取方式。具体交互流程可参照图9所示：

步骤901、第一服务请求端若检测到订单展示界面中的功能说明选项被触发，则向服务器发送功能说明获取请求。

步骤902、服务器向第一服务请求端发送功能说明界面信息，功能说明界面信息用于描述服务信息的获取方式。

步骤903、第一服务请求端接收服务器发送的功能说明界面信息，并展示基于功能说明界面信息生成的功能说明界面。

其中，功能说明界面信息的具体内容可以根据不同的服务场景和服务信息的不同进行适应性配置，本申请对此并不限定。

在一些实施例中，考虑到在服务订单的执行过程中可能会遇到一些异常情况，这种情况下为了有效避免一些可能出现的安全隐患，本申请中还可以在异常情况下对第一服务请求方进行提示。

下面列举几种实施场景下的异常情况提示流程。

实施场景一、在服务订单被执行的过程中，若在第二设定时长内无法从服务提供端中获取服务信息，则向第一服务请求端发送第一异常提示，第一异常提示用于提示服务信息获取失败。

示例性的，以服务信息为录音内容为例，如果在服务订单被执行过程中，服务器检测到服务提供端关闭了麦克风权限，且关闭时长超出第二设定时长，那么服务器无法成功获取到录音内容，这时，服务器可以向第一服务请求端发送第一异常提示。

一示例中，若服务订单被执行过程中，第一服务请求端可以展示图8所示的行程状态界面800，那么在接收到第一异常提示之后，可以参照图10所示，在行程状态界面800中展示第一异常提示框805，第一异常提示框805中可以展示“行程录音已关闭，请及时联系乘车人确认行程”。

实施场景二、若检测到服务订单提前执行结束，则向第一服务请求端发送第二异常提示，第二异常提示用于提示查看服务信息。

一示例中，以代叫车服务为例，服务订单即为代叫车订单，若检测到服务提供端未到达代叫车订单中规定的乘车目的位置，或者，在预计到达时间之前提前较长时间便结束服务订单，可以确定服务订单提前执行结束。该场景下，服务器发送的第二异常提示例如为“行程提前结束，请及时联系乘车人确认行程”。

实施场景三、若检测到服务订单执行过程中的行程位置在第三设定时长内未发生变化，则向第一服务请求端发送第二异常提示，第二异常提示用于提示查看服务信息。

一示例中，以代叫车服务为例，服务订单即为代叫车订单，若检测到服务提供端的行程位置停留在某个位置较长时间，可以确定服务订单出现异常。该场景下，服务器发送的第二异常提示例如为“行程出现异常停留，请及时联系乘车人确认行程”。

基于同一技术构思，本申请实施例中还提供了与服务信息获取方法对应的服务信息获取装置，由于本申请实施例中的装置解决问题的原理与本申请实施例上述服务信息获取方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

参见图11所示，为本申请实施例提供的服务信息获取装置的结构示意图一，该装置1100包括：接收模块1101、派单模块1102、处理模块1103、以及发送模块1104，具体的：

接收模块1101，用于接收第一服务请求端发送的为第二服务请求端请求服务的服务请求；

派单模块1102，用于派发所述服务请求对应的服务订单；

处理模块1103，用于若检测到所述第一服务请求端请求获取所述服务订单被执行过程中产生的服务信息，则在检测到所述服务订单被服务提供端执行后，从所述服务提供端中获取所述服务信息；

发送模块1104，用于将获取的所述服务信息通知给所述第一服务请求端。

一种可能的设计中，所述发送模块1104，还用于：

在所述处理模块1103检测到所述第一服务请求端请求获取所述服务订单被执行过程中产生的服务信息之后，向所述第二服务请求端发送授权请求，其中，所述授权请求用于请求授权所述第一服务请求端获取所述服务信息；

所述接收模块1101，还用于：

在所述处理模块1103从所述服务提供端中获取所述服务信息之前，接收所述第二服务请求端回复的同意授权指示。

一种可能的设计中，所述处理模块1103，在检测所述第一服务请求端请求获取所述服务订单被执行过程中产生的服务信息时，具体用于：

确定接收的所述服务请求中携带有所述服务信息的获取请求信息。

一种可能的设计中，所述发送模块1104，还用于：

若所述处理模块1103确定接收的所述服务请求中未携带有所述服务信息的获取请求信息，则所述发送模块1104向所述第一服务请求端发送提示界面信息，所述提示界面信息用于提示是否请求获取所述服务信息；

所述接收模块1101，还用于：

接收所述第一服务请求端针对所述提示界面信息发送的所述服务信息的获取请求信息。

一种可能的设计中，所述发送模块1104，在向所述第一服务请求端发送提示界面信息之后，还用于：

若在所述服务订单被所述服务提供端执行后，所述接收模块1101仍未接收到所述第一服务请求端针对所述提示界面信息发送的所述服务信息的获取请求信息，则所述发送模块1104指示所述第一服务请求端取消展示基于所述提示界面信息生成的提示界面。

一种可能的设计中，所述接收模块1101，还用于：

接收所述第一服务请求端发送的功能说明获取请求；

所述发送模块1104，还用于：

向所述第一服务请求端发送功能说明界面信息，所述功能说明界面信息用于描述所述服务信息的获取方式。

一种可能的设计中，所述发送模块1104，还用于：

向所述第一服务请求端发送第一申请授权提示；

其中，所述第一申请授权提示用于提示在所述服务请求成功发送后所述服务器向所述第二服务请求端发送所述授权请求。

一种可能的设计中，所述发送模块1104，在向所述第二服务请求端发送授权请求之后，还用于：

向所述第一服务请求端发送第二申请授权提示，所述第二申请授权提示用于提示已向所述第二服务请求端发送所述授权请求。

一种可能的设计中，所述发送模块1104，还用于：

在所述接收模块1101接收所述第二服务请求端回复的同意授权指示之后，向所述第一服务请求端发送第一授权成功提示，以及，向所述第二服务请求端发送第二授权成功提示。

一种可能的设计中，所述发送模块1104，还用于：

在所述接收模块1101接收到所述第二服务请求端回复的同意授权指示之后，向所述服务提供端发送第三授权成功提示，所述第三授权成功提示用于提示在所述服务订单被执行过程中上报所述服务信息。

一种可能的设计中，所述发送模块1104，在将获取的所述服务信息通知给所述第一服务请求端时，具体用于：

在所述服务订单执行结束且结束时间超出所述第一设定时长之前，若所述处理模块1103检测到所述第一服务请求端发送用于获取所述服务信息的获取请求，则所述发送模块1104将获取的所述服务信息通知给所述第一服务请求端。

一种可能的设计中，所述发送模块1104，还用于：

在所述服务订单执行结束且结束时间超出所述第一设定时长之后，向所述第一服务请求端发送禁止获取提示，所述禁止获取提示用于提示禁止获取所述服务信息；和/或，

指示所述第一服务请求端隐藏用于获取所述服务信息的触发选项。

一种可能的设计中，所述发送模块1104，在将获取的所述服务信息通知给所述第一服务请求端时，具体用于：

向所述第一服务请求端发送所述服务信息以及所述服务信息的展示页面信息，其中，所述展示页面信息包括所述服务信息的标识、生成时间、以及文件大小中的至少一种。

一种可能的设计中，所述处理模块1103，还用于：

每隔设定时间段从所述服务提供端中获取所述设定时间段的服务信息，更新所述服务信息的展示页面信息；

所述发送模块1104，还用于：

将更新后的展示页面信息通知给所述第一服务请求端。

一种可能的设计中，所述发送模块1104，还用于：

在所述服务订单被执行的过程中，若所述处理模块1103检测到在第二设定时长内无法从所述服务提供端中获取所述服务信息，则所述发送模块1104向所述第一服务请求端发送第一异常提示；

其中，所述第一异常提示用于提示所述服务信息获取失败。

一种可能的设计中，所述发送模块1104，还用于：

若所述处理模块1103检测到所述服务订单提前执行结束，或检测到所述服务订单执行过程中的行程位置在第三设定时长内未发生变化，则所述发送模块1104向所述第一服务请求端发送第二异常提示；

其中，所述第二异常提示用于提示查看所述服务信息。

一种可能的设计中，所述服务信息包括录音内容。

其中，上述各个模块的交互过程，参照上述方法实施例的记载，这里不再赘述。

通过上述装置，可以使得第一服务请求端可以及时获知代叫的服务订单的服务信息，及时获知服务订单执行过程中的状况，从而既可以有效避免安全隐患，也可以改善第三方用户的操作体验，提升用户体验度。

参见图12所示，为本申请实施例提供的服务信息获取装置1200的结构示意图二，该装置1200包括：发送模块1201、接收模块1202、以及处理模块1203，具体的：

发送模块1201，用于向服务器发送为第二服务请求端请求服务的服务请求，以及，向所述服务器请求获取服务信息，所述服务信息为所述服务请求对应的服务订单被执行过程中产生的；

接收模块1202，用于在所述服务订单被服务提供端执行后，从所述服务器中获取所述服务信息。

一种可能的设计中，所述装置还包括：

处理模块1203，用于检测所述第一服务请求端的订单展示界面中的第一获取选项是否被触发，所述第一获取选项用于请求获取所述服务信息；

所述发送模块1201，在向所述服务器请求获取服务信息时，具体用于：

若所述处理模块1203检测到所述第一获取选项被触发，则所述发送模块1201将携带所述服务信息的获取请求信息的服务请求发送给所述服务器。

一种可能的设计中，所述接收模块1202，还用于：

若所述处理模块1203检测到所述第一获取选项未被触发，接收所述服务器发送的提示界面信息，所述提示界面信息用于提示是否请求获取所述服务信息；

所述处理模块1203，还用于：

在基于所述提示界面信息生成提示界面并展示后，检测所述提示界面中的第二获取选项是否被触发，所述第二获取选项用于请求获取所述服务信息；

所述发送模块1201，还用于：

若所述处理模块1203检测到所述第二获取选项被触发，则所述发送模块1201向所述服务器发送所述服务信息的获取请求信息。

一种可能的设计中，所述发送模块1201，还用于：

若所述检测模块检测到所述订单展示界面中的功能说明选项被触发，则所述发送模块1201向所述服务器发送功能说明获取请求；

所述接收模块1202，还用于：

接收所述服务器发送的功能说明界面信息，并展示基于所述功能说明界面信息生成的功能说明界面，其中，所述功能说明界面信息用于描述所述服务信息的获取方式。

一种可能的设计中，所述接收模块1202，还用于：

接收所述服务器发送的第一申请授权提示，所述第一申请授权提示用于提示在所述服务请求成功发送后所述服务器向所述第二服务请求端发送所述授权请求。

一种可能的设计中，所述接收模块1202，还用于：

在所述发送模块1201向所述服务器请求获取服务信息之后，接收所述服务器发送的第二申请授权提示，所述第二申请授权提示用于提示已向所述第二服务请求端发送所述授权请求。

一种可能的设计中，所述接收模块1202，还用于：

在从所述服务器中获取所述服务信息之前，接收所述服务器发送的授权成功提示，所述授权成功提示用于提示所述第二服务请求端已授权所述第一服务请求端获取所述服务信息。

一种可能的设计中，所述发送模块1201，具体用于：

在所述服务订单执行结束且结束时间超出所述第一设定时长之前，向所述服务器发送用于获取所述服务信息的获取请求；

所述接收模块1202，具体用于：

接收所述服务器发送的所述服务信息。

一种可能的设计中，所述接收模块1202，还用于：

在所述服务订单执行结束且结束时间超出所述第一设定时长之后，接收所述服务器发送的禁止获取提示，所述禁止获取提示用于提示禁止获取所述服务信息；和/或，

所述处理模块1203，还用于：

在所述服务器的指示下隐藏用于获取所述服务信息的触发选项。

一种可能的设计中，所述接收模块1202，在接收所述服务器发送的所述服务信息时，具体用于：

接收所述服务器发送的所述服务信息以及所述服务信息的展示页面信息，其中所述展示页面信息包括所述服务信息的标识、生成时间、以及文件大小中的至少一种；

所述处理模块1203，还用于：

基于所述展示页面信息生成展示页面。

一种可能的设计中，所述处理模块1203，在基于所述展示页面信息生成展示页面之后，还用于：

在所述服务器的指示下更新所述展示页面中展示的内容。

一种可能的设计中，所述服务信息包括录音内容。

其中，上述各个模块的交互过程，参照上述方法实施例的记载，这里不再赘述。

通过上述装置，可以有效避免安全隐患，也可以改善第三方用户的操作体验，提升用户体验度。

参见图13所示，为本申请实施例提供的一种电子设备的结构示意图一，该电子设备130包括：处理器131、存储器132和总线133；

所述存储器132存储有所述处理器131可执行的机器可读指令(比如，图11中的接收模块1101、派单模块1102、处理模块1103、以及发送模块1104对应的执行指令等)，当电子设备130运行时，所述处理器131与所述存储器132之间通过总线133通信，所述机器可读指令被所述处理器131执行时执行如下处理：

接收第一服务请求端发送的为第二服务请求端请求服务的服务请求，并派发所述服务请求对应的服务订单；

若检测到所述第一服务请求端请求获取所述服务订单被执行过程中产生的服务信息，则在检测到所述服务订单被服务提供端执行后，从所述服务提供端中获取所述服务信息；

将获取的所述服务信息通知给所述第一服务请求端。

其中，处理器131的具体处理流程可以参照上述方法实施例的记载，这里不再赘述。

参见图14所示，为本申请实施例提供的一种电子设备的结构示意图，该电子设备140包括：处理器141、存储器142和总线143；

所述存储器142存储有所述处理器141可执行的机器可读指令(比如，图12中的发送模块1201、以及接收模块1202对应的执行指令等)，当电子设备140运行时，所述处理器141与所述存储器142之间通过总线143通信，所述机器可读指令被所述处理器141执行时执行如下处理：

服务器发送为第二服务请求端请求服务的服务请求，以及，向所述服务器请求获取服务信息，所述服务信息为所述服务请求对应的服务订单被执行过程中产生的；

在所述服务订单被服务提供端执行后，从所述服务器中获取所述服务信息。

其中，处理器141的具体处理流程可以参照上述实施例的记载，这里不再赘述。

基于相同的技术构思，本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述服务信息获取方法的步骤。

具体地，该存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的计算机程序被运行时，能够执行上述服务信息获取方法，以避免安全隐患，改善第三方用户的操作体验，提升用户体验度。

基于相同的技术构思，本申请实施例还提供了一种计算机程序产品，包括存储了程序代码的计算机可读存储介质，程序代码包括的指令可用于执行上述服务信息获取方法的步骤，具体实现可参见上述方法实施例，在此不再赘述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。