CN103959355A - 用于定位一个或多个对等体的系统和方法 - Google Patents

Abstract

可以提供一种用于定位一个或多个对等体的系统和方法，其中，该方法包括：确定请求对等体的位置信息（例如地理位置）；基于该请求对等体的位置信息确定用于约定的至少一个可用对等体的位置信息；以及将该至少一个可用对等体的位置信息发送到该请求对等体。

Description

用于定位一个或多个对等体的系统和方法

技术领域

本发明广泛地涉及用于定位一个或多个对等体的系统和方法。

背景技术

在对等约定中，通常需要进行通信的对等体具有一些关于彼此的信息以便利约定。例如，这种约定可以是出租车乘客寻求叫出租车或预约出租车。

在示例场景中，通常，出租车乘客（一个对等体）不得不在出租车站点或沿着路边等待出租车（另一个对等体）的到来。出租车乘客不确定出租车到来之前的等待持续时间。同样，出租车司机通常到处驾驶以定位潜在的出租车乘客。这可能导致将时间和资源浪费在试图定位出租车乘客上。

为了努力缓解上述情况，一种方法是设置用于管理用于出租车的预约的呼叫的呼叫中心。出租车乘客可呼叫出租车预约热线以预约出租车。随着技术的进步，诸如短信服务系统（SMS）消息、电子邮件和互联网web预约的不同平台被呼叫中心所支持。也就是说，出租车乘客可通过由呼叫中心支持的这些可用的平台预约出租车。一般而言，预订出租车是通过呼叫路由到由出租车公司管理的出租车呼叫中心的指定的出租车热线号码来完成的。

通常，呼叫中心一般由出租车公司操纵。在市场中有很多出租车公司，每个出租车公司在市场中具有不同的出租车车队大小，由此可能出现在市场中存在具有不同的可用热线号码的多个呼叫中心的情况。因此，乘客需要注意到市场中的各种可用的出租车预约热线号码。

另外，具有较大车队的出租车公司倾向于在市场中占主导地位，其各自的呼叫中心热线通常比其他出租车公司更受欢迎。在高峰时段期间，这些更受欢迎的呼叫中心则通常被预订电话拥塞。因此，呼叫中心可能成为用于处理出租车预约呼叫的瓶颈，同时具有比较不受欢迎的呼叫中心的其他出租车司机正在路上四处漫游寻找潜在的乘客。而且，在呼叫中心处，预订由呼叫接线员分配给出租车司机，当一个呼叫接线员必须服务多个出租车司机时，瓶颈频繁地出现。

进一步地，维护呼叫中心通常是成本高昂的，具有小出租车车队大小的出租车公司可能面临运营呼叫中心的财务问题。因此，为了支付运营呼叫中心的成本，该成本通常经由出租车预约费而转移给乘客，出租车预约费通常是出租车公司和出租车司机的收入来源。也就是说，相比于在街边叫出租车，预约费是因为使用预约服务而向出租车乘客收取的附加量。

一种利用诸如苹果iOS使能的iPhone、Android使能的电话等的智能手机或智能移动设备的基于位置的服务已被提议用来辅助出租车乘客预订出租车。然而，已认识到这种服务只是由呼叫中心提供的预约服务的扩展，原因在于形式例如为移动应用的基于位置的服务是被集成到呼叫中心系统或被编程以执行到呼叫中心预订系统的自动拨号。该系统仍继承了呼叫中心正是瓶颈的问题，这里其效率极大地依赖于系统的处理能力。而且，处理能力是依赖于与移动应用进行通信的计算机主机。来自移动应用的预约被发送到主机，主机转而向出租车广播作业请求。出租车司机被允许响应，预约通常先来先服务地被提供，即，提供给对作业请求响应的第一个出租车司机。因此，可能会出现被给予预约的出租车司机可能不在乘客的附近的问题。

此外，对于上述预约服务，乘客通常与呼叫中心的工作人员或系统通信，呼叫中心的工作人员或系统与出租车司机通信。通常乘客与司机之间没有直接联系。通常，仅在预订确认后，例如出租车车辆号码和预计到达时间（ETA）被发送给乘客。出租车的其他细节不为乘客所知，而且进一步地，乘客不能对出租车进行选择或挑选。

另外，预约通常依赖于针对乘客的作业请求向呼叫中心进行响应的出租车。因此，该出租车可能不是在预约时到乘客最近的可用出租车，从而增加了到达时间。

因此，存在对试图解决上述问题中的至少一个的用于定位一个或多个对等体的系统和方法的需求。

发明内容

根据本发明的第一方面，提供了一种用于定位一个或多个对等体的方法，该方法包括：确定请求对等体的位置信息；基于该请求对等体的位置信息确定用于约定的至少一个可用对等体的位置信息；以及将该至少一个可用对等体的位置信息发送到该请求对等体。

该方法可进一步包括向该请求对等体呈现该至少一个可用对等体的位置信息。

该方法可进一步包括在图形显示中显示该请求对等体的所述位置信息、用于约定的所述至少一个可用对等体的所述位置信息、或者上述两者。

该方法可进一步包括允许该请求对等体对所选可用对等体的挑选。

该至少一个可用对等体可以是已针对该请求对等体的定位主动指示可用状态的对等体。

所述确定请求对等体的位置信息可包括由用户输入约定位置信息。

约定位置信息的用户输入可包括使用连接到网络的web浏览器输入地址信息。

所述确定请求对等体的位置信息可进一步包括利用该请求对等体处的基于位置的服务。

所述确定用于约定的所述至少一个可用对等体的位置信息可进一步包括利用该至少一个可用对等体处的基于位置的服务。

所述基于该请求对等体的位置信息确定用于约定的所述至少一个可用对等体的位置信息可包括使用从请求对等体发送的范围信息。

所述将该至少一个可用对等体的位置信息发送到该请求对等体可包括发送该至少一个可用对等体的简档和/或历史明细。

该方法可进一步包括允许该请求对等体与所述至少一个可用对等体之间的约定。

该方法可进一步包括经由所述至少一个可用对等体生成用于发送到该请求对等体的服务支付消息而确认约定。

该方法可进一步包括经由该请求对等体生成用于发送到所述至少一个可用对等体的服务支付消息而确认约定。

请求对等体可以是请求交通服务的实体，该至少一个可用对等体是提供交通服务的实体。

请求对等体可以是提供交通服务的实体，该至少一个可用对等体是请求交通服务的实体。

确定用于约定的至少一个可用对等体的位置信息的步骤可包括动态地确定位置信息。

根据本发明的第二方面，提供了供请求对等体用于定位一个或多个对等体的通信设备，该设备包括：用于确定请求对等体的位置信息的模块；用于接收用于约定的至少一个可用对等体的位置信息的接收模块，至少一个可用对等体的所述位置信息基于该请求对等体的位置信息而确定。

该设备可进一步包括用于显示该请求对等体的所述位置信息、用于约定的所述至少一个可用对等体的所述位置信息、或者上述两者的图形显示。

该设备可进一步包括用于该请求对等体对所选可用对等体的挑选的输入模块。

该设备可进一步包括用于针对对等体的定位主动开启可用状态的输入界面。

用于确定请求对等体的位置信息的模块可包括约定位置信息的用户输入字段。

约定位置信息的用户输入可包括使用连接到网络的web浏览器输入地址信息。

该设备可进一步包括基于位置的服务模块。

该基于位置的服务模块可与用于确定该请求对等体的位置信息的模块集成在一起。

至少一个可用对等体的所述位置信息可在该至少一个可用对等体处使用基于位置的服务而确定。

至少一个可用对等体的所述位置信息可进一步基于从该请求对等体发送的范围信息而确定。

所述接收模块能够接收该至少一个可用对等体的简档和/或历史明细。

该设备可进一步包括用于确认该请求对等体和该至少一个可用对等体的约定的消息传送模块，其中该至少一个可用对等体可生成用于经由该消息传送模块发送到该请求对等体的服务支付消息。

该设备可进一步包括用于确认该请求对等体和该至少一个可用对等体的约定的消息传送模块，其中该请求对等体可生成用于经由该消息传送模块发送到该至少一个可用对等体的服务支付消息。

请求对等体可以是请求交通服务的实体，该至少一个可用对等体可以是提供交通服务的实体。

请求对等体可以是提供交通服务的实体，该至少一个可用对等体是请求交通服务的实体。

至少一个可用对等体的所述位置信息可动态地被确定。

根据本发明的第三方面，提供了用于对等约定的系统，该系统包括：请求对等体通信设备，一个或多个可用约定对等体通信设备，和应用服务器；其中，该请求对等体通信设备包括：用于确定该请求对等体的位置信息的模块，用于从应用服务器接收用于约定的至少一个可用对等体的位置信息的接收模块；并且其中，对于该一个或多个可用约定对等体通信设备，每个可用约定对等体通信设备包括：用于确定该可用约定对等体的位置信息的模块，用于向应用服务器发送该可用约定对等体的位置信息的发送模块；另外其中，应用服务器被配置为接收该请求对等体的位置信息并基于该请求对等体的位置信息确定至少一个可用对等体的所述位置信息。

每个可用约定对等体通信设备可进一步包括用于针对请求对等体的定位主动开启可用状态的输入界面。

