CN105027177A - 交通工具管理系统 - Google Patents

Abstract

本发明揭示一种交通工具请求管理系统，其具有：服务器(10)，其经布置以与多个交通工具请求装置(12)通信；及多个交通工具(14)，其各自装备有具有路径规划及导航功能性的装置(200)。在接收到交通工具请求时，在所述交通工具请求与交通工具请求的现有群集中的请求相关的情况下，服务器将所述交通工具请求分配到所述现有群集。如果所述交通工具请求与交通工具请求的现有群集中的所述请求不相关，那么将所述交通工具请求用于产生新群集。基于与新请求相关联的搭客位置与现有请求的搭客位置的接近度来评估新交通工具请求与现有群集的交通工具请求之间的关系。使用基于与所述群集相关联的区域中的交通工具请求的地理密度及时间密度选择的参数来评估所述关系。当所述群集达到关于与其相关联的最旧请求的存续期的阈值或替代地达到最大大小阈值时，所述群集中的请求经历匹配过程以将交通工具匹配到每一请求以满足所述请求。

Description

交通工具管理系统

技术领域

本发明涉及用于管理交通工具请求(例如，用户对出租车或其它类似形式的运输工具的请求)的方法及系统。特定来说，但不是排他性地，本发明涉及用于将交通工具请求匹配到交通工具以满足所述请求的方法及系统。

背景技术

近年来，随着公众采用位置感知移动装置(例如，智能电话)，已创建许多软件应用程序(或“app”)来改善预订及叫出租车的体验。这些app的实例包含：Hailo–http://hailocab.com；myTaxi–http://www.mytaxi.net/；及Taxi Magic–http://taximagic.com。

通过在位置感知移动装置(例如，具有GNSS(全球导航卫星系统)信号接收及处理功能性的位置感知移动装置)上使用此类app，即使所述用户本身不知晓其周围环境，所述用户也可容易地请求出租车去到其当前位置。

举例来说，在使用Hailo app时，在用户的移动装置上向用户展示以用户的当前位置为中心的地图，从而指示距用户的位置最近的可用出租车的实时位置及对每一出租车到达所述位置将花费的时间的估计。此信息是从服务器系统下载，所述系统从每一出租车中的位置感知装置接收周期性更新。用户可通过在其装置的触摸屏上触摸出表示出租车的图标来选择出租车，且接着经由服务器将订单请求发送到所选择的出租车。如果司机接受订单请求，那么确认消息被发送到所述用户。还向用户提供司机的简档图片(profile picture)、与所述司机相关联的用户评级、所选择的出租车的详细资料及出租车应到达搭客位置的时间的实时倒计时；该倒计时是估计，因为其不考虑可能对出租车造成延迟的交通、道路施工及其它此类事件。用户还可在地图上看见所选择的出租车在接近搭客位置时的当前位置。同样经由服务器向用户发送出租车已到达搭客位置的通知。在行程已完成之后，用户便可使用信用卡或类似形式的非现金付费对旅程进行付费(假设所述卡的详细资料先前已与用户在服务器上的账户关联)。接着，用户从服务器接收确认行程的详细资料及对所支付金额的接收的消息。用户还可在行程完成之后借此机会对其司机进行评级。

尽管已关于通过使用位置感知装置来叫出租车做出改进，但本申请人相信仍有进一步改进用于管理交通工具请求的方法及系统的余地。特定来说，本申请人已意识到仍有在将交通工具请求匹配到交通工具(例如，出租车)的方式方面进一步改进此类方法及系统的余地。

发明内容

根据本发明的第一方面，提供一种在服务器处管理交通工具请求的方法，所述服务器可访问指示多个交通工具中的每一者的当前位置的数据，所述方法包括：

在服务器处接收多个交通工具请求；

产生一或多个群集，每一群集包括多个交通工具请求；以及

将交通工具匹配到所述群集或每一群集内的每一相应交通工具请求。

本发明涉及一种用于管理交通工具请求的方法。所述方法涉及在服务器处接收多个交通工具请求。所述服务器知晓多个交通工具(例如，出租车)中的每一者的当前位置。首先将交通工具请求指派到群集，且在逐群集基础上将交通工具匹配到所述请求。

将了解，至少根据本发明的此方面，本发明并非仅仅在逐个个别请求的基础上(即，当每一请求进入时)通过参考交通工具的当前位置距与交通工具请求相关联的位置(例如，所要搭客位置)的接近度来将交通工具分配到交通工具请求。而是，首先使交通工具请求群集化，其中在逐群集基础上将交通工具分配到每一群集内的请求。因此，举例来说，只有在给定群集“完整”之后，第一个请求(即，给定群集中的最早请求)才会被分配交通工具。接着，分配可考虑到指派到群集的所有请求及其相关联位置，从而使得能够优化交通工具与请求的匹配。这与常规系统(例如，上文描述的app，其中用户能够基于向用户显示的一或多个可用出租车与用户的当前位置的接近度从所述出租车中选择出租车)形成对比。在其它常规系统中，同样基于出租车的当前位置为最接近用户的当前位置的出租车，出租车可被自动分配到给定请求。在这些系统中，将出租车分配到给定请求而不考虑任何其它请求。

已发现，通过在将交通工具分配或匹配到交通工具请求之前将所述请求群集化为群组，可以在用户(例如，请求者)的等待时间方面更好地优化的方式实行交通工具到请求的匹配。通过一直等到已接收一群请求(其根据本文中描述的某些准则形成群集)，且接着将交通工具分配到所述群集中的请求，有可能对请求及可用交通工具具有较高水平的概览，使得可改善用户的平均等待时间。以此方式，本发明可解决与常规技术(其中对交通工具的每一请求被个别地匹配到最接近的可用交通工具)相关联的某些缺陷。常规方式可导致一些用户的等待时间较短，但这是以牺牲其它用户为代价的。此类系统不允许在减少多个用户的平均等待时间方面进行优化。本发明的基于群集的系统还提供更好地平衡交通工具用户的需求与交通工具司机的需求的能力，例如，通过对用户的等待时间与交通工具司机为满足交通工具请求而将行进的距离进行平衡。这与在逐请求基础上将最近交通工具分配到交通工具请求的系统形成对比，所述系统可潜在地导致一个交通工具操作者行进短距离就可到达搭客(位置)，但是下一个交通工具操作者要行进过长的距离，用户的等待时间也会发生同样的情况。

此外且根据本发明的第二方面，提供一种交通工具请求管理系统，所述系统包括可访问指示多个交通工具中的每一者的当前位置的数据的服务器，所述服务器包括：

通信构件，其经布置以接收多个交通工具请求；

处理构件，其经布置以产生一或多个群集，每一群集包括多个交通工具请求；以及

处理构件，其经布置以将交通工具匹配到所述群集或每一群集内的每一相应交通工具请求。

本发明在此进一步方面中可包含关于本发明的第一方面所描述的任何或所有特征，且反之亦然，前提是所述特征不相互矛盾。因此，在未在本文中明确陈述的情况下，本发明的系统可包括用于实行所描述的方法的步骤中的任何者的构件。

用于实行计算机实施方法的步骤中的任何者的处理构件可包括经配置(例如，经编程)以实行所述步骤中的任何者的一或多个处理器的集合。给定步骤可使用与任何其它步骤相同或不同的处理器集合来实行。可使用处理器集合的组合来实行任何给定步骤。

本发明在其实施例中的任一者中可适用于关于任何类型的交通工具将交通工具匹配到交通工具请求。所述交通工具优选为可连同其司机一起被请求以将一或多个乘客从搭客位置运载到下客位置的交通工具。在尤其优选实施例中，所述交通工具为出租车或类似形式的运输工具。所述交通工具可为机动交通工具，例如，出租车、轿车、豪华轿车或其它动力交通工具。在其它实施例中，所述交通工具可为人力交通工具，例如自行车或人力车。

如上文论述，本发明针对一种交通工具请求管理系统。换句话说，人或(通常)多个不同的人可凭借其提出使交通工具在特定位置(“搭客位置”)及(在一些情形中额外地)在特定时间迎接他或她的请求的系统。所述系统用于将交通工具(或在一些情形中，若干交通工具)指派到每一请求。本发明的交通工具请求系统尤其可适用于管理出租车请求(例如，在大城镇及城市中)，但将理解，所述系统可在适当的情况下与任何类型的交通工具请求一起使用。

所述方法包括在服务器处接收多个交通工具请求，且所述系统包括具有用于接收多个交通工具请求的通信构件的服务器。虽然在本文中称为“服务器”，但将了解，可使用任何合适中央控制器，且本文中的用词“服务器”可由“中央控制器”取代。

在优选实施例中，从多个第一装置的集合接收多个交通工具请求。所述第一装置可为可用于提出交通工具请求的任何合适装置。举例来说，所述第一装置可为具有固定位置的装置，例如个人计算机或其它计算资源。所述第一装置还可包括经布置以定位在建筑物内或定位在户外迎接点(例如，旅馆、酒吧、餐馆、车站或类似者)且通常仅与单个搭客位置相关联的装置。然而，在优选实施例中，所述第一装置包括可由用户携带的移动装置，例如，移动电话、PDA、平板计算机或类似者。

根据本发明，服务器可访问至少指示多个交通工具中的每一者的当前位置的数据。每一交通工具为用于满足交通工具请求的可用交通工具。在一些实施例中，所述服务器的通信构件经布置以接收至少指示所述多个交通工具中的每一者的当前位置的数据。所述方法可包括服务器接收指示所述多个交通工具中的每一者的当前位置的数据。所述服务器可包括存储至少指示所述多个交通工具中的每一者的当前位置的数据存储构件。每一交通工具优选地与司机相关联。因此，可认为交通工具的位置对应于司机的位置。

优选地，服务器可访问关于每一交通工具随时间推移的位置的位置数据。优选地，指示所述多个交通工具中的每一者的当前位置的数据为指示多个第二装置的集合中的每一者的当前位置的数据，所述第二装置中的每一者与相应交通工具相关联。举例来说，第二装置可以任何合适方式安装在相应交通工具内或与所述交通工具相关联，使得所述第二装置的位置将对应于所述交通工具的位置。优选地，所述数据为关于每一第二装置随时间推移的位置的位置数据。优选地，所述服务器与各自与交通工具相关联的多个第二装置的集合中的每一者通信。所述服务器的通信构件优选地经额外布置以接收指示所述多个交通工具中的每一者的当前位置的数据及优选地经额外布置以接收指示多个第二装置的集合中的每一者的当前位置的数据，所述第二装置中的每一者与相应交通工具相关联。所述服务器(例如，其通信构件)可接收关于所述第二装置且优选地每一第二装置及因此与第二装置相关联的交通工具随时间推移的位置的位置数据。

指示交通工具的当前位置的数据优选地与指示与所述数据有关的交通工具的数据相关联。指示交通工具的数据可直接或间接地识别交通工具，且允许通信构件与交通工具通信(例如，以将交通工具请求传达到所述交通工具)。在优选实施例中，指示交通工具的数据由如上文描述的指示与所述交通工具相关联的第二装置的数据提供。指示交通工具的数据可包括(例如)指示交通工具的类型、大小或其它属性的额外数据。这可使得能够关于多个准则实行交通工具请求到合适交通工具的匹配，如下文论述。

在优选实施例中，所述系统包括服务器，所述服务器包括用于与多个第一装置(其用于提出交通工具请求)的集合及多个第二装置(其与用于满足所提交的交通工具请求的相应交通工具相关联)的集合通信的通信构件。所述第一装置可由用户携带且所述第二装置可安装到交通工具。因此，在实施例中，所述交通工具请求管理系统包括服务器，所述服务器包括经配置以与多个第一装置及各自与交通工具相关联的多个第二装置通信的通信构件。所述多个第一装置为多个不同第一装置且所述多个第二装置为多个不同第二装置。将理解，在适当的情况下，本发明因此扩展到涵盖包括服务器及多个第一装置及/或第二装置的集合的交通工具请求管理系统。

根据本发明，所述方法包括服务器接收多个交通工具请求，每一交通工具请求至少包括第一位置，优选地，其中所述交通工具请求是从相应第一装置接收，且所述系统的服务器包括用于接收此数据的通信构件。所述第一位置优选为搭客位置，即，用户希望被交通工具搭载的地方。将了解，在未明确陈述的情况下，包括第一位置或类似者的交通工具请求可理解为是指包括指示所述第一位置或类似者的数据的请求。交通工具请求(例如，由第一装置提交且随后由服务器接收的请求)可仅包括指示第一位置的数据。然而，除指示第一位置的数据之外，所述交通工具请求可包括其它数据。

在一些实施例中，每一交通工具请求可进一步包括指示目的地位置(或“下客位置”)及/或搭客时间的数据。所述目的地位置将指示用户希望从交通工具下客的位置，且搭客时间将指示用户希望由交通工具搭载的时间。本发明尤其可适用于匹配需要“立即”搭客的交通工具请求。此类型的请求可被称为“尽快”类型的请求，且通常将不包含指示所要搭客时间的数据。本发明提供以更有效方式满足多个此请求的能力，以便由于所采用的群集化技术而全局地最小化等待时间。然而，将了解，本发明还可适用于需要在指定的将来时间搭客的所谓的“预定”交通工具请求。在此情形中，交通工具请求将包含指示搭客时间的数据。

如上文论述，交通工具请求可包含指示所述请求的一或多个额外属性的数据。在优选实施例中，交通工具请求包括指示所要的搭客时间、目的地位置、一或多个司机偏好、一或多个交通工具偏好、待搭载的人数及/或所要司机评级的数据。交通工具偏好的实例包含大小、型号、无障碍设施(disabled access)等等。如将在下文更详细描述，此数据可在将交通工具匹配到请求时使用。在实施例中，因此，每一交通工具请求包括第一位置(例如，搭客位置)，以及(任选地)第二位置(例如，下客位置)、搭客时间、司机偏好及交通工具偏好中的一或多者。

在服务器从第一装置接收交通工具请求的实施例中，第一装置可具有任何合适及所要形式。举例来说，所述第一装置可为具有固定位置的装置，例如个人计算机或其它计算资源。所述第一装置还可包括经布置以定位在建筑物内或定位在户外迎接点(例如，旅馆、酒吧、餐馆、车站或类似者)且通常仅与单个搭客位置相关联的装置。在这些实施例中，第一装置具有相关联位置。在实施例中，在服务器处存储所述相关联位置。然而，在优选实施例中，第一装置包括移动装置，例如移动电话、PDA、平板计算机或类似者。在这些实施例中，所述装置包括具有经布置以确定所述装置的当前地理位置的位置确定构件的移动装置。将了解，虽然在优选实施例中，交通工具请求者将为用户(即，希望搭乘交通工具行进的人)，但在其它情形中(例如，经由与单个搭客位置(例如，旅馆等等)相关联的第一装置发出请求)，交通工具请求者可与预期的交通工具用户不同。换句话说，交通工具请求是代表预期的用户发出的。因此，在本文中，用户是指希望搭乘交通工具行进的人。

