CN111179579A - 一种用户提醒方法及系统 - Google Patents

Abstract

本申请提供了一种用户提醒方法和系统。该方法包括：获取用车订单，所述用车订单中包括上车地点；确定所述上车地点的可停靠时长；根据所述可停靠时长向用户发送提醒信息。

Description

一种用户提醒方法及系统

技术领域

本申请涉及交通运输领域，尤其涉及一种用户提醒方法及系统。

背景技术

随着我国机动车保有量不断地增加，违章停车问题也逐渐增多。发生违章停车的地点为限制停车地点，一般分为禁止停车地点和临时停车地点。不同限制停车地点的可停靠时长可能不同，当停车超过可停靠时长时可能被处罚。因此，有必要提供一种能根据不同上车地点的可停靠时长向用户发送提醒信息的方法和系统。

发明内容

本申请通过确定上车地点的可停靠时长，确定向用户发送的提醒信息，以避免用户受到违停处罚。

本申请的一方面提供了一种用户提醒方法。该方法包括：获取用车订单，所述用车订单中包括上车地点；确定所述上车地点的可停靠时长；根据所述可停靠时长向用户发送提醒信息。

在一些实施例中，所述确定所述上车地点的可停靠时长包括：获取所述上车地点所在区域内的历史用车订单；确定所述区域内历史用车订单的接驾等待时长，所述接驾等待时长为司机到达上车地点后等待乘客上车的时长；根据所述区域内的历史用车订单的接驾等待时长确定所述上车地点的可停靠时长。

在一些实施例中，所述确定所述上车地点的可停靠时长包括：获取所述上车地点所在区域内的历史违停处罚信息；根据所述历史违停处罚信息确定所述上车地点的可停靠时长。

在一些实施例中，所述方法还包括：获取所述用户的历史用车订单；确定所述用户历史用车订单的接驾等待时长；根据所述用户的历史用车订单的接驾等待时长调整所述上车地点的可停靠时长。

在一些实施例中，所述方法还包括：获取所述用户的历史用车订单；确定所述用户历史用车订单的接驾等待时长；根据所述用户的历史用车订单的接驾等待时长调整所述上车地点的可停靠时长。

本申请的另一方面提供了一种用户提醒系统，其特征在于，包括：获取模块，用于获取用车订单，所述用车订单中包括上车地点；可停靠时长确定模块，用于确定所述上车地点的可停靠时长；提醒模块，用于根据所述可停靠时长向用户发送提醒信息。

本申请的另一方面提供一种用户提醒装置，包括处理器，所述处理器用于执行如上所述的用户提醒方法。

本申请实施例之一提供一种计算机可读存储介质，所述存储介质存储计算机指令，当计算机读取存储介质中的计算机指令后，计算机执行如上所述的用户提醒方法。

附图说明

图1所示为根据本申请一些实施例所示的用户提醒系统的应用场景示意图；

图2是根据本申请的一些实施例所示的一种用户提醒方法的示例性流程图；

图3是根据本申请一些实施例所示的一种用户提醒系统的模块图；

图4是根据本申请一些实施例所示的确定上车地点可停靠时长的方法的示例性流程图；

图5是根据本申请一些实施例所示的确定上车地点可停靠时长的方法的示例性流程图；

图6是根据本申请一些实施例所示的确定上车地点可停靠时长的方法的示例性流程图；

图7是根据本申请一些实施例所示的确定上车地点可停靠时长的方法的示例性流程图；以及

图8是根据本申请一些实施例所示的更新上车地点可停靠时长的方法的示例性流程图。

具体实施方式

为了更清楚地说明本申请的实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其它类似情景。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。

如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其它的步骤或元素。

虽然本申请对根据本申请的实施例的系统中的某些模块或单元做出了各种引用，然而，任何数量的不同模块或单元可以被使用并运行在客户端和/或服务器上。所述模块仅是说明性的，并且所述系统和方法的不同方面可以使用不同模块。

本申请中使用了流程图用来说明根据本申请的实施例的系统所执行的操作。应当理解的是，前面或下面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各种步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。

为了更清楚地说明本申请实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。

应当理解，本文使用的“系统”、“装置”、“单元”和/或“模组”系用于区分不同级别的不同组件、元件、部件、部分或装配的一种方法。然而，如果其他词语可实现相同的目的，则可通过其他表达来替换所述词语。

如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其他的步骤或元素。

本申请中使用了流程图用来说明根据本申请的实施例的系统所执行的操作。应当理解的是，前面或下面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各种步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。

本申请的实施例可以应用于不同的交通服务系统，不同的交通服务系统包括但不限于陆地、水面航行、航空、航天等中的一种或几种的组合。例如，人力车、代步工具、汽车(例如，小型车、巴士、大型运输车等)、轨道交通(例如，火车、动车、高铁、地铁等)、船舶、飞机、飞船、卫星、热气球、无人驾驶的交通工具等。本申请的不同实施例应用场景包括但不限于运输业、仓储物流业、农业作业系统、城市公交系统、商业运营车辆等中的一种或几种的组合。应当理解的是，本申请的系统及方法的应用场景仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。例如，其他类似的有轨迹的行驶系统。