该请求对等体通信设备可进一步包括用于针对对等体的定位主动开启可用状态的输入界面。

用于确定请求对等体的位置信息的模块可包括约定位置信息的用户输入字段。

约定位置信息的用户输入可包括使用连接到耦接于应用服务器的网络的web浏览器输入地址信息。

至少一个可用对等体的所述位置信息可在该至少一个可用对等体处使用基于位置的服务而确定。

至少一个可用对等体的所述位置信息可进一步基于从该请求对等体发送到应用服务器的范围信息而确定。

应用服务器可被配置为向接收模块发送该至少一个可用对等体的简档和/或历史明细。

应用服务器可被配置以向该请求对等体发送服务支付消息用于确认该请求对等体和该至少一个可用对等体的约定。

应用服务器可被配置以向该至少一个可用对等体发送服务支付消息用于确认该请求对等体和该至少一个可用对等体的约定。

该系统可进一步包括被配置为处理来自该请求对等体或该至少一个可用对等体的支付的支付服务器。

请求对等体可以是请求交通服务的实体，该至少一个可用对等体可以是提供交通服务的实体。

请求对等体可以是提供交通服务的实体，该至少一个可用对等体是请求交通服务的实体。

应用服务器可被进一步配置为动态地确定至少一个可用对等体的所述位置信息。

根据本发明的第四方面，提供了其上存储有计算机代码部件的计算机可读数据存储介质，该计算机代码部件用于指示通信设备的处理模块来执行用于定位一个或多个对等体的方法，该方法包括：确定请求对等体的位置信息；接收用于约定的至少一个可用对等体的位置信息，至少一个可用对等体的所述位置信息基于该请求对等体的位置信息而确定。

该方法可进一步包括在通信设备的图形显示中显示该请求对等体的所述位置信息、用于约定的所述至少一个可用对等体的所述位置信息、或者上述两者。

该方法可进一步包括允许该请求对等体对所选可用对等体的挑选。

该至少一个可用对等体可以是已针对该请求对等体的定位主动指示可用状态的对等体。

至少一个可用对等体的所述位置信息可动态地被确定。

附图说明

根据以下结合附图并仅作为示例的说明，本领域的技术人员将更好地理解和更容易地清楚本发明的示例性实施例，其中：

图1是示例性实施例中的基于位置的对等系统的示意性描述。

图2是为用于描述示例性实施例中的系统的网络架构示意图。

图3是用于描述示例性实施例中的对等约定的示意性流程图。

图4是示例性实施例中的示意性对等交易流程图。

图5描述了示例性实施例中的使用“叫出租汽车”的基于位置的服务（LBS）的移动应用图形用户界面（GUI）的示例场景。

图6是示例性实施例中的约定处理的示意性逻辑流程图。

图7是示例性实施例中的应用服务器的示意性模块架构图。

图8是示例性实施例中的客户端应用的示意性模块架构图。

图9是用于描述示例性实施例中的用于定位一个或多个对等体的方法的示意性流程图。

图10是适合于实现示例性实施例的通信设备的示意图。

具体实施方式

在下述示例性实施例中，可提供实时的、基于位置的对等交互式的方法和系统。对等体可使用该方法和系统进行约定。对等体可包括寻求约定或提供约定的实体，并且一般可包括用于租用的车辆或船只。约定可以指两个用户或对等体同意交易或执行服务，诸如乘客租用出租车。在以下描述中，使用出租车或出租汽车以易于对约定方法和系统的描述。

在一个示例性实施例中，一个对等体（出租车乘客）和另一个对等体（出租车司机）可以使用基于地理位置的系统和方法，以一方面叫出租车和在另一方面供出租车司机定位出租车乘客。该系统和方法可向诸如出租车乘客和出租车司机的不同对等体提供移动性和便利。此外，可以提供的是一个对等体可查看一个或多个对等体的位置以对约定做决定。

在整个说明中，出于说明的目的，阐述了许多具体细节以提供对本发明的示例性实施例的理解。然而，对于本领域的技术人员来说明显的是，本发明的一些实施例可在没有这些具体细节中的一些的情况下而被实践。

在该说明中使用的术语“耦接”或“连接”旨在涵盖直接连接或通过一个或多个中间部件连接两者，除非另有说明。

此处的描述在某些部分可被显式或隐式地描述为对电子线路或计算机存储器内的数据操作的功能操作和/或算法。这些算法描述和/或功能操作通常由信息/数据处理领域的技人员用于有效的描述。算法一般地涉及产生想要的结果的自洽的步骤序列。算法的步骤可包括对物理量的物理操作，这些物理量诸如能够被存储、发送、传递、组合、比较以及以其他方式操作的电、磁或光信号。

此外，除非特别声明，否则通常根据以下内容明显的是，本领域的技术人员会清楚，在本说明书中，使用诸如“扫描”、“计算”、“确定”、“替换”、“生成”、“初始化”、“输出”等的术语是指指令处理器/计算机系统或类似的电子电路/设备/组件的动作和处理，指令处理器/计算机系统或类似的电子电路/设备/组件将在所描述的系统内被表示为物理量的数据，操作/处理和转换为在该系统或其他信息存储、发送或显示设备等内被同样地表示为物理量的其他数据。

说明还公开了用于执行所描述方法的步骤的相关设备/装置。这种装置可出于该方法的目的而被特别构造，或者可包括通用计算机/处理器或由存储在存储构件中的计算机程序选择性地激活或重新配置的其设备。这里描述的算法和显示不固有地与任何特定的计算机或其他装置相关。根据这里的教导可以理解，通用设备/机器可被使用。另选地，可能需要构建执行该方法步骤的专用设备/装置。

另外，说明还隐式地涵盖了计算机程序，因为将会清楚的是，这里所描述的方法的步骤可由计算机代码实施。将会清楚的是，多种多样的编程语言和编码可被用于实现这里的说明的教导。而且，如果适用的话，计算机程序并不被限制于任何特定的控制流程，并且可以使用不同的控制流程，而不脱离本发明的范围。

此外，如果适用的话，一个或多个计算机程序步骤可被并行和/或按顺序执行。如果适用的话，这样的计算机程序可被存储在任何计算机可读介质上。计算机可读介质可包括诸如磁或光盘、存储器芯片、或适合于与合适的读取器/通用计算机相接口的其他存储设备的存储设备。在这种情况下，计算机可读存储介质是非易失性的。这种存储介质也涵盖了所有的计算机可读介质，例如仅短时期和/或仅在存在电源时存储数据介质，诸如寄存器存储器、处理器高速缓存和随机存取存储器（RAM）等。计算机可读介质甚至可包括诸如在因特网系统中所示例的有线介质和诸如在蓝牙技术中所示例的无线介质。当计算机程序在合适的读取器上加载并执行时，有效地产生可实现所描述的方法的步骤的装置。

示例性实施例还可被实现为硬件模块。模块是被设计为与其他组件或模块一起使用的硬件功能单元。例如，模块可使用数字或分立电子组件来实现，或者其可形成诸如专用集成电路（ASIC）的整个电子电路的一部分。本领域的技术人员会理解示例性实施例还可被实现为硬件和软件模块的组合。

进一步地，在这里的说明中，每当词语“基本”被使用时将被理解为包括但不限于“全部地”或“完全地”等等。进一步地，每当诸如“包括”、“包含”等的术语被使用时，旨在作为非限制的描述性语言，因为这种术语广义地在未显式地记载的其他组件之外，还包括其后面所记载的元件/组件。进一步地，每当诸如“大约”、“大致”等的术语被使用时，通常意指合理的变化，例如所公开值的+/-5%的变化、或所公开值的4%的差异、或所公开值的3%的差异、或所公开值的2%的差异、或所公开值的1%的差异。

此外，在这里的说明中，某些值可被公开为范围。表示范围的端点的值旨在描述优选的范围。每当已描述了范围，其目的在于该范围涵盖并教导了所有可能的子范围以及在该范围内的单独数值。就是说，范围的端点不应被解释为僵化的限制。例如，对1%到5%的范围的说明旨在具体公开了子范围1%到2%、1%到3%、1%到4%、2%到3%等，以及在该范围内的诸如1%、2%、3%、4%和5%的单独的值。上述具体公开内容的目的适用于范围的任何深度/宽度。

基于位置的服务（LBS）——例如移动计算应用——可基于地理位置向用户提供服务。在示例性实施例中，可提供例如在出租车交通部门中的并且使用例如用于实时、交互的“叫出租车”和/或“乘客位置”的LBS的对等（例如，乘客到出租车司机或出租车司机到乘客）定位系统。LBS可使用诸如“查找附近的出租车”和“告诉我在我附近的出租车是否被租用或预订”等的功能。LBS可接着辅助解决问题，诸如辅助乘客“叫出租汽车”、辅助出租车司机搜索潜在的乘客以“定位乘客”、以及潜在地减轻由出租车公司运营的呼叫中心系统的效率低下。

在示例性实施例中，出租车乘客可使用诸如智能电话的通信设备实时地“叫出租车”，以访问或开始允许定位附近的出租车的基于位置的服务（LBS）。使用LBS，出租车乘客能够经由图形显示（例如在地图上）可视地定位在附近可用的若干出租车。乘客还能够经由无线访问或因特网来访问应用服务器，以例如获取已进行的出行的信息、检索并检查过去的行驶记录、支付记录和乘客的收据。

