用于基于网络的服务的情景通知的制作方法

背景技术：

常规网络服务的用户可以针对由实体提供的、待由服务提供方将其递送到服务位置的一个或多个物品提交请求。用户可以通过在用户设备上执行的应用程序来执行该操作。

附图说明

在附图的各图中，通过示例而非限制的方式示出了本文的公开内容，在附图中，相同的附图标记指代相似的元件，并且其中：

图1是示出根据本文描述的示例的与提供方设备和用户设备通信的示例网络系统的框图；

图2是描述根据本文描述的示例的为给定用户设备生成情景(上下文，contextual)通知的示例方法的流程图；

图3a和图3b是分别示出根据本文描述的示例的情景通知和请求用户界面的示例的图；

图4是示出根据本文描述的示例的示例移动计算设备的框图；和

图5是示出可以在其上实施本文描述的示例的计算机系统的框图。

具体实施方式

本文提供了一种网络服务，该网络服务由一个或多个服务器或网络计算机系统(为简单起见，在本文中称为“网络系统”)实现，该网络服务链接遍及给定地理区域(例如，大都市区，比如旧金山湾区)的服务提供方(例如，驾驶员、快递员、自动驾驶车辆(av)等)和请求用户。在这样操作的过程中，网络服务与给定地理区域的服务提供方组成的池进行通信，每个服务提供方操作用于提供服务的车辆和一个或多个计算设备(“服务提供方设备”或“提供方设备”)。在各种实施方式中，网络系统经由在用户的移动计算设备(“用户设备”)上执行的指定用户或客户端应用程序(“用户应用程序”)从请求用户接收针对服务(例如，运输服务、递送服务等)的请求。作为响应，网络系统识别一个或多个可用的服务提供方来履行每个用户的请求。根据实施例，网络系统和/或用户设备可以基于所确定的度量(metric)，来确定是否为给定用户呈现与基于网络的服务有关的通知，其中该度量代表给定用户将在给定时间窗口(例如，在接下来的30分钟内、在接下来的一个小时内等)内提交服务请求(或与用于基于网络的服务的用户应用程序进行交互)的可能性。因此，网络系统和/或用户设备可以基于所确定的用户是否将在给定时间段内与用户应用程序进行交互的可能性和/或所确定的用户是否将在给定时间段内提交服务请求的可能性，来选择性地使用于基于网络的服务的通知在用户设备上呈现。网络系统可以被配置为确定给定用户的度量并且将该度量与一个或多个阈值进行比较。

在各个示例中，用户设备和提供方设备可以是计算设备，例如智能电话、可穿戴设备、平板电脑、膝上型计算机、台式计算机等。网络服务使用户能够通过在用户设备上执行的用户应用程序来选择由一个或多个实体提供的一个或多个物品。如本文所指的，实体可以对应于提供一个或多个待售商品或物品的个人、公司、集团、卖方或商人等(例如，厨师、面包师、餐馆、咖啡厅、商店等)。网络系统接收到的服务请求可包括请求用户对由一个或多个实体提供的、待由服务提供方运输到服务位置以递送给请求用户的一个或多个物品的选择。在这样的情景下(例如，食物订购和递送服务)，服务位置可以是服务提供方将在此与请求用户会合和/或将所请求的物品递送给请求用户的递送位置。响应于服务请求，网络系统可以将用户的选择通知实体。另外，网络系统可以识别可用的服务提供方来履行用户的请求。网络系统可以将邀请发送到所识别的服务提供方的提供方设备，服务提供方可以接受邀请以履行所请求的服务。

与未实现计算机化的对等服务相比较，尽管如上所述的基于网络的服务为用户提供了便利，但是常规的基于网络的服务中存在许多缺点。例如，为了通过在用户设备上执行的用户应用程序请求常规递送服务中的服务，用户通常必须启动用户设备上的用户应用程序，浏览众多的菜单和选项来选择感兴趣的物品，随后提交服务请求。在用于显示与基于网络的服务有关的内容的屏幕受到限制的诸如智能电话的移动计算设备中，该问题更加严重。由于屏幕实用面积有限，可能会迫使用户浏览更多菜单，或者必须滚动浏览更多内容以提交服务请求。另外，为常规的基于网络的服务吸引用户的常规方法(例如，通过将通知发送给用户设备)是无效的。无论用户行为是否通过查看通知而受到影响，都发送通知，结果，这种发送既浪费了网络传输带宽，又浪费了用户设备在呈现通知时的处理能力。此外，用户设备的显示屏或用户界面可能会因不需要的通知而变得混乱-移动计算设备上可用的有限数量的显示实用面积又使问题加重。

根据实施例，网络系统可以生成并发送通知数据，以使通知被呈现在基于网络的服务的用户的用户设备上。该通知可以是推送通知(例如，由用户设备接收并以一种或多种方式显示的通知)或应用程序内通知(“应用内通知”)。该通知可以是用户可操作的(例如，经由用户设备的触摸屏上的点击手势或滑动手势)。用户可以与通知进行交互，以使用于基于网络的服务的用户应用程序启动和/或执行与基于网络的服务有关的一组动作。例如，响应于用户与可操作通知(actionablenotification)的交互，用户应用程序可以启动并自动地提交服务请求。在一些示例中，响应于用户与通知的交互，用户应用程序可以被启动并且可以呈现预先填充有一组内容的用户界面(例如，用于提交基于网络的服务的服务请求的服务请求界面)，以允许在提交服务请求时的加快或简化的用户体验。可操作通知可以进一步建议或提醒用户请求服务。

网络系统可以为基于网络的服务的每一个维护用户简档，并且每个用户简档可以包括指示相应用户的基于网络的服务的过去实例的细节的数据。给定用户的给定用户简档可以包括以下信息，比如给定用户的优选/常用地址(例如，工作地址、家庭住址等)、由给定用户请求的基于网络的服务的过去实例的历史数据和/或为给定用户提供的基于网络的服务的过去实例的历史数据、给定用户关于物品选择和/或实体的隐式(例如，基于历史数据得出的)和/或显式(例如，声明的、输入到用户应用程序的等)的偏好。在一些实施方式中，网络系统可以进一步维护一个或多个数据库，该数据库存储关于基于网络的服务的多个用户的集体性信息。例如，关于位于一个地理区域内的一组用户的匿名信息(例如，关于物品选择、实体、服务时间等的隐式或显式的偏好)。