图1所示为根据本申请一些实施例所示的用户提醒系统100的应用场景示意图。该用户提醒系统100可以确定向用户发送的提醒信息，降低用户违停的风险。该用户提醒系统100可以是用于互联网服务的线上服务平台。例如，该用户提醒系统100可以是运输服务的线上运输服务平台。在一些实施例中，该用户提醒系统100可以应用于网约车服务，例如出租车呼叫、快车呼叫、专车呼叫、小巴呼叫、拼车、公交服务、司机雇佣和接送服务等。在一些实施例中，该用户提醒系统100还可以用于快递、外卖等。用户提醒系统100可以包括一个服务器110、网络120、服务请求者终端130、服务提供者终端140、存储设备150、信息源160和导航系统170。服务器110可以包括处理引擎112。

在一些实施例中，服务器110可以是一个单个的服务器或者一个服务器群组。所述服务器群可以是集中式的或分布式的(例如，服务器110可以是一个分布式的系统)。在一些实施例中，服务器110可以是本地的或远程的。例如，服务器110可以通过网络120访问存储在存储设备150、服务请求者终端130、服务提供者终端140和/或信息源160中的信息和/或数据。再例如，服务器110可以直接连接到存储设备150、服务请求者终端130、服务提供者终端140和/或信息源160以访问存储的信息和/或数据。在一些实施例中，服务器110可以从存储设备150、服务请求者终端130、服务提供者终端140和/或信息源160处获取违停处罚信息。在一些实施例中，服务器110可以在一个云平台上实现。仅仅作为示例，所述云平台可以包括私有云、公共云、混合云、社区云、分布云、云之间、多重云等或上述举例的任意组合。在一些实施例中，处理引擎112可处理与上车地点可停靠时长有关的数据和/或信息以执行一个或多个本申请中描述的功能。例如，处理设备112可以根据上车地点的可停靠时长确定向用户发送的提醒信息。

网络120可以促进信息和/或数据的交换。在一些实施例中，用户提醒系统100中的一个或多个部件(例如，服务器110、存储设备150、和服务请求者终端130等)可以通过网络120向用户提醒系统100中的其他部件发送信息和/或数据。例如，服务器110可以通过网络120从服务请求者终端130获取/得到数据信息。在一些实施例中，网络120可以是有线网络或无线网络中的任意一种，或其组合。例如，网络120可以包括电缆网络、有线网络、光纤网络、远程通信网络、内联网、互联网、局域网(LAN)、广域网(WAN)、无线局域网(WLAN)、城域网(MAN)、公共开关电话网络(PSTN)、蓝牙网络、ZigBee网络、近场通讯(NFC)网络等或上述举例的任意组合。在一些实施例中，网络120可以包括一个或多个网络接入点。例如，网络120可能包括有线或无线网络接入点，如基站和/或互联网交换点120-1、120-2等等。通过接入点，用户提醒系统100的一个或多个部件可能连接到网络120以交换数据和/或信息。

在一些实施例中，服务请求者终端130的使用者可以是服务请求者本人。在一些实施例中，服务请求者终端130的使用者可以是除服务请求者以外的其他人。例如，在网约车服务中，服务请求者终端130的使用者可以是乘车人本人，也可以是乘车人的亲戚、朋友等帮乘车人下单的人。

在一些实施例中，服务提供者终端140的使用者可以是服务提供者本人。在一些实施例中，服务提供者终端140的使用者可以是除服务提供者以外的其他人。例如，在网约车服务中，服务提供者终端140的使用者可以是司机本人，也可以是帮助司机接单的人。

在一些实施例中，服务请求者终端130可以包括但不限于台式电脑130-1、笔记本电脑130-2，车载内置设备130-3、移动设备130-4等或其任意组合。在一些实施例中，车载内置设备130-3可以包括但不限于个车载电脑、车载抬头显示(HUD)、车载自动诊断系统(OBD)等或其任意组合。在一些实施例中，移动设备130-4可以包括但不限于智能手机、个人数码助理(Personal Digital Assistance，PDA)、平板电脑、掌上游戏机、智能眼镜、智能手表、可穿戴设备、虚拟显示设备、显示增强设备等或其任意组合。在一些实施例中，服务请求者终端130可以将运输服务需求发送至服务器110进行处理。在一些实施例中，服务请求者终端130可以是一带有定位技术的装置，以确定服务请求者和/或服务请求者终端130的位置，并发送给用户提醒系统100中的一个或多个设备，例如服务器110。在一些实施例中，服务器110可以向服务请求者终端130发送提醒信息。

在一些实施例中，服务提供者终端140可以是与服务请求者终端130类似或相同的装置。在一些实施例中，服务提供者终端140可以是一带有定位技术的装置，以确定服务提供者和/或服务提供者终端140的位置。在一些实施例中，服务请求者终端130和/或服务提供者终端140可与其他定位装置通讯以确定服务请求者、服务请求者终端130、服务提供者、或服务提供者终端140的位置。在一些实施例中，服务请求者终端130和/或服务提供者终端140可将定位信息发送至服务器110。在一些实施例中，服务器110可以向服务提供者终端140发送提醒信息。