在示例性实施例中，出租车司机可使用诸如安装在出租车中的处理器单元或智能电话的通信设备实时地“定位出租车乘客”，以访问或开始允许定位附近的潜在乘客的基于位置的服务（LBS）。使用LBS，出租车司机能够经由图形显示（例如在地图上）可视地定位在附近等待出租车的乘客。出租车司机还能够经由无线访问或因特网来访问应用服务器，以例如获取已进行的出行的信息、检索并检查过去的行驶记录、出租车费的支付记录和出租车司机的收据。

在示例性实施例中，乘客通信设备中的LBS移动应用可经由应用服务器与出租车司机的对应的LBS移动应用通信，以供乘客实时地叫出租车。使用LBS移动应用，出租车乘客能够通过经由图形显示（例如在地图上）而可视地定位在附近可用的出租车的数量来“叫其选择的出租车”，向所选择的出租车发送作业请求，跟踪出租车的运动以及优选的交易支付。

在示例性实施例中，出租车司机的通信设备中的LBS移动应用可经由应用服务器与乘客通信设备中的对应的LBS移动应用通信，以供出租车司机实时地定位潜在的乘客。使用LBS移动应用，出租车司机能够通过经由图形显示（例如在地图上）而可视地定位在附近可用的潜在乘客的数量来“定位其选择的乘客”，向潜在乘客发送服务请求，允许跟踪经约定的乘客的运动以及优选的交易支付。

图1是示例性实施例中的基于位置的对等系统100的示意性描述。在示例性实施例中，一个对等体被示例性地指示为使用诸如移动设备110的乘客通信设备的潜在乘客。另一个对等体被示例性地指示为使用诸如移动设备150的出租车司机通信设备的出租车司机。在示例性实施例中，每个对等体（乘客或出租车司机）具有对他/她的位置信息的完全的控制。例如，出租车司机能够通过关闭他/她的位置状态而禁用位置跟踪。每个通信设备110、150包括可与应用服务器130进行通信的客户端应用180。应用服务器130远离使用通信设备110、150的用户或位于与其不同的位置。优选地，应用服务器130耦接于支付方案服务器120并与其进行通信。

在示例性实施例中，应用服务器130试图提供可辅助于记录和/或记帐目的的管理功能，诸如管理交易日志记录等。

图2是用于描述示例性实施例中的系统100的网络架构200的示意图。网络架构200包括用于确定位置的服务（诸如GPS卫星服务230），用于允许通信设备110、150和应用服务器130之间的通信的介质，诸如与通信设备110、150无线（或有线/固定）通信的以及与应用服务器130网络（或因特网）220通信的移动载体210。移动载体210可以是电话公司（telco）。应用服务器130可与支付方案服务器120网络（或因特网）240通信。可以清楚的是，网络（或因特网）通信220、240可以是无线或有线/固定的。

图3是用于描述示例性实施例中的对等约定的示意性流程图302。在步骤300处，用户（诸如乘客或出租车司机的对等体）将客户端应用下载和/或安装到通信设备中。客户端应用（例如图1和图2的客户端应用180）使得能够进行对等约定。下载和/或安装可能依赖于正被使用的通信设备的类型。例如，通信设备可包括苹果iOS的iphone、谷歌的基于android的电话、黑莓的智能手机和基于Windows的设备等。

在步骤310和350处，用户经由其通信设备注册为对等体，例如在步骤310处的乘客或在步骤350处的出租车司机。例如，对于出租车司机，一些注册详细信息可包括联系电话号码、公司名称、出租车号码、银行帐户详细信息等。对于乘客，一些注册详细信息可包括联系电话号码、信用卡详细信息、通常/喜爱的搭乘位置或“书签”等。比照对数字603的描述。根据实现的参数，信用卡详细信息可被存储在例如电话本地数据库和/或应用服务器中。可以设置的是，出于验证的目的，OTP（一次性密码）或短信代码等可被生成并发送给用户，使得用户被验证为是真实的用户。

下面的描述分为首先描述乘客对等体，之后继续进行描述出租车司机对等体的部分。乘客对等体部分被示出在图3的左手边，出租车司机对等体部分被示出在图3的右手边。

此后，在步骤311处，在开始/运行客户端应用后，乘客的位置状态被设置为“打开”。开始或运行客户端应用可例如通过激活通信设备（比照图1和2中的110）的图形显示上的用于客户端应用的“打开”/“运行”按钮/滑块而被激活。这可包括在通信设备的电容式触摸屏等上感测到的触摸信号。

开始/运行客户端应用包括向应用服务器（比照图1和2中的130）发送指示想要开始约定的激活信号。激活信号可包括激活对等体（乘客）的位置信息。在某些示例性实施例中，位置信息可在稍后的阶段被提供，例如在搜索阶段。位置信息可由通讯设备（比照图1和2中的110）的LBS提供。在另选的示例性实施例中，位置信息可由对等体提供的信息补充或完全由其提供。例如，在另选的示例性实施例中，搭乘的位置信息（即期望的搭乘点）可由乘客提供或修改/补充，例如从当前位置推测。提供位置信息可包括经由连接到因特网的浏览器输入搭乘地址，或在触摸屏的图形显示上将图标拖到所需的位置。

在某些示例性实施例中，开始/运行客户端应用可指示对等体可用于与另一个对等体的约定，例如向出租车指示乘客可由出租车接载，或向乘客指示有可用出租车用于约定。

在步骤312处，注册的乘客可使用客户端应用来在通信设备的图形显示上可视地搜索和显示在指定的雷达范围内的所有可用的约定对等体，诸如出租车。这些是在其通信设备（比照图1和2中的150和稍后在步骤351处所描述的）上指示了可用的对等体。客户端应用可以用通信设备的图形显示上的用于客户端应用的搜索按钮/滑块被激活用于搜索，以搜索可用出租车。这可包括在通信设备的电容式触摸屏等上感测到的触摸信号。雷达的范围或附近可根据用户的需求从列表被预先确定或挑选，例如10到100米、100到500米和500米到1公里等的半径。

激活搜索包括向应用服务器（比照图1和2中的130）发送请求信号以在指定的附近内发送可用对等体的信息。请求信号可包括预先确定或挑选的范围，作为范围信息。在应用服务器（比照图1和2中的130）处，搜索通过数据库被执行，以基于请求对等体（乘客）的位置信息和所接收的范围信息确定适合于约定的对等体（例如出租车）。应用服务器（比照图1和2中的130）接着发送适合于约定的对等体的结果到请求对等体通信设备（比照图1和2中的110）。结果可显示在通信设备上的图形显示中。

在步骤313处，乘客可检索和查看与所定位的出租车司机相关的详细信息，包括诸如出租车公司详细信息、车辆详细信息和其他详细信息（诸如评级、评论等）的由先前的乘客提供的信息。检索可基于乘客挑选在图形显示上显示的每个对等体。就是说，出租车或车辆的图形表示被显示在乘客的通信设备上以用于挑选。一经挑选，详细信息可从应用服务器被发送。另选地，详细信息可在步骤312中与结果信息一起被发送。

在步骤314中，在查看了详细信息后，乘客自由挑选优选的出租车并向所挑选的出租车司机发送作业请求。就是说，作业请求信号经由应用服务器（比照图1和2中的130）被从请求对等体通信设备（比照图1和2中的110）发送到用于约定的对等体的通信设备（比照图1和2中的150）。作为另选方案，作业请求信号绕开应用服务器（比照图1和2中的130）被从请求对等体通信设备（比照图1和2中的110）直接发送到用于约定的对等体的通信设备（比照图1和2中的150）。

在示例性实施例中，作业请求信号包括可以是当前位置或所需的搭乘位置的乘客位置信息。优选地是，作业请求可包括所需的目的地。

在用于约定的对等体（例如所挑选的出租车）的通信设备（比照图1和2中的150）处，作业请求被指示在图形显示上用于接受或拒绝。

在示例性实施例中，出租车司机可选择拒绝或接受所接收到的作业请求。如果出租车司机拒绝作业请求，则乘客通过拒绝信号被通知，乘客可继续进行选择下一个选择。就是说，处理循环到步骤312处。这种通信可以是经由应用服务器，或者绕开应用服务器（比照图1和2中的130）直接在请求对等体通信设备（比照图1和2中的110）到用于约定的对等体的通信设备（比照图1和2中的150）之间。对于直接的通信，例如，设备之间的通信链路可通过向通信设备发送链路详细信息（诸如设备标识号码或因特网协议（IP）地址等）的应用服务器的辅助而被建立。直接的通信也可用其他形式的直接对等通信技术被实现。

在步骤315处，如果出租车司机接受作业请求，则接受消息例如经由应用服务器被发送到乘客通信设备（比照图1和2中的110）。将是清楚的是，这种技术也可由电话公司实现。

在步骤316处，客户端应用将乘客的位置状态切换到“关闭”。在步骤317处，乘客通过使用客户端应用的“应用内方式”或SMS接收接受/确认消息。优选地，乘客和出租车司机被从应用服务器（比照图1和2中的130）处的可用对等体/用户的列表中去除（或者状态被切换到”关闭”），使得他们对其他用户看起来“不可见”。在这种情况下，虽然乘客和出租车司机看起来是“不可见”的，但是他们仍然能够查看其状态是“打开”的其他用户。