在各个方面，可以基于与用户相关联的信息(例如，基于网络的服务的用户历史记录、用户偏好、用户的位置、用户的等等)和各种其他参数(例如，当前时间和/或星期几、附近实体的可用性、关于网络服务的其他用户的历史数据等)来显示通知。网络系统和/或用户设备(例如，经由在用户设备上执行的用户应用程序)可以确定是否为给定用户呈现通知、何时为给定用户呈现通知、通知的内容和/或响应于用户与通知的交互而由用户设备执行的动作。

在一个示例中，网络系统可以响应于确定度量高于阈值(例如，指示用户更可能提交请求)来确定不向用户的用户设备发送通知数据，并且可以响应于确定度量值低于阈值(例如，指示用户不太可能提交请求)来确定发送通知数据。以这种方式，仅当网络系统确定在给定时间窗口内用户不太可能启动用户应用程序和/或不太可能提交服务请求时，才可以使通知显示在用户设备上。实际上，可以向被确定为不太可能提交服务请求(例如，与阈值相比较)的第一用户呈现目标通知，从而提醒该用户与用于基于网络的服务的用户应用程序进行交互以提交服务请求；然而被确定为已经可能提交服务请求的第二用户将不会被呈现此类通知。

在其他示例中，网络系统可以将给定用户的所确定的度量与两个或更多个阈值进行比较。在一个这样的示例中，网络系统可以基于或响应于确定用户在给定时间段内提交服务请求的可能性(或用户启动用于基于网络的服务的用户应用程序或与用于基于网络的服务的用户应用程序进行交互的可能性)在两个阈值(例如，低阈值和高阈值)之间，来确定向用户设备发送通知数据。以这种方式，可以将通知智能地呈现给与通知最相关的用户。被确定为即使在没有被通知提示的情况下也可能与用户应用程序进行交互以提交服务请求的用户将不会被呈现通知，并且他们的设备无需从网络系统接收通知数据。类似地，被确定为即使在被其用户设备上的通知提示时也不太可能与用户应用程序进行交互以提交的用户(例如，低于阈值的度量)也不会被呈现通知。对于这些类别的用户中的每一个，关于基于网络的服务的通知都可能被视为不必要或垃圾邮件。

根据实施例，网络系统可以基于与给定用户有关的数据(例如，服务历史、用户偏好等)、与基于网络的服务的其他用户有关的数据以及各种情景信息(例如，当前时间/星期几、附近实体的可用性、第二基于网络的服务的服务进度信息等)，来确定或计算给定用户的度量。例如，网络系统可以基于用户的过去服务历史，来确定用户通常在特定时间或特定时间段期间(例如，工作日的中午至12:30pm、周末的1:00到2:00pm等)启动和/或查看应用程序，和/或提交服务请求。基于此类信息，网络系统可以确定指示用户在某些时间窗口内提交请求的可能性的度量。时间窗口可以是预定的。例如，对于食品递送服务，可以将时间窗口预定为在用餐时间(例如，早餐、午餐或晚餐)前后。因此，基于给定用户的服务历史数据，网络系统可以确定给定用户的指示用户很可能在星期一的12:00pm到1:00pm的预定时间窗口内提交服务请求的度量。

在各种实施方式中，网络系统还可基于与给定区域内基于网络的服务的大量用户相关联的服务历史数据来确定给定用户的度量。例如，网络系统可以确定给定区域内的用户一天中通常请求基于网络的服务的时间。至少部分基于该信息，网络系统可以确定给定用户的度量。作为说明性示例，网络系统可以维护大都市区域内的大量用户的用户简档数据，该用户简档数据集体性地指示大都市区域内的用户通常在工作日的12:30pm和1:30pm之间提交服务请求(例如，食品的递送请求)。网络系统可以分析大都市区域内的用户简档，以确定在星期一的12:00pm时给定用户的度量，并至少部分基于所确定的度量，确定是否在那个时间将通知数据发送到给定用户的用户设备。以这种方式，网络系统可以基于大量用户的过去行为来主动地并且智能地将通知数据发送到给定用户设备，使得可以在相关时间为给定用户显示关于基于网络的服务的通知。

在某些实施方式中，网络系统可以基于与更细分的地理子区域(与其中提供基于网络的服务的整个大都市区域相比)相关联的历史数据(或基于用户的更细分的子集的历史数据)来确定给定用户的度量。可以确定具有关于基于网络的服务的过去行为的一致模式的地理子区域和/或用户子集。例如，用户通常在某个时间窗口内提交服务请求的地理子区域(例如，市区的金融区，其中用户通常在工作日期间在12:00pm和1:00pm之间提交食品递送服务请求；住宅区，其中用户通常在每周的每天的6:00pm至8:00pm之间提交食品递送服务请求，等等)。以这种方式，基于位于与给定用户的位置(或服务位置)相同的区域内的并且因此最有可能表现出与给定用户相同的偏好和行为的其他用户的过去行为，可以确定是否在给定用户设备上呈现情景通知。网络系统可以分析用户简档数据，以识别整个服务区域中的一致用户行为，以确定各种地理区域(其用于确定是否将通知数据发送到用户设备)的划分。在一些示例中，地理子区域(或用户子集)可以由系统管理员预定义或选择。