因此，在一些实施例中，第一位置包括第一装置的当前地理位置，其中所述第一装置包括具有经布置以确定装置的当前地理位置的位置确定构件的移动装置。在其它实施例中，所述第一位置对应于与第一装置相关联的位置，所述相关联位置存储在服务器处。

所述第一装置优选地能够确定所述装置的当前位置，且因此优选包括位置确定构件。所述位置确定构件可具有任何类型。举例来说，所述第一装置可包括用于从WiFi接入点或蜂窝通信网络访问及接收信息且使用此信息来确定其位置的构件。然而，在优选实施例中，所述第一装置包括全球导航卫星系统(GNSS)接收器(例如，GPS接收器)，其用于接收指示所述接收器在特定时间点处的位置的卫星信号且优选以有规律间隔接收更新的位置信息。

在服务器和与交通工具相关联的第二装置通信的实施例中，所述第二装置能够接受由用户提交的交通工具请求，且因此优选具有其可在交通工具中携带或运送的形式。所述第二装置可为(例如)能够被手持且(例如)可可移除地安装在交通工具内的便携式装置。在其它实施例中，所述第二装置可为交通工具内系统，即，永久地安装在交通工具内的系统。

所述第二装置优选经布置以将关于所述装置及因此与其相关联的交通工具的当前位置的位置数据发射到服务器。因此，第二装置能够确定所述装置的位置，且因此包括位置确定构件。所述位置确定构件可同样具有任何类型。举例来说，第二移动装置可包括用于从WiFi接入点或蜂窝通信网络访问及接收信息且使用此信息来确定其位置的构件。然而，在优选实施例中，所述第二装置包括全球导航卫星系统(GNSS)接收器(例如，GPS接收器)，其用于接收指示所述接收器在特定时间点处的位置的卫星信号且优选以有规律间隔接收更新位置信息。

所述第二装置优选还包含用于确定其中携带所述装置的交通工具的相对位移的构件，从而允许(例如)确定所述交通工具在任何时间点的速度及行驶方向。所述构件可包含上文描述的GNSS接收器、所述装置中的一或多个电子陀螺仪或加速度计，或所述装置可(例如)使用交通工具CAN总线访问在所述交通工具自身中的此类传感器。

因此，在优选实施例中，用于本发明中的第二装置包括导航设备，例如可可移除地安装在交通工具内的便携式导航装置(PND)或交通工具内导航系统，且其优选包含GNSS信号接收及处理功能性。然而，将了解，所述第二装置还可包括运行合适软件程序的移动电话、PDA、平板计算机或类似者。

可以表示交通工具(例如，第二装置)的位置的任何合适形式将关于交通工具(例如，与其相关联的第二装置)的位置数据发射到服务器。举例来说，所述位置数据可包括一对经度坐标及维度坐标，或其可包括对数字地图内的特征的位置参考(例如，相对于道路交叉点)。如将了解，位置数据优选与表示在交通工具或第二装置处产生位置数据的时间的时间数据(例如，时间戳)相关联。所述位置数据优选以有规律间隔(例如，至少每5分钟，且优选至少每一分钟或在一些情形中甚至更频繁地)从交通工具或第二装置发射到服务器。因此，所述服务器可以高精确度从所接收的位置数据确定第二装置在特定时间点处的当前位置。

本发明的服务器可进一步包括其中存储有数字地图数据的数据存储构件。所述数字地图数据具有表示由所述地图涵盖的地理区域中的可通行路径的区段的多个可通行区段，且因此可用于路径规划及导航目的。举例来说，在本发明中，数字地图数据用于计算第一位置与交通工具待行进到的目的地位置之间的路径。

在本发明中，所述服务器经布置以接收至少包括第一位置(例如，搭客位置)的交通工具请求。所述交通工具请求优选从第一装置接收。所述第一位置可以任何合适方式产生。举例来说，所述位置可由用户在第一装置的用户接口上直接输入。举例来说，这将为用户希望在不同于其当前位置的位置被交通工具搭载的情形。然而，在优选实施例中，在第一装置处使用所述装置的位置确定构件产生所述第一位置。如将了解，这将为用户希望在其当前位置处被交通工具搭载的情形。

如上文论述，本发明尤其可适用于“立即”满足类型的请求，其中提出尽快提供交通工具的交通工具请求。然而，本发明还可适用于所谓的“预定”交通工具请求(其中提出在指定的将来时间提供交通工具的请求)或适用于涉及立即交通工具请求及预定交通工具请求的组合的系统。

在优选实施例中，产生一或多个群集的步骤使用与每一所接收交通工具请求相关联的时间数据。所述时间数据可包括在由服务器接收到时已与请求相关联的数据(例如，针对预定请求)及/或在接收到请求时由服务器与请求相关联的数据。优选地，用于产生一或多个群集时使用的时间数据至少为指示在服务器处接收到交通工具请求的时间的数据。这可为针对预定类型请求或立即类型请求的情形。替代地或另外，所使用的时间数据可指示与请求相关联的所要搭客时间。这尤其可适用于预定请求。

优选地，无论所述数据是否用于产生一或多个群集，所述方法进一步包括服务器使指示在服务器处接收到交通工具请求的时间的数据与每一所接收的交通工具请求相关联的步骤。所述服务器可包括用于实行此步骤的处理构件。无论请求是立即请求还是预定请求，均可实行此步骤。由服务器指派到每一交通工具请求的指示接收到交通工具请求的时间的数据可直接或间接地指示接收时间。所述数据可为接收时间。在其它实施例中，所述数据可包括(例如)关于请求的时间排序的识别号。

在优选实施例中，在服务器处接收到时，将至少第一交通工具请求集合中的每一交通工具请求分配到群集。这可最适于“立即”类型的请求。因此，第一请求集合可为针对立即满足的请求集合。在涉及预定请求的情况下，所述方法可包括产生一或多个群集，例如，基于比所要搭客时间提前预订量的时间(例如，在搭客时间之前30分钟)将此类请求分配到群集。在一些实施例中，所述方法可包括在服务器处接收到之后的给定时间将至少第二交通工具请求集合的每一交通工具请求分配到一或多个群集，优选地其中所述时间是基于与所述请求相关联的所要搭客时间，例如，比所述搭客时间提前预先确定的时间量。接着，所述第二请求集合可为在指定的将来时间进行满足的预定请求集合。在其它布置中，预定类型请求可与“立即”类型请求分开处理，例如，分配到单独的群集集合或可个别地处置。

根据本发明，所述方法包括服务器实行产生各自包括多个交通工具请求的一或多个群集的步骤。接着，在每一群集内实行交通工具到交通工具请求的匹配。在实施例中，所述方法包括在针对定义给定的所产生群集的请求中的任何者实行交通工具到请求的匹配之前使所述群集完整。在将交通工具匹配到请求之前，将每一所接收请求分配到给定群集。

“群集”为将在实行将交通工具匹配到请求的步骤时一起处理的一群交通工具请求。通过将交通工具请求指派到群集且接着在每群集基础上实行匹配，本发明提供动态平衡系统在实行匹配之前等待接收给定数目的交通工具请求的时间(其有利之处在于能够对供应及需求进行概览且其辅助优化匹配)与避免个别用户的过量等待时间的能力。群集包括多个交通工具请求的群组，所述多个交通工具请求已分配到所述群集以用于将交通工具匹配到所述请求。产生群集的步骤涉及出于本发明的目的建立待被当做群集处理的一群交通工具请求的过程。所述方法可涉及在包含在给定群集中的交通工具请求之间产生关联。

在实施例中，本发明的方法包括至少使用与每一请求相关联的时间数据及/或第一位置数据来产生包括多个交通工具请求的一或多个群集。

一般来说，根据本发明，优选地，产生一或多个群集的步骤考虑地理分布，例如多个交通工具请求及/或交通工具的空间密度。使用与每一交通工具请求相关联的位置来确定多个交通工具请求的地理分布。优选地，使用与请求相关联的第一位置数据来确定交通工具请求的地理分布。所述第一位置数据优选地指示搭客位置，如上文陈述。当然，可替代地或额外地使用与交通工具请求相关联的另一位置(例如，下客位置)来确定地理分布。使用搭客位置是优选的，因为这与以优化等待时间的方式将可用交通工具匹配到交通工具请求最相关。可基于交通工具的当前位置确定交通工具在某一区域中的地理分布。在尤其优选实施例中，产生一或多个群集的步骤考虑交通工具的地理分布及优选地交通工具的空间密度。已发现，考虑交通工具的地理分布在产生群集时是有用的，这是因为可用于满足交通工具请求的交通工具的空间密度将影响可出于匹配目的将交通工具请求在间隔开的位置(例如，搭客位置)方面一起考虑的范围。如果交通工具的空间密度较高，那么很可能将存在接近给定搭客位置的交通工具，所以可从关于相对紧密间隔的位置(例如，搭客位置)的交通工具请求建立群集。因为群集中的请求将作为群组匹配到交通工具，所以考虑关于较远距离处的位置的请求没有益处，这是因为交通工具将不可能为此类旅程的良好匹配以及更紧密间隔位置的旅程的良好匹配。

优选地，产生一或多个群集的步骤替代地或优选额外地考虑多个交通工具请求的时间分布。

优选地，产生多个群集，每一群集包括多个交通工具请求。在优选实施例中，同时产生多个群集。接着，可在认为每一所产生群集“完整”之后将每一所产生群集传递到匹配阶段。这些布置可提供关于不同准则同时产生群集的机会，例如关于可相对于某些属性(其可为地理属性或其它属性)而被认为是相关的请求，如下文描述。所提及的“产生”群集涉及将交通工具请求添加到群集或从多个现有群集产生群集(例如，合并群集)的步骤。这可一直进行到认为群集“完整”且准备好匹配的时间为止。当将第一交通工具请求分配到群集时，即，使用交通工具请求来开始新群集而非将所述交通工具请求添加到现有群集的时候起始所述群集。

产生群集的步骤可包括使指示给定群集的数据与用于定义所述群集的多个交通工具请求的集合中的每一者相关联。因此，针对给定群集的交通工具请求中的每一者与指示属于所述给定群集的请求的数据相关联。指示群集的数据可具有任何类型，前提是其识别所述群集以使得能够在交通工具匹配发生时一起处理与所述群集相关联的交通工具请求。指示群集的数据将请求识别为形成用于匹配目的的群组的一部分。

将了解，在产生交通工具请求的一或多个群集时，必须将每一所接收的请求分配到群集。优选地，在服务器处接收到时将交通工具请求分配到给定群集。然而，如上文陈述，对于预定请求，到群集的分配可在相对于所要搭客时间的给定时间处发生。

在实施例中，所述方法包括将每一所接收交通工具请求分配到给定群集的步骤。将给定请求分配到群集的步骤可包括将请求分配到一或多个且优选地多个现有群集的集合中的给定群集，或使用所述请求来产生新群集。使用交通工具请求来产生新群集可包括使用交通工具来起始群集或将所述请求添加到通过合并多个现有群集产生的群集。因此，所述方法可涉及确定是否将所接收交通工具请求添加到现有群集，且如果是这样，添加到哪一个群集，或是否应使用新请求产生待将所述新请求添加到其的新群集，且如果是这样，所述请求是否将起始新群集或是否将用于通过合并多个现有群集产生新群集。在一些实施例中，所述方法可包括确定将所接收交通工具请求分配到多个现有群集中的哪一者。

在实施例中，所述方法可包括至少基于指示与给定所接收请求相关联的时间及/或第一位置的数据确定是否将所述请求分配到现有群集，或产生新群集并将所述请求分配到所述新群集。

在优选实施例中，确定是否将所接收交通工具请求添加到现有群集或将所接收交通工具请求用于产生新群集的步骤包括基于一或多个关系量度评估所接收交通工具请求与一或多个现有群集的一或多个交通工具请求的相关程度。所述方法可包括基于一或多个关系量度确定是否认为所接收交通工具请求与一或多个现有群集的现有请求中的一或多者相关。在实施例中，所述方法包括当基于一或多个关系量度可认为所接收交通工具请求与现有群集的现有请求中的一或多者相关时将所接收请求添加到现有群集。所述方法可包括当基于一或多个关系量度不认为所接收交通工具请求与现有群集的现有请求中的任何者相关时使用所述交通工具请求起始新群集。所述方法可包括当确定可认为所接收交通工具请求与多个群集中的每一者的现有请求中的一或多者相关时将交通工具请求添加到通过合并多个群集产生的新群集。

通过以此方式产生群集，通过在可将所接收交通工具请求添加到现有群集或添加到通过合并多个现有群集产生的新群集之前首先考虑所接收交通工具请求与一或多个群集的一或多个现有请求之间的关系，有可能产生根据一或多个关系量度被认为相关的交通工具请求的群集。这可促进交通工具到请求的匹配，这是因为可假设类似交通工具集合或甚至相同交通工具集合可用于为请求服务。因此，不同司机集合可用于为不同群集服务，从而使得匹配过程更简单。其中交通工具请求与多个群集的现有请求相关的群集的合并可进一步巩固所述群集及其请求的相关性。

一般来说，在优选实施例中，所述方法包括产生一或多个且优选地多个群集，其中基于一或多个关系量度，认为与每一群集相关联的交通工具请求彼此相关。

将了解，本发明的方法可涉及在可将交通工具请求添加到群集或添加到通过合并现有群集产生的新群集之前确定可认为所述交通工具请求与一或多个现有群集的现有请求中的一者或一者以上相关。可根据需要来设置所述群集或每一群集中的新请求必须与之相关以便被添加到群集或通过合并群集产生的新群集的现有请求的数目及所要求的关系的紧密度以产生含有给定相关性水平的请求的群集。如下文描述，在优选实施例中，所要求的相关性程度可取决于交通工具请求的时间分布、交通工具请求的地理分布，或基于与所述群集或每一群集相关联的一或多个位置的在地理区域中交通工具的地理分布中的一或多者。