在示例性实施例中，在步骤318处，乘客能够在通信设备（比照图1和2中的110）的图形显示上实时地跟踪约定的对等体（即所叫的出租车）的运动。就是说，乘客可以例如经由乘客通信设备（比照图1和2中的110）上的LBS应用的地图和路线选择模块而可见地跟踪约定的出租车的运动。

在步骤319处，当出租车到达接载位置时，乘客登上出租车。在步骤320处，乘客接收到服务费支付确认请求消息。出租车司机可发起到乘客的服务费支付请求确认消息。这可以是经由出租车司机从通信设备（比照图1和2中的150）向应用服务器（比照图1和2中的130）发送“已接载”消息而实现的。乘客接着从应用服务器（比照图1和2中的130）接收服务费支付请求确认消息。

在步骤321处，当乘客确认服务费支付确认请求消息时,约定/服务处理完成。在此之后,支付处理发生。

在示例性实施例中，由于经注册的乘客已经在向应用服务器注册期间输入过信用卡详细信息，在司机在“接载”期间发起支付处理后（比照步骤320），一经乘客例如通过按下移动应用中的按钮而确认（比照步骤321），乘客的信用卡详细信息就被发送到支付模块或支付方案主机用于处理。例如，支付方案主机连接到收单银行的信用卡主机以完成交易。司机和乘客二者都可被通知交易的状态。在示例性实施例中，乘客和出租车司机二者都能够从应用服务器查看交易记录。

作为信用卡支付的另选方案，乘客和/或司机被允许相对于信用卡挑选现金支付用于服务费支付。

对于在图3的右手侧上示出的出租车司机对等体的部分，例如出租车司机的对等体可在搜索例如在附近使用通信设备（比照图1和2中的150）并使用该通信设备的LBS应用的乘客的潜在约定对等体时扮演主动的角色。

作为用户，出租车司机在步骤350处注册对等体的角色。

在步骤351处，出租车司机可在搜索潜在的乘客时扮演主动的角色，并且无需等待潜在的乘客发送作业请求。一经在通信设备（比照图1和2中的150）上开始/运行客户端应用，出租车司机的位置状态被设置为“打开”。开始或运行客户端应用可例如通过激活通信设备（比照图1和2中的150）的图形显示上的用于客户端应用的“打开”/“运行”按钮/滑块而被激活。这可包括在通信设备的电容式触摸屏等上感测到的触摸信号。

开始/运行客户端应用包括向应用服务器（比照图1和2中的130）发送指示想要开始约定的激活信号。激活信号可包括激活对等体（出租车司机）的位置信息。在某些示例性实施例中，位置信息可在稍后的阶段被提供，例如在搜索阶段。位置信息可由通信设备（比照图1和2中的150）的LBS提供。在另选的示例性实施例中，位置信息可由对等体提供的信息补充或完全由其提供。例如，在另选的示例性实施例中，接载的位置信息（即期望的接载点或出租车车站）可由出租车司机提供或修改/补充。这可包括出租车司机使用web浏览器输入定位详细信息，或在触摸屏图形显示上将图标拖到期望的位置。

在某些示例性实施例中，开始/运行客户端应用可指示对等体可用于与另一个对等体的约定，例如向出租车指示乘客可由出租车接载，或向乘客指示有可用出租车用于约定。

在步骤352处，经注册的出租车司机可使用客户端应用来在通信设备（比照图1和2中的150）的图形显示上可视地搜索和显示在指定的雷达范围内的所有可用的约定对等体，诸如潜在的乘客。这些是在其通信设备（比照图1和2中的110以及在步骤311处所描述的）上指示了可用的对等体。客户端应用可以用通信设备的图形显示上的用于客户端应用的搜索按钮/滑块被激活用于搜索，以搜索可用约定对等体。这可包括在通信设备的电容式触摸屏等上感测到的触摸信号。雷达的范围或附近可根据用户的需求从列表被预先确定或挑选，例如10到100米、100到500米和500米到1公里等的半径。

激活搜索包括向应用服务器（比照图1和2中的130）发送请求信号以在指定的附近内发送可用对等体的信息。请求信号可包括预先确定或挑选的范围，作为范围信息。在应用服务器（比照图1和2中的130）处，搜索通过数据库被执行，以基于请求对等体（出租车司机）的位置信息和所接收的范围信息确定适合于约定的对等体（例如乘客）。应用服务器（比照图1和2中的130）接着发送适合于约定的对等体的结果到请求对等体通信设备（比照图1和2中的150）。结果可显示在通信设备上的图形显示中。

在步骤353处，出租车司机可检索和查看关于所定位的乘客的详细信息，包括诸如由先前的出租车司机提供的过去的约定成功率、评论等的信息。检索可基于出租车司机选择在图形显示上显示的每个对等体（乘客）。就是说，潜在乘客的图形表示被显示在出租车司机的通信设备上以用于选择。一经选择，详细信息可从应用服务器被发送。另选地，详细信息可在步骤352中与结果信息一起被发送。

在步骤354中，一经查看详细信息，出租车司机自由挑选优选的乘客并向所选择的乘客发送服务请求。就是说，服务请求信号经由应用服务器（比照图1和2中的130）被从请求对等体通信设备（比照图1和2中的150）发送到用于约定的对等体的通信设备（比照图1和2中的110）。作为另选方案，服务请求信号可绕开应用服务器（比照图1和2中的130）被从请求对等体通信设备（比照图1和2中的150）直接发送到用于约定的对等体的通信设备（比照图1和2中的110）。

在示例性实施例中，服务请求信号包括可以是当前位置或期望的接载位置的出租车位置信息。

在用于约定的对等体（例如所挑选的乘客）的通信设备（比照图1和2中的110）处，服务请求被指示在图形显示上用于接受或拒绝。

在示例性实施例中，乘客可选择拒绝或接受所接收到的服务请求。如果乘客拒绝服务请求，则出租车司机通过拒绝信号被通知，出租车司机可继续进行选择下一个选择。拒绝信号可经由应用服务器被发送。就是说，处理循环到步骤352处。

在步骤355处，如果乘客接受服务请求，则接受消息被发送到出租车司机通信设备（比照图1和2中的150）。接受信号可经由应用服务器被发送。

在步骤356处，客户端应用将出租车司机的位置状态切换到“关闭”。

在步骤357处，出租车司机通过SMS或客户端应用接收接受/确认消息。优选地，乘客和出租车司机被从应用服务器（比照图1和2中的130）处的可用对等体/用户的列表中去除（或者状态被切换到“关闭”）。在这种情况下，虽然乘客和出租车司机看起来是“不可见”的，但是他们仍然能够查看其状态是“打开”的其他用户。

在示例性实施例中，在步骤358处，出租车司机能够在通信设备（比照图1和2中的150）的图形显示上实时地跟踪约定的对等体（即约定的乘客）的位置，直到出租车司机到达接载乘客的位置，除非接收到来自乘客的取消请求。乘客也可被允许跟踪出租车司机的位置（比照步骤318）。

在步骤359处，当出租车到达接载位置时，乘客登上出租车。

在步骤360处，出租车司机可发起到乘客的服务费支付请求确认消息。这可以是经由出租车司机从通信设备（比照图1和2中的150）向应用服务器（比照图1和2中的130）发送“已接载”消息实现的。乘客接着从应用服务器（比照图1和2中的130）接收服务费支付请求确认消息。

在步骤361处，当乘客确认服务费支付确认请求消息时,约定/服务处理完成。在此之后,支付处理发生。

在示例性实施例中，由于经注册的乘客已经在向应用服务器注册期间输入过信用卡详细信息，在司机在“接载”期间发起支付处理后（比照步骤320），一经乘客例如通过按下移动应用中的按钮而确认（比照步骤321），乘客的信用卡详细信息就被发送到支付模块或支付方案主机用于处理。例如，支付方案主机连接到收单银行的信用卡主机以完成交易。司机和乘客二者都可被通知交易的状态。在示例性实施例中，乘客和出租车司机二者都能够从应用服务器查看交易记录。

作为信用卡支付的另选方案，乘客和/或司机被允许相对于信用卡挑选现金支付用于服务费支付。

图4是示例性实施例中的示意性对等交易流程图400。该关于交易流程的示例从例如使用通信设备（比照图1和2中的110）约定另一个对等体（例如叫出租汽车或出租车）的对等体的角度被示出。为了易于描述，某些步骤未被包括。

在数字401处，乘客请求显示例如在半径大约100米内的所有用于约定的可用的对等体（例如在附近的可用出租车）。该请求从乘客的通信设备110中的具有LBS应用的客户端应用被发送到应用服务器130。

在数字402处，应用服务器130从出租车司机的通信设备150的具有LBS应用的客户端应用请求位置信息，这些通信设备150向应用服务器130指示了其可用并在指定的附近以内。

在数字403处，可用出租车的位置信息接着被返回到应用服务器130。在数字404处，应用服务器130获得位置信息并发送该信息用于在乘客的通信设备110上显示。

在数字405处，乘客从乘客的通信设备110请求选择的出租车的服务并向所挑选的出租车司机发送作业请求。这可以是直接在乘客和出租车司机之间或是经由应用服务器的。