在某些示例中，网络系统还可以基于与第二基于网络的服务(例如，运输服务)有关的情景信息来确定度量。在一些示例中，度量确定可以基于第二基于网络的服务的服务参数或服务进度信息。例如，度量确定可以基于服务位置(例如，运输服务的下车位置)、服务时间(例如，下车时间)、到达服务位置的估计到达时间等。在一个这样的示例中，网络系统可以接收关于运输服务的用户的服务进度信息(例如，从管理运输服务的第二网络系统接收、从用户设备接收)，并且至少部分基于服务进度信息来确定度量。在一个示例中，网络系统可以确定运输服务的服务位置是用户的住所，并且预计到达时间约为6:00pm。基于这一信息和过去的用户历史记录，该历史记录表明用户在这些或类似的情况下有70％的时间提交了食品递送服务请求，网络系统可以为用户计算度量。可以确定计算出的度量与用户在星期天的2:00pm利用运输服务到达健身房的另一情形相比更高(例如，指示用户在例如随后的一个小时内提交服务请求的可能性更高)。

在一些示例中，网络系统还可以确定要在用户设备的屏幕上显示通知的时间(或将通知数据发送给用户设备的时间)。网络系统可以确定给定用户的预期递送时间。这可以基于与给定用户相关联的历史数据、基于通常为该给定用户递送请求的过去的递送时间来确定。这也可以基于与其他用户(例如，在同一地理子区域内或在用户位置的预定距离内请求递送的用户)相关联的历史数据来确定。网络系统可以至少部分基于估计的递送时间来确定显示通知的时间。在该确定过程中，网络系统可以进一步考虑准备时间(例如，实体准备所请求的物品所花费的时间等)、运输时间(例如，服务提供方的等待时间、服务提供方从实体位置到服务位置的行进时间)以及给定用户提交请求所需的时间。这些参数的估计可以基于历史数据，并且可以基于一个或多个机器学习模型来确定。也可以为基于网络的服务的每个用户分别确定这些参数。例如，如果给定用户通常从第一实体请求第一组物品，则网络系统可以基于与准备第一组物品时的第一实体相关联的历史数据以及与服务提供方在从第一实体行进到给定用户所请求的服务位置或其附近的位置时的表现相关的历史数据，来估计准备时间和运输时间。以这种方式，网络系统可以及时发送通知数据，并使通知及时显示在用户设备上，使得可以在预期的递送时间或之前将所请求的物品递送给用户。

在各种实施方式中，响应于用户与可操作通知的交互而呈现的请求界面的一个或多个方面可以是自动化的，或者可以用于加快或精简的用户体验。从网络系统发送的通知数据可以包括与服务请求关联的一组默认参数。例如，服务请求界面可以自动地填充待由用户请求递送的一组默认物品。服务请求界面还可以自动地填充一个默认服务位置，在该位置，履行服务请求的服务提供方将与用户会合和/或将所请求的物品递送给用户。结果，用户可以与服务请求界面内的简单输入(例如，单次点击)交互，以使用该组默认参数来提交服务请求。服务请求界面还可包括供用户在将服务请求提交到网络系统之前修改服务请求的参数(例如，添加、移除或替换要订购的物品、修改服务位置、修改服务时间等)的选项。

在其他益处中，本文描述的实施例允许基于所确定的用户将与基于网络的服务进行交互(例如，提交服务请求)的可能性而在用户设备上呈现情景通知。以此方式，如果确定用户已经可能在没有任何通知的情况下提交服务请求，或者即使呈现通知用户也不太可能提交服务请求，则通知数据可能不会由网络系统发送。以此方式，可以使网络系统和用户设备的网络资源以及用户设备的处理资源更加有效。另外，这避免了用户设备的有限的显示实用面积因不需要的或不必要的通知而混乱。此外，情景通知对于用户而言可以是交互式的，以使得呈现请求用户界面，该请求用户界面旨在简化提交服务请求中的用户体验(例如，通过为用户预选物品)。这使用户应用程序能够更好地利用用户设备的有限的显示实用面积，并使用户能够避免滚动浏览众多菜单来提交服务请求。

如本文所使用的，计算设备是指与台式计算机、蜂窝设备或智能电话、个人数字助理(pda)、膝上型计算机、虚拟现实(vr)或增强现实(ar)头戴式设备、平板电脑设备、电视(ip电视)等相对应的设备，其可以提供网络连接和处理资源以通过网络与系统通信。计算设备还可以对应于定制硬件、车载设备或板载计算机等。计算设备还可以运行被配置为与网络系统通信的指定应用程序。

本文描述的一个或多个示例规定由计算设备执行的方法、技术和动作以编程方式或者作为计算机实施的方法来执行。如本文所使用的，编程方式意味着通过使用代码或计算机可执行指令。这些指令可以存储在计算设备的一个或多个存储器资源中。以编程方式执行的步骤可以是自动的，也可以不是自动的。

本文描述的一个或多个示例可以使用编程模块、引擎或组件来实施。编程模块、引擎或组件可以包括能够执行一个或多个所述任务或功能的程序、子例程、程序的一部分、或软件组件或硬件组件。如在本文中所使用的，模块或组件可以独立于其他模块或组件存在于硬件组件上。或者，模块或组件可以是其他模块、程序或机器的共享元件或进程。

本文描述的一些示例通常可能需要使用计算设备，包括处理和存储器资源。例如，本文描述的一个或多个示例可以全部或部分在诸如服务器、台式计算机、蜂窝或智能电话、个人数字助理(例如，pda)、膝上型计算机、vr或ar设备、打印机、数码相框、网络设备(例如，路由器)和平板电脑设备之类的计算设备上实现。存储器、处理和网络资源都可以与本文描述的任何示例的建立、使用或执行(包括与任何方法的执行或与任何系统的实施一起)结合使用。

此外，本文描述的一个或多个示例可以通过使用可由一个或多个处理器执行的指令来实施。可以在计算机可读介质上承载这些指令。下面通过附图示出或描述的机器提供了处理资源和计算机可读介质的示例，其上可以承载和/或执行用于实施在本文中公开的示例的指令。具体而言，由本发明的示例示出的许多机器包括处理器和用于保存数据和指令的各种形式的存储器。计算机可读介质的示例包括永久存储器存储装置，例如，个人计算机或服务器上的硬盘驱动器。计算机存储介质的其他示例包括便携式存储单元，例如，cd或dvd单元、闪存(例如，在智能电话、多功能设备或平板电脑上承载的)和磁存储器。计算机、终端、网络化设备(例如，移动设备，比如，手机)都是利用处理器、存储器和存储在计算机可读介质上的指令的机器和装置的示例。此外，示例可以以计算机程序或能够承载这种程序的计算机可用载体介质的形式实施。