在优选实施例中，一或多个关系量度与群集相关联。在实施例中，因此，一或多个关系量度与所述群集或每一群集相关联以用于确定新请求是否与群集的一或多个现有请求相关。所述方法可扩展到定义一或多个关系量度且使所述关系量度或每一关系量度与一或多个群集相关联的步骤。所述关系量度可具有任何合适类型。关系量度可指示待达到的关系阈值。

在优选实施例中，一或多个关系量度至少包含指示地理关系的量度，例如，地理关系阈值。举例来说，指示地理关系的量度可指示待由某一位置(例如，与交通工具请求相关联的第一位置)达到以便使所述请求被认为与群集的一或多个现有交通工具请求相关的范围要求。地理关系量度可通过参考请求的搭客位置、目的地位置或任何一或多个合适地理位置。如上文论述，在实施例中，与给定交通工具请求相关联的第一位置可为搭客位置、目的地位置或类似者，且优选为搭客位置。优选地，地理关系量度是通过参考搭客位置。在一些优选实施例中，地理关系量度指示与交通工具请求相关联的位置(例如，搭客位置)必须位于其内以使所述请求形成群集的一部分的范围。所述范围可相对于与群集的现有请求中的给定一或多者相关联的对应位置(例如，搭客位置)(例如，起始群集的交通工具请求的搭客位置)。对应位置可为群集的形心(或几何中心)。因此，所述方法可包括基于使用与所接收交通工具请求相关联的第一位置数据基于地理关系的量度来评估所接交通工具请求与现有群集的一或多个交通工具请求的相关程度。在一些优选实施例中，地理关系量度指示与交通工具请求相关联的搭客位置必须位于其内的相对于与群集的一或多个现有请求相关联的搭客位置的最大范围。

在其它实施例中，可额外地或替代地使用指示非地理关系的关系量度。举例来说，关系量度可指示基于一或多准则(例如，时间、交通工具类型、交通工具大小、是否需要接受宠物的交通工具等等)的关系。所述准则是关于与所述交通工具请求或每一交通工具请求相关联的数据。因此，为使关系确定基于交通工具大小，至少一些交通工具请求将需要指定所要交通工具大小。时间准则可关于所要搭客时间或下客时间。这可尤其与预定请求相关。量度可要求请求的搭客时间或下客时间在群集的请求的对应搭客或下客时间的给定时间范围内。与请求相关联的时间数据(例如，搭客时间)可用于确定是否可基于一或多个量度认为请求与现有群集的请求相关。

将了解，可考虑到多个关系量度，且在适当的情况下，可使用基于不同关系量度的合适函数实现关于不同量度的所要加权。

在优选实施例中，用于评估交通工具请求与现有群集的一或多个现有交通工具请求之间的关系的一或多个关系量度是基于以下项目中的一或多者而定义：使用与基于与群集相关联的一或多个位置的地理区域中的交通工具请求相关联的位置确定的交通工具请求的地理分布；基于在包含与所述群集相关联的一或多个位置的地理区域中的交通工具的当前位置数据的交通工具的地理分布；及在包含与所述群集相关联的一或多个位置的地理区域中的交通工具请求的时间分布。优选地，所述地理分布为空间密度。在优选实施例中，所述方法包括基于一或多个此类地理分布及时间分布定义一或多个关系量度。在这些实施例及其中使用与交通工具请求相关联的位置确定地理分布的任何实施例中，所述位置可为第一位置，例如，搭客位置。交通工具或请求的地理分布或时间分布可为时间相依(time dependent)的。因此，可基于相关时段内的请求或交通工具的地理分布或时间分布来定义关系量度。

通过以此方式产生群集，有可能控制所产生的群集的密度及大小。举例来说，对于与相对繁忙的区域(即，其中存在高空间密度的交通工具或交通工具请求的地方)相关联的群集，通过设置关系量度来要求新请求与群集的现有请求之间的较紧密关系以便使所述请求被添加到所述区域中的群集或添加到通过使所述群集与另一群集合并而形成的新群集，将趋向于产生具有与所述群集中的请求相关联的位置(例如，搭客位置)的相对较小地理散布的更多群集。相反地，对于与较不繁忙的区域(其中请求具有较不紧密的关系就可被添加到群集的地方)相关联的群集，可产生包含与散布在更大地理区域上的位置相关联的请求的较少群集。

所述方法可包括取决于以上因素中的任何一或多者改变与群集相关联的一或多个关系量度。所述方法可包括取决于在基于与群集相关联的一或多个位置的地理区域中随时间变化提出的交通工具请求的时间分布的变化来改变一或多个关系量度。所述方法可包括取决于在基于与每一群集相关联的一或多个位置的地理区域中的交通工具请求的时间分布来使不同关系量度与不同群集相关联。请求的时间分布是指每单位时间提出的请求的数目。因此，当群集与其中每单位时间提出相对少的交通工具请求的地理区域中的位置相关联时，与关联于与其中每单位时间提出相对多的交通工具请求的地理区域(即，相对繁忙的区域)中的位置相关联的群集的关系量度相比，可不同地定义一或多个关系量度。类似地，在基于与群集相关联的一或多个位置的地理区域中的交通工具请求的时间密度发生改变的情况下，可改变一或多个关系量度。

替代地或额外地，所述方法可包括取决于与交通工具请求相关联的位置的地理分布及/或在基于与群集相关联的一或多个位置的地理区域中的交通工具的地理分布相对于时间的变化来改变一或多个关系量度。所述方法可包括取决于与交通工具请求相关联的位置的地理分布及/或在基于与每一群集相关联的一或多个位置的地理区域中的交通工具的地理分布来使不同关系量度与不同群集相关联。优选地基于与交通工具请求及/或在基于与群集相关联的一或多个位置的地理区域中的交通工具相关联的位置的空间分布的相对于时间的改变来改变一或多个量度。因此，当群集与其中交通工具请求与相对广泛地空间分布的位置相关联或其中交通工具相对广泛地空间分布的地理区域中的位置相关联时，与关联于与某地理区域(其中与交通工具请求或交通工具相关联的位置的空间密度相对高)(即，相对繁忙的区域)中的位置相关联的群集的关系量度相比，可不同地定义一或多个关系量度。类似地，在与交通工具请求或在与群集相关联的地理区域中的交通工具相关联的位置的空间密度改变的情况下，可改变一或多个关系量度。

基于与群集相关联的一或多个位置的地理区域可具有任何所要范围。与包含在区域中的群集相关联的一或多个位置优选为与群集的交通工具请求中的一或多者相关联的位置。所述位置优选为第一位置且最优选为搭客位置。将了解，为简洁目的，所述地理区域可在本文中描述为与群集“相关联”。所述地理区域可包含所述位置或每一位置，或可以其它方式基于所述位置或每一位置。举例来说，所述区域可以某一位置或使用多个位置确定的位置为中心。所述区域可具有任何合适大小。将了解，所述区域是基于与群集相关联的一或多个位置。因此，当群集变化时(例如，在添加更多请求时增大)，区域的定义可改变。在一些布置中，所述区域可基于某一位置，例如与首先添加到群集的请求相关联的搭客位置。通过适当地选择所述区域，可在考虑(例如)请求或交通工具的空间或时间密度的局部变化而非假设系统的全局“业务”水平的情况下实现系统的给定分辨率水平。

所述区域优选为扩展区域。取决于要考虑的时间请求分布中的相对局部变化的范围，地理区域可具有任何大小。举例来说，地理区域可为国家的地区、城市、区域、国家等等。在一些实施例中，地理区域可对应于城市的中心或郊区区域。可针对每一群集定义特定地理区域，或可基于一或多个位置将某一群集确定为与预定义地理区域集合中的给定地理区域相关联。在前一情形中，可依据距与群集的一或多个请求相关联的搭客位置或距被认为是与多个请求相关联的位置的中心的点的给定范围来定义地理区域。

可针对与群集相关联的任何一或多个位置以同一方式定义所述区域，或替代地，可取决于所述一或多个位置而定义所述地理区域。设想，可基于交通工具请求或交通工具在地理区域上(在实施例中)在给定时间内的时间分布及地理分布来定义地理区域的范围。因此，可基于区域的不同部分的交通工具请求的时间密度来将所述区域分成若干地理区域，且接着可使每一群集与所述区域中的一者相关联，例如，基于所述群集的第一请求与某一位置(例如，所述区域内的搭客位置)相关联。所述地理区域可分别涵盖具有交通工具请求或交通工具的类似时间密度的位置。不同的地理区域可与请求或司机的“低”及“高”时间密度或任何数目的中间时间密度水平相关联。为避免疑惑，以上关于基于与群集相关联的一或多个位置的地理区域的定义的陈述可同样适用于以下实施例，其中用于评估群集的完整性的阈值是基于在基于与群集相关联的一或多个位置的地理区域中的请求的时间分布。

根据本发明，仅在已将请求分配到给定群集之后，实行交通工具到交通工具请求或每一交通工具请求的匹配。所述方法可包括将交通工具匹配到第一群集的交通工具请求，且接着将交通工具匹配到第二不同群集的交通工具请求。

将了解，必须做出关于何时开始将交通工具匹配到给定群集的交通工具请求的确定。换句话说，可确定何时可认为某一群集“完整”使得所述群集的交通工具请求准备好匹配。根据本发明，直到认为给定群集完整之后，才关于形成所述群集的交通工具请求中的任何者进行交通工具到交通工具请求的匹配。当群集完整时，不可将其它交通工具请求添加到所述群集。

在认为某一群集完整之后，便可在任何时间使所述群集的交通工具请求经历匹配过程。可在所述群集满足用于评估何时认为所述群集处于“完整”状态的一或多个要求时立即实行匹配过程，或可在此后不久的某个时点处实行所述匹配过程。举例来说，可定期轮询群集以识别被视为完整且准备好匹配的那些群集。

所述方法可包括通过参考指示某一群集的完整性的一或多个量度来确定可认为所述群集完整。根据本发明的优选实施例，所述方法包括通过参考一或多个阈值确定何时认为某一群集完整，使得不可将其它请求添加到所述群集。所述一或多个阈值可包含关于由所述群集所包括的交通工具请求的数目的阈值及/或时间相关阈值。优选地，可使用时间相关阈值及关于请求的数目的阈值两者。在一些实施例中，当达到或超过第一阈值及第二阈值中的任一者时认为群集完整；所述第一阈值为关于由所述群集包括的交通工具请求的数目的阈值，且所述第二阈值为时间相关阈值。关于请求的数目的阈值优选为最大阈值。因此，此阈值可依据某一群集含有的请求的数目设置所述群集的最大大小。时间相关阈值优选为最大阈值。在这些实施例中，时间相关阈值及请求数目相关阈值两者均与群集相关联。

在一些优选实施例中，时间相关阈值是基于从将群集的交通工具请求中的首先群集化的交通工具请求被添加到所述群集之时起经过的时间。将了解，所述交通工具请求最初可能已通过将所述交通工具请求添加到接着与一或多个其它群集合并以产生群集的不同群集来群集化。在此情形中，经过的时间是相对于最早将请求添加到任何群集的时间。在其它实施例中，首先群集化的交通工具请求可能最初在产生所讨论的群集时被群集化。因此，所述经过的时间可相对于所述群集的产生时间。所述经过的时间可基于指示将首先群集化的请求群集化的时间的任何合适时间数据。所述时间数据可为与请求相关联的群集化时间或群集的产生时间。在一些实施例中，所述时间数据为在服务器处接收请求的时间。在在接收时将请求添加到群集的情况下，可认为此时间指示请求的最初群集化时间。

通过指定关于时间及包含在群集中的交通工具请求的数目的阈值(其用于确定何时可认为群集完整，使得不可将其它请求添加到所述群集且所述群集的请求准备好匹配)，本发明提供产生群集的动态方式，使得在在实行匹配之前等待足够长时间以提供足够请求以允许实现更佳匹配与同时避免用户的过量等待时间之间维持平衡。举例来说，如果仅参考群集中存在的请求的数目来设置阈值，那么针对关于每单位时间具有相对少的交通工具请求的地理区域的群集，与关于每单位时间具有相对大数目的交通工具请求的较繁忙地理区域的群集的情形相比，在可认为某一群集完整且使其经历匹配之前需要等待长得多的时间。相反地，如果仅参考从将第一请求添加到群集时起经过的时间来设置阈值，那么针对每单位时间具有低密度的交通工具请求的地理区域中的群集，与较繁忙区域中的群集相比，将需要关于具有相对少的交通工具请求的群集实行匹配。通过参考到达时间相关阈值及基于请求数目的阈值中的任一者来确定群集的完整性，在这些情形之间达到平衡。因此，在这些优选实施例中本发明的方法可考虑到关于地理区域的交通工具请求的变化的时间分布。

可以任何合适方式确定用于确定何时可认为某一群集完整的所述阈值或每一阈值。可基于对所要响应性的最小要求来确定基于时间或数目的阈值。通过选择相对低的数目阈值，当状况更繁忙时，系统将更具响应性，即，匹配将更迅速发生。时间相关阈值可用于确定在未首先达到数目区域的较不繁忙的区域中发生匹配的时间，且因此较低时间阈值将导致更具响应性的系统。所述阈值可经全局设置且可独立于与群集相关联的地理区域中的交通工具请求的空间或时间分布。

在其它布置中，设想，可基于优选在与群集相关联的地理区域中的交通工具请求的时间分布及/或地理分布来选择所述阈值或每一阈值。所述地理分布优选为空间密度。可按如上文关于将关系量度用于确定可添加到现有群集的请求的类似性的实施例描述的任何方式来定义地理区域。

一般来说，一次性匹配的交通工具请求的数目越高(即，群集的大小越大)，匹配的优化程度就越高。然而，实际上，不可能等待过量的时间，这是因为这将给用户带来不可接受的延迟。将了解，在接收高时间密度的请求的情况下(即，在繁忙时间)，有可能显著增大群集中的请求的数目，且因此增大匹配效率，这仅以适度的时间增加为代价。因此，在请求的时间密度较高的情况下，便可在不显著增加用户的等待时间的情况下增大最大大小及/或时间阈值。另一方面，当时间密度较低时(例如，在平静时间)，在针对群集执行匹配之前等待显著较长时间将对匹配效率具有有限影响，这是因为可预期在额外时期上仅有很少的额外请求。因此，在时间密度较低的情况下，增大时间或大小阈值可为有害的。本发明者已意识到请求的时间密度可相对于地理区域改变。因此，本发明的优选实施例考虑到与群集相关联的给定地理区域的请求的时间分布。这可使得能够考虑请求的时间分布的局部变化，而非假设全局时间分布。