在数字406处，出租车司机对作业请求的接受被作为确认消息返回到乘客通信设备110，并且乘客的位置状态被“关闭”。在数字407处，一经接载了乘客，司机通过应用服务器130向乘客发起服务费请求消息。

在数字408处，乘客在通信设备110上接收服务费确认请求消息。在数字409处，一经登上出租车，乘客确认出租车已经到达，约定服务完成。

在数字410处，应用服务器130向支付方案服务器120发起支付请求，以例如经由乘客的信用卡向乘客收取服务费。在数字411处，服务费被支付给司机以完成交易处理。

图5描述了示例性实施例中的使用“叫出租汽车”的LBS移动应用图形用户界面（GUI）的示例场景。流程处理在数字510处被指示。LBS移动应用可基本类似于客户端应用180和/或如参考图3所描述的而起作用。为了易于描述，某些步骤未被包括。在示例性实施例中，用户被注册为乘客。

例如，乘客可通过通信设备（例如智能移动设备）中的移动应用来开始约定对等体的处理（例如叫出租汽车）。假设用户是已注册的乘客并且想要叫到期望的目的地的出租车。

在起始页511处，乘客开始被示例地称为“叫出租汽车”的LBS移动应用，并且乘客的状态被设置为“在线”或“打开”。就是说，该状态使得乘客对正搜索乘客的出租车司机“可见”。乘客被允许输入出行信息并搜索在附近的可用出租车。可用出租车可在由移动应用提供的地图上，以图形方式在其当前位置上，由符号、图形图标或任何其他合适的表示来表示。乘客能够查看由图形图标所表示的出租车的详细信息。图形图标可以具有诸如颜色、编号等的性质和属性，以表示在不同位置处出租车的不同类型、出租车的编号等。

在详细信息页512处，可以查看出租车的详细信息。这些详细信息可包括但不限于显示已注册的出租车司机的详细信息、可用出租车的类型、出租车公司的详细信息、已注册的车辆编号、起步出租车费、可用的支付类型、使用的语言和诸如由之前的乘客提供的评级和评论等的其他信息。

在预约页513处，在发送作业请求之前，乘客能够输入例如出行信息、支付类型和其他偏好。在向所挑选的出租车司机发送作业请求用于接受之前，确认屏幕514可被显示。随后，乘客将作业请求发送到出租车司机，一旦出租车司机接受了该作业请求，确认消息515被接收。确认消息显示指示预约由出租车司机确认的消息，并且可提供例如预计的到达时间（ETA）。

在跟踪屏幕516处，乘客可继续经由移动应用在地图的图形显示上可视地跟踪出租车的位置。

图6是示例性实施例中的约定处理的示意性逻辑流程图。流程图描述了示例的“叫出租汽车”和示例的“定位乘客”的逻辑处理流程。为了易于描述，某些步骤未被包括。

在步骤601处，用户下载客户端应用到诸如移动设备的通信设备，并在步骤602处注册，作为乘客（在步骤604处）或出租车司机（在步骤603处）。客户端应用可基本类似于客户端应用180和/或如参考图3所描述的而起作用。

在步骤604处，乘客输入简档信息、可包括用于支付服务费或出租车费的信用卡信息的优选支付方法、紧急联系人等。在步骤603处，出租车司机输入出租车司机的详细信息、例如用于接收服务费和出租车费的银行账户信息、和紧急情况下的紧急联系人等。优选地，在紧急情况期间，客户端应用可拨号到指定的紧急号码。

在步骤605处，用户接受可包括允许跟踪用户的位置的隐私设置的条款和条件。

在步骤605处用户接收了隐私设置之后，在步骤607处，可以开始客户端应用。在步骤608处，当该应用在通信设备上运行/开始时，位置状态变为“打开”。在步骤609处，处于“打开”或“在线”的位置状态允许乘客“叫出租汽车”或者允许出租车司机“定位乘客”。比照图3的步骤311和351。在步骤610处，乘客或出租车司机接着能够分别地发送作业或服务请求消息。比照图3的步骤314和354。

如果接收到对作业或服务请求消息的确认，则在步骤612处，位置状态可被设为“关闭”或“离线”。比照图3的步骤316和356。否则，用户循环到重新发送或重复步骤610。

在步骤613处，每个用户/对等体可查看和/或跟踪其他约定用户/对等体的位置。例如，乘客能够跟踪出租车的位置和/或运动，直到出租车到达来接载乘客。比照图3的步骤318和358。

在步骤614处，如果用户在对作业或服务请求消息的确认被接收到之后激活取消请求，则在步骤615处，通知消息被发送到另一约定用户。例如，如果乘客在确认被接收之后、出租车出现之前激活了取消请求，则通知消息被发送到出租车司机。在步骤615处，应用服务器也被通知该取消，并且每个用户取消的出行的数目可被记录用于例如评级的目的。

在步骤617，如果用户违约，即在没有发送取消请求的情况下未完成约定，则在步骤615处，应用服务器也被通知该违约，并且每个用户违约的数目可被记录用于例如评级的目的。例如，在出租车司机对接载乘客违约或乘客对出租车司机违约的情况下，该信息可由被违约的用户发送到应用服务器，并且该信息被记录用于相应地对违约的用户评级。例如，违约可通过被违约的用户激活/点击通信设备上的未出现按钮而被激活。在这种情况下，乘客或出租车司机可在步骤616处分别地重复从步骤607的“叫出租汽车”或“定位乘客”的处理。

在步骤618处，约定按照预期继续进行。例如，司机按照承诺到达以接载乘客。比照图3的步骤319和359。在步骤619处，出租车司机接着可发起供乘客确认的服务费支付请求消息。比照图3的步骤320和360。在步骤620处，乘客继续进行以确认该服务费支付请求消息。比照图3的步骤321和361。在步骤621处，两个用户均被支付方案服务器（比照图1中的120）通知交易成功。支付方案服务器被理解为是促进支付门户（诸如网站、移动电话或交互式语音应答IVR服务）与前端处理器或收单银行之间的信息传递的支付网关。因此，当乘客从支付网关使能的商户（在这里的情况中即出租车司机）预订服务时，支付网关执行多种任务来处理乘客和司机之间的交易。

图7是示例性实施例中的应用服务器的示意性模块架构图。应用服务器700可基本与图1和2中的应用服务器130相同地起作用。

在示例性实施例中，应用服务器700包括与用户/对等体客户端应用（例如乘客或出租车司机移动应用）进行通信的多个模块。比照图1和2中的180。每个模块的功能描述如下。

提供移动-服务器集成模块31，其可处理乘客的移动应用180和耦接到移动-服务器集成模块31的应用逻辑模块32之间的客户端-服务器通信。移动-服务器集成模块31处理由应用逻辑模块32在到移动应用的发送期间以安全的方式提供的一个或多个功能。

应用逻辑模块32包含例如用于移动应用的图形用户界面的业务逻辑，诸如但不限于用于叫出租汽车/出租车、搜索或显示指定范围/附近内的可用出租车、查看关于出租车的实时运行信息、和当登上出租车时更新用户的位置等的逻辑。

数据库模块33被提供为耦接到应用逻辑模块32。数据库模块33是用于存储特定于应用的信息，诸如但不限于用户出行的数目和预计的到达/出发时间等。

提供通知服务模块34用于当预约被确认时或当出租车正接近其目的地时等等，向乘客发送通知。通知可定期地（例如每分钟一次）或经由来自位置服务的关于被跟踪的用户（乘客或出租车）的更新通知而被触发。

SMS服务模块35被提供为耦接到通知服务模块34，并且当预约被确认时或当经由支付方案服务器120做出支付时，能够例如向乘客发送SMS通知。

提供实时运行处理器模块36用于请求例如关于出租车的位置和预计的到达/出发时间（如果可用的话）的实时更新，以及用于相应地更新相关的数据点。更新可定期地（例如一分钟一次）被触发以运行。更新可从用户移动应用（例如从出租车司机）被推送或发送到实时运行的处理器模块36。

提供用户管理模块37用于允许用户（例如乘客、出租车司机）例如注册用户信息、查看交易记录、更新详细信息和设置等。在示例性实施例中，乘客的简档和出租车的出租车详细信息被记录在应用服务器700中。可以使用户管理模块37可由用户经由因特网（例如使用因特网浏览器）而访问。用户管理模块37可提供对用户的简档、设置、性质和属性设置等进行管理的后端管理页。

提供交易管理模块38用于保持交易记录，诸如出行编号、支付金额、出行详细信息、支付方法等。可以使交易管理模块38可由用户经由因特网（例如使用因特网浏览器）而访问。用户可以检索、查看和打印过去的交易历史、出行历史、账户的收据和声明等。

提供支付模块39用于允许用户（例如乘客）挑选不同的支付方法。支付模块39可被集成到各种可用的支付平台，诸如移动支付、信用卡或借记卡支付网关。

位置服务和位置更新服务模块40被提供为耦接到模块32、34、36、37、38和39。位置服务和位置更新服务模块40能够访问和存储关于用户（诸如乘客和出租车）的位置跟踪信息。在示例性实施例中，位置服务和位置更新服务模块40使用OpenLS跟踪规范实现，以使得应用服务器700中的其他模块能够容易地利用位置更新和通知功能。在另选的示例性实施例中，商业产品可被用于提供这些模块的功能。这些模块也可在不同的LBS之间重用。

