CN110782648B - 确定预计到达时间的系统和方法 - Google Patents
确定预计到达时间的系统和方法 Download PDFInfo
- Publication number
- CN110782648B CN110782648B CN201811468237.7A CN201811468237A CN110782648B CN 110782648 B CN110782648 B CN 110782648B CN 201811468237 A CN201811468237 A CN 201811468237A CN 110782648 B CN110782648 B CN 110782648B
- Authority
- CN
- China
- Prior art keywords
- request
- feature vector
- service
- road segment
- arrival
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/20—Monitoring the location of vehicles belonging to a group, e.g. fleet of vehicles, countable or determined number of vehicles
- G08G1/205—Indicating the location of the monitored vehicles as destination, e.g. accidents, stolen, rental
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/005—Traffic control systems for road vehicles including pedestrian guidance indicator
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/20—Monitoring the location of vehicles belonging to a group, e.g. fleet of vehicles, countable or determined number of vehicles
- G08G1/202—Dispatching vehicles on the basis of a location, e.g. taxi dispatching
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/14—Network analysis or design
- H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/52—Network services specially adapted for the location of the user terminal
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Traffic Control Systems (AREA)
Abstract
本发明涉及用于确定预计到达时间(ETA)的系统和方法。系统可以执行方法,以经由网络从与服务请求者相关联的请求者终端接收服务请求;从服务请求中获取上车地点、目的地和请求相关的信息;根据请求相关的信息确定至少一个请求相关的特征向量;通过基于上车地点和目的地搜索存储在数据库中的预先生成的路段表来确定至少一个路段相关的特征向量;并且基于至少一个请求相关的特征向量和至少一个路段相关的特征向量来确定ETA。该系统可以至少基于随时间变化的因素计算ETA,使得其可以更快地响应于对请求者的服务请求。
Description
技术领域
本申请一般涉及用于线上到线下服务的系统和方法,尤其涉及用于确定预计到达时间(Estimated Time of Arrival,ETA)的系统和方法。
背景技术
利用因特网技术的线上到线下服务(例如,出租车呼叫服务、食品配送服务)由于其便利性而变得越来越流行。当接收到由请求者发起的服务请求时,系统必须在向服务请求提供实际线上到线下服务之前立即提供响应服务请求的信息。例如,系统可以确定请求者指定的上车地点与目的地之间具有相关联的ETA的至少一个行程路线,并在请求者和/或提供者的终端上显示具有相关联的ETA的至少一个行程路线。然而,现有技术可能基于很少随时间变化的因素重复计算ETA,从而导致对请求者的响应速度慢。因此,期望提供更有效地确定ETA的系统和方法。
发明内容
针对上述基于很少随时间变化的因素重复计算ETA导致对请求者的响应速度慢的问题,本发明的目的之一在于提供更有效地确定ETA的系统和方法。为达到上述发明的目的,本发明提供的技术方案如下:
一方面,本发明提供了一种用于确定预计到达时间(ETA)的方法。所述方法可以包括:通过所述网络接收来自与服务请求者相关联的请求者终端的服务请求;从所述服务请求中获取上车地点、目的地和请求相关的信息;基于所述请求相关的信息确定至少一个请求相关的特征向量;通过搜索存储在数据库中的预先生成的路段表,基于所述上车地点和所述目的地来确定至少一个路段相关的特征向量;以及基于所述至少一个请求相关的特征向量和所述至少一个路段相关的特征向量,确定所述ETA。
另一方面,本发明提供了一种用于确定预计到达时间(ETA)的系统。该系统包括获取模块、请求相关的特征向量确定模块、路段相关的特征向量确定模块和ETA确定模块。所述获取模块接收来自与服务请求者相关联的请求者终端的服务请求;所述获取模块从所述服务请求中获取上车地点、目的地和请求相关的信息;所述请求相关的特征向量确定模块基于所述请求相关的信息确定至少一个请求相关的特征向量;所述路段相关的特征向量确定模块通过搜索存储在数据库中的预先生成的路段表,基于所述上车地点和所述目的地来确定至少一个路段相关的特征向量;以及所述ETA确定模块基于所述至少一个请求相关的特征向量和所述至少一个路段相关的特征向量,确定所述ETA。
另一方面,本发明提供了一种确定预计到达时间的装置,至少一个存储介质以及至少一个处理器;所述至少一个存储介质用于存储计算机指令;所述至少一个处理器用于执行所述计算机指令,以实现确定预计到达时间的方法。所述方法包括:通过所述网络接收来自与服务请求者相关联的请求者终端的服务请求;从所述服务请求中获取上车地点、目的地和请求相关的信息;基于所述请求相关的信息确定至少一个请求相关的特征向量;通过搜索存储在数据库中的预先生成的路段表,基于所述上车地点和所述目的地来确定至少一个路段相关的特征向量;以及基于所述至少一个请求相关的特征向量和所述至少一个路段相关的特征向量,确定所述 ETA。
另一方面,本发明提供了一种计算机可读存储介质,所述存储介质存储有计算机指令,当所述计算机指令被至少一个处理器执行时,实现确定预计到达时间的方法。所述方法包括:通过所述网络接收来自与服务请求者相关联的请求者终端的服务请求;从所述服务请求中获取上车地点、目的地和请求相关的信息;基于所述请求相关的信息确定至少一个请求相关的特征向量;通过搜索存储在数据库中的预先生成的路段表,基于所述上车地点和所述目的地来确定至少一个路段相关的特征向量;以及基于所述至少一个请求相关的特征向量和所述至少一个路段相关的特征向量,确定所述ETA。
另一方面,本发明还提供了又一种确定预计到达时间的系统,该系统包括:包括一组指令的至少一个存储设备;通信连接到网络的数据交换端口;与所述至少一个存储设备通信的至少一个处理器。当执行所述一组指令时,所述至少一个处理器被配置为使所述系统:通过所述网络,接收来自与服务请求者相关联的请求者终端的服务请求;从所述服务请求中获取上车地点、目的地和请求相关的信息;基于所述请求相关的信息确定至少一个请求相关的特征向量;通过搜索存储在数据库中的预先生成的路段表,基于所述上车地点和所述目的地来确定至少一个路段相关的特征向量;以及基于所述至少一个请求相关的特征向量和所述至少一个路段相关的特征向量,确定所述ETA。
在本发明中,所述请求相关的信息进一步包括时间信息、天气信息或所述服务请求的类型中的至少一个。
在本发明中,所述请求相关的信息包括所述服务请求者的个人信息、所述服务请求者的偏好设置、或所述服务请求者的行程习惯中的至少一个。
在本发明中,所述请求相关的信息包括服务提供者的个人信息、所述服务提供者的车辆信息、或所述服务提供者的驾驶习惯中的至少一个。
在本发明中,为了通过搜索存储在数据库中的预先生成的路段表,基于所述上车地点和所述目的地来确定至少一个路段相关的特征向量路段表,所述至少一个处理器被配置为进一步使所述系统:确定从所述上车地点到所述目的地位置的目标路线;基于所述目标路线确定路段序列,其特征在于,所述路段序列包括至少一个路段;以及通过搜索存储在所述数据库中的所述预先生成的路段表,为所述至少一个路段中的每一个检索所述路段相关的特征向量。
在本发明中,所述路段表包括关于对应于区域的道路的至少两个路段的至少两个预先生成的特征向量,并且由人工神经网络模型定期更新。
在本发明中,为了基于所述至少一个请求特定的特征向量和所述至少一个路段相关的特征向量,确定所述ETA,所述至少一个处理器被配置为进一步使所述系统:通过指定所述至少一个请求相关的特征向量和所述至少一个路段相关的特征向量作为ETA确定模型的输入,来确定所述ETA。
在本发明中,所述ETA确定模型是人工神经网络模型。
在本发明中,所述ETA确定模型通过以下过程训练,包括:获取与一组历史服务请求相关的信息,其特征在于,所述与所述一组历史服务请求相关的信息包括样本路段相关的特征向量、样本请求相关的特征向量,和分别与所述样本路段相关的特征向量和所述样本请求相关的特征向量相关联的样本ETA;通过指定对应的样本路段相关的特征向量和对应的样本请求相关的特征向量作为所述ETA确定模型的输入,来确定关于所述一组历史服务请求的预测ETA;以及所述通过最小化对应的样本ETA和关于所述一组历史服务请求的每个的所述预测ETA之间差,来迭代地训练所述ETA确定模型。
在本发明中,所述至少一个处理器被配置为使所述系统进一步:通过所述网络,将所述ETA发送到与所述服务请求者相关的所述请求者终端。
本申请的一部分的附加特征将在如下描述中详细解释,基于对如下内容和附图的审查或通过实现或操作实施例的学习,一部分的附加特征对本领域技术人员来说是显而易见的。本申请的特征可以通过对以下描述的具体实施例的各方面的方法、手段及其组合的实践或使用得以实现和达到。
附图说明
本申请将通过示例性实施例进行进一步描述。这些示例性实施例将通过附图进行详细描述。附图不是按比例绘制的。这些实施例是非限制性的示例性实施例,在附图的多个视图中,相同的附图标记表示相似的结构,其中:
图1是根据本申请的一些实施例所示的示例性线上到线下服务系统的示意图;
图2是根据本申请的一些实施例所示的计算设备的示例性硬件和/或软件组件的示意图;
图3是根据本申请的一些实施例所示的示例性处理引擎的框图;
图4A是根据本申请的一些实施例所示的用于确定预计到达时间(ETA) 的示例性过程的流程图;
图4B是根据本申请的一些实施例所述的电子信号编码和服务请求的示例性格式的示意图;
图5是根据本申请的一些实施例所示的示例性训练模块的框图;
图6是根据本申请的一些实施例所示的用于训练ETA确定模型的示例性过程的流程图;
图7是根据本申请的一些实施例所示的示例性路段相关的特征向量确定模块的框图;
图8是根据本申请的一些实施例所示的确定路段相关的特征向量的示例性过程的流程图;
图9A是根据本申请的一些实施例所示的呈现服务请求的示例性用户界面的示意图;
图9B是根据本申请的一些实施例所示的呈现与服务请求相关的ETA的示例性用户界面的示意图;
图9C是根据本申请的一些实施例所示的呈现与服务请求相关的ETA的示例性用户界面的示意图;以及
图9D是根据本申请的一些实施例所示的呈现与服务请求相关的ETA的示例性用户界面的示意图。
具体实施方式
以下描述是为了使本领域的普通技术人员能够实施和利用本申请,并且该描述是在特定的应用场景及其要求的环境下提供的。对于本领域的普通技术人员来讲,显然可以对所公开的实施例作出各种改变,并且在不偏离本申请的原则和范围的情况下,本申请中所定义的普遍原则可以适用于其他实施例和应用场景。因此,本申请并不限于所描述的实施例,而应该被给予与权利要求一致的最广泛的范围。
本申请中所使用的术语仅用于描述特定的示例性实施例,并不限制本申请的范围。如本申请使用的单数形式“一”、“一个”及“该”可以同样包括复数形式,除非上下文明确提示例外情形。还应当理解,如在本申请说明书中,术语“包括”、“包含”仅提示存在所述特征、整体、步骤、操作、组件和/或部件,但并不排除存在或添加一个或以上其他特征、整体、步骤、操作、组件、部件和/或其组合的情况。
根据以下对附图的描述,本申请的这些和其他的特征、特点以及相关结构元件的功能和操作方法,以及部件组合和制造经济性,可以变得更加显而易见,这些附图都构成本申请说明书的一部分。然而,应当理解的是,附图仅仅是为了说明和描述的目的,并不旨在限制本申请的范围。应当理解的是,附图并不是按比例绘制的。
本申请中使用了流程图用来说明根据本申请的一些实施例的系统所执行的操作。应当理解的是,流程图中的操作可以不按顺序执行。相反,可以按照倒序或同时处理各种步骤。此外,可以向流程图添加一个或以上其他操作。也可以从流程图中删除一个或以上操作。
此外,虽然本申请中的系统和方法主要是关于线上到线下服务来描述的,但是还应该理解,这仅是一个示例性实施例。本申请的系统或方法可以应用于任何其他类型的按需服务。例如,本申请的系统和方法还可应用于包括陆地、海洋、航空太空等或其任意组合的不同运输系统。运输系统的车辆可以包括出租车、私家车、挂车、公共汽车、火车、动车、高铁、地铁、船舶、航空器、宇宙飞船、热气球、无人驾驶车辆等或其任意组合。运输系统还可以包括用于经营和/或分配的任何运输系统,例如用于发送和/或接收快递的系统。本申请的系统或方法的应用场景可以包括网页、浏览器插件、客户端终端、定制系统、内部分析系统、人工智能机器人等或其任意组合。
本申请中的术语“乘客”、“请求者”、“服务请求者”和“客户”可用于表示请求或订购服务的个人、实体或工具,可互换使用。同样地,本申请描述的“司机”、“提供者”、“供应者”、“服务提供者”、“服务提供方”、“服务者”与“服务方”等也是可以互换的,是指提供服务或者协助提供服务的个人、工具或者其他实体等。本申请中的术语“用户”可表示用于请求服务、订购服务、提供服务或协助提供服务的个人、实体或工具。例如,用户可以是乘客、司机、操作员等或其任意组合。在本申请中,“乘客”和“乘客终端”可互换使用,“司机”和“司机终端”可互换使用。
在本申请中,术语“服务请求”和“订单”可以交换使用,其表示由乘客、请求方、服务请求者、客户、司机、提供方、服务提供方、供应方等或上述举例的任意组合所发起的请求。所述服务请求可以被乘客、请求方、服务请求者、客户、司机、提供方、服务提供方、供应方中的任一个接受。服务请求可以是计费的或免费的。
本申请中使用的定位技术可以包括全球定位系统(GPS)、全球卫星导航系统(GLONASS)、北斗导航系统(COMPASS)、伽利略定位系统、准天顶卫星系统(QZSS)、无线保真(WiFi)定位技术等或其任意组合。上述定位技术中的一种或多种可以在本申请中互换使用。
本申请的一个方面涉及基于从服务请求获取的上车地点、目的地和请求相关的信息,确定预计到达时间(ETA)的系统和方法。ETA可以指从服务请求的上车地点或服务请求者和/或服务提供者的当前位置行驶到服务请求的目的地的估计时间段。根据本申请,当系统收到运输服务的服务请求,并从该服务请求获取上车地点、目的地和请求相关信息,系统可以基于请求相关的信息确定至少一个请求相关的特征向量,并通过搜索存储在数据库中的预先生成的路段表,基于上车地点和目的地来确定至少一个路段相关的特征向量。预先生成的路段表可以包括至少两个路段相关的特征向量。系统可以进一步基于至少一个请求相关的特征向量和至少一个路段相关的特征向量来确定ETA。通过预生成路段表以存储路段相关特征,系统仅需要分析与订单相关的特征,从而提高确定ETA的速度和效率。
应该指出的是,总体而言,确定ETA是一种深深植根于互联网世界的技术。如果没有实时GPS定位以及终端与服务器之间的实时通信的可能性,则确定服务请求的目标路线,并确定与目标路线相对应的ETA是不可能的。因此,本申请中公开的技术方案也是一种深深植根于互联网时代的技术。
图1是根据本申请的一些实施例所示的示例性线上到线下服务系统的示意图。例如,线上到线下服务系统100可以是用于运输服务的线上到线下服务平台,例如呼叫出租车、专车服务、配送车辆、拼车、公共汽车服务、代驾、班车服务和产品(例如食品、药品、电器、服装等)配送服务。线上到线下服务系统100可以是在线平台,包括服务器110、网络120、请求者终端130、提供者终端140和存储器150。
在一些实施例中,服务器110可以是单个服务器,也可以是服务器组。所述服务器组可以是集中式的,也可以是分布式的(例如,服务器110可以是分布式的系统)。在一些实施例中,服务器110可以是本地的,也可以是远程的。例如,服务器110可以经由网络120访问存储于请求者终端130、提供者终端140、和/或存储器150中的信息和/或数据。又例如,服务器110可以直接连接到请求者终端130、提供者终端140和/或存储器150以访问存储的信息和/或数据。在一些实施例中,服务器110可以在云平台上实施。仅作为示例,该云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。在一些实施例中,服务器110可以在图2中所示的有一个或以上组件的计算设备200上实现。
在一些实施例中,服务器110可以包括处理引擎112。处理引擎112可以处理与服务请求相关的信息和/或数据以执行本申请描述的一个或多个功能。例如,处理引擎112可以从服务请求获取上车地点、目的地和请求相关的信息,并基于上车地点、目的地和请求相关的信息确定ETA。在一些实施例中,所述处理引擎112 可包括一个或者以上处理引擎(例如,单芯片处理引擎或多芯片处理引擎)。仅仅作为示例,处理引擎112可以包括一个或以上硬件处理器,如中央处理单元(CPU)、专用集成电路(ASIC)、专用指令集处理器(ASIP)、图形处理单元(GPU)、物理处理单元(PPU)、数字信号处理器(DSP)、现场可编程门阵列(FPGA)、可编程逻辑器件(PLD)、控制器、微控制器单元、精简指令集计算机(RISC)、微处理器或类似物、或其任意组合。
网络120可以促进信息和/或数据的交换。在一些实施例中,线上到线下服务系统100中的一个或以上组件(例如,服务器110、请求者终端130、提供者终端140、存储器150、以及定位系统160)可以通过网络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的用户A可以通过请求者终端130为用户B发送服务请求,或从服务器110处接收服务和/或资讯或指令。在一些实施例中,提供者可以是提供者终端140的用户。在一些实施例中,提供者终端130的用户可以为除该提供者之外的其他人。例如,提供者终端140的使用者C可以为使用者D通过提供者终端140接收服务请求和/或从服务器110处接收信息或指令。在一些实施例中,“请求者”、“服务请求者”和“请求者终端”可以互换使用,“提供者”、“服务提供者”和“提供者终端”可以互换使用。
在一些实施例中,请求者终端130可以包括移动设备130-1、平板电脑130-2、膝上型电脑130-3、车载设备130-4等或其任意组合。在一些实施例中,移动设备130-1 可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、增强现实设备等,或其任意组合。在一些实施例中,智能家居设备可以包括智能照明设备、智能电器控制设备、智能监控设备、智能电视、智能摄像机、对讲机等,或其任意组合。在一些实施例中,该可穿戴设备可包括智能手环、智能鞋袜、智能眼镜、智能头盔、智能手表、智能衣物、智能背包、智能配件等或其任意组合。在一些实施例中,智能移动设备可以包括移动电话、个人数字助理(PDA)、游戏设备、导航设备、销售点(POS)膝上型电脑、台式机等或其任意组合。在一些实施例中,虚拟现实设备和/或增强型虚拟现实设备可以包括虚拟现实头盔、虚拟现实眼镜、虚拟现实眼罩、增强现实头盔、增强现实眼镜、增强现实眼罩等,或其任意组合。例如,虚拟现实设备和/或增强现实设备可以包括Google GlassTM、Oculus RiftTM、HololensTM或Gear VRTM等。在一些实施例中,车载设备130-4可以包括车载计算机、车载电视等。在一些实施例中,请求者终端130可以是具有定位技术的设备,用于确定请求者和/或请求者终端130位置。
在一些实施例中,提供者终端140可以是与请求者终端130类似或相同的设备。在一些实施例中,提供者终端140可以是利用定位技术来定位提供者终端140 (例如,服务提供者)和/或提供者终端140的用户的位置的设备。
在一些实施例中,请求者终端130和/或提供者终端140可以与一个或以上其他定位设备通信以确定请求者、请求者终端130、提供者和/或提供者终端140 的位置。在一些实施例中,请求者终端130和/或提供者终端140可以将定位信息发送至服务器110。
存储器150可以存储数据和/或指令。在一些实施例中,存储器150可以存储从请求者终端130和/或提供者终端140获取的数据。在一些实施例中,存储器150可以储存服务器110用来执行或使用来完成本申请中描述的示例性方法的数据及/或指令。在一些实施例中,存储器150可包括大容量存储器、可移动存储器、易失性读写存储器、只读存储器(ROM)等或其任意组合。示例性的大容量存储器可以包括磁盘、光盘、固态磁盘等。示例性可移动存储器可以包括闪存驱动器、软盘、光盘、存储卡、压缩盘、磁带等。示例性易失性读写存储器可以包括随机存取内存(RAM)。示例性RAM可包括动态随机存取存储器(DRAM)、双倍数据速率同步动态随机存取存储器(DDR SDRAM)、静态随机存取存储器(SRAM)、晶闸管随机存取存储器(T-RAM)和零电容随机存取存储器(Z-RAM)等。示例性只读存储器可以包括掩模型只读存储器(MROM)、可编程只读存储器(PROM)、可擦除可编程只读存储器(PEROM)、电可擦除可编程只读存储器(EEPROM)、光盘只读存储器(CD-ROM)和数字多功能磁盘只读存储器等。在一些实施例中,存储器150可以在云平台上实现。仅作为示例,云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云,多层云等,或其任意组合。
在一些实施例中,存储器150可以连接到网络120以与线上到线下服务系统100中的一个或以上组件通信(例如,服务器110、请求者终端130、提供者终端 140等)。线上到线下服务系统100中的一个或以上组件可以经由网络120访问存储在存储器150中的数据或指令。在一些实施例中,存储器150可以直接连接到线上到线下服务系统100中的一个或以上组件或与之通信(例如,服务器110、请求者终端130、提供者终端140等)。在一些实施例中,存储器150可以是服务器110 的一部分。
在一些实施例中,线上到线下服务系统100中的一个或以上组件(例如,服务器110、请求者终端130、提供者终端140等)可以具有访问存储器150的许可。在一些实施例中,当满足一个或以上条件时,线上到线下服务系统100中的一个或以上组件可以读取和/或修改与请求者、提供者和/或公众有关的信息。例如,在完成一个服务后,服务器110可以读取和/或修改一个或以上用户的信息。又例如,当从请求者终端130接收到服务请求时,提供者终端140可以访问与所述请求者相关的信息,但提供者终端140无法修改请求者的相关信息。
在一些实施例中,线上到线下服务系统100中的一个或以上组件的信息交换可以通过请求服务来实现。服务请求的对象可以为任何产品。在一些实施方案中,产品可以是有形产品或非物质产品。有形产品可包括食品、药品、商品、化学产品、电器、服装、汽车、房屋、奢侈品等,或其任何组合。非物质产品可以包括服务产品、金融产品、知识产品、互联网产品等,或其任何组合。互联网产品可以包括个人主机产品、网站产品、移动互联网产品、商业主机产品、嵌入式产品等或上述举例的任意组合。移动互联网产品可以用于移动终端的软件、程序、系统等的软件或上述举例的任意组合。移动终端可以包括平板计算机、膝上型计算机、移动电话、个人数字助理(PDA)、智能手表、POS装置、车载计算机、车载电视、可穿戴装置等或其任意组合。例如,产品可以是在计算机或移动电话上使用的任何软件和/或应用。所述软件和/或应用程序可以与社交、购物、交通、娱乐、学习、投资等或上述举例的任意组合有关。在一些实施例中,所述与运输有关系统软件和/或应用程序可以包括出行软件和/或应用程序、车辆调度软件和/或应用程序、地图软件和/或应用程序等。在车辆调度软件和/或应用程序中,交通工具可以包括马、马车、人力车 (例如独轮手推车、自行车、三轮车)、汽车(例如,出租车、公共汽车、私家车)、火车、地铁、船舶、飞行器(例如,飞机、直升机、航天飞机、火箭、热气球)等其任意组合。
本领域普通技术人员应当理解,当执行线上到线下服务系统100的元件时,该元件可以通过电信号和/或电磁信号执行。例如,当请求者终端130处理诸如做出确定、识别或选择对象的任务时,请求者终端130可以在其处理器中操作逻辑电路以处理这些任务。当请求者终端130向服务器110发出服务请求时,服务请求者终端130的处理器可以生成编码服务请求的电信号。然后,请求者终端130的处理器可以将电信号发送到输出端口。如果请求者终端130通过有线网络与服务器110通信,输出端口可以物理连接到电缆,电缆可以进一步将电信号传输到服务器110的输入端口。如果请求者终端130经由无线网络与服务器110通信,请求者终端130 的输出端口可以是一个或以上天线,其将电信号转换为电磁信号。类似地,提供者终端140可以通过其处理器中的逻辑电路的操作来处理任务,并且经由电信号或电磁信号从服务器110接收指令。在诸如请求者终端130、提供者终端140和/或服务器110的电子设备内,当其处理器处理指令、发出指令和/或执行动作时,该指令和/或动作通过电信号执行。例如,当处理器从存储介质(例如,存储器150)检索或保存数据时,它可以将电信号发送到存储介质的读/写设备,其可以在存储介质中读取或写入结构化数据。该结构化数据可以以电信号的形式经由电子装置的总线传输至处理器。如本申请所示的,电信号是指一个电信号、一系列电信号和/或至少两个不连续的电信号。
图2是根据本申请的一些实施例所示的计算设备的示例性硬件和/或软件组件的示意图。在一些实施例中,服务器110和/或用户终端130可以在计算设备200 上实现。例如,处理引擎112可以在计算设备200上实施并执行本申请所公开的处理引擎112的功能。
计算设备200可用于实现如本申请所述的线上到线下服务系统100的任何组件。例如,处理引擎112可以在计算设备200上通过其硬件、软件程序、固件或其组合实现。为了方便起见,图中仅示出了一台计算机,但是本申请所描述的与线上到线下服务有关的计算机功能可以在多个类似平台上以分布式的方式实现,以分担处理负载。
例如,计算设备200可以包括连接到和/或连接到其的网络的通信端口250,以便于数据通信。计算设备200还可以包括处理器(例如,处理器220),可以以一个或以上处理器(例如,逻辑电路)的形式执行程序指令。例如,处理器220可以包括接口电路和其中的处理电路。接口电路可以被配置为从总线210接收电信号,其中电信号编码用于处理电路的结构化数据和/或指令。处理电路可以进行逻辑计算,然后将结论、结果和/或指令编码确定为电信号。然后,接口电路可以经由总线210 从处理电路发出电信号。示例性的计算机平台可以包括一个内部总线210、不同形式的程序存储和数据存储,例如,磁盘270、和只读存储器(ROM)230或随机存取内存(RAM)240,用于存储由计算机处理和/或传输的各种数据文件。示例性计算机平台也可以包括储存在ROM 230、RAM 240和/或其他类型的非暂时储存介质中的程序指令,以由处理器220执行。本申请的方法和/或流程可以以程序指令的方式实现。计算设备200还包括输入/输出(I/O)260,用来支持计算机和其他组件之间的输入/输出。计算设备200也可以通过网络通信接收编程和数据。
为了方便说明,计算设备200中仅描述了一个CPU和/或处理器。然而,需要注意的是,本申请中的计算设备200可以包括多个CPU和/或处理器,因此本申请中描述的由一个CPU和/或处理器执行的操作和/或方法步骤也可以由多个CPU 和/或处理器共同地或单独执行。例如,如果在本申请中,计算设备200的CPU和/ 或处理器执行步骤A和步骤B,应当理解的是,步骤A和步骤B也可以由计算设备 200的两个不同的CPU和/或处理器共同地或独立地执行(例如,第一处理器执行步骤A、第二处理器执行步骤B,或者第一和第二处理器共同地执行步骤A和步骤B)。
图3是根据本申请的一些实施例所示的示例性处理引擎的框图。处理引擎 112可包括获取模块310、请求相关的特征向量确定模块320、路段相关的特征向量确定模块330、ETA确定模块、训练模块350和通信模块360。
获取模块310可以被配置为从与服务请求者相关联的请求者终端130接收服务请求。服务请求可以是电子信号,包括从请求者终端130发送的6个部分(例如,参见图4B及其描述)。获取模块310也可以是配置用于从服务请求获取上车地点、目的地和请求相关的信息。
服务请求者可以通过指定上车地点和/或目的地来发起服务请求。在一些实施例中,服务请求者可以在请求者终端130执行的应用的用户界面(UI)(例如,参见图9A及其描述)上输入上车地点和/或目的地。在一些实施例中,线上到线下服务系统100可以自动推荐一个或以上候选上车地点和/或一个或以上候选目的地,以在UI上显示供服务请求者选择。
请求相关的特征向量确定模块320可以被配置用于基于请求相关的信息确定至少一个请求相关的特征向量。在一些实施例中,处理引擎112可以通过将请求相关的信息指定为诸如深度神经网络(DNN)模型的人工神经网络(ANN)模型的输入,来确定至少一个请求相关的特征向量。在一些实施例中,可以基于DNN预先确定包括至少两个请求相关的特征向量的特征数据库。处理引擎112可通过搜索特征数据库来确定至少一个请求相关的特征向量,并基于请求相关的信息检索至少一个请求相关的特征向量。
路段相关的特征向量确定模块330可以被配置为通过搜索存储在数据库 (例如,存储器150)中的预先生成的路段表,基于上车地点和目的地来确定至少一个路段相关的特征向量。路段相关的特征向量确定模块330可以被配置为确定从上车地点到目的地的包括至少一个路段的目标路线,并通过搜索预先生成的路段表,为目标路线的至少一个路段中的每一个检索路段相关的特征向量。关于至少一个路段相关的特征向量的确定的更多描述可以在本申请的其他地方找到(例如,参见图 8及其相关描述)。
ETA确定模块340可以被配置用于基于至少一个请求特定的相关特征向量和至少一个路段相关的特征向量来确定ETA。ETA可以指从服务请求的上车地或服务请求者和/或服务提供者的当前位置行驶到服务请求的目的地的估计时间段。在一些实施例中,ETA确定模块340可以通过将至少一个请求特定的相关特征向量和至少一个路段相关的特征向量指定为ETA确定模型的输入,来确定ETA。ETA确定模型可以响应于该输入而输出ETA。ETA确定模型可以是ANN模型,例如DNN模型。
训练模块350可以被配置为训练ETA确定模型。ETA确定模型可以是ANN 模型,例如DNN模型。训练模块350可以通过训练过程(例如,参见图6及其描述) 训练ETA确定模型。
通信模块360可以被配置为将ETA发送到接收设备(例如,请求者终端 130、提供者终端140)。在一些实施例中,可以以文本、图像、视频内容、音频内容、图形等的格式(例如,参见图9B-9D及其描述)在请求者终端130和/或提供者终端140上呈现ETA。在一些实施例中,与至少一个路线相关联的信息可以是使用任何合适的通信协议(例如,超文本传输协议(HTTP))地址解析协议(ARP)、动态主机配置协议(DHCP)、文件传输协议(FTP)等通过消息进行发送和/或接收。
处理引擎112中的模块可以通过有线连接或无线连接以互相连接或互相通信。有线连接可以包括金属线缆、光缆、混合电缆等或其任意组合。无线连接可以包括局域网络(LAN)、广域网络(WAN)、蓝牙、ZigBee网络、近场通信(NFC) 等或上述举例的任意组合。两个或多个模块可以合并成一个模块,任意一个模块可以被拆分成两个或多个单元。例如,获取模块310和通信模块360可以组合为单个模块,其可以获取服务请求和与服务请求有关的信息,并将ETA发送到接收设备。又例如,处理引擎112可以包括存储模块(图3中未显示),其可以被配置用于存储任何与ETA相关联的信息和/或数据(例如,与服务请求相关的上车地点、目的地、请求相关的信息等)。
图4A是根据本申请的一些实施例所示的用于确定预计到达时间(ETA) 的示例性过程的流程图。过程400可以通过存储在存储ROM 230或RAM 240中的一组指令(例如,应用程序)实现。处理器220和/或图3中的模块可以执行该指令,当执行该指令时,处理器220和/或模块可以被配置为执行过程400。以下所示过程的操作仅出于说明的目的。在一些实施例中,过程400可以通过未描述的一个或以上附加操作和/或不通过一个或以上本申请讨论的操作来完成。另外,如图4中所示和下面描述的过程的操作顺序不旨在是限制性的。
在410中,处理引擎112(例如,获取模块310)(例如,处理器220的接口电路)可以从与服务请求者相关联的请求者终端130接收服务请求。服务请求者可以通过指定上车地点和/或目的地来发起服务请求。在一些实施例中,服务请求者可以在请求者终端130执行应用的用户界面(UI)(例如,参见图9A及其描述) 上输入上车地点和/或目的地。在一些实施例中,线上到线下服务系统100可以自动推荐一个或以上候选上车地点和/或一个或以上候选目的地,以在UI上显示供服务请求者选择。
服务请求可以是运输服务请求,其将被分配给服务提供者,该服务提供者通过车辆为服务请求者提供运输服务。例如,服务请求者可以在请求者终端130(例如服务请求者的移动电话)上发起对出租车呼叫服务的请求。线上到线下服务系统 100可以将请求分配给服务提供者(例如,最靠近服务方请求者的可用司机),并将与该请求相关联的信息(例如,上车地点、目的地)发送到服务提供者的提供者终端140。然后,服务提供者可以在上车地点接服务请求者并将服务请求传送到目的地。又例如,服务请求者可以从请求者终端130上的餐馆发起对食物配送服务的请求。线上到线下服务系统100可以将请求分配给服务提供者(例如,距离该餐馆最近的可用配送者)和将与该请求相关联的信息(例如,餐馆的位置、服务请求者的位置)发送到服务提供者的提供者终端140。然后,服务提供者可以在餐厅领取食物并送给服务请求者。
服务请求可以是从请求者终端130发送的电子信号中的编码。此外,电子信号的格式可以包括六个部分,如图4B所示。电子信号格式的第一部分(也称为部分1)可以编码指示服务请求本身的开始的数据头。电子信号格式的第二部分(也称为部分2)可以编码指示与服务请求者相关联的身份号码的数据,例如电话号码、身份证号码、服务请求者的用户ID等。电子信号格式的第三部分(也称为部分3) 可以编码与上车地点和所请求的运输服务的目的地有关的信息。电子信号格式的第四部分(也称为部分4)可以包括与服务请求相关联的时间信息。电子信号格式的第五部分(也称为部分5)可以包括关于服务请求的类型的数据(也称为服务类型)。例如,如果服务请求者同意与其他请求者共享运输服务,服务请求的类型可以是拼车类型。电子信号格式的第六部分(也称为部分6)可以指示电子信号的结束。应当注意,提供电子信号的六个部分仅用于说明,电子信号的格式可包括任意数量的部分。例如,可以省略第五部分。又例如,电子信号的格式还可以包括一部分,其包括示出当启动服务请求时的天气状况的天气信息。
在一些实施例中,当用户第一次请求线上到线下服务系统100上的服务时线上到线下服务系统100可以为每个用户(例如,请求者或提供者)创建唯一的身份号码并对应地分配存储设备(例如,存储器150)的存储空间。每个存储空间可以被配置为存储与用户相关联的存储信息。基于用户的身份号码,线上到线下服务系统100可以访问对应于用户的存储空间并检索更多请求相关的信息,例如用户的个人信息、偏好设置、车辆信息、行程习惯、驾驶习惯等。服务请求者的个人信息可以包括但不限于姓名、昵称、国籍、专业、年龄、性别、联系信息(例如,移动电话号码、社交帐户),例如WeChatTM号、QQTM号、LinkedInTM账号或可用于联系用户的其他信息等,或其任何组合。服务请求者的偏好设置可以指用户设置的一个或以上偏好,基于该偏好设置,线上到线下服务系统100可以为服务请求者确定路线和/或分配服务提供者。例如,服务请求者可能更喜欢在早高峰时段选择收费公路。又例如,服务请求者可能更喜欢5分制中评分高于4.8分的服务提供者。偏好设置可以由用户在终端(例如,请求者终端130、提供者终端140)上预设。车辆信息可以包括与服务提供者的车辆有关的信息,例如车牌号、品牌、模型、购买日期、硬件条件、维护记录等。行程习惯和驾驶习惯都可以从与用户的历史服务请求(也称为历史服务订单)相关的信息中提取。例如,基于与服务请求者的历史服务请求相关的信息,线上到线下服务系统100可以提取出服务请求者具有比预定的接送时间晚两到十分钟的习惯。又例如,基于与服务提供者的历史服务请求相关的信息,线上到线下服务系统100可以提取出服务提供者是经验丰富的司机,跟其他人相比,能够更快更安全地驾驶。
电子信号中的上述部分可以按预定顺序放置。预定顺序可以是从部分1到部分6的顺序(例如,部分1、部分2、部分3、部分4、部分5、部分6)。或者,除了部分1和部分6之外,电子信号的其他部分可以随机排列(例如,部分1、部分3、部分4、部分2、部分5、部分6)。
在420中,处理引擎112(例如,获取模块310)(例如,处理器220的接口电路)可以从服务请求获取上车地点、目的地和请求相关的信息。如这里所使用的,上车地点可以指服务提供者(例如,司机)接收服务请求者(例如,乘客) 的起始位置,或者服务提供者(例如,交付)提取出的服务请求者订购产品的位置。请求相关的信息可以指影响确定服务请求的ETA的服务请求有关的信息。ETA可以指从服务请求的上车点或服务请求者和/或服务提供者的当前位置到服务请求的目的地的估计时间段。在一些实施例中,请求相关的信息可以包括但不限于时间信息、天气信息、服务类型,与服务请求者相关的信息(如个人信息、偏好设置和行程习惯)、与服务提供者相关的信息(如个人信息、车辆信息和驾驶习惯)等,或其任何组合。
在一些实施例中,处理引擎112可以直接通过从电信号解码服务请求,从服务请求获取上车地点、目的地和请求相关的信息。例如,处理引擎112可以解码服务请求,并从上述服务请求的第三部分获取上车地点和目的地。又如例,处理引擎112可以从解码的服务请求的第四部分获取与服务请求者相关联的时间信息,从解码的服务请求的第五部分获取服务类型。在一些实施例中,处理引擎112通过电信号解码服务请求并访问存储设备(例如,存储器150),以基于解码的服务的至少一部分检索更多请求相关的信息,从服务请求获取请求相关的信息。例如,处理引擎112可以从解码的服务请求的第二部分获取服务请求者的身份信息。处理引擎 112可以基于服务请求者的身份信息从存储设备(例如,存储器150)检索更多请求相关的信息。在一些实施例中,处理引擎112可以访问外部系统,以基于解码的服务请求检索更多请求相关的信息。例如,处理引擎112可以基于从解码的服务请求的第四部分获取的时间信息,访问天气预报系统并在未来时间段(例如,接下来的 15分钟、接下来的1小时)中检索天气信息。
在一些实施例中,在接收到服务请求之后,处理引擎112可以将服务请求分配给服务提供者。基于服务提供者的身份号码,处理引擎112可以访问存储设备 (例如,存储器150),并检索与服务提供者相关的更多请求相关的信息,例如服务提供者的车辆信息和驾驶习惯。
在一些实施例中,上车地点、目的地和请求相关的信息的至少一部分可以与确定目标路线和对应于该目标路线的ETA相关。例如,从上车地点到目的地可能存在至少两个候选路线。处理引擎112可以基于时间信息(例如,工作日上午8:30) 和服务请求者的偏好设置(如服务请求者更愿意支付通行费以节省早高峰时间),确定包括至少一个收费公路的候选路线作为目标路线。请求相关的信息可能会影响目标路线对应的ETA。在一些实施例中,时间信息和天气信息可能影响交通状况,这会进一步影响服务提供者的驾驶速度。例如,早高峰和/或晚高峰时段或非高峰时段都会影响交通状况。又如,晴天或下雨或下雪都会影响交通状况。在一些实施例中,服务类型(例如,拼车类型)可以增加其他服务请求者的等待时间。在另一个实施例中,服务请求者的行程习惯可以增加服务请求者的等待时间并影响服务提供者的驾驶速度。例如,服务请求者是否总是准时或迟到会影响等待时间。又例如,服务请求者是否要求服务提供者缓慢开车会影响等待时间。在另一实施例中,车辆信息(例如,品牌、型号、购买日期、硬件条件、维护记录)可能影响服务提供者的驾驶速度。例如,新购买或维护良好的跑车可能比十年前的轿车具有更快的驾驶速度。在另一个示例中,服务提供者的驾驶习惯可能会影响服务提供者的驾驶速度。例如,当服务提供者非常熟悉特定区域的道路状况时,他/她可能在该特定区域比其他区域开得更快。
在430中,处理引擎112(例如,请求相关的特征向量确定模块320(例如,处理器220的处理电路)可以基于请求相关的信息确定至少一个请求相关的特征向量。在一些实施例中,处理引擎112可以通过将请求相关的信息指定为诸如深度神经网络(DNN)模型的人工神经网络(ANN)模型的输入,来确定至少一个请求相关的特征向量。在一些实施例中,可以基于DNN预先确定特征数据库。特征数据库可以包括至少两个请求相关的特征向量。处理引擎112可通过搜索特征数据库并基于请求相关的信息检索至少一个请求相关的特征向量,来确定至少一个请求相关的特征向量。
在一些实施例中,请求相关的特征向量可以包括至少两个元素。请求相关向量的每个元素可以表示请求相关的信息的特征。请求相关的信息的特征可以包括但不限于服务提供者的时间特征、天气特征、服务类型、偏好特征和行程习惯特征、服务提供者的车辆特征和驾驶习惯特征。
在440中,处理引擎112(例如,路段相关的特征向量确定模块330)(例如,处理器220的接口电路)可以通过搜索存储在数据库(例如,存储器150)中的预先生成的路段表,基于上车地点和目的地来确定至少一个路段相关的特征向量。处理引擎112可以确定从上车地点到目的地的目标路线,该目标路线包括至少一个路段,并通过搜索预先生成的路段表,为目标路线的至少一个路段中的每个路段检索路段相关的特征向量。关于确定至少一个路段相关的特征向量的更多描述可以在本申请的其他地方找到(例如,参见图8及其相关描述)。
路段表可以包括至少两个路段相关的特征向量。可以针对与区域的道路 (例如,城镇、县、城市的地区、城市、省)相对应的至少两个路段预先生成至少两个路段相关的特征向量。至少两个路段相关的特征向量的每个可以对应于至少两个路段中的一个。如这里所使用的,“路段”可以指路线中的两个位置(例如,参见图8及其描述)之间的部分。在一些实施例中,路线可以由包括至少两个路段的路段序列表示。至少两个路段可以具有相同或不同的长度。在一些实施例中,路段相关的特征向量可以包括至少两个元素。路段相关的特征向量的每个元素可以表示路段的特征。路段的特征可以包括静态特征和动态特征。静态特征可以指很少根据时间变化的因素,对ETA的影响较小。静态特征可以包括但不限于路段的长度、车道数量、速度限制、道路水平、道路收费等,或其任何组合。动态特征可以指随时间变化的因素,对ETA具有更大的影响。动态特征可以包括但不限于当前时间、拥堵级别、路段中包括的交叉路口的交通灯等待时间等,或其任何组合。
可以基于模型预先生成路段表中的至少两个路段相关的特征向量。模型可以是ANN,例如DNN模型。其中,该至少两个路段相关的特征向量可以是基于模型的输出结果确定的,该模型的输出结果表示了与该至少两个路段相关联的特征,如静态特征和动态特征。在一些实施例中,该模型的输出结果可以采用数字或向量的方式表示与该至少两个路段相关联的特征中的每一个。例如,使用数字0、1和2 表明路段的拥堵级别。0表明不拥堵(即顺畅),1表明稍微拥堵(路段上的车辆缓行,如平均车速为10km/h),2表明非常拥堵(路段上的车辆几乎不动,如平均车速为0km/h)。又例如,使用(0,0,0)、(0,1,0)和(0,0,1)表明路段的拥堵级别。(0,0, 0)表明不拥堵,(0,1,0)表明稍微拥堵,(0,0,1)表明非常拥堵。在一些实施例中,可以使用模型周期性地更新至少两个路段相关的特征向量。关于路段表的更新的更多描述可以在本申请的其他地方找到(例如,参见图8及其相关描述)。
在450中,处理引擎112(例如,ETA确定模块340)(例如,处理器220 的处理电路)可以基于至少一个请求特定的相关特征向量和至少一个路段相关的特征向量来确定ETA。处理引擎112可以通过将至少一个请求特定的相关特征向量和至少一个路段相关的特征向量指定为ETA确定模型的输入来确定ETA。ETA确定模型可以响应于其输入而输出ETA。ETA确定模型可以是ANN模型,例如DNN模型。
可以基于与历史服务请求相关的信息来训练ETA确定模型。如这里所使用的,历史服务请求也被称为历史服务订单,是请求者和提供者之间完成的交易(例如,服务提供者已经将服务请求者或服务请求者订购的产品运送到指定的目的地)。关于ETA确定模型的训练的更多描述可以在本申请的其他地方找到(例如,参见图 6及其相关描述)。
在460中,处理引擎112(例如,通信模块360)(例如,处理器220的接口电路)可以将ETA传输到接收设备(例如,请求者终端130、提供者终端140)。在一些实施例中,ETA可以以文本、图像、视频内容、音频内容、图形等格式呈现在请求者终端130和/或提供者终端140上(例如,参见图9B-9D及其描述)。在一些实施例中,与至少一个路线相关联的信息可以使用任何合适的通信协议(例如,超文本传输协议(HTTP)、地址解析协议(ARP)、动态主机配置协议(DHCP)、文件传输协议(FTP)等),通过消息来发送和/或接收)。
在一些实施例中,与至少一个路线相关联的信息可以以文本、图像、视频内容、音频内容、图形等格式呈现在请求者终端130和/或提供者终端140上。在一些实施例中,与至少一个路线相关联的信息可以是使用任何合适的通信协议(例如,超文本传输协议(HTTP)、地址解析协议(ARP)、动态主机配置协议(DHCP)、文件传输协议(FTP)等)通过消息来发送和/或接收。
出于说明的目的,本申请描述了一种应用场景,处理引擎112接收运输服务的服务请求,并且请求者同意与其他请求者共享运输服务。进一步地,处理引擎 112确定服务请求的目标路线,并确定与目标路线类似的至少一条路线。应当注意,该应用场景仅用于说明目的,本申请可以应用于任何其他应用场景。
应该注意的是,上述仅出于说明性目的而提供,并不旨在限制本申请的范围。对于本领域的普通技术人员来说,根据本申请的教导可以做出多种变化和修改。然而,变形和修改不会背离本申请的范围。例如,操作410和操作420可以合并成单个操作,其中,处理引擎112可以接收服务请求并从服务请求获取上车地点、目的地位置和请求相关的信息。又例如,可以在示例性过程400的其他地方添加一个或以上其他可选操作(例如,存储操作)。在存储操作中,处理引擎112可以存储与ETA相关联的信息和/或数据(例如,上车地点、目的地、与服务请求相关的请求相关的信息等)。
图5是根据本申请的一些实施例所示的示例性训练模块的框图。训练模块 350可包括设置单元510、样本获取单元520、确定单元530和修改单元540。
设置单元510可以被配置为设置ETA确定模型(例如,DNN模型)的初始参数。ETA确定模型可以包括输入层、至少一个隐藏层和输出层。初始参数可以包括与输入层相关联的至少一个第一初始参数、与至少一个隐藏层相关联的至少一个第二初始参数、或者与隐藏层相关联的至少第三初始参数。初始参数可以是系统 100的默认设置,或者可以在不同情况下进行调整。
样本获取单元520可以被配置用于获取与一组历史服务请求相关的信息。如这里所使用的,历史服务请求也被称为历史服务订单,指请求者和提供者之间完成的交易(例如,服务提供者已经将服务请求者或服务请求者订购的产品运送到指定目的地)。处理引擎112可以从本申请中其他地方公开的存储设备(例如,存储器150)获取与一组历史服务请求有关的信息。
确定单元530可以被配置为通过指定相应的样本路段相关的特征向量和相应的样本请求相关的特征向量作为ETA确定模型的输入,确定与该组历史服务请求中的每一个相关的预测ETA。
修改单元540可以被配置为通过最小化与该组历史服务请求中的每个相关的样本ETA和预测ETA之间的差值,来迭代地训练ETA确定模型。例如,处理引擎112可以通过使用反向传播算法或梯度下降算法来修改/更新初始参数。梯度下降算法可以包括随机梯度下降、批量梯度下降、小批量梯度下降等。
训练模块350中的单元可以通过有线连接或无线连接彼此连接或通信。有线连接可以包括金属线缆、光缆、混合电缆等或其任意组合。无线连接可以包括局域网络(LAN)、广域网络(WAN)、蓝牙、紫蜂网络、近场通信(NFC)等或上述举例的任意组合。两个或以上的单元可以组合为单个模块,并且任何一个单元可以分为两个或以上子单元。例如,训练模块350可以包括用于存储任何与ETA确定模型相关联的信息(例如,初始参数)的存储单元(未示出)。又例如,训练模块 350中的单元可以分别包括存储子单元(未示出)。
图6是根据本申请的一些实施例所示的用于训练ETA确定模型的示例性过程的流程图。过程600可以通过存储在存储只读存储器(ROM)230或随机存取存储器(RAM)240中的一组指令(例如,应用程序)实现。处理器220和/或图5 中的单元可以执行该指令,当执行该指令时,处理器220和/或模块可以被配置为执行过程600。以下所示过程的操作仅出于说明的目的。在一些实施例中,过程600 可以通过未描述的一个或以上附加操作和/或不通过一个或以上本申请讨论的操作来完成。另外,如图4中所示和下面描述的过程的操作顺序不旨在是限制性的。
在610中,处理引擎112(例如,设置单元510)(例如,处理器220的处理电路)可以设置ETA确定模型(例如,DNN模型)的初始参数。ETA确定模型可以包括输入层、至少一个隐藏层和输出层。初始参数可以包括与输入层相关联的至少一个第一初始参数、与至少一个隐藏层相关联的至少一个第二初始参数、或者与输出层相关联的至少一个第三初始参数。初始参数可以是系统100的默认设置,或者可以在不同情况下可调节。
在620中,处理引擎112(例如,样本获取单元520)(例如,处理器220 的接口电路)可以获取与一组历史服务请求相关的信息。如这里所使用的,历史服务请求也被称为历史服务订单,是请求者和提供者之间完成的交易(例如,服务提供者已经将服务请求者或服务请求者订购的产品运送到指定目的地)。处理引擎112 可以从本申请中其他地方公开的存储设备(例如,存储器150)获取与一组历史服务请求有关的信息。
与该组历史服务请求相关的信息可以包括样本路段相关的特征向量、样本请求相关的特征向量、以及分别与该样本路段相关的特征向量和该样本请求相关的特征向量相关联的样本ETA。如这里所使用的,与该组历史服务请求中的每个相关的信息可以包括至少一个对应的样本路段相关的特征向量、对应的样本请求相关向量和对应的样本ETA。样本ETA可以指沿着对应于至少一个对应的样本路段相关的特征向量的至少一个路段行驶的实际时间。
在630中,处理引擎112(例如,确定单元530)(例如,处理器220的处理电路)可以通过指定对应的样本路段相关的特征向量和对应的样本请求相关的特征向量作为ETA确定模型的输入,来确定与该组历史服务请求中的每个相关的预测ETA。如操作620中所述,对应的样本路段相关的特征向量和对应的样本请求相关的特征向量可以对应于样本ETA,该样本ETA可以指到达目的地的实际时间。
在640中,处理引擎112(例如,修改单元540)(例如,处理器220的处理电路)可以通过最小化与一组历史服务请求中的每个相关的样本ETA和预测 ETA之间的差值,迭代地训练ETA确定模型。在一些实施例中,可以根据损失函数来评估样本ETA和预测ETA之间的差值。损失函数可以包括但不限于L1范数损失函数、L2范数损失函数、二次成本函数、交叉熵损失函数、对数似然成本函数等,或其任何组合。在一些实施例中,处理引擎112可以通过在每次迭代中使用反向传播算法或梯度下降算法来修改/更新ETA确定模型的参数。梯度下降算法可能包括随机梯度下降、批量梯度下降、小批量梯度下降等。可以通过不同策略修改/更新ETA 确定模型的参数。例如,如果当前迭代中的样本ETA与预测ETA之间的差异大于阈值(例如,在先前迭代中确定的差值),可以修改/更新ETA确定模型的部分或全部参数。如果在当前迭代中样本ETA与预测ETA之间的差值小于先前迭代中的差值,在当前迭代中可以不修改/更新ETA确定模型的参数。在一些实施例中,直到遍历所有训练数据或满足预设条件,处理引擎112才终止迭代并确定训练好的ETA确定模型。示例性预设条件可以包括在一个或以上连续迭代中,样本ETA与其对应的预测ETA之间的差值小于预设阈值。
应当注意,以上描述仅出于说明的目的,并不旨在限制本申请的范围。对于本领域的普通技术人员来说,可以根据本申请的描述,做出多种修改和变化。然而,这些修改和变化不会背离本申请的范围。例如,可以在示例性过程600中的其他地方添加一个或以上其他可选操作(例如,存储操作)。在存储操作中,处理引擎112可以存储任何与ETA确定模型相关联的信息和/或数据(例如,初始参数、一组历史服务请求等)。
图7是根据本申请的一些实施例所示的示例性路段相关的特征向量确定模块的框图。路段相关的特征向量确定模块330可以包括路线确定单元710、路段序列确定单元720和向量确定单元730。
路线确定单元710可以被配置用于确定从上车地点到目的地的目标路线。从上车地点到目的地的候选路线可能有多条。在一些实施例中,处理引擎112可以基于请求相关的信息的至少一部分从候选路线中确定目标路线。
路段序列确定单元720可以被配置用于基于目标路线确定路段序列。路段序列可以包括至少一个路段,并且可以对应于目标路线的方向。如结合操作420所述,“路段”可以指路线(例如,目标路线)的两个位置之间的部分。
向量确定单元730可以被配置为通过搜索存储在数据库(例如,存储器 150)中的预先生成的路段表,来检索目标路线的至少一个路段中的每个的路段相关的特征向量。路段表可以包括至少两个路段相关的特征向量。可以预先生成与区域 (例如,城镇、县、城市的地区、城市、省)的道路相对应的至少两个路段相关的至少两个路段相关的特征向量。
应当注意,以上描述仅出于说明的目的,并不旨在限制本申请的范围。对于本领域的普通技术人员来说,可以根据本申请的描述,做出多种修改和变化。然而,这些修改和变化不会背离本申请的范围。
图8是根据本申请的一些实施例所示的确定路段相关的特征向量的示例性过程的流程图。过程800可以通过存储在存储只读存储器(ROM)230或随机存取存储器(RAM)240中的一组指令(例如,应用程序)实现。处理器220和/或图7中的单元可以执行该指令,当执行该指令时,处理器220和/或模块可以被配置为执行过程800。以下所示过程的操作仅出于说明的目的。在一些实施例中,过程800 可以通过未描述的一个或以上附加操作和/或不通过一个或以上本申请讨论的操作来完成。另外,如图8中所示和下面描述的过程的操作顺序不旨在是限制性的。
在810中,处理引擎112(例如,路线确定单元710)(例如,处理器220 的接口电路)可以确定从上车地点到目的地的目标路线。从上车地点到目的地的候选路线可能有多条。在一些实施例中,处理引擎112可以基于请求相关的信息的至少一部分从候选路线中确定目标路线。如结合操作420所述,请求相关的信息可包括但不限于时间信息、天气信息、服务类型、与服务请求者相关联的信息(例如个人信息、偏好设置和行程习惯)、与服务提供者相关的信息(例如个人信息、车辆信息和驾驶习惯)等,或其任何组合。例如,在特定工作日的早高峰时段,若服务提供者车辆的车牌号不被限行,可以允许服务提供者在高速公路上开车,服务请求者更愿意支付通行费以节省时间,处理引擎112可以确定沿着一个或以上收费公路的目标路线,以节省服务请求者的时间。在一些实施例中,处理引擎112可以直接基于服务请求者的历史服务请求确定目标路线。例如,服务请求者可以在工作日的早高峰时段(例如,星期一的上午8点)将他的家指定为上车地点并将其工作场所指定为目的地。因为目标路线被存储为服务请求者的常规路线,处理引擎112可以直接从存储设备(例如,存储器150)获取目标路线。
在820中,处理引擎112(例如,路段序列确定单元820)(例如,处理器220的处理电路)可以基于目标路线确定路段序列。路段序列可以包括至少一个路段,并与目标路线的方向对应。如结合操作420所述,“路段”可以指路线(例如,目标路线)的两个位置之间的部分。
例如,对于特定目标路线,目标路线可包括如下所示的至少两个位置:
TR=[W1,W2,…,Wi…,Wm],(1≤i≤m) (1)
TR指目标路线。m指目标路线TR中的至少两个位置的数量,Wi指目标路线TR中特定位置i的地理信息,至少两个位置的序列与目标路线TR的方向对应。特定位置i的地理信息可以包括位置i的经度-纬度坐标。
因此,目标路线可以由下面所示的路段序列表示:
在830中,处理引擎112(例如,向量确定单元730)(例如,处理器220 的处理电路)可以通过搜索存储在数据库(例如,存储器150)中的预先生成的路段表,为目标路线的至少一个路段中的每个检索路段相关的特征向量。例如,对于路段处理引擎112可以搜索预先生成的路段表中的路段并检索路段的路段相关的特征向量。
路段表可以包括至少两个路段相关的特征向量。可以预先生成与区域(例如,城镇、县、城市的地区、城市、省)的道路相对应的至少两个路段相关的至少两个路段相关的特征向量。在一些实施例中,路段相关的特征向量可以包括至少两个元素。路段相关的特征向量的每个元素可以表示路段的特征。路段的特征可以包括静态特征和动态特征。静态特征可以指很少根据时间变化的因素,对ETA的影响较小。静态特征可以包括但不限于路段的长度、车道的数量、速度限制、道路水平、道路收费、路段等,或其任何组合。动态特征可以指随时间变化的因素,对ETA影响更大。动态特征可以包括但不限于当前时间、拥塞级别、路段中包括的交叉路口的交通灯等待时间等,或其任何组合。
可以基于模型预先生成路段表的至少两个路段相关的特征向量。模型可以是ANN,例如DNN模型。其中,该至少两个路段相关的特征向量可以是基于模型的输出结果确定的,该模型的输出结果表示了与该至少两个路段相关联的特征,如静态特征和动态特征。在一些实施例中,该模型的输出结果可以采用数字或向量的方式表示与该至少两个路段相关联的特征中的每一个。例如,使用数字0、1、2、3 表明路段的拥堵级别。0表明不拥堵(即顺畅),1表明稍微拥堵(路段上的车辆缓行,如平均车速为10km/h),2表明非常拥堵(路段上的车辆几乎不动,如平均车速为0km/h)。又例如,使用(0,0,0)表明不拥堵,使用(0,1,0)表明稍微拥堵,使用(0,0,1)表明非常拥堵。在一些实施例中,可以通过模型周期性地更新至少两个路段相关的特征向量。更新周期可以是任意值,例如30秒、2分钟、5分钟、半小时等。在一些实施例中,可以基于由至少两个用户(例如,请求者终端130、提供者终端140)的终端上传的信息,来更新至少两个路段相关的特征向量。例如,交叉路口可能发生交通事故,导致严重拥堵。基于由至少两个用户的终端周期性(例如,每五秒)或实时上传的位置信息(例如,GPS信息),处理引擎112可以发现许多车辆堵在该交叉路口处,并更新与交叉路口相对应的路段的拥堵程度。在一些实施例中,可以基于从外部系统获取的信息来更新至少两个路段相关的特征向量。例如,城市的交通部门可以在其网站上发布临时调整交叉路口的绿灯持续时间的通知。处理引擎112可以得知该通知,并更新对应于交叉路口的路段的交通灯等待时间。处理引擎112可以通过周期性地更新路段表,来确定更接近路段实际条件的路段相关的特征向量。
本申请实施例可能带来的有益效果包括但不限于:1.通过搜索预先生成的路段表来确定路段相关的特征向量,可以节省线上计算ETA所需要的计算机运算资源;2.通过搜索预先生成的路段表来确定路段相关的特征向量,可以加快确定ETA 的响应时间。确定ETA的响应时间可以指从接收ETA请求的时刻到确定ETA的时刻的时间。使用本申请中其他地方公开的过程确定ETA的响应时间可以加快到微秒级。需要说明的是,不同实施例可能产生的有益效果不同,在不同的实施例里,可能产生的有益效果可以是以上任意一种或几种的组合,也可以是其他任何可能获得的有益效果。
应当注意,以上描述仅出于说明的目的,并不旨在限制本申请的范围。对于本领域的普通技术人员来说,可以根据本申请的描述,做出多种修改和变化。然而,这些修改和变化不会背离本申请的范围。
图9A是根据本申请的一些实施例所示的呈现服务请求的示例性用户界面的示意图。用户界面900A可以由终端(例如,请求者终端130、提供者终端140) 呈现。用户界面900可以包括用于呈现与服务请求相关联的信息的一个或以上用户界面元素(也称为“UI元素”)。每个UI元素可以是和/或包括,例如,一个或以上按钮、图标、复选框、讯息框、文本框、数据区、检索区等。
例如,如图所示,用户界面900A可以包括用于呈现服务类型的UI元素 902(例如,快车、出租车、专车、拼车)。用户界面900还可以包括用于呈现接收与上车地点相关联的输入的输入框的UI元素904,和用于呈现接收与目的地相关联的输入的输入框的UI元素906。此外,用户界面900还可以包括用于呈现选项(例如,“快车拼车”、“拒绝快车拼车”)的UI元素908,该选项可以用于使用户选择是否同意与其他请求者共享运输服务。
图9B是根据本申请的一些实施例所示的呈现与服务请求相关的ETA的示例性用户界面的示意图。用户界面900B可以在服务请求者(例如,乘客)的请求者终端130上显示,表示服务请求者正在等待来自服务提供者(例如,司机)吴的接送。用户界面900B还可以呈现ETA为27:35,包括等待时间2分钟,该ETA由线上到线下服务系统100确定。
图9C是根据本申请的一些实施例所示的呈现与服务请求相关的ETA的示例性用户界面的示意图。用户界面900C可以显示在服务提供者(例如,司机)的提供者终端140上,呈现服务提供者已到达上车地点并正在等待服务提供者(例如,乘客)胡。用户界面900C还可以呈现ETA 30:17,包括等待时间5分钟,该ETA由线上到线下服务系统100确定的。
图9D是根据本申请的一些实施例所示的呈现与服务请求相关的ETA的示例性用户界面的示意图。可以在服务请求者(例如,乘客)的请求终端130和/或服务提供者(例如,司机)的提供者终端140上显示用户界面900D,显示服务请求者和服务提供者正在前往目的地的途中。用户界面900D还可以呈现其当前位置和由线上到线下服务系统100确定的ETA为12:17。
上文已对基本概念做了描述,显然,对于阅读此申请后的本领域的普通技术人员来说,上述发明公开仅作为示例,并不构成对本申请的限制。虽然此处并没有明确说明,本领域技术人员可能会对本申请进行各种修改、改进和修正。该类修改、改进和修正在本申请中被建议,所以该类修改、改进、修正仍属于本申请示范实施例的精神和范围。
同时,本申请使用了特定词语来描述本申请的实施例。例如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本申请至少一个实施例相关的某一特征、结构或特性。因此,应当强调并注意的是,本说明书中在不同位置两次或以上提及的“一实施例”或“一个实施例”或“一替代性实施例”并不一定系指同一实施例。此外,本申请的一个或以上实施例中的某些特征、结构或特性可以进行适当的组合。
此外,本领域的普通技术人员可以理解,本申请的各方面可以通过若干具有可专利性的种类或情况进行说明和描述,包括任何新的和有用的过程、机器、产品或物质的组合,或对其任何新的和有用的改良。相应地,本申请的各个方面可以完全由硬件执行、可以完全由软件(包括韧体、常驻软件、微代码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“单元”、“模块”或“系统”。此外,本申请公开的各方面可以采取体现在一个或以上计算机可读介质中的计算机程序产品的形式,其中计算机可读程序代码包含在其中。
计算机可读信号介质可能包含一个内含有计算机程序编码的传播数据信号,例如在基带上或作为载波的一部分。此类传播信号可以有多种形式,包括电磁形式、光形式等或任何合适的组合形式。计算机可读信号介质可以是除计算机可读存储介质之外的任何计算机可读介质,该介质可以通过连接至一个指令执行系统、装置或设备以实现通讯、传播或传输供使用的程序。位于计算机可读信号介质上的程序编码可以通过任何合适的介质进行传播,包括无线电、电缆、光纤电缆、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 (22)
1.一种用于确定预计到达时间的方法,其特征在于,所述方法包括:
通过网络接收来自与服务请求者相关联的请求者终端的服务请求;
从所述服务请求中获取上车地点、目的地和请求相关的信息;
基于所述请求相关的信息确定至少一个请求相关的特征向量;
通过搜索存储在数据库中的预先生成的路段表,基于所述上车地点和所述目的地来确定至少一个路段相关的特征向量;以及
基于所述至少一个请求相关的特征向量和所述至少一个路段相关的特征向量,确定所述预计到达时间;
其中,所述至少一个路段相关的特征向量反映路段的静态特征和动态特征,所述路段表定期更新,所述路段表通过如下方式生成:
获取与区域的道路相对应的至少两个路段;以及
基于模型生成与所述至少两个路段相关的特征向量,所述至少两个路段相关的特征向量的每个可以对应于所述至少两个路段中的一个。
2.根据权利要求1所述的方法,其特征在于,所述请求相关的信息包括时间信息、天气信息或所述服务请求类型中的至少一个。
3.根据权利要求1或2所述的方法,其特征在于,所述请求相关的信息包括所述服务请求者的个人信息、所述服务请求者的偏好设置、或所述服务请求者的行程习惯中的至少一个。
4.根据权利要求1或2所述的方法,其特征在于,所述请求相关的信息包括服务提供者的个人信息、所述服务提供者的车辆信息、或所述服务提供者的驾驶习惯中的至少一个。
5.根据权利要求1所述的方法,其特征在于,所述通过搜索存储在数据库中的预先生成的路段表,基于所述上车地点和所述目的地来确定至少一个路段相关的特征向量包括:
确定从所述上车地点到所述目的地位置的目标路线;
基于所述目标路线确定路段序列,其中,所述路段序列包括至少一个路段;以及
通过搜索存储在所述数据库中的所述预先生成的路段表,为所述至少一个路段中的每一个检索所述路段相关的特征向量。
6.根据权利要求1所述的方法,其特征在于,确定所述预计到达时间的响应时间为微秒级。
7.根据权利要求1所述的方法,其特征在于,所述基于所述至少一个请求相关联的特征向量和所述至少一个路段相关的特征向量,确定所述预计到达时间包括:
通过指定所述至少一个请求相关的特征向量和所述至少一个路段相关的特征向量作为预计到达时间确定模型的输入,来确定所述预计到达时间。
8.根据权利要求7所述的方法,其特征在于,所述预计到达时间确定模型是人工神经网络模型。
9.根据权利要求7或8所述的方法,其特征在于,所述预计到达时间确定模型的训练方法包括:
获取与一组历史服务请求相关的信息,其中,所述与所述一组历史服务请求相关的信息包括样本路段相关的特征向量、样本请求相关的特征向量、和分别与所述样本路段相关的特征向量和所述样本请求相关的特征向量相关联的样本预计到达时间;
通过指定对应的样本路段相关的特征向量和对应的样本请求相关的特征向量作为所述预计到达时间确定模型的输入,来确定所述一组历史服务请求的预测预计到达时间;以及
通过最小化对应的样本预计到达时间和所述一组历史服务请求的每一个的所述预测预计到达时间之间差,来迭代地训练所述预计到达时间确定模型。
10.根据权利要求1所述的方法,其特征在于,所述方法进一步包括:
通过所述网络,将所述预计到达时间发送到与所述服务请求者相关联的所述请求者终端。
11.一种确定预计到达时间的系统,其特征在于,所述系统包括获取模块、请求相关的特征向量确定模块、路段相关的特征向量确定模块和预计到达时间确定模块;
所述获取模块被配置为通过网络接收来自与服务请求者相关联的请求者终端的服务请求;
所述获取模块被配置为从所述服务请求中获取上车地点、目的地和请求相关的信息;
所述请求相关的特征向量确定模块被配置为基于所述请求相关的信息确定至少一个请求相关的特征向量;
所述路段相关的特征向量确定模块被配置为通过搜索存储在数据库中的预先生成的路段表,基于所述上车地点和所述目的地来确定至少一个路段相关的特征向量;其中,所述至少一个路段相关的特征向量反映路段的静态特征和动态特征,所述路段表定期更新,所述路段表通过如下方式生成:
获取与区域的道路相对应的至少两个路段;以及
基于模型生成与所述至少两个路段相关的特征向量,所述至少两个路段相关的特征向量的每个可以对应于所述至少两个路段中的一个;以及
所述预计到达时间确定模块被配置为基于所述至少一个请求相关的特征向量和所述至少一个路段相关的特征向量,确定所述预计到达时间。
12.根据权利要求11所述的系统,其特征在于,所述请求相关的信息包括时间信息、天气信息或所述服务请求的类型中的至少一个。
13.根据权利要求11或12所述的系统,其特征在于,所述请求相关的信息包括所述服务请求者的个人信息、所述服务请求者的偏好设置、或所述服务请求者的行程习惯中的至少一个。
14.根据权利要求11或12所述的系统,其特征在于,所述请求相关的信息包括服务提供者的个人信息、所述服务提供者的车辆信息、或所述服务提供者的驾驶习惯中的至少一个。
15.根据权利要求11所述的系统,其特征在于,所述路段相关的特征向量确定模块进一步用于:
确定从所述上车地点到所述目的地位置的目标路线;
基于所述目标路线确定路段序列,其中,所述路段序列包括至少一个路段;以及
通过搜索存储在所述数据库中的所述预先生成的路段表,为所述至少一个路段中的每一个检索所述路段相关的特征向量。
16.根据权利要求11所述的系统,其特征在于,所述预计到达时间确定模块确定所述预计到达时间的响应时间为微秒级。
17.根据权利要求11所述的系统,其特征在于,所述预计到达时间确定模块进一步用于:
通过指定所述至少一个请求相关的特征向量和所述至少一个路段相关的特征向量作为预计到达时间确定模型的输入,来确定所述预计到达时间。
18.根据权利要求17所述的系统,其特征在于,所述预计到达时间确定模型是人工神经网络模型。
19.根据权利要求11所述的系统,其特征在于,所述系统进一步包括训练模块,用于:
获取与一组历史服务请求相关的信息,其中,所述与所述一组历史服务请求相关的信息包括样本路段相关的特征向量、样本请求相关的特征向量,和分别与所述样本路段相关的特征向量和所述样本请求相关的特征向量相关联的样本预计到达时间;
通过指定对应的样本路段相关的特征向量和对应的样本请求相关的特征向量作为所述预计到达时间确定模型的输入,来确定所述一组历史服务请求的预测预计到达时间;以及
通过最小化对应的样本预计到达时间和所述一组历史服务请求的每一个的所述预测预计到达时间之间差,来迭代地训练所述预计到达时间确定模型。
20.根据权利要求11所述的系统,其特征在于,所述系统进一步包括通信模块,用于通过网络将所述预计到达时间发送到与所述服务请求者相关的所述请求者终端。
21.一种确定预计到达时间的装置,其特征在于,包括至少一个存储介质以及至少一个处理器;
所述至少一个存储介质用于存储计算机指令;
所述至少一个处理器用于执行所述计算机指令,以实现如权利要求1~10任一项所述的确定预计到达时间的方法。
22.一种计算机可读存储介质,所述存储介质存储有计算机指令,当所述计算机指令被至少一个处理器执行时,实现如权利要求1~10任一项所述确定预计到达时间的方法。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811468237.7A CN110782648B (zh) | 2018-12-03 | 2018-12-03 | 确定预计到达时间的系统和方法 |
PCT/CN2018/120448 WO2020113626A1 (en) | 2018-12-03 | 2018-12-12 | Systems and methods for determining estimated time of arrival |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811468237.7A CN110782648B (zh) | 2018-12-03 | 2018-12-03 | 确定预计到达时间的系统和方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN110782648A CN110782648A (zh) | 2020-02-11 |
CN110782648B true CN110782648B (zh) | 2022-02-18 |
Family
ID=69382911
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201811468237.7A Active CN110782648B (zh) | 2018-12-03 | 2018-12-03 | 确定预计到达时间的系统和方法 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN110782648B (zh) |
WO (1) | WO2020113626A1 (zh) |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111813881A (zh) * | 2020-06-10 | 2020-10-23 | 北京嘀嘀无限科技发展有限公司 | 用于行程信息处理的方法、装置、设备和存储介质 |
CN112241873A (zh) * | 2020-06-12 | 2021-01-19 | 广元量知汇科技有限公司 | 基于大数据的智慧政务云平台 |
CN113409596A (zh) * | 2020-06-28 | 2021-09-17 | 节时科技(深圳)有限公司 | 一种全自动智能控流交通系统及智能交通控流方法 |
CN111882112B (zh) * | 2020-07-01 | 2024-05-10 | 北京嘀嘀无限科技发展有限公司 | 一种预测到达时间的方法和系统 |
US20230004931A1 (en) * | 2021-06-30 | 2023-01-05 | Transportation Ip Holdings, Llc | Systems and methods for estimating time of arrival of vehicle systems |
CN114997747B (zh) * | 2022-07-29 | 2022-11-04 | 共幸科技(深圳)有限公司 | 一种实现上下游供需平衡的代驾服务调度方法及装置 |
Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104217605A (zh) * | 2013-05-31 | 2014-12-17 | 张伟伟 | 一种公交车到站时间测算方法和装置 |
CN104637334A (zh) * | 2015-02-10 | 2015-05-20 | 中山大学 | 一种公交车到站时间实时预测方法 |
CN104794886A (zh) * | 2014-08-12 | 2015-07-22 | 北京东方车云信息技术有限公司 | 网络租车系统中打车费用预估系统和方法 |
CN106096767A (zh) * | 2016-06-07 | 2016-11-09 | 中国科学院自动化研究所 | 一种基于lstm的路段行程时间预测方法 |
CN106127344A (zh) * | 2016-06-28 | 2016-11-16 | 合肥酷睿网络科技有限公司 | 一种基于网络的公交车到站时间预测方法 |
CN106205125A (zh) * | 2016-07-27 | 2016-12-07 | 安徽聚润互联信息技术有限公司 | 一种救护车抵达时间实时预测系统及方法 |
CN107111794A (zh) * | 2015-01-11 | 2017-08-29 | 微软技术许可有限责任公司 | 预测和利用地图服务中出行时间的可变性 |
CN107305742A (zh) * | 2016-04-18 | 2017-10-31 | 滴滴(中国)科技有限公司 | 用于确定预计到达时间的方法和设备 |
CN108288096A (zh) * | 2017-01-10 | 2018-07-17 | 北京嘀嘀无限科技发展有限公司 | 用于估算行程时间、模型训练的方法及装置 |
WO2018204157A1 (en) * | 2017-05-05 | 2018-11-08 | Walmart Apollo, Llc | Predicting realistic time of arrival for queue priority adjustment |
WO2018213996A1 (en) * | 2017-05-22 | 2018-11-29 | Beijing Didi Infinity Technology And Development Co., Ltd. | Systems and methods for determining estimated time of arrival |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
TW200902942A (en) * | 2007-03-09 | 2009-01-16 | Tomtom Int Bv | Navigation device assisting road traffic congestion management |
JP6336570B2 (ja) * | 2013-04-17 | 2018-06-06 | トムトム ナビゲーション ベスローテン フエンノートシャップTomTom Navigation B.V. | 移動情報を提供する方法及び装置 |
CN104123841B (zh) * | 2014-08-14 | 2016-08-24 | 苏州大学 | 一种车辆到站时间的获取方法及系统 |
WO2017180208A1 (en) * | 2016-04-13 | 2017-10-19 | Google Inc. | Wide and deep machine learning models |
CN106679685B (zh) * | 2016-12-29 | 2020-07-17 | 鄂尔多斯市普渡科技有限公司 | 一种用于车辆导航的行车路径规划方法 |
-
2018
- 2018-12-03 CN CN201811468237.7A patent/CN110782648B/zh active Active
- 2018-12-12 WO PCT/CN2018/120448 patent/WO2020113626A1/en active Application Filing
Patent Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104217605A (zh) * | 2013-05-31 | 2014-12-17 | 张伟伟 | 一种公交车到站时间测算方法和装置 |
CN104794886A (zh) * | 2014-08-12 | 2015-07-22 | 北京东方车云信息技术有限公司 | 网络租车系统中打车费用预估系统和方法 |
CN107111794A (zh) * | 2015-01-11 | 2017-08-29 | 微软技术许可有限责任公司 | 预测和利用地图服务中出行时间的可变性 |
CN104637334A (zh) * | 2015-02-10 | 2015-05-20 | 中山大学 | 一种公交车到站时间实时预测方法 |
CN107305742A (zh) * | 2016-04-18 | 2017-10-31 | 滴滴(中国)科技有限公司 | 用于确定预计到达时间的方法和设备 |
CN106096767A (zh) * | 2016-06-07 | 2016-11-09 | 中国科学院自动化研究所 | 一种基于lstm的路段行程时间预测方法 |
CN106127344A (zh) * | 2016-06-28 | 2016-11-16 | 合肥酷睿网络科技有限公司 | 一种基于网络的公交车到站时间预测方法 |
CN106205125A (zh) * | 2016-07-27 | 2016-12-07 | 安徽聚润互联信息技术有限公司 | 一种救护车抵达时间实时预测系统及方法 |
CN108288096A (zh) * | 2017-01-10 | 2018-07-17 | 北京嘀嘀无限科技发展有限公司 | 用于估算行程时间、模型训练的方法及装置 |
TW201829982A (zh) * | 2017-01-10 | 2018-08-16 | 大陸商北京嘀嘀無限科技發展有限公司 | 用於預估到達時間之方法及系統 |
WO2018204157A1 (en) * | 2017-05-05 | 2018-11-08 | Walmart Apollo, Llc | Predicting realistic time of arrival for queue priority adjustment |
WO2018213996A1 (en) * | 2017-05-22 | 2018-11-29 | Beijing Didi Infinity Technology And Development Co., Ltd. | Systems and methods for determining estimated time of arrival |
Also Published As
Publication number | Publication date |
---|---|
CN110782648A (zh) | 2020-02-11 |
WO2020113626A1 (en) | 2020-06-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110782648B (zh) | 确定预计到达时间的系统和方法 | |
CN111862585B (zh) | 用于交通预测的系统和方法 | |
CN109478275B (zh) | 分配服务请求的系统和方法 | |
CN110537212B (zh) | 确定预估到达时间的系统与方法 | |
US20200011692A1 (en) | Systems and methods for recommending an estimated time of arrival | |
US11398002B2 (en) | Systems and methods for determining an estimated time of arrival | |
US11011057B2 (en) | Systems and methods for generating personalized destination recommendations | |
WO2017088828A1 (en) | Systems and methods for allocating sharable orders | |
CN108713326B (zh) | 分配按需服务请求的系统及方法 | |
US20200300650A1 (en) | Systems and methods for determining an estimated time of arrival for online to offline services | |
CN109313036B (zh) | 路线规划的系统及方法 | |
JP2019527871A (ja) | 到着予定時刻を決定するシステム及び方法 | |
CN108780562B (zh) | 更新服务序列的系统和方法 | |
CN110839346A (zh) | 用于分配服务请求的系统和方法 | |
CN110402370B (zh) | 用于确定服务请求的推荐信息的系统和方法 | |
CN112154473A (zh) | 用于推荐上车点的系统和方法 | |
CN111133484A (zh) | 用于评估与指定的驾驶服务相关的调度策略的系统和方法 | |
CN112243487A (zh) | 用于按需服务的系统和方法 | |
CN110998615A (zh) | 用于确定服务请求费用的系统和方法 | |
CN111386542B (zh) | 用于分配按需服务请求的系统和方法 | |
CN110832513B (zh) | 用于按需服务的系统和方法 | |
CN113924460B (zh) | 确定服务请求的推荐信息的系统和方法 | |
WO2021022487A1 (en) | Systems and methods for determining an estimated time of arrival |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |