一种用于处理运输请求的方法和系统与流程

本申请基于并要求2017年8月16日提交的申请号为201710702067.3的中国申请，和2018年1月4日提交的申请号为15/862,393的美国专利申请的优先权，前述申请的全部内容以引用方式被包含于此。

本申请涉及处理运输请求，尤其涉及通过检测适合每个运输请求的队列来排队运输请求的方法和系统。

背景技术：

网约车平台(例如嘀嘀在线打车)接收乘客的运输请求，然后派遣至少一个运输服务提供者(例如，出租车司机，私家车主等)来履行服务请求。在一天的特定时间段、特定区域内，网约车平台可能接收到比该区域内可用服务车辆的容量更多的运输请求。因此，所述运输请求在被处理之前通常在队列中排队。但是，根据所述运输请求的原始请求特征，所述运输请求在被处理之前可能需要在该队列中等待很长时间。与此同时，可能有其他队列可用于容纳更多请求并快速处理它们。因此，仅仅根据其原始请求特征将运输请求保持在队列中是低效的。

用于处理所述运输请求的方法和系统被设计为可以识别等待时间较短的运输请求队列，以此提高网约车平台的效率。

技术实现要素：

本申请的实施例提供用于处理运输请求的由计算机实施的方法。所述方法包括从终端设备接收区域中的运输请求。所述方法还包括确定放置运输请求的第一队列，所述第一队列与排队区相关联，所述运输请求包括在第一队列中被处理之前的第一估计等待时间。所述方法进一步包括确定与所述排队区相关联的第二队列，所述运输请求包括在所述第二队列中被处理之前的第二估计等待时间，其中所述第二估计等待时间短于所述第一估计等待时间。所述方法还包括向终端设备提供与所述第二队列有关的信息。

本申请的另一个实施例进一步提供用于处理运输请求的系统。所述系统可以包括通信接口，所述通信接口被配置为从终端设备接收区域中的运输请求。所述系统进一步包括存储器和耦合到通信接口和存储器的至少一个处理器。所述至少一个处理器被配置为确定放置运输请求的第一队列，所述第一队列与排队区相关联，所述运输请求包括在第一队列中被处理之前的第一估计等待时间。所述至少一个处理器进一步被配置为确定与排队区相关联的第二队列，所述运输请求包括在所述第二队列中被处理之前的第二估计等待时间，所述第二估计等待时间短于第一估计等待时间。所述至少一个处理器还被配置为向终端设备提供与第二队列有关的信息。

本申请的又一实施例提供一种非暂时性计算机可读介质，所述介质存储一组指令。当所述组指令由电子设备的至少一个处理器执行时，可以使电子设备执行处理运输请求的方法。所述方法包括从终端设备接收区域中的运输请求。所述方法还包括确定放置运输请求的第一队列，所述第一队列与排队区相关联，所述运输请求包括在所述第一队列中被处理之前的第一估计等待时间。所述方法进一步包括确定与排队区相关联的第二队列，所述运输请求包括在所述第二队列中被处理之前的第二估计等待时间，其中所述第二估计等待时间短于第一估计等待时间。所述方法还包括向终端设备提供与第二队列有关的信息。

应当理解的是，前面的一般描述和下面的详细描述都仅是示例性和说明性的，并不构成对本发明的限定。

附图说明

图1是根据本申请一些实施例所示的用于处理运输请求的一种示例性系统的示意图。

图2是根据本申请一些实施例所示的区域中的排队区的示意图。

图3是根据本申请一些实施例所示的队列中的运输请求的示例图。

图4是根据本申请一些实施例所示的在终端设备上显示的示例性用户界面。

图5是根据本申请一些实施例所示的用于处理运输请求的一种示例性方法的流程图。

图6是根据本申请一些实施例所示的用于在多个队列中确定第二队列的一种示例性方法的流程图。

具体实施方式