此外，位置服务和位置更新服务模块40可更新例如出租车的位置，可计算例如预计在搭乘/中转点到达/出发的时间，并且可确定例如出租车位置和预计的到达时间等。一旦用户已完成出行，则位置服务和位置更新服务模块40还可以清除特定的用户信息，诸如移动电话标识符。在示例性实施例中，为了处理数据密集型的处理，诸如JBossDrools或IBMiLog的生产规则引擎可被用于模块的实现。位置服务和位置更新服务模块40可定期地（如每分钟一次）被触发或例如经由来自位置服务的关于车辆运动的更新通知而被触发。

图8是示例性实施例中的客户端应用的示意性模块架构图。客户端应用800可基本与在图1和2中和/或参照图3-7种的任何一个所描述的应用180相同地起作用。在该示例性实施例中，客户端应用是供用户（例如乘客和出租车司机）使用的移动LBS应用。

在该示例性实施例中，乘客或出租车司机的移动应用800是在用户的诸如智能电话的通信设备上运行的移动LBS应用。移动应用包括图形用户界面和多个模块，诸如用于搜索可用出租车或乘客的模块、用于输入出行信息的模块、用于管理位置和运动信息的模块、客户端-服务器通信模块、和推送通知处理程序模块等。

应用模块81被设置并包括用户界面。应用模块81可促进应用服务器130和一个或多个模块之间的通信，这些模块诸如消息传送模块82、地图和路线选择模块83、位置模块84、隐私模块85、内容模块86和计费模块87等。

应用模块81还可通信/操作各种功能，诸如由例如移动运营商或电话公司90通过一个或多个网关连接器88的服务而提供的SMS、MMS、LBS和支付模块89。

消息传送模块82被设置用于即时消息传送服务，位置模块84是用于提供位置信息的LBS-客户端组件。位置信息请求经由在参与的移动设备上的客户端之间特殊编码的即时消息被信号化。例如在通信设备处的GPS定位设备可被用于向请求对等体发送原始位置坐标（例如经度-纬度-高度）。通过使用位置信息，地图或街道地址可从例如被定位对等体的外部地图服务器（例如从谷歌地图）经由例如GPRS连接技术被获得。LBS客户端和应用服务提供者之间的接口可使用基于标准化的HTTP或SIP的通信协议。

在示例性实施例中，两个移动对等体（例如乘客和出租车司机）之间的定位请求按照如下被执行。向基于位置的服务注册的移动对等体（例如乘客）可从消息传送菜单请求另一个已注册的同类对等体（例如出租车司机）的位置。

根据对等体（例如出租车司机的）的隐私设置（例如由隐私模块85来处理的），消息弹出可被显示在出租车司机的通信设备显示器上，其示出乘客的请求。如果出租车司机的隐私设置被设置为“允许接受”请求对等体/用户，则消息弹出可以跳过。如果乘客的请求被出租车司机准许，则出租车司机的GPS坐标可被转换为特殊的消息格式并被发送到乘客通信设备。一旦乘客接收到所需的位置坐标，示出了出租车司机的位置的地图（例如由地图和路线选择模块83处理的）可从在线地图服务器被接收。

另选地，在乘客的通信设备处，可以使用来自GPS设备或安装在乘客的通信设备中的应用的位置信息计算到远程对等体（例如出租车司机）的距离。因此，可能定位附近的出租车，并且如果已注册的出租车司机进入到乘客通信设备的范围中，则优选地触发即时消息。上述可通过执行到已注册的对等体的周期位置请求被实现。

在示例性实施例中，如果对等体（例如乘客和出租车司机）是“在线”的，则对等体之间的位置请求可被执行。因此，优选地，在发送任何位置请求之前，对对等体的存在状态（在线/离线）的轮询可被执行。

在示例性实施例中，计费模块87被设置用于处理支付服务，诸如服务费用或出租车费。诸如内容模块86、连接器88、模块89和90的其他模块可以是并非一般地应用于示例性实施例中的通用模块。

图9是用于描述示例性实施例中的用于定位一个或多个对等体的方法的示意性流程图900。在步骤902处，请求对等体的位置信息被确定。在步骤904处，用于约定的至少一个可用对等体的位置信息基于请求对等体的位置信息被确定。在步骤906处，该至少一个可用对等体的位置信息被发送到请求对等体。

其他示例性实施例

在另选的实施例1中，提供了用于出租车交通部门中的对等（乘客到出租车司机或出租车司机到乘客）定位系统的系统，包括：应用服务器，其与乘客移动LBS应用和出租车司机移动LBS应用进行通信，集成到支付方案服务器，并提供经由因特网的用于管理目的的用户访问，诸如注册、编辑用户简档和设置、查看和检索有关出行编号的交易记录、账户的收据和声明；乘客移动LBS应用，其运行在乘客移动设备中，与应用服务器进行通信，并使得乘客能够“叫出租车”；出租车LBS应用，其运行在租车司机移动设备中，与应用服务器进行通信，使得出租车司机能够“定位乘客”；支付方案服务器，其集成到具有各种支付服务平台的应用服务器。

在另选的实施例2中，提供了如在实施例1中所提及的系统，其中，应用服务器包括：移动-服务器集成模块，其负责处理乘客移动应用和应用逻辑模块之间的客户端-服务器通信，其处理由应用逻辑模块以安全的方式提供给移动应用的功能；应用逻辑模块，其包含用于应用的用户界面、搜索或显示特定范围内的可用出租车、查看有关出租车的实时运行信息、和当用户登上出租车时更新用户的位置的业务逻辑；数据库模块，其负责存储诸如用户旅行和预计的到达/出发时间的特定于应用的信息和数据；通知服务模块，其负责当预约被确认时或当出租车正接近其目的地时，向乘客发送通知，通知定期地或经由来自位置服务的有关被跟踪的乘客或出租车的更新通知而被触发；实时运行处理器模块，其负责请求有关出租车的位置和预计的到达/出发时间（如果可用的话）的实时更新，以及相应地更新相关的数据点，这定期地被触发，更新从出租车移动应用被推送至其；以及SMS服务模块，其负责当预约被确认时或当支付经由支付方案服务器被做出时，向乘客发送通知。

在另选的实施例3中，提供了如在实施例2中所提及的系统，其中，应用服务器还包括：用户管理模块，其可由用户经由因特网访问，允许用户注册、查看交易记录、更新详细信息和设置等，其管理用户简档、设置、性质和属性设置；交易管理模块，其管理诸如出行编号、金额、出行详细信息、支付方法等的交易记录，并可由用户经由因特网访问，用户可检索、查看和打印过去的交易历史、出行历史、账户的收据和声明；和支付管理模块，其负责供乘客挑选支付方法，该模块集成到各种可用的支付平台，诸如移动支付、信用卡或借记卡支付网关。

在另选的实施例4中，提供了如在实施例1中所提及的系统，其中，支付解决服务器包括：使用在线信用卡或借记卡工具的出租车费或管理费用支付，其通过LBS应用并经由通过银行的计费和移动SMS被认证；使用通过电话公司的移动支付和计费的出租车费或管理费用支付；以及使用在线信用卡、借记卡工具或通过第三方支付服务提供者的移动支付和计费的出租车费或管理费用支付。

在另选的实施例5中，提供了如在实施例1中所提及的系统，其中，移动LBS应用包括：由用户界面构成的应用模块，其在应用服务器和各种模块之间进行通信，这些模块诸如消息传送模块、地图和路线选择模块、位置模块、隐私模块、内容模块和计费模块。

在另选的实施例6中，提供了如在实施例4中所提及的系统，其中，移动LBS应用还包括：应用模块还与各种功能特征部通信，诸如由移动运营商通过网关连接器服务提供的SMS、MMS、LBS和支付。

在另选的实施例7中，提供了如在实施例4中所提及的系统，其中，移动LBS应用还包括：出于提供即时消息传送服务目的的消息传送模块；出于提供位置信息目的的位置模块；用于示出用户位置和从在线地图服务器接收地图信息的地图和路线选择模块；负责处理用户的隐私设置的隐私模块；负责处理和显示应用内容的内容模块；和负责处理用户所挑选的支付方法的计费模块。

在另选的实施例8中，提供了用于乘客到出租车司机的定位系统的方法，包括：乘客移动设备中的移动LBS应用，其经由应用服务器与出租车司机移动设备中的LBS应用进行通信；定位并搜索乘客附近内的出租车并在移动设备中查看出租车的图形表示；在移动设备中查看出租车的详细信息；将隐私设置设置为“在线”并输入出行信息；发送作业请求到出租车司机；在出租车司机接受作业请求之后经由消息传送或SMS接收预约确认；经由消息传送、SMS或移动电话联系出租车司机；在移动设备上实时地跟踪已预约的出租车的位置；以及通过移动设备支付出租车费和/或管理费用。

在另选的实施例9中，提供了用于出租车司机到乘客的定位系统的方法，包括：司机移动设备中的移动LBS应用，其经由应用服务器与乘客移动设备中的LBS应用进行通信。定位并搜索出租车附近内的乘客并在移动设备中查看乘客的图形表示；在移动设备中查看乘客的简档；将隐私设置设置为“在线”并输入出租车车辆详细信息、出租车费用、车辆注册编号、联系人详细信息；发送服务请求到乘客；在出租车司机接受作业请求之后经由消息传送或SMS接收预约确认；经由消息传送、SMS或移动电话联系乘客；在移动设备上实时地查看乘客的位置；以及通过移动设备接收出租车费和/或管理费用的支付确认。