存储设备150可以存储数据和/或指令。在一些实施例中，存储设备150可以存储从服务器110、服务请求者终端130、服务提供者终端140或导航系统170获得的数据。在一些实施例中，存储设备150可以存储供服务器110执行或使用的数据和/或指令，服务器110可以通过执行或使用所述数据和/或指令以实现本申请描述的示例性方法。在一些实施例中，存储设备150可以与网络120连接以实现与用户提醒系统100中的一个或多个部件(例如，服务器110、服务请求者终端130等)之间的通信。用户提醒系统100的一个或多个部件可以通过网络120访问存储在存储设备150中的数据或指令。在一些实施例中，存储设备150可以直接与用户提醒系统100的一个或多个部件(例如，服务器110、服务请求者终端120等)连接或通信。在一些实施例中，存储设备150可以是服务器110的一部分。

信息源160是为用户提醒系统100提供其他信息的一个源。在一些实施例中，信息源160可以用于为系统提供违停处罚信息、历史订单信息、路况信息等。信息源160可以是一个单独的中央服务器的形式存在，也可以是以多个通过网络连接的服务器的形式存在，还可以是以大量的个人设备形式存在。当信息源160以大量个人设备形式存在时，这些设备可以通过一种用户生成内容(user-generated contents)的方式，例如向云端服务器上传文字、语音、图像、视频等，从而是云端服务器连通与其连接的众多个人设备一起组成信息源160。

所述导航系统170可以确定与目标或用户终端相关的定位信息，例如，一个或多个服务请求者终端130的定位信息，一个或多个服务提供者终端140的定位信息等。在一些实施例中，导航系统170可以是全球定位系统(GPS)、全球导航卫星系统(GLONASS)、指南针导航系统(COMPASS)、北斗导航卫星系统、伽利略定位系统、准天顶卫星系统(QZSS)等。所述信息可包括对象的位置、海拔、速度、加速度或当前时间。导航系统170可以包括一个或多个卫星，例如，卫星170-1、卫星170-2和卫星170-3。卫星170-1至170-3可以独立地或共同地确定上述信息。卫星导航系统170可以通过无线连接将上述信息发送至网络120、服务请求者终端130或服务提供者终端140。

为了实现在本申请中描述的各种模块、单元及其功能，计算设备或移动设备可以用作本申请所描述的一个或多个组件的硬件平台。这些计算机或移动设备的硬件元件、操作系统和编程语言本质上是常规的，并且本领域技术人员熟悉这些技术后可将这些技术适应于本申请所描述的按需服务系统。具有用户界面元件的计算机可以用于实现个人计算机(PC)或其他类型的工作站或终端设备，如果适当地编程，计算机也可以充当服务器。

图2是根据本申请的一些实施例所示的一种用户提醒方法的示例性流程图。具体地，该用户提醒方法200可以由服务器110实现。

步骤201，获取用车订单，所述用车订单中包括上车地点。在一些实施例中，乘客可以通过服务请求者终端130发起用车请求。在一些实施例中，服务器110可以为乘客发起的用车请求确定接单司机，生成用车订单。用车订单中含有各类信息，包括但不限于上车地点、下车地点、上车时间、下车时间、乘客信息、司机信息、费用信息等信息。在一些实施例中，乘客可以在服务请求者终端130中输入上车地点，服务器110可以获取(例如，通过网络120)乘客在服务请求者终端130中输入的上车地点；或者，服务器110可以从根据乘客发起的用车请求生成的用车订单中提取上车地点信息。

在一些实施例中，服务器110可以判断所述上车地点是否为限制停车地点。在限制停车地点处可能发生违停，被处罚的风险较高。在一些实施例中，服务器110可以获取限制停车地点数据。服务器110本身可以包含限制停车地点数据，也可以接入其他设备(例如存储设备150、信息源160)获取限制停车地点数据。在一些实施例中，每条限制停车地点数据包括限制停车地点的名称、位置(例如经纬度)信息。服务器110可以将上车地点与限制停车地点数据进行匹配，以确定上车地点是否为限制停车地点。例如，上车地点为一个地点名称，服务器110可以对上车地点名称与限制停车地点名称进行文本匹配，如果上车地点名称与至少一个限制停车地点名称匹配成功，则确定该上车地点为限制停车地点。又例如，上车地点为一个具体的位置(例如经纬度)，服务器110可以对上车地点位置与限制停车地点位置进行匹配，如果上车地点位置与至少一个限制停车地点位置匹配成功，则确定该上车地点为限制停车地点。

步骤203，确定所述上车地点的可停靠时长。在一些实施例中，所述上车地点为非限制停车地点，则所述上车地点的可停靠时长无限制。在一些实施例中，所述上车地点可以是限制停车地点，不同限制停车地点的可停靠时长可能不同。在一些实施例中，限制停车地点包括禁止停车地点和/或临时停车地点。在一些实施例中，可以获取历史用车订单，根据历史用车订单的接驾等待时长确定上车地点的可停靠时长。有关根据历史用车订单的接驾等待时长确定上车地点的可停靠时长的更多内容可以参见图4及其描述。在一些实施例中，可以获取历史违停处罚信息，根据历史违停处罚信息确定上车地点的可停靠时长。有关根据历史违停处罚信息确定上车地点的可停靠时长的更多内容可以参见图5及其描述。在一些实施例中，可以获取路况信息，根据路况信息确定上车地点的可停靠时长。有关根据路况信息确定上车地点的可停靠时长的更多内容可以参见图6及其描述。在一些实施例中，可以获取特定用户的历史用车订单，确定历史用车订单的接驾等待时长，根据历史用车订单中的接驾等待时长调整上车地点的可停靠时长，得到特定用户的个性化可停靠时长。有关根据特定用户的历史用车订单确定用户个性化可停靠时长的更多内容可以参见图7及其描述。在一些实施例中，可以在确定上车地点的可停靠时长后获取订单取消数据，根据订单取消数据更新可停靠时长。有关根据订单取消数据更新可停靠时长的更多内容可以参见图8及其描述。