现在将详细参考示例性实施例，示例性实施例的示例在相应的附图中示出。任何可能的情况下，在整个附图中将使用相同的附图标记来指代相同或相似的部分。

本申请一个方面涉及一种用于处理运输请求的系统。

图1是根据本申请一些实施例所示的用于处理运输请求的系统100的示意图。

系统100是用于处理运输请求的通用服务器或专用设备。可以预期的是，系统100可以是单独的系统(例如服务器)或服务器的集成组件。因为处理运输请求需要大量的计算资源，所以在一些实施例中，系统100优选地作为单独的系统实施。在一些实施例中，系统100包括子系统，所述子系统中的一些是远程的。

在一些实施例中，如图1所示，系统100包括通信接口102、处理器104和存储器114。处理器104进一步包括多个模块：例如，队列确定单元106、时间估计单元108、交互单元110、激活单元112等。这些模块(以及任何相应的子模块或子单元)是处理器104的硬件单元(例如，集成电路的部分)，其被设计为与其他组件一起使用或执行程序的一部分。所述程序可以被存储在计算机可读介质上，当其被处理器104执行时，所述程序实施一个或多个方法。尽管图1示出的单元106-112全部在处理器104内，但可以预期的是这些单元可以分布在多个处理器中，所述处理器彼此位置邻近或彼此远离。在一些实施例中，系统100在云中或在单独的计算机/服务器上实施。

通信接口102被配置为从终端设备120接收区域中的运输请求122。终端设备120是能够与用户交互的任何合适的设备，例如智能手机、平板电脑、可穿戴设备、计算机等。终端设备120可以是用户携带的移动设备。运输请求122包括请求特征，例如乘客的当前位置，所请求的运输的起点和目的地、出发时间、服务类型、服务车辆类型等。在一些实施例中，乘客的当前位置可以用作运输请求122的位置。

在一些实施例中，通信接口102可以是综合业务数字网(isdn)卡、电缆调制解调器、卫星调制解调器、或提供数据通信连接的调制解调器。又例如，通信接口102可以是局域网(lan)卡，所述局域网卡提供数据通信连接到兼容局域网。无线链路也可以被通信接口102实施。在这样的实施中，通信接口102经由网络发送和接收电信号、电磁信号、或光信号，这些信号传送代表各种类型的信息的数字数据流。所述网络通常包括蜂窝通信网络、无线局域网(wlan)、广域网(wan)等。

在一些实施例中，系统100基于所请求的运输服务的来源来确定可以被预设的区域。例如，所述区域可以是与其他六边形区域相邻的六边形区域。可以预期的是，所述区域可以是除六边形以外的其他形状，例如圆形、正方形、长方形等。在一些实施例中，所述区域是基于终端设备120的当前位置动态确定的形状和大小。

图2是根据本申请一些实施例所示的区域200中排队区的示意图。例如，如图2所示，区域200是六边形区域。在一些实施例中，区域200包括多个排队区，例如202和204。每个排队区与一个或多个请求队列相关联。例如，排队区202与请求队列2022和2024相关联。

因为提供队列服务消耗大量的计算和存储资源，所以激活单元112被配置为仅当满足队列激活条件时才激活队列。例如，激活单元112确定所述区域中的运输请求的数量，并基于所确定的数量来激活队列。例如，所述队列激活条件包括所述运输请求的数量超过服务车辆的可用容量的预设值。又例如，所述队列激活条件包括在预定时间段内做出请求。可以预期的是，排队条件包括其他合适的条件，以及所述条件的任何组合。

排队区可以根据区域内的历史请求来确定，并且与至少一个区域属性相关联。所述区域属性包括地理属性、可用性属性、服务类型属性等。例如，所述地理属性可以定义排队区的地理范围，使得只有源自所述地理范围内的请求才可以与所述排队区和所述排队区内的队列相关联。所述可用性属性可以定义排队区的可用时间段。例如，所述排队区只能在上午9点到晚上10点之间接收请求。所述服务类型属性可以定义在排队区内可以接收的请求的服务类型。所述服务类型包括拼车服务、非拼车服务、豪华车服务等中的至少一个。