系统描述

图1是示出根据本文描述的示例的与提供方设备和用户设备通信的示例网络系统的框图。网络系统100可以实施或管理基于网络的服务(例如，按需递送服务等)，其将请求用户197与可用于履行用户的服务请求199的服务提供方192连接。网络系统100可以通过在用户设备195上执行的用户应用程序196和在提供方设备190上执行的提供方应用程序191来提供一个平台，该平台使可用的服务提供方192能够为请求用户197提供按需服务。如本文中所使用的，提供方设备190和用户设备195可以是被配置为执行用于由网络系统100管理的按需服务的相应指定应用程序(例如，提供方应用程序191、用户应用程序196等)的计算设备。例如，提供方设备190和用户设备195可以包括移动计算设备，例如智能手机、平板计算机、vr或ar头戴式设备、车辆的车载计算系统、智能手表等。

在一个示例中，请求用户197可以通过网络180提交请求199，该请求指示由一个或多个服务提供方192递送到服务位置的一个或多个选择的物品，服务位置也可以由请求199指示。响应于接收到请求199，网络系统100可以处理请求199并将请求128发送到相关实体185，以提供或准备由请求用户197请求的一个或多个物品。

根据实施例，网络系统100可以包括用于处理接收到的请求199的请求处理引擎120。请求处理引擎120可以传达由请求用户197选择的物品，并将物品选择消息123发送到相关的实体185(例如，提供由用户197选择的物品的餐馆)，以使实体能够开始准备所选择的物品。请求处理引擎120可以查找与实体有关的相关信息(例如，通过从存储实体简档数据157的数据库150中查询实体数据153)，以便正确地将物品选择消息123发送给计算机、终端或设备(例如，交易终端、销售点终端、由实体操作的移动计算设备等)。

请求处理引擎120还可以从多个服务提供方192中识别服务提供方以为请求199提供服务。可以基于服务提供方相对于在请求199中选择的实体的当前位置来识别服务提供方。例如，网络系统100可以维持与每个服务提供方设备190的通信，以监视服务提供方192的当前位置。响应于请求199，请求处理引擎120可以基于服务提供方的当前位置在距与请求199相关联的实体的预定距离(或行进时间)内来识别服务提供方。在某些情况下，请求处理引擎120可以基于服务提供方的提供方类别来识别服务提供方192。例如，如果实体和/或服务位置位于拥挤的市区中，则请求处理引擎120可以识别具有与操作摩托车或自行车而不是汽车的服务提供方相对应的提供方类别的服务提供方。另外，服务提供方的识别可以基于从请求处理引擎120接收到的请求组127。请求组127可以指示将由单个服务提供方提供服务的一组服务请求。请求处理引擎120可以利用该信息来识别履行服务请求199的服务提供方。

在识别出履行请求199的服务提供方后，请求处理引擎120可以生成邀请122。邀请可以由提供方设备接口145通过网络160发送到提供方的提供方设备190。作为响应，所识别的服务提供方可以接受或拒绝邀请122。如果服务提供方接受邀请122(例如，经由提供方应用程序191内的选择)，则网络系统100可以例如向提供方设备190发送路线121，该路线121由请求处理引擎120确定，以利于提供方设备履行请求199。如果服务提供方拒绝邀请122，则请求处理引擎120可以识别另一个合适的服务提供方。

在本文描述的示例中，请求处理引擎120还可以确定路线121。可以将路线121发送到所选择的服务提供方以在履行所请求的服务中遵循。路线121可以包括到实体的路线段和到服务位置的路线段。在一个示例中，路线可以至少包括从服务提供方192的当前位置到提供一个或多个所选物品的实体185的第一路线段和从实体到服务位置的第二路线段，使得一个或多个所选物品可以提供给请求用户197。在另一示例中，如果服务提供方被网络系统100识别为履行请求来自多个实体的物品的服务请求199，则路线121可以包括从所选择的服务提供方的当前位置到实体中的第一个的第一路线段、从实体中的第一个到第二实体的第二路线段，等等。此外，如果服务提供方192被网络系统100识别为履行具有不同服务位置的多个服务请求，则路线121可以包括从实体的最后一个到服务位置中的第一个的区段、从服务位置中的第一个到服务位置中的第二个的区段，等等。

在各种实施方式中，网络系统可以包括用于存储诸如用户简档156和实体简档157之类的信息的数据库150。用户简档156可以存储诸如对实体提供的物品的相应用户偏好(例如，物品偏好、喜欢的实体、喜欢的物品类型、不喜欢的物品、食物过敏等)。用户简档156还可以存储用户最常用或最喜欢的服务位置(例如，工作地、住所等)。另外，用户简档156可以存储关于用户过去提交给网络系统100的服务请求的信息(例如，所请求的物品、花费的金额等)。随着网络系统100收集其他或更多最新信息，可以连续地更新数据库150中存储的数据。使用存储在用户简档156中的信息，网络系统100可以优化相应用户197的体验。例如，网络系统100可以基于存储在用户简档156中的信息来生成物品或实体建议或推荐。此外，如本文所述，网络系统100可以利用历史数据和存储在用户简档156中的信息来生成情景通知以显示在用户设备197上。

根据实施例，网络系统100可以包括通知引擎115，其可以生成通知数据116以传输给用户设备195。通知数据116可以经由用户设备接口140和通过网络180被传输到用户设备195。用户设备195可以基于从网络系统100接收到的通知数据116，为用户197呈现情景通知。通知引擎115可以通过计算用户设备195的用户197的度量，来确定是否要在用户设备195上呈现通知(例如，是否将通知数据116发送到用户设备195)。该度量可以指示用户将在给定时间段内提交服务请求或与用户应用程序进行交互的可能性。通知引擎115可以将度量与一个或多个阈值进行比较，以确定是否将通知数据116发送给用户设备195。