在一些实施例中，可以确定上车地点限制停车的风险程度。例如，可以获取历史违停处罚数据，确定在上车地点处违停处罚的次数和涉及该上车地点的订单数。涉及该上车地点的订单可以是以该上车地点为起始地、目的地、途径地等的订单。可以根据该上车地点处发生违停处罚的次数占涉及该上车地点的订单数的比例，确定在该上车地点处被违停处罚的风险，比例越大，风险越大。

在一些实施例中，限制停车地点只在特定时间段(例如每日8:00-19:00)限制停车，服务器110还可以确定限制停车地点限制停车的时间段。例如，服务器110可以从历史违停处罚信息中提取违停时间信息，根据违停时间确定限制停车地点何时限制停车。在一些实施例中，服务器110可以确定限制停车地点在不同时间段限制停车的风险程度。例如，可以将一天24小时划分为多个时间段，获取不同时间段内同一限制停车地点处违停处罚的次数和该时间段内涉及该限制停车地点的订单数。可以根据每个时间段内该限制停车地点处发生违停处罚的次数占该时间段内涉及该限制停车地点的订单数的比例，确定在该时间段内在该地点处被违停处罚的风险，比例越大，风险越大。

步骤205，根据所述可停靠时长向用户发送提醒信息。在一些实施例中，在交通拥堵区域，可以提醒用户尽量减少停靠时间，以避免制造更多的拥堵。在又一些实施例中，在限制停车地点停车时长超过可停靠时长，可能受到违停处罚，可以提醒用户尽量减少停靠时间以避免收到行政处罚。在一些实施例中，提醒信息为倒计时方式，倒计时时长与可停靠时长相等或正相关，以提醒用户在限制停车地点可停车多久。在一些实施例中，用户为司机，可以根据可停靠时长确定司机在上车地点最长需要等待乘客多久，如果乘客未按时到达上车地点，则司机可以无责取消订单。在一些实施例中，用户为乘客，可以根据可停靠时长确定乘客需要在司机达到上车地点后多久内上车，如果乘客未按时到达上车地点，则订单可以被司机无责取消。在一些实施例中，还可以根据上车地点限制停车的风险程度向用户发送提醒信息，风险程度不同，对用户进行提醒的力度和/或方式也不同。例如，如果上车地点限制停车的风险程度超过设定阈值，则每间隔第一时间向用户发送提醒信息，如果风险程度未超过设定阈值，则每间隔第二时间向用户发送提醒信息，所述第一时间小于所述第二时间。又例如，如果上车地点限制停车的风险程度超过设定阈值，则提醒用户(例如乘客)选择其他地点作为上车地点。

图3是根据本申请一些实施例所示的一种用户提醒系统的模块图。如图3所示，该用户提醒系统300可以包括获取模块310、可停靠时长确定模块320、提醒信息确定模块330。在一些实施例中，该用户提醒系统300可以是服务器110内的系统。

获取模块310可以获取用车订单。用车订单中包括上车地点。在一些实施例中，所述上车地点为限制停车地点。在一些实施例中，乘客可以在服务请求者终端130中输入上车地点，服务器110可以获取(例如，通过网络120)乘客在服务请求者终端130中输入的上车地点；或者，服务器110可以根据乘客发起的用车请求生成用车订单，从所述用车订单中提取上车地点信息。在一些实施例中，获取模块310可以获取限制停车地点数据。在一些实施例中，可以根据限制停车地点数据确定上车地点为限制停车地点。在一些实施例中，获取模块310可以获取历史用车订单。在一些实施例中，获取模块310可以获取违停处罚信息。在一些实施例中，获取模块310可以获取路况信息。在一些实施例中，获取模块310可以获取用车订单取消数据。

可停靠时长确定模块320可以确定上车地点的可停靠时长。在一些实施例中，上车地点为非限制停车地点，则可停靠时长确定模块320可以确定该上车地点的可停靠时长不受限制。在一些实施例中，上车地点为限制停车地点，可停靠时长确定模块320可以采用多种方法确定限制停车地点的可停靠时长。在一些实施例中，可停靠时长确定模块320可以根据历史用车订单的接驾等待时长确定上车地点的可停靠时长。在一些实施例中，可停靠时长确定模块320可以根据历史违停处罚信息确定上车地点的可停靠时长。在一些实施例中，可停靠时长确定模块320可以根据路况信息确定上车地点的可停靠时长。在一些实施例中，可停靠时长确定模块320可以根据特定用户的历史用车订单调整可停靠时长，得到该用户的个性化可停靠时长。在一些实施例中，可停靠时长确定模块320可以根据用车订单取消数据更新可停靠时长。