可以预期的是，与排队区相关联的队列包括队列属性。所述队列的至少一个队列属性是相同的并且对应于至少一个区域属性。例如，与排队区202相关联的队列2022和2024具有与排队区202相同的地理属性。但是，所述队列可以具有不同的可用属性和服务类型属性。例如，队列2022是拼车队列，队列2024是非拼车队列。

队列确定单元106确定与用于放置运输请求122的排队区相关联的队列。如上所述，运输请求122包括请求位置、请求源、请求目的地、出发时间、服务类型、服务车辆类型等的请求特征。基于运输请求122的请求特征和上述区域属性，队列确定单元106确定运输请求122的排队区。例如，如图2所示，队列确定单元106确定运输请求122的请求位置是否落入排队区202内，如果是，则将运输请求122分配给排队区202。在已经确定排队区202之后，队列确定单元106根据队列属性和所述请求特征来进一步确定排队区202内的运输请求122的队列。例如，运输请求122是非拼车请求，因此可以被放置到非拼车队列2022。

时间估计单元108可以估计运输请求122在队列中被处理之前的等待时间。在一些实施例中，时间估计单元108可以确定队列的处理速度，确定所述队列中所述运输请求的位置，并估计所述运输请求的等待时间。图3是根据本申请一些实施例所示的队列中的运输请求的示例图。例如，如图3所示，时间估计单元108确定队列2022的处理速度是每个请求5分钟，并且运输请求122是队列2022中的第五个请求。即，在队列2022中的运输请求122之前有四个请求。因此，运输请求122被处理之前的估计等待时间302是5×4分钟。可以设想，还可以考虑例如交通状况、天气状况等的其他因素来估计队列中的请求的所述等待时间。例如，在极端天气条件下，所述估计等待时间增加。

为了向乘客提供更好的建议，系统100进一步确定运输请求122的处理时间是否可以通过将其放置在另一个队列中来减少。通过识别这样的另一个队列的存在，系统100可以向所述乘客建议替代的旅行计划。

在一些实施例中，队列确定单元106进一步确定与排队区(例如，202)相关联的另一队列。如上所述，排队区202与拼车队列2022和非拼车队列2024相关联。尽管由于相互服务类型属性(即，拼车)，运输请求122已经被初始放置在拼车队列2022中，但是队列确定单元106可以进一步确定与运输请求122的排队区202相关联的队列。例如，队列确定单元106确定具有一个队列属性的队列，所述队列属性不同于其中放置有运输请求122的所述确定的队列。例如，队列确定单元106可以确定非拼车队列2024不同于具有拼车的服务类型属性的拼车队列2022。在一些实施例中，所述“另一个队列”可以是与区域202相关联的任何其他队列。

时间估计单元108可以估计运输请求122在新确定的队列(例如2024)中被处理之前的另一个等待时间。例如，如图3所示，如果运输请求122被放置在队列2024中，则只有两个请求会在运输请求122之前。因此，在运输请求122之前的估计等待时间304将是比估计等待时间302更短的5×2分钟。因此，通过将运输请求122放置在队列2024中，运输请求122的所述等待时间可以减少10分钟。

可以设想，排队区202可以包括两个以上队列。在那种情况下，系统100可以确定除了与排队区202相关联的队列2022之外的一组队列，确定如果运输请求122被放置在各个队列中的估计等待时间，并且识别具有最短估计等待时间的所述队列。