可以基于用户简档数据151(例如，关于用户197的基于网络的服务的过去实例的或从该过去实例中确定的信息或数据)来计算给定用户197的度量。简档数据151可以在由网络系统100在数据库150中维护的用户197的对应用户简档中检索或查询。简档数据151可以例如指示用户197在与基于网络的服务的交互(例如，提交服务请求)中的过去行为。可以利用简档数据151中包含的信息，例如用户197通常提交服务请求的日期和时间，来确定该度量。

可以进一步基于历史数据152(例如，关于基于网络的服务的其他用户的基于网络的服务的过去实例的或从该过去实例中确定的信息或数据)来计算用户197的度量。在一些实施方式中，通知引擎115可以确定基于网络的服务的用户子集，其历史数据将被包括在历史数据152中，并因此用于计算用户197的度量。可以确定具有关于基于网络的服务的过去行为的一致模式的用户子集。例如，用户通常在某个时间窗口内提交服务请求的地理子区域(例如，市区金融区，其中用户通常在工作日期间在12:00pm和1:00pm之间提交食品递送服务请求；住宅区，其中用户通常在每周的每天的6:00pm和8:00pm之间提交食品递送服务请求，等)。以这种方式，可以基于在与用户197的位置(或服务位置)相同的区域中并且因此最有可能表现出与用户197相同的偏好和行为的其他用户的过去行为，来确定是否为用户197呈现情景通知。

取决于实施方式，在确定用户197的度量的过程中，通知引擎115可以确定归于用户197的用户简档数据151和基于网络的服务的其他用户的历史数据152的相应权重。在一个实例中，例如当用户197在他或她的用户简档中没有足够的数据时，用户197的度量可以完全基于历史数据152。在其他示例中，权重可以基于用户197的时间、日期或位置而变化。例如，当用户197处于家的区域(例如，居住和工作的城市)时，确定用户197的度量可以部分基于用户197的用户简档数据151，部分基于历史数据152。但是，当用户197前往其中用户197没有关于基于网络的服务的服务历史的不同区域时，通知引擎115可以完全基于与用户197行进到的区域中的其他用户相关联的历史数据152来确定用户197的度量。替代地，在确定度量的过程中，通知引擎115可以向历史数据152分配附加权重(与用户197处于他或她的家的区域时相比)。因此，可以基于用户197的目的地区域中的用户的典型行为来提醒用户197与基于网络的服务进行交互或提交服务请求。在一些实施方式中，可以使用用户简档数据151和历史数据152来计算单独的度量，可以将适当的权重分配给单独的度量，并且可以通过组合单独的度量来确定用户197的度量。

根据实施例，网络系统100可以与管理第二基于网络的服务(例如，运输服务)的第二网络系统170通信。在确定是否在用户设备195上显示通知时(例如，在确定用户197的度量时)，通知引擎115可以接收第二服务进度信息(sspi)171，该信息指示用户197的第二基于网络的服务的参数或进度信息。sspi171可以指示例如目的地位置和由运输服务为用户197安排的行程的估计到达时间。通知引擎115可以基于目的地位置来确定用户197的度量。例如，通知引擎115可以确定用户197的在用户197使用运输服务于6:00pm到家的第一场景中的度量与在用户197于下午的2:00pm行进到健身房的第二场景中的度量相比要高。在第一种情况下，用户197更有可能基于sspi171中包含的信息来提交递送服务的服务请求。

在某些示例中，基于sspi171(例如，eta和目的地位置)，网络系统100可以生成通知数据116并将其发送给用户设备195，以在用户197到达目的地位置的途中时在用户设备195上呈现通知，以便用户197可以在到达目的地位置之前提交服务请求199。以这种方式，可以在用户197将要到达目的地位置的大约同一时间将物品递送给用户197。在一些实施方式中，发送到用户设备195的通知数据116可以使通知呈现在用户应用程序196之外的第二用户应用程序内(例如，用于与第二基于网络的服务进行交互的专用的第二用户应用程序内的应用内通知或内容卡)。

取决于具体的实施方式，还可以通过网络180从用户设备195接收sspi171。例如，与第二基于网络的服务相关联的第二用户应用程序可以将sspi171发送到网络系统100(例如，可以通过在第二用户应用程序中输入用户197的基于网络的服务的登录凭据，将第二用户应用程序“链接”到基于网络的服务的用户197的简档)。

取决于变化，可以使用一个或多个机器学习模型111来确定用户197的度量。机器学习模型111可以由机器学习模型生成器(“mlm生成器”)110生成。机器学习模型111可以基于用户197的用户简档数据151和基于网络的服务的其他用户的历史数据152由mlm生成器进行训练。机器学习模型111也可以使用与第二基于网络的服务有关的数据来训练。在某些实施方式中，用于确定用户197的度量的一个或多个机器学习模型111可以包括基于用户197的用户简档数据151生成的用户特定的机器学习模型以及从基于网络的服务的其他用户的历史数据152导出的第二机器学习模型。对于基于网络的服务的另一用户，通知引擎115可以基于由mlm生成器110生成的使用该用户的简档数据的另一机器学习模型和从历史数据152(也用于用户197)导出的第二机器学习模型来确定该用户的度量。在其他实施方式中，可以使用一个机器学习模型111，并且该机器学习模型111可以包括从用户简档数据151以及历史数据152两者导出的数据。机器学习模型111可以是基于决策树的模型(例如，随机森林模型)，并且可以基于针对基于网络的服务收集的数据(例如，用户简档数据151和历史数据152)由mlm生成器110生成。

还可以基于经由一个或多个网络180从用户设备195接收到的用户数据198来确定用户197的度量。用户数据198可以包括诸如用户197的当前位置之类的信息。当前位置可以由用户设备195确定，并且可以由诸如gps、glonass、伽利略或北斗接收机的一种或多种地理感知资源生成。基于用户197的当前位置，通知引擎115可以确定相关数据(例如，历史数据152)和机器学习模型111，以用于确定用户197的度量。