提醒信息确定模块330可以确定向用户发送的提醒信息。在一些实施例中，提醒信息确定模块330可以根据上车地点的可停靠时长确定向用户发送的提醒信息。在一些实施例中，提醒信息为倒计时方式，倒计时时长与可停靠时长相等或正相关，以提醒用户在上车地点可停车多久。在一些实施例中，用户为司机，可以根据可停靠时长确定司机在上车地点最长需要等待乘客多久，如果乘客未按时到达上车地点，则司机可以无责取消订单。在一些实施例中，用户为乘客，可以根据可停靠时长确定乘客需要在司机达到上车地点后多久内上车，如果乘客未按时到达上车地点，则订单可以被司机无责取消。

应当理解，图3所示的系统及其模块可以利用各种方式来实现。例如，在一些实施例中，系统及其模块可以通过硬件、软件或者软件和硬件的结合来实现。其中，硬件部分可以利用专用逻辑来实现；软件部分则可以存储在存储器中，由适当的指令执行系统，例如微处理器或者专用设计硬件来执行。本领域技术人员可以理解上述的方法和系统可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、CD或DVD-ROM的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本申请的系统及其模块不仅可以有诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用例如由各种类型的处理器所执行的软件实现，还可以由上述硬件电路和软件的结合(例如，固件)来实现。

需要注意的是，以上对于用户提醒系统及其模块的描述，仅为描述方便，并不能把本申请限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解该系统的原理后，可能在不背离这一原理的情况下，对各个模块进行任意组合，或者构成子系统与其他模块连接。例如，在一些实施例中，例如，图3中披露的获取模块310、可停靠时长确定模块320、提醒信息确定模块330可以是一个系统中的不同模块，也可以是一个模块实现上述的两个或两个以上模块的功能。例如，各个模块可以共用一个存储模块，各个模块也可以分别具有各自的存储模块。诸如此类的变形，均在本申请的保护范围之内。

在一些实施例中，所述上车地点可以是限制停车地点。图4是根据本申请一些实施例所示的确定限制停车地点的可停靠时长的方法的示例性流程图。具体地，该确定限制停车地点的可停靠时长的方法400可以由服务器110实现。

步骤401，获取限制停车地点所在区域内的历史用车订单。在一些实施例中，限制停车地点所在区域包括但不限于限制停车地点所在街道、行政划区、城市或省份等，服务器110可以获取该区域内的历史用车订单。在一些实施例中，服务器110可以从用户提醒系统100内部的设备(例如存储设备150或信息源160)或外部设备获取历史用车订单。在一些实施例中，服务器110可以获取不同区域的历史用车订单，并从中筛选出限制停车地点所在区域内的历史用车订单，例如筛选出其中上车地点在所述限制停车地点所在区域内的历史用车订单。在一些实施例中，服务器110可以仅获取限制停车地点所在区域内的历史用车订单，例如仅获取上车地点为在所述限制停车地点所在区域内的历史用车订单。

步骤403，确定所述区域内历史用车订单的接驾等待时长，所述接驾等待时长为司机到达上车地点后等待乘客上车的时长。在一些实施例中，每个历史订单可以包括该历史订单不同阶段的数据。用车订单的阶段包括但不限于司机赶往上车地点、乘客赶往上车点、司机到达上车地点等待乘客上车、乘客到达上车点等待司机接驾、司机接到乘客后前往目的地、司机将乘客送至目的地后乘客下车等。在一些实施例中，每个历史订单可以包括该订单的位置和/或时间数据。在一些实施例中，服务器110可以从每个历史订单中提取司机到达上车地点等待乘客上车阶段的时间数据，从而得到接驾等待时长。

步骤405，根据所述区域内的历史用车订单的接驾等待时长确定所述限制停车地点的可停靠时长。可以理解，所述区域内的历史用车订单的接驾等待时长反映了该区域人们的出行习惯以及该区域内的限制停车地点允许车辆停靠时长的限制程度。例如接驾等待时长越长，可以表明该区域人们越倾向于晚点到达上车地点，也可以表明该区域限制停车地点对停靠时间的限制较为宽松；接驾等待时长越短，可以表明该区域人们越倾向于早点到达上车地点，也可以表明该区域限制停车地点对允许停靠时间的限制较为严格。在一些实施例中，可以计算所述区域内的历史用车订单的平均接驾时长，限制停车地点的可停靠时长与所述区域内的历史用车订单的平均接驾等待时长正相关，即所述区域内的历史用车订单的平均接驾等待时长越长，所确定的限制停车地点的可停靠时间越长。在一些实施例中，限制停车地点的可停靠时长也可以与所述区域内的历史用车订单的平均接驾等待时长负相关，即所述区域内的历史用车订单的平均接驾等待时长越长，所确定的限制停车地点的可停靠时间越短，以督促所述区域的人们尽快到达上车地点，降低违停风险。

在一些实施例中，所述上车地点可以是限制停车地点。图5是根据本申请一些实施例所示的确定限制停车地点的可停靠时长的方法的示例性流程图。具体地，该确定限制停车地点的可停靠时长的方法500可以由服务器110实现。