基于所述确定的较短的估计等待时间，返回参考图1，交互单元110可以向终端设备120提供与具有较短的估计等待时间的所述队列(例如，2024)相关的信息。例如，可以使用通信接口102将所述信息发送到终端设备120。在一些实施例中，所述信息包括所述估计等待时间(例如，302和304)之间的时间差，以表示通过切换到另一个队列所述乘客可以节省的等待时间的量。在一些实施例中，所述信息包括修改运输请求122的建议，使得经修改的运输请求122适于被放置在具有所述较短或最短估计等待时间的队列中。在一些实施例中，如果适于被放置的话，所述建议还可以指示修改运输请求122的估计服务费。在一些实施例中，当等待时间显著减少时，例如当所述时间差大于或等于预设值时，交互单元110可以提供修改运输请求122的建议。

此外，如果乘客同意所述建议，则通信接口102从终端设备120接收修改运输请求120的指令。基于所述接收到的指令，交互单元110修改运输请求120并将修改后的运输请求120放置在相应的队列(例如2024)中。

图4是根据本申请一些实施例所示的在终端设备上显示的示例性用户界面400。

如图4所示，用户界面400包括显示部分402、404和406。显示部分402显示与放置运输请求122的第一队列(例如，2022)相关联的所述估计等待时间(例如，302)。显示部分402还显示使用不同队列(例如2024)的所述建议和所述减少的等待时间。显示部分404显示与所述第一队列(例如2022)相关的信息，例如估计的费用。显示部分406显示与所述建议的第二队列(例如2024)相关联的信息，例如所述估计的费用和所述乘客发送用于修改运输请求122的指令的选项。

本申请的另一方面涉及用于处理运输请求的方法。

图5是根据本申请一些实施例所示的用于处理运输请求的一种示例性方法500的流程图。例如，方法500由包括至少一个处理器的系统100来实施，并且方法500包括如下所述的步骤s502-s508。

在步骤s502中，系统100可以从终端设备接收区域中的运输请求122。所述运输请求包括请求特征，例如乘客的当前位置，所请求的运输的起点和目的地、出发时间、服务类型、服务车辆类型等。在一些实施例中，所述区域可以由系统100基于所请求的运输服务的起点来预先设定。例如，所述区域可以是与其他六边形地区相邻的六边形地区。可以想到的是，所述区域可以具有除六边形以外的形状，例如圆形、正方形、长方形等。在一些实施例中，所述区域可以具有基于所述终端设备的当前位置动态确定的形状和大小。所述区域包括多个排队区。每个排队区可以与一个或多个请求队列相关联。

当队列激活条件满足时激活队列。例如，激活单元112可以确定所述区域中的多个运输请求，并且基于所确定的数量来激活所述队列。所述队列激活条件包括超过服务车辆的可用容量预设值的运输请求的数量。又例如，所述队列激活条件包括请求在预设时间段内进行。

排队区可以基于所述区域内的历史请求来确定，并且与至少一个区域属性相关联。所述区域属性包括地理属性、可用性属性、服务类型属性等。例如，所述地理属性可以定义所述排队区的地理范围，使得只有源自所述地理范围内的请求才可以与所述排队区和所述排队区内的队列相关联。所述可用性属性可以定义所述排队区的可用时间段。例如，所述排队区只能在上午9点到晚上10点之间接收请求。所述服务类型属性可以定义在所述排队区内可以接收的请求的服务类型。所述服务类型包括拼车服务、非拼车服务、豪华车服务等中的至少一个。

可以预期的是，与排队区相关联的队列包括队列属性。所述队列的至少一个所述队列属性是相同的并且对应于至少一个所述区域属性。例如，排队区可以与第一队列和第二队列相关联。所述第一和第二队列可以具有与排队区相同的地理属性。但是，所述第一和第二个队列可以具有不同的可用性属性和服务类型属性。例如，所述第一队列是拼车队列，所述第二队列是非拼车队列。

