一种服务履约信息展示方法、系统和介质与流程

1.本技术涉及计算机技术领域，特别涉及一种服务履约信息展示方法和系统。


背景技术：

2.随着互联网技术的蓬勃发展，人们逐渐习惯通过网络来签订各种行业场景的服务订单。人们还可以通过用户端展示的服务履约信息，获取服务订单的被执行状态。然而，不同行业场景的服务订单有不同的较优展示时机。
3.因此，希望提供一种服务履约信息展示方法、系统和介质，可以控制不同行业场景的服务订单对应的展示时机，从而提高用户体验。


技术实现要素：

4.本说明书一个方面提供一种服务履约信息展示方法，所述方法包括：获取服务履约信息；所述服务履约信息与服务订单对应且包含与服务订单相关的信息项；确定服务履约信息的状态信息；所述状态信息至少用于指示有效不可展示或有效可展示；响应于用户对用户端的预设操作，将状态信息指示有效可展示的服务履约信息推送给用户端，以便所述用户端展示；和/或，响应于所述用户对所述用户端的预设操作，判断所述状态信息指示有效不可展示的服务履约信息的信息项包含的位置信息与所述用户端当前所在的位置信息是否匹配，并将判断结果为匹配的服务履约信息推送给所述用户端，以便所述用户端展示。
5.本说明书另一个方面提供一种服务履约信息展示系统，所述系统包括：服务履约信息获取模块，用于获取服务履约信息；所述服务履约信息与服务订单对应且包含与服务订单相关的信息项；状态信息确定模块，用于确定服务履约信息的状态信息；所述状态信息至少用于指示有效不可展示或有效可展示；服务履约信息推送模块，用于响应于用户对用户端的预设操作，将状态信息指示有效可展示的服务履约信息推送给用户端，以便所述用户端展示；和/或，响应于所述用户对所述用户端的预设操作，判断所述状态信息指示有效不可展示的服务履约信息的信息项包含的位置信息与所述用户端当前所在的位置信息是否匹配，并将判断结果为匹配的服务履约信息推送给所述用户端，以便所述用户端展示。
6.本说明书另一个方面提供一种计算机可读存储介质，其特征在于，所述存储介质存储计算机指令，当所述计算机指令被处理器执行时实现服务履约信息展示的方法。
附图说明
7.本说明书将以示例性实施例的方式进一步说明，这些示例性实施例将通过附图进行详细描述。这些实施例并非限制性的，在这些实施例中，相同的编号表示相同的结构，其中：
8.图1是根据本说明书一些实施例所示的服务履约信息展示系统的应用场景示意图；
9.图2是根据本说明书一些实施例所示的服务履约信息展示方法的示例性流程图；
10.图3是根据本说明书一些实施例所示的服务履约信息的状态信息更新的示意图。
具体实施方式
11.为了更清楚地说明本说明书实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本说明书的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本说明书应用于其它类似情景。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。
12.应当理解，本说明书中所使用的“系统”、“装置”、“单元”和/或“模组”是用于区分不同级别的不同组件、元件、部件、部分或装配的一种方法。然而，如果其他词语可实现相同的目的，则可通过其他表达来替换所述词语。
13.如本说明书和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其它的步骤或元素。
14.本说明书中使用了流程图用来说明根据本说明书的实施例的系统所执行的操作。应当理解的是，前面或后面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各个步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。
15.随着互联网技术的蓬勃发展，人们逐渐习惯通过网络来签订各种行业场景的服务订单。为了获取服务订单的被执行状态，以便提示人们及时享受服务订单权利和/或履行服务订单义务，可以通过用户端展示的服务履约信息。
16.当用户签订的服务订单较多时，如果同时通过用户端展示各服务订单对应的服务履约信息，会使得用户难以高效掌握与当前场景(如当前时间或当前所在地域)关系密切的服务履约信息。此外，不同行业场景的服务订单有不同的较优展示时机。例如，外卖配送服务订单的较优展示时机是从外卖配送开始直到送达这一过程中，以便用户能直接获取有效的外卖配送的行程信息，缓解用户在等待外卖过程中的焦虑。又例如，电影票订票服务订单的较优展示时机是电影开场前预设时间(如开场前2小时)，以便提醒用户不要错过电影。再例如，餐厅排号服务订单的较优展示时机是用户端位于餐厅附近时，以便还未到达餐厅附近的用户受到展示消息干扰。再例如，酒店住宿服务订单的服务履约信息“退房提醒”的较优展示时机是退房前半小时，防止客户因为超时产生多余费用。由此可见，服务订单需要结合具体服务订单的行业场景、当前用户位置、当前时间确定较优展示时机。此外，同一用户可能同时进行多个服务订单。为了让不同服务订单的服务履约信息在较优展示时机进行展示，同时减少与当前场景关联不大的服务履约展示信息对用户的干扰，需要一种更加精确控制展示时机的服务履约信息展示方法、系统和介质。
17.图1是根据本说明书一些实施例所示的服务履约信息展示系统的应用场景示意图。
18.如图1所示，服务履约信息展示系统的应用场景100可以包括处理设备110、网络
120、订单管理平台130和用户端140。
19.处理设备110可以响应于用户对用户端的预设操作，将状态信息指示有效可展示的服务履约信息推送给用户端，以便所述用户端展示。在处理过程中，处理设备110可以从订单管理平台130获取数据(如与服务订单相关的信息项)，也可以通过网络120从用户端140等其他来源读取数据(如用户端位置信息)或将数据(如有效可展示的服务履约信息)输出至用户端140。
20.处理设备110可以用于处理来自应用场景100的至少一个组件或外部数据源(例如，云数据中心)的数据和/或信息。在一些实施例中，处理设备110可以是单一服务器或服务器组。该服务器组可以是集中式或分布式的(例如，处理设备110可以是分布式系统)。在一些实施例中，处理设备110可以是区域的或者远程的。在一些实施例中，处理设备110可以在云平台上实施，或者以虚拟方式提供。仅作为示例，云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。
21.订单管理平台130可以用于管理服务订单。在一些实施例中，订单管理平台130可以包含于第三方平台内，其中，第三方平台可以是能够向用户提供服务的在线业务平台，如外卖平台、电商平台、货运平台、医院等社会公共类服务网上平台等等。在管理过程中，订单管理平台130可以存储数据(如服务订单等)，也可以获取服务订单的状态，并更新服务订单的信息项。在一些实施例中，订单管理平台130可以从用户端140获取服务订单的状态。在一些实施例中，订单管理平台130也可以从其他终端设备(如叫号设备、定位装置等)处获取服务订单的状态信息。订单管理平台130可以包括一个或多个存储组件，每个存储组件可以是一个独立的设备，也可以是其他设备的一部分。在一些实施例中，订单管理平台130可包括随机存取存储器(ram)、只读存储器(rom)、大容量存储器、可移动存储器、易失性读写存储器等或其任意组合。示例性地，大容量储存器可以包括磁盘、光盘、固态磁盘等。在一些实施例中，订单管理平台130可在云平台上实现。仅作为示例，云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。在一些实施例中，订单管理平台130可以集成或包括在系统100的一个或多个其他组件(例如，处理设备110、用户端140或其他可能的组件)中。
22.用户端140指用户所使用的一个或多个终端设备或软件，所述用户可以包括订单义务履行人员(如外卖配送员、货运司机等)或者订单权利享受人员(如点餐用户、待就诊患者、网上商品购买用户等)。在一些实施例中，用户可以使用用户端140通过网络120与处理设备110和/或订单管理平台130通信，如用户可以使用用户端140与订单管理平台130在线签订服务订单，并接收处理设备推送的服务履约信息并展示给用户，又如用户可以使用用户终端140将服务订单被执行的状态信息发送给订单管理平台130以便其实时获知服务订单被执行的状态。在一些实施例中，用户端140可以是移动设备140
‑
1、平板计算机140
‑
2、膝上型计算机140
‑
3、台式计算机140
‑
4、其他具有输入和/或输出功能的设备等或其任意组合。上述示例仅用于说明所述用户端140设备范围的广泛性而非对其范围的限制。
23.网络120可以连接系统的各组成部分和/或连接系统与外部部分。网络120使得系统各组成部分之间以及与系统与外部部分之间可以进行通讯，促进数据和/或信息的交换。在一些实施例中，网络120可以是有线网络或无线网络中的任意一种或多种。例如，网络120可以包括电缆网络、光纤网络、电信网络、互联网、局域网络(lan)、广域网络(wan)、无线局
域网络(wlan)、城域网(man)、公共交换电话网络(pstn)、蓝牙网络、紫蜂网络(zigbee)、近场通信(nfc)、设备内总线、设备内线路、线缆连接等或其任意组合。在一些实施例中，系统各部分之间的网络连接可以采用上述一种方式，也可以采取多种方式。在一些实施例中，网络120可以是点对点的、共享的、中心式的等各种拓扑结构或者多种拓扑结构的组合。在一些实施例中，网络120可以包括一个或以上网络接入点。例如，网络120可以包括有线或无线网络接入点，例如基站和/或网络交换点120
‑
1、120
‑
2、
…
，通过这些网络接入点，系统100的一个或多个组件可连接到网络120以交换数据和/或信息。
24.在一些实施例中，服务履约信息展示系统可以在处理设备110上实现，其包括服务履约信息确定模块、状态信息确定模块以及服务履约信息推送模块。
25.服务履约信息获取模块可以用于获取服务履约信息。在一些实施例中，所述服务履约信息与服务订单对应且包含与服务订单相关的信息项。关于服务履约信息获取模块的更多描述可以参见步骤210，在此不再赘述。
26.状态信息确定模块可以用于确定服务履约信息的状态信息。在一些实施例中，所述状态信息至少用于指示有效不可展示或有效可展示。所述状态信息与服务订单被执行的状态相关。
27.在一些实施例中，所述服务履约信息具有对应的打开时机和关闭时机。当打开时机到来时，状态信息确定模块可以将所述状态信息由指示有效不可展示更新为指示有效可展示；当关闭时机到来时，状态信息确定模块可以将所述状态信息由指示有效可展示更新为指示有效不可展示或无效。
28.在一些实施例中，服务履约信息对应的打开时机和关闭时机与服务订单被执行的状态相关且基于其行业场景属性确定。
29.在一些实施例中，所述状态信息还用于指示是否无效。当获取到指示服务订单结束的消息或者当服务履约信息存在的时间超过预设超时阈值时，状态信息确定模块可以将所述状态信息更新为指示无效。
30.关于状态信息获取模块的更多描述可以参见步骤220，在此不再赘述。
31.服务履约信息推送模块可以用于响应于用户对用户端的预设操作，将状态信息指示有效可展示的服务履约信息推送给用户端，以便所述用户端展示。
32.在一些实施例中，服务履约信息推送模块还可以响应于所述用户对所述用户端的预设操作，判断所述状态信息指示有效不可展示的服务履约信息的信息项包含的位置信息与所述用户端当前所在的位置信息是否匹配，并将判断结果为匹配的服务履约信息推送给所述用户端，以便所述用户端展示。
33.在一些实施例中，服务履约信息推送模块可以响应于所述用户对所述用户端的预设操作、以及所述状态信息指示有效不可展示的服务履约信息具有指示与用户端定位有关的标识，获取所述用户端的定位信息；获取具有指示与用户端定位有关的标识且状态信息指示有效不可展示的服务履约信息的信息项包含的位置信息；判断所述位置信息与所述用户端的定位信息是否匹配，将判断结果为匹配的位置信息对应的服务履约信息推送给所述用户端，以便所述用户端显示。
34.在一些实施例中，所述服务履约信息具有动态更新标识，用于指示是否动态更新对应服务订单的被执行状态。
35.当动态更新标识指示动态更新对应服务订单的被执行状态时，服务履约信息推送模块可以响应于用户对用户端的预设操作，获取推送给用户端的服务履约信息对应的服务订单的被执行状态，并推送给用户端，以便用户端展示。
36.关于服务履约信息推送模块的更多描述可以参见步骤230，在此不再赘述。
37.应当理解，所述系统及其模块可以利用各种方式来实现。例如，在一些实施例中，系统及其模块可以通过硬件、软件或者软件和硬件的结合来实现。其中，硬件部分可以利用专用逻辑来实现；软件部分则可以存储在存储器中，由适当的指令执行系统，例如微处理器或者专用设计硬件来执行。本领域技术人员可以理解上述的方法和系统可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、cd或dvd
‑
rom的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本说明书的系统及其模块不仅可以有诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用例如由各种类型的处理器所执行的软件实现，还可以由上述硬件电路和软件的结合(例如，固件)来实现。
38.需要注意的是，以上对于服务履约信息展示系统及其模块的描述，仅为描述方便，并不能把本说明书限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解该系统的原理后，可能在不背离这一原理的情况下，对各个模块进行任意组合，或者构成子系统与其他模块连接。例如，服务履约信息确定模块、状态信息确定模块可以合并为一个模块。诸如此类的变形，均在本说明书的范围之内。
39.图2是根据本说明书一些实施例所示的服务履约信息展示方法的示例性流程图。
40.如图2所示，服务履约信息展示方法200可以包括：
41.步骤210，获取服务履约信息。
42.具体地，该步骤210可以由服务履约信息获取模块执行。
43.服务是指第三方为用户提供的有偿或无偿的活动。例如，售票平台提供的电影票、火车票和机票等订票服务。又例如，共享租赁平台提供的充电宝租赁服务和共享单车租赁服务等。再例如，配送员提供的外卖配送服务、餐厅提供的排号服务。其中，第三方可以是服务平台(如共享租赁平台、售票平台等)，也可以是个体(如配送员、餐厅等)。在一些实施例中，服务平台包括订单管理平台130。
44.服务订单是以电子数据形式存储的服务约定。例如，外卖服务订单、订票服务订单和共享租赁订单等。在一些实施例中，所述服务订单由用户发起创建请求，由第三方创建并执行。以外卖配送服务为例，用户发起创建外卖配送服务订单请求后，第三方完成服务订单创建，之后第三方将服务订单派送给配送员以执行订单。
45.订单管理平台是存储和管理服务订单的平台。在一些实施例中，服务订单平台可以更新服务订单被执行的状态。所述服务订单的被执行的状态可以包括待执行、执行中、执行完毕和取消执行。具体地，服务订单平台可以基于从用户端或其他终端设备接收用户和/或工作人员对服务订单的操作，确定服务订单被执行的状态。
46.示例性地，以外卖配送服务为例，完成服务订单创建后，服务订单被执行状态为“待执行”；配送员履行配送义务过程中，服务订单被执行状态为“执行中”；配送员将外卖送达用户后，服务订单被执行状态为“执行完毕”；在“待执行”状态中，用户取消服务订单，则
服务订单被执行状态可以变为“取消执行”。在一些实施例中，服务订单被执行的状态还可以进一步包括执行中的位置状态。例如，配送员履行配送义务过程中，服务订单被执行状态还可以进一步包括当前外卖所处的位置状态，如“位于x街道”、“位于y小区”、“距离xx地点n米”等。
47.又一示例性地，以电影票订票服务为例，完成服务订单创建后，服务订单被执行状态为“待执行”；电影开场后，服务订单被执行状态为“执行中”；电影结束后，服务订单被执行状态为“执行完毕”；在“待执行”状态中，用户取消服务订单，则服务订单被执行状态可以变为“取消执行”。
48.关于服务订单被执行的状态的更多描述可以参见图3及其相关描述，在此不再赘述。
49.服务履约信息是第三方和/或用户履行服务订单的相关信息。在一些实施例中，服务履约信息与服务订单对应且包含与服务订单相关的信息项。例如，当产生一个服务订单时，则可以相应创建一条服务履约信息。作为示例，订单管理平台130可以以消息的方式通知处理设备110或者服务履约信息获取模块有一个新的服务订单被创建了，进而处理设备110或者服务履约信息获取可以创建与服务订单对应的服务履约信息。
50.在一些实施例中，所述与服务订单相关的信息项可以包括用户基本信息、第三方基本信息、行业场景属性、订单基本信息和位置信息等。
51.用户基本信息可以是发起创建服务订单请求的用户信息。在一些实施例中，用户基本信息可以包括用户标识和用户属性。用户标识是用于表示用户的符号。可以理解，每个用户都可以用对应的标识来表示。所述标识可以是数字(如1、2)、字母(如a、b)、汉字或其他符号。例如，用户标识可以是订单管理平台的用户身份证明(user identification，uid)、用户注册昵称、用户身份证编号等。用户属性是表征用户特征的信息。在一些实施例中，用户属性可以包括用户年龄、用户选择偏好和用户注册时间等。
52.第三方基本信息可以是创建并执行服务订单的第三方信息。在一些实施例中，第三方基本信息可以包括第三方标识和第三方属性。第三方标识是用于表示第三方的符号。关于第三方标识的相关描述可以参见用户标识，在此不再赘述。第三方属性是可以表征第三方特征的信息。在一些实施例中，第三方属性可以包括第三方类型(如平台、个体等)、第三方角色(如配送员、商家、直销和中介等)等。
53.行业场景属性可以是指服务订单所属行业或场景的类型或第三方提供的服务所属的行业或场景。例如，文娱、酒店旅游、共享租赁、物流、交通出行和餐饮等。示例性地，外卖配送服务订单的行业场景属性为“餐饮”。又一示例性地，机票订票服务订单的行业场景属性为“交通出行”，电影票订票服务订单的行业场景属性为“文娱”。
54.订单基本信息可以包括订单内容的相关信息。在一些实施例中，不同行业场景属性的服务订单对应的订单基本信息不同。例如，外卖配送服务的订单基本信息可以包括外卖商家信息、配送员信息、外卖信息和预计送达时间。又例如，电影票订票服务的订单基本信息可以包括电影名称、电影院名称、电影开场时间、电影散场时间和座位号。
55.位置信息是与订单相关联的地理信息。例如，订单中的服务提供场所(如电影院、酒店)的地理信息。又例如，订单中服务履行内容(如机票的出发地和目的地，外卖员当前位置)的地理信息。在一些实施例中，位置信息可以是经纬度坐标。例如，电影院的经纬度坐
标。在一些实施例中，位置信息也可以是具有唯一标识性的地址。例如，a省b市c区d小区e栋902室。又例如，a省b市火车南站。在一些实施例中，位置信息还可以是地图上的兴趣点(point of interesting，poi)、兴趣区域(area of interest，aoi)和/或其对应的编号。例如，观音桥商圈和/或其对应的编号aoi
‑
50003。为了便于管理，在一些实施例中，服务履约信息获取模块可以将不同形式的位置信息转换为同一形式。例如，服务履约信息获取模块可以将电影院的经纬度坐标转换为兴趣点的编号“poi
‑
510423”。
56.在一些实施例中，服务履约信息获取模块可以通过网络从订单管理平台130获取与服务订单相关的信息项，进而创建对应的服务履约信息。在一些实施例中，订单管理平台也直接创建与服务订单对应的服务履约信息并自动发送给服务履约信息获取模块。
57.步骤220，确定服务履约信息的状态信息。
58.具体地，该步骤220可以由状态信息确定模块执行。
59.服务履约信息的状态信息是用于指示服务履约状态的信息。服务履约的状态可以表征服务履约的有效性和可展示性。
60.服务履约的有效性可以表征服务履约是否具有被展示的必要。例如，“取消执行”的服务订单对应的服务履约不具有被展示的必要，所述服务履约的状态为“无效”。在一些实施例中，不具有被展示的必要的服务订单对应的服务履约信息不会被发送到服务履约信息获取模块。换而言之，处理设备从订单管理平台获取的服务履约信息的状态均为“有效”。在一些实施例中，处理设备获取的有效的服务履约信息也可以随着服务订单的状态由有效变更为无效。例如，电影票的服务订单在“待执行”阶段被取消，此时处理设备可以从订单管理平台获取到取消通知，进而将该服务履约信息置为无效。
61.进一步地，可展示性可以表征有效服务履约是否处于展示时机，即对应被展示的充分条件。在一些实施例中，所述状态信息可以至少用于指示有效不可展示或有效可展示。其中，有效不可展示即表征有效服务履约处于不可展示时机，有效可展示即表征有效服务履约处于可展示时机。例如，“待执行”的服务订单对应的服务履约暂不处于展示时机，则对应的状态信息指示为有效不可展示。又例如，“执行中”的服务订单处于展示时机，则对应的状态信息指示为有效可展示。
62.在一些实施例中，状态信息与服务订单被执行的状态相关。具体地，状态信息确定模块可以从订单管理平台获取服务履约信息对应的服务订单被执行的状态，再基于服务订单被执行的状态，确定所述服务履约信息的状态信息。在一些实施例中，服务履约的状态信息可以基于服务订单被执行的状态变化而更新。例如，服务履约的状态信息可以由指示有效不可展示更新为指示有效可展示，还可以由指示有效不可展示更新为无效，又或者从有效可展示更新为无效或有效不可展示等。
63.关于基于服务订单被执行的状态，确定所述服务履约信息的状态信息的更多描述可以参见图3及其相关描述，在此不再赘述。
64.步骤230，响应于用户对用户端的预设操作，将状态信息指示有效可展示的服务履约信息推送给用户端，以便所述用户端展示。
65.具体地，该步骤230可以由服务履约信息推送模块执行。
66.用户对用户端的预设操作可以是用户对用户端和/或用户端中的应用程序的操作。例如，预设操作可以是用户打开用户端。又例如，预设操作可以是用户打开用户端上接
收服务履约信息的应用功能。再例如，预设操作还可以是用户在用户端上搜索相关服务履约信息。本说明书对此不做限制。
67.示例性地，当用户在用户端打开所述应用程序时，服务履约信息推送模块可以将当前指示有效可展示的外卖订单服务履约信息推送给用户端，以便所述用户端展示。
68.在一些实施例中，用户端可以在用户端消息提示栏、用户端锁屏和应用程序首页等展示所述服务履约信息。
69.在一些实施例中，所述服务履约信息被展示以告知用户其对应的服务订单被执行的状态。例如，“执行中”的外卖配送服务履约信息被展示可以告知用户对应的外卖配送服务订单正在配送中，还可以进一步告知用户所述外卖“位于x街道”。
70.在一些实施例中，所述服务履约信息具有动态更新标识，用于指示是否动态更新对应服务订单的被执行状态。所述动态更新标识可以用符号、汉字、数字等表示。例如，用“1”表示动态更新标识指示动态更新，用“0”表示动态更新标识指示不动态更新。
71.具体地，当动态更新标识指示动态更新对应服务订单的被执行状态时，响应于用户对用户端的预设操作，服务履约信息推送模块可以获取推送给用户端的服务履约信息对应的服务订单的被执行状态，并推送给用户端，以便用户端展示服务订单被执行的状态。
72.在一些实施例中，服务履约信息推送模块可以从订单管理平台获取对应的服务订单的被执行状态。其中，订单管理平台可以基于预设的时间间隔更新所述订单的被执行状态。
73.示例性地，当外卖配送服务履约信息包括动态更新标识“1”，当用户第一次在用户端打开所述应用程序时，订单管理平台已经基于从配送员用户端获取的位置信息更新当前配送员位置信息为“位于x街道”，服务履约信息推送模块可以从订单管理平台获取该外卖配送服务订单的被执行状态为“执行中，位于x街道”；当用户第二次在用户端打开所述应用程序时，订单管理平台已经基于从配送员用户端获取的位置信息更新当前配送员位置信息为“位于y小区”，服务履约信息推送模块可以从订单管理平台获取该外卖配送服务订单的被执行状态为“执行中，位于y小区”。
74.在一些可替代的实施例中，服务履约信息推送模块也可以从其他用户端或终端设备获取对应的服务订单的被执行状态，例如，从配送员的用户端直接获取该外卖配送服务订单的被执行状态，又例如，从叫号设备获取当前排队的序号等。
75.在一些实施例中，还可以基于用户当前位置确定哪些服务履约信息可以被展示。例如，在一些应用场景中，即使某些服务履约信息从时间维度未到达展示的较优时刻，但是从其所在位置考虑，是适于展示的。即可以基于用户当前位置信息将某些状态信息指示有效不可展示的服务履约信息进行展示。
76.具体的，服务履约信息推送模块还可以响应于用户对用户端的预设操作，获取用户端当前所在的位置信息，判断状态信息指示有效不可展示的服务履约信息的信息项包含的位置信息与用户端当前所在的位置信息是否匹配，并将判断结果为匹配的服务履约信息推送给用户端，以便所述用户端展示。
77.在一些实施例中，用户端当前所在的位置信息可以是用户对用户端执行预设操作的时刻，用户端所在的位置数据，其可以通过用户主动上传位置信息或用户端定位功能获取。例如，用户端具有定位功能，当用户开放获取位置信息权限时，服务履约信息推送模块
可以获取用户端的定位信息，作为用户端位置信息。
78.用户端位置信息可以反映用户的当前位置的地理信息。与前述信息项包含的位置信息类似地，用户端位置信息可以包含多种形式。关于用户端位置信息的形式的详细描述可以参见步骤210，在此不再赘述。用户对用户端执行预设操作后，触发服务履约信息推送模块从用户端获取用户端位置信息。例如，当用户在用户端搜索“餐厅”时，服务履约信息推送模块可以从该用户端获取所述用户端位置信息“a省b市c区d小区e栋902室”。
79.在一些实施例中，服务履约信息推送模块可以将用户端位置信息的形式转换为信息项包含的位置信息的形式，便于后续操作。例如，将述用户端位置信息“a省b市c区d小区e栋902室”转换为兴趣区域的编号“aoi
‑
50002”。进一步地，触发服务履约信息推送模块可以确定所述用户端位置信息是否与服务履约信息的信息项包含的位置信息匹配。这里的服务履约信息主要包括状态信息为有效不可展示的服务履约信息。若位置信息匹配，即使该服务履约信息的状态信息指示当前时刻不是展示时机，但是依然可以认为当前用户所处的地域是适于该服务履约信息展示的，因此，服务履约信息推送模块可以将状态信息指示为有效不可展示但是位置信息匹配的服务履约信息推送给用户端，以便所述用户端显示。
80.在一些实施例中，匹配可以是用户端位置信息和信息项包含的位置信息相同。例如，兴趣区域的编号相同。
81.以餐厅排号服务履约信息的信息项包含的位置信息“观音桥商圈”为例，其转换对应的兴趣区域编号为“aoi
‑
50003”，和当前用户段位置信息的兴趣区域编号“aoi
‑
50002”不匹配。进一步地，当用户持用户端发生位置变化后，再次搜索“餐厅”时，服务履约信息推送模块可以从该用户端获取当前用户端位置信息“a省b市z街道”对应的兴趣区域编号为“aoi
‑
50003”，此时用户端位置信息与服务履约信息的信息项包含的位置信息匹配。
82.在一些实施例中，匹配可以是用户端位置信息在信息项包含的位置信息的预设范围内。例如，用户端的兴趣点位于信息项包含的兴趣区域内。又例如，用户端的兴趣点和信息项包含的兴趣点之间的距离小于100m。
83.在一些实施例中，服务履约信息具有指示与用户端定位有关的标识，该标识可以反映该服务履约信息与用户位置关联较为紧密，可以基于用户端的位置信息进行展示。所述标识可以在服务履约信息创建时，基于其所属的业务场景添加。在一些实施例中，响应于用户对用户端的预设操作、以及状态信息指示有效不可展示的服务履约信息具有指示与用户端定位有关的标识，服务履约信息推送模块可以获取用户端的定位信息，同时服务履约信息推送模块可以获取具有指示与用户端定位有关的标识且状态信息指示有效不可展示的服务履约信息的信息项包含的位置信息。之后，服务履约信息推送模块判断所述位置信息与用户端的定位信息是否匹配，将判断结果为匹配的位置信息对应的服务履约信息推送给用户端，以便所述用户端显示。
84.本说明书的一些实施例基于用户端地理位置将服务履约信息推送给用户端，可以减少以服务场所为主要服务内容的服务订单对应的服务履约展示信息对用户的打扰，同时可以在用户处于服务订单相关联的地域时，提醒用户还存在一些与当前地域关联的服务订单，从而提高用户体验。
85.图3是根据本说明书一些实施例所示的服务履约信息的状态信息更新的示意图。
86.具体地，图3可以由状态信息确定模块执行。
87.在一些实施例中，服务履约信息的状态信息与服务订单被执行的状态相关。
88.如图3所示，当服务订单完成创建后，被执行状态为“待执行”，对应的服务履约信息的状态信息可以为“有效不可展示”。在一些实施例中，还可以基于服务订单所述的行业场景属性来确定所述状态信息。如外卖配送服务履约信息，当外卖配送服务订单的被执行状态为“待执行”时，所述状态信息可以被确定为“有效不可展示”；当外卖配送服务订单的被执行状态为“执行中”时，所述状态信息可以被确定为有效可展示；当外卖配送服务订单的被执行状态为“执行完毕”时，所述状态信息可以被确定为“无效”。又如电影票订票服务履约信息，当电影票订票服务订单的被执行状态为“待执行”并且距离电影开场时间(即“执行中”的起始时间点)大于2小时，可以确定所述状态信息为有效不可展示；当电影票订票服务订单的被执行状态为“待执行”并且距离电影开场时间(即“执行中”的起始时间点)小于2小时，可以确定所述状态信息为有效可展示，当电影票订票服务订单的被执行状态为“执行中”，可以确定所述状态信息为不可展示或无效。
89.在一些实施例中，服务履约信息具有对应的打开时机和关闭时机，进而可以基于打开时机和关闭时机自动更新服务履约信息的状态信息。如图3所示，当打开时机到来时，状态信息确定模块可以将所述状态信息由指示有效不可展示更新为指示有效可展示；当关闭时机到来时，状态信息确定模块可以将所述状态信息由指示有效可展示更新为指示不可展示或无效。
90.在一些实施例中，服务履约信息对应的打开时机和关闭时机可以预先设置，例如可以基于服务订单被执行的状态以及其行业场景属性确定。
91.示例性地，以图3“餐饮”行业场景的外卖配送服务履约信息为例，其对应的打开时机为外卖配送服务订单的被执行状态为“执行中”，关闭时机为外卖配送服务订单的被执行状态为“执行完毕”。
92.又一示例性地，以图3“文娱”行业场景的电影票订票服务履约信息为例，其对应的打开时机为电影票订票服务订单的被执行状态为“待执行”并且距离电影开场时间小于2小时，关闭时机为电影票订票服务订单的被执行状态为“执行中”(即电影已经开场)。
93.在一些实施例中，状态信息确定模块可以基于预先设置的定时任务，自动判断打开时机和/或关闭时机是否到来。所述定时任务可以基于预定的时间间隔，判断当前时间是否处于打开时机和/或关闭时机。
94.示例性地，继续以图3外卖配送服务履约信息为例，定时任务可以包括创建订单后每间隔10s，判断当前外卖配送服务订单的被执行状态是否为“执行中”(即配送员是否已经开始履行配送义务)，是则表示打开时机到来，状态信息确定模块可以将所述状态信息由指示有效不可展示更新为指示有效可展示。进一步地，定时任务还可以包括创建订单后每间隔15s，判断当前外卖配送服务订单的被执行状态是否为“执行完毕”(即配送员是否已经将外卖送达用户)，是则表示关闭时机到来，状态信息确定模块可以将所述状态信息由指示有效可展示更新为指示有效不可展示或无效。
95.又一示例性地，继续以图3电影票订票服务履约信息为例，定时任务可以包括创建订单后每间隔10s，判断当前电影订票服务订单的被执行状态是否为“待执行”并且当前时间是否距离电影开场时间小于2小时(即电影临近开场)，是则表示打开时机到来，状态信息确定模块可以将所述状态信息由指示有效不可展示更新为指示有效可展示。进一步地，定
时任务还可以包括创建订单后每间隔15s，判断当前电影订票服务订单的被执行状态是否为“执行中”(即电影已经开场)，是则表示关闭时机到来，状态信息确定模块可以将所述状态信息由指示有效可展示更新为指示有效不可展示。
96.在一些实施例中，所述状态信息还用于指示是否无效。
97.在一些实施例中，当获取到指示服务订单结束的消息，状态信息确定模块可以将所述状态信息更新为指示无效。
98.在一些实施例中，状态信息确定模块可以从服务订单管理平台获取指示服务订单结束的消息。具体地，服务订单管理平台基于服务订单被执行的状态，可以生成指示服务订单结束的消息，并发送给状态信息确定模块。进一步地，状态信息确定模块接收到指示服务订单结束的消息后，将所述状态信息更新为指示无效。
99.例如，完成创建外卖配送服务订单后，订单管理平台接收到用户取消订单的操作后，基于所述服务订单的被执行状态“取消订单”生成指示服务订单结束的消息，并发送给状态信息确定模块。进一步地，状态消息确定模块接收指示服务订单结束的消息后，将所述状态信息更新为指示无效。
100.在一些实施例中，当服务履约信息存在的时间超过预设超时阈值时，状态信息确定模块可以将所述状态信息更新为指示无效。
101.在一些实施例中，状态信息确定模块可以基于超时定时任务，判断服务履约信息存在的时间(即从服务履约信息被创建到当前的时间段)是否超过预设超时阈值。所述预设超时阈值可以基于服务履约的行业场景属性预先设置。例如，外卖配送服务履约的预设超时阈值可以是12小时。又例如，共享单车服务履约时间可以是3小时。
102.所述超时定时任务可以基于预定的时间间隔，判断截至当前时间，服务履约信息存在的时间是否超过预设超时阈值。例如，如图3所示的外卖配送服务履约，超时定时任务可以在配送服务订单创建后，每间隔1分钟判断截至当前时间，服务履约信息存在的时间是否超过12小时，如果超过，状态信息确定模块则可以将所述状态信息更新为指示无效。
103.在一些实施例中，状态信息确定模块还可以基于用户端的操作，判断服务履约信息存在的时间是否超过预设超时阈值。即，状态信息确定模型可以在用户的预设操作被执行后，执行一次超时判断操作。具体地，状态消息确定模块可以通过从用户端接收的特定用户端操作(参见用户对用户端的预设操作的相关说明)，判断服务履约信息存在的时间超过预设超时阈值，若是则将所述状态信息更新为指示无效。
104.示例性地，当用户打开用户端上的应用程序，处理设备可以执行流程200，将可展示的服务履约信息展示给用户，同时还可以对已有的服务履约信息进行一遍超时检测，将超时的服务履约信息的状态信息置为无效。
105.本说明书的一些实施例基于用户端的操作，判断服务履约信息存在的时间是否超过预设超时阈值可以避免设置过多的定时任务，从而提高处理设备的处理效率。
106.本说明书实施例还提供一种计算机可读存储介质。所述存储介质存储计算机指令，当计算机读取存储介质中的计算机指令后，计算机实现前述的服务履约信息展示方法。
107.本说明书实施例还提供一种服务履约信息展示装置，包括存储介质以及处理器，所述存储介质用于存储计算机指令，所述处理器用于执行所述计算机指令中的至少一部分以实现前述的服务履约信息展示方法。
108.本说明书实施例可能带来的有益效果包括但不限于：(1)针对不同行业场景的服务订单，设置了从时间和/或位置多个维度确定对应的服务履约信息的较优展示时机，可以提高用户对服务履约信息的关注，从而提高用户体验；(2)在后台针对特定行业场景的服务订单设置定时任务，实时更新服务履约信息的状态信息，一方面可以确保及时提醒用户履行具有时效性的服务订单，防止用户错过服务，另一方面可以避免服务履约信息提前对用户进行打扰，使用户接收无效信息；(3)基于用户端地理位置将服务履约信息推送给用户端，可以减少以服务场所为主要服务内容的服务订单对应的服务履约展示信息对用户进行打扰，从而提高用户体验。需要说明的是，不同实施例可能产生的有益效果不同，在不同的实施例里，可能产生的有益效果可以是以上任意一种或几种的组合，也可以是其他任何可能获得的有益效果。
109.上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述详细披露仅仅作为示例，而并不构成对本说明书的限定。虽然此处并没有明确说明，本领域技术人员可能会对本说明书进行各种修改、改进和修正。该类修改、改进和修正在本说明书中被建议，所以该类修改、改进、修正仍属于本说明书示范实施例的精神和范围。
110.同时，本说明书使用了特定词语来描述本说明书的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本说明书至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一个替代性实施例”并不一定是指同一实施例。此外，本说明书的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。
111.此外，本领域技术人员可以理解，本说明书的各方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的工序、机器、产品或物质的组合，或对他们的任何新的和有用的改进。相应地，本说明书的各个方面可以完全由硬件执行、可以完全由软件(包括固件、常驻软件、微码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“数据块”、“模块”、“引擎”、“单元”、“组件”或“系统”。此外，本说明书的各方面可能表现为位于一个或多个计算机可读介质中的计算机产品，该产品包括计算机可读程序编码。
112.计算机存储介质可能包含一个内含有计算机程序编码的传播数据信号，例如在基带上或作为载波的一部分。该传播信号可能有多种表现形式，包括电磁形式、光形式等，或合适的组合形式。计算机存储介质可以是除计算机可读存储介质之外的任何计算机可读介质，该介质可以通过连接至一个指令执行系统、装置或设备以实现通讯、传播或传输供使用的程序。位于计算机存储介质上的程序编码可以通过任何合适的介质进行传播，包括无线电、电缆、光纤电缆、rf、或类似介质，或任何上述介质的组合。
113.本说明书各部分操作所需的计算机程序编码可以用任意一种或多种程序语言编写，包括面向对象编程语言如java、scala、smalltalk、eiffel、jade、emerald、c++、c#、vb.net、python等，常规程序化编程语言如c语言、visual basic、fortran2003、perl、cobol2002、php、abap，动态编程语言如python、ruby和groovy，或其他编程语言等。该程序编码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机运行、或完全在远程计算机或处理设备上运行。在后种情况下，远程计算机可以通过任何网络形式与用户计算机连接，比如局域网(lan)或广域
网(wan)，或连接至外部计算机(例如通过因特网)，或在云计算环境中，或作为服务使用如软件即服务(saas)。
114.此外，除非权利要求中明确说明，本说明书所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本说明书流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本说明书实施例实质和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的处理设备或移动设备上安装所描述的系统。
115.同理，应当注意的是，为了简化本说明书披露的表述，从而帮助对一个或多个发明实施例的理解，前文对本说明书实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本说明书对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。
116.一些实施例中使用了描述成分、属性数量的数字，应当理解的是，此类用于实施例描述的数字，在一些示例中使用了修饰词“大约”、“近似”或“大体上”来修饰。除非另外说明，“大约”、“近似”或“大体上”表明所述数字允许有
±
20％的变化。相应地，在一些实施例中，说明书和权利要求中使用的数值参数均为近似值，该近似值根据个别实施例所需特点可以发生改变。在一些实施例中，数值参数应考虑规定的有效数位并采用一般位数保留的方法。尽管本说明书一些实施例中用于确认其范围广度的数值域和参数为近似值，在具体实施例中，此类数值的设定在可行范围内尽可能精确。
117.针对本说明书引用的每个专利、专利申请、专利申请公开物和其他材料，如文章、书籍、说明书、出版物、文档等，特此将其全部内容并入本说明书作为参考。与本说明书内容不一致或产生冲突的申请历史文件除外，对本说明书权利要求最广范围有限制的文件(当前或之后附加于本说明书中的)也除外。需要说明的是，如果本说明书附属材料中的描述、定义、和/或术语的使用与本说明书所述内容有不一致或冲突的地方，以本说明书的描述、定义和/或术语的使用为准。最后，应当理解的是，本说明书中所述实施例仅用以说明本说明书实施例的原则。其他的变形也可能属于本说明书的范围。因此，作为示例而非限制，本说明书实施例的替代配置可视为与本说明书的教导一致。相应地，本说明书的实施例不仅限于本说明书明确介绍和描述的实施例。