在一些示例中，响应于接收到通知数据116，用户设备195可以立即为用户197呈现或显示情景通知。在其他示例中，通知数据116可以指示通知应在用户设备195上呈现的时间。响应于接收到这样的一组通知数据116，用户设备195可以对要在所指示的时间显示或呈现的通知进行时间安排。因此，网络系统100可以提前确定是否使通知呈现在用户设备195上和发送的通知数据116，以使用户设备195在通知数据中指示的时间呈现通知。

在各种示例中，在用户设备195上呈现的通知可以是用户可操作的，以使得用于提交服务请求(例如，请求199)的请求用户界面被呈现在用户设备195上(例如，在用户应用程序196内)。响应于用户与通知的交互(例如，点击手势、滑动手势等)，用户设备195可以呈现请求用户界面。可以使用内容或信息自动填充请求用户界面，以帮助简化用户体验。例如，请求用户界面的“购物车”可以自动填充一个或多个物品(例如，菜品、食品、饮料等)，使得用户197通过单次点击请求用户界面的特征即可提交服务请求199。如果用户197希望修改自动填充的内容(例如，预选物品)，则用户197可以在提交请求199之前进行修改。

通知引擎115生成的通知数据116还包括与在呈现情景通知时由用户设备195显示的内容相对应的内容数据。内容数据可以包括要在通知本身上显示的内容(“通知内容”)，例如提醒用户提交服务请求的文本和图形信息。通知内容可以将相关的情景信息通知给用户197，并且可以为用户197提供概要，以激起用户对与用户设备195上呈现的情景信息进行交互的兴趣。例如，通知内容可以通知用户197用户197当前所在区域的基于网络的服务(例如，在该区域中的递送服务)的服务请求通常在特定时间(例如，12:00pm的递送时间)请求，并且可以在11:00am提示用户在该区域内的用户请求服务的典型时间提交递送请求。作为另一示例，通知内容还可以包括关于第二基于网络的服务的信息(例如，从sspi171得出)：通知内容可以通知用户197用户197估计在例如6:00pm到达第二基于网络的服务(例如，运输服务)的目的地位置，并且可以提示用户197提交在目的地位置的递送服务请求，以便可以在估计用户197到达目的地位置的时间或前后将所请求的物品递送给用户197。

通知数据116可以进一步包括在用户197与情景通知交互之后在用户应用程序196内显示的内容(“应用程序内容”)。应用程序内容可以包括在用户197与通知交互之后显示的请求用户界面中要为用户197针对服务请求预选的物品的标识。通知引擎115可以基于指示用户197的偏好和过去服务请求的用户简档数据151来生成应用程序内容。应用程序内容可以包括用户197经常请求的物品的预选，使得用户197可以方便快捷地请求提供这些物品的服务。应用程序内容可以取决于用户197的位置(例如，如用户数据198所示)。例如，要递送的物品的预选可以取决于用户197所处的位置(例如，取决于哪个实体在附近)。应用程序内容还可以取决于基于网络的服务的其他用户的历史数据152。例如，应用程序内容可以建议用户197所处的区域中的基于网络的服务的用户所流行的物品或实体。在一些实施方式中，应用程序内容不作为通知数据116的一部分被发送，而是响应于用户197与情景通知交互而由用户设备195查询。因此，在用户197与情景通知交互之后，网络系统100将应用程序内容发送到用户设备195。

方法

图2是描述根据本文描述的示例的为给定用户设备生成情景通知的示例方法的流程图。在下面的图2的论述中，可以参考关于图1示出和描述的特征和示例。例如，图2中所示的方法210可以由关于图1中示出和描述的网络系统100和/或用户设备195来执行。

转到图2，在某些实施方式中，网络系统和/或用户设备可以检测一个或多个触发器以确定是否为用户设备呈现通知(211)。通知确定可以基于时间(206)、基于位置(207)或基于其他情景信息(208)。例如，响应于检测到用户的位置已经改变(例如，用户已经移动到不同的地理区域或地理子区域)，可以触发网络系统以执行确定过程。触发确定过程的情景信息可以包括与用户正在请求或正在进行的第二基于网络的服务(例如，运输服务)有关的服务进度信息。作为检测触发事件以执行通知的确定过程的补充或替代，网络系统和/或用户设备可以周期性地(例如，每天一次)确定是否在给定的用户设备上呈现情景通知。

网络系统被配置为确定给定用户的度量，该度量表示用户将在给定时间段(例如，接下来的2小时、接下来的12小时，等等)内与用于基于网络的服务的用户应用程序进行交互或提交服务请求的可能性(210)。如本文所述，可以基于以下各项来确定度量：(i)特定于用户的数据(例如，用户的服务历史记录、存储在用户简档中的用户偏好等)(211)，(ii)与其他用户有关的数据(例如，与该用户在同一区域内的其他用户的使用模式和偏好)(212)，和/或(iii)情景信息(例如，诸如体育赛事之类的附近事件、天气状况、用户在诸如运输服务的第二基于网络的服务中的服务进度，等)。在利用与基于网络的服务的其他用户相对应的数据时，网络系统可以确保数据被匿名化。另外，网络系统可以使用一个或多个机器学习模型(例如，随机森林模型、基于决策树的模型等)来进行确定，机器学习模型被使用上述各种类别的数据进行训练。网络系统可以通过将所确定的度量与一个或多个阈值进行比较来确定是否将通知数据发送到用户的用户设备(215)。

如果网络系统确定将通知数据发送到用户设备，则网络系统然后可以确定通知内容(220)。通知内容可以包括要在情景通知中显示的文本或图形。可以基于用户的用户简档和与基于网络的服务的其他用户相对应的数据来生成通知数据。例如，通知内容可以通知用户用户当前所在区域的基于网络的服务(例如，在该区域中的递送服务)的服务请求通常在特定时间(例如，12:00pm的递送时间)请求，并且可以在11:00am提示用户在该区域内的用户请求服务的典型时间提交递送请求。网络系统可以发送通知数据以使用户设备在用户设备上呈现情景通知(225)。用户设备可以响应于用户与情景通知的交互来呈现请求用户界面。