在一些优选实施例中，在交通工具请求的相对高的时间密度与基于与群集相关联的一或多个位置的地理区域相关联的情况下，使用针对群集的相对较高的最大大小阈值，且/或在交通工具请求的相对较低时间密度与基于与所述群集相关联的一或多个位置的地理区域相关联的情况下，使用针对群集的相对低的最大大小。替代地或额外地，在交通工具请求的相对较高时间密度与基于与所述群集相关联的一或多个位置的地理区域相关联的情况下，使用针对群集的相对较高最大时间阈值，且/或在交通工具请求的相对较低时间密度与基于与群集相关联的一或多个位置的地理区域相关联的情况下，使用针对群集的相对较低最大时间阈值。

在优选实施例中，将用于确定何时可认为群集完整的方法与上文描述的用于基于一或多个关系量度确定是否可将请求添加到现有群集的方法相结合使用。已发现，通过使用这些方法的组合(即，通过在产生群集时考虑请求的相关性及在考虑阈值的完整性时考虑时间及大小阈值且考虑与每一群集相关联的地理区域中的请求的时间分布)，有可能控制在较繁忙区域及较不繁忙的区域中产生群集且使群集完整的方式，且在实施例中，在较不繁忙的地理区域中可考虑到由在群集的匹配可发生之前的最大时间阈值强加的约束(即，时延)产生相关旅程的最大可能群集，且在较繁忙区域中可使用在匹配发生之前的最小可能时间产生如由用于提供更佳的匹配的最大大小阈值指示的相关旅程的充分大群集。

作为实例，如果使用交通工具请求的时间阈值及数量阈值两者，那么结果将为在较繁忙的区域(例如，城市中心)将趋向于基于达到或超过基于数量的阈值而将群集认为是完整的，而在城镇的郊区中的较平静区域中，将趋向于基于达到或超过基于时间的阈值而将群集认为是完整的。换句话说，将在较繁忙的区域中趋向于产生相对大数目的较小群集，而将在较平静的区域中趋向于产生相对较小数目的较大群集。

可以任何合适方式关于形成群集的一部分的请求实行匹配。在实施例中，通过参考群集的每一其它交通工具群集实行交通工具到群集的每一交通工具请求的匹配的步骤。因此，全局地实行匹配以对群集的全体请求实现最佳匹配，而非一次仅考虑单个请求且基于一或多个准则分配最适当的交通工具(来自所有可用交通工具)。优选地，将单个交通工具匹配到群集的每一请求。优选地，将每一交通工具匹配到仅一个请求。将交通工具匹配到请求的步骤可包括服务器分析群集的每一所接收交通工具请求的内容，且确定与交通工具请求相关联的准则。将交通工具匹配到交通工具请求的步骤可包括将来自多个可用第二装置的第二装置匹配到所接收交通工具请求。所述服务器可经布置以按任何合适且所要方式做出此选择，如下文描述。

将了解，在优选实施例中，与给定群集相关联的交通工具请求以某种方式彼此相关。这可促进将交通工具匹配到请求的任务。在优选实施例中，所述请求至少在地理上相关，优选地相对于第一位置(例如，与所述请求相关联的搭客位置)相关。还可参考在将请求分配到群集时所考虑的一或多个其它准则(例如，关于一或多个司机偏好、交通工具偏好、待运载的人数、搭客时间、下客时间等等)使请求相关。

所述匹配可基于关于群集的每一交通工具请求的一或多个属性的一或多个准则及优选地至少与群集的每一交通工具请求相关联的位置(例如，搭客位置)。然而，额外地或替代地，可考虑其它准则(包含用户指定准则)。所述准则可替代地或额外地包括关于以下项目中的一或多者的准则：至少一个交通工具偏好、至少一个司机偏好、司机评级、指示所要搭客时间的数据、指示待搭载的人数的数据。将了解，如本文中提及的“偏好”可指示积极或消积的愿望(即，使某事物如此或并非如此)。

将了解，通过将交通工具匹配到交通工具请求的方式来描述匹配过程。交通工具具有相关联司机，且司机偏好等等是指可能分配到交通工具请求的交通工具的司机。在给定交通工具可与多个司机相关联的情况下，所提及的司机将与当前司机或预期(或已知)将在相关时间(例如，搭客时间)使用交通工具的司机相关。

将交通工具匹配到群集的每一交通工具请求的步骤优选地包括基于一或多个准则确定适于满足群集的请求的交通工具集合。所述交通工具集合可为多个交通工具的子集。所述交通工具为服务器已知其可用于满足请求的交通工具。所述准则优选地包括至少一个地理准则。所述准则优选地包括关于交通工具的当前位置与基于与群集相关联的一或多个位置的一或多个位置之间的距离的准则，优选地其中所述位置所基于的一或多个位置为与群集的请求相关联的第一位置。所述位置优选地为群集的请求中的一或多者的搭客位置。基于与群集相关联的一或多个位置的所述一或多个位置可对应于所述位置，或以其它方式基于所述位置而确定，例如为相对于所述位置确定的中心等等。优选地，对于基于与群集相关联的位置的所述位置或每一位置，所述服务器定义含有相应位置的地理区域。所述地理区域可以任何合适且所要方式定义。举例来说，所述区域可为以所述位置为中心且具有预先确定半径(例如，50米到500米之间的距离，优选地约250米)的圆。所述区域可针对任何位置以相同方式定义，或替代地所述地理区域可取决于所述位置来定义。所述确定交通工具集合可为所述区域内的交通工具。

所述准则可额外地或替代地包括关于以下项目中的一或多者的准则：至少一个交通工具偏好、司机评级、至少一个司机偏好、指示所要搭客时间的数据及指示待搭载的人数的数据。所述准则可包括用户准则。所述服务器可以任何合适方式确定用于满足交通工具请求的交通工具的可用性。举例来说，所述服务器可接收具有第二装置且具有满足所接收交通工具请求的可能性的多个交通工具中的每一者的位置及状态的连续(例如，周期性)更新。举例来说，一些交通工具可能不可用于满足所接收交通工具请求，例如，这是因为交通工具可能正在完成先前行程或替代性地交通工具的司机可能正在休息。因此，除了交通工具的当前位置之外，所述服务器还知晓在特定时刻可用于接受所接收交通工具请求的交通工具。此外并且如果交通工具请求是关于将来的预先确定时间(与来自用户的指示用户希望被立即搭载的交通工具请求形成对照)，服务器基于交通工具可能已经在进行的行程而知晓所述交通工具在将来时间的位置及可用性。

接着，将交通工具匹配到交通工具请求的步骤可包括将来自所述确定的交通工具集合的交通工具匹配到群集的交通工具请求集合。在一些实施例中，所述方法可包括以某种方式将交通工具匹配到交通工具请求以最小化交通工具到达与每一请求相关联的第一位置或搭客位置的估计时间。将了解，术语“最小化”是指服从由一或多个其它准则强加的任何其它约束的最小化。这最适于“立即”类型请求，其通常为可应用本文中描述的群集化方法的请求。如上文论述，可在指定的所要搭客时间之前的给定时间群集化预定请求，到所要搭客时间之时，可将预定请求视为立即请求。然而，在群集仅基于预定请求的情况下，群集可基于具有类似指定搭客时间的请求，使得试图在群集的请求之中最小化所估计到达时间仍将是有益的。

认识到，到达时间并非仅有的对用户来说是重要的因素(无论是关于立即请求还是预定请求)，且一些情形中在交通工具满足某种其它准则的情况下用户可能宁可为交通工具到达而等待较长时间。替代地或此外，当将交通工具匹配到交通工具请求时，可考虑一或多个其它准则。所述其它准则可包括交通工具司机的偏好。这可提供平衡用户的偏好与司机的偏好的匹配。所述匹配步骤也可考虑系统偏好，例如，基于司机的历史表现的偏好或基于作为一个整体的系统的操作的其它偏好。举例来说，所述步骤可偏向于向更可靠的司机提供更有利可图的旅程。准则可考虑司机或用户的历史行为。历史司机行为可关于历史驾驶风格，例如，攻击性或是稳健性。历史用户行为可关于所进行的先前旅程、所表达的历史偏好等等。历史用户行为可关于用户指定偏好或从先前旅程推断出的偏好。在实施例中，指示历史用户及/或司机行为的数据可经存储以用于匹配过程。用户或司机的身份可由与交通工具请求相关联的第一装置或与交通工具相关联的第二装置指示。

在优选实施例中，所述方法包括基于交通工具到达与请求相关联的第一位置或搭客位置的估计时间及/或一或多个其它准则将来自所述确定的交通工具集合的交通工具匹配到群集的所述交通工具集合，所述一或多个其它准则优选地包括以下项目中的一或多者：用户准则、司机准则、交通工具准则、系统准则及基于历史司机行为及历史用户行为的准则。优选地，所述匹配至少基于所估计到达时间。所述用户准则可选自一或多个司机偏好、一或多个交通工具偏好、所要下客时间或待运载的人数。司机准则可包含优选搭客区域或优选行进方向。用户或司机准则可为用户或司机指定准则，或可以其它方式(例如)从过去行为或用户或司机简档等等确定。

所述方法可包括将匹配值指派到交通工具与群集的交通工具请求的每一对，且以某种方式将交通工具匹配到交通工具请求以在群集的交通工具请求中最大化经分配的所述对交通工具与交通工具请求之间匹配值。所述匹配值可为随在匹配过程中考虑的各种因素而变。所述匹配值可基于交通工具到达某一请求的搭客位置的估计到达时间及/或司机偏好、用户偏好、历史用户行为、历史司机行为及系统偏好中的一或多者。这些可具有上文描述的任何类型。在确定匹配值时可向不同因素指派不同权重。可由用户及/或司机指定相对于一或多个其它因素加到所估计到达时间的权重。可以任何方式布置所述函数以平衡冲突的偏好。

接着，所述方法可包括将交通工具请求提供到交通工具(即，所述请求已匹配到的司机)，例如，提供到与所述交通工具相关联的第二装置。所述方法可进一步包括服务器将指示每一交通工具请求的数据传达到所述请求已被匹配到的交通工具。所述服务器可将所述数据提供到与所述交通工具相关联的第二装置。应理解所提及的将交通工具请求提供到交通工具，且所述提法可与将交通工具请求提供到交通工具的司机互换。

将交通工具匹配到交通工具请求的步骤优选地包括将单个交通工具匹配到每一交通工具请求。然而，预期不是每一个交通工具都将接受其所匹配到的交通工具请求。在一些优选实施例中，所述方法可进一步包括将至少一个替代交通工具分配到每一交通工具请求。在优选实施例中，根据所描述的方法(例如，通过考虑群集中的所有请求)分配到交通工具请求的交通工具可被认为是一级交通工具。优选地，单个一级交通工具匹配到每一请求。在一些实施例中，所述方法进一步包括基于在不考虑群集中的其它请求的情况下将交通工具匹配到请求来将至少一个次级交通工具分配到群集的每一请求。换句话说，使用常规技术匹配次级交通工具。所述次级交通工具可为基于可如上文描述的一或多个准则被确定为最佳地匹配交通工具请求的交通工具。所述次级交通工具为一级交通工具之后的用于满足所述请求的较低等级的交通工具。可针对每一请求基于常规技术将第三级及任何其它较高级的交通工具集合(即，更低等级的集合)确定为次优匹配。优选地，单个交通工具分配到每一级交通工具集合中的每一交通工具请求。在优选实施例中，所述方法包括将交通工具匹配到群集的每一交通工具请求以提供用于满足所述群集的交通工具请求的一级交通工具集合(其中参考群集的每一其它交通工具请求来实行每一一级交通工具到交通工具请求的匹配)，及将交通工具匹配到群集的每一交通工具请求以提供用于满足群集的交通工具请求的次级交通工具集合(其中在不参考所述群集的任何其它交通工具请求的情况下实行每一次级交通工具到交通工具请求的匹配)。可根据需要设置实施方案(例如)以控制是否可向同一司机分配给定级别的多个交通工具请求，或是否可向司机分配关于多个级别的交通工具请求等等。所述方法可包括首先将每一交通工具请求提供到每一所分配的一级交通工具，及在所述一级交通工具(例如，在给定时间内)不接受请求时将交通工具请求提供到针对所述请求的次级交通工具。

如将了解，在使用第一装置及/或第二装置的本发明的方面或实施例中，第一及第二装置(在使用的情况下)包括用于将信息发射到系统的其它组件(例如，服务器)及从所述其它组件接收信息的通信构件。所述信息可包括位置数据、待显示的数据、路径数据等等。所述通信构件可根据需要为任何类型。举例来说，所述装置可包括可借以将数据信号发射到装置并从装置接收数据信号的一或多个物理连接器接口。然而，在优选实施例中，所述通信构件包括用于允许经由蜂窝电信及其它信号及数据网络(例如，WiFi、GSM、GPRS及类似者)的通信的一或多个无线发射器/接收器。

如上文所论述，在本发明的方面或实施例中的任一者中，将交通工具匹配到交通工具请求可被理解为是指将与交通工具相关联的司机匹配到交通工具请求，且可与将与交通工具相关联的司机匹配到交通工具请求互换。所述匹配涉及在相关时间与交通工具相关联的给定司机，且因此交通工具及与交通工具相关联的司机可被互换地使用。

本发明扩展到经配置以与如上文描述的根据本发明的方面或实施例中的任一者的交通工具请求管理系统一起操作的第一及/或第二装置。此外，虽然上文已将某些步骤描述为仅在服务器上发生，但将了解，在适当的情况下，所述步骤可替代地在第一及第二装置(如果存在)中的一者或两者上或在所述第一及第二装置及所述服务器的任何组合上进行。

根据本发明的方法可至少部分使用软件来实施。因此，将可见，当从进一步方面观察时，本发明扩展到包括适于当在合适数据处理构件(例如，服务器)上执行时实行本文中描述的方法中的任何或所有方法的计算机可读指令的计算机程序产品。

本发明还扩展到包括此软件的计算机软件载体。此软件载体可为物理(或非暂时性)存储媒体或可为信号，例如经由导线的电子信号、光学信号或(例如，到卫星的)无线电信号或类似者。

虽然已在本文中参考将针对交通工具的请求匹配到用于满足所述请求的可用移动交通工具来描述本发明，但将了解，本发明在其较宽广方面中可至少适用于将服务请求匹配到移动服务提供商。