步骤501，获取所述限制停车地点所在区域内的历史违停处罚信息。在一些实施例中，限制停车地点所在区域包括但不限于限制停车地点所在街道、行政区划、城市或省份等，服务器110可以获取该区域内的历史违停处罚信息。违停处罚信息包括但不限于违停车辆、违停地点、违停时间、违停理由、处罚内容、处罚单位等信息。在一些实施例中，服务器110可以从用户提醒系统100的内部设备(例如，存储设备150、信息源160)或其他外部来源获取违停处罚信息。在一些实施例中，服务器110可以从至少两个来源获取违停处罚信息，并对所有违停处罚信息进行去重操作。具体地，服务器110可以比较各条违停处罚信息，如果存在至少两条违停处罚信息一致，则认为所述至少两条违停处罚信息重复，服务器110可以只选用其中一条。违停处罚信息一致可以是违停处罚信息中的所有信息全部一致，也可以是部分信息一致，例如，违停车辆和违停时间一致，或者违停车辆、违停地点和违停时间一致。在一些实施例中，服务器110可以获取多种类型的交通违章处罚信息，并从中筛选出违停处罚信息。在一些实施例中，服务器110可以获取交通管理部门推送的违章处罚信息、发布的违章公告信息(例如，关于xx路段禁止停车的公告信息)、张贴的罚单和/或司机提供的违章处罚信息，从而得到违停处罚信息。在一些实施例中，服务器110可以获取过去一段时间内(例如1年、半年、3个月、1个月、1周等)的违停处罚数据。在一些实施例中，服务器110可以定期更新违停处罚数据。

步骤503，根据所述历史违停处罚信息确定所述限制停车地点的可停靠时长。在一些实施例中，服务器110可以从违停处罚信息中提取处罚内容，根据处罚内容确定限制停车地点的可停靠时长。处罚内容包括但不限于罚款金额、扣分分值等。可以理解，处罚内容可以反映所述区域交通管理部门对违停的处罚力度，例如，罚款金额越高和/或扣分分值越高，说明处罚力度越大。在一些实施例中，可以计算历史违停处罚的平均处罚金额，平均处罚金额越高，所确定的限制停车地点的可停靠时长越短，从而可以提醒用户不要在限制停车地点停留太久，避免因为违停缴纳高额罚款。在又一些实施例中，可以计算历史违停处罚的平均扣分分值，平均分值越高，所确定的限制停车地点的可停靠时长越短，从而可以提醒用户不要在限制停车地点停留太久，避免因为违停被扣去较多分值。

图6是根据本申请一些实施例所示的确定上车地点的可停靠时长的方法的示例性流程图。具体地，该确定上车地点的可停靠时长的方法600可以由服务器110实现。

步骤601，获取所述上车地点所在区域内的路况信息。在一些实施例中，所述上车地点可以也是限制停车地点。所述上车地点所在区域可以包括距离上车地点不超过一定距离阈值的区域。在一些实施例中，路况信息表明上车地点所在区域内的交通是否拥堵或者拥堵程度。例如，路况信息可以包括所述区域内各道路上的平均车速，平均车速越小，表明交通越拥堵。在一些实施例中，服务器110可以接入路况信息平台(例如交通管理部门的路况信息平台或其他第三方的路况信息平台)获取路况信息。

步骤603，根据所述路况信息确定所述上车地点的可停靠时长。在一些实施例中，路况信息表明上车地点所在区域内的交通越拥堵，所确定的上车地点的可停靠时长越短。在一些实施例中，可以根据该区域内的路况对上车地点的可停靠时长进行调整。例如，在交通高峰期，上车地点所在区域内的车流量较大，则上车地点的可停靠时长可设置较短，以避免车辆较长时间停留造成交通拥堵。

图7是根据本申请一些实施例所示的确定上车地点的可停靠时长的方法的示例性流程图。具体地，该确定上车地点的可停靠时长的方法700可以由服务器110实现。

每个乘客都有不同的出行习惯，可以为每个乘客确定个性化可停靠时长。在一些实施例中，每个上车地点有一个基准可停靠时长，该基准可停靠时长可以通过例如图4至图6中任意一种方法确定。在该基准可停靠时长的基础上，可以针对每个用户进行调整，得到该上车地点针对每个用户的个性化可停靠时长。

步骤701，获取用户的历史用车订单。在一些实施例中，服务器110可以从用户提醒系统100内部的设备(例如存储设备150或信息源160)或外部设备获取所述用户的历史用车订单。在一些实施例中，服务器110可以获取所述用户过去一段时间内(例如1年、半年、3个月、1个月、1周等)的历史用车订单。

步骤703，确定所述用户历史用车订单的接驾等待时长。在一些实施例中，每个历史订单可以包括该历史订单不同阶段的数据。用车订单的阶段包括但不限于司机赶往上车地点、乘客赶往上车点、司机到达上车地点等待乘客上车、乘客到达上车点等待司机接驾、司机接到乘客后前往目的地、司机将乘客送至目的地后乘客下车等。在一些实施例中，每个历史订单可以包括该订单的位置和/或时间数据。在一些实施例中，服务器110可以从每个历史订单中提取司机到达上车地点等待乘客上车阶段的时间数据，从而确定接驾等待时长。

步骤705，根据所述用户的历史用车订单的接驾等待时长调整上车地点的可停靠时长。可以理解，用户的历史用车订单的接驾等待时长反映了该用户的出行习惯，接驾等待时长越长，表明该用户越倾向于晚点到达上车地点；接驾等待时长越短，表明该用户越倾向于早点到达上车地点。在一些实施例中，可以计算用户的历史用车订单的平均接驾等待时长，平均接驾等待时长越长，针对该用户将所述上车地点的可停靠时长调整得稍长，以迎合该用户较慢的出行习惯。在一些实施例中，用户的历史用车订单的平均接驾等待时长越长，针对该用户将所述上车地点的可停靠时长调整得越短，以督促该用户尽快到达上车地点，避免违停处罚。