在另选的实施例10中，提供了如在实施例8中所提及的用于乘客到出租车司机的定位系统的方法，还包括：经由因特网访问应用服务器用于用户注册，管理用户简档，访问有关出行的信息，检索并检查过去的旅行记录、支付记录和收据。

在另选的实施例11中，提供了如在实施例9中所提及的用于出租车司机到乘客的定位系统的方法，还包括：经由因特网访问应用服务器用于用户注册，管理用户简档，访问有关出行的信息，检索并检查过去的旅行记录、有关出租车费的支付记录和收据。

在另选的实施例12中，提供了用于出租车司机和乘客的定位系统的方法，包括以下步骤：为乘客或出租车司机的用户下载LBS客户端应用到用户的移动设备；用户注册为乘客或出租车司机，输入诸如简档、偏好、支付方法、银行账户、紧急联系人号码和出租车车辆详细信息的信息到系统中；用户将同意使用软件的条款和条件，包括接受允许其位置被跟踪和监视的隐私设置；当应用运行时，用户的位置状态为“打开”。用户能够经由移动设备搜索和显示附近的其他用户。例如，乘客能够搜索和显示出租车的位置，同时出租车司机能够搜索和显示乘客的位置；用户能够发送作业或服务请求到其他用户；其他用户自由地选择接受确认或拒绝该请求；在任何取消的情况下，双方用户和应用服务器将被通知，用户将再次重复该处理；一经由其他用户确认，用户的位置状态为“关闭”，并且用户能够跟踪接受了其作业请求的其他用户的位置。如果用户是乘客，出租车一经到达，他将登上该出租车（另一用户）；出租车司机将发送服务费支付请求以供乘客确认；一经接收到确认，支付方案服务器将向双方用户发送有关成功交易的通知。

在另一个示例性实施例中，请求对等体（例如乘客）可在例如连接到因特网的浏览器中输入位置信息，并经由该界面指示该请求对等体可用于约定。用于约定的至少一个可用对等体（例如一个或多个出租车司机）的位置信息可根据该请求对等体的位置信息被获得并过滤。所获得的用于约定的该至少一个可用对等体的位置信息接着被发送到请求对等体，并例如可被在浏览器上显示为符号以供该请求对等体挑选。挑选和约定的步骤之后基本与参照图3所描述的步骤相同。

不同的示例性实施例可被实现在在通信设备中执行的数据结构、程序模块、程序和计算机指令的上下文中。这里简要地公开示例通信设备。一个或多个示例性实施例可被具体实现为一个或多个通信设备，例如，1000，诸如在图10中所示意性描述的。

一个或多个示例性实施例可被具体实现为软件，诸如在通信设备1000内执行、并指示通信设备1000进行示例性实施例的方法的计算机程序。

通信设备1000包括处理器模块1002、诸如触摸屏界面或小键盘1004的输入模块、诸如触摸屏上的显示器1006的输出模块。

处理器模块1002被耦接到第一通信单元1008用于与蜂窝网络1010进行通信。第一通信单元1008可包括但不限于用户识别模块（SIM）卡加载湾。例如，蜂窝网络1010可以为3G或4G网络。

处理器模块1002还被耦接到第二通信单元1012用于与网络1014进行连接。例如，第二通信单元1012可以使得能够对例如互联网或诸如局域网（LAN）、广域网（WAN）或个人网络的其他网络系统进行访问。网络1014可包括服务器、路由器、网络个人计算机、对等体设备或其他常见的网络节点、无线电话机或无线个人数字助理。网络环境可以在办公室、全企业的计算机网络和家庭计算机系统等中找到。第二通信单元1012可包括但不限于无线网卡或以太网网络电缆端口。第二通信单元1012也可以是调制解调器/路由器单位，并且可以是任何类型的调制解调器或路由器，诸如电缆类型的调制解调器或卫星类型的调制解调器。

将会清楚的是，所示的网络连接是示例的，可以使用其他方法建立计算机之间的通信链路。假定了存在各种协议中的任何协议，诸如TCP/IP、帧中继、以太网、FTP、HTTP等，通信设备1000可操作在客户端-服务器配置中，以允许用户从从基于web的服务器中检索web页面。此外，可以使用各种web浏览器中的任何浏览器来在web页面上显示和操作数据。

在示例中的处理器模块1002包括处理器1016、随机存取存储器（RAM）1018和只读存储器（ROM）1020。ROM1020可以是存储基本输入/输出系统（BIOS）信息的系统存储器。RAM1018可以存储一个或多个程序模块，诸如操作系统、应用程序和程序数据。

处理器模块1002还包括若干输入/输出（I/O）接口，例如到显示器1006的I/O接口1022和到小键盘1004的I/O接口1024。

处理器模块1002的组件通常经由互连的总线1026并且以相关领域的技术人员所已知的方式进行通信和连接地耦接/接口。总线1026可以是几种类型的总线结构中的任何一种，这些总线结构类型包括使用各种总线架构的任何一种的存储器总线或存储器控制器、外围总线、和本地总线。

将会清楚的是，其他设备也可连接到系统总线1026。例如，通用串行总线（USB）接口可被用于将通信设备的附件（诸如读取器）耦接到系统总线1026。

应用程序通常提供给通信设备1000的用户，其编码在诸如闪存存储器模块或存储器卡/棒的数据存储介质上，并利用数据存储设备的对应存储器读写器1028被读取。数据存储介质并不限于便携式的并可以包括被嵌入在通信设备1000中的实例。

应用程序在其由处理器1016的执行中被读取并控制。程序数据的中间存储可使用RAM1018来完成。示例性实施例的方法可被实现为计算机可读指令、计算机可执行组件或软件模块。一个或多个软件模块可另选地被使用。这些可以包括可执行程序、数据链接库、简档、数据库、图形图像、二进制数据文件、文本数据文件、对象文件或源代码文件等。当一个或多个处理器模块执行软件模块中的一个或多个时，软件模块交互以导致一个或多个处理器模块根据这里的教导执行。

通信设备1000的操作可由多种多样的不同程序模块控制。程序模块的例子有执行特定的任务或实现特定的抽象数据类型的例程、程序、对象、组件、数据结构和库等。

示例性实施例也可以以其他的计算机系统配置被实践，包括手持式设备、多处理器的系统/服务器、基于微处理器或可编程的消费电子产品、网络PC、微型计算机、大型计算机、个人数字助理和移动电话等。此外，示例性实施例也可以以分布式计算环境被实践，其中任务由通过无线或有线通信网络链接的远程处理设备执行。在分布式计算环境中，程序模块可位于本地和远程的存储器存储设备中。

上面已经讨论的各种示例性实施例的优点和功能可被独立地实现，或者可组合在其他的示例性实施例中。

在示例性实施例中，通信设备并不限于移动电话或智能电话，并且可采取例如桌面个人计算机（PC）、笔记本电脑、平板PC和移动音乐播放器等的形式。

在示例性实施例中，基于位置的服务可以包括用于确定地理位置信息的机制，并且可以是但不限于全球定位服务（GPS）、GSM（全球移动通信系统）三角位置服务或WI-FI位置服务等。该服务甚至可包括约定位置信息的用户输入，诸如使用连接到网络（诸如因特网）的web浏览器输入地址信息。

在示例性实施例中，基于位置的服务可与客户端应用集成，或者可耦接到客户端应用或与其分开（诸如安装在智能电话上的原生（native）GPS）。

在示例性实施例中，与电话公司的无线通信可以是经由WI-FI、3G或4G网络等。电话公司与应用服务器之间和/或应用服务器与支付服务器之间的电话公司，可以是有线网络或WI-FI、3G、4G或光纤网络等。

在示例性实施例中，位置信息的呈现并不限于GUI上的可视显示，并且可包括但不限于音频提示、列表格式中的展示等。

在一些示例性实施例中，确定位置信息可被解释为动态确定的步骤，以将这种示例性实施例的方法和系统与示出诸如建筑、地标等的固定实体的常规位置地图相区分。

在一些示例性实施例中，对于乘客，如果没有可用出租车可供租用，呼叫中心号码的列表可接着被提供给乘客用于挑选尝试预约的呼叫中心。

在一些示例性实施例中，一旦乘客和出租车司机已确认对约定的请求，可做出供乘客和出租车司机通过语音呼叫直接通信的选项。就是说，呼叫按钮可被设置在触摸屏的图形显示上。

在一些示例性实施例中，如果用户（乘客或出租车司机）要退出用于约定的应用（app），则可设置的是用户的状态接着被改变为“关闭”或离线。

在所描述的示例性实施例中，由于应用服务器并不主要用于搜索和处理提供约定的用户和请求约定的用户的配对，应用服务器的处理负载相比于当前的呼叫中心类型的服务器被显著减小。此外，在一些示例性实施例中，可以设置的是客户端应用与应用服务器定期（例如每30秒或1分钟）进行通信以更新提供约定的用户和请求约定的用户，使得相比于永远在线的通信格式进一步减少处理负载。