所属领域的技术人员还将理解，本发明的所有所描述的方面及实施例在适当的情况下可包含且优选地确实包含本文中描述的优选及任选特征中的任何一或多者或所有。

附图说明

下文将在参考附图的情况下借助说明性实例描述本发明的教示的各种方面及体现那些教示的布置，在附图中：

图1为可根据本发明使用的交通工具请求管理系统的结构的说明；

图2及3展示可用作所述系统中的交通工具请求装置的示范性固定位置装置；

图4为经布置以提供与系统中的交通工具相关联的导航装置的电子组件的示意说明；

图5为导航装置可经由无线通信信道接收信息的方式的示意说明；

图6到15为用于系统中的导航装置上的示范性显示屏；

图16说明自动确定交通工具到达搭客位置或下客位置的方法的步骤；

图17说明在由用户携带的移动装置与交通工具中的导航装置之间形成关联的方法的步骤；

图18说明根据本发明的用于将交通工具匹配到交通工具请求的方法的步骤；以及

图19说明本发明可如何用于优化提出交通工具请求的用户的等待时间。

具体实施方式

本发明在至少一些优选实施例中针对交通工具请求管理系统，且特定来说针对用于管理在人与个别出租车之间的针对出租车的请求的系统。参考图1描述可用于本发明的系统架构。

如图1中展示，所述系统包括三个主要组件：服务器10；多个交通工具请求装置12；及多个交通工具14(其各自装备有具有路径规划及导航功能性的装置200)。

交通工具请求装置12可具有若干不同形式。举例来说，所述交通工具请求装置可呈固定位置装置20的形式，如图2及3中展示。如名称暗示，固定位置装置仅与单个位置相关联且仅可用于请求交通工具去到此位置。所述交通工具请求装置还可呈移动装置22的形式，例如移动电话。如将在下文更详细论述，此类移动装置能够确定其自身位置，且可用于根据需要请求交通工具去到其当前位置或任何其它位置。所述交通工具请求装置还可为不具有用于确定其自身位置但仍可用于请求交通工具在特定位置处搭客的计算资源24，例如桌上型或便携式个人计算机。

交通工具请求装置12中的每一者可由用户用于将针对交通工具(例如，出租车)的请求发送到服务器10。所述请求通常将包含搭客位置或可用于导出此位置的数据，且还可包含以下项目中的至少一者：搭客时间；下客位置；所要交通工具类型或大小(例如，汽车、微型面包车、豪华轿车等等)；待搭载的乘客的数目；及任何额外偏好(例如，对儿童座椅的需要、对无障碍设施的需要或是否需要特定司机)。可使用任何合适通信构件(例如，移动电信网络、因特网等等)将交通工具请求发射到服务器10。

当在服务器10处接收交通工具请求时，所述服务器将选择满足在请求中陈述的准则的合适交通工具14。因此，服务器10用作用于基于用户请求调度合适交通工具的调度系统。

交通工具14各自装备有装置200，装置200包括位置确定构件及用于与服务器10通信的通信构件。所述交通工具中的所述装置可具有任何合适形式，但在说明性实施例中为导航设备。所述导航设备可为可移除地安装在交通工具中的便携式导航装置(PND)或建置到所述交通工具中的导航装置。在图4中展示可定位在交通工具14中的一者中的导航装置200的说明性表示。

交通工具装置各自将其当前位置及因此所述交通工具的位置以有规律间隔发射到服务器10。因此，服务器10至少以合理的精确度知晓所述系统内的所有交通工具在任何时刻的当前位置。所述服务器还知晓交通工具的当前可用性，例如，交通工具是否已经在完成请求的过程中，及交通工具的司机是否由于任何其它原因而不可用。在此方面，每一司机可能够输入其交通工具可用于接收请求的时间范围。替代地，所述司机可仅仅根据需要激活或停用所述装置。所述司机还可输入其愿意或不愿意运营于的某些位置或区域。

服务器10可响应于特定请求来选择交通工具14，且因此根据自动调度系统在请求装置12与交通工具中的装置200之间形成临时关联。下文参看图11描述根据本发明的系统。如将了解，即使司机被服务器10选择为最合适的，所述司机也可(例如)通过在其导航装置上进行合适用户输入来拒绝工作。

一旦已将工作给予交通工具，且接着所述交通工具的司机接受所述工作，且在一些情况中提出所述请求的用户也接受所述安排，那么在请求装置与所述交通工具中的导航装置之间生成关联。此关联允许在所述两个装置之间交换数据，直到打破所述关联的时间为止(例如，当已完成旅程且进行了付费时)。

一旦交通工具已赢得工作，便将所述工作的详细资料发送到交通工具的导航装置200。所述详细资料将包含搭客位置，且还可包含提出所述请求的人的详细资料。所述导航装置可自动或在由司机进行输入时计算从交通工具的当前位置到所述搭客位置的路径，且开始将司机引导到所述位置。替代地，如果所述交通工具当前正在完成工作，那么可将搭客位置暂时存储在存储器中直到需要所述搭客位置为止，或可将当前工作的下客位置用作路径点(waypoint)来计算到搭客位置的路径。在计算路径之后，产生到达搭客位置的估计到达时间(ETA)，且可将此时间供应到请求装置12。每当需要时，例如，如果ETA在交通工具沿所计算路径行进时改变，那么可将经更新ETA发送到请求装置12。

在搭客位置处搭载用户之后，交通工具14的导航装置200将把司机引导到所要下客位置。所述下客位置可能已由用户在原始交通工具请求中提供，或其可在搭客时由乘客给予司机。在到达下客位置时，乘客将对旅程进行付费。所述付费可使用现金或通过使用信用卡或借记卡来进行，然而，优选地，乘客将在服务器10上具有可将旅程指派到其的账户，从而允许以电子方式进行付费。

交通工具请求装置12可采取的一种形式为固定位置装置20。在图2及3中展示固定位置装置的实例。

固定位置装置20经布置以定位在建筑物或室外迎接点(例如，旅馆、酒吧、餐馆、购物中心、火车站或类似者)且与单个搭客位置相关联。所述搭客位置可为装置的实际位置或其可为所述装置附近的位置，例如所述旅馆或酒吧的街道入口或在街道上出租车可安全停靠的最近点。

固定位置装置20经配置以允许发出到与所述装置相关联的搭客位置的多个交通工具请求，且在任一时间使这些请求中的一者以上待处理。如图2中展示，装置20具有用户可通过其提出交通工具请求的第一按钮126。在实施例中，在触发请求之前，必须按压所述按钮达预先确定的时段(例如，1秒)。装置20还可具有可通过其取消先前提出的交通工具请求的第二按钮128。在装置20的壳体122内有用于与服务器10通信的构件。此构件通常将为移动电信模块，例如GSM或GPRS。额外或替代地，装置20可含有WiFi模块，(例如)用于具有有限移动电信覆盖的区域。此类模块优选地定位在壳体122内的印刷电路板(PCB)136内(如图3中展示)。装置20还可具有到因特网的物理连接，然而，此布置限制了可定位装置20的地方。

装置20具有到外部电源138的连接，但将了解，装置20可额外地或替代地具有电池或其它内部电源。

装置20进一步包括输出构件(例如，LED或其它类似发光装置130及/或扬声器)，其在优选实施例中用于指示何时交通工具处在搭客位置的预先确定距离内或已到达搭客位置。

当按压按钮126时，将含有与装置20相关联的参考号的交通工具请求发射到服务器10。服务器10具有参考号列表(一个参考号针对系统中的固定位置装置中的每一者)及与每一参考号相关联的搭客位置。这限制了需要包含在经发射交通工具请求中的数据量，且还允许容易地改变与装置20相关联的搭客位置。

装置20具有相关联显示器124，其用于显示针对每一待处理请求的消息；所述消息指示所述请求的当前状态。显示器124可定位在装置20的壳体22内，如图2中展示。然而，在其它实施例中，显示器124可与所述装置分离，例如定位在附近的墙壁上。举例来说，所述消息最初可表示：请求已被发出。接着，所述消息改变而表示：交通工具已接受所述请求且在去向搭客位置的途中。此消息还可包含所述交通工具、司机及/到达搭客位置的ETA的详细资料。接着，所述消息可改变而指示交通工具已到达搭客位置。

当从服务器10接收到与所述请求相关联的交通工具已离开搭客位置的指示时，从所述显示器移除消息。可在服务器10处自动做出此确定，例如，通过确定交通工具已停靠在含有搭客位置的区域中达预先确定时段且接着已从所述区域移出(如将在下文更详细论述)。替代地，交通工具的司机可在其导航装置200上指示其正离开搭客位置，且可经由服务器10将此指示发射到装置20。

装置20经布置以固定到平整表面142，例如桌子、吧台区域或墙壁。因此，装置20具有开口134，可通过所述开口放置螺钉140以将所述装置固定到表面142。装置20的基部135还具有支撑特征(例如，橡胶支腿132)以辅助将所述装置紧固在单个位置且防止装置20在通常可在例如酒吧或餐馆的环境中发现的湿表面上移动。由于此原因，装置的壳体122通常将为防水的。

交通工具请求装置12可采取的另一形式为移动装置22，例如移动电话、平板计算机、便携式数字助理(PDA)。

移动装置22定位在包含连接到输入装置及显示屏的处理器的外壳内。所述输入装置可包含键盘装置、语音输入装置、触摸面板及/或用于输入信息的任何其它已知输入装置；且所述显示屏可包含任何类型的显示屏，例如LCD显示器。在尤其优选的布置中，所述输入装置及显示屏被集成为集成输入及显示装置(包含触摸垫及触摸屏输入)，使得用户仅需触摸显示屏的一部分来选择多个显示选择中的一者或激活多个虚拟按钮中的一者。

移动装置22具有位置确定构件，其能够确定装置22的当前位置。在优选实施例中，所述位置确定构件为全球导航卫星系统(GNSS)接收器(例如，GPS接收器)，其接收且处理卫星广播信号(包含位置数据)以确定所述装置的当前位置。

软件应用程序在移动装置22的处理器上运行，所述软件应用程序允许用户产生交通工具请求且将此交通工具请求发送到服务器10。使用无线通信模块(例如，GSM或GPRS模块)将所述交通工具请求发送到服务器10。所述交通工具请求将包含搭客位置，所述搭客位置可为移动装置22的当前位置(从GNSS接收器获得)或可为由用户在输入装置上输入的位置。所述交通工具请求还可包含下客位置(其同样可由用户在输入装置上选择)且还可包含搭客时间。所述搭客时间可为尽快需要出租车的指示，或其可为由用户在输入装置上输入的特定将来时间。

如上文描述，一旦在服务器10处从移动装置22接收到交通工具请求，就选择满足请求中的准则的交通工具14。接着，在服务器10处在所述两个装置之间形成临时关联，即，使得所述两个装置将在所述系统上被链接直到已完成所请求的行程为止。服务器10将把所选择交通工具14的详细资料发射到移动装置22。所述详细资料可包含：关于所述交通工具的信息，例如，型号、颜色、注册号等等；关于司机的信息，例如照片、姓名、电话号码等等；及关于交通工具的当前位置及/或交通工具将行进到搭客位置的路径及/或到达搭客位置的估计时间的信息。服务器10可将所选择交通工具14的位置连续发送到移动装置22，使得用户可在交通工具向搭客位置行进时看见交通工具的进度。

所述用户可在发射到服务器10的请求中包含针对其所请求行程其想要的优选司机或优选司机集合。替代地，用户可具有与存储在服务器10上的简档相关联的一或多个优选司机。服务器10在选择交通工具以完成请求时考虑优选司机。

将交通工具14到达搭客位置的情况发射到移动装置22，且向用户提供合适警报。所述警报可为装置的显示屏上的虚拟警报、可闻警报、触觉警报或其任何组合。服务器10可自动确定交通工具到达搭客位置，例如，如下文更详细论述。替代地，可在司机在其导航设备200上提供指示时确定交通工具的到达。除提供此警报之外，可在移动装置22上提供关于交通工具14在搭客位置处的当前位置的指示。举例来说，所述指示可为从移动装置22的当前位置指向交通工具14的当前位置(如从服务器10接收)的定向指针或箭头。可使用移动装置22内的任何合适构件(例如，罗盘、陀螺仪及加速度计中的一或多者)产生此指针。使用此指针或箭头允许用户识别他或她的交通工具14，即使(例如)当所述交通工具紧挨着若干其它出租车停靠在街上且因此用户难以识别时用户也可识别他或她的交通工具14。

当用户已发现且进入所选择交通工具14时，所述交通工具的司机可立即开始朝向下客位置(如果其已从原始交通工具请求知晓)行进。替代地，用户可简单地直接向司机通知下客位置，且接着司机可将目的地输入到其导航设备200中。在其它实施例中，且归因于在服务器10处在所述两个装置之间形成的临时关联，用户可在其移动装置22上输入所要下客位置且将此目的地发射到所述交通工具的导航装置200。用户甚至可在向司机提供大致目的地之后进行此操作，使得司机可在提供最终下客位置之前开始行程。如将理解，此功能性还将允许用户在需要的情况下在途中修改下客目的地。

可自动对行程进行付费，例如，通过用户在服务器10上设置具有与其相关联的某一金额的账户。可简单地从用户的账户扣除所述行程的费用。这可自动发生或在司机及/或用户在其相应装置上确认待支付的金额之后发生。

在行程结束时，用户还可使用其移动装置22来提供对行程及/或司机的评级。此评级将被发射到服务器10且与保持在服务器10处的相关司机详细资料相关联。如上文论述，用户及/或服务器10在选择用于完成交通工具请求的交通工具时可使用司机的评级。如果服务器10确定司机未遵循计算出的最佳路径且因此导致用户的行程比必要行程更长(就时间及/或距离来说)，那么还可自动降低与司机相关联的评级。

图4为可定位在交通工具14中的一者中的导航装置200的说明性表示。导航装置200以框格式展示。应注意，导航装置200的框图不包含所述导航装置的所有组件而仅表示许多实例组件。导航装置200在以下段落中描述为能够可移除地安装在交通工具中的便携式导航装置(PND)。然而，将理解，在其它实施例中，导航装置200可建置在交通工具中。

导航装置200通常将包括数字地图数据，所述数字地图数据具有表示由所述地图涵盖的地理区域中的可通行路径的区段的多个可通行区段。所述数字地图数据由导航装置200用于计算可由携带所述导航装置的交通工具穿过的若干位置之间的路径，且向司机提供合适导航指令以沿着计算出的路径引导司机。