图8是根据本申请一些实施例所示的更新上车地点的可停靠时长的方法的示例性流程图。具体地，该确定上车地点的可停靠时长的方法800可以由服务器110实现。

在确定了上车地点的可停靠时长后，还可以根据实际运行情况对可停靠时长进行更新。在一些实施例中，订单取消数据可以反映所确定的可停靠时长是否合理。例如，如果所确定的可停靠时长过短，要求乘客在很短的时间内到达上车地点，乘客可能会因为时间过于紧张而取消订单；或者，司机只需在上车地点等待乘客很短一段时间便可取消订单，从而导致订单取消率较高。因此，可以根据订单取消数据对上车地点的可停靠时长进行更新。

步骤801，获取用车订单取消数据。在一些实施例中，服务器110可以从用户提醒系统100内部的设备(例如存储设备150或信息源160)或外部设备获取用车订单取消数据。在一些实施例中，服务器110可以获取在确定了上车地点的可停靠时长一段时间后(例如1年、半年、3个月、1个月、1周等)以所述上车地点的用车订单的取消数据。具体地，服务器110可以统计该段时间内以所述上车地点作为上车地点的用车订单被用户取消的次数；或者，服务器110可以统计该段时间内以所述上车地点作为上车地点的用车订单被用户取消的次数占该段时间内所有所述上车地点的用车订单的比例(也称为订单取消率)。

步骤803，根据所述用车订单取消数据更新上车地点的可停靠时长。在一些实施例中，服务器110可以根据用车订单被用户取消的次数更新上车地点的可停靠时长。例如，如果取消次数大于设定阈值，则可以将可停靠时长调长。在一些实施例中，服务器110可以根据订单取消率更新上车地点的可停靠时长。例如，如果订单取消率大于设定阈值，则可以将可停靠时长调长。在一些实施例中，每次更新可以以固定幅度调整可停靠时长。例如，每次更新都将可停靠时长调长1分钟、2分钟、3分钟、5分钟等。

需要说明的是，上述各个具体实施例中确定上车地点可停靠时长的方法可以单独使用，也可以组合使用。例如图4所示的流程与图5所示的流程可以组合使用。在一些实施例中，当通过分析所述上车地点所在区域内的历史违停处罚信息确定该区域对违停处罚力度较大，且通过分析上车地点所在区域内的历史用车订单，确定所述区域内的历史用车订单的接驾等待时长较长时，则可将所述可停靠时长进一步设置的较短。在一些实施例中，可以通过可停靠时长确定模型实现上述确定上车地点可停靠时长的方法。仅作为示例，可停靠时长确定模型的输入可以包括上车地点所在区域内的历史用车订单信息、历史违停处罚信息、路况信息、特定用户的历史订单信息、订单取消数据等中的一种或任意组合。本领域技术人员在本申请公开内容的启示下，对上述各个具体实施例进行其他方式的组合也属于本申请保护的范围，在此不再赘述。

本申请实施例可能带来的有益效果包括但不限于：(1)确定上车地点的可停靠时长，根据可停靠时长对用户进行提醒，提高用户体验；(2)按区域确定上车地点的可停靠时长，贴合不同区域人们的出行习惯；(3)为个体用户调整可停靠时长，满足不同用户的个性化需求；(4)根据实际运行情况不断更新可停靠时长，满足实际需求。需要说明的是，不同实施例可能产生的有益效果不同，在不同的实施例里，可能产生的有益效果可以是以上任意一种或几种的组合，也可以是其他任何可能获得的有益效果。

上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述详细披露仅仅作为示例，而并不构成对本申请的限定。虽然此处并没有明确说明，本领域技术人员可能会对本申请进行各种修改、改进和修正。该类修改、改进和修正在本申请中被建议，所以该类修改、改进、修正仍属于本申请示范实施例的精神和范围。

同时，本申请使用了特定词语来描述本申请的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本申请至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一替代性实施例”并不一定是指同一实施例。此外，本申请的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。