根据实施例，网络系统可以等待从用户设备接收请求(230)。可以使用响应于用户与情景通知的交互而显示的请求用户界面来提交请求，或者可以在没有情景通知的提示的情况下由用户单独启动用户应用程序来提交请求。该请求可以包括关于送至指定或预定服务位置的一个或多个服务物品的用户选择的数据。可以由用户设备响应于请求用户与用户应用程序的交互来生成请求(例如，使用“提交”或“下单”或“结账”用户界面特征)。在各种示例中，响应于在步骤230接收到请求，网络系统将请求信息发送到相关实体(235)。在一些示例中，请求信息包括预期的准备完成时间。预期的准备完成时间可以是由网络系统估计的实体完成相应物品的准备的时间，以确保及时地(例如，在预期服务时间或前后)履行请求。作为替代，网络系统可以发送信息以使实体能够基于与需求有关的历史数据来准备物品。

根据实施例，网络系统还确定服务提供方在履行服务请求时的最佳路线(240)。该步骤可以例如由图1的服务请求处理引擎120执行。具体而言，可以基于与一个或多个所选物品相关联的准备时间来确定最佳路线，以例如最小化所选择的服务提供方和请求用户的等待时间。例如，基于准备时间，网络系统可以确定最佳路线，以使得所选择的服务提供方在估计由实体准备的所选物品准备就绪以便拿取的时间或前后到达实体的位置。网络系统可以通过基于所选物品的准备时间确定路线上的实体顺序来进一步优化路线。网络系统可以另外优化路线以减少行驶距离和/或时间。另外，网络系统可以从实体接收实时数据以便更新最佳路线。例如，基于指示在一个特定实体处的延迟的实时数据，网络系统可以更新最佳路线以解决该延迟(例如，重新排序实体的顺序或延迟到达正经历延迟的特定实体的路线段)。以这种方式，服务提供方的路线可以基于最新信息保持最佳状态。

在各个方面，网络系统可以从多个服务提供方中识别或选择服务提供方来履行服务请求(245)。例如，网络系统可以选择位于实体和/或服务位置附近的服务提供方。另外，网络系统可以基于最佳路线选择服务提供方。例如，网络系统可以基于最佳路线在拥挤的市区环境中选择自行车服务提供方。相反，如果最佳路线包括高速公路上的一个或多个路段，则网络系统可以选择汽车服务提供方。另外，网络系统可以基于与之相关联的服务能力来识别服务提供方。例如，网络系统可以基于由单个服务提供方服务的一组服务请求中的请求用户所选择的物品来确定所需的服务能力。网络系统可以识别服务提供方，使得该服务提供方的服务能力足以履行该组服务请求。

根据实施例，网络系统可以将与最佳路线相对应的数据发送到所选择的服务提供方(250)。对应于最佳路线的数据可以包括内容数据，例如地图数据，以使得或致使所选择的提供方的提供方设备能够显示路线引导或包括最佳路线的交互式地图。

用户界面示例

图3a和3b是分别示出根据本文描述的示例的情景通知和请求用户界面的示例的图。

参照图3a，情景通知可以由用户设备响应于从网络系统接收到的通知数据来显示。该通知可以在通知数据中指定的时间显示(例如，延迟呈现)，或者可以响应于接收到通知数据而由用户设备立即呈现。当用户设备被锁定时或当用户设备的屏幕关闭时，情景通知可以显示在用户设备操作系统的锁定屏幕上。如关于图1所描述的，通知内容可以将相关的情景信息通知给用户197，并且可以为用户提供概要。

参照图3b，可以响应于用户与情景通知的交互(例如，点击手势、滑动手势，等)来显示请求用户界面。可以为特定用户定制请求用户界面的内容，并且可以基于用户的历史数据(例如，存储在用户的用户简档中)生成请求用户界面的内容。在各个方面中，可以呈现请求用户界面，以允许在与基于网络的服务进行交互和/或在用户应用程序内提交服务请求时提供简化和容易的用户体验。例如，请求用户界面可以包括在提交服务请求时为用户预选的物品(例如，用户最喜欢的物品或经常请求的物品)。请求用户界面可以清楚地指示预选的物品(例如，添加到用户的“购物车”中)。在某些情况下，请求用户界面可以提供与实体有关的信息(例如，实体名称、实体联系信息、实体地址、实体的用户评级等)。尽管在图3b中未具体示出，但请求用户界面还可包括服务信息，例如可以基于用户的当前位置得到的预定服务位置(例如，用户将在该位置接收物品的递送)和估计的服务时间(例如，估计服务提供方将预选的物品递送给用户的时间)。用户能够通过请求用户界面容易、快速地修改未提交的请求的任何方面。例如，用户能够添加、删除或替换预选的物品。用户还能够修改服务位置、指定服务时间(例如，尽快或安排服务时间)以及浏览附近区域中其他实体的供应。一旦用户对请求的参数感到满意，用户就可以通过“结账”或“下单”用户界面特征来提交服务请求。通过利用已在文件中保存(例如，存储在用户的用户简档中)的基于网络的服务的付款信息，可以简化请求提交过程。

硬件图

图4是示出根据本文描述的示例的示例移动计算设备的框图。在许多实施方式中，移动计算设备400可以是智能电话、平板计算机、膝上型计算机、vr或ar头戴式设备等。在图1的情境中，用户设备195和/或提供方设备190可以使用在图4中示出且关于图4描述的移动计算设备400来实现。

根据实施例，移动计算设备400可以包括典型的电话特征，诸如麦克风445、摄像头450和通信接口410，以使用任何数量的无线通信协议与外部实体(例如，实施基于网络的服务的网络系统490)进行通信。移动计算设备400可以将指定的应用程序(例如，服务应用程序432)存储在本地存储器430中。服务应用程序432可以对应于用于将移动计算设备400实施为用于基于网络的服务的用户设备的一个或多个用户应用程序。服务应用程序432还可以对应于用于将移动计算设备400实施为用于基于网络的服务的提供方设备的一个或多个提供方应用程序。