本领域的技术人员将会清楚的是，可对特定的实施例做出各种变型和/或修改，而不偏离本发明的所广泛地描述的范围。因此，这些实施例在所有方面被视为是描述性的而不是限制性的。

Claims (52)

1.一种用于定位一个或多个对等体的方法，该方法包括：

确定请求对等体的位置信息；

基于该请求对等体的位置信息确定用于约定的至少一个可用对等体的位置信息；以及

将该至少一个可用对等体的位置信息发送到该请求对等体。

2.根据权利要求1的方法，进一步包括向该请求对等体呈现该至少一个可用对等体的位置信息。

3.根据权利要求1或2的方法，进一步包括在图形显示中显示该请求对等体的所述位置信息、用于约定的所述至少一个可用对等体的所述位置信息、或者上述两者。

4.根据权利要求1至3中的任何一项的方法，进一步包括允许该请求对等体对所选可用对等体的挑选。

5.根据权利要求1至4中的任何一项的方法，其中，该至少一个可用对等体是已针对该请求对等体的定位主动指示可用状态的对等体。

6.根据权利要求1至5中的任何一项的方法，其中，所述确定请求对等体的位置信息包括由用户输入约定位置信息。

7.根据权利要求6的方法，其中，由用户输入约定位置信息包括使用连接到网络的web浏览器输入地址信息。

8.根据权利要求1至7中的任何一项的方法，其中，所述确定请求对等体的位置信息进一步包括在该请求对等体处使用基于位置的服务。

9.根据权利要求1至8中的任何一项的方法，其中，所述确定用于约定的所述至少一个可用对等体的位置信息进一步包括在该至少一个可用对等体处使用基于位置的服务。

10.根据权利要求1至9中的任何一项的方法，其中，所述基于该请求对等体的位置信息确定用于约定的所述至少一个可用对等体的位置信息包括使用从请求对等体发送的范围信息。

11.根据权利要求1至10中的任何一项的方法，其中，所述将该至少一个可用对等体的位置信息发送到该请求对等体包括发送该至少一个可用对等体的简档和/或历史明细。

12.根据权利要求1至11中的任何一项的方法，进一步包括允许该请求对等体与所述至少一个可用对等体之间的约定。

13.根据权利要求12的方法，进一步包括经由所述至少一个可用对等体生成用于发送到该请求对等体的服务支付消息而确认约定。

14.根据权利要求12的方法，进一步包括经由该请求对等体生成用于发送到所述至少一个可用对等体的服务支付消息而确认约定。

15.根据权利要求1至14中的任何一项的方法，其中，请求对等体是请求交通服务的实体，该至少一个可用对等体是提供交通服务的实体。

16.根据权利要求1至14中的任何一项的方法，其中，请求对等体是提供交通服务的实体，该至少一个可用对等体是请求交通服务的实体。

17.根据权利要求1至16中的任何一项的方法，其中，确定至少一个可用对等体的位置信息的步骤包括动态地确定该位置信息。

18.一种供请求对等体用于定位一个或多个对等体的通信设备，该设备包括：

用于确定请求对等体的位置信息的模块；

用于接收用于约定的至少一个可用对等体的位置信息的接收模块，至少一个可用对等体的所述位置信息基于该请求对等体的位置信息而确定。

19.根据权利要求18的设备，进一步包括用于显示该请求对等体的所述位置信息、用于约定的所述至少一个可用对等体的所述位置信息、或者上述两者的图形显示。

20.根据权利要求18或19的设备，进一步包括用于该请求对等体对所选可用对等体的挑选的输入模块。

21.根据权利要求18至20中的任何一项的设备，进一步包括用于针对对等体的定位主动开启可用状态的输入界面。

22.根据权利要求18至21中的任何一项的设备，其中，用于确定请求对等体的位置信息的模块包括约定位置信息的用户输入字段。

23.根据权利要求22的设备，其中，由用户输入约定位置信息包括使用连接到网络的web浏览器输入地址信息。

24.根据权利要求18至23中的任何一项的设备，进一步包括基于位置的服务模块。

25.根据权利要求24的设备，其中，该基于位置的服务模块与用于确定请求对等体的位置信息的模块集成在一起。

26.根据权利要求18至25中的任何一项的设备，其中，至少一个可用对等体的所述位置信息在该至少一个可用对等体处使用基于位置的服务而确定。

27.根据权利要求18至26中的任何一项的设备，其中，至少一个可用对等体的所述位置信息基于从该请求对等体发送的范围信息而进一步确定。

28.根据权利要求18至27中的任何一项的设备，其中，所述接收模块能够接收该至少一个可用对等体的简档和/或历史明细。

29.根据权利要求18至28中的任何一项的设备，进一步包括用于确认该请求对等体和该至少一个可用对等体的约定的消息传送模块，其中，该至少一个可用对等体生成用于经由该消息传送模块发送到该请求对等体的服务支付消息。

30.根据权利要求18至28中的任何一项的设备，进一步包括用于确认该请求对等体和该至少一个可用对等体的约定的消息传送模块，其中，该请求对等体生成用于经由该消息传送模块发送到该至少一个可用对等体的服务支付消息。

31.根据权利要求18至30中的任何一项的设备，其中，请求对等体是请求交通服务的实体，该至少一个可用对等体是提供交通服务的实体。

32.根据权利要求18至30中的任何一项的设备，其中，请求对等体是提供交通服务的实体，该至少一个可用对等体是请求交通服务的实体。

33.根据权利要求18至32中的任何一项的设备，其中，至少一个可用对等体的所述位置信息动态地被确定。

34.一种用于对等约定的系统，该系统包括：

请求对等体通信设备；

一个或多个可用约定对等体通信设备；

应用服务器；

其中，该请求对等体通信设备包括：

用于确定请求对等体的位置信息的模块；

用于从应用服务器接收用于约定的至少一个可用对等体的位置信息的接收模块；以及

其中，对于该一个或多个可用约定对等体通信设备，每个可用约定对等体通信设备包括：

用于确定可用约定对等体的位置信息的模块；

用于向应用服务器发送该可用约定对等体的位置信息的发送模块；

另外其中，应用服务器被配置为接收该请求对等体的位置信息并基于该请求对等体的位置信息确定至少一个可用对等体的所述位置信息。

35.根据权利要求34的系统，其中，每个可用约定对等体通信设备进一步包括用于针对请求对等体的定位主动开启可用状态的输入界面。

36.根据权利要求34或35的系统，其中，请求对等体通信设备进一步包括用于针对对等体的定位主动开启可用状态的输入界面。

37.根据权利要求34至36中的任何一项的系统，其中，用于确定请求对等体的位置信息的模块包括约定位置信息的用户输入字段。

38.根据权利要求37的系统，其中，由用户输入约定位置信息包括使用连接到耦接于应用服务器的网络的web浏览器输入地址信息。

39.根据权利要求34至38中的任何一项的系统，其中，至少一个可用对等体的所述位置信息在该至少一个可用对等体处使用基于位置的服务而确定。

40.根据权利要求34至39中的任何一项的系统，其中，至少一个可用对等体的所述位置信息基于从该请求对等体发送到应用服务器的范围信息而进一步确定。

41.根据权利要求34至40中的任何一项的系统，其中，应用服务器被配置为向该接收模块发送该至少一个可用对等体的简档和/或历史明细。

42.根据权利要求34至41中的任何一项的系统，其中，应用服务器被配置以向该请求对等体发送服务支付消息用于确认该请求对等体和该至少一个可用对等体的约定。

43.根据权利要求34至42中的任何一项的系统，其中，应用服务器被配置以向该至少一个可用对等体发送服务支付消息用于确认该请求对等体和该至少一个可用对等体的约定。

44.根据权利要求34至43中的任何一项的系统，进一步包括被配置为处理来自该请求对等体或该至少一个可用对等体的支付的支付服务器。

45.根据权利要求34至44中的任何一项的系统，其中，请求对等体是请求交通服务的实体，该至少一个可用对等体是提供交通服务的实体。

46.根据权利要求34至45中的任何一项的系统，其中，请求对等体是提供交通服务的实体，该至少一个可用对等体是请求交通服务的实体。

47.根据权利要求34至46中的任何一项的系统，其中，应用服务器被进一步配置为动态地确定至少一个可用对等体的所述位置信息。

48.一种其上存储有计算机代码部件的计算机可读数据存储介质，该计算机代码部件用于指示通信设备的处理模块来执行用于定位一个或多个对等体的方法，该方法包括：

确定请求对等体的位置信息；

接收用于约定的至少一个可用对等体的位置信息，至少一个可用对等体的所述位置信息基于该请求对等体的位置信息而确定。

49.根据权利要求48的计算机可读数据存储介质，其中，该方法进一步包括在通信设备的图形显示中显示该请求对等体的所述位置信息、用于约定的所述至少一个可用对等体的所述位置信息、或者上述两者。

50.根据权利要求48或49的计算机可读数据存储介质，其中，该方法进一步包括允许该请求对等体对所选可用对等体的挑选。

51.根据权利要求48至50中的任何一项的计算机可读数据存储介质，其中，该至少一个可用对等体是已针对该请求对等体的定位主动指示可用状态的对等体。

52.根据权利要求48至51中的任何一项的计算机可读数据存储介质，其中，至少一个可用对等体的所述位置信息动态地被确定。