CN111566708A - 用于服务平台的组队系统和方法 - Google Patents

Abstract

本说明书实施例提供了一种用于组队的系统和方法。所述方法包括获得与至少两个待组队成员中的每一个相关的信息，所述至少两个成员包括至少一个队长和至少一个队员。所述方法还包括通过基于与所述至少两个成员相关的信息，自动地将至少两个队员分配给至少两个队长来确定一个或以上的组队，其中一个或以上组队中的每一个组队包括一个队长和至少一个队员。

Description

用于服务平台的组队系统和方法

优先权声明

本申请要求于2018年2月11日提交的申请号为201810141843.1的中国申请，于2018年5月23日提交的申请号为201810499757.8的中国申请，以及于2018年6月11日提交的申请号为201810596480.0的中国申请的优先权，其全部内容通过引用方式包含合于此。

技术领域

本申请一般涉及线上到线下服务平台，尤其涉及用于线上到线下服务平台队员的组队系统和方法。

背景技术

随着互联网经济的不断发展，越来越多基于互联网的服务出现，例如在线打车服务、食品配送、快递、代驾等。以在线打车服务为例。在线打车也被称为在线出租车预订。乘客可以随时随地通过乘客终端呼叫出租车。司机可以接受附近的出租车订单，在司机接受订单后，他或她将在约定的地点接载乘客。乘客不需要被动地等待经过的出租车，而是可以主动通过在线打车服务提交订单，以便接受了订单的司机可以来接载乘客，从而便于乘客的出行。

目前，为了获得更多用户，在线打车平台需要增加在线打车平台的容量，已经完成一定数量(或数量)订单的司机将获得奖励，以增加司机通过在线打车平台接受订单的积极性。但是，在司机达到订单的设定数量(或数量)后，当司机单独工作时，大多数司机都会对他们可以获得的奖励感到满意。现有激励措施的效果是不够的，在线打车平台的容量会减少。

由于司机单独作业，而每一司机有自己的行为习惯，例如雨雪天气、偏远地区、或者某些时间段(如早晚高峰)等等接单的意愿较低，因此影响打车软件平台的运营，也导致交通资源不均，影响乘客的出行便利性。而通过对司机进行组队则可一定程度上通过司机间的相互鼓励、与其他司机团队形成竞争关系等方式激励司机完成更多的订单。但现有技术通常采用线下的组队方式，无法实现很便捷的进行司机团队的组队。

发明内容

根据本申请的一个方面，提供了一个系统。所述系统包括用于确定一个组队的一组指令的存储介质、至少一个与所述至少一种存储介质通信的处理器。其中，当执行所述一组指令时，指导所述至少一个处理器执行以下的操作：获得与至少两个待组队成员中的每一个有关的信息，所述至少两个成员包括至少一个队长和至少一个队员；基于与所述至少两个队员有关的所述信息，自动将所述至少两个队员分配给所述至少两个队长，确定一个或以上的组队，其中所述一个或以上组队中的每一个组队包括一个队长和至少一个队员。

在一些实施例中，确定所述一个或以上的组队，所述至少一个处理器执行附加操作，还包括：基于所述至少两个队员的所述信息，确定所述至少两个队长和所述至少两个队员中的每一个之间的接收概率；基于所述接收概率使用优化推荐算法，确定组队推荐方案；以及基于所述组队推荐方案，确定所述一个或以上的组队。

在一些实施例中,所述确定所述至少两个队长和所述至少两个队员中的每一个之间的所述接收概率，指导所述至少一个处理器执行附加操作，包括：基于所述至少两个队员的信息，使用接收概率模型确定所述至少两个队长和所述至少两个队员中的每一个之间的所述接收概率。

在一些实施例中,所述接收概率模型是基于与所述至少两个队长和所述至少两个队员有关的历史组队数据确定的。

在一些实施例中,所述接收概率模型是使用逻辑回归算法确定的。

在一些实施例中,基于所述接收概率，使用所述优化推荐算法确定所述组队推荐方案，所述至少一个处理器还用于执行附加操作，包括：确定一个或以上候选组队推荐方案中每个组队的预期成功概率；指定与所述一个或以上候选组队推荐方案中的所述最大预期成功概率相对应的所述候选组队推荐方案作为所述组队推荐方案。

在一些实施例中,基于所述接收概率，使用所述优化推荐算法确定所述组队推荐方案，所述至少一个处理器还用于执行附加操作，包括：确定组队的预期成功概率模型；基于所述预期成功概率模型，使用所述优化推荐算法确定所述组队推荐方案。

在一些实施例中,确定所述一个或以上的组队，所述至少一个处理器执行附加操作，包括：基于所述至少两个队长及所述至少两个队员的信息，确定所述至少两个队长和所述至少两个队员的每一个之间的匹配值；基于所述匹配值，确定所述一个或以上的组队。

在一些实施例,确定所述至少两个队长和所述至少两个队员的每一个之间的所述匹配值，指导所述至少一个处理器执行附加操作，包括：确定所述至少两个队长中的每一个的所述信息与所述至少两个队员中的每一个的所述信息之间的相似度；基于所述至少两个队长中的每一个的所述信息与所述至少两个队员中的每一个的所述信息之间的所述相似度，确定所述至少两个队长和所述至少两个队员中的每一个之间的匹配值。

在一些实施例中，所述相似度包括家乡相似度、年龄相似度和特征相似度。

在一些实施例中，所述家乡相似度是基于家乡评价函数确定的，所述年龄相似度是基于年龄评价函数确定的，所述特征相似度基于特征评价函数确定。

在一些实施例中，为了所述]确定所述匹配值，指示所述至少一个处理器执行附加操作，包括：基于所述家乡相似度确定第一子匹配值；基于所述年龄相似度确定第二子匹配值；基于所述特征相似度确定第三子匹配值；基于所述第一子匹配值、所述第二子匹配值或所述第三子匹配值中的至少一个确定所述匹配值。

在一些实施例中，所述确定所述一个或以上的组队，指示所述至少一个处理器执行附加操作，包括：从所述至少两个待组队成员的所述信息中提取与所述至少两个队员有关的评价信息；基于所述至少两个队员的每一个的所述评价信息，将所述至少两个队员的每一个分配给一个等级组；基于与所述至少两个队员的每一个相关的所述等级组，确定所述一个或以上的组队。

在一些实施例中，将所述至少两个队员中的每一个分配给等级组，指导所述至少一个处理器执行附加操作，包括：获得分类模型；基于所述评价信息，使用所述分类模型，确定与所述至少两个队员的每一个相关的等级组。

在一些实施例中，与所述至少两个队员的一个队员相关的评价信息包括所述队员对所述线上到线下服务平台的评价信息。

在一些实施例中，所述等级组包括推荐者组队、被动者组和贬损者组，并将所述至少两个队员分配给一个组，所述指导至少一个处理器执行附加操作，包括：基于所述线上服务平台上所述队员的所述评价信息，将所述队员分配给推荐者组、被动者组，或贬损者组。

在一些实施例中，与所述至少两个队员的一个队员有关的所述评价信息包括服务请求者提供的关于所述队员的评价信息。

在一些实施例中，所述等级组包括优质服务组、一般服务组和较差服务组，并将所述至少两个队员的每一个分配给一个等级组，指导所述至少一个处理器执行附加操作，包括：基于所述服务请求者提供的关于所述队员的评价信息，将所述队员分配给所述优质服务组、所述一般服务组，或所述较差服务组。

在一些实施例中，使所述至少一个处理器执行附加操作，包括：将属于不同的等级组的一个或以上队员组成一个组队。

在一些实施例中，使所述至少一个处理器执行附加操作，包括：将属于同一等级组的一个或以上队员组织成一个组队。

在一些实施例中,所述确定所述一个或以上的组队，使所述至少一个处理器执行附加操作，包括：从所述至少两个待组队成员的所述信息中提取与所述至少两个队员的每一个队员相关的历史订单信息；基于与所述每个队员有关的所述历史订单信息，确定所述至少两个队员的每个队员的出车行为特征；基于所述至少两个队员的每一个队员的所述出车行为特征，将所述至少两个队员分为一个或以上司机分组；对于所述一个或以上司机分组中的每一个，形成至少一个组队。

在一些实施例中,所述队员的出车行为特征包括所述队员的出车时间特征或所述队员的出车地域特征。

在一些实施例中,所述将所述至少两个队员分成一个或以上司机分组，使所述至少一个处理器执行附加操作，包括：确定每对所述至少两个队员之间的驾驶行为相似度；基于每对所述至少两个队员之间的驾驶行为相似度，确定所述一个或以上司机分组。

在一些实施例中，所述司机分组中的每一个包括至少一个队长和至少一个队员，并为所述一个或以上司机分组成立至少一个组队，指示所述至少一个处理器执行附加操作，包括：对于司机分组，将与所述至少一个所述司机分组队员有关的信息发送至所述司机分组的至少一个队长；接收所述司机分组的至少一个队长对所述司机分组的至少一个队员的回复；基于至少一个所述司机分组队长的回复，为所述司机分组确定至少一个组队。

在一些实施例中，所述与所述至少一个队员和所述响应有关的信息被加密，所述至少一个处理器还用于执行附加操作，包括解密与所述至少一个队员有关的加密信息并解密所述加密的响应。

在一些实施例中，所述解密与所述至少一个队员有关的加密信息，所述至少一个处理器还用于执行附加操作包括：在解密所述加密信息之前，验证所述至少一个队员或所述至少一个队员的设备的认证信息。为了解密所述加密响应，所述至少一个处理器还用于执行附加操作，包括：在解密所述加密响应之前，验证所述至少一个队长或所述至少一个队长的设备的认证信息。

在一些实施例中，使所述至少一个处理器执行附加操作，包括：通过所述至少两个待组队成员的装置的第一界面，接收报名指令；确定所述报名指令的类型，其中所述报名指令的类型包括队长报名指令或队员报名指令；响应于确定所述报名指令是一个队长报名指令，从所述至少两个队员，识别一个或以上备选队员；将所述一个或以上备选队员有关的用户信息显示在所述队员设备的第二界面上；从所述队员设备接收所述一个或以上备选队员中的至少一个的选择；向所述至少一个选定的备选队员发送加入组队的第一邀请；接收对于所述第一次邀请的一个或以上回复；基于所述收到的回复，确定至少一名同意加入所述组队的队员；将同意加入所述组队的所述至少一个队员的有关的用户信息显示在所述队员设备的第三界面上。

在一些实施例中，所述确定一个或以上备选队员，指导所述至少一个处理器执行附加操作，包括：使所述设备显示个人信息设置界面；通过所述个人信息设置界面，接收所述队员设置的用户信息；基于所述队员设置的用户信息以及所述队长报名指令，确定所述一个或以上备选队员。

在一些实施例中，所述至少一个处理器用于执行附加操作，包括：确定同意加入所述组队的队员的数量；响应于同意加入所述组队的队员的数量等于或超过预定值，生成指示所述组队已成功成立的通知；向所述至少一名队员发送所述通知；使所述通知显示在所述设备的所述第三界面上。

在一些实施例中，所述至少一个处理器还用于执行附加操作，包括：加密所述通知；向所述至少一个队员中的每一个发送所述加密通知。

在一些实施例中,发送给所述至少一个队员之一的所述加密通知包括所述队员或所述队员设备的认证信息，以认证所述队员或所述队员设备。

在一些实施例中,响应于确定所述报名指令是队员的报名指令，指导所述至少一个处理器执行附加操作，包括：使所述设备显示个人信息设置界面；通过所述个人信息设置界面，接收所述队员设置的用户信息；基于所述队员的用户信息，从所述一个或以上队员中设别所述队员的队长；检测从所述队长收到的第二个邀请；将所述第二邀请显示在所述设备的第四界面上。

在一些实施例中，所述第二邀请被加密，并且所述至少一个处理器被进一步指示执行附加操作，包括：解密所述加密的第二邀请。

在一些实施例中，所述解密所述加密的第二邀请，所述至少一个处理器还用于执行附加操作，包括：在所述解密之前，验证所述队员或所述队员设备的认证信息。

在一些实施例中，所述至少一个处理器还用于执行附加操作，包括：将所述报名指令的类型对应的活动信息显示在所述设备的第五界面上，其中所述活动信息包括职责信息、任务信息或奖励信息中的至少一个。

在一些实施例中，所述至少一个处理器还用于执行附加操作，包括：加密所述第一邀请；向所述至少一个选定的备选队员发送所述加密的第一邀请。

在一些实施例中，发送给所述至少一个所选备选队员中的每一个的所述加密的第一邀请包括所述每个所选备选队员的认证信息或所述每个所选备选队员设备的认证信息，以认证所述每个所选备选队员或所述每个所选备选队员的所述设备。

根据本申请的另一方面，提供了一个方法。所述方法可以在具有至少一个处理器和包括用于确定组队的一组指令的至少一个存储介质的计算设备上实现。该方法可以包括获得与至少两个待组队成员中的每一个相关的信息，所述至少两个成员包括至少一个队长和至少一个队员。所述方法还可以包括基于与所述至少两个队员有关的信息，自动将所述队员分配给所述队长，确定一个或以上的组队，其中所述一个或以上组队中的每一个包括一个队长和至少一个队员。

根据本申请的又一个方面，一种非暂时性计算机可读存储介质可以体现为计算机程序产品。所述计算机程序产品包括指令，所述指令用于使计算设备：获得与至少两个待组队成员中的每一个有关的信息，所述至少两个成员包括至少一个队长和至少一个队员；基于与所述至少两个队员有关的所述信息，自动将所述至少两个队员分配给所述至少两个队长，确定一个或以上的组队，其中所述一个或以上组队中的每一个组队包括一个队长和至少一个队员。

本申请的一部分附加特性可以在下面的描述中进行说明。通过对以下描述和相应附图的研究或者对实施例的生产或操作的了解，本申请的一部分附加特性对于本领域技术人员是明显的。本申请的特征可以通过对以下描述的具体实施例的各种方面的方法、手段和组合的实践或使用得以实现和达到。

附图说明

本申请将通过示例性实施例进行进一步描述。这些示例性实施例将通过附图进行详细描述。这些实施例是非限制性的示例性实施例，在这些实施例中，各图中相同的编号表示相似的结构，其中：

图1是根据本申请的一些实施例所示的线上到线下服务系统的应用场景示意图；

图2是根据本申请的一些实施例的示例性计算设备的示例性硬件和软件组件的示意图；

图3A是根据本申请的一些实施例所示的示例性移动装置的示例性软件和/或硬件的示意图；

图3B是根据本申请的一些实施例所示的又一示例性移动装置的示例性软件和/或硬件的示意图；

图4是根据本申请的一些实施例所示的示例性处理引擎的框图；

图5是根据本申请的一些实施例所示的说明示例性组队过程的框图；

图6是根据本申请的一些实施例所示的说明示例性组队模块的框图；

图7是根据本申请的一些实施例所示的说明示例性组队过程的框图；

图8是根据本申请的一些实施例所示的训练接收概率模型的示例性流程图；

图9是根据本申请的一些实施例所示的训练接收概率模型的另一示例性流程图；

图10是根据本申请的一些实施例所示的组队的示例性流程图；

图11是根据本申请一些实施例所示的说明又一示例性组队模块的框图；

图12是根据本申请一些实施例所示的又一示例性组队过程的流程图；

图13是根据本申请一些实施例所示的又一示例性组队过程的流程图；

图14是根据本申请一些实施例所示的又一示例性组队模块的框图；

图15是根据本申请一些实施例所示的用于组队的又一示例性过程的流程图；

图16A至图16C是根据本申请一些实施例所示的用于组队的又一示例性过程的流程；

图17是根据本申请一些实施例所示的用户的设备的用户界面的示例性第一界面；

图18是根据本申请一些实施例所示的用户设备的用户的界面的示例性第二界面；

图19是根据本申请一些实施例所示的用户的设备的用户界面的示例性第三界；

图20是根据本申请一些实施例所示的用户的设备的用户界面的示例性个人信息设置界面。

具体实施方式

以下描述是为了使本领域的普通技术人员能够实施和利用本申请，并在特定应用及其要求的上下文中提供。对于本领域的普通技术人员来讲，对本申请披露的实施例进行的各种修改是显而易见的，并且本文中定义的通则在不背离本申请的精神及范围的情况下，可以适用于其他实施例及应用。因此，本申请不限于所示的实施例，而是符合与申请专利范围一致的最广泛范围。

本文中所使用的术语仅用于描述特定示例性实施例，并不限制本申请的范围。如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可以包括复数。应该被理解的是，本申请中所使用的术语“包括”与“包含”仅提示已明确标识的特征、整数、步骤、操作、元素和/或部件，而不排除可以存在和添加其他一个或以上特征、整数、步骤、操作、元素、部件和/或其组合。

应当理解，本文使用的术语“系统”、“模块”和/或“块”是以升序区分不同级别的不同部件、组件、零件、部分或组合的一种方法。但是，如果能达到同样的目的，这些术语则可能会被另一些术语所取代。

这里使用的术语“模块”或“块”是指包含在硬件或固件中的逻辑，或者是软件指令的集合。这里描述的模块或块可以实现为软件和/或硬件，并且可以存储在任何类型的非暂时性计算机可读介质或其他存储设备中。在一些实施例中，软件模块/单元/块可以编译并将链接到可执行程序中。应当理解，软件模块可以从其他模块/单元/块或它们自身调用，和/或可以响应于检测到的事件或中断而被调用。用于在计算设备上执行的软件模块/单元/块可以在计算机可读介质上提供，例如光盘，数字视频盘，闪存驱动器，磁盘或任何其他有形介质，或者作为数字下载(最初可以以压缩或可安装的格式存储，需要在执行前进行安装，解压缩或解密)。这里的软件代码可以部分或全部地储存在执行操作的计算设备的存储设备中，并应用在计算设备的操作之中。软件指令可以嵌入固件中，例如电可编程只读存储器(EPROM)。进一步讲，硬件模块/单元/块可能被包括在连接逻辑组件中,如开门电路和触发电路,和/或包括在可编程单元中,如可编程门阵列或处理器。模块/单元/块或计算设备所述功能可以实现为软件模块/单元/块,但是可能呈现为硬件或固件。一般来说,不考虑物理组织架构和存储，所述模块/单元/块指逻辑模块/单元/块可能结合其他模块/单元/块或分为子模块/子单元/子块。该描述可适用于系统、引擎或其部分。

应当理解,当一个模块或块被“连接”,或“耦合”到另一个模块块,它可能直接连接或耦合,或与其他模块通信,块,或中间单元、引擎、模块或块可能存在，除非上下文清楚地表明。本文中使用的术语“和/或”可以包括任何或所有至少一个所列项目的组合。

根据以下对附图的描述，本申请所述的和其他的特征、操作方法、相关组件的功能和经济的结构更加显而易见，这些都构成说明书的一部分。然而，应当理解，附图仅仅是为了说明和描述的目的，并不旨在限制本申请的范围。应当理解的是附图并不是按比例的。

本申请中使用了流程图用于说明根据本申请的实施例的系统所执行的操作。应当明确理解，流程图中的操作可以不按顺序实施。相反，可以按照倒序或同时处理各种步骤。而且，可以将一个或以上其他操作添加到流程图中。一个或以上操作也可能会从流程图中删除。

此外，虽然本申请的系统和方法的描述主要关于分配交通运输服务请求，应该理解的是，这只是一个示例性的实施例。本申请的系统或方法还可应用于其他类型的线上到线下服务。例如，本申请的系统和方法还可应用于包括陆地、海洋、航空航天等，或其任意组合。该运输系统中的使用的交通工具可包括出租车、私家车、顺风车、巴士、列车、子弹头列车、高速铁路、地铁、船只、飞机、宇宙飞船、热气球、无人驾驶车辆等，或其任意组合。运输系统还可以包括用于经营及/或分配的任何运输系统，例如用于传输及/或接收快递的系统。本申请的不同实施例应用场景可以包括网页、浏览器插件、客户端、定制系统、企业内部分析系统与人工智能机器人等中的一种或几种的组合。

线上到线下服务的对象可以是任何产品。在一些实施例中，产品可以是有形产品或非物质产品。有形产品可包括食品、药品、商品、化工产品、电器、服装、汽车、住房、奢侈品等，或上述产品的任意组合。非物质产品可包括服务产品、金融产品、知识产品、互联网产品等，或上述产品的任意组合。互联网产品可包括单个主机产品、网络产品、移动互联网产品、商业主机产品、嵌入式产品等，或上述产品的任意组合。移动互联网产品可用于移动终端、程序、系统等软件或上述任意组合中。移动终端可以包括平板计算机、膝上型计算机、移动电话、个人数字助理(PDA)、智能手表、销售点(POS)设备、车载计算机、车载电视、可穿戴设备等，或上述终端的任意组合。例如，产品可以是计算机或移动电话中使用的任何软件和/或应用程序。该软件和/或应用程序可涉及社交、购物、运输、娱乐、学习、投资等，或上述领域的任意组合。在一些实施例中，与运输有关的软件和/或应用可包括旅行软件和/或应用、车辆调度软件和/或应用、绘图软件和/或应用等。在车辆调度软件和/或应用中，车辆可包括马、车厢、人力车(例如，独轮车、自行车、三轮车等)、汽车(如出租车、公共汽车、私家车等)、火车、地铁、船只、飞机(如飞机、直升机、航天飞机、火箭、热气球等)等，或上述交通工具的任意组合。

本申请中的术语“用户”指的是可以请求服务、订购服务、提供服务或促进提供服务的个人、实体或工具。在本申请中，术语“用户”和“用户终端”可以互换使用。在本申请中，术语“提供者”、“服务提供者”，以及“司机端”也可以交换使用，其表示可以提供服务或促进该服务提供的服务提供者使用的移动终端。在本申请中，术语“请求者”、“服务请求者”、“服务请求者”和“客户端”可以交换使用，其表示可以请求或订购服务的移动终端。