导航装置200定位在外壳(未展示)内。所述外壳包含连接到输入装置204及显示屏206的处理器202。输入装置204可包含键盘装置、语音输入装置、触摸面板及/或用于输入信息的任何其它已知输入装置；且显示屏206可包含任何类型的显示屏，例如，举例来说，LCD显示器。在尤其优选布置中，输入装置204及显示屏206被集成到集成输入及显示装置(包含触摸垫及触摸屏输入)中，使得用户仅需触摸显示屏206的一部分来选择多个显示选择中的一者或激活多个虚拟按钮中的一者。

导航装置200可包含输出装置208，例如可闻输出装置(例如，扬声器)。输出装置208可向导航装置200的用户产生可闻信息，同样应理解，输入装置204还可包含用于接收输入语音命令的麦克风及软件。

在导航装置200中，处理器202经由连接210操作性地连接到输入装置204且经设置以经由连接210从输入装置204接收信息，且经由输出212操作性地连接到显示屏206及输出装置208中的至少一者以将信息输出到显示屏206及输出装置208中的至少一者。此外，处理器202经由连接216可操作地耦合到存储器资源214且进一步适于经由连接220从输入/输出(I/O)端口218接收信息/将信息发送到输入/输出(I/O)端口218，其中I/O端口218可连接到导航装置200外部的I/O装置222。举例来说，存储器资源214包括易失性存储器(例如，随机存取存储器(RAM))及非易失性存储器(例如，数字存储器，例如快闪存储器)。外部I/O装置222可包含但不限于外部收听装置，例如，举例来说，耳机。到I/O装置222的连接可进一步为到任何其它外部装置(例如，汽车音响单元)的有线或无线连接以用于免提操作及/或用于语音激活操作，例如，以用于连接到耳机或头戴式耳机及/或用于连接到例如移动电话，其中所述移动电话连接可用于(例如)在导航装置200与因特网或任何其它网络之间建立数字连接，及/或用于(例如)经由因特网或某种其它网络建立到服务器的连接。

图4进一步说明处理器202与天线/接收器224之间经由连接226的操作性连接，其中举例来说，天线/接收器224可为GPS天线/接收器。将理解，由参考数字224指示的天线及接收器经示意性地组合以用于说明，但所述天线及接收器可为单独定位的组件，且举例来说所述天线可为GPS贴片天线或螺旋形天线。

此外，所属领域的一般技术人员将理解，图4中展示的电子组件由电源(未展示)以常规方式供电。如所属领域的一般技术人员将理解，认为图4中展示的组件的不同配置在本申请案的范围内。举例来说，图4中展示的组件可经由有线及/或无线连接及类似者与彼此通信。因此，本申请案的导航装置200的范围包含便携式或手持导航装置200。

此外，图4的便携式或手持导航装置200可以已知方式连接或“对接”到例如自行车、摩托车、汽车或船的交通工具。接着，可从对接位置移除此导航装置200以用于便携式或手持式导航用途。

现参考图5，导航装置200可经由移动装置(未展示)(例如，移动电话、PDA、及/或具有移动电话技术的任何装置)与服务器302建立“移动”或电信网络连接，从而建立数字连接(例如，经由(例如)已知蓝牙技术的数字连接)。此后，通过其网络服务器提供商，移动装置可与服务器302建立网络连接(通过例如因特网)。因而，在导航装置200(其在单独行进及/或交通工具中行进时可为且通常为移动的)与服务器302之间建立“移动”网络连接以提供“实时”或至少“最新”的信息网关。

在移动装置(经由网络服务器提供商)与另一装置(例如服务器302)之间使用例如因特网(例如，万维网)建立网络连接可以已知方式进行。举例来说，这可包含使用TCP/IP分层协议。所述移动装置可利用任何数目的通信标准，例如，CDMA、GSM、WAN等等。

因而，可利用经由(例如)数据连接、经由移动电话或导航装置200内的移动电话技术实现的因特网连接。对于此连接，建立服务器302与导航装置200之间的因特网连接。举例来说，这可通过移动电话或其它移动装置及GPRS(通用分组无线电服务)连接(GPRS连接为由电信运营商提供的用于移动装置的高速数据连接；GPRS为用于连接到因特网的方法)来进行。

导航装置200可进一步经由例如现有蓝牙技术以已知方式与移动装置且最终与因特网及服务器302完成数据连接，其中数据协议可利用任何数目的标准，例如，举例来说，GSRM、用于GSM标准的数据协议标准。

导航装置200可在导航装置200自身(包含(例如)天线或任选地使用导航装置200的内部天线)内包含其自身的移动电话技术。导航装置200内的移动电话技术可包含如上文指定的内部组件，且/或可包含可插入卡(例如，用户识别模块或SIM卡)，连同(例如)必要的移动电话技术及/或天线。因而，导航装置200内的移动电话技术可类似地经由(例如)因特网以类似于任何移动装置的方式在导航装置200与服务器302之间建立网络连接。

对于GPRS电话设置，具有蓝牙能力的导航装置可用于与不断变化的范围的移动电话型号、制造商等等一起正确工作；举例来说，型号/制造商专用设置可存储在导航装置200上。可更新针对此信息所存储的数据。

在图5中，导航装置200被描绘为经由可由若干不同布置中的任何者实施的通用通信信道318与服务器302通信。当在服务器302与导航装置200之间建立经由通信信道318的连接时，服务器302与导航装置200可通信(注意，此连接可为经由移动装置的数据连接、经由因特网经由个人计算机的直接连接等等)。

除了可能未说明的其它组件之外，服务器302包含操作性地连接到存储器306且经由有线或无线连接314进一步操作性连接到大容量数据存储装置312的处理器304。处理器304进一步操作性地连接到发射器308及接收器310以经由通信信道318将信息发射到导航装置200及从导航装置200接收信息。所发送及接收的信号可包含数据、通信及/或其它传播信号。可根据在导航系统200的通信设计中使用的通信要求及通信技术来选择或设计发射器308及接收器310。此外，应注意，可将发射器308及接收器310的功能组合到信号收发器中。

服务器302进一步连接到(或包含)大容量存储装置312，注意，大容量存储装置312可经由通信链路314耦合到服务器302。大容量存储装置312含有许多导航数据及地图信息，且可同样为与服务器302分离的装置或可并入到服务器302中。

导航装置200适于通过通信信道318与服务器302通信，且包含如先前关于图4描述的处理器、存储器等等以及发射器320及接收器322以通过通信信道318发送及接收信号及/或数据，注意，这些装置可进一步用于与除服务器302以外的装置通信。此外，根据在导航装置200的通信设计中使用的通信要求及通信技术来选择或设计发射器320及接收器322，且可将发射器320及接收器322的功能组合到单个收发器中。

存储在服务器存储器306中的软件为处理器304提供指令，且允许服务器302向导航装置200提供服务。由服务器302提供的一个服务涉及处理来自导航装置200的请求，且将导航数据从大容量数据存储装置312发射到导航装置200。由服务器302提供的另一服务包含使用所要应用程序的各种算法处理导航数据且将这些计算的结果发送到导航装置200。

通信信道318一般表示连接导航装置200与服务器302的传播媒体或路径。服务器302及导航装置200都包含用于通过通信信道发射数据的发射器及用于接收已通过通信信道发射的数据的接收器。

通信信道318不限于特定通信技术。此外，通信信道318不限于单个通信技术；即，信道318可包含使用各种技术的若干通信链路。举例来说，通信信道318可适于提供用于电通信、光学通信及/或电磁通信等等的路径。因而，通信信道318包含但不限于以下项目中的一者或组合：电路、电导体(例如，电线及同轴电缆)、光缆、转换器、射频(RF)波、大气层、真空等等。此外，通信信道318可包含中间装置，例如，举例来说，路由器、中继器、缓冲器、发射器及接收器。

在一个说明性布置中，通信信道318包含电话及计算机网络。此外，通信信道318可能够适应无线通信，例如射频、微波频率、红外线通信等等。此外，通信信道318可适应卫星通信。

通过通信信道318发射的通信信号包含但不限于给定通信技术要求或所要的信号。举例来说，所述信号可适于用于蜂窝通信技术，例如时分多址(TDMA)、频分多址(FDMA)、码分多址(CDMA)、全球移动通信系统(GSM)等等。可通过通信信道318发射数字信号及模拟信号两者。这些信号可为按通信技术的需要经调制信号、经加密信号及/或经压缩信号。

服务器302包含可由导航装置200经由无线信道访问的远程服务器。服务器302可包含定位在局域网(LAN)、广域网(WAN)、虚拟专用网(VPN)等等上的网络服务器。在其它实施例中，服务器302可包含个人计算机(例如，桌上型计算机或膝上型计算机)，且通信信道318可为连接在个人计算机与导航装置200之间的缆线。替代地，个人计算机可连接在导航装置200与服务器302之间以在服务器302与导航装置200之间建立因特网连接。替代地，移动电话或其它手持装置可建立到因特网的无线连接以用于经由因特网将导航装置200连接到服务器302。

可经由信息下载从服务器302向导航装置200提供信息，所述信息可被自动周期性更新或在用户将导航装置200连接到服务器302时更新，且/或可在经由(例如)无线移动连接装置及/TCP/IP连接在服务器302与导航装置200之间建立更恒定或频繁连接时更加动态。对于许多动态计算，服务器302中的处理器304可用于处置大部分处理需要，然而，导航装置200的处理器210还可通常独立于到服务器302的连接而处置许多处理及计算。

在优选实施例中，导航装置200经布置以存储若干用户简档，使得同一装置可由若干不同的人使用。这在导航装置200被用于通常将在若干不同司机之间共享的出租车或其它类似交通工具内时是有益的。当特定用户登录到所述装置上时(例如，通过触摸“司机A”图标400或通过使用“新用户”图标402(如图6中展示)输入他或她的详细资料)，将此选择的指示发送到服务器10，使得所述服务器可使司机与交通工具相关联。当选择交通工具来完成从用户提交的交通工具请求时，可相应地将正确司机详细资料及/或评级供应到用户。

当在服务器10处接收交通工具请求时，选择一或多个合适交通工具14且将所述请求发射到所述交通工具或每一交通工具内的导航装置200。展示在导航装置200上的示范性屏幕可见于图7中。在此情况中，交通工具请求404涉及正在阿姆斯特丹市中心的位置寻找尽早的交通工具的人。

在图7的屏幕的左下角是标记为“中断”的所选择图标406。司机可在任何时间触摸此图标以指示其在当前时间不可用于接受请求。如将了解，当触摸图标406时，便将指示从导航装置200发射到服务器10以通知系统所述交通工具当前不可用。

如果司机触摸交通工具请求消息404，那么导航装置平移(pan)所显示地图使得其以与所述请求相关联的搭客位置为中心。例如通过圆圈410及/或通过使地图显示器的其它部分变暗淡或变灰来在屏幕上突出显示搭客位置，使得司机可迅速识别搭客位置。交通工具的当前位置408也显示在屏幕上，同样用来辅助司机识别搭客位置。如果司机希望申请接受所述交通工具请求，那么其可触摸图标414。替代地，如果司机希望拒绝交通工具请求，那么其可触摸图标412。

如果司机申请接受交通工具请求404，那么其将赢得所述请求(如图9中展示)或失去所述请求(如图10中展示)。

如果司机赢得所述请求，那么服务器10将把所述交通工具请求的全部详细资料发送到导航装置200。举例来说，对于讨论中的交通工具请求，且如图11中展示，所述请求已由乔纳森·米勒·约翰逊(Jonathan Miller Johnson)提交或代表乔纳森·米勒·约翰逊提交。所述请求的详细资料将至少包含搭客位置(A)424；在此情形中为阿姆斯特丹中心的达姆拉克(Damrak)。司机还将看见请求的日期—425及到达搭客位置的估计时间—423。到达搭客位置的ETA由规划从交通工具的当前位置到搭客位置的路径的导航装置200确定，所述路径在优选实施例中考虑历史交通状况、当前交通状况及/或所估计的将来交通状况。如图11中展示，所述请求还可包含来自用户的消息(所述消息指示用户当前定位在何处(例如，“我正站在黄色电话亭的前面”))及允许司机联系用户的图标422。

图11中展示的旅程详细资料屏幕可在整个行程中的任何时间由司机访问，且含在其中的信息将被更新以反映行程的当前状态。举例来说，当用户已在位置A处被搭载且已向司机提供目的地位置时，所述屏幕便还将包含此位置及相关联ETA的详细资料。旅程详细资料屏幕还可由司机用于取消其先前已接受的旅程。这可通过选择“取消旅程”图标426来进行，且将把合适消息发送到服务器10。所述消息可包含取消的理由，例如交通、交通工具处于事故中或交通工具出故障。在接收到此取消时，可在服务器10处采取适当行动，例如将另一交通工具发送到搭客位置并相应地通知用户，或在当前交通工具已出故障的情形中将另一交通工具发送到当前交通工具的位置。如果在没有正当理由的情况下取消旅程，那么可自动将司机的评级降低一定量。

一旦司机接受及/或赢得旅程，导航装置200就将自动计算到搭客位置的路径且向司机提供引导。举例来说，这在图12中展示。可通过司机选择“到达搭客点”图标428来指示交通工具到达搭客位置，同样如图12中展示。然而，还预期，可在服务器10处自动确定交通工具到达搭客位置，且将指示交通工具到达搭客位置的消息发送到导航装置200。将在下文更详细描述服务器10可借以自动检测交通工具到达特定位置及/或从特定位置出发的方式。

当交通工具到达搭客位置(A)时，导航装置200将显示图13中展示的屏幕。此时，用户将进入交通工具且如果尚未提供下客位置(即，在原始交通工具请求中)，那么司机将向用户询问下客位置。此可由司机在导航装置200上输入或其可由用户在请求装置(例如，移动装置22)上提供。一旦已提供下客位置，司机就可选择“去到下客点”图标430(如图13中展示)，且导航装置200将计算从搭客位置(A)到下客位置(B)的路径且向司机提供导航引导。

如图13中展示，如果在交通工具到达搭客位置时司机及用户无法立即定位彼此，那么司机可试图使用“联系客户”图标432联系用户。如果司机仍然无法定位用户，那么其可选择“爽约”图标434，于是，合适消息被发送到服务器10。服务器10可在此事件之后降低与用户的账户相关联的对用户的评级。这防止用户滥用系统且连续提出无效交通工具请求。