此外，本领域技术人员可以理解，本申请的各方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的工序、机器、产品或物质的组合，或对他们的任何新的和有用的改进。相应地，本申请的各个方面可以完全由硬件执行、可以完全由软件(包括固件、常驻软件、微码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“数据块”、“模块”、“引擎”、“单元”、“组件”或“系统”。此外，本申请的各方面可能表现为位于一个或多个计算机可读介质中的计算机产品，该产品包括计算机可读程序编码。

计算机存储介质可能包含一个内含有计算机程序编码的传播数据信号，例如在基带上或作为载波的一部分。该传播信号可能有多种表现形式，包括电磁形式、光形式等，或合适的组合形式。计算机存储介质可以是除计算机可读存储介质之外的任何计算机可读介质，该介质可以通过连接至一个指令执行系统、装置或设备以实现通讯、传播或传输供使用的程序。位于计算机存储介质上的程序编码可以通过任何合适的介质进行传播，包括无线电、电缆、光纤电缆、RF、或类似介质，或任何上述介质的组合。

本申请各部分操作所需的计算机程序编码可以用任意一种或多种程序语言编写，包括面向对象编程语言如Java、Scala、Smalltalk、Eiffel、JADE、Emerald、C++、C#、VB.NET、Python等，常规程序化编程语言如C语言、Visual Basic、Fortran 2003、Perl、COBOL 2002、PHP、ABAP，动态编程语言如Python、Ruby和Groovy，或其他编程语言等。该程序编码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机运行、或完全在远程计算机或服务器上运行。在后种情况下，远程计算机可以通过任何网络形式与用户计算机连接，比如局域网(LAN)或广域网(WAN)，或连接至外部计算机(例如通过因特网)，或在云计算环境中，或作为服务使用如软件即服务(SaaS)。

此外，除非权利要求中明确说明，本申请所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本申请流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本申请实施例实质和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的服务器或移动设备上安装所描述的系统。

同理，应当注意的是，为了简化本申请披露的表述，从而帮助对一个或多个实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本申请对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

Claims (18)

1.一种用户提醒方法，其特征在于，包括：

获取用车订单，所述用车订单中包括上车地点；

确定所述上车地点的可停靠时长；

根据所述可停靠时长向用户发送提醒信息。

2.如权利要求1所述的用户提醒方法，其特征在于，所述确定所述上车地点的可停靠时长包括：

获取所述上车地点所在区域内的历史用车订单；

确定所述区域内历史用车订单的接驾等待时长，所述接驾等待时长为司机到达上车地点后等待乘客上车的时长；

根据所述区域内的历史用车订单的接驾等待时长确定所述上车地点的可停靠时长。

3.如权利要求1所述的用户提醒方法，其特征在于，所述确定所述上车地点的可停靠时长包括：

获取所述上车地点所在区域内的历史违停处罚信息；

根据所述历史违停处罚信息确定所述上车地点的可停靠时长。

4.如权利要求1所述的用户提醒方法，其特征在于，所述确定所述上车地点的可停靠时长还包括：

获取所述上车地点所在区域内的路况信息；

根据所述路况信息确定所述上车地点的可停靠时长。

5.如权利要求1所述的用户提醒方法，其特征在于，所述方法还包括：

获取所述用户的历史用车订单；

确定所述用户历史用车订单的接驾等待时长；

根据所述用户的历史用车订单的接驾等待时长调整所述上车地点的可停靠时长。

6.如权利要求1所述的用户提醒方法，其特征在于，所述方法还包括：

获取用车订单取消数据；

根据所述用车订单取消数据更新所述上车地点的可停靠时长。

7.如权利要求1所述的用户提醒方法，其特征在于，所述上车地点为限制停车地点。

8.如权利要求1所述的用户提醒方法，其特征在于，所述提醒信息为倒计时方式，所述倒计时时长与所述可停靠时长相等或者正相关。

9.一种用户提醒系统，其特征在于，包括：

获取模块，用于获取用车订单，所述用车订单中包括上车地点；

可停靠时长确定模块，用于确定所述上车地点的可停靠时长；

提醒模块，用于根据所述可停靠时长向用户发送提醒信息。

10.如权利要求9所述的用户提醒系统，其特征在于，

所述获取模块还用于获取所述上车地点所在区域内的历史用车订单；

所述可停靠时长确定模块还用于：

确定所述区域内历史用车订单的接驾等待时长，所述接驾等待时长为司机到达上车地点后等待乘客上车的时长；

根据所述区域内的历史用车订单的接驾等待时长确定所述上车地点的可停靠时长。

11.如权利要求9所述的用户提醒系统，其特征在于，

所述获取模块还用于获取所述上车地点所在区域内的历史违停处罚信息；

所述可停靠时长确定模块还用于根据所述历史违停处罚信息确定所述上车地点的可停靠时长。

12.如权利要求9所述的用户提醒系统，其特征在于，

所述获取模块还用于获取所述上车地点所在区域内的路况信息；

所述可停靠时长确定模块还用于根据所述路况信息确定所述上车地点的可停靠时长。

13.如权利要求9所述的用户提醒系统，其特征在于，

所述获取模块还用于获取所述用户的历史用车订单；

所述可停靠时长确定模块还用于：

确定所述用户历史用车订单的接驾等待时长；

根据所述用户的历史用车订单的接驾等待时长调整所述上车地点的可停靠时长。

14.如权利要求9所述的用户提醒系统，其特征在于，

所述获取模块还用于获取用车订单取消数据；

所述可停靠时长确定模块还用于根据所述用车订单取消数据更新所述上车地点的可停靠时长。

15.如权利要求9所述的用户提醒系统，其特征在于，所述上车地点为限制停车地点。

16.如权利要求9所述的用户提醒系统，其特征在于，所述提醒信息为倒计时方式，所述倒计时时长与所述可停靠时长相等或者正相关。

17.一种用户提醒装置，其特征在于，包括至少一个存储介质及至少一个处理器；

所述至少一个存储介质用于存储计算机指令；

所述至少一个处理器用于执行所述计算机指令，以实现权利要求1～8中任一项所述的用户提醒方法。

18.一种计算机可读存储介质，所述存储介质存储有计算机指令，当所述计算机指令被处理器执行时，实现如权利要求1～8任一项所述的用户提醒方法。

Images