本申请中使用的定位技术可以包括全球定位系统(Global Positioning System，GPS)、全球卫星导航系统(Global Navigation Satellite System，GLONASS)、北斗导航系统(Compass Navigation System，COMPASS)、伽利略定位系统、准天顶卫星系统(Quasi-Zenith Satellite System，QZSS)、无线保真(Wireless Fidelity，WiFi)定位技术等，或其任意组合。上述定位技术中的一种或以上可以在本申请中互换使用。

本申请的本发明的一个方面涉及用于组织线上线下服务平台的队员(例如，司机)以形成一个或以上组队的系统和方法。每个组队可以包括一个队长和至少一个队员。系统可以接收与至少两个司机有关的信息。系统可以基于与所述至少两个司机相关的信息来确定组队。通过组建组队，通过司机之间的相互鼓励和与相互竞争鼓励司机完成更多的订单。

在本申请中，系统可以自动组织在线的线上到线下服务系统的队员，或者系统可以获得希望与其他队员一起组成组队的至少两个队员的请求。系统可以基于在线队员或报名实时参加组队的队员，动态地和/或实时地为队员形成一个或以上的队伍。

系统还可以允许使用至少两个多维的信息来确定组织队员的适合性。多维度的信息可以包括来自，例如不同时间(例如，历史信息、实时信息)，不同来源(例如，存储在系统的存储设备中的信息、由队员输入的信息等)的信息以提高组队的可靠性或准确性。

此外，历史信息可以包括历史订单信息和历史组队信息。系统可以为每个司机确定出车行为特征，并计算司机之间的出车行为特征的相似性。系统可以基于历史确定信息确定队员的偏好。系统可以将具有类似出车行为特征的队员组织到同一组队中和/或考虑队员的偏好以形成组队，这也可以提高组队的成功率和/或可靠性。

此外，在本申请的一些实施例中，系统可以采用以下技术中的至少一种：将服务系统的请求中的认证信息和嵌入到服务系统中/或将所述信息嵌入到请求者终端；加密用于传输的数据；如果嵌入的认证信息被验证，解密接收的数据等或其组合。这可以使特定数据到特定设备和/或队员(例如，队长、队员等)的安全通信和/或准确传输。

在本申请中提供了用于请求组队的用户界面。用户界面可以包括用于接收报名指令(包括队长报名指令或队员报名指令)的第一界面，用于显示与队长匹配的候选队员信息的第二界面，用于显示与同意加入队长组队有关的信息或显示通知的第三界面，用于显示邀请队长的邀请的第四界面，用于显示活动信息的第五界面，或用于接收队员(队长或队员)输入的个人信息的个人信息设置界面。特定信息可以以特定方式呈现在队员设备的界面上。

本申请的系统和方法解决的问题之一是线上到线下服务系统面临的大数据问题及其实时应用，包括，例如处理队员和为队员确定一个或以上组队的数据的无效使用。通过本申请的系统和方法解决的其他问题包括在大量用户设备(例如，队长的设备，队员的设备)之间的实时安全通信和/或特定数据到特定用户设备和/或特定队员的准确传输这些问题在后网络时代的线上到线下服务系统中出现，本申请以技术方式提供了这些问题的解决方案。

图1是根据本申请的一些实施例所示的线上到线下服务系统的应用场景示意图；例如，线上到线下服务系统100可以是用于运输服务的线上到线下服务系统(例如，出租车服务、司机服务、递送服务、拼车、公共汽车服务、外卖服务、司机雇用、车辆租用、火车服务、地铁服务、班车服务)，购物服务、健身服务、学习服务、金融服务等。

线上到线下服务系统100可以包括服务器110、网络120、一个或以上用户终端(例如，一个或以上乘客终端130、司机终端140)以及存储设备150。

服务器110可以包括处理设备112。应当注意图1所示的线上到线下服务系统100仅仅是一个例子，并不是限制性的。在一些实施例中，线上到线下服务系统100可以获得与由行程请求者发起的行程请求有关的实际乘坐共享行程的实际行程信息。在一些实施例中，线上到线下服务系统100还可以确定估计行程的估计行程信息，其中估计行程不是乘坐共享行程。在一些实施例中，线上到线下服务系统100可以基于实际行程信息和估计行程信息确定提示信息。

在一些实施例中，服务器110可以是单个服务器，也可以是服务器组。所述服务器组可以是集中式的，也可以是分布式的(例如，服务器110可以是分布式的系统)。在一些实施例中，服务器110可以是本地的，也可以是远程的。例如，服务器110可以通过网络120访问存储在一个或以上用户终端(例如，一个或以上乘客终端130、司机终端140)和/或数据存储设备150中的信息和/或数据。又例如，服务器110可以直接连接到一个或以上用户终端(例如，一个或以上乘客终端130、司机终端140)和/或存储设备150以访问存储的信息和/或数据。在一些实施例中，服务器110可以在云平台上实施。仅作为示例，该云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等，或其任意组合。在一些实施例中，服务器110可以在本申请中的图3描述的包含了一个或以上组件的计算设备300上执行。

在一些实施例中，服务器110可包括处理设备112。在一些实施例中，所述处理设备112可包括一个或以上处理引擎(例如，单芯片处理引擎或多芯片处理引擎)。仅作为范例，处理设备112可包括中央处理器(CPU)、特定应用集成电路(ASIC)、特定应用指令集处理器(ASIP)、图像处理器(GPU)、物理运算处理单元(PPU)、数字信号处理器(DSP)、现场可编程门阵列(FPGA)、可编程逻辑设备(PLD)、控制器、微控制器单元、精简指令集计算机(RISC)、微处理器等，或其任意组合。

网络120可以促进信息和/或数据的交换。在一些实施例中，线上到线下服务系统100中的一个或以上组件(例如，服务器110、一个或以上乘客终端130、一个或以上司机终端140或存储设备150)可以通过网络120向线上到线下服务系统100中的其他组件发送信息和/数据。例如，服务器110可以经由网络120从一个或以上乘客终端130获得/获取一个或以上的行程请求。又例如，服务器110可以向一个或以上乘客终端130发送提示信号以指示一个或以上乘客终端130通过网络120显示提示信息。作为另一示例，服务器110可以经由网络120向一个司机终端140发送一个或以上的行程请求。在一些实施例中，网络120可以是有线网络、无线网络等，或其任意组合。仅作为示例，网络120可以包括缆线网络、有线网络、光纤网络、远程通信网络、内部网络、互联网、局域网络(LAN)、广域网路(WAN)、无线局域网络(WLAN)、城域网(MAN)、公共交换电话网络(PSTN)、蓝牙网络、紫蜂网络、近场通信(NFC)网络等，或其任意组合。在一些实施例中，网络120可以包括一个或以上网络接入点。例如，网络120可以包括有线或无线网络接入点，例如基站和/或互联网交换点120-1,120-2，......通过这些接入点，线上到线下服务系统100的一个或以上组件可以连接到网络120以交换数据和/或信息。

在一些实施例中，乘客终端130可以包括移动设备130-1、平板计算机130-2、膝上型计算机130-3、机动车辆内置设备130-4等，或其任意组合。在一些实施例中，移动设备130-1可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、增强现实设备等，或其任意组合。在一些实施例中，智能家居设备可以包括智能照明设备、智能电器控制设备、智能监控设备、智能电视、智能摄像机、对讲机等，或其任意组合。在一些实施例中，可穿戴设备可包括智能手镯、智能鞋袜、智能眼镜、智能头盔、智能手表、智能衣服、智能背包、智能配件等，或其任意组合。在一些实施例中，智能移动设备可以包括智能电话、个人数字助理(PDA)、游戏设备、导航设备、销售点(POS)等，或其任意组合。在一些实施例中，虚拟现实设备和/或增强型虚拟现实设备可以包括虚拟现实头盔、虚拟现实眼镜、虚拟现实眼罩、增强现实头盔、增强现实眼镜、增强现实眼罩等，或其任意组合。例如，该虚拟现实设备和/或增强实境设备可包括Google Glass、Oculus Rift、HoloLens或Gear VR等。在一些实施例中，机动车辆内置设备130-4包括车载计算机或车载电视等。在一些实施例中，乘客终端130可以是一具有定位技术的设备。所述定位技术可以用于确定请求者和/或乘客终端130的位置。

在一些实施例中，司机终端140可以是一个与乘客终端130类似或者相同的设备。司机终端140可以包括移动设备140-1、平板电脑140-2、膝上型计算机140-3、机动车辆140-4中的内置设备等，或其任何组合。在一些实施例中，司机终端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)、可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)、光盘只读存储器(CD-ROM)和数字多功能磁盘只读存储器等。在一些实施例中，所述存储设备150可以在云平台上实现。仅作为示例，该云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等，或其任意组合。

在一些实施例中，存储设备150可以连接到网络120以与线上到线下服务系统100中的一个或以上组件(例如，服务器110，一个或以上用户终端等)通信。线上到线下服务系统100中的一个或以上组件可以经由网络120访问存储设备150中存储的数据和/或指令。在一些实施例中，存储设备150可以直接连接到线上到线下服务系统100(例如，服务器110，一个或以上用户终端等)中的一个或以上组件或与之通信。在一些实施例中，存储设备150可以是服务器110的一部分。

在一些实施例中，线上到线下服务系统100(例如，服务器110、一个或以上用户终端等)的一个或以上组件可以具有访问存储设备150的许可。在一些实施例中，当满足一个或以上条件时，线上到线下服务系统100中的一个或以上组件可以读取和/或修改与服务请求者、司机和/或公众有关的信息。例如，在完成一个服务后，服务器110可以读取和/或修改一个或以上用户的信息。应当注意，线上到线下服务系统100仅仅是用于说明处理设备112用于确定服务请求者的提示信息的应用的示例。处理设备112和线上到线下服务系统100的上述描述是出于说明的目的而提供的，并不旨在限制本申请的范围。

在一些实施例，线上到线下服务系统100的一个或以上的组件(例如，服务器110、乘客终端130、司机终端140和存储设备150)可以通过有线和/或无线通信，以电子和/或电磁信号的方式通信。在一些实施例中，线上到线下服务系统100还可以包括至少一个信息交换端口。所述至少一个交换端口可以被配置为接收信息和/或在线上到线下服务系统100中的任何电子设备之间发送与服务请求有关的信息(例如，以电子信号和/或电磁信号的形式)。例如，至少一个信息交换端口可以通过服务器110和司机终端140之间的无线通信，从司机终端140接收用于确定他/她的一个或以上队友的请求。又例如，该至少一个信息交换端口可以通过无线通信将包括确定的队友的电磁信号发送到司机终端140。在一些实施例中，至少一个信息交换端口可以是天线、网络接口、网络端口等中的至少一个，或其任何组合。例如，至少一个信息交换端口可以是连接到服务器110的网络端口，以向其发送信息和/或接收从其发送的信息。

图2是根据本申请的一些实施例所示的可以在其上实现服务器110，一个或以上用户终端(例如，一个或以上乘客终端130、司机终端140)的计算设备200的示例性硬件和软件组件的框图。计算设备200可以被配置为执行本申请中披露的服务器110，乘客终端130和司机终端140的一个或以上功能。例如，处理设备112可以在计算设备200上实现，并且被配置用于执行本申请中披露的处理设备112的功能。

计算设备200可以是通用计算机或专用计算机，两者都可以用于实现本申请中的线上到线下服务系统100。计算设备200可用于实现如本文所述的线上到线下服务系统100的任何组件。例如，处理设备112可以在计算设备200上通过其硬件、软件程序、固件或其组合实现。为了方便起见，图中仅示出了一台计算机，但是本申请描述的与检索服务有关的计算机功能可以在多个类似平台上以分布式方式实现，以分担处理负载。

例如，计算设备200可以包括网络相连接通信端口250，以实现数据通信。计算设备200还可以包括处理器220,以一个或以上处理器(例如，逻辑电路)的形式执行程序指令。例如，处理器包括其中的接口电路和处理电路。接口电路可以被配置为从总线210接收电信号，其中电信号为编码处理电路处理的结构化数据和/或指令。处理电路可以进行逻辑计算，然后将结论、结果和/或指令编码确定为电信号。处理电路还可以生成包括结论或结果的电子信号(例如，与司机有关的信息)和触发代码。在一些实施例中，触发代码可以是系统100中的电子设备(例如，乘客终端130)的操作系统(或其中安装的应用程序)可识别的格式。例如，触发代码可以是指令、代码、标记、符号等，或其任何组合，其可以激活移动电话的某些功能和/或操作或者让移动电话执行预定的程式)。在一些实施例中，触发器代码可以被配置用于分离电子设备的操作系统(或应用程序)以在电子设备界面上生成结论或结果的呈现(例如，与组队有关的结果)。然后，接口电路可以经由总线210从处理电路发出电信号。

示例性的计算机平台可以包括一个内部通信总线210、不同形式的程序内存和数据存储器，例如，磁盘270、和只读存储器(ROM)230或随机存取存储器(RAM)240，用于存储由计算机处理和/或传输的各种各样的数据文件。示例性的计算机平台也包括存储在只读存储器(ROM)230、随机存取存储器(RAM)240和/或其他形式的非暂时性存储介质中的能够被处理器220执行的程序指令。本申请的方法和/或流程可以以程序指令的方式实现。

计算设备200还包括输入/输出组件260，用来支持计算机和其他组件之间进行输入/输出。计算设备200也可以通过网络通信接收程序和数据。计算设备200还可以包括与硬盘通信的硬盘控制器、与小键盘/键盘通信的小键盘/键盘控制器、与串行接口设备通信的串行接口设备控制器、与并行接口设备通信的并行接口控制器、与显示器通信的显示器控制器等，或其任意组合。

仅仅为了说明，计算设备200只描述了一个中央处理单元和/或处理器。然而，需要注意的是，本申请中的计算设备300可以包括多个CPU和/或处理器，因此本申请中描述的由一个CPU和/或处理器实现的操作和/或方法也可以共同地或独立地由多个CPU和/或处理器实现。例如，如果在本申请中，计算设备300的CPU和/或处理器执行步骤A和步骤B，应当理解的是，步骤A和步骤B也可以由计算设备200的两个不同的CPU和/或处理器共同地或独立地执行(例如，第一处理器执行步骤A，第二处理器执行步骤B，或者第一和第二处理器共同地执行步骤A和步骤B)。

图3A是被配置用于实现本申请中披露的特定系统的示例性移动设备300-1的框图。在一些实施例中，被配置用于显示和传送与位置有关的信息的用户终端可以是移动设备300-1。移动设备300-1可以包括但不限于智能手机、平板电脑、音乐播放器、便携式游戏机、GPS接收器、可穿戴计算设备(例如，眼镜、手表等)等。移动设备300-1可以包括一个或以上中央处理单元(CPU)340、一个或以上图形处理单元(GPU)330、显示器320、内存360、通信平台310、存储设备390和输入/输出(输入/输出)350。在一些实施例中，CPU可以包括接口电路和处理电路。此外，移动设备300-1还可以是任何其他合适的组件，包括但不限于系统总线或控制器(图3A中未示出)。如图3A所示，移动操作系统(OS)370(例如，iOS、android、windows Phone等)和一个或以上的应用程序380可以从存储设备390加载到存储器360并由CPU 340实现。应用程序380可以包括被配置的浏览器或其他移动应用程序，用于接收和处理与用户在移动设备300-1中输入的查询(例如，位置名称)有关的信息。乘客/司机可以通过系统输入/输出设备350获得与一个或以上搜索结果有关的信息，并将该信息提供给服务器110和/或线上到线下服务系统100的其他模块或单元(例如，网络120)。

为了实现上述各种模块、单元及其功能，计算机硬件平台可以用作一个或以上元件的硬件平台。由于这些硬件元件，操作系统和程序语言是常见的，因此可以假设本领域技术人员熟悉这些技术并且他们能够根据本申请中描述的技术提供线上线下服务所需的信息。具有用户界面的计算机可以用作个人计算机(PC)，或其他类型的工作站或终端设备。在正确编程之后，具有用户界面的计算机可以用作服务器。可以认为本领域普通技术人员也可以熟悉这种类型的计算机设备的这种结构、程序或一般操作。因此，没有针对附图描述额外的解释。

图3B是示出根据本申请的一些实施例的另一示例性用户终端的框图。如图3B所示，用户终端可以在移动电话、计算机、平板设备、个人数字助理等上实现。用户终端300-2可以包括存储设备302、处理器309和计算机程序。计算机程序可以存储在存储设备302中，并且可以被配置为由处理器309执行以实现对司机组队的确定。

在一些实施例中，用户终端300-2还可以包括处理组件301、功率组件303、多媒体组件304、音频组件305、输入/输出(输入/输出)接口306、传感器组件307和通信组件308。

处理组件301可以控制用户终端300-2的整体操作，例如与显示、电话呼叫、数据通信、相机操作和记录操作相关的操作。处理组件301可以包括一个或以上处理器309，以执行指令以完成本申请中描述的方法的全部或部分步骤。另外，处理组件301可以包括一个或以上模块，以促进处理组件301和其他组件之间的交互。

存储设备302可以被配置用于存储各种类型的数据以支持用户终端300-2处的操作。这样的数据的示例可以包括用于在用户终端300-2上操作的任何应用或方法的指令、联系人数据、电话簿数据、消息、图片、视频等。存储设备302可以由任何类型的易失性或非易失性存储设备或其组合实现，例如静态随机存取存储器(SRAM)、电可擦除可编程只读存储器(EEPROM)、可擦除可编程只读存储器(EPROM)、可编程只读存储器(PROM)、只读存储器(ROM)、磁存储器、闪存、磁盘或光盘。

功率组件303可以向用户终端300-2的各种组件提供功率。功率组件303可以包括功率管理系统，一个或以上电源，和/或与为用户终端300-2生成、管理和分配功率相关联的其他组件。

多媒体组件304可以包括可以在用户终端300-2和用户之间提供输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸板(TP)。如果屏幕包括触摸板，则屏幕可以实现为触摸屏，以接收来自用户的输入信号。触摸板可以包括一个或以上触摸传感器，以感测触摸板上的触摸、滑动和手势。触摸传感器不仅可以感测触摸或滑动动作的边界处，还可以感测与触摸或滑动操作相关联的持续时间和压力。在一些实施例中，多媒体组件304可包括前置摄像头和/或后置摄像头。当用户终端300-2处于诸如拍摄模式或视频模式的操作模式时，前置摄像头和/或后置摄像头可以接收外部多媒体数据。每个前后摄像头可以是固定的光学镜头系统或具有焦距和光学变焦能力。

音频组件305可以被配置用于输出和/或输入音频信号。例如，音频组件305可以包括麦克风(MIC)，当用户终端300-2处于操作模式，例如呼叫模式、记录模式或者语音识别模式时，麦克风可以被配置用于接收外部音频信号。接收的音频信号可以进一步存储在存储设备302中或者通过通信组件308传送。在一些实施例中，音频组件305还可以包括用于输出音频信号的扬声器。

输入/输出接口306可以提供处理组件301和外围接口模块之间的接口，外围接口模块可以是键盘、点击轮、按钮等。这些按钮可以包括但不限于主页按钮、音量按钮、开始按钮或锁定按钮。

传感器组件307可以包括一个或以上传感器，用于为用户终端300-2提供各个方面的状态评估。例如，传感器组件307可以检测用户终端300-2的打开/关闭状态，组件的相对定位，例如组件为用户终端300-2的显示器和小键盘，传感器组件307还可以检测用户终端300-2或用户终端300-2的组件位置的变化，用户联系人与用户终端300-2之间是否存在联系，用户终端300-2用户终端300-2的方向或加速/减速和温度变化。传感器组件307可包括被配置的近距离传感器，用于检测附近物体的存在而无需任何物理接触。传感器组件307还可以包括光传感器，例如CMOS或CCD图像传感器，用于成像应用。在一些实施例中，传感器组件307还可包括加速度传感器、陀螺仪传感器、磁传感器、压力传感器或温度传感器。

通信组件308可以被配置用于促进用户终端300-2与其他设备之间的有线或无线通信。用户终端300-2可以基于诸如Wi-Fi、2G或3G之类的通信标准或其组合来接入无线网络。在一些实施例中，通信组件308可以经由广播通道从外部广播管理系统接收广播信号或广播相关信息。在一些实施例中，通信组件308还可以包括近场通信(NFC)模块以促进短程通信。例如，NFC模块可以基于射频识别(RFID)技术、红外数据协议(IrDA)技术、超宽带(UWB)技术、蓝牙(BT)技术等，或者它们的组合来实现。