当将司机引导到下客位置时，将在导航装置200上显示例如在图14中展示的屏幕。如同到达搭客位置，可通过司机选择“到达下客点”图标436来指示交通工具到达下客位置，如图14中展示。然而，同样预期，可在服务器10处自动确定交通工具到达下客位置，且可将指示交通工具到达下客位置的消息发送到导航装置200。

当交通工具到达下客位置(B)时，导航装置200将显示图15中展示的屏幕。从此屏幕，司机可看见完成的行程438的概述(包含行程时间及距离)。司机可通过选择“结束旅程”图标439来结束行程，这可致使服务器10将消息发送到用户的移动装置22以确认对行程的付费。司机还可选择“给予反馈”图标440以提供关于行程及/或用户的信息。举例来说，所述司机可指示其不希望从所述用户接收进一步交通工具请求。

现参考图16描述服务器10可借以自动确定交通工具到达搭客位置或下客位置的方式。

服务器10定义含有搭客位置或下客位置的地理区域—500。通常，此区域为以所述位置为中心的半径为250m的圆。接着，可分析关于向所述位置行进的交通工具的位置数据以确定所述交通工具是否已在所定义区域内减速或停下达预先确定的时段且已在处在含有与计算出的路径相关联的估计到达时间的时窗内的时刻处停下—504。通过在到达检测算法中利用计算出的路径的ETA，实质上降低了在交通工具实际上(例如)在邻近道路上在交通灯处停下时错误地确定交通工具已到达某一位置的机会。

在以上描述中，假设用户将使用所描述的交通工具请求装置12中的一者提出针对交通工具的请求且所述用户将在交通工具到达所请求的搭客位置时进入所述交通工具。在此场景中，交通工具请求的发射导致在服务器10处在交通工具请求装置12与交通工具14之间形成临时关联。此临时关联接着可用于提供与本发明相关联的许多益处，例如，电子付费、在途中修改下客位置、对司机及/或乘客进行评级及乘客查看应由交通工具行进的路径。然而，将理解，如果用户招停附近经过的交通工具，那么即使所述用户及所述交通工具均为本发明的交通工具请求管理系统的部分，也将不进行此临时关联。

可通过使用图17中说明的方法来克服此问题。

当用户招停经过的出租车时，所述用户可使用其移动装置22将其已经或将进入交通工具14的指示发送到服务器10—600。举例来说，可简单地通过在用户的移动装置22上打开适当软件应用程序来产生这一指示。通过使用从移动装置22发送到服务器10且指示移动装置22的位置及移动的位置数据，服务器10可识别在含有移动装置22的预定义地理区域内的哪些交通工具。此区域可为以移动装置22的当前位置为中心(例如)半径为约30米的圆—604。一旦已识别任何此类交通工具，就可在服务器10处在从移动装置22接收的位置数据与经识别交通工具的位置数据之间进行比较，以确定所述交通工具中的任何者是否与移动装置22同时沿着同一行进路径移动。此同时移动可由类似速度、加速度、方向改变及类似者指示。如果仅单个交通工具被识别为与移动装置22同时移动，那么可推断出此交通工具必定为用户当前正在其中行进的交通工具，且服务器10使移动装置22与所述交通工具中的导航装置200相关联。替代地，如果识别多个候选交通工具，那么由服务器10将具有合适识别信息(例如，交通工具及/或司机的详细资料)的交通工具列表发送到移动装置22—608。接着，用户可从移动装置22上的列表选择适当交通工具，且接着可将此选择发射回到服务器10—610。接着，服务器10将使移动装置22与所选择交通工具内的导航装置200相关联—612。

现将参考图18及19描述根据本发明的选择交通工具来为交通工具请求服务的方法的一些优选实施例。

将参考“立即满足”类型交通工具请求(即，来自用户的应尽快提供而非在指定的将来时间提供的请求)描述本发明的优选实施例。然而，将了解，所述方法还可适用于针对指定的将来时间的预定交通工具请求，或立即类型交通工具请求与预定类型交通工具请求的组合。下文将概述可借以修改所述方法以处置预定请求的一些方式。

将参考图18的流程图及图1中展示的类型的系统(其包含服务器10、多个交通工具请求装置12及各自装备有具有路径规划及导航功能性的装置200的多个交通工具14)来描述所述方法。本发明的方法涉及服务器选择合适交通工具来满足交通工具请求中陈述的准则的方式。

服务器10从交通工具请求装置12接收来自用户的对交通工具的请求—图18的步骤700。所述交通工具请求装置可具有上文关于图1论述的形式中的任何者。交通工具请求包含搭客位置或可用于导出此位置的数据，且还可包含以下项目中的至少一者：搭客时间；下客位置；所要的交通工具类型或大小(例如，汽车、微型面包车、豪华轿车等等)；待搭载的乘客数目；及任何额外偏好(例如对儿童座椅的需要、对无障碍设施的需要或是否需要特定司机)。可使用任何合适通信构件(例如，移动电信网络、因特网等等)将所述交通工具请求发射到服务器10。

在接收到交通工具请求时，所述服务器将指示在所述服务器处接收到所述请求的时间的参数指派到所述请求—702。所述参数可为时间或指示时间的数据，例如可用于确定相对于之前及之后的请求接收到给定请求的时间的数目。

在常规系统中，通常一旦接收到交通工具请求就参考与所述请求相关联的准则、搭客位置及可用交通工具的地理位置来将交通工具分配到交通工具请求。然而，本发明人已意识到，就可在整个系统上实现的匹配程度来说，在交通工具为针对讨论中的交通工具请求的最佳匹配的基础上将交通工具指派到每一交通工具请求可为不利的。以下实例说明与常规分配方法相关联的问题。

借助实例，考虑图19中展示的情形，其中在给定路段上有两个可用交通工具，即，出租车A及出租车B。在短时间内连续接收到两个交通工具请求。第一个所接收请求为旅程1，且第二个为旅程2。常规系统将接收旅程1且基于交通工具距与所述请求相关联的搭客位置的接近度来将出租车A及B中的一者分配到所述请求。假设与旅程1相关联的搭客位置是沿着所述道路距离出租车A 10分钟路程处，且距离出租车B 9分钟路程处，其中所述位置在出租车A与出租车B之间。常规系统将把旅程1分配到出租车B，给予9分钟的等待时间。在此实例中，接着接收的旅程2是与在远离出租车A的方向上、沿着道路距出租车B 10分钟路程的搭客位置相关联。因为旅程1刚刚被分配到出租车B，所以此交通工具不再可用于为旅程2服务。因此，必须将旅程2分配到出租车A，这是沿着所述道路距离出租车A总共29分钟的旅程。可见，在根据交通工具的估计到达时间的最佳匹配基础上分配每一请求可导致一些用户(例如，旅程1的用户)的较低等待时间，但这是以其它用户(例如，与旅程2相关联的用户)为代价的。如果分配已被推迟而非在接收到旅程1时立即发生，那么将接收旅程2，且将有可能在分配过程中考虑旅程1及旅程2两者。那么，最佳分配将把旅程1分配到出租车A且将旅程2分配到出租车B，从而导致旅程1的用户等待10分钟及旅程2的用户等待10分钟。因此，旅程1及旅程2的平均等待时间从19分钟减少到10分钟。

本发明者已意识到，通过在将交通工具指派到请求时一起考虑交通工具请求的群集，有可能在请求集合上实现更优化的交通工具到请求的匹配，且减少平均等待时间。根据本发明的方法，出于匹配的目的将交通工具请求分组成“群集”。

返回到图18，当在服务器处接收到新交通工具请求且向所述交通工具请求分配指示在服务器处的接收时间的参数时，便立即将所述交通工具请求分配到请求群集。请求群集为将被一起匹配到交通工具的一群请求，即，所述匹配将考虑所述群集中的所有请求。本发明以导致群集中的请求根据某些准则相关的方式产生群集。

为了将交通工具请求分配到群集，必须确定所述请求是否与现有一或多个群集的任何请求相关—704。这是使用与每一现有群集相关联的“关系参数”来确定。在一个实施方案中，关系参数要求：当新请求的搭客位置在现有群集的请求的预先确定范围内时，可认为所述新请求与所述现有群集的所述请求相关。

如果未发现请求与任何现有群集的任何请求相关，那么将所述请求用于起始新群集—706。如果发现所述请求与现有群集的请求相关，那么将所述请求添加到所述群集—708。如果发现所述请求与一个以上现有群集的请求相关，那么将所述请求添加到通过合并所述现有群集中的每一者所形成的新群集。

向每一群集分配产生时间。在分配第一请求后产生群集(使得所述请求起始所述群集)的情形中，所述群集的产生时间对应于将请求添加到所述群集的时间。在通过合并现有群集产生群集的情况下，将产生时间设置为形成新群集的部分的最旧现有群集的产生时间。

以此方式，建立相关请求的群集。可将新请求添加到现有群集，直到所述群集被认为“完整”的时间为止。当所述群集完整时，不添加新请求，且使所述群集中的请求经历与可用交通工具的匹配。

每一群集与用于确定群集何时充满的两个阈值相关联。第一阈值(“最大大小”)是关于群集可含有的请求的最大数目，即，所述群集的最大大小。第二阈值(“最大时延”)是关于交通工具请求在被匹配之前可保留在系统中的最大时间。使用群集的产生时间来考虑此阈值。因为一接收到请求就把请求添加到群集，所以群集的产生时间应近似于所述群集中的最旧请求的存续期。这些阈值可称为“大小”及“时间”阈值。当超过这些阈值中的任一者时，认为群集完整且将所述群集发送到匹配阶段。一般来说，在每单位时间具有可根据经定义关系参数添加到群集的大量请求的情况下，将趋向于基于达到最大大小阈值而认为所述群集完整，而在较不繁忙的区域中，将更有可能在首先到达时间阈值的基础上认为群集完整。

在步骤710中，所述方法包括确定群集是否达到最大大小或最大时延。如果答案为否，那么不采取任何行动。如果答案为是，那么将所述群集中的请求发送到匹配阶段。

可定期轮询所述群集以在超过最大大小阈值或最大时延阈值的基础上检索准备好匹配的那些群集。下文描述实行匹配的方式。如果发现群集达到所述阈值中的一者，那么实行所述群集内的匹配—712。如果所述群集未达到阈值，那么不采取任何行动—714。

参考上文陈述的实例，将了解，尤其当系统忙碌时(即，存在可用于为请求服务的高空间密度的交通工具及/或每单位时间提出的大量请求)，可通过在实行交通工具到请求的匹配之前等待更长的时间以使得能够一起考虑一群请求而非在请求进入时简单地将最近交通工具匹配到每一请求来实现改善的匹配，从而导致用户的较低平均等待时间。然而，在其中请求无限期地连续进入的在线系统中，不可能永远等待，这是因为对可进入的请求的数目不存在限制。

一般来说，在实行匹配之前等待越久，匹配就可越佳。然而，这必须在匹配开始之前相对于对用户引入的额外延迟来平衡。作为说明，考虑两个极端情形。当在知晓每一旅程请求时立即匹配每一旅程请求时，未引发任何额外延迟，但从全局角度，这可导致较差的平均匹配质量。当在进行匹配之前等待所有旅程请求时，引入无限延迟，但可将平均匹配质量调整到最佳。

这些冲突因素之间的最佳平衡取决于系统在给定时间有多繁忙，即，取决于旅程请求的时间分布。当在每时间单位中许多请求进入时，可仅以小额外延迟为代价极大地增加一次性匹配的旅程请求的数目。相反，在不繁忙时间，即使在等待长时间之后，仅可出现少量额外旅程请求或没有额外旅程请求可出现，从而仅微不足道地改善匹配质量且以显著延迟为代价。旅程请求的地理分布同样为实现适当平衡的重要因素。举例来说，在同一时间，系统可能在一个地理区域(例如，邻近社区、地区、城市、区域或甚至国家)中繁忙，但可能在另一地理区域中不繁忙。

本发明以取决于交通工具请求的时间分布及地理分布及/或可用于为所述请求服务的交通工具的地理分布的方式产生群集，而非应用其中基于全局状态(例如，系统的繁忙水平)产生群集的统一规则。

可使用上文论述的关系参数及时间阈值及大小阈值(最大大小、最大时延)来控制产生群集的方式(例如，群集的相对大小，及与群集的请求相关联的位置的地理散布)。

为此目的，用于确定是否将交通工具请求添加到现有群集或用于通过起始群集或合并现有群集来产生新群集的关系参数取决于这些因素中的一或多者。希望所述参数取决于交通工具在与所述群集相关联的地理区域中的空间密度。与群集相关联的地理区域在建立群集时变化，且是关于所述群集的交通工具请求中的一或多者的搭客位置定义的，例如，基于在任何时间形成群集的部分的请求的搭客位置的想象“中心”来定义。替代地，地理区域可基于与首先添加到群集的请求相关联的搭客位置。所述区域可具有任何所要范围以相对于系统的繁忙程度的地理变化来提供所述系统的所需程度的分辨率。举例来说，所述区域可为城镇区域的郊区或中心。

在在所述区域中存在高空间密度的交通工具的情况下，可能将存在紧密接近与请求相关联的任何特定搭客位置的交通工具。因此，在同一群集中包含与地理上间隔较远的搭客位置相关联的请求以一起进行匹配是无益处的，这是因为给定交通工具将不可能为针对这两个旅程的优秀匹配。在此情形中，可将关系参数设置为在添加到群集的请求与所述群集的现有请求之间需要高水平的关系，例如，通过将对搭客位置距所述群集中的请求的搭客位置的最大距离的要求设置为仅需要小距离。这将导致产生含有与限于相对小的地理区域的搭客位置相关联的请求的较大数目的群集。

类似地，在关联于与群集相关联的地理区域中的请求的搭客位置的空间密度较高及/或每单位时间在与群集相关联的地理区域中的请求的数目较高的情况下，可将关系参数设置为需要添加到群集的请求之间的更接近的关系程度，从而导致在这些较繁忙区域中具有较小地理散布的较大数目的群集。

还可取决于类似因素(即，与群集相关联的地理区域中的交通工具或交通工具请求的空间密度及/或所述区域中的请求的时间分布)来选择时间及大小阈值。然而，在其它实施例中，时间阈值及大小阈值独立于此类因素。

所述时间阈值及大小阈值可经设置以提供系统在繁忙时的所要响应水平。通过将最大大小阈值设置为低，在系统较繁忙时，更多群集将由于达到此阈值而被认为完整且准备好匹配。如果将大小阈值设置为高，那么即使系统不那么繁忙，更多群集也将基于到达时间阈值(最大时延)而被认为完整且准备好匹配。应将时间阈值设置为某一水平以设置所述系统所需的所要响应水平。