响应于输入418，服务应用程序432可以由处理器440执行，这可以使应用程序界面442在移动计算设备400的显示屏420上生成。在移动计算设备400作为提供方设备的实施方式中，应用程序界面442可以使服务提供方能够例如接受或拒绝用以履行由网络系统490生成的服务请求的邀请。邀请可以作为传入服务消息469来接收，并且邀请的接受可以被移动计算设备400将其作为传出服务消息467发送到网络系统490。在移动计算设备400作为用户设备的实施方式中，应用程序界面442可以使用户能够例如请求基于网络的服务。服务请求可以作为传出服务消息467发送到网络系统490。

在各个示例中，移动计算设备400可以包括gps模块460，其可以通过网络480向网络系统490提供指示移动计算设备400的当前位置的位置数据462。在一些实施方式中，可以使用诸如glonass、galileo或北斗之类的其他位置感知或地理定位资源来代替gps模块460或作为其补充。网络系统490可以利用移动计算设备400的当前位置462来管理基于网络的服务(例如，选择履行服务请求的服务提供方、规划服务提供方和用户的路线、确定用户的服务位置等)。

第二用户应用程序433可以存储在移动计算设备400的存储器430中。第二用户应用程序433可以对应于用于第二基于网络的服务(例如，运输服务)的专用用户应用程序。在某些实施方式中，第二用户应用程序433可以被配置为与用户应用程序432或与网络系统490共享第二基于网络的服务的信息(例如，服务进度信息)。例如，基于网络的服务的用户的登录凭据可以在第二用户应用程序433内，以允许第二用户应用程序433将数据传输到网络系统490。作为另一个示例，该基于网络的服务和第二基于网络的服务可以利用相同的一组登录凭据。

通信接口410被配置为通过网络480接收通知数据426。响应于接收到通知数据426，移动计算设备400可以在显示屏420上呈现情景通知428。可以立即呈现该通知或可以在通知数据426中指定的稍后的时间显示该通知。用户可以通过用户输入418(例如，点击手势、滑动手势)与情景通知进行交互。可以响应于接收到与情景通知交互的用户输入418而呈现用户应用程序432的特定用户界面(例如，请求用户界面)，该情景通知使用户能够有效地与基于网络的服务和用户应用程序432进行交互。

图5是示出可以在其上实施本文描述的示例的计算机系统的框图。计算机系统500可以表示例如用于服务器或服务器组合的硬件，其可被实现为用于提供按需服务的网络服务的一部分。在图1的情境中，可以使用计算机系统500或多个计算机系统500的组合来实施网络系统100，如图5所述。

一方面，计算机系统500包括处理资源(处理器510)、主存储器520、存储器530、存储设备540和通信接口550。计算机系统500包括至少一个处理器510，用于处理存储在主存储器520中的信息，该主存储器例如由随机存取存储器(ram)或其他动态存储设备提供，用于存储可由处理器510执行的信息和指令。主存储器520还可以用于存储在执行由处理器510执行的指令期间的临时变量或其他中间信息。计算机系统500还可以包括存储器530或其他静态存储设备，用于存储用于处理器510的静态信息和指令。存储设备540，例如，磁盘或光盘，被用于存储信息和指令。

通信接口550使计算机系统500能够通过使用网络链接(无线或有线)与一个或多个网络580(例如，蜂窝网络)通信。使用网络链接，计算机系统500可以与一个或多个计算设备、一个或多个服务器和/或一个或多个自动驾驶车辆通信。根据一些示例，计算机系统500从单个用户的移动计算设备接收服务请求。存储在存储器530中的可执行指令可以包括服务提供方路线规划和选择指令522以及通知生成指令524，以在被执行时执行本文所述的一种或多种方法。

作为示例，存储在存储器520中的指令和数据可以由处理器510执行，以实现图1的示例网络系统100。在执行操作时，处理器510可以处理服务请求和提供方状态，并提交服务邀请以利于履行服务请求。处理器510执行用于软件和/或其他逻辑的指令，以执行一个或多个过程、步骤和其他与实施方式一起描述的功能，例如由图1至图3b描述的。

本文所述的示例与用于实施本文所述技术的计算机系统500的使用有关。根据一个示例，那些技术由计算机系统500响应于处理器510执行包含在主存储器520中的一个或多个指令的一个或多个序列来执行。这些指令可以从另一机器可读介质(例如，存储设备540)读入主存储器520中。执行包含在主存储器520中的指令序列使处理器510执行本文所述的过程步骤。在替代实施方式中，可以使用硬连线电路代替软件指令或与软件指令结合来实现本文描述的示例。因此，所描述的示例不限于硬件电路和软件的任何特定组合。

通过执行本文描述的功能和技术，计算机系统500被配置为通过网络580从用户设备接收请求582，并且识别适当的服务提供方(例如，基于通过网络从提供方设备接收到的服务提供方位置584)。计算机系统可以将邀请552发送到所识别的服务提供方，以邀请所识别的服务提供方来履行所请求的服务。另外，计算机系统500可以生成通知数据554，以使用户设备呈现为操作用户设备的给定用户特别确定的情景通知。

设想到在本文中描述的示例延伸到在本文中描述的独立于其他概念、想法或系统的各个元件和概念，并且示例包括本申请中任何地方记载的元件的组合。尽管在本文中参考附图详细描述了示例，但是应当理解，这些概念不限于那些具体的示例。因此，许多修改和变化对于本领域技术人员来说是明显的。因此，概念的范围旨在由所附权利要求及其等同方案限定。此外，设想到单独描述或作为示例的一部分描述的特定特征可以与其他单独描述的特征或其他示例的一部分相结合，即使其他特征和示例没有提到该特定特征。因此，没有描述组合不应排除对这种组合的权利主张。