在一些实施例中，用户终端300-2可以包括一个或以上专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑设备(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子组件。

图4是根据本申请的一些实施例所示的示例性处理设备112的框图。在一些实施例中，处理设备112可以与计算机可读存储器(例如，存储设备150)通信，并且可以执行存储在计算机可读存储介质中的指令。处理设备112可包括信息获取模块410和组队模块420。模块可以是处理设备112的全部或部分的硬件电路。模块还可以实现为由处理设备112读取和执行的应用程序或一组指令。此外，模块可以是硬件电路和应用/指令的任何组合。例如，当处理设备112正在执行应用程序/一组指令时，模块可以是处理设备112的一部分。

信息获取模块410可用于获得与组队确定(或称为组队)过程相关的信息和/或数据。在一些实施例中，信息获取模块410可以获得至少两个待组队成员的信息。至少两个队员可以包括至少一个队长和至少一个队员。在一些实施例中，待组队的队长信息和待组队的队员的信息可以包括但不限于自然属性信息、社会属性信息或习惯属性信息。自然属性信息可包括年龄、家乡、性别、身高、权值等，或其任何组合。社会属性信息可以包括姓名、职业、行业、家庭角色、家庭信息、社会角色等，或其任何组合。习惯属性信息可以包括爱好、专业、习惯等，或其任何组合。在某些实施例中，当队长和队员是司机时，队长和队员的信息还可以包括司机的驾驶年龄、服务水平(服务点)和/或车辆类型、颜色、品牌、车牌号码、容量(例如4或7个座位等)、附加属性(例如全景天窗)、行驶里程、年龄等，或其任何组合。

在一些实施例中，信息获取模块410可以获得历史组队数据。历史组队数据可以包括在组队推荐过程和/或结果中生成的信息和/或数据。

在一些实施例中，信息获取模块410还可以获得带组队的至少两个队员(包括队长和队员)的评价信息。在一些实施例中，待组队成员的评价信息可包括待组队成员的平台的评价信息，由待组队成员获得的评价信息等，或其任何组合。在一些实施例中，待组队成员可以是司机(例如在线打车司机)。在示例性实施例中，待组队成员是司机，待组队成员的评价信息可能包括至少一个司机对在线打车平台的评价信息、乘客对司机的评价信息、以及司机的综合评级信息等，或其任何组合。在一些实施例中，信息获取模块410可以获得与至少两个队员有关的历史订单信息。在某些实施例中，历史订单信息可包括司机信息、接单时间或接单位置。历史订单信息还可以包括乘客信息、起始位置、目的地位置、起始位置的开始时间、到达目的地位置的时间、支付信息等，或其组合。

组队模块420可以基于与至少两个队员有关的信息自动地将队员分配给队长来确定一个或以上的队伍。一个或以上组队中的每一个组队可以包括一个队长和至少一个队员。在一些实施例中，组队模块420可以基于与至少两个队员有关的信息确定至少两个队长中的每一个与至少两个队员中的每一个之间的接收概率。然后，组队模块420可以使用优化推荐算法基于接收概率来确定组队推荐方案，并基于组队推荐方案确定一个或以上的组队。在一些实施例中，组队模块420可以基于与至少两个队员有关的信息确定每一个队长与至少两个队员中的每一个之间的匹配值。然后，组队模块420可以基于匹配值确定一个或以上的组队。在一些实施例中，组队模块420可以基于与至少两个队员中的每一个相关的评价信息将至少两个队员中的每一个分配给等级组，并且基于与至少两个队员的每一个有关的等级组分配，确定一个或以上的组队。在一些实施例中，组队模块420可以基于与至少两个队员的每一个相关的历史订单信息来确定至少两个队员中的每一个的出车行为特征，基于每个至少两个队员的出车行为特征，划分至少两个队员到一个或多个司机等级组，并为一个或多个等级组的每一个确定至少一个组队。

应当注意，上述处理设备112的描述是出于说明的目的而提供的，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种各样的变化和修改。然而，这些变化和修改不会背离本申请的范围。在一些实施例中，上述任何模块可以一个或以上附加模块。例如，处理设备112还可以包括用于加密信息的加密模块和/或用于解密信息的解密模块。

图5是根据本申请的一些实施例所示的组队的示例性过程的框图。在一些实施例中，过程500可以由服务系统100执行。例如，过程500可以实现为存储设备(例如，存储设备150、只读存储器(ROM)、随机存取存储器(RAM)、存储设备390)中存储的一组指令(例如，应用程序)。在一些实施例中，处理设备112(例如，计算设备200的处理器220、移动设备300-1的中央处理单元(CPU)340、和/或图4中所示的一个或以上模块)可以执行一组指令，因此可以指示在服务平台(例如，线上线下服务系统100)中执行过程500。所述平台可以是基于因特网的平台，其通过因特网连接服务提供者和请求者。

在一些实施例中，处理设备112可以通过司机终端140的用户界面从司机终端140接收用于确定队伍的请求。在一些实施例中，所述请求可以由司机终端140加密。处理设备112可以在接收到加密的请求之后解密加密的请求。仅作为示例，司机终端可以使用其私钥对请求进行加密和/或对请求进行数字签名。处理设备112可以使用司机终端的公钥来解密请求。在一些实施例中，加密请求可以包括与司机终端和/或司机有关的认证信息，例如司机的标识、司机输入的密码、和/或司机终端的数字签名。处理设备112可以在解密之前验证请求者终端和/或请求者的认证信息。

在510中，处理设备112(例如，信息获取模块410)可以获取与待分组的至少两个队伍成员(例如，服务提供者)中的每一个有关的信息。至少两个队伍成员可以包括至少一个队长和至少一个队员。

在一些实施例中，与至少两个队伍成员的每一个有关的信息也可以由司机终端140加密，或者当信息存储在线上线下服务系统100的存储设备中时，由线上线下服务系统100的存储设备加密(例如，存储设备150、ROM230、RAM240等)。处理设备112可以在接收到加密信息之后解密加密信息。仅作为示例，司机终端可以使用其私钥对信息进行加密和/或对请求进行数字签名。处理设备112可以使用司机终端的公钥来解密信息。在一些实施例中，加密信息可以包括与司机有关的认证信息，例如司机的标识、司机输入的密码和/或司机的数字签名。处理设备112可以在解密之前验证司机终端和/或司机的认证信息。

在一些实施例中，与至少两个队伍成员中的每一个有关的信息可包括自然属性信息、社会属性信息、习惯属性信息等，或其任何组合。自然属性信息可包括年龄、家乡、性别、身高、体重等，或其任何组合。社会属性信息可以包括姓名、职业、行业、家庭角色、家庭信息、社会角色等，或其任何组合。习惯属性信息可以包括爱好、专业、习惯等，或其任何组合。在一些实施例中，当被分组的队长和队员是司机时，队长和队员的信息可以包括司机的驾驶年龄、服务水平(服务点)和/或车辆类型、颜色、品牌、车牌号码、容量(例如，4或7个座位等)、附加属性(例如，全景天窗)、行驶里程、车龄等，或其任何组合。

在一些实施例中，与至少两个队伍成员中的每一个相关的信息可以包括与至少两个队伍成员中的每一个相关的历史组队数据。历史组队数据可以包括在一个或以上组队过程中生成的信息或数据，或者队伍确定或形成的结果中包含的信息或数据。

在一些实施例中，与至少两个队伍成员中的每一个相关的信息可以包括与至少两个队伍成员中的每一个相关的评价信息。在一些实施例中，待组队成员的评价信息可包括待组队成员的平台评价信息、由待组队成员获取的评价信息，或其任何组合。在一些实施例中，待组队成员可以是司机(例如，在线汽车司机)。在特定实施例中，待组队成员是司机，待组队成员的评价信息可以包括在线汽车平台上司机的评价信息中的至少一个、一个或以上所述司机的乘客的评价信息、或司机的综合评级等，或其任何组合。

在一些实施例中，与至少两个队伍成员中的每一个相关的信息可以包括与至少两个队伍成员中的每一个相关的历史订单信息。历史订单信息包括：司机、接单时间或接单位置的信息。历史订单信息还可以包括乘客信息、起始位置、目的地位置、到起始位置的开始时间、到达目的地位置的时间、支付信息等，或其任何组合。

在520中，基于与至少两个队伍成员有关的信息，处理设备112(例如，组队模块420)可以通过自动地将至少两个队员分配给至少两个队长来确定一个或以上的队伍。所述一个或以上队伍中的每一个可以包括一个队长和至少一个队员。

在一些实施例中，基于与至少两个队伍成员有关的信息，组队模块420可以优先确定至少两个队长中的每一个与至少两个队员中的每一个之间的接收概率。然后，组队模块420可以基于接收概率使用优化推荐算法确定组队推荐方案，并基于组队推荐方案确定一个或以上的队伍。关于基于接收概率确定一个或以上队伍的过程的更多描述可以在本申请的其他地方找到。例如，参见图7和8及其相关描述。

在一些实施例中，基于与至少两个队伍成员有关的信息，组队模块420可以确定至少两个队长中的每一个与至少两个队员中的每一个之间的匹配值。然后，基于匹配值，组队模块420可以确定一个或以上的队伍。关于基于匹配值确定一个或以上队伍的过程的更多描述可以在本申请的其他地方找到。例如，参见图9及其相关描述。

在一些实施例中，基于与至少两个队伍成员中的每一个相关的评价信息，组队模块420可以将至少两个队伍成员中的每一个分配给队伍，并且基于与至少两个队伍成员中的每一个相关的所述队伍，分配确定一个或以上的队伍。在一些实施例中，与至少两个队伍成员的队伍成员有关的评价信息可以包括线上线下服务平台上的队伍成员的评价信息。这些组可以包括推荐者组、被动者组和贬损者组。在一些实施例中，与至少两个队伍成员的队伍成员相关的评价信息可以包括服务请求者提供的关于队伍成员的评价信息。这些组可以包括优质服务组、一般服务组和较差服务组。关于基于评价信息确定一个或以上队伍的过程的更多描述可以在本申请的其他地方找到。例如，参见图10及其相关描述。

在一些实施例中，基于与至少两个队伍成员相关的历史订单信息，组队模块420可以确定至少两个队伍成员中的每一个的出车行为特征，基于至少两个队伍成员中的每一个的出车行为特征，将至少两个队员划分为一个或以上司机分组，并且为一个或以上司机分组的每一个确定至少一个队伍。关于基于历史订单信息确定一个或以上队伍的过程的更多描述可以在本申请的其他地方找到。例如，参见图11和12及其相关描述。

图6是根据本申请的一些实施例所示的示例性组队模块的框图。如图6所示，组队模块420可以包括接收概率确定单元610、推荐方案确定单元620、匹配值确定单元630、等级组确定单元640、训练单元650和组队单元660。所述模块可以是组队模块420的全部或部分的硬件电路。所述模块也可以实现为由组队模块420读取和执行的应用程序或一组指令。此外，模块可以是硬件电路和应用/指令的任何组合。例如，当组队模块420正在执行应用程序/一组指令时，所述模块可以是处理设备112的一部分。

接收概率确定单元610可以被配置用于确定待分组的至少两个队长和待分组的至少两个队员中的每一个之间的接收概率。在一些实施例中，基于待分组的至少两个队长的信息和待分组的至少两个队员信息，接收概率确定单元610可以确定待分组的至少两个队长与待分组的至少两个队员之间的接收概率。在一些实施例中，根据接收概率模型，接收概率确定单元610可以确定待分组的每个队长与待分组的每个队员之间的接收概率。在一些实施例中，接收概率确定单元610可以确定一部分待分组的队长与一部分待分组的队员之间的接收概率。

推荐方案确定单元620可以被配置为确定组队推荐方案。例如，基于待分组的多个队长和待分组的多个队员之间的接收概率，推荐方案确定单元620可以根据优化推荐算法确定组队推荐方案。在一些实施例中，推荐方案确定单元620的推荐方案可用于确定至少两个候选组队推荐方案的预期成功概率。推荐方案确定单元620的推荐方案可以确定具有组队最高预期成功率的组队推荐作为组队推荐方案。推荐方案确定单元620的推荐方案可以建立组队成功率期望模型。基于组队成功率期望模型，推荐方案确定单元620可以根据组合优化算法确定组队推荐方案。推断方案单元620的推荐方案可以确定在不同意向状态下接受组队推荐(被称为接受意向)而成功组队的概率之和。推荐方案确定单元620可以确定成功组队的概率最大化的组队推荐。

匹配值确定单元630可以被配置用于确定待组队成员之间的匹配值。在一些实施例中，基于待组队成员的信息，匹配值确定单元630可以确定待组队成员之间的匹配值。例如，匹配值确定单元630可以确定所有待组队成员之间的匹配值。在一些实施例中，匹配值确定单元630可以确定每个待分组的队长与每个待分组的队员之间的匹配值。在一些实施例中，匹配值确定单元630可以比较待组队成员的一些或全部属性信息(例如，自然属性信息、社会属性信息、习惯属性信息)，并且根据比较结果，确定待组队成员之间的部分或全部属性的相似性。

对于待组队成员，等级组确定单元640可以被配置为确定一个或以上等级组(也简称为称为组)。在一些实施例中，等级组的数量或计数可以是至少两个。例如，根据待组队成员的评价信息，等级组确定单元640可以确定待组队成员的等级组。在一些实施例中，基于待组队成员的评价信息，等级组确定单元640可以使用分类模型确定待组队成员的等级组。在一些实施例中，等级组确定单元640可以使用决策树来确定待组队成员的等级组。例如，等级组确定单元640可以将待组队成员的评价信息作为输入，并且通过构造决策树模型来确定待组队成员的等级组。在一些实施例中，基于在线汽车平台上的司机的评价信息，等级组确定单元640可以确定属于推荐者组、被动者组或贬损者组的司机。在一些实施例中，根据司机的乘客的评价信息，等级组确定单元640可以被配置用于确定属于优质服务组、一般服务组或较差服务组的司机。

训练单元650可以被配置为训练以获取接收概率模型。在一些实施例中，基于历史组队数据，训练单元650可以生成接收概率模型。在一些实施例中，根据基于历史组队数据的机器学习方法，训练单元650可以生成接收概率模型。例如，根据逻辑回归(LR)算法，训练单元650可以被训练用于获取接收概率模型。

组队单元660可以被配置为确定待组队成员为一个或以上的队伍。例如，基于待组队成员之间的匹配值，组队单元660可以确定待组队成员为一个或以上的队伍。在一些实施例中，根据待分组的队员的等级组，组队单元660可以确定待组队成员的队伍。在一些实施例中，组队单元660可以确定待组队成员的不同等级组的队伍。在一些实施例中，组队单元660可以确定待分组的相同等级组的队伍成员的队伍。

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

应当注意以上对组队模块420及其模块的描述仅仅是为了便于描述，本申请不限于实施例的范围。应当理解，在理解了系统的原理之后，本领域普通技术人员可以在不脱离原理的情况下任意组合各种模块或连接其他子系统。例如，在一些实施例中，信息获取模块410、接收概率确定单元610、推荐方案确定单元620、匹配值确定单元630、等级组确定单元640、训练单元650和组队单元660可以是系统中的不同模块，也可以是实现上述两个或以上模块的功能的模块。例如，接收概率确定单元610、推荐方案确定单元620、匹配值确定单元630和等级组确定单元640可以是四个模块，或者可以是同时确定接收概率、确定推荐方案、确定匹配值，并且确定级别组和其他功能的模块(例如确定模块)。又例如，每个模块可以共享一个存储模块，并且每个模块也可以具有单独的存储模块。所述变化在本申请的范围内。在一些实施例中，组队模块420还可以包括一个或以上的附加单元，或者可以省略上述单元或以上。例如，组队模块420还可以包括被配置为加密信息的加密模块和/或被配置为解密信息的解密模块。

图7是根据本申请的一些实施例所示的组队的示例性过程的方框图。在一些实施例中，过程700可以由服务系统100执行。例如，过程700可以实现为存储设备(例如，存储设备150、只读存储器(ROM)、随机存取存储器(RAM)、存储设备390)中存储的一组指令(例如，应用程序)。在一些实施例中，处理设备112(例如，计算设备200的处理器220、移动设备300-1的中央处理单元(CPU)340、和/或图4中所示的一个或以上模块)可以执行一组指令，因此可以指示在服务平台(例如，线上线下服务系统100)中执行过程700。所述平台可以是基于因特网的平台，其通过因特网连接服务提供者和请求者。

在710中，基于至少两个队伍成员的信息(包括至少两个待组队队长的信息和至少两个待组队成员的信息)，处理设备112可以确定待分组的至少两个队长中的每一个与待分组的至少两个队员中的每一个之间的接收概率。在一些实施例中，步骤710可以由接收概率确定单元610执行。

在一些实施例中，线上线下服务系统100(例如信息获取模块410)可以获取待分组的至少两个队长的信息和至少两个队员的信息。在一些实施例中，待分组的队长和待分组的队员可以是司机。例如，待分组的队长和待分组的队员可以是在线汽车服务的司机。在一些实施例中，司机可以自由选择是否申请确定一个队伍。例如，司机可以通过司机终端140(例如，在线汽车服务终端)选择独立订单或队伍订单。在一些实施例中，当司机选择队伍订单时，司机可以选择报名为队长或队员。一般来说，队长在组队过程中或队伍成立后扮演整个队伍的主角。例如，队长可以选择哪个司机可以成为队伍的队员。又例如，队长可以在队伍成立后管理队伍(例如，任务分配、成员管理等)。在一些实施例中，队员可以选择加入队长的队伍。例如，系统可以向队员推荐多个队长(例如2、3、5等)。队员可以从多个队长中挑选一个并加入他/她的队伍。应当注意，在线汽车司机只是本申请披露的线上线下服务系统100的一个具体应用实施例。所述线上到线下服务系统的应用范围不限于司机或在线汽车司机。例如，线上线下服务系统也可以应用于任何合理的场景或领域，例如外卖、快递和游戏。

在一些实施例中，系统100可能要求请求者在满足某些条件之后请求形成队伍(报名为队长和/或队员)。在一些实施例中，所述条件可以包括但不限于在线汽车平台中的司机的服务时间超过某个阈值(例如，半年、1年、2年、3年等)、已完成服务订单的数量(或计数)超过某个阈值(例如500个订单、1000个订单等)、服务评估(例如，司机的乘客)超过某个阈值(例如，分数大于4.5/5分)等，或其任何组合。在一些实施例中，报名为队长的标准可能高于报名为队员的标准。例如，当他/她已经是组队的队员的次数(或计数)超过某个阈值(例如，10、20等)时，系统可能需要司机报名为队长。在一些实施例中，系统100(例如，处理设备112)可以调整队长的数量(或计数)和队员的数量(或计数)。例如，当有太多人试图报名时，系统100可以将一些队员指定为队长。在一些实施例中，司机可以报名参加组队而不指定为队长或队员。在一些实施例中，系统100可以将报名的司机的一部分指定(或随机分配)为队长。

在一些实施例中，当司机报名到组队(报名为队长或队员)时，系统100可以获取司机的信息。例如，处理设备112可以通过网络120从司机终端140获取司机的信息。又如例如，在司机终端140发送组队请求之后，处理设备112可以从存储设备150获取司机的相应信息。

在一些实施例中，待分组的队长的信息和待分组的队员的信息可以包括但不限于自然属性信息、社会属性信息或习惯属性信息。自然属性信息可包括年龄、家乡、性别、身高、体重等，或其任何组合。社会属性信息可以包括姓名、职业、行业、家庭角色、家庭信息、社会角色等，或其任何组合。习惯属性信息可以包括爱好、专业、习惯等，或其任何组合。在一些实施例中，当待分组的队长和待分组的队员是司机时，待分组的队长的信息和队员的信息还可以包括司机的驾驶年龄、服务水平(服务点)和/或或车辆类型、颜色、品牌、车牌号、容量(例如4或7个座位等)、附加属性(例如全景天窗)、行驶里程、车龄等，或其任何组合。

在一些实施例中，根据接收概率模型，处理设备112可以确定待分组的至少两个队长与待分组的至少两个队员之间的接收概率。在一些实施例中，基于历史组队数据的训练，可以获取接收概率模型。在一些实施例中，基于机器学习算法(例如，逻辑回归算法)，可以获取接受概率模型。在一些实施例中，系统100可以确定待分组的每个队长与待分组的每个队员之间的接收概率。

在720中，基于待分组的至少两个队长和待分组的至少两个队员之间的接收概率，处理设备112可以使用优化推荐算法来确定组队推荐方案。在一些实施例中，步骤720可以由推荐方案确定单元620执行。

在一些实施例(例如，图8和相关描述)中，可以假设待分组的n队长和待分组的m队员之间的接收概率矩阵表示为矩阵L，如等式(1)所示：

其中，p_ij表示待分组的队长l_j接收待分组的队员m_i，p_ij∈[0，1]的概率。

在一些实施例中，使用优化推荐算法确定组队推荐方案可以包括：相对于至少两个候选组队推荐方案的每一个，确定组队的预期成功率；确定对应于最高成功率的组队推荐方案作为最终组队推荐方案。在一些实施例中，根据优化推荐算法确定组队推荐方案可以包括：建立用于确定组队成功率的期望模型(在此也称为组队成功率期望模型)；基于确定组队成功率的期望模型，根据组合优化算法确定组队推荐方案。

假设队长和队员之间的推荐关系可以用以下推荐矩阵R表示，如下式(2)所示：

其中，b_ij表示队员m_i是否被推荐给队长l_j。其中，队长l_j最多可以分配给l_j队员。队员m_i最多可以分配给m_i队长。即：

根据接收概率矩阵L和推荐矩阵R，预期成功率可以表示为E_(L，R)。确定具有最大预期成功率的候选组队推荐方案作为最终组队推荐方案可以描述为：当E_(L，R)的值最大时确定推荐矩阵R.即：

其中，

表示组队推荐方案，而

当E_(L，R)的值最大时表示R。

在一些实施例中，可以以各种方式建立成功率期望模型。下面描述用于确定成功率预期的两个实施例(实施例1，实施例2)。应当注意期望模型用于确定组队的成功率也可以采取许多其他形式，本申请本申请不限于实施例的范围。

实例1

在该示例中，待分组的n队长愿意接受待分组的m队员，可以表示为接受意图矩阵Q，如等式(5)所示：

其中，c_ij表示队长l_j是否意图接受队员m_i.c_ij是否满足以下约束：

也就是说，c_ij可以是0或1。当c_ij＝0时，可能意味着队长l_j无意接受队员m_i；当c_ij＝1时，表示队长l_j有意接受队员m_i。另外，因为b_ij表示队员m_i是否被推荐给队长l_j。当c_ij＝0，即队长m_i不推荐给队长l_j时，队长l_j不能接收队员m_i，所以c_ij可以设置为0。当b_ij＝1，即队员m_i被推荐给队长l_j时，可以根据他/她自己的意图选择队长l_j，即c_ij可以是0或1。在一些实施例中，接受意图矩阵Q是枚举类型，并且可以取集合Vq中的任何值，集合Vq是包括至少两个定值意图矩阵q的集合。当每个c_ij取特定值(0或1)时，接受意图矩阵Q变为确定值意图矩阵q。

基于推荐矩阵R和接受意图矩阵Q，概率，P_(Q＝q)，可以获取接受意图矩阵Q取不同的定值意图矩阵q(表示为Q＝q)，并且组队的成功率为N_(Q＝q)，当Q＝q时也可以获取。在一些实施例中，组队的预期成功率可表示为等式(7)：

E_(L，R)＝∑_q∈Vq P_(Q＝q)·N_(Q＝q)， (7)

其中，接受意图矩阵Q＝q的出现概率可以通过等式(8)确定：

在一些实施例中，可以将待分组的队员推荐给多个队长以进行分组(例如，至少两个队长待分组)。假设a_i表示想要接受队员m_i的队长的数量(或计数)，则：

当队员m_i被推荐给a_i队长时，每个队长都想接受队员m_i，各种队长之间存在着类似于竞争关系的关系。在一些实施例中，当几个队长向队员m_i发送邀请时，每个队长可以自由选择加入哪个队长的队伍。在一些实施例中，系统100可以根据每个队长选择的顺序分配队员m_i。例如，哪个队长第一选择队员m_i，那么队员m_i可以默认加入队长的队伍。在这个例子中，当队员m_i被推荐给a_i时，队长都想接受队员，认为每个队长可能有接受队员m_i的相同概率，所以有：

其中，P_(ij|q)表示当接受意图矩阵Q＝q时，队长l_j接受队员m_i的概率。

假设队长l_j缺少的队员数量(或计数)是s_j，队长的数量(或计数)推荐给队长l_j是r_j，其中r_j≥s_j，s_j队员可以从r_j队员中选择组成队伍。因此，队长l_j有

可能的组合来组成一个队伍。假设在第k个组合中，队长l_j收到的队员的索引表示为

有：

其中，p_(j|q)表示队长的概率l_j组队在接受意图矩阵的情况下Q＝q。

根据等式(9)-(12)，组队或阵型的预期成功率可以推导为：

实例2：

假设M表示每个队伍允许的队员的最大数量(或计数)，q_i表示属于队长l_i的队伍的队员的数量(或计数)，然后是队伍队员的数量(或计数)需求是M-q_i.在这种情况下，为每个队伍推荐的队员的总数(或计数)是a_i＝a(M-q_i)，其中，a是常数。例如，a可以是2，表示推荐的数字(或计数)是缺少的队员数量(或计数)的两倍。进一步假设

表示当另一个(α示当)队长接受队员

时，队长l_i可以与队员

成功组成队伍的概率，其中，队员

代表第k个组合中的第g个队员。然后有：

其中，len(Lj)表示推荐队员

的队长的数量(或计数)。此外，可以确定与队长l_i和队员

有关的组队或阵型的成功率可以表示为等式(15)：

在一些实施例中，可以认为队长l_i和每个队员

可以在队伍中分组是独立的。因此，可以进一步确定根据第k次确定的组队成功率可以表示为等式(16)：

此外，队长l_i组队的成功率可以表示为等式(17)：

因此，基于等式(14)-(17)，可以确定组队或阵型的预期成功率可以表示为等式(18)：

通过建立用于确定组队成功率的期望模型(例如，示例1、示例2)，可以表达预期成功率E_(L，R)与接收概率矩阵L和推荐矩阵R之间的关系。基于所述，根据组合优化算法，可以确定组队推荐方案(即推荐矩阵R)。在一些实施例中，组合优化算法可以包括遗传算法、蚁群算法、蜂群算法、粒子群算法等，或其任何组合。本申请不限于实施例的范围。

在730中，基于组队推荐方案，处理设备112可以确定一个或以上的队伍。在一些实施例中，730可以由组队单元660执行。

在一些实施例中，组队单元660可以向队长推荐(发送)队员的信息。在一些实施例中，组队单元660向队长推荐的队员的数量(或计数)可以大于队长所需的队员的数量(或计数)。在这种情况下，队长可以从推荐的队员中选择他/她想要的队员。在一些实施例中，如果队长选择队员并且所选队员的数量(或计数)达到某个阈值(例如，5、8、10等)，则可能表示该队伍已成功形成。在一些实施例中，如果队长拿起一些队员并且队员中队员的数量(或计数)没有达到某个阈值，则可能意味着组队失败。在一些实施例中，当组队失败时，相应的队长和队员可以重新报名并再次参加组队。在一些实施例中，系统100可以将队伍成员保持在失败的组队中，并且基于队员缺少的数量(或计数)，推荐一个或以上其他队员作为形成队伍的另一次尝试。

在一些实施例中，组队单元660还可以向队员推荐(例如，发送)待分组的队长的信息以进行分组。例如，根据组队推荐方案(例如，推荐矩阵R)，组队单元660可以推荐待分组的队长的信息到相应待分组的队员。在一些实施例中，如果向同一队员推荐不止一个队长，则队员可以选择加入一个队长的队伍。在一些实施例中，只有队长选择了队员，才会向队员推荐队长。在一些实施例中，也可以采用双向选择机制。例如，系统100可以向每个队长推荐多个队员，并向每个队员推荐一个或以上队长。只有当队长选择队员并且队员也选择队长时，队员才能加入队长的队伍。

在一些实施例中，当队伍形成时，队伍中的队长和队员可以相互制约和彼此鼓励以提供更好的互联网服务(例如在线汽车服务)。在一些实施例中，系统100可以根据队伍的表现在队伍基础上进行评估，并且可以给予具有相对良好的评估结果的队伍一定的奖励，从而也激励司机积极地报名到组队。

图8是根据本申请的一些实施例所示的用于训练接收概率模型的示例性过程的流程图。在一些实施例中，过程800可以由服务系统100执行。例如，过程800可以实现为存储设备(例如，存储设备150、只读存储器(ROM)、随机存取存储器(RAM)、存储设备390)中存储的一组指令(例如，应用程序)。在一些实施例中，处理设备112(例如，计算设备200的处理器220、移动设备300-1的CPU340、和/或图4中所示的一个或以上模块)可以执行一组指令，因此可以指示在服务平台(例如，线上线下服务系统100)中执行过程800。所述平台可以是基于因特网的平台，其通过因特网连接服务提供者和请求者。

在810中，处理设备112可以获取与至少一个队长和至少一个队员有关的历史组队数据。在一些实施例中，步骤810可以由信息获取模块410执行。

在一些实施例中，历史组队数据可以包括在队伍推荐过程和/或结果中生成的信息和/或数据。例如，历史组队数据可以包括队伍推荐时间、队伍推荐号码(队长的数量或计数以及队员号码的数量或计数)、组队推荐方案、队伍推荐后的队长选择结果、队伍推荐后的队员选择结果、队长信息、队员信息等，或其任何组合。队长信息和/或队员信息可以包括但不限于自然属性信息、社会属性信息或习惯属性信息。自然属性信息可包括年龄、家乡、性别、身高、体重等，或其任何组合。社会属性信息可以包括姓名、职业、行业、家庭角色、家庭信息、社会角色等，或其任何组合。习惯属性信息可以包括爱好、专业、习惯等，或其任何组合。在一些实施例中，当队长和队员是司机时，队长的信息和/或队员的信息还可以包括司机的驾驶年龄、服务水平(服务点)和/或车辆类型、颜色、品牌、车牌号码、容量(例如4或7个座位等)、附加属性(例如全景天窗)、行驶里程、车龄等，或其任何组合。

在一些实施例中，一旦组队根据队伍建议完成，队伍推荐可以被视为历史组队数据。在一些实施例中，历史组队数据可以包括与过去时期(例如，1天、1周、1个月、3个月、半年、1年等)的队伍确定(或队伍推荐)有关的数据。在一些实施例中，历史组队数据可包括与最近完成的组队的数量有关的数据(例如，500、1000、5000等)。在一些实施例中，历史组队数据可以是与区域内的队伍确定(或队伍推荐)有关的数据。例如，区域可以包括某个国家、某个省、某个州、某个城市、某个区域、某个预定区域等，或者它们的任何组合。在一些实施例中，历史组队数据可能包括历史上用于队伍推荐但最终组队没有成功的数据。

在820中，处理设备112可以使用历史组队数据训练接收概率模型。在一些实施例中，步骤820可以由训练单元650执行。

接收概率模型可以反映某种类型的队长接受某种类型的队员的的接收概率。例如，对于相同类型的队长(或相同类型的队员)，他们可以在自然属性信息、社会属性信息、习惯属性信息等，或其任何组合中，具有相似性。在一些实施例中，接收概率可以表示当队员(特定类型的队员)被推荐给队长(或特定类型的队长)时，队长(或特定类型的队长)接受队员(或特定类型的队员)的概率。

在一些实施例中，基于历史组队数据的机器学习算法，训练单元650可以生成接收概率模型。机器学习方法可以包括归纳学习算法、强化学习算法、演绎学习算法、模拟学习算法等，或其任何组合。例如，根据逻辑回归(LR)算法，训练单元650可以训练并获取接收概率模型。在所述情况下，可以获取队长和/或队员的各种类型的信息(如自然属性信息/社会属性信息等)对接受结果的影响程度(诸如关于接收结果的各种类型的信息(或特征)的权重)。在一些替代实施例中，接收概率模型也可以基于其他训练方法获取，例如，神经网络、决策树等。

在一些实施例中(例如，当没有足够的历史组队数据时)，系统100还可以通过其他方式确定接收概率模型。例如，队长在选择队员(或队员)时考虑的主要因素(例如家乡、年龄、职业等)可以通过调查来确定，基于调查结果确定的每个因子的权重，并且可以根据每个因子的权重确定接收概率模型。

在完成接收概率模型的训练之后，接收概率确定单元610可以使用训练的接收概率模型来确定待分组的每个队长与待分组的每个队员之间的接收概率。为了更清楚地描述本申请中的相关实施例，可以假设有n队长被分组{l₁，l₂，...，l_n}和m队员被分组{m₁，m₂，...，m_m}。基于待分组的n队长的信息和待分组的m队员的信息，接收概率确定单元610可以使用接收概率模型确定待分组的n队长和待分组的m队员之间的接收概率矩阵。接收概率矩阵可以表示为L：

其中，p_ij表示待分组的队长l_j接受待分组的队员m_i的概率。p_ij可以是大于或等于0且小于或等于1的任何值。也就是说，p_ij∈[0，1]。例如，p_ij＝1可以指示当待分组的队员m_i被推荐给待分组的队长l_j时，待分组的队长l_j肯定会接受待分组的队员m_i。又例如，p_ij＝0可以表示待分组的队长l_j肯定不会接受待分组的队员m_i。又例如，当p_ij＝0.6时，它可以指示当待分组的队员m_i被推荐给待分组的队长l_j时，待分组的队长l_j具有60％的概率会接受待分组的队员m_i。

在一些实施例中，接收概率确定单元610可以确定一部分的待分组的队长与一部分的待分组的队员之间的接收概率。例如，队长可以在报名时为组队设置条件。具体而言，例如，队长可以设定他/她不会与某种类型的队员(例如，具有吸烟爱好的队员)合作，或者设置不接受一个或以上队员(例如，被列入黑名单的队员)进行组队等在这种情况下，队长和队员(受限队员)之间的接收概率可能无法确定；或者队长和这些队员之间的接收概率可以设置为0。在一些实施例中，队员也可以为队长和/或其他队员设置类似的限制。

图9是根据本申请的一些实施例所示的组队的另一示例性过程的流程图。在一些实施例中，过程900可以由服务系统100执行。例如，过程900可以实现为存储设备(例如，存储设备150、只读存储器(ROM)、随机存取存储器(RAM)、存储设备390)中存储的一组指令(例如，应用程序)。在一些实施例中，处理设备112(例如，计算设备200的处理器220、移动设备300-1的中央处理单元(CPU)340、和/或图4中所示的一个或以上模块)可以执行一组指令，因此可以指示在服务平台(例如，线上线下服务系统100)中执行过程900。所述平台可以是基于因特网的平台，其通过因特网连接服务提供者和请求者。

在910中，处理设备112可以获取待组队成员的至少两个队伍成员的信息。在一些实施例中，步骤910可以由信息获取模块410执行。

在一些实施例中，待组队成员可以包括司机(例如，在线汽车司机)、快递员、食品递送者，或可能与系统100有关的其他对象。在一些实施例中，待组队成员可能是同一地点同一工作的对象，例如，上海的在线汽车司机。在一些实施例中，待组队成员可以包括待分组的队长和待分组的队员。

在一些实施例中，待组队成员的信息可以参考待组队成员的属性信息，这可能反映了待组队成员的特征。属性信息可以包括但不限于自然属性信息、社会属性信息或习惯属性信息。自然属性信息可以包括家乡、年龄、个性(例如，外向、开放、内向、保守、热情、理性等)、性别、身高、体重等，或其任何组合。社会属性信息可以包括姓氏、职业、行业、家庭角色、家庭信息、社会角色等，或其任何组合。习惯属性信息可以包括爱好、专业、习惯等，或其任何组合。在一些实施例中，当待组队成员是司机时，待组队成员的信息可以进一步包括驾驶年龄、服务水平(服务点)和/或车辆信息(例如，模型、颜色、品牌、车牌号、容量、驾驶里程、车龄)等，或其任何组合。

在920中，基于待组队成员的信息，处理设备112可以确定至少两个待组队成员的每对之间的匹配值。在一些实施例中，步骤920可以由匹配值确定单元630执行。

在一些实施例中，基于待组队成员的信息，可以确定每对待组队成员之间的相似性。此外，基于每对待组队成员之间的相似性，可以确定每组待组队成员之间的匹配值。在一些实施例中，当待组队成员不被分成待分组队长或待分组队员时，基于任何两个待组队成员的信息，可以确定任何两个待组队成员的信息之间的相似性，然后可以确定两个队伍成员之间的匹配值。在一些实施例中，当待组队成员被分成待分组的队长和待分组的队员时，基于待分组的队长与待分组的队员的信息，可以确定待分组的队长的信息与待分组的队员的信息之间的相似性。然后，可以进一步确定待分组的队长与待分组的队员之间的匹配值。然后，匹配值确定单元630可以确定待分组的每个队长与待分组的每个队员之间的匹配值。

在一些实施例中，处理设备112可以将队伍成员的信息与所述组进行比较(例如，家乡信息、年龄、性格信息等)，并且基于比较，确定待组队成员信息之间的相似性。在一些实施例中，当比较待组队成员的家乡信息时，如果两个待组队成员的家乡在同一个县(区)，可以确定两个待组队成员的家乡信息之间的相似性非常高。如果两个待组队成员的家乡在同一个城市但不同的县(区域)，则可以确定两个待组队成员信息的家乡信息之间的相似性高。如果两个待组队成员的家乡在同一个省但不同的城市，则可以确定两个待组队成员的家乡信息之间的相似性较低。如果两个待组队成员的家乡在同一个国家但不同的省份，则可以确定两个待组队成员的家乡信息之间的相似性非常低。当两个待组队成员在不同的国家时，可以确定两个待组队成员的家乡信息之间的相似性是最低的。

在一些实施例中，当比较待组队成员的年龄时，可以确定两个待组队成员之间的年龄差异。两个待组队成员之间的年龄差异越小，两个待组队成员的年龄之间的相似性越高。具体地，两个待组队成员的年龄差异可以被划分为至少两个不同的阈值区间。至少两个不同的阈值间隔反映了两个待组队成员之间的年龄差异。至少两个不同的阈值间隔可以由系统手动设置或自动设置。例如，机器学习算法可用于分析与组队有关的大量历史数据，以确定适当的阈值间隔。例如，待分组的队员的年龄差异可以被划分为三个不同的阈值间隔，其分别是第一阈值间隔、第二阈值间隔和第三阈值间隔。可以逐渐增加第一阈值间隔、第二阈值间隔和第三阈值间隔的结束值。例如，第一阈值间隔、第二阈值间隔和第三阈值间隔可以分别是[0，4]、[5，9]、[10，100]。又例如，第一阈值间隔、第二阈值间隔和第三阈值间隔可分别为[0，5]、[6，10]、[11，100]。当两个待组队成员的年龄差异在第一阈值区间内时，可以确定两个待组队成员的年龄之间的相似性高。当两个待组队成员的年龄差异在第二阈值区间内时，可以确定两个待组队成员的年龄之间的相似性高。当两个待组队成员的年龄差异在第三阈值区间内时，可以确定两个待组队成员的年龄之间的相似性较低。

在一些实施例中，当比较待分组的队员的性格信息时，如果待分组的两个队友具有相同的性格，例如，待分组的两个队员的角色是外向和开放的，可以确定待分组的两个队员的性格信息之间的相似性非常高。如果待分组的两个队员的部分性格是相同的，例如，一个待组队成员的性格是热情和开放的，并且另一个待组队成员的性格是热情和保守的，并且可以确定待分组的两个队员的性格信息之间的相似性高。如果两个待组队成员的性格完全不同，例如，一个待组队成员的性格是热情和开放的，另一个待组队成员的性格内向和保守，可以确定两个待组队成员的性格信息之间的相似性非常低。在一些实施例中，机器学习算法可以用于确定待分组的队员的性格信息的相似性。在一些实施例中，可以使用字符分析模型来确定待组队成员的性格信息的相似性。

待组队成员之间的相似性(例如，家乡信息之间的相似性、年龄之间的相似性以及性格信息之间的相似性)可以量化为特定值。在一些实施例中，待组队成员的信息之间的较高相似性可以量化为较大的特定值。相反，待组队成员的信息之间的较低相似性可以量化为较小的特定值。在一些实施例中，特定值可以由系统手动或自动设置。在一些实施例中，机器学习算法可以用于分析与组队有关的大量历史数据，以确定特定值的适当值。

应当注意以上描述比较队员的家乡信息、年龄和人物信息以确定待组队成员的相似性仅仅是一个例子，并不限制本申请的包含范围。对于本领域普通技术人员，匹配值确定单元630可以比较待组队成员的一些或全部属性信息(例如，自然属性信息、社会属性信息、习惯属性信息)，根据比较结果确定待组队成员的部分或全部属性信息之间的相似性。

在一些实施例中，可以使用评估函数来确定两个队员之间的相似性。在一些实施例中，可以使用家乡评价函数来确定待组队成员的家乡信息之间的相似性。家乡评价函数可以是分段函数、指数函数、对数函数等，或其任何组合。在一些实施例中，家乡评价函数可以表示为等式(20)：

其中，a和b分别代表两个待组队成员，h(a，b)代表家乡评价函数，T₁、T₂、…、T₅分别代表队伍成员家乡信息之间的相似度值。例如，T₁、T₂、…、T₅可以分别是5、4、3、2、1。又例如，T₁、T₂、…、T₅可以分别为4、3、2、1、0。

在一些实施例中，当待组队成员分为带分组队长和带分组队员时，家乡评价函数可以用于评估每个待分组队长的家乡信息与每个待分组队员的家乡信息之间的相似度。在所述情况下，家乡评价函数h(a，b)中的a代表待分组队长，b代表待分组队员。

在一些实施例中，年龄评估函数可用于确定待组队成员的年龄之间的相似性。年龄评估函数可以是分段函数、指数函数、对数函数等，或其任何组合。在一些实施例中，年龄评估函数可以表示为等式(21)：

其中a和b分别代表两个待组队成员，f(a，b)代表年龄评估函数，R₁、R₂和R₃分别代表待组队成员年龄之间的相似性值。例如，R₁、R₂和R₃可以分别为3、2和1。又例如，R₁、R₂和R₃可以分别为2、1和0。可以逐渐增加第一阈值间隔、第二阈值间隔和第三阈值间隔的结束值。例如，第一阈值间隔、第二阈值间隔和第三阈值间隔可以分别是[0，4]、[5，9]、[10，100]。又例如，第一阈值间隔、第二阈值间隔和第三阈值间隔可以分别为[0，5]、[6，10]、[11，100]。

在一些实施例中，当待组队成员被分成待分组队长和待分组队员时，年龄评估函数可用于评估每个待分组队长和每个待分组队员的年龄之间的相似性。在这种情况下，年龄评估函数f(a，b)中的a代表待分组队长，b代表待分组队员。

在一些实施例中，可以使用性格评估函数来确定待组队成员的性格信息之间的相似性。字符评估函数可以是分段函数、指数函数、对数函数等，或其任何组合。在一些实施例中，字符评估函数可以表示为等式(22)：

其中，a和b分别代表两个待组队成员，y(a，b)代表性格评价函数，Q₁、Q₂和Q₃分别表示待组队成员的性格信息之间的相似度值。例如，Q₁、Q₂和Q₃可以分别为3、2和1。又例如，Q₁、Q₂和Q₃可以分别为2、1和0。

在一些实施例中，当待组队成员分为队长分组和队员分组时，角色评价函数可用于评估待分组的每个队长的性格信息与待分组的每个队员之间的相似度。在这种情况下，角色评价函数y(a，b)中的a代表待分组队长，b代表待分组队员。

应当注意上述家乡评价函数、年龄评价函数和性格评价函数的描述仅仅是示例，并不限制本申请的包含范围。对于本领域普通技术人员，基于其他评估函数(例如，习惯评估函数、职业评估函数)，匹配值确定单元630可以确定待组队成员的其他方面之间的相似性。匹配值确定单元630还可以基于家乡评估函数、年龄评估函数或性格评估函数的其他变体确定待组队成员的信息之间的相似性。

在一些实施例中，在确定一个或以上待组队成员的信息之间的相似性之后，基于一个或以上待组队成员的信息之间的相似性，可以确定待组队成员之间的匹配值。待组队成员信息之间的相似性越高，待组队成员之间的匹配值越大。具体地，基于一个或以上待组队成员的信息之间的相似性，可以确定待组队成员之间的匹配值的一个或以上分量。此外，根据匹配值的一个或以上分量，可以确定待组队成员之间的匹配值。

在一些实施例中，当一个或以上待组队成员的信息之间的相似性是非定量值时，待组队成员之间的匹配值的一个或以上分量可以根据一个或以上待组队成员的信息之间的相似程度来确定。当待组队成员的信息之间的相似性高时，待组队成员之间的匹配值的分量可能很大。相反，当待组队成员的信息之间的相似性低时，待组队成员的匹配值的分量可能很小。在一些实施例中，当一个或以上待组队成员的信息之间的相似性是量化值时，根据量化值的大小，可以确定待组队成员之间的匹配值的一个或以上分量。例如，可以设置待组队成员之间的匹配值的分量与待组队成员的信息之间的相似性之间的映射关系，并且根据映射关系，可以确定待组队成员之间的匹配值的一个或以上分量。例如，映射关系可以是待组队成员之间的匹配值的一个或以上分量可以等于待组队成员的信息之间的相似性。

在一些实施例中，待组队成员之间的匹配值可以是匹配值的一个或以上分量的简单总和。在一些实施例中，待组队成员之间的匹配值可以是匹配值的一个或以上分量的权值总和。一个或以上分量的权值系数可以由系统手动设置或自动设置。在一些实施例中，机器学习算法可以用于分析历史组队数据的数量以确定适当的权值系数。待组队成员之间的匹配值可以是匹配值的一个或以上分量的其他操作的结果。其他操作可以包括但不限于乘法、倒数、积分等，或其任何组合。

在一些实施例中，如果待组队成员之间的匹配值包括第一分量、第二分量和第三分量，待组队成员之间的匹配值可以根据第一分量、第二分量或第三分量来确定。在一些实施例中，基于待组队成员的家乡信息之间的相似性，可以确定第一分量。基于待组队成员的年龄之间的相似性，可以确定第二分量。基于待组队成员的性格信息之间的相似性，可以确定第三分量。

在一些实施例中，基于第一分量、第二分量和第三分量中的任何一个，可以确定待组队成员之间的匹配值。例如，基于第一分量，可以确定待组队成员之间的匹配值。应该注意的是，当待组队成员之间的匹配值完全由第一分量确定时(即待组队成员的家乡信息之间的相似性)，在一些实施例中，队伍成员与相同的家乡信息(例如，在同一县(区))之间的匹配值可能是最高的，并且被分配给同一队伍的概率可能是最大的。当待组队成员分为待分组队长和待分组队员时，待分组的队员与具有相同家乡信息(例如，在同一个县(区))的待分组队长之间的匹配值可能是最高的，被分配到同一个队伍的概率可能是最大的。

在一些实施例中，基于具有较高优先级第一分量、第二分量和第三分量的分量，可以确定待组队成员之间的匹配值。在一些实施例中，第一分量、第二分量和第三分量的优先级可以连续降低。在组队中，具有较大第一分量的队伍成员可以被分配到同一个队伍，那么剩余待组队成员的第二分量较大的队伍成员可能会被分配到同一个队伍，然后剩下的队伍成员在两轮具有较大第三分量的组队之后可以被分配到同一个队伍。优先级可以由系统手动设置或自动设置。在一些实施例中，机器学习算法可以用于分析历史组队数据的数量以确定适当的优先级。在一些实施例中，可以基于第一分量确定待组队成员之间的匹配值。当两个或以上待组队成员和另一个待组队成员之间的匹配值彼此相等时，可以基于第二分量确定两个或以上待组队成员和另一个待组队成员之间的匹配值。应该注意的是，在一些实施例中，当待组队成员之间的匹配值优先根据第一分量(即，待组队成员的家乡信息之间的相似性)确定、然后根据第二分量(即，待组队成员的年龄之间的相似性)确定时，队伍成员与同一家乡信息(例如，在同一个县(区))之间的匹配值可能是最高的，并且被分配到同一个队伍的概率最大，并且具有相同年龄信息的待组队成员被分配到同一队伍的概率可以随后。

在一些实施例中，待组队成员之间的匹配值可以基于第一分量、第二分量和第三分量中的任何两个或全部来确定。例如，可以基于第一分量和第二分量、第一分量和第三分量、或第二分量和第三分量来确定待组队成员之间的匹配值。又例如，待组队成员之间的匹配值可以基于第一分量、第二分量和第三分量来确定。应该注意的是，当待组队成员之间的匹配值是基于第一分量、第二分量和第三分量确定的时候，考虑待组队成员的故乡信息、待组队成员年龄相似性和待组队成员的性格信息对待组队成员匹配值的影响。在一些实施例中，具有相似的家乡信息、年龄信息和性格信息的队伍成员之间的匹配值可能最高，并且被分配到同一队伍的概率可能是最大的。当待组队成员分为待分组队长和待分组队员时，待分组队员与具有相似家乡信息、年龄信息和性格信息的队长之间的匹配值可能是最高的，并且被分配到同一队伍的概率可能是最大的。

以上描述中的相似性是指两个或以上类型的信息接近的程度。例如，第一类信息是“北京”，第二类信息也是“北京”。第一类信息与第二类信息完全相同。两者彼此最接近，即相似度最大。应当理解，相似性仅仅是指示两个或以上类型的信息的接近度的示例，并且不是唯一的示例。表示两个或以上类型的信息接近程度的所有表达，例如相关性、相似性等，被表达和相似，并且应该包括在本申请中。

在930，基于待组队成员之间的匹配值，处理设备112可以确定待组队成员的一个或以上的队伍。在一些实施例中，步骤930可以由组队单元660执行。

在一些实施例中，可以通过各种分配方案对队伍成员进行分组。然后，基于待组队成员之间的匹配值(即，已经分组的队中的队伍成员之间的匹配值)，可以选择至少两个分配方案。当使用至少两个分配方案对待组队成员进行分组时，每个分配方案可以将待组队成员组合成至少一个队伍。每个队伍可以包括至少两个队伍成员，或者可以包括至少一名队员和至少一名队长。分配方案对应于匹配值的总和。总匹配值的总和可以是分配方案中所有队伍的总匹配值的总和。例如，当第一分配方案将待组队成员组合成三个小组时，三个小组的总匹配值分别为52、85和43，第一分配方案的总匹配值之和为180，即(52+85+43)。队伍的总匹配值反映了队伍中队伍成员之间的匹配值的总和。在一些实施例中，当队伍成员不区分队长和队员时，队伍的总匹配值是指队伍中任何两个队伍成员之间的匹配值之和。例如，当第一队有7个队伍成员时，第一队的总匹配值是7个队伍成员中任意两个之间的匹配值的总和。在一些实施例中，当队伍成员分为队长和队员时，队伍的总匹配值是指队长与组队中每个队员之间的匹配值之和。例如，当第二队有1个队长和6个队员时，第二队的总匹配值是队长和6个队员中的每一个之间的匹配值的总和。

在一些实施例中，基于对应于分配方案的总匹配值的总和，可以选择至少两个分配方案。例如，系统可以选择具有最高总和的总匹配值的分配方案来对待组队成员进行分组。例如，当三个分配方案用于对待组队成员进行分组时，对应于三个分配方案的总匹配值的总和分别为580、680和780，可以选择总匹配值为780的分配方案来对待组队成员进行分组。

在一些实施例中，根据机器学习分配方案，可以对队员进行分组。第一，任何分配方案可用于将待组队成员分组以获取至少两个初始组队。任意分配方案可以是人为确定的分配方案，或者可以是由系统随机选择的分配方案。至少两个初始组队可能包括待组队成员的全部或部分。每个初始组队可以包括至少两个队伍成员，或者可以包括至少一个队员和至少一个队长。然后，基于待组队成员之间的匹配值(即，初始组队中的队伍成员之间的匹配值)，可以确定每个初始组队的总匹配值。然后，基于每个初始组队的总匹配值，可以确定至少两个初始组队的总匹配值的总和。最后，不断调整至少两个初始组队的组成，直到所有可能的分配方案中调整后的初始组队的总匹配值之和最大。在这种情况下，相应的调整初始分配是最终分配方案。此外，最终分配方案可用于对待组队成员进行分组。

应当注意队伍成员与待组队成员之间的匹配值表示相同的内容。仅在不同的使用时段中使用不同的表达。在组合之前没有形成队伍时使用待组队成员之间的匹配值，并且在分组后形成队伍时使用队伍成员之间的匹配值。

为了完整地解释组队的过程，一个例子描述如下。应当理解，以下描述仅用于说明目的，并不限制本申请的保护范围。

假设有m+n待组队成员，m+n待组队成员由多个队长和多个队员组成。它可以用矩阵A表示为等式(23)：

其中，矩阵A有m行n列，矩阵A中任意元素a_ij的含义如下：

在分组过程中，设置两个约束：(1)每队最多7个队员；(2)每个队员只能推荐给1个队长。这两个约束可以表示如下：

如上所述，当队伍成员分为队长和队员时，队伍的总匹配值是队长与组队中每个队员之间的匹配值的总和。通过匹配值的一个或以上分量，可以确定队长与队伍中每个队员之间的匹配值，所述匹配值的一个或以上分量由组队中队长的信息与组队中每个队员的信息之间的相似性确定。在分组过程中，可以使用一个或以上的评估函数来确定待组队成员之间的相似性。例如，只有家乡评估函数可用于确定待组队成员之间的相似性，如等式(20)所示。在这种情况下，待组队成员之间的匹配值仅由一个分量确定，即，仅由待组队成员的家乡信息之间的相似性确定。假设待组队成员的家乡信息之间的相似性等于队伍待组队成员之间的匹配值的分量，队伍的总匹配值可以如等式(26)所示：

其中函数g(i)代表队长为l_i的队伍的总匹配值，h(l_i，a_ij)代表队长l_i和队员a_ij之间的匹配值(即，匹配值的分量对应于队长l_i和队员a_ij的家乡信息之间的相似性)。在这种情况下，h(l_i，a_ij)也代表队长l_i和队员a_ij的家乡信息之间的相似性。

根据以上描述，可以获取如下式(27)所示的模型：

可以通过使用合适的算法来解决模型。当分配方案的总匹配值的总和最大时，可以获取目标(或最终)分配方案。目标分配方案可用于对m+n待组队成员进行分组。该算法可以包括但不限于遗传算法、退火算法等，或其任何组合。

图10是根据本申请的一些实施例的组队的另一示例性过程的流程图。在一些实施例中，过程1000可以由服务系统100执行。例如，过程1000可以实现为存储设备(例如，存储设备150、只读存储器(ROM)、随机存取存储器(RAM)、存储设备390)中存储的一组指令(例如，应用程序)。在一些实施例中，处理设备112(例如，计算设备200的处理器220，移动设备300-1的中央处理单元(340)，和/或图4中所示的一个或以上模块)可以执行一组指令，并且可以指示在服务平台(例如，线上线下服务系统100)中执行过程1000。该平台可以是基于因特网的平台，其通过因特网连接服务提供者和请求者。

在1010中，处理设备112(例如，信息获取模块410)可以获取与至少两个待组队成员相关的评价信息。在1020中，等级组确定单元640可以基于与每个待组队成员相关的评价信息将每个队伍成员分配给等级组(在此也称为组)。

在一些实施例中，待组队成员的评价信息可以在线上线下服务平台上包括队伍成员的评价信息，服务请求者就待组队成员等提供的评价信息，或其任何组合。在一些实施例中，待组队成员可能是司机(如在线汽车司机)。在待组队成员是司机的特定实施例中，待组队成员的评价信息可包括在线汽车平台上的司机的评价信息、乘客提供的关于司机的评价信息，或司机的综合评级信息等，或其任何组合。

在一些实施例中，系统100可以在在线汽车平台上获取司机的评价信息。例如，在在线汽车行驶期间，司机可以通过司机终端140向系统100(例如服务器110)提交关于在线汽车平台的评估。又如例，在线汽车平台(如处理设备112)可以积极发起对司机的研究，并在在线汽车平台上获取司机的评价信息。在一些实施例中，在线汽车平台可以通过净推动者得分(NPS)调查工具调查司机。具体来说，司机可能是推荐的问题，例如，“请评价在线汽车平台(0-10)，得分越高，您对在线汽车平台的认可度越高，”或者“你想向朋友和同事推荐这个在线汽车平台(如果你愿意，为什么)。”等，收集司机的回应信息，然后可以提取司机答复信息中的相关评价信息。在一些实施例中，可以使用语义分析方法来提取司机响应信息中的相关评价信息。

在一些实施例中，根据司机反馈的评价信息，司机可分为不同的等级组。在一些实施例中，等级组的计数可以是至少两个。例如，根据在线汽车平台上的司机的评价信息，司机可以分为推荐者组、被动者组或贬损者组。其中，推荐者组的司机可能对在线汽车平台有更高的认可度，并可能在一定程度上成为在线汽车平台的推荐者；被动者组的司机可能在在线汽车平台上得到普遍认可。例如，他们既不会向他人推荐平台，也不会贬低平台；贬损者组的司机对在线汽车平台的认知度较低，可能会在一定程度上损害平台。

在一些实施例中，系统100可以获取乘客的评价信息到司机。在在线汽车服务平台中，每当司机完成订单时，乘客可以评估司机的表现。具体地，乘客可以通过乘客终端130选择(或输入)司机的评价信息(例如评级、评价标签、评论等)。在一些实施例中，乘客可能会得分司机。系统100可以获取在司机上提供的至少两个乘客的历史评价信息，并确定该司机的最终评价信息。例如，系统100可以获取历史中由多个乘客(例如，500、1000)提供的司机的得分，并确定多名乘客提供的分数的平均分数作为司机的最终分数。

在一些实施例中，根据司机上乘客的评价信息，司机可分为一个或以上等级组。在一些实施例中，等级组的计数可以是至少两个。例如，根据司机上乘客的评价信息，司机可以分为优质服务组，一般服务组或较差服务组。在这种情况下，不同等级组的司机可以反映乘客对司机的满意度。例如，属于优质服务组的司机可能涉及更高的乘客满意度；属于一般服务组的司机可能与乘客的普遍满意度有关；属于较差服务组的司机可能涉及较低的乘客满意度。

在一些实施例中，等级组确定单元640可以使用基于待组队成员的评价信息的分类模型来确定待组队成员的等级组。分类模型可以包括决策树、分析层次结构过程、贝叶斯分类算法或神经网络等，或其任何组合。在一些实施例中，可以使用历史评估数据(包括历史评价信息和与等级组相关的相应标签)来训练分类模型，以获取能够基于新评价信息确定待组队成员的等级组的分类模型。在一些实施例中，等级组确定单元640可以使用决策树来确定待组队成员的等级组。例如，等级组确定单元640可以将待组队成员的评价信息作为输入，并通过构造决策树模型来确定待组队成员的等级组。

在1030，处理设备112可以根据与待组队成员相关的组分配来确定待组队成员的一个或以上的队伍。在一些实施例中，步骤1030可以由组队单元660执行。

在一些实施例中，组队单元660可以将不同等级组的队伍成员分配给同一队伍。例如，属于推荐者组的司机，被动者组和贬损者组可以被分配给同一个队伍。又例如，优质服务组的司机，一般服务组和较差服务组可以分配给同一个队伍。在这种情况下，每个队伍包含属于至少两个等级组的司机。通过这样的队伍任务，队伍成立后，队伍中的队伍成员可以相互制约和鼓励。例如，推荐者组的司机可以驾驶贬损者组的司机，使得贬损者组可以提供更好的服务，并提高对在线汽车平台的贬损者组中的司机的理解。又例如，优质服务组的司机可以驾驶较差服务组的司机，以提高较差服务组的服务质量。

在一些实施例中，组队单元660可以将同一等级组的队伍成员分配给一个队伍。例如，组队单元660可以将属于推荐者组的司机分配给同一队伍，将属于被动者组的司机分配给同一队伍，并将属于贬损者组的司机分配给同一队伍。又例如，组队单元660可以将属于优质服务组的司机分配给同一队伍，将属于一般服务组的司机分配给同一队伍，并将属于较差服务组的司机分配给同一队伍。在这种情况下，由于同一队伍的司机有相似的理解，他们可以相处得更好，这有助于提高队伍的凝聚力。

在一些实施例中，当队伍成员待分组时，组队单元660还可以与基于待组队成员的等级组的其他因素组合在一起。例如，组队单元660可以结合本申请中披露的其他实施例将队伍成员组队。例如，组队单元660可以基于队伍成员的等级组和一个或以上属性信息(诸如家乡信息、年龄信息或队伍成员的工作)来确定待组队成员的一个或以上的队伍。

图11是示出根据本申请的一些实施例的另一示例性组队模块的框图。组队模块420可包括出车行为特征确定单元1110、司机分组确定单元1120和组队单元1130。模块可以是组队模块420的全部或部分的硬件电路。模块也可以实现为由组队模块420读取和执行的应用程序或一组指令。此外，模块可以是硬件电路和应用/指令的任何组合。例如，当组队模块420正在执行应用程序/一组指令时，模块可以是处理设备112的一部分。

出车行为特征确定单元1110可以根据历史订单信息计算每个司机的出车行为特征。出车行为特征确定单元1110还可以基于历史订单信息计算每个司机的工作时间特征和/或驾驶区域的特征。其中，工作时间的特征可能包括：接收时间在一天内的至少一个第一预设时间段内的分布信息，和/或接单时间在一周内的至少一个第二预设时间段内的分布信息。驱动区域的特征可以包括：接单位置在预设地理区域内的至少一个预设区域中的分布信息。第一预设时间段可包括早晨高峰期或晚高峰期等；并且第二预设期间是一周中的任何一天。

司机分组确定单元1120可以根据每个司机的出车行为特征对司机进行分组，以产生至少两个司机分组。司机分组确定单元1120还可以根据每个司机的出车行为特征来计算每两个司机的驾驶行为的相似度。司机分组确定单元1120还可以根据每两个司机的驾驶行为的相似性对司机进行分组，并生成至少两个司机分组。

组队单元1130可以将每个司机分组中的司机分配给至少一个队伍。组队单元1130还可以获取司机分组中每个司机的角色。司机的角色可能包括队长和队员。同一司机分组中的队员的信息可以被发送到司机分组中的队长，以请求队长可以提供指示队长是否允许队员加入他/她的队伍的反馈。结果可能包括队长的标识和已成功加入的队员的标识。组队单元1130还可以从队长接收结果并将与成功加入的标识相对应的司机分配给他/她的队伍。

图12是根据本申请的一些实施例的组队的另一示例性过程的流程图。在一些实施例中，过程1200可以由服务系统100执行。例如，过程1200可以实现为存储设备(例如，存储设备150、只读存储器(ROM)、随机存取存储器(RAM)、存储设备390)中存储的一组指令(例如，应用程序)。在一些实施例中，处理设备112(例如，计算设备200的处理器220，移动设备300-1的中央处理单元(CPU)340，和/或图4中所示的一个或以上模块)可以执行一组指令并因此可以指示在服务平台(例如，线上线下服务系统100)中执行过程1200。该平台可以是基于因特网的平台，其通过因特网连接服务提供者和请求者。

在1210中，处理设备112(例如，信息获取模块410)可以获取与至少两个待组队成员中的每一个相关的历史订单信息。历史订单信息可包括司机，接单时间或接单位置的信息。在一些实施例中，历史订单信息还可以包括乘客的信息、起始位置、目的地位置、到起始位置的开始时间、到达目的地位置的时间、支付信息等，或其任何组合。历史订单信息还可能包含历史订单中包含的所有信息，以及其他所需信息。其中，接单位置可以是司机接受订单时记录的司机的实时位置，或者历史订单信息中的起始位置可以用作接单位置。

在1220中，处理设备112(例如，出车行为特征确定单元1110)可以基于与至少两个队伍成员中的每一个相关的历史订单信息，确定至少两个队伍成员(例如，司机)中每一个的出车行为特征。在一些实施例中，司机的出车行为特征可以包括工作时间的特征和/或驾驶区域的特征。

在一些实施例中，在线汽车平台报名的一些司机是兼职司机，而兼职司机也有其他工作。这种司机的出发时间可以集中在一天的一个或几个时间段上，或者集中在一周的一天或几天。在一些实施例中，一些司机是全职司机，但可能需要在每天的固定时间去学校接孩子。因此，不同的司机'出发时间可能会有不同的特征。

在一些实施例中，出车行为特征确定单元1110可以根据每个司机的历史订单信息计算司机的工作时间特征。工作时间的特征可以指示司机的接单时间在一天中集中在哪个时间段和/或一周中的几天。工作时间的特点还可能包括司机每天上网的时间，每天的第一接单时间等。例如，司机的工作时间可以是早高峰期和晚高峰期，也可以是一周的周六和周日。另外，由于每个司机的地址不同，司机的接单位置可能具有一定的区域特征。在一些实施例中，出车行为特征确定单元1110还可以根据每个司机的历史订单信息计算出司机的驾驶区域的特征。驱动区域的特征可以表示司机的接单位置的地理范围。例如，司机驾驶区域的特征可以集中在北京的朝阳区和通州区，而另一个司机的驱动区域的特征可以集中在北京的五环区域。

在1230，处理设备112(例如，司机分组确定单元1120)可以基于每个司机的出车行为特征将司机划分为一个或以上司机分组。在计算每个司机的出车行为特征后，司机分组确定单元1120可根据司机'出车行为特征的相似性划分司机，因此，司机在同一组中的行为可能相似，并且同一组中的司机可能有更多共同的主题，并且彼此更熟悉和熟悉。

在1240，处理设备112(例如，组队单元1130)可以为司机分组中每一个确定至少一个队伍(在此也称为司机队伍)。在一些实施例中，每个司机只能加入一个司机队伍。每个司机分组中的司机可根据每个队伍中预设数量(或数量)的人数分为几个司机队伍。各司机队伍人员之间的出车行为特征相对类似，同一司机队伍的人员可能有更多共同话题，可以更好地互相监督和鼓励，增加接受订单的数量(或数量)。系统可以预先设置每个队伍的人数(或计数)，并且可以为每个队伍设置最小和/或上限。例如，系统可以将每个队伍设置为5人，或者系统可以为每个队伍设置最少4个人，或者系统可以设置最少4个人，每个队伍最多6个人。

图13是根据本申请的一些实施例的组队的另一示例性过程的流程图。在一些实施例中，过程1300可以由服务系统100执行。例如，过程1300可以实现为存储设备(例如，存储设备150、只读存储器(ROM)、随机存取存储器(RAM)、存储设备390)中存储的一组指令(例如，应用程序)。在一些实施例中，处理设备112(例如，计算设备200的处理器220，移动设备300-1的中央处理单元(CPU)340，和/或图4中所示的一个或以上模块)可以执行一组指令并因此可以指示在服务平台(例如，线上线下服务系统100)中执行过程1300。该平台可以是基于因特网的平台，其通过因特网连接服务提供者和请求者。

在1310中，处理设备112(例如，信息获取模块410)可以获取与待分组的至少两个队伍成员(例如，司机)中的每一个相关的历史订单信息。在一些实施例中，历史订单信息可以在预设时间段(例如，过去一个月，过去几个月，一年等)中与历史订单相关。

在1320中，处理设备112(例如，出车行为特征确定单元1110)可以根据与至少两个队伍成员中每一个相关的历史订单信息确定至少两个队伍成员中每一个的出车行为特征。

在1330，处理设备112(例如，司机分组确定单元1120)可以根据每个司机的出车行为特征将司机划分为一个或以上司机分组。

在确定每个司机的出车行为特征后，处理设备112可以根据司机的出车行为特征的相似性对司机进行分组，以使司机在每组中的行为相似，并且同一组中的司机有更多共同的主题，彼此更熟悉。在一些实施例中，处理设备112可以根据工作时间的特征和/或司机的驾驶区域的特征来确定司机工作的集中驾驶时间段和/或集中驾驶区域。每个司机分组中的所有司机可具有共同的集中驾驶时间段和/或共同的集中驾驶区域。

在一些实施例中，处理设备112可以指定司机工作的次数(或计数)超过第一预设数量(或次数)的时间段作为司机的集中驾驶时间段，并且处理设备112可以指定其中司机工作的次数(或次数)超过第二预设数量(或计数)的区域作为司机的集中驾驶区域。其中，可以根据实际和/或实时需要设置第一预设数量(或计数)次数和第二预设数量(或次数)，在此不做具体限定。

集中驾驶时间段可以包括一个或以上第一预设时间段和/或第二预设时间段。集中驱动区域可包括一个或以上预设区域。

在一些实施例中，处理设备112还可以根据工作时间的特征对司机进行分组，并且每个司机分组中的所有司机可能有一个共同的集中驾驶时间段，或每个司机分组的所有司机可能具有完全相同的集中驾驶时间段。

在一些实施例中，处理设备112可以仅根据驱动区域的特征对司机进行分组，并且每个司机分组中的所有司机可以具有共同的集中驱动区域，或者每个司机分组中的所有司机可能具有完全相同的集中驾驶区域。

在一些实施例中，处理设备112可以根据工作时间的特征和驱动区域的特征对司机进行分组，并且每个司机分组中的所有司机可能具有共同的集中驾驶时间段和共同的集中驾驶区域，或者每个司机分组中的所有司机可以具有完全相同的集中驾驶时间段和完全相同的集中驾驶区域。

为了根据工作时间的特征和驾驶区域的特征对司机进行分组，每个司机分组中的所有司机可以具有车辆的共同集中驾驶时段和共同的集中驾驶区域。例如，司机1的集中驾驶时间段是早晨高峰期，司机1的集中驾驶区域是朝阳区和海淀区；司机2的集中驾驶时间段为早高峰期和傍晚高峰期，司机2的集中驾驶区域为朝阳区和昌平区；司机3的集中驾驶时间是晚上高峰时间，司机3的集中驾驶区域是昌平区和海淀区；然后，当分组时，处理设备112可以将司机1和司机2分配给同一组，并将司机1和司机3分配给同一组。

在一些实施例中，根据每个司机的出车行为特征，处理设备112可以计算每两个司机的驾驶行为的相似性。

在一些实施例中，处理设备112可以根据每个司机的出车行为特征来计算每两个司机的驾驶行为的相似性。在计算每个司机的出车行为特征后，处理设备112可以根据司机的出车行为特征的相似性对司机进行分组，以使司机在每组中的行为相似，司机可能有更多共同的主题，彼此更熟悉。

具体地，对于任何两个司机，处理设备112可以根据两个司机的工作时间特征计算两个司机的工作时间(这里也称为工作时间相似度)的相似度，并且可以根据两个司机的驾驶区域的特征来计算两个司机的驾驶区域(这里也称为驾驶区域相似性)的相似度，并且可以基于工作时间特征的预设权值和驾驶区域的特征来计算两个司机的驾驶行为的相似性。

在一些实施例中，处理设备112可以确定工作时间相似度和驱动区域相似度的权值平均值或权值和，并将权值平均值或权值和指定为两个司机的驾驶行为相似度。

在一些实施例中，对于任何两个司机，处理设备112还可以根据两个司机的工作时间特征和驾驶区域的特征生成两个司机的驾驶属性向量。可以通过计算两个司机的驾驶车辆属性矢量之间的距离来确定驾驶行为相似性。此外，其他相似之处也可用于表示司机驾驶行为的相似性，如欧几里德距离、余弦相似度等。

在一些实施例中，司机的分组可以是模糊分组，即，每个司机可以同时属于至少两个不同的组。

在一些实施例中，处理设备112可以根据每个队伍中人数(或计数)的预定范围将每个司机分组中的司机分成几个司机队伍。每个司机队伍成员之间的出车行为特征相对类似，他们可能有更多共同的话题，可以更好地监督和鼓励对方，并增加接受订单的数量(或数量)。

在一些实施例中，处理设备112可以通过向队长推荐司机来分别确定每个司机分组中的司机队。在一些实施例中，司机可以根据每个队伍中预设数量(或数量)的人通过在线汽车平台随机分配到司机分组。

在1340中，对于每个司机分组，处理设备112可以获取司机分组中的每个司机的角色。司机的角色可能包括队长或队员。其中，司机可以通过在线汽车平台提供的应用程序的界面申请成为队长。或者，可以通过在线汽车平台选择并由司机批准的队长。

在1350中，处理设备112可以将队员的信息发送到同一司机分组中的一个或以上队长。当队长收到推荐队员的信息时，队长可以回复反馈结果，该结果表明队长是否允许队员加入他/她的队伍。结果可能包括队长的标识和已成功加入队伍的队员的标识。

在一些实施例中，处理设备112可以每次向队长发送预设数量的队员的信息。可以基于每个队伍的预设数量(或计数)的人来设置预设数量。在一些实施例中，预设数量(或计数)可以大于每队人数的预设数量(或数量)，这可以提高组队的效率。

在一些实施例中，与队员有关的信息可以由队员的设备加密。处理设备112可以在接收到加密信息之后解密加密的请求。仅作为示例，队员的设备可以使用其私钥对信息进行加密和/或对请求进行数字签名。处理设备112可以使用设备的公钥来解密信息。在一些实施例中，加密信息可以包括与队员和/或队员的设备有关的认证信息，例如队员的标识、队员输入的密码，和/或队员的设备的数字签名。处理设备112可以在解密之前验证队员和/或队员的设备的认证信息。

在一些实施例中，在线汽车平台可以向队长的司机终端140发送分组消息，并且分组消息可以包括向队长推荐的队员的信息。

在1360中，处理设备112可以从队长接收关于每个司机分组的至少一个队员中的每一个的响应。

在一些实施例中，来自队长的响应可以由队长的设备加密。处理设备112可以在从队长接收到加密响应之后解密来自队长的加密响应。仅作为示例，队长的设备可以使用其私钥加密来自队长的响应和/或对请求进行数字签名。处理设备112可以使用设备的公钥来解密来自队长的响应。在一些实施例中，来自队长的加密响应可以包括与队长和/或队长的设备有关的认证信息，例如，队长的识别、队长输入的密码，和/或队长的设备的数字签名。处理设备112可以在解密之前验证队长和/或队长的设备的认证信息。

在1370中，处理设备112可以基于响应确定每个司机分组的至少一个队伍。在一些实施例中，处理设备112可以根据响应将对应于成员加入的队员标识的司机添加到对应于队长标识的司机队伍。

在一些实施例中，如果处理设备112确定已形成队长的队伍，则处理设备112将不再向队长推荐成员的信息。如果一个队员成功加入一个队伍，那么在线汽车平台将不会向其他队长推荐队员的信息。

在一些实施例中，处理设备112可以以司机队伍为单位执行容量排名和奖励，以进一步改善司机活动和接受订单的热情。具体地，处理设备112可以计算每个司机队伍在预设时间范围内接受的订单的数量(或计数)，并在预设时间范围内向接受订单数量大于预设数量的队伍发放奖励。在一些实施例中，司机也可以在队伍中进行排名和奖励。

在本申请中，处理设备112通过组织具有较高类似出车行为特征的司机来形成队伍。司机的工作模式从个人工作变为队伍工作。每个队伍的司机可以互相监督和鼓励，以增加队伍中每个司机的能力。因此，在线汽车平台的整体容量得到改善。此外，在线汽车平台可根据每个司机的偏好确定队长，组建队伍后，属于同一组的司机被推荐到同一组的队长，队长可以选择队员来完成组队，从而允许队长参与该过程，从而使组队的过程更加用户友好。

图14是示出根据本申请的一些实施例的另一示例性组队模块的框图。组队模块420可包括报名单元1410、处理单元1420、邀请单元1430和设置单元1440。模块可以是组队模块420的全部或部分的硬件电路。模块也可以实现为由组队模块420读取和执行的应用程序或一组指令。此外，模块可以是硬件电路和应用/指令的任何组合。例如，当组队模块420正在执行应用程序/一组指令时，模块可以是处理设备112的一部分。

报名单元1410可以通过队伍成员的设备的第一界面接收由至少两个队伍成员(在此也称为用户)输入的报名指令。报名指令的类型可包括队长报名指令或队员报名指令。报名单元1410还可以使与报名指令的类型相对应的活动信息显示在设备的第五界面上。活动信息可包括职责信息、任务信息、奖励信息等，或其任何组合。

处理单元1420可以确定报名指令的类型。如果报名指令的类型是队长报名指令，则处理单元1420可根据队长报名指令从至少两个队伍成员识别一个或以上备选队员，并使与一个或以上备选队员有关的用户信息显示在第二界面上。例如，处理单元1420可以根据队长报名指令和用户的信息生成对备选队员的请求。处理单元1420可以基于确定备选队员的请求和用户的信息来确定备选队员。如果报名指令的类型是队员报名指令，则处理单元1420还可以通过个人信息设置界面接收用户输入的用户信息。用户信息可以包括行为习惯信息和/或自然属性信息。处理单元1420还可以根据队员报名指令和用户的信息确定一个或以上的队伍。

在用户通过第二界面选择任何备选队员之后，邀请单元1430可以被配置为向备选队员发送第一邀请。第一邀请可以是预设信息或用户输入的信息。在所选队员接受第一邀请后，已接受第一邀请并同意加入队伍的备选队员的用户信息可显示在第三界面上。邀请单元1430还可以确定同意加入队伍的备选队员的计数是否达到或超过预定值，如果是，生成通知，表明队伍已成功成立。邀请单元1430还可以将通知f发送给同意加入队伍的每个备选队员，并使得通知显示在第三界面上。

设置单元1440可以被配置为显示个人信息设置界面，并且通过个人信息设置界面接收用户输入的用户信息。用户信息可以包括行为习惯信息和/或自然属性信息。

图15是根据本申请的一些实施例的组队的另一示例性过程的流程图。在一些实施例中，过程1500可以由服务系统100执行。例如，过程1500可以实现为存储设备(例如，存储设备150、只读存储器(ROM)、随机存取存储器(RAM)、存储设备390)中存储的一组指令(例如，应用程序)。在一些实施例中，处理设备112(例如，计算设备200的处理器220，移动设备300-1的中央处理单元(CPU)340，和/或图4中所示的一个或以上模块)可以执行一组指令并因此可以指示在服务平台(例如，线上线下服务系统100)中执行过程1500。该平台可以是基于因特网的平台，其通过因特网连接服务提供者和请求者。

在1510中，处理设备112(例如，报名单元1410)可以接收用户通过用户的设备的第一界面输入的报名指令。报名指令的类型可包括队长报名指令或队员报名指令。

在一些实施例中，用户可以通过用户设备的第一界面设置输入报名指令。具体的第一界面可以设置有用于报名为队长的按钮和用于报名为队员的按钮。用户可以通过点击用于报名为队长的按钮或用于报名为队员的按钮来输入报名指令。在一些实施例中，用户还可以通过其他方式输入报名指令。

在一些实施例中，对应于报名指令类型的活动信息也可以显示在第一界面上。活动信息可以包括职责信息、任务信息、奖励信息等，或其任何组合。在一些实施例中，在确定报名指令的类型之后，可以在设备的其他接口上显示与报名指令的类型相对应的活动信息。职责信息可能包括队长的责任(例如，确定并领导一个队伍、帮助队员解决问题、动员热情、消除负面情绪等)、队员的责任(例如，与队长合作、协助组队、积极完成任务等)，或其任何组合。任务信息可以包括要完成的目标流量，要完成的目标订单量或目标服务得分值等。任务信息可以根据活动规则设置或者可以由每个司机队伍设置。在一些实施例中，规则信息对于不同的竞赛活动可能是不同的。在用户输入报名指令之前，可以包括选择竞赛格式的操作，以及各种竞赛格式的名称，如PK游戏、排名游戏等，以及相应的规则信息，例如“戏、游戏规则：在活动期间，与队伍投诉相关的订单数量(或计数)小于10，并且，可以在竞赛选择界面上显示与队伍中的小于预定分数的服务分数相关的订单的数量(或计数)小于10。竞赛选择界面还可以包括每种竞赛格式的报名条目，用户可以点击报名条目以显示与竞赛格式对应的第一界面。奖励信息可能涉及在完成任务后给予司机队伍一定的价格奖励。可以根据竞赛格式指定奖励规则。例如，前三名队伍将在活动结束后共收到1000元人民币。竞赛选择界面还可以包括用于反馈，事件共享等的选项，或其任何组合。

在1520，处理设备112(例如，处理单元1420)可以确定报名指令的类型是否是队长报名指令。当报名指令的类型是队长报名指令时，则在1530，处理设备112可以根据队长报名指令识别一个或以上备选队员。在1540，处理设备112可以使一个或以上备选队员的用户信息显示在用户设备的第二界面上。

在一些实施例中，处理设备112可以在接收到用户通过第一界面输入的报名指令后确定报名指令的类型。如果报名指令的类型是队长报名指令，则处理设备112可以匹配以确定用户的备选队员。匹配过程可以包括获取用户的信息第一，并且使用具有与用户类似的用户信息选择一个或以上报名用户。其中，用户信息可以由用户通过用户的设备输入并发送给处理设备112，也可以根据用户的历史数据获取。用户信息可以包括行为习惯信息和/或自然属性信息。行为习惯信息可能包括司机，驾驶区域等的工作时间。自然属性信息可以包括年龄、性别、司机的等，或其任何组合。处理设备112可以将用户与报名用户进行匹配。处理设备112完成匹配后，备选队员的用户信息可以发送给用户的设备，用户的设备可以在第二界面上显示备选队员的用户信息，供用户选择队员。在一些实施例中，第二界面也可以设置有邀请朋友的选项。当用户点击该选项时，用户的设备可以获取用户的好友列表，用户可以选择好友列表中的一个好友发送邀请。

在1550，处理设备112可以从备选队员接收来自用户设备的至少一个队员的选择，并且处理设备112(例如，邀请单元1430)可以将第一邀请发送给所选择的至少一个备选队员以加入该队伍。第一邀请可以是预设信息或用户输入的信息。

在一些实施例中，处理设备112可以加密第一邀请。处理设备112还可以将加密的第一邀请发送到所选择的至少一个备选队员的设备以加入该队伍。例如，处理设备112可以使用所选择的至少一个备选队员的设备的公钥来加密第一邀请以加入队伍。队员的设备可以使用所选择的至少一个备选队员的设备的私钥来解密加密的第一邀请以加入队伍。在一些实施例中，加密的第一邀请可以包括与所选择的至少一个备选队员相关的认证信息以加入该队伍和/或所选择的至少一个备选队员的设备加入队伍以验证所选择的至少一个备选队员以加入队伍和/或所选择的至少一个备选队员的设备加入该队伍。

在1560，处理设备112可以接收对第一邀请的一个或以上响应，并基于该响应确定同意加入队伍的至少一个队员。

在1570，处理设备112可以使同意加入队伍的备选队员的用户信息显示在用户设备的第三界面上。

在一些实施例中，用户可以选择第二界面上的任何备选队员，并将第一邀请发送给备选队员。具体地，用户可以在选择任何备选队员之后与备选队员建立即时通信，例如，通过集成在出租车软件中的微信，QQ或即时通信软件。用户还可以通过呼叫或其他方式与备选队员通信。当备选队员接受邀请并同意加入队伍时，用户的设备可以显示已接受邀请并同意在第三界面加入队伍的备选队员的用户信息。此外，当已接受邀请并同意加入队伍的备选队员的数量(或计数)达到或超过预设数量(或计数)时，完成组队。在一些实施例中，用户在查看备选队员的用户信息后，可以根据意愿向任意备选队员发送第一邀请，备选队员可根据意愿选择是否接受邀请。

图16A至16C是根据本申请的一些实施例的组队的另一示例性过程的流程图。在一些实施例中，过程1600可以由服务系统100执行。例如，过程1600可以实现为存储设备(例如，存储设备150、只读存储器(ROM)、随机存取存储器(RAM)、存储设备390)中存储的一组指令(例如，应用程序)。在一些实施例中，处理设备112(例如，计算设备200的处理器220、移动设备300-1的中央处理单元(CPU)340，和/或图4中所示的一个或以上模块)可以执行一组指令并因此可以指示在服务平台(例如，线上线下服务系统100)中执行过程1600。该平台可以是基于因特网的平台，其通过因特网连接服务提供者和请求者。

在1605中，处理设备112可以接收用户在第一界面上输入的报名指令。报名指令可包括队长报名指令或队员报名指令。第一界面可以如图17所示。第一界面1710具有用于报名为队长的按钮1711和用于报名为队员的按钮1712。在一些实施例中，第一界面1710还可以设置为活动信息，例如职责信息、任务信息或奖励信息。

在1610中，处理设备112可以确定报名指令的类型是否是队长报名指令。如果报名指令的类型是队长报名指令，则过程1600可以进行到1615；如果报名指令的类型是队员报名指令，则可以执行1660。

进一步地，在确定报名指令的类型后，该方法还可以包括：使活动信息显示在与报名指令的类型对应的第五界面上。

在1615，处理设备112可以使用户设备在个人信息设置界面上显示个人信息设置界面并接收用户输入的用户信息。用户信息可以包括行为习惯信息和/或自然属性信息。

在一些实施例中，个人信息设置界面可以如图20所示，输入框可以设置在个人信息设置界面2000上。在报名成队长后，用户可以通过个人信息设置界面输入用户信息。用户信息可以包括行为习惯信息和/或自然属性信息。行为习惯信息可以包括用户的工作时间，用户的驾驶区域等。自然属性信息可以包括年龄，性别，本地，用户的爱好等，或其任何组合。在一些实施例中，也可以在个人信息设置界面上提供一些标签供用户选择，例如70后、80后、保持鸟类、打麻将、种花、打斗地主、登山等。用户信息可以用于服务器的匹配过程，或者可以显示给备选队员，以便备选队员可以决定是否接受邀请并同意加入队伍。

在1620，处理设备112可以识别一个或以上备选队员，并使备选队员的用户信息显示在设备的第二界面上。

例如，处理设备112可以根据队长报名指令和用户的信息生成用于确定备选队员的请求。然后，处理设备112可以根据用户的信息匹配备选队员。处理设备112返回的至少两个备选队员的用户信息可以显示在用户设备的第二界面上。

在一些实施例中，第二界面可以如图18所示。可以在第二界面1800上显示至少两个备选队员的用户信息。在一些实施例中，可以显示所有用户信息。在一些实施例中，可以仅显示用户信息的一部分。在一些实施例中，如果仅显示标签，则当点击标签时，可以显示备选队员的全部或部分用户信息。

在1625，处理设备112可以从用户的设备接收对一个或以上备选队员中的至少一个的选择。在1630，处理设备112可以向所述至少一个所选备选队员中的每一个发送加入队伍的第一邀请。第一邀请可以是用户设置的预定信息或信息。在1635，处理设备112可以使得与同意加入队伍的至少一个队员有关的用户信息显示在用户设备的第三界面上。

在一些实施例中，第三界面也可以设置刷新按钮。当没有合适的备选队员时，用户可以点击刷新按钮，这样终端设备可以显示其他备选队员。第三界面1900可以如图19所示。已经接受邀请并同意加入队伍的队员的用户信息以列表的形式显示，并且还可以提供即时通信门户。用户可以单击门户以实现与队员的通信。在一些实施例中，在队员收到邀请并同意加入队伍之后，也可以由处理设备112获取队员的车牌号。队长可以通过将队员的牌照号上传到服务器来确定队员加入队伍。

在1640，处理设备112可以确定同意加入队伍的至少一个队员的计数。在1645，响应于确定同意加入队伍的至少一个队员的计数等于或超过预定值，处理设备112可以生成指示队伍已成功形成的通知。在1650，处理设备112可以将通知发送给至少一个队员中的每一个。在1655，处理设备112可以使通知显示在至少一个队员的设备的第三界面上。

在一些实施例中，处理设备112可以加密通知。处理设备112还可以将加密的通知发送到队员的设备。例如，处理设备112可以使用队员的设备的公钥来加密通知。队员的设备可以使用队员的设备的私钥来解密加密的通知。在一些实施例中，加密通知可以包括与队员和/或队员的设备有关的认证信息，以验证队员和/或队员的设备。

在一些实施例中，每个队伍也可以设置一个队伍名称。在队伍名称设置界面上收到用户输入的队伍名称后，设备可以将队伍名称发送给服务器，以便服务器根据队伍名称识别出司机队伍。

在1660中，当报名指令是队员报名指令时，处理设备112可以使设备显示个人信息设置界面，并通过用户设备的个人信息设置界面接收用户(例如，队员)设置的用户信息。用户设置的用户信息可以包括行为习惯信息和自然属性信息。在一些实施例中，也可以在个人信息设置界面上提供一些标签供用户选择，例如70后、80后、保持鸟类、打麻将、种花、打斗地主、登山等。该步骤中的个人信息设置界面可以与个人信息设置界面在步骤1615相同或不同。队员的用户信息可用于匹配过程。当队长选择队员作为邀请时，队员的用户信息可以显示给队长，以便队长可以决定是否邀请队员。

在1665中，处理设备112可以基于用户设置的用户的信息来识别用户的队长。在1670，处理设备112可以检测到从队长接收到第二邀请并且使第二邀请显示在设备的第四界面上。第四界面可以是即时消息接口或其他类型的通信接口。

在一些实施例中，来自队长的第二个邀请可以由队长的设备加密。处理设备112可以在从队长接收到加密的响应之后解密来自队长的加密的第二邀请。仅作为示例，队长的设备可以使用其私钥加密来自队长的第二邀请和/或对请求进行数字签名。处理设备112可以使用设备的公钥来解密来自队长的第二邀请。在一些实施例中，来自队长的加密的第二邀请可以包括与队长和/或队长的设备有关的认证信息，例如，队长的识别、队长输入的密码，和/或队长的设备的数字签名。处理设备112可以在解密之前验证队长和/或队长的设备的认证信息。

此外，如果队长接受邀请，则队伍的队伍成员和每个队伍成员的用户信息的信息可以显示在队伍成员界面上。队伍成员也可以通过即时通信接口进行通信。

在一些实施例中，用户可以在队伍形成之前退出队伍。例如，用户的设备可以接收用户输入的退出指令，并将退出指令发送给服务器，以便服务器可以从r队伍中移除用户。

在一些实施例中，在活动期间，用户的设备可以接收用户通过分数查询界面输入的分数查询，将分数查询发送到服务器，接收从服务器发送的结果，并在分数查询界面上显示结果。

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

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

此外，本领域的普通技术人员可以理解，本申请的各方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的过程、机器、产品或物质的组合，或对其任何新的和有用的改进。相应地，本申请的各个方面可以完全由硬件执行、可以完全由软件(包括韧体、常驻软件、微代码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“单元”、“模块”或“系统”。此外，本申请的各方面可以采取体现在一个或以上计算机可读介质中的计算机程序产品的形式，其中计算机可读程序代码包含在其中。

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

本申请各部分操作所需的计算机程序编码可以用任意一种或以上程序语言编写，包括面向主体编程语言如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)。

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

同理，应当注意的是，为了简化本申请披露的表述，从而帮助对一个或以上发明实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。然而，本申请的该方法不应被解释为反映所声称的待扫描对象物质需要比每个权利要求中明确记载的更多特征的意图。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

发明陈述

1、一种操作线上到线下服务平台的系统，包括：

至少一种包括用于组队的一组指令的存储介质、至少一个与所述至少一种存储介质通信的处理器。其中，当执行所述一组指令时，指导所述至少一个处理器执行包括以下的操作：

获得与至少两个待组队成员中的每一个有关的信息，所述至少两个成员包括至少一个队长和至少一个队员；以及

基于与所述至少两个成员有关的所述信息，自动将所述至少两个队员分配给所述至少两个队长，确定一个或以上的组队，其中所述一个或以上组队中的每一个组队包括一个队长和至少一个队员。

2、根据条目1所述的系统，其特征在于，确定所述一个或以上的组队，所述至少一个处理器执行附加操作，还包括：

基于所述至少两个队员的所述信息，确定所述至少两个队长和所述至少两个队员中的每一个之间的接收概率；

基于所述接收概率使用优化推荐算法，确定组队推荐方案；以及

基于所述组队推荐方案，确定所述一个或以上的组队。

3、根据条目2所述的系统，其特征在于，确定所述至少两个队长和所述至少两个队员中的每一个之间的所述接收概率，指导所述至少一个处理器执行附加操作，包括：

基于所述至少两个队员的信息，使用接收概率模型确定所述至少两个队长和所述至少两个队员中的每一个之间的所述接收概率。

4、根据条目3所述的系统，其特征在于，所述接收概率模型是基于与所述至少两个队长和所述至少两个队员有关的历史组队数据确定的。

5、根据条目4所述的系统，其特征在于，所述接收概率模型是使用逻辑回归算法确定的。

6、根据条目2-5中任一条目所述的系统，其特征在于，基于所述接收概率，使用所述优化推荐算法确定所述组队推荐方案，所述至少一个处理器还用于执行附加操作，包括：

确定一个或以上候选组队推荐方案中每个组队的预期成功概率；以及

指定与所述一个或以上候选组队推荐方案中的所述最大预期成功概率相对应的所述候选组队推荐方案作为所述组队推荐方案。

7、根据条目2-5中任一条目所述的系统，其特征在于，基于所述接收概率，使用所述优化推荐算法确定所述组队推荐方案，所述至少一个处理器还用于执行附加操作，包括：

确定组队的预期成功概率模型；以及

基于所述预期成功概率模型，使用所述优化推荐算法确定所述组队推荐方案。

8、根据条目1-7中任一条目所述的系统，其特征在于，确定所述一个或以上的组队，所述至少一个处理器执行附加操作，包括：

基于所述至少两个队长及所述至少两个队员的信息，确定所述至少两个队长和所述至少两个队员的每一个之间的匹配值；以及

基于所述匹配值，确定所述一个或以上的组队。

9、根据条目8所述的系统，其特征在于，确定所述至少两个队长和所述至少两个队员的每一个之间的所述匹配值，指导所述至少一个处理器执行附加操作，包括：

确定所述至少两个队长中的每一个的所述信息与所述至少两个队员中的每一个的所述信息之间的相似度；以及

基于所述至少两个队长中的每一个的所述信息与所述至少两个队员中的每一个的所述信息之间的所述相似度，确定所述至少两个队长和所述至少两个队员中的每一个之间的匹配值。

10、根据条目9所述的系统，其特征在于，所述相似度包括家乡相似度、年龄相似度和特征相似度。

11、根据条目10所述的系统，其特征在于，所述家乡相似度是基于家乡评价函数确定的，所述年龄相似度是基于年龄评价函数确定的，所述特征相似度基于特征评价函数确定。

12、根据条目10或11所述的系统，其特征在于，确定所述匹配值，指示所述至少一个处理器执行附加操作，包括：

基于所述家乡相似度确定第一子匹配值；

基于所述年龄相似度确定第二子匹配值；

基于所述特征相似度确定第三子匹配值；以及

基于所述第一子匹配值、所述第二子匹配值或所述第三子匹配值中的至少一个确定所述匹配值。

13、根据条目1所述的系统，其特征在于，确定所述一个或以上的组队，指示所述至少一个处理器执行附加操作，包括：

从所述至少两个待组队成员的所述信息中提取与所述至少两个队员有关的评价信息；

基于所述至少两个队员的每一个的所述评价信息，将所述至少两个队员的每一个分配给一个等级组；以及

基于与所述至少两个队员的每一个相关的所述等级组，确定所述一个或以上的组队。

14、根据条目13所述的系统，其特征在于，将所述至少两个队员中的每一个分配给等级组，指导所述至少一个处理器执行附加操作，包括：

获得分类模型；以及

基于所述评价信息，使用所述分类模型，确定与所述至少两个队员的每一个相关的等级组。

15、根据条目13或14所述的系统，其特征在于，与所述至少两个队员的一个队员相关的评价信息包括所述队员对所述线上到线下服务平台的评价信息。

16、根据条目15所述的系统，其特征在于，所述等级组包括推荐者组队、被动者组和贬损者组，并将所述至少两个队员分配给一个组，所述指导至少一个处理器执行附加操作，包括：

基于所述线上服务平台上所述队员的所述评价信息，将所述队员分配给推荐者组、被动者组，或贬损者组。

17、根据条目13或14所述的系统，其特征在于，与所述至少两个队员的一个队员有关的所述评价信息包括服务请求者提供的关于所述队员的评价信息。

18、根据条目17所述的系统，其特征在于，所述等级组包括优质服务组、一般服务组和较差服务组，并将所述至少两个队员的每一个分配给一个等级组，指导所述至少一个处理器执行附加操作，包括：

基于所述服务请求者提供的关于所述队员的评价信息，将所述队员分配给所述优质服务组、所述一般服务组，或所述较差服务组。

19、根据条目13-18中任一条目所述的系统，其特征在于，使所述至少一个处理器执行附加操作，包括：

将属于不同的等级组的一个或以上队员组成一个组队。

20、根据条目13-18中任一条目所述的系统，其特征在于，使所述至少一个处理器执行附加操作，包括：

将属于同一等级组的一个或以上队员组织成一个组队。

21、根据条目1所述的系统，其特征在于，所述确定所述一个或以上的组队，使所述至少一个处理器执行附加操作，包括：

从所述至少两个待组队成员的所述信息中提取与所述至少两个队员的每一个队员相关的历史订单信息；

基于与所述每个队员有关的所述历史订单信息，确定所述至少两个队员的每个队员的出车行为特征；

基于所述至少两个队员的每一个队员的所述出车行为特征，将所述至少两个队员分为一个或以上司机分组；以及

对于所述一个或以上司机分组中的每一个，形成至少一个组队。

22、根据条目21所述的系统，其特征在于，所述队员的出车行为特征包括所述队员的出车时间特征或所述队员的出车地域特征。

23、根据条目21或22所述的系统，其特征在于，所述将所述至少两个队员分成一个或以上司机分组，使所述至少一个处理器执行附加操作，包括：

确定每对所述至少两个队员之间的驾驶行为相似度；以及

基于每对所述至少两个队员之间的驾驶行为相似度，确定所述一个或以上司机分组。

24、根据条目21-23中任一条目所述的系统，其特征在于，所述司机分组中的每一个包括至少一个队长和至少一个队员，并为所述一个或以上司机分组成立至少一个组队，指示所述至少一个处理器执行附加操作，包括：

对于司机分组，将与所述至少一个所述司机分组队员有关的信息发送至所述司机分组的至少一个队长；

接收所述司机分组的至少一个队长对所述司机分组的至少一个队员的回复；以及基于至少一个所述司机分组队长的回复，为所述司机分组确定至少一个组队。

25、根据条目24所述的系统，其特征在于，所述与所述至少一个队员和所述响应有关的信息被加密，所述至少一个处理器还用于执行附加操作，包括：解密与所述至少一个队员有关的加密信息并解密所述加密的响应。

26、根据条目25所述的系统，其特征在于，所述解密与所述至少一个队员有关的加密信息，所述至少一个处理器还用于执行附加操作，包括：

在解密所述加密信息之前验证所述至少一个队员或所述至少一个队员的设备的认证信息，以及为了解密所述加密响应，所述至少一个处理器还用于执行附加操作，包括：

在解密所述加密响应之前，验证所述至少一个队长或所述至少一个队长的设备的认证信息。

27、根据条目1所述的系统，其特征在于，使所述至少一个处理器执行附加操作，包括：

通过所述至少两个待组队成员的装置的第一界面，接收报名指令；

确定所述报名指令的类型，其中所述报名指令的类型包括队长报名指令或队员报名指令；以及

响应于确定所述报名指令是一个队长报名指令，

从所述至少两个队员，识别一个或以上备选队员；

将所述一个或以上备选队员有关的用户信息显示在所述队员设备的第二界面上；以及

从所述队员设备接收所述一个或以上备选队员中的至少一个的选择；

向所述至少一个选定的备选队员发送加入组队的第一邀请；

接收对于所述第一次邀请的一个或以上回复；

基于所述收到的回复，确定至少一名同意加入所述组队的队员；

将同意加入所述组队的所述至少一个队员的有关的用户信息显示在所述队员设备的第三界面上。

28、根据条目27所述的系统，其特征在于，所述确定一个或以上备选队员，指导所述至少一个处理器执行附加操作，包括：

使所述设备显示个人信息设置界面；

通过所述个人信息设置界面，接收所述队员设置的用户信息；以及

基于所述队员设置的用户信息以及所述队长报名指令，确定所述一个或以上备选队员。

29、根据条目27或28所述的系统，其特征在于，所述至少一个处理器用于执行附加操作，包括：

确定同意加入所述组队的队员的数量；以及

响应于同意加入所述组队的队员的数量等于或超过预定值，

生成指示所述组队已成功成立的通知；

向所述至少一名队员发送所述通知；以及

使所述通知显示在所述设备的所述第三界面上。

30、根据条目29所述的系统，其特征在于，所述至少一个处理器还用于执行附加操作，包括：

加密所述通知；以及

向所述至少一个队员中的每一个发送所述加密通知。

31、根据条目30所述的系统，其特征在于，发送给所述至少一个队员之一的所述加密通知包括所述队员或所述队员设备的认证信息，以认证所述队员或所述队员设备。

32、根据条目27所述的系统，其特征在于，响应于确定所述报名指令是队员的报名指令，指导所述至少一个处理器执行附加操作，包括：

使所述设备显示个人信息设置界面；

通过所述个人信息设置界面，接收所述队员设置的用户信息；

基于所述队员的用户信息，从所述一个或以上队员中设别所述队员的队长；以及检测从所述队长收到的第二个邀请；以及

将所述第二邀请显示在所述设备的第四界面上。

33、根据条目32所述的系统，其特征在于，所述第二邀请被加密，并且所述至少一个处理器被进一步指示执行附加操作，包括：解密所述加密的第二邀请。

34、根据条目33所述的系统，其特征在于，所述解密所述加密的第二邀请，所述至少一个处理器还用于执行附加操作，包括：在所述解密之前，验证所述队员或所述队员设备的认证信息。

35、根据条目27-34中任一条目所述的系统，其特征在于，所述至少一个处理器还用于执行附加操作，包括：将所述报名指令的类型对应的活动信息显示在所述设备的第五界面上，其中所述活动信息包括职责信息、任务信息或奖励信息中的至少一个。

36、根据条目27-35中任一条目所述的系统，其特征在于，所述至少一个处理器还用于执行附加操作，包括：

加密所述第一邀请；以及

向所述至少一个选定的备选队员发送所述加密的第一邀请。

37、根据条目36所述的系统，其特征在于，发送给所述至少一个所选备选队员中的每一个的所述加密的第一邀请包括所述每个所选备选队员的认证信息或所述每个所选备选队员设备的认证信息，以认证所述每个所选备选队员或所述每个所选备选队员的所述设备。

38、一种用于操作在计算设备上实现的线上到线下服务平台的方法，所述计算设备具有至少一个处理器和包括用于确定组队的一组指令的至少一个存储介质，包括：

获得与至少两个待组队成员中的每一个相关的信息，所述至少两个成员包括至少一个队长和至少一个队员；以及

基于与所述至少两个队员有关的信息，自动将所述队员分配给所述队长，确定一个或以上的组队，其中所述一个或以上组队中的每一个包括一个队长和至少一个队员。

39、根据条目38的方法，其特征在于，所述确定所述一个或以上的组队包括：

基于所述队员的信息，确定所述队长和每一个所述队员之间的接收概率；

使用优化推荐算法基于所述接收概率，确定组队推荐方案；以及

基于所述组队推荐方案，确定所述一个或以上的组队。

40、根据条目39的方法，其特征在于，所述确定所述队长和所述队员中的每一个之间的所述接收概率包括：基于所述队员的所述信息，使用接收概率模型，确定所述队长和所述队员的每一个之间的所述接收概率。

41、根据条目40的方法，其特征在于，所述接收概率模型是根据与所述至少两个队长和所述至少两个队员有关的历史组队数据确定的。

42、根据条目41的方法，其特征在于，使用逻辑回归算法确定所述接收概率模型。

43、根据条目39-42中任一条目的方法，其特征在于，所述使用所述优化推荐算法，基于所述接收概率确定所述组队推荐方案包括：

确定一个或以上候选组队推荐方案中每个组队的预期成功概率；以及指定所述一个或以上候选组队推荐方案中的最大预期成功概率相对应的所述候选组队推荐方案作为所述组队推荐方案。

44、根据条目39-42中任一条目的方法，其特征在于，所述使用所述优化推荐算法，基于所述接收概率确定所述组队推荐方案，包括：

确定组队的预期成功概率模型；以及

使用所述优化推荐算法，基于所述预期成功概率模型确定所述组队推荐方案。

45、根据条目38-44中任一条目的方法，其特征在于，所述确定所述一个或以上的组队，包括：

基于与所述至少两个队长及所述至少两个队员有关的信息，确定所述至少两个队长与所述至少两个队员的每一个之间的匹配值；以及

基于所述匹配值确定所述一个或以上的组队。

46、根据条目45的方法，其特征在于，所述确定所述至少两个队长和所述至少两个队员的每一个之间的匹配值，包括：

确定所述至少两个队长中的每一个的信息与所述至少两个队员中的每一个的信息之间的相似度；以及

基于所述至少两个队长中的每一个的信息与所述至少两个队员中的每一个的信息之间的所述相似度，确定所述至少两个队长和所述至少两个队员的每一个之间的匹配值。

47、根据条目46的方法，其特征在于，所述相似度包括家乡相似度、年龄相似度和特征相似度。

48、根据条目47的方法，其特征在于，所述家乡相似度是基于家乡评价函数确定的，所述年龄相似度是基于年龄评价函数确定的，所述角色评价函数是基于特征相似度确定的。

49、根据条目47或48的方法，其特征在于，所述确定匹配值包括：

基于所述家乡相似度确定第一子匹配值；

基于所述年龄相似度确定第二子匹配值；

基于所述特征相似度确定第三子匹配值；以及

基于所述第一子匹配值、所述第二子匹配值或所述第三子匹配值中的至少一个确定所述匹配值。

50、根据条目38的方法，其特征在于，所述确定所述一个或以上的组队包括：

从所述至少两个待组队成员的所述信息中提取与所述至少两个队员有关的评价信息；

基于所述至少两个队员的每一个的所述评价信息，将所述至少两个队员的每一个分配给一个等级组；以及

基于与所述至少两个队员的每一个相关的所述等级组，确定所述一个或以上的组队。

51、根据条目50的方法，其特征在于，所述将所述至少两个队员中的每一个分配给等级组包括：

获得分类模型；以及

基于所述评价信息，使用所述分类模型，确定与所述至少两个队员的每一个相关的等级组。

52、根据条目50或51的方法，其特征在于，与所述至少两个队员的一个队员相关的评价信息包括所述队员对所述线上到线下服务平台的评价信息。

53、根据条目52的方法，其特征在于，所述等级组包括推荐者组队、被动者组和贬损者组，并将所述至少两个队员分配给一个组，所述方法还包括：基于所述线上服务平台上所述队员的所述评价信息，将所述队员分配给推荐者组、被动者组，或贬损者组。

54、根据条目50或51的方法，其特征在于，与所述至少两个队员的一个队员有关的所述评价信息包括服务请求者提供的关于所述队员的评价信息。

55、根据条目54的方法，其特征在于，所述等级组包括优质服务组、一般服务组和较差服务组，并将所述至少两个队员的每一个分配给一个等级组，所述方法还包括：基于所述服务请求者提供的关于所述队员的评价信息，将所述队员分配给所述优质服务组、所述一般服务组，或所述较差服务组。

56、根据条目50-55中任一条目的方法，其特征在于，所述方法还包括：将属于不同的等级组的一个或以上队员组成一个组队。

57、根据条目50-55中任一条目的方法，其特征在于，所述方法还包括：将属于同一等级组的一个或以上队员组织成一个组队。

58、根据条目38的方法，其特征在于，所述确定所述一个或以上的组队包括：

从所述至少两个待组队成员的所述信息中提取与所述至少两个队员的每一个队员相关的历史订单信息；

基于与所述每个队员有关的所述历史订单信息，确定所述至少两个队员的每个队员的出车行为特征；

基于所述至少两个队员的每一个队员的所述出车行为特征，将所述至少两个队员分为一个或以上司机分组；以及

对于所述一个或以上司机分组中的每一个，形成至少一个组队。

59、根据条目58的方法，其特征在于，所述队员的出车行为特征包括所述队员的出车时间特征或所述队员的出车地域特征。

60、根据条目58或59的方法，其特征在于，所述将所述至少两个队员分成一个或以上司机分组包括：

确定每对所述至少两个队员之间的驾驶行为相似度；以及

基于每对所述至少两个队员之间的驾驶行为相似度，确定所述一个或以上司机分组。

61、根据条目58-60中任一条目的方法，其特征在于，所述司机分组中的每一个包括至少一个队长和至少一个队员，并为所述一个或以上司机分组成立至少一个组队，包括：

对于司机分组，

将与所述至少一个所述司机分组队员有关的信息发送至所述司机分组的至少一个队长；

接收所述司机分组的至少一个队长对所述司机分组的至少一个队员的回复；以及

基于至少一个所述司机分组队长的回复，为所述司机分组确定至少一个组队。

62、根据条目61的方法，其特征在于，所述与所述至少一个队员和所述响应有关的信息被加密，该方法还包括：解密与所述至少一个队员有关的加密信息并解密所述加密的响应。

63、根据条目62的方法，其特征在于，所述解密与所述至少一个队员有关的加密信息包括：

在解密所述加密信息之前验证所述至少一个队员或所述至少一个队员的设备的认证信息，以及

为了解密所述加密响应，所述至少一个处理器还用于执行附加操作，包括：

在解密所述加密响应之前，验证所述至少一个队长或所述至少一个队长的设备的认证信息。

64、根据条目38的方法，其特征在于，所述方法进一步包括：

通过所述至少两个待组队成员的装置的第一界面，接收报名指令；

确定所述报名指令的类型，其中所述报名指令的类型包括队长报名指令或队员报名指令；以及

响应于确定所述报名指令是一个队长报名指令，

从所述至少两个队员，识别一个或以上备选队员；

将所述一个或以上备选队员有关的用户信息显示在所述队员设备的第二界面上；以及

从所述队员设备接收所述一个或以上备选队员中的至少一个的选择；

向所述至少一个选定的备选队员发送加入组队的第一邀请；

接收对于所述第一次邀请的一个或以上回复；

基于所述收到的回复，确定至少一名同意加入所述组队的队员；

将同意加入所述组队的所述至少一个队员的有关的用户信息显示在所述队员设备的第三界面上。

65、根据条目64的方法，其特征在于，所述识别一个或以上备选队员包括：

使所述设备显示个人信息设置界面；

使所述设备显示个人信息设置界面；

通过所述个人信息设置界面，接收所述队员设置的用户信息；以及

基于所述队员设置的用户信息以及所述队长报名指令，确定所述一个或以上备选队员。

66、根据条目64或65的方法，其特征在于，所述方法还包括：

确定同意加入所述组队的队员的数量；以及

响应于同意加入所述组队的队员的数量等于或超过预定值，

生成指示所述组队已成功成立的通知；

向所述至少一名队员发送所述通知；以及

使所述通知显示在所述设备的所述第三界面上。

67、根据条目66的方法，其特征在于，所述方法还包括：

加密所述通知；以及

向所述至少一个队员中的每一个发送所述加密通知。

68、根据条目67的方法，其特征在于，发送给所述至少一个队员之一的所述加密通知包括所述队员或所述队员设备的认证信息，以认证所述队员或所述队员设备。

69、根据条目64所述的方法，其特征在于，响应于确定所述报名指令是队员的报名指令，指导所述至少一个处理器执行附加操作，包括：

使所述设备显示个人信息设置界面；

通过所述个人信息设置界面，接收所述队员设置的用户信息；

基于所述队员的用户信息，从所述一个或以上队员中设别所述队员的队长；以及检测从所述队长收到的第二个邀请；以及

将所述第二邀请显示在所述设备的第四界面上。

70、根据条目69的方法，其特征在于，所述第二邀请被加密，并且所述方法还包括：解密所述加密的第二邀请。

71、根据条目70所述的方法，其特征在于，所述解密所述加密的第二邀请包括：在所述解密之前，验证所述队员或所述队员设备的认证信息。

72、根据条目64-71中任一条目所述的方法，其特征在于，所述方法还包括：将所述报名指令的类型对应的活动信息显示在所述设备的第五界面上，其中所述活动信息包括职责信息、任务信息或奖励信息中的至少一个。

73、根据条目64-72中任一条目所述的方法，其特征在于，所述方法还包括：

加密所述第一邀请；以及

向所述至少一个选定的备选队员发送所述加密的第一邀请。

74、根据条目73所述的方法，其特征在于，发送给所述至少一个所选备选队员中的每一个的所述加密的第一邀请包括所述每个所选备选队员的认证信息或所述每个所选备选队员设备的认证信息，以认证所述每个所选备选队员或所述每个所选备选队员的所述设备。

75、一种非暂时性计算机可读存储介质，其包括计算机程序产品，所述计算机程序产品包括指令，所述用于使计算设备：

获得与至少两个待组队成员中的每一个有关的信息，所述至少两个成员包括至少一个队长和至少一个队员；以及

基于与所述至少两个队员有关的所述信息，自动将所述至少两个队员分配给所述至少两个队长，确定一个或以上的组队，其中所述一个或以上组队中的每一个组队包括一个队长和至少一个队员。

Claims (61)

1.一种组队推荐方法，其特征在于，包括：

基于至少两个待组队队长信息和至少两个待组队成员信息，确定所述至少两个待组队队长和所述至少两个待组队成员之间的接收概率；

基于所述至少两个待组队队长和所述至少两个待组队成员之间的接收概率，根据优化推荐算法确定组队推荐方案；

根据所述组队推荐方案进行组队推荐。

2.如权利要求1所述的组队推荐方法，其特征在于，所述至少两个待组队队长信息和所述至少两个待组队成员信息包括自然属性信息、社会属性信息或习惯属性信息。

3.如权利要求1所述的组队推荐方法，其特征在于，所述确定所述至少两个待组队队长和所述至少两个待组队成员之间的接收概率包括：

根据接收概率模型确定所述至少两个待组队队长和所述至少两个待组队成员之间的接收概率。

4.如权利要求3所述的组队推荐方法，其特征在于，所述接收概率模型基于历史组队数据训练获得。

5.如权利要求1所述的组队推荐方法，其特征在于，所述确定所述至少两个待组队队长和所述至少两个待组队成员之间的接收概率包括：

确定每个待组队队长和每个待组队成员之间的接收概率。

6.如权利要求5所述的组队推荐方法，其特征在于，所述根据优化推荐算法确定组队推荐方案包括：

确定多个组队推荐备选方案的期望组队成功率；

确定期望组队成功率最大的组队推荐备选方案为所述组队推荐方案。

7.如权利要求1所述的组队推荐方法，其特征在于，所述根据优化推荐算法确定组队推荐方案包括：

建立组队成功率期望模型；

基于组队成功率期望模型，根据组合优化算法确定组队推荐方案。

8.如权利要求1所述的组队推荐方法，其特征在于，所述根据优化推荐算法确定组队推荐方案包括：

确定在不同接收意向状态下组队成功的概率的总和；

确定使得所述总和最大的组队推荐备选方案为所述组队推荐方案；

所述接收意向状态包括每个待组队队长与每个待组队成员之间的接收意向。

9.一种组队推荐系统，其特征在于，包括：接收概率确定模块、推荐方案确定模块和组队推荐模块；

所述接收概率确定模块用于基于至少两个待组队队长信息和至少两个待组队成员信息，确定所述至少两个待组队队长和所述至少两个待组队成员之间的接收概率；

所述推荐方案确定模块用于基于所述至少两个待组队队长和所述至少两个待组队成员之间的接收概率，根据优化推荐算法确定组队推荐方案；

所述组队推荐模块用于根据所述组队推荐方案进行组队推荐。

10.如权利要求9所述的组队推荐系统，其特征在于，所述接收概率确定模块进一步用于：根据接收概率模型确定所述至少两个待组队队长和所述至少两个待组队成员之间的接收概率。

11.如权利要求9所述的组队推荐系统，其特征在于，所述接收概率确定模块进一步用于：确定每个待组队队长和每个待组队成员之间的接收概率。

12.如权利要求9所述的组队推荐系统，其特征在于，所述推荐方案确定模块进一步用于：

确定多个组队推荐备选方案的期望组队成功率；

确定期望组队成功率最大的组队推荐备选方案为所述组队推荐方案。

13.如权利要求9所述的组队推荐系统，其特征在于，所述推荐方案确定模块进一步用于：

建立组队成功率期望模型；

基于组队成功率期望模型，根据组合优化算法确定组队推荐方案。

14.如权利要求9所述的组队推荐系统，其特征在于，所述推荐方案确定模块进一步用于：

确定在不同接收意向状态下组队成功的概率的总和；

确定使得所述总和最大的组队推荐备选方案为所述组队推荐方案；

所述接收意向状态包括每个待组队队长与每个待组队成员之间的接收意向。

15.一种组队方法，其特征在于，包括：

基于待组队成员的信息，确定所述待组队成员之间的匹配值；

基于所述待组队成员之间的匹配值，对所述待组队成员进行组队。

16.如权利要求15所述的组队方法，其特征在于，所述基于待组队成员的信息，确定所述待组队成员之间的匹配值包括：

基于所述待组队成员的信息之间的相似度，确定所述待组队成员之间的匹配值。

17.如权利要求16所述的组队方法，其特征在于，所述待组队成员的信息之间的相似度越大，所述待组队成员之间的匹配值越大。

18.如权利要求16所述的组队方法，其特征在于，所述基于所述待组队成员的信息之间的相似度，确定所述待组队成员之间的匹配值包括：

基于匹配值的第一组件、第二组件或第三组件中的一个或多个的组合，确定所述待组队成员之间的匹配值；

其中，所述匹配值的第一组件基于所述待组队成员的家乡信息之间的相似度确定；

匹配值的第二组件基于所述待组队成员的年龄信息之间的相似度确定；

匹配值的第三组件基于所述待组队成员的性格信息之间的相似度确定。

19.如权利要求15所述的组队方法，其特征在于，所述待组队成员包括待组队队长和待组队成员；

所述基于待组队成员的信息，确定所述待组队成员之间的匹配值包括：

基于待组队队长的信息和待组队成员的信息，确定每个待组队队长和每个待组队成员之间的匹配值。

20.如权利要求19所述的组队方法，其特征在于，所述基于所述至少两个待组队队长的信息和至少两个待组队成员的信息，确定每个待组队队长和每个待组队成员之间的匹配值包括：

基于评价函数，确定所述每个待组队队长和每个待组队成员之间的匹配值。

21.如权利要求15所述的组队方法，其特征在于，所述基于所述待组队成员之间的匹配值，对所述待组队成员进行组队包括：

基于所述待组队成员之间的匹配值将所述待组队成员组成至少一个队伍，且所述至少一个队伍的总匹配值之和最大；

其中，队伍的总匹配值反映该队伍成员匹配值总和的大小。

22.如权利要求21所述的组队方法，其特征在于，每个队伍包括一名队长和至少两个队员，所述队伍的总匹配值为所述一名队长与每个队员的匹配值之和。

23.一种组队系统，其特征在于，包括：匹配值确定模块和组队模块；

所述匹配值确定模块用于基于待组队成员的信息，确定所述待组队成员之间的匹配值；

所述组队模块用于基于所述待组队成员之间的匹配值，对所述待组队成员进行组队。

24.如权利要求23所述的组队系统，其特征在于，所述匹配值确定模块进一步用于：

基于所述待组队成员的信息之间的相似度，确定所述待组队成员之间的匹配值。

25.如权利要求24所述的组队系统，其特征在于，所述待组队成员的信息之间的相似度越大，所述待组队成员之间的匹配值越大。

26.如权利要求24所述的组队系统，其特征在于，所述匹配值确定模块进一步用于：

基于匹配值的第一组件、第二组件或第三组件中的一个或多个的组合，确定所述待组队成员之间的匹配值；

其中，所述匹配值的第一组件基于所述待组队成员的家乡信息之间的相似度确定；

匹配值的第二组件基于所述待组队成员的年龄信息之间的相似度确定；

匹配值的第三组件基于所述待组队成员的性格信息之间的相似度确定。

27.如权利要求23所述的组队系统，其特征在于，所述待组队成员包括待组队队长和待组队成员；

所述匹配值确定模块进一步用于：

基于待组队队长的信息和待组队成员的信息，确定每个待组队队长和每个待组队成员之间的匹配值。

28.如权利要求23所述的组队系统，其特征在于，所述组队模块进一步用于：

基于所述待组队成员之间的匹配值将所述待组队成员组成至少一个队伍，且所述至少一个队伍的总匹配值之和最大；

其中，队伍的总匹配值反映该队伍成员匹配值总和的大小。

29.如权利要求28所述的组队系统，其特征在于，每个队伍包括一名队长和至少两个队员，所述队伍的总匹配值为所述一名队长与每个队员的匹配值之和。

30.一种组队方法，其特征在于，包括：

根据待组队成员的评价信息，确定所述待组队成员的等级组；

根据所述待组队成员的等级组对所述待组队成员进行组队。

31.如权利要求30所述的组队方法，其特征在于，所述确定所述待组队成员的等级组包括：基于所述待组队成员的评价信息，使用分类模型确定待组队成员的等级组。

32.如权利要求30所述的组队方法，其特征在于，所述待组队成员为司机。

33.如权利要求32所述的组队方法，其特征在于，所述待组队成员的评价信息包括司机对网约车平台的评价信息。

34.如权利要求33所述的组队方法，其特征在于，所述确定所述待组队成员的等级组包括：根据司机对网约车平台的评价信息，确定司机属于推荐者组、被动者组或贬损者组。

35.如权利要求32所述的组队方法，其特征在于，所述待组队成员的评价信息包括乘客对司机的评价信息。

36.如权利要求35所述的组队方法，其特征在于，所述确定所述待组队成员的等级组包括：根据乘客对司机的评价信息，确定司机属于优质服务组、一般服务组或较差服务组。

37.如权利要求30所述的组队方法，其特征在于，所述根据所述待组队成员的等级组进行组队包括：

将不同等级组的待组队成员组成一队。

38.如权利要求30所述的组队方法，其特征在于，所述根据所述待组队成员的等级组进行组队包括：

将相同等级组的待组队成员组成一队。

39.一种组队系统，其特征在于，包括：等级组确定模块和组队模块；

所述等级组确定模块用于根据待组队成员的评价信息，确定所述待组队成员的等级组；

所述组队模块用于根据所述待组队成员的等级组对所述待组队成员进行组队。

40.如权利要求39所述的组队系统，其特征在于，所述等级组确定模块进一步用于：基于所述待组队成员的评价信息，使用分类模型确定待组队成员的等级组。

41.如权利要求39所述的组队系统，其特征在于，所述待组队成员为司机。

42.如权利要求41所述的组队系统，其特征在于，所述待组队成员的评价信息包括司机对网约车平台的评价信息。

43.如权利要求42所述的组队系统，其特征在于，所述等级组确定模块进一步用于：根据司机对网约车平台的评价信息，确定司机属于推荐者组、被动者组或贬损者组。

44.如权利要求41所述的组队系统，其特征在于，所述待组队成员的评价信息包括乘客对司机的评价信息。

45.如权利要求44所述的组队系统，其特征在于，所述等级组确定模块进一步用于：根据乘客对司机的评价信息，确定司机属于优质服务组、一般服务组或较差服务组。

46.一种基于出车行为的司机组队方法，其特征在于，包括：

获取历史订单信息，所述是历史订单信息至少包括：司机信息、接单时间和接单位置；

根据所述历史订单信息，计算每个司机的出车行为特征；

根据所述每个司机的出车行为特征对司机进行分组，生成至少两个司机分组；

将每个司机分组内的司机组成至少一个司机团队。

47.根据权利要求46所述的方法，其特征在于，所述根据所述历史订单信息，计算每个司机的出车行为特征，包括：

根据所述历史订单信息，计算每个司机的出车时间特征和/或出车地域特征；

所述出车时间特征包括：接单时间在一天内的至少一个第一预设时段内的分布信息，和/或，接单时间在一周内的至少一个第二预设时段内的分布信息；

所述出车地域特征包括：接单位置在预设地域范围内的至少一个预设区域内的分布信息。

48.根据权利要求46所述的方法，其特征在于，所述根据所述每个司机的出车行为特征对司机进行分组，生成至少两个司机分组，包括：

根据所述每个司机的出车行为特征，计算每两个司机的出车行为相似度；

根据所述每两个司机的出车行为相似度对司机进行分组，生成至少两个司机分组。

49.根据权利要求46-48任一项所述的方法，其特征在于，所述将每个司机分组内的司机组成至少一个司机团队，包括：

获取司机分组内每个司机的角色，所述司机的角色包括队长和队员；

将同一司机分组内的队员信息推送给队长，以使队长反馈入队结果，所述入队结果包括队长标识和成功加入的队员标识；

接收所述队长反馈的入队结果；

根据所述入队结果，将所述入队结果中成功加入的队员标识对应的司机添加到所述队长标识对应的司机团队中。

50.一种基于出车行为的司机组队装置，其特征在于，包括：

获取模块，用于获取历史订单信息，所述是历史订单信息至少包括：司机信息、接单时间和接单位置；

计算模块，用于根据所述历史订单信息，计算每个司机的出车行为特征；

分组模块，用于根据所述每个司机的出车行为特征对司机进行分组，生成至少两个司机分组；

组队模块，用于将每个司机分组内的司机组成至少一个司机团队。

51.根据权利要求50所述的装置，其特征在于，所述计算模块还用于：

根据所述历史订单信息，计算每个司机的出车时间特征和/或出车地域特征；

所述出车时间特征包括：接单时间在一天内的至少一个第一预设时段内的分布信息，和/或，接单时间在一周内的至少一个第二预设时段内的分布信息；

所述出车地域特征包括：接单位置在预设地域范围内的至少一个预设区域内的分布信息。

52.根据权利要求50所述的装置，其特征在于，所述分组模块还用于：

根据所述每个司机的出车行为特征，计算每两个司机的出车行为相似度；

根据所述每两个司机的出车行为相似度对司机进行分组，生成至少两个司机分组。

53.根据权利要求50-52任一项所述的装置，其特征在于，所述组队模块还用于：

获取司机分组内每个司机的角色，所述司机的角色包括队长和队员；

将同一司机分组内的队员信息推送给队长，以使队长反馈入队结果，所述入队结果包括队长标识和成功加入的队员标识；

接收所述队长反馈的入队结果；

根据所述入队结果，将所述入队结果中成功加入的队员标识对应的司机添加到所述队长标识对应的司机团队中。

54.一种司机团队的组队方法，其特征在于，包括：

接收用户在第一界面上输入的报名指令，所述报名指令为队长报名指令或者队员报名指令；

判断所述报名指令的种类，若所述报名指令的种类为队长报名指令，则根据所述队长报名指令生成备选队员获取请求发送给向服务器，并将所述服务器根据所述备选队员获取请求返回的多个备选队员的用户信息显示于第二界面上；

接收所述用户在所述第二界面选择任一所述备选队员的操作指令后，向所述备选队员发送邀请信息，所述邀请信息为预设信息或所述用户输入的信息，并在所述备选队员接受邀请后于第三界面上显示已接受邀请的备选队员的用户信息。

55.根据权利要求54所述的方法，其特征在于，所述根据所述队长报名指令生成备选队员获取请求发送给向服务器前，还包括：

显示个人信息设置界面，并接收所述用户在所述个人信息设置界面上输入的用户信息，所述用户信息包括行为习惯信息和/或自然属性信息；

所述根据所述队长报名指令生成备选队员获取请求发送给向服务器，具体包括：

根据所述队长报名指令和所述用户的用户信息生成所述备选队员获取请求，其中所述备选队员获取请求携带所述用户的用户信息；

将所述备选队员获取请求发送给所述服务器，以使所述服务器根据所述用户的用户信息匹配备选队员。

56.根据权利要求54所述的方法，其特征在于，还包括：

若所述报名指令的种类为队员报名指令，则显示个人信息设置界面；

接收所述用户在所述个人信息设置界面上输入的用户信息，所述用户信息包括行为习惯信息和/或自然属性信息；

根据所述队员报名指令和所述用户的用户信息生成组队匹配请求并发送给所述服务器，以使所述服务器根据所述用户的用户信息将所述用户匹配给某一队长，并在接收到所述队长发送的所述邀请信息后将所述邀请信息显示于第四界面。

57.根据权利要求54所述的方法，其特征在于，还包括：

判断已接受邀请的备选队员的数量是否达到预设数量，若达到，则生成组队完成提示信息；

将所述组队完成提示信息发送给每一所述已接受邀请的备选队员，并同时将所述组队完成提示信息显示于所述第三界面上。

58.一种司机团队的组队装置，其特征在于，包括：

报名模块，用于接收用户在第一界面上输入的报名指令，所述报名指令为队长报名指令或者队员报名指令；

处理模块，用于判断所述报名指令的种类，若所述报名指令的种类为队长报名指令，则根据所述队长报名指令生成备选队员获取请求发送给向服务器，并将所述服务器根据所述备选队员获取请求返回的多个备选队员的用户信息显示于第二界面上；

邀请模块，用于接收所述用户在所述第二界面选择任一所述备选队员的操作指令后，向所述备选队员发送邀请信息，所述邀请信息为预设信息或所述用户输入的信息，并在所述备选队员接受邀请后于第三界面上显示已接受邀请的备选队员的用户信息。

59.根据权利要求58所述的装置，其特征在于，还包括：

设置模块，用于显示个人信息设置界面，并接收所述用户在所述个人信息设置界面上输入的用户信息，所述用户信息包括行为习惯信息和/或自然属性信息；

所述处理模块具体用于：

根据所述队长报名指令和所述用户的用户信息生成所述备选队员获取请求，其中所述备选队员获取请求携带所述用户的用户信息；

将所述备选队员获取请求发送给所述服务器，以使所述服务器根据所述用户的用户信息匹配备选队员。

60.根据权利要求58所述的装置，其特征在于，所述处理模块还用于：

若所述报名指令的种类为队员报名指令，则驱动设置模块显示个人信息设置界面，接收所述用户在所述个人信息设置界面上输入的用户信息，所述用户信息包括行为习惯信息和/或自然属性信息；

根据所述队员报名指令和所述用户的用户信息生成组队匹配请求并发送给所述服务器，以使所述服务器根据所述用户的用户信息将所述用户匹配给某一队长，并在接收到所述队长发送的所述邀请信息后将所述邀请信息显示于第四界面。

61.根据权利要求58所述的装置，其特征在于，所述邀请模块还用于：

判断已接受邀请的备选队员的数量是否达到预设数量，若达到，则生成组队完成提示信息；

将所述组队完成提示信息发送给每一所述已接受邀请的备选队员，并同时将所述组队完成提示信息显示于所述第三界面上。

Images