应设置阈值及关系参数以试图在在给定时间较不繁忙的地理区域中实现在给定时间阈值(即，最大时延)内的相关旅程的最大可能群集(即，就所含有的请求的数目来说)，同时在在给定时间较繁忙的区域中提供相关旅程的足够大的群集以在最小可能时间(即，时延)中提供良好的匹配水平。

一般来说，可预期系统将在城市中心类型区域(即，较繁忙区域)提供基于超过最大大小阈值而被认为完整且准备好匹配的多个较小群集，且在较平静的郊区区域提供基于超过最大时延而被认为完整且准备好匹配的较小数目的较大群集。

将了解，关系参数可基于用于确定请求的相关性的多个准则，而非仅基于地理因素。举例来说，所述参数可考虑与请求相关联的用户偏好，例如待运载的乘客数目、交通工具类型等等。关系参数应导致形成可能可由同一交通工具集合服务的请求群集，从而促进匹配。

虽然已参考立即满足类型请求描述以上过程，但预定请求可适应于此系统。举例来说，预定请求可在预先确定时间(例如，搭客时间之前的30分钟)引入到群集化过程中，或可在专用于此类请求的单独群集化系统中加以处置。替代地，可使用不仅基于地理因素(即，搭客位置)而且还基于搭客时间的关系参数来群集化预定请求。

现将描述用于将交通工具匹配到每一群集的请求的匹配阶段的操作。在群集完整之后，便将所述群集发送到匹配引擎上。在所述群集内实行请求的匹配。

首先，选择可适于为所述群集中的交通工具请求服务的候选交通工具集合。这是通过选择当前位置在与所述群集的一或多个请求相关联的一或多个搭客位置的给定范围内的交通工具的子集来实现。举例来说，可参考单个搭客位置或多个位置的某种类型的中心来定义所述范围。这提供待彼此匹配的交通工具集合及请求集合。

常规地，以最小化交通工具到达搭客位置处的估计到达时间(ETA)为目的来实行匹配过程。然而，本发明者已意识到ETA仅为对司机及用户两者来说均可为重要的若干因素中的一者。本发明的匹配过程可相对于此类额外准则更好地平衡司机的需要与用户的需要。举例来说，用户可具有最喜爱的司机或列入黑名单的司机，或关于交通工具及/或司机的特性的积极或消极偏好。与交通工具相关联的司机可能具有最喜爱的(或列入黑名单的)用户、优选的搭客区域或其想要行驶的优选方向(例如，在接近下班时离家更近)。此外，请求管理系统可具有偏好，例如，其可能想要通过将尤其可靠的司机指派到尤其有利可图的旅程来奖励尤其可靠的司机。

为了试图平衡此类偏好，将匹配值指派到潜在的每一对交通工具请求及交通工具。此值是作为ETA及关于待考虑的额外准则中的任何者的不同分数的加权组合而计算的。

用户能够针对每一交通工具请求指定与其它准则(例如，司机是否具有高安全评级等等)相比指派到ETA的相对权重。类似地，司机能够指定应加上较高权重以提供在一天的某些时间使司机更接近家的位置的旅程。

匹配优化过程可建模为偶图中的最大权重匹配问题，其中上文描述的匹配值用作对于连接交通工具与交通工具请求的边的权重。可以各种方式(例如，通过也称为匈牙利法(Hungarian Method)的原始对偶算法)计算最优解(即，针对每一经匹配对具有最高平均匹配值的匹配)。

成本函数可用于确定合适司机(即，用于满足给定交通工具请求的交通工具)的等级列表。将了解，在某些交通工具可由多个司机使用的情况下，交通工具在匹配过程中的等级将取决于已知在给定时间驾驶或被预期在相关搭客时间驾驶的司机。可相对于每一参数而产生积极等级或消极等级，且等级可乘以客户对所述参数的偏好的权重。以此方式，个别用户的用户偏好可与与交通工具相关联的司机就所述参数的表现相关。对所有可能司机的输出进行加权及比较可导致产生最佳匹配司机的等级。

关于将交通工具匹配到群集的交通工具请求，一旦针对所述群集内的每一交通工具请求识别最合适的司机，就将交通工具请求提供到所述司机。这可通过将搭客位置的详细资料及与所述交通工具请求相关联的任何其它详细资料发射到装置(例如，与所述交通工具相关联的导航装置)来实行。这可以上文描述的方式来实行。

因为优选地实行匹配使得其不仅仅基于地理因素，所以请求将可能由被认为是最适于所述请求的交通工具的司机接受。然而，应认识到，针对每一旅程请求仅选择一个交通工具可能是不足够的，这是因为司机可能拒绝报价(offer)或不响应报价。

在一些实施例中，实施进一步过程以在第一、最合适司机不接受请求的情况将所述请求提供到后备交通工具。

当根据以上技术将群集的交通工具请求匹配到交通工具时，为了跨越整个群集提供适当匹配，优选地将每一交通工具请求分配到最多一个交通工具。这些交通工具被称为1等交通工具(或替代地，与所述交通工具相关联的司机可被认为是1等司机)

除这些1等交通工具之外，还选择后备司机，即，2等、3等或更多等级的司机。2等交通工具是当以仅考虑所述一个交通工具请求(即，而非试图关于群集的所有请求进行优化)的常规方式执行匹配过程时被认为具有针对请求的最高匹配值的交通工具。可针对每一旅程确定2等交通工具。3等交通工具可被认为是基于常规技术的下一个最合适的交通工具，以此类推。可将单个2等或更高等级的交通工具分配到每一交通工具请求，或可将多个此类交通工具分配到每一请求。举例来说，在分配两个2等交通工具的情况下，这些交通工具可为基于常规技术具有最高匹配值及次高匹配值(以此类推)的交通工具。

可设想各种布置，其中每一等级的交通工具被独占地指派到一个请求，例如，使得其不可作为相同等级的交通工具用于其它请求及/或不可作为更高等级的交通工具用于旅程。

一个特定实施方案将1等交通工具保持为完全独占的，即，交通工具仅可为最多一个请求的1等交通工具，且1等交通工具不可为针对任何请求的更高等级的交通工具；而对2等或更高等级的交通工具的仅有约束为其仅可能作为相同请求的交通工具(具有任何等级)至多出现一次。

交通工具等级可用于以某种次序向交通工具提供旅程。首先将请求提供到其1等交通工具(或如果存在若干1等交通工具，那么同时将所述请求提供到所有所述交通工具)。如果1等交通工具(或所有1等交通工具)在给定时段内不接受所述请求，那么将所述请求提供到其2等交通工具(或如果存在若干2等交通工具，那么同时将所述请求提供到所有所述交通工具)，以此类推。

可根据需要设置此过程的参数(即，其中交通工具被提供(请求)的“回合”数及每一等级的交通工具的数目)。一个特定实施方案针对每一等级可仅具有一个交通工具，使得请求绝不会被同时提供到若干交通工具，从而避免司机的竞争状况。

将了解，虽然上文已描述本发明的各种方面及实施例，但本发明的范围限于本文中陈述的特定布置且替代地扩展到涵盖所有布置及对其的修改及变更。举例来说，虽然以上描述中描述的实施例涉及GPS，但应注意，所述装置可利用任何种类的位置感测技术作为对GPS的替代或(实际上)补充。举例来说，所述装置可利用其它全球导航卫星系统，例如欧洲伽利略系统。同样，其不限于基于卫星的系统，而可使用使得所述装置能够确定其地理位置的陆基信标或其它种类的系统来容易地起作用。

所属领域的一般技术人员还将理解，虽然优选实施例可借助软件实施某功能性，但所述功能性可同样单独以硬件(例如，借助一或多个SIC(专用集成电路))实施或实际上由硬件与软件的混合实施。

最后，应注意，虽然所附权利要求书陈述本文中描述的特征的特定组合，但本发明的范围不限于下文主张的特定组合，而是替代地扩展到本文中揭示的特征或实施例的任何组合，而不论所述特定组合此时是否已在所附权利要求书中具体列举。

Claims (22)

1.一种在服务器处管理交通工具请求的方法，所述服务器可访问指示多个交通工具中的每一者的当前位置的数据，所述方法包括：

在服务器处接收多个交通工具请求；

产生一或多个群集，每一群集包括多个所述交通工具请求；以及

将交通工具匹配到所述群集或每一群集内的每一相应交通工具请求。

2.根据权利要求1所述的方法，其中所述服务器包括通信构件，所述通信构件用于与用于提出交通工具请求的多个第一装置及与用于满足所提交的交通工具请求的相应交通工具相关联的多个第二装置通信。

3.根据权利要求2所述的方法，其中每一第一装置具有存储在所述服务器处的相关联位置，且其中每一交通工具请求至少包括第一位置，所述第一位置对应于所述相关联位置。

4.根据权利要求2所述的方法，其中所述第一装置包括具有经布置以确定所述装置的当前地理位置的位置确定构件的移动装置，且其中每一交通工具请求至少包括第一位置，所述第一位置对应于所述第一装置的所述当前地理位置。

5.根据任一前述权利要求所述的方法，其中所述交通工具请求包括指示搭客位置及以下项目中的一或多者的数据：目的地位置；搭客时间；一或多个司机偏好；一或多个交通工具偏好；待搭载的人数；及所要司机评级。

6.根据任一前述权利要求所述的方法，其进一步包括使指示在所述服务器处接收所述请求的时间的数据与每一所接收交通工具请求相关联。

7.根据任一前述权利要求所述的方法，其中所述产生所述一或多个群集的步骤考虑以下项目中的一或多者：使用与每一请求相关联的搭客位置数据确定的所述多个交通工具请求的地理分布；使用所述交通工具的当前位置数据确定的所述多个交通工具的地理分布；及所述多个交通工具请求的时间分布。

8.根据任一前述权利要求所述的方法，其中与每一所产生群集相关联的所述交通工具请求被认为基于一或多个关系量度彼此相关。

9.根据任一前述权利要求所述的方法，其包括将每一交通工具请求分配到给定群集，其中所述将请求分配到群集的步骤包括将所述请求分配到现有群集或使用所述请求来产生新群集，其中使用请求来产生新群集包括使用所述交通工具请求来起始所述群集，或将所述交通工具请求添加到通过合并多个现有群集产生的群集。

10.根据权利要求9所述的方法，其包括通过基于一或多个关系量度评估可认为所接收交通工具请求与一或多个现有群集的一或多个交通工具请求相关的程度来确定是否将所述所接收交通工具请求添加到现有群集或用于产生新群集。

11.根据任一前述权利要求所述的方法，其包括：

当基于所述一或多个关系量度可认为所接收请求与所述群集的现有请求中的一或多者相关时，将所述所接收交通工具请求添加到现有群集；

当基于所述一或多个关系量度不认为所接收交通工具请求与现有群集的所述现有请求中的任何者相关时，使用所述交通工具请求来产生新群集；及/或

当确定可认为所接收交通工具请求与多个现有群集中的每一者的所述现有请求中的一或多者相关时，使用所述所接收交通工具请求通过合并所述多个群集来产生新群集。

12.根据权利要求10或11所述的方法，其中所述一或多个关系量度至少包含指示地理关系的量度，任选地，其中所述量度指示待由与交通工具请求相关联的搭客位置数据满足以使所述请求被添加到所述群集的范围要求。

13.根据权利要求10到12中任一权利要求所述的方法，其中用于评估交通工具请求与现有群集的一或多个现有交通工具请求之间的关系的所述一或多个关系量度是基于以下项目中的一或多者来定义：使用与基于与所述群集相关联的一或多个位置的地理区域中的所述交通工具请求相关联的位置确定的所述交通工具请求的地理分布；基于交通工具在基于与所述群集相关联的一或多个位置的地理区域中的当前位置数据的所述交通工具的地理分布；及在基于与所述群集相关联的一或多个位置的地理区域中的交通工具请求的时间分布。

14.根据任一前述权利要求所述的方法，其中所述将交通工具匹配到群集的每一交通工具请求的步骤包括：仅当参考时间相关阈值及关于由所述群集包括的交通工具请求的数目的阈值中的任一者认为所述群集完整时，才将交通工具匹配到所述群集内的每一交通工具请求。

15.根据任一前述权利要求所述的方法，其中所述将交通工具匹配到群集的每一交通工具请求的步骤包括基于一或多个准则确定适于满足所述群集的所述请求的交通工具集合，其中所述准则至少包含地理准则。

16.根据权利要求15所述的方法，其包括基于所述交通工具到达与每一请求相关联的所述第一位置或搭客位置的所估计到达时间及一或多个其它准则来将来自所述确定交通工具集合的交通工具匹配到所述群集的所述交通工具请求集合，所述其它准则包含以下项目中的一或多者：用户准则；司机准则；交通工具准则；系统准则及基于历史司机行为及历史用户行为的准则。

17.根据任一前述权利要求所述的方法，其包括所述服务器将每一交通工具请求提供到所述交通工具请求已被匹配到的所述交通工具。

18.根据任一前述权利要求所述的方法，其中匹配到每一群集的所述交通工具请求的所述交通工具集合提供用于满足所述群集的所述交通工具请求的一级交通工具集合，其中参考所述群集的每一其它交通工具请求来实行每一一级交通工具到交通工具请求的匹配，任选地，其中将单个一级交通工具匹配到每一交通工具请求，且其中所述方法进一步包括在不考虑所述群集中的其它请求的情况下通过将交通工具匹配到所述群集的每一请求来将至少一个二级交通工具分配到所述请求，任选地其中将多个二级交通工具分配到每一请求。

19.根据权利要求18所述的方法，其包括将每一交通工具请求提供到针对所述请求的所述一级交通工具，且如果未在给定时间内接受所述请求，那么将所述请求提供到针对所述请求的所述二级交通工具或每一二级交通工具。

20.一种交通工具请求管理系统，所述系统包括可访问指示多个交通工具中的每一者的当前位置的数据的服务器，所述服务器包括：

通信构件，其经布置以接收多个交通工具请求；

处理构件，其经布置以产生一或多个群集，每一群集包括多个所述交通工具请求；以及

处理构件，其经布置以将交通工具匹配到所述群集或每一群集内的每一相应交通工具请求。

21.根据权利要求20所述的系统，其中所述服务器经布置以使指示在所述服务器处接收每一交通工具请求的时间的数据与每一请求相关联。

22.一种计算机程序产品，其包括可执行以执行根据权利要求1到19中任一权利要求所述的方法的计算机可读指令。