在步骤s504中，系统100可以确定与排队区相关联的放置运输请求的第一队列。如上所述，运输请求122包括请求位置、请求源、请求目的地、出发时间、服务类型、服务车辆类型等的请求特征。基于所述运输请求的所述请求特征和上述区域属性，系统100可以例如基于在所述排队区内所述运输请求的确定来确定所述运输请求的所述排队区。所述排队区确定后，系统100可以根据队列属性和请求特征，进一步确定在所述排队区内的所述运输请求的所述第一队列。例如，所述运输请求是一个非拼车请求，因此可以被放置到所述第一个队列中，这是一个非拼车队列。

同时，系统100可以在运输请求在所述第一队列中被处理之前估计其第一等待时间。在一些实施例中，系统100可确定所述第一队列的处理速度，确定第一队列中的所述运输请求的位置，并估计所述运输请求的所述第一等待时间。

在步骤s506中，系统100可以进一步确定与排队区相关联的第二队列。在第二队列中被处理之前，运输请求可具有第二估计等待时间。第二估计等待时间比第一估计等待时间短。在一些实施例中，第二队列可以具有与第一队列不同的一个队列属性。第二个队列的底线是第二个队列应该与第一个队列在同一个队列区中。例如，第一个队列是一个拼车队列，第二个队列是非拼车队列，第一个和第二个队列都处在排队区中。当第二队列被确定时，系统100可以在运输请求在第二队列中被处理之前估计其第二等待时间。

可以设想，所述排队区包括两个以上队列。因此，系统100可以执行用于在多个队列中确定所述第二队列的方法。图6是根据本申请一些实施例所示的用于在多个队列中确定第二队列的一种示例性方法600的流程图。例如，方法600可以由系统100作为单独的方法或方法600的一部分来实施。方法600包括如下所述的步骤s602-s606。

在步骤s602中，系统100可以确定与所述排队区相关联的一组第二队列。如上所述，所述组第二队列处在所述排队区中，并且在同一排队区中包括与所述第一队列不同的至少一个属性。

在步骤s604中，系统100可以确定被放置在各个队列中的所述运输请求的估计等待时间。已经讨论了确定所述估计等待时间的过程，并且在此不再重复。

在步骤s606中，系统100可以识别具有最短估计等待时间的队列。因此，系统100可以识别能够减少所述运输请求的所述等待时间但仍然满足所述运输请求的大部分要求的第二队列。

返回参考图5，在步骤s508中，系统100可以向所述终端设备提供与具有较短的估计等待时间的所述第二队列有关的信息。所述信息包括所述第一和第二估计时间之间的时间差，以表示通过切换到另一个队列乘客可以节省的等待时间的量。在一些实施例中，所述信息包括修改所述运输请求的建议，使得经修改的运输请求适于被放置在具有所述较短估计等待时间的所述队列中。在一些实施例中，如果适于被放置的话，所述建议还可以指示修改运输请求的估计服务费。在一些实施例中，当等待时间显著减少时，例如当所述第一和第二估计等待时间的时间差大于或等于预设值时，系统100可以提供修改所述运输请求的所述建议。

此外，如果所述乘客同意所述建议，则系统100可以从所述终端设备接收修改所述运输请求的指令。基于所述接收到的指令，然后系统100可以修改所述运输请求并将所述修改后的运输请求放置在所述第二队列中。

本申请的另一方面涉及存储指令的非暂时性计算机可读介质，所述指令在被执行时使得一个或多个处理器实施如上所述方法。所述计算机可读介质包括易失性或非易失性、磁性、半导体、磁带、光学、可移动、不可移动或其他类型的计算机可读介质或计算机可读存储设备。例如，如所披露的，所述计算机可读介质可以是其上存储有计算机指令的存储设备或存储器模块。在一些实施例中，所述计算机可读介质可以是其上存储有计算机指令的盘或闪存驱动器。

对于本领域技术人员显而易见的是，可以对本申请所披露的系统和相关方法进行各种修改和变化。考虑到本申请所披露的系统和相关方法的说明书和实践，其他实施例对于本领域技术人员将是显而易见的。

本申请的说明书和示例仅是示例性的，真正的范围由下述权利要求及其等同物指示。