CN106209396B

CN106209396B - 匹配方法及相关装置

Info

Publication number: CN106209396B
Application number: CN201610513406.9A
Authority: CN
Inventors: 陈凯斌
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2016-06-30
Filing date: 2016-06-30
Publication date: 2018-10-19
Anticipated expiration: 2036-06-30
Also published as: CN106209396A

Abstract

本发明实施例提供匹配方法及相关装置，以解决现有方式中多人通信组的发起依靠用户请求，组内成员局限于联系人名单的问题。该方法包括采集多个用户的预约信息，该预约信息包括预约的通话主题、通话开始时间和通话持续时长中的任意一种或任意组合；将预约信息相匹配的用户归入同一由服务器端创建的通信组；在所述通信组对应的预设时间区间内，建立所述通信组中各用户之间的通信连接。本发明实施例，可由服务器端创建通信组，组内的成员是预约信息相匹配的用户，而不再局限于联系人名单，为多人通话提供了新方式。

Description

匹配方法及相关装置

技术领域

本发明涉及计算机技术领域，具体涉及匹配方法及相关装置。

背景技术

在现有方式中，用户使用平台(例如社交平台、直播平台)组建通信组时，是由某一用户作为发起者，建立通信组，加入通信组的成员是由发起者从联系人名单中选出，或者，由已属于该组的成员从其联系人名单中选出。通信组中的成员可进行多人语音通话、多人视频通话，以及传输文件等。

例如，通过微信平台，用户可从其通信录中勾选好友来建立微信群，被选中的好友将被拉入该用户建立的微信群中。之后，微信群中的成员还可选择将自己的好友拉入微信群。

上述方式的缺点是：通信组的发起依靠用户请求，组内成员局限于联系人名单。

发明内容

有鉴于此，本发明实施例提供一种多人会话组匹配方法及相关装置，以解决现有方式中多人通信组的发起依靠用户请求，组内成员局限于联系人名单的问题。

为实现上述目的，本发明实施例提供如下技术方案：

一种匹配方法，应用于服务器端，所述方法包括：

采集用户的预约信息，所述预约信息包括预约的通话主题、通话开始时间和通话持续时长中的任意一种或任意组合；

在预设时间区间内，建立预约信息相匹配的用户之间的通信连接，以便所述预约信息相匹配的用户进行多人通话；所述预设时间区间中包含用户预约的通话开始时间。

一种匹配方法，所述方法包括：

生成并发送预约信息，所述预约信息包括用户预约的通话主题、通话开始时间和通话持续时长中的任意一种或任意组合；

判断是否到达所述通话开始时间；

在判断出到达所述通话开始时间时，发送通信请求消息，以便服务器端为发送了通信请求消息且预约信息与之相匹配的用户之间建立通信连接，进行多人通话。

一种匹配装置，应用于服务器端，所述匹配装置包括：

通信单元，用于采集用户的预约信息，所述预约信息包括预约的通话主题、通话开始时间和通话持续时长中的任意一种或任意组合；

处理单元，用于在预设时间区间内，建立预约信息相匹配的用户之间的通信连接，以便所述预约信息相匹配的用户进行多人通话；所述预设时间区间中包含用户预约的通话开始时间。

一种匹配装置，应用于终端，所述匹配装置包括：

通信模块，用于生成并发送预约信息，所述预约信息包括用户预约的通话主题、通话开始时间和通话持续时长中的任意一种或任意组合；

处理模块，用于：

判断是否到达所述通话开始时间；在判断出到达所述通话开始时间时，发送通信请求消息，以便服务器端为发送了通信请求消息且预约信息与之相匹配的用户之间建立通信连接，进行多人通话。

一种服务器，包括：

一种终端，包括：

处理模块，用于：

基于上述技术方案，本发明实施例，可由服务器端根据预约信息匹配用户，为预约信息相匹配的用户建立通信连接，预约信息相匹配且建立通信连接的用户，对应同一通信组。因此，在本发明实施例中，不再依靠用户发起通信组，相互通信的用户是预约信息相匹配的用户，而不再局限于联系人名单，为多人通话提供了新方式。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图2a、2b、4、6-8、12为本发明实施例提供的匹配方法示例性流程图；

图3、5、9、10a、10b、11、14-16、17a、17b、18a、18b为本发明实施例提供的交互界面示例图；

图13为本发明实施例提供的受助者申请方式示意图；

图19、20为本发明实施例提供的匹配装置的示例性结构图；

图1为本发明实施例提供的终端/服务器的计算机架构示例图。

具体实施方式

本发明提供匹配方法、匹配装置、终端和服务器/平台。

上述匹配装置可包括运行于终端中的匹配装置和运行于后台服务器/平台中的匹配装置。

上述终端可以是诸如台式机、移动终端(例如智能手机)、ipad等的电子设备。在一个示例中，运行于终端中的匹配装置可为运行在终端中的客户端，例如微信、QQ等即时通信客户端。该客户端可以是应用程序客户端，也可以是网页客户端。

运行于后台服务器/平台中的匹配装置可为服务器/平台的一个硬件组成部分，也可为功能模块或组件。

上述后台服务器或平台可以是一台服务器，也可以是由若干台服务器组成的服务器集群，或者是一个云计算服务中心。

图1示出了上述任一服务器或终端的一种通用计算机系统结构。

上述计算机系统可包括总线、处理器1、存储器2、通信接口3、输入设备4和输出设备5。处理器1、存储器2、通信接口3、输入设备4和输出设备5通过总线相互连接。其中：

总线可包括一通路，在计算机系统各个部件之间传送信息。

处理器1可以是通用处理器，例如通用中央处理器(CPU)、网络处理器(NetworkProcessor，简称NP)、微处理器等，也可以是特定应用集成电路(application-specificintegrated circuit，ASIC)，或一个或多个用于控制本发明方案程序执行的集成电路。还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

处理器1可包括主处理器，还可包括基带芯片、调制解调器等。

存储器2中保存有执行本发明技术方案的程序，还可以保存有操作系统和其他关键业务。具体地，程序可以包括程序代码，程序代码包括计算机操作指令。更具体的，存储器2可以包括只读存储器(read-only memory，ROM)、可存储静态信息和指令的其他类型的静态存储设备、随机存取存储器(random access memory，RAM)、可存储信息和指令的其他类型的动态存储设备、磁盘存储器、flash等等。

输入设备4可包括接收用户输入的数据和信息的装置，例如键盘、鼠标、摄像头、扫描仪、光笔、语音输入装置、触摸屏、计步器或重力感应器等。

输出设备5可包括允许输出信息给用户的装置，例如显示屏、打印机、扬声器等。

通信接口3可包括使用任何收发器一类的装置，以便与其他设备或通信网络通信，如以太网，无线接入网(RAN)，无线局域网(WLAN)等。

处理器1执行存储器2中所存放的程序，以及调用其他设备，可用于实现本发明实施例所提供的匹配方法中的各个步骤。

下面将基于上面的本发明涉及的共性方面，对本发明实施例进一步详细说明。

本发明的一个实施例提供一种匹配方法，和基于这个方法的服务器端。

请参见图2a，上述服务器端至少执行如下步骤：

S1：采集用户的预约信息；

预约信息具体可包括预约的通话主题、通话开始时间和通话持续时长中的任意一种或任意组合。

S2：在预设时间区间内，建立预约信息相匹配的用户之间的通信连接，以便预约信息相匹配的用户进行多人通话。

其中，预设时间区间中包含用户预约的通话开始时间。

本发明实施例，可由服务器端根据预约信息匹配用户，为预约信息相匹配的用户建立通信连接。预约信息相匹配且建立通信连接的用户，对应同一通信组。因此，在本发明实施例中，不再依靠用户发起通信组，相互通信的用户是预约信息相匹配的用户，而不再局限于联系人名单，为多人通话提供了新方式。

图2b示出了上述匹配方法的另一种交互示例性流程，其至少可包括如下步骤：

200部分：客户端/终端生成并发送用户的预约信息。

客户端/终端可应服务器/平台的主动获取而生成预约信息，也可由使用者主动触发客户端/终端生成并发送用户的预约信息。

需要说明的是，使用者与用户是不同的。使用者指的是自然人。而用户指的是使用者在服务器/平台上注册的账号。

在一个示例中，用户可通过用户身份唯一标识来区分。例如，在微信系统中，可用uin来区分用户。

预约信息具体可包括预约的通话主题、通话开始时间和通话持续时长中的任意一种或任意组合。客户端/终端也会记录用户的预约信息，尤其是通话开始时间。

在一个示例中，预约信息还可包括日期或其他预约事项，例如语音聊天、视频聊天。此外，预约信息还可包括用户唯一身份标识，例如uin等。

在另一示例中，用户还可设置在到达通话开始时间之时或之前是否进行提醒。

201部分：服务器/平台采集用户的预约信息。

更具体的，一种采集方式可为服务器/平台中的匹配装置主动获取用户的预约信息。或者，也可由用户主动提交预约信息，服务器/平台中的匹配装置予以记录的方式实现预约信息的采集。

上述通话主题可由服务器/平台以选项的方式提供给用户，用户从服务器/平台提供的选项中进行单选或复选。

当然，用户也可直接提交自己感兴趣的主题，由服务器/平台进行归类。

例如，用户可提交“艾灸”的通信主题，服务器/平台将其归类为“养生调理”这一大类。

举例来讲，微信公益提供多个公益活动，例如暖心读书项目、端午节送关爱项目、心理开导课程、养生调理项目等，某一用户可在线申请参与其中的公益活动(假定是暖心读书项目)，并提交参与时间(假定是17：00)和参与时长(假定15分钟)。

则服务器/平台可采集到该用户的预约信息包括：暖心读书项目的名称或标识，通话开始时间(17：00)，以及，通话持续时长(15min)。

202部分：服务器端将预约信息相匹配的用户归入同一由服务器端自动创建的通信组；

服务器端如何自动创建通信组可参见本文后续702部分的记载。

服务器端可在预设时间区间内自动创建通信组，也可提前创建通信组。

服务器端可创建临时的通信组，也可创建永久性的通信组。在该通信组中的用户与其他用户的预约信息是相匹配的。

在一个示例中，预约信息相匹配，可指的是预约信息完全相同。

在另一个示例中，预约信息相匹配，可指的是预约信息相一致。例如，主题一致，通话开始时间和通话持续时长一致。

举例来讲，用户1预约的主题是“艾灸”，用户2预约的主题是“针灸”，二者主题一致。

再例如，用户1预约的通话开始时间为11：00，用户2预约的通话开始时间为11：02，则二者通话开始时间相一致。

以此可类推至通话持续时长。

在同一通信组中的用户可进行多人通话，例如多人语音通话，多人视频通话，传输文件、共享文件等。

当然，也可进行点对点语音通话或视频通话、传输文件、共享文件等。

203部分：客户端判断是否到达通话开始时间。

204：在判断出到达通话开始时间时，客户端发送通信请求消息。

在一个示例中，客户端可在判断出到达通话开始时间时，直接发送通信请求消息，例如VoIP请求。更具体的，客户端是经由服务器向通信组中的其他用户的客户端发送VoIP请求。

在另一个示例中，在判断出到达通话开始时间时，可向终端的显示屏输出通话提醒消息。通话提醒消息可依用户自行设置是否显示。

更具体的，上述通话提醒消息可为消息提示框形式，该消息提示框包括第一点击按钮和第二点击按钮；其中，第一点击按钮用于，在被点击时触发进行发出通信请求消息的操作；而第二点击按钮用于，在被点击时触发执行结束操作。

例如，请参见图3在判断出到达开始时间后，终端会弹出toast消息，消息的内容可包括“有人想与你聊天”。

Toast是用来显示显示信息的一种机制，Toast是没有焦点的，并且Toast显示的时间有限，过一定的时间就会自动消失。

Toast是种简易的消息提示框。

仍请参见图3，toast消息中可包含“取消”和“接听”两个点击按钮，使用者若点击“接听”(对应第一点击铵钮)，则发送了“通信请求消息”，例如VoIP请求。使用者若点击“取消”(对应第二点击按钮)，则进入结束流程。

至于如何判断出到达通话开始时间，则有几种情况：

情况一，假定用户预约的通话开始时间为17：00，用户在17：00之前上线，到达17：00时刻时，判断出到达通话开始时间。

情况二，若用户在上述通话开始时间之后上线，且用户的上线时刻与上述通话开始时间的差值小于或小于等于预设差值，则判断出到达通话开始时间。

例如，假定用户预约的通话开始时间为17：00，用户在17：02上线，17：02与17：00之间的差值为2分钟，若预设差值为5分钟，2分钟小于5分钟，则判断出到达通话开始时间。

205部分：客户端向终端的拍摄装置(例如摄像头)发送开启命令。

这样，后续用户可通过客户端与通信组中的其他成员进行视频通话。

当然，对于仅语音聊天的场景，可省略205部分。

206部分：在上述通信组对应的预设时间区间内，服务器端/平台建立该通信组中发送通信请求消息的各用户之间的通信连接，以便通信组中的用户进行多人通话。

上述预设时间区间中包含通信组中的用户预约的通话开始时间。

例如，假定用户预约的通话开始时间为20：00，则预设时间区间可为20：00-20：05。本领域技术人员可根据需要合理设计时间区间，在此不作赘述。

再例如，假定通信组中用户预约的通话开始时间的范围为20：00-20：05，则预设时间区间至少应包括20：00-20：05这一时间范围。

在一个示例中，建立通信组中各用户之间的通信连接的具体方式可包括：

建立通信组中、在上述预设的时间区间内、发送通信请求消息的用户之间的通信连接。

在204部分，客户端会发送了通信请求消息，对于通信组中未发送通信请求消息的用户，可能是不在线，或者虽在线但选择了取消参与多人通话。因此，在206部分，服务器端/平台为通信组中发送通信请求消息的各用户之间建立通信连接。

206部分是前述S2部分的细化。

可见，本发明实施例，可由服务器端创建通信组，组内的成员是预约信息相匹配的用户而不再局限于联系人名单，为多人通话提供了新方式。

在本发明其他实施例中，请参见图4，上述匹配方法还可包括：

401部分：在多人通话的过程中，客户端提交主播模式切换请求。

同一通信组中的任一用户均可提交主播模式切换请求。

在多人通话过程中，客户端可提供主播模式切换UI控件，此外，还可显示通话主题、持续时长或剩余时长等。

请参见图5，在一个示例中，主播模式切换UI控件可为主播模式按键501。

使用者可通过主播模式切换UI控件输入主播模式切换请求，并向服务器端发送。例如，仍请参见图5，使用者点击主播模式按键501，则触发向服务器端发送主播模式切换请求。

402部分：服务器/平台将发送主播切换模式请求的用户设置为主讲人。

在一个示例中，将发送主播切换模式请求的用户设置为主讲人可具体包括：

令发送主播切换模式请求的用户的视频显示区域大于组中其他成员的视频显示区域。

同时，还可令发送主播切换模式请求的用户所发送的音频数据的分贝值大于其他成员所发送的音频数据的分贝值。

在本发明其他实施例中，仍请参见图4，还可包括：

403部分：服务器/平台判断上述多人通话是否到达结束时间；

服务器/平台可开启倒计时计数器，当倒计时结束时，判断出到达结束时间。

倒计时的计数值可依据通信组中用户预约的通话时长而定。例如，用户预约的通话时长为15分钟，则倒计时计数器从15分钟开始倒计时。

404部分：若判断到达结束时间，服务器/平台结束上述多人通话。

更具体的，服务器/平台可断开通信组中各用户之间的VoIP连接，此外，还可向客户端发送通话结束通知消息。

本发明所提供的匹配方法及相关装置，可适应于多种多人通话的场景。例如，其可借助微信社交平台或其他直播平台提供的多人通话服务，让对同一主题感兴趣的人更快地聚拢。

更具体的，本发明所提供的匹配方法及相关装置可应用于微信平台的公益项目，将对同一主题感兴趣的孤寂老人(受助者)与有爱服务的志愿者匹配在同一通信组中，为受助者带来温暖的陪伴。

在本发明其他实施例中，用户可包括第一用户和第二用户。

在一个示例中，第一用户为一类用户，第二用户则为与第一用户不同的一类用户。在不同的场景下，第一用户和第二用户可有不同的含义。

例如，第一用户可为志愿者，第二用户可为受助者，反之亦然。再例如，在直播教学场景下，第一用户可为学生，第二用户可为老师。

在另一个示例中，第一用户和第二用户中的第一、第二仅作为区分，不具有分类的含义。

图6示出了上述匹配方法的又一示例性流程，除图2b、图4所示的步骤外，其还可包括如下步骤：

601部分：在多人通话过程中或在多人通话结束后，第二用户的客户端向使用者提供评价反馈界面。

602部分：第二用户的客户端通过上述评价反馈界面接收对通信组中的一个或多个第一用户的评价信息，并提交至服务器端/平台。

评价信息的内容可进行灵活设计，例如，在一个示例中，评价反馈界面可罗列出通信组中所有的第一用户，每一第一用户对应一个选框，第二用户选中选框则选中了对应的第一用户，相应的，评价信息中包含所选中的第一用户的名字或标识，例如uin。更具体的，可单选或复选第一用户，对于可复选第一用户的情况，可使用一个评价信息包括所选中的多个第一用户的名字或标识，也可用多个评价信息承载所选中的多个第一用户的名字或标识。

在另一示例中，评价反馈界面除罗列出通信组中的所有第一用户外，还提供用于为第一用户打分的UI控件，例如，可为包含五颗星的UI控件，第二用户可标亮五颗星中的任意几颗，标亮的星星的个数，则表示分数或星级。则评价信息除包含第一用户的名字或标识外，还可包括评分。更具体的，可单选或复选第一用户，对于可复选第一用户的情况，可使用一个评价信息包括所选中的多个第一用户的名字或标识及评分，也可用多个评价信息承载所选中的多个第一用户的名字或标识及评分。

此外，第二用户也可提交针对本次多人通话的评价信息。在一个示例中，该评价信息中可为表征第二用户满意或不满意的数值。

603：服务器端/平台接收上述评价信息并保存；

604：服务器端/平台保存提交评价信息的第二用户与所评价的第一用户之间的匹配关系。

在一个示例中，上述匹配关系可包括第二用户与所评价的第一用户的标识对(例如uin对)，此外，匹配关系还可包括匹配次数。举例来讲，假定在两次多人通话中，受助者A均选择了志愿者1，则匹配关系可包括受助者A与志愿者1的标识对，及累计的匹配次数2。

605部分：在多人通话过程中或在多人通话结束后，第一用户的客户端提供状态反馈界面；

606部分：第一用户的客户端通过上述状态反馈界面接收个人状态信息，并提交至服务器端。

在一个示例中，上述个人状态信息可包括通信组中一个或多个第二用户的个人状态信息。

以志愿者和受助者为例，志愿者通过与受助者聊天，可能会知道受助者的兴趣爱好、年龄、病史、敏感事件等。则志愿者可以将受助者的兴趣爱好、年龄、病史、敏感事件等提交上去，以供以后的志愿者参考。因此,个人状态信息具体可包括兴趣爱好、年龄、病史、敏感事件等。

当然第一用户(例如受助者)也可提交自己的个人状态信息。

在另一个示例中，上述个人状态信息可包含每一用户自身的个人状态信息。

以志愿者和受助者为例，志愿者可提交自己的兴趣爱好、年龄等。以便在后续的活动中，系统可进行更精准的匹配。

607部分：服务器端/平台接收所述通信组中的第一用户提交的个人状态信息并保存。

608部分：在本次多人通话结束后，服务器端/平台记录第一用户在本次多人通话中的服务时长，并确定第一用户所参与的所有多人通话的累积服务时长。

服务器端/平台可使用第一用户的累积服务时长和针对该第一用户的评价信息来计算经验参数。

例如，若第一用户的累积服务时长为A小时，累计的所有匹配次数为B次，则可直接将经验参数设置为等于A或B，也可将经验参数设置为C＝a*A+b*B，其中，C表示经验参数，a和b表示权重。a、b的取值本领域技术人员可进行灵活设计，在此不作赘述。

600-604部分，与605-607部分可并行执行。

608部分可在600-607中任一部分之前或之后，本发明不作限制。

下面实施例将重点对前述的202部分(将预约信息相匹配的用户归入同一由服务器端创建的通信组)进行详细介绍。

图7示出了上述匹配方法的一种示例性流程，包括：

701部分：服务器/平台采集多个第一用户和第二用户的预约信息。

701部分内容可参考前述的200部分和201部分，在此不作赘述。

702部分：服务器/平台创建包含N个第一用户的通信组。

所述N为正整数，例如5、6等。

在一个示例中，上述N个第一用户的预约信息彼此相匹配。匹配的相关含义可参见202部分的介绍，在此不作赘述。

在另一个示例中，创建的通信组的通话属性与N个第一用户的预约信息相匹配。该通话属性可包括通话主题、通话开始时间和通话持续时长中的至少一种。

在又一个示例中，上述N个第一用户的预约信息相匹配，并且通信组的通话属性也可与这N个第一用户的预约信息相匹配。

所谓的通信组的通话属性与第一用户的预约信息相匹配，可指的是完全相同。

也可指通信组的通话属性与第一用户的预约信息相一致。例如，通话主题一致，通话开始时间和通话持续时长一致。

举例来讲，第一用户1预约的主题是“艾灸”，第一用户2预约的主题是“针灸”，通信组的通话主题是“养生调理”，则第一用户1和第二用户2的通话主题与通信组的通话主题相一致。

再例如，第一用户1预约的通话开始时间为11：00，第一用户2预约的通话开始时间为11：02，通信组的通话开始时间为11：00，则第一用户1和第二用户2的通话开始时间与通信组的通话开始时间相一致。

以此可类推至通话持续时长。

在一个场景下，第一用户可为志愿者，第二用户可为受助者。

可在通话开始时间之前，创建包含N个志愿者的通信组。志愿者可进行备课讨论。也可在到达通话开始时间时,再创建通信组。

需要说明的是，在一个示例中，针对同一通话主题，服务器可创建多个通信组。

例如，共有50个第一用户提交了预约信息，其中：

10个第一用户的预约信息的通话主题是“读书”，开始时间为15：00，持续时长为15分钟；

20个第一用户的预约信息的通话主题是“养生”，开始时间为15：00，持续时长为15分钟；

20个第一用户的预约信息的通话主题是“养生”，开始时间为15：30，持续时长为15分钟，假定N＝5。则：

创建10个通信组，其中：

两个通信组的通话主题是“读书”，开始时间为15：00，持续时长为15分钟；

4个通信组的通话主题是“养生”，开始时间为15：00，持续时长为15分钟；

4个通信组的通话主题是“养生”，开始时间为15：30，持续时长为15分钟。

需要说明的是，在一个示例中，对于某一通信组而言，还可进行经验验证，经验验证包括：获取该通信组中N个第一用户的经验参数(经验参数请参见前述608部分的记载)；在N个第一用户的经验参数均低于阈值(这N个第一用户都是新手)时，向该通信组中加入至少一个经验参数高于阈值的第一用户(加入有经验的第一用户)。

在另一个示例中，还可为一个主题活动设置第一用户的最少人数和最多人数。若预约的第一用户人数到达最少人数，则开启上述经验验证。若预约的第一用户人数到达上述最多人数，则不允许再报名，并且该主题活动会移至进行中。

703部分：服务器/平台为第二用户确定出归属的通信组。

归属的通信组中第一用户的预约信息与第二用户的预约信息相匹配，和/或，所述归属的通信组的通话属性与所述第二用户的预约信息相匹配：

在一个示例中，归属的通信组中的N个第一用户的预约信息与第二用户的预约信息相匹配。匹配的相关含义可参见202部分的介绍，在此不作赘述。

在另一个示例中，归属的通信组的通话属性与第二用户的预约信息相匹配。匹配的相关含义可参考202部分的介绍，在此不作赘述。

在又一个示例中，归属的通信组中的N个第一用户的预约信息与第二用户的预约信息相匹配，并且归属的通信组的通话属性与第二用户的预约信息相匹配。

具体的，为第二用户确定出归属的通信组可包括：

A：为第二用户确定出候选通信组。

其中，候选通信组中第一用户的预约信息与第二用户的预约信息相匹配，和/或，通话属性与所述第二用户的预约信息相匹配。

假定第二用户的预约信息包括：通话主题是“养生”，开始时间为15：00，持续时长为15分钟。

有4个通信组的通话属性包括：通话主题是“养生”，开始时间为15：00，持续时长为15分钟。

则这4个通信组为第二用户的候选通信组。

B：优先将包含有目标第一用户的候选通信组作为归属的通信组，其中，目标第一用户与所述第二用户存在匹配关系。

匹配关系的介绍请参见前述604部分的介绍，在此不作赘述。

仍沿用前例，假定第二用户对应4个通信组，其中通信组A中的某一或某些第一用户与第二用户存在匹配关系，也即第二用户曾评价过该通信组中的某一或某些第一用户，则优先将通信组A作为该第二用户所归属的通信组。

704部分：第二用户的客户端在判断出到达通话开始时间时，发送通信请求消息。

具体内容请参见前述的203-204部分，在此不作赘述。

705部分：在归属的通信组的预设时间区间内，若接收到第二用户的通信请求消息，则服务器/平台将第二用户加入上述归属的通信组。同时，服务器/平台建立第二用户与通信组中其他(发送通信请求消息)的用户之间的通信连接。

预设时间区间的介绍请参见本文前述的206部分，在此不作赘述。通信请求消息的介绍请参见本文前述的204部分，在此不作赘述。

假定第二用户归属的通信组的通话开始时间为17：00，预设时间区间为17：00-17：05，在17：02接收到第二用户的通信请求消息，则将第二用户正式加入其归属的通信组。

建立通信连接的介绍请参见前述的206部分，在此不作赘述。

706部分：在判断出到达通话开始时间时，第一用户的客户端发送通信请求消息。

可参见前述的204部分，在此不作赘述。

707部分：服务器/平台建立第一用户与通信组中其他(发送通信请求消息)的用户之间的通信连接。

建立通信连接部分的介绍请参见前述的206部分，在此不作赘述。

下面，将以应用于微信平台的公益项目为例，对本发明所提供的技术方案进行更详细的介绍。

在本实施例中,通过微信平台的多人通话能力，结合VOIP直播的体验,与公益项目相配合，达成受助者和志愿者的连接。令志愿者在家也可线上方便、高效得做公益。

请参见图8，志愿者客户端与后台之间的交互流程如下：

801部分：志愿者登录微信进入到腾讯公益服务号；

802部分：志愿者在服务号中选取自己感兴趣的互助任务；

服务号中的互助任务如图9所示。

更具体的，在一个示例中，志愿者进入腾讯公益，点击某一互助任务(例如暖心读书项目)，可查看该互助任务的具体内容(例如相关的介绍)，若志愿者选择预约该互助任务，则其提交的预约信息至少包括通话主题(例如暖心读书)。

此外，志愿者也可根据自己的时间，预约通话开始时间和通话持续时长，乃至结束时间。则其提交的预约信息还可包括预约的通话开始时间、通话持续时长、结束时间中的至少一种。

在另一个示例中，志愿者进入腾讯公益，可在搜索栏中输入时间，则可以显示通话开始时间(或结束时间)与志愿者输入的时间相匹配的互助任务，若用户选择预约该任务，则其提交的预约信息至少包括预约的通话主题、通话开始时间(或通话结束时间)。

在又一个示例中，志愿者进入腾讯公益，可在搜索栏中输入通话持续时长，则可以显示通话持续时长与志愿者输入的时长相匹配的互助任务，若用户选择预约该任务，则其提交的预约信息至少包括预约的通话主题、通话持续时长。

关于预约信息，请参见前述201部分、701部分。

803部分：当某任务的志愿者召集完毕后，创建微信群(也即通信组)，将选择该任务的志愿者拉入群中。

所谓的召集完毕，可指报名参加某任务的志愿者的数量到达预设个数(或预设的最少个数)，例如5个。

服务器端需创建微信群的id，将各志愿者的uin与该微信群id(group id)绑定，则在后台实现将与该微信群id绑定的志愿者拉入此微信群中。

服务器通知与该微信群id绑定的每一位志愿者的客户端，被通知的每一位志愿者的客户端，可在客户端侧创建与该group id对应的微信群，将与微信群id绑定的各志愿者拉入微信群，则在客户端实现将与该微信群id绑定的志愿者拉入此微信群中。

群中的志愿者可提前对本次任务进行讨论和备课。

相关细节请参见前述的202部分、702部分，在此不作赘述。

804部分：判断志愿者是否全是新手，若是，进入步骤805，否则进入步骤806；

在一个示例中，可依据志愿者的经验参数来判断志愿者是新手，还是有经验。相关细节请参见前述608和702部分，在此不作赘述。

805部分：后台拉进一名有经验的志愿者进入微信群，以进行共同服务和引导培训。

在一个示例中，可依据志愿者的经验参数来判断志愿者是否有经验。相关细节请参见前述608和702部分，在此不作赘述。

806部分：志愿者客户端判断是否到达通话开始时间，若到达，显示通话提醒消息。

通话提醒消息可为消息提示框形式，该消息提示框包括第一点击按钮和第二点击按钮；其中，第一点击按钮用于，在被点击时触发进行发出通信请求消息(VoIP请求)的操作；而第二点击按钮用于，在被点击时触发执行结束操作。

若使用者点击了第一点击按钮则继续执行807部分。

806部分与204部分相类似，在此不作赘述。

807部分：志愿者客户端拉起VoIP并打开摄像头。

所谓的拉起VoIP，指的是向微信群中的用户发送VoIP请求。

客户端可向终端的摄像头发送开启命令，以打开摄像头。

808部分：在多人视频通话过程中，志愿者可以切换主播模式。

主播模式如何切换等细节可参见前述的401部分和402部分，在此不作赘述。

809部分：多人视频通话结束后，志愿者可将受助者的状态进行汇总记录，提交受助者的个人状态信息，便于后续服务开展。

809部分请参见前述的605-607部分。在此不作赘述。

810部分：服务器端(后台)累积志愿者的线上服务时长(即前述的累积服务时长)。

服务器还可结合受助者的评价信息来计算志愿者的经验参数，将志愿者的服务在线上标准化。

此外，在本发明其他实施例中，志愿者还可以将志愿者服务分享到朋友圈等SNS传播渠道，以鼓励更多人加入志愿者服务。

例如，图10a示出了志愿者在微信朋友圈分享的志愿者服务。

图10b是所分享的具体内容。

使用本方法可标准化地对志愿者进行管理和运营，形成线上志愿者闭环。其管理和运营流程可参见图11所示。

请参见图12，受助者客户端与后台之间的交互流程如下：

1201部分：受助者在预约时间前后登录微信；

需要说明的是，请参见图13，可通过个人申请，公益组织代理审批的方式，申请成为受助者。

也可通过政府机构、养老院、公益组织等机构提交申请，成为受助者。

1202部分：受助者客户端判断是否到达通话开始时间，若到达，显示通话提醒消息，以提示“有人想与你聊天”。

相关内容请参见前述的806部分和204部分，在此不作赘述。

1203部分：受助者的客户端判断受助者是否接受服务，若是，进入1204，否则结束；

更具体的，请参见图14，若点击了接听，则接受服务，若点击了取消，则不接受服务。

1204部分：点击接听后，自动将受助者拉入微信群。

有前期报名此活动的志愿者已在微信群中。

例如，请参见图15，会自动将受助者拉入“星光有爱小队”。

此外，点击接听后，会向微信群中的其他用户发送VoIP请求。

在本部分，服务器端会将受助者的uin与微信群id绑定，则在后台实现将受助者拉入微信群中。

然后，服务器会通知之前已与该微信群id绑定的每一位用户的客户端，被通知的客户端会根据通知更新群成员。

此外，服务器还会通知上述受助者的客户端，该受助者的客户端会在客户端侧创建与该group id对应的微信群，将与微信群id绑定的各用户拉入在客户端创建的微信群，从而在客户端实现受助者的加入。

此外，在本发明其他实施例中，服务器端还可事先为受助者确定出归属的微信群。相关内容请参见前述的703-705部分。在此不作赘述。

1205部分：受助者客户端拉起VoIP并打开摄像头。

所谓的拉起VoIP，指的是向微信群中的用户发送VoIP请求。具体内容请参见204、205、807等部分，在此不作赘述。

客户端可向终端的摄像头发送开启命令，以打开摄像头。

拉起VoIP并打开摄像头后，其界面可如图16所示。

在图16中，中间的视频区域显示的是受助者。

1206部分：在多人视频通话过程中，受助者可以切换主播模式。

主播模式下，请参见图5，会由一名用户主讲演示，降低其他用户的音频接入。

由于是互助直播活动，还可在VOIP上增加主题、倒计时。

1207部分：结束之后，受助者可以对本次服务进行评价(请参见图17a)，同时选择喜欢的志愿者，对志愿者进行评价(请参见图17b)。

相关内容请参见前述的601-604部分，在此不作赘述。

1208部分：本次服务结束后，受助者还可预约下次服务的时间(图18a)和主题(图18b)。

需要说明的是，当同一对志愿者和受助者进行多次匹配，并且都有较好评价，两人便可以达成连接，从线上发展至线下的关怀互助关系。

可见，本发明实施例可提供线上公益新方式，让有意参加志愿者服务的人在家就可以做公益，同时，降低了匹配的成本，对于同一主题有兴趣的人能更快地聚拢；增加了平台的活跃，让受助者依靠平台的力量更容易找到愿意施助的人群。

图19示出了上述实施例中所涉及的匹配装置或服务器的一种可能的结构示意图，包括：

通信单元1901，用于采集用户的预约信息，所述预约信息包括预约的通话主题、通话开始时间和通话持续时长中的任意一种或任意组合；

处理单元1902，用于在预设时间区间内，建立预约信息相匹配的用户之间的通信连接，以便所述预约信息相匹配的用户进行多人通话；所述预设时间区间中包含用户预约的通话开始时间。

通信单元1901可用于支持图2a所示的S1步骤、图2b和4所示的200-201、204部分，图4所示的401部分，图6所示的601-602或605-606部分，图7所示的701、704、706部分，图8所示的801-803部分，图12所示的1201、1204、1207、1208部分中与其他装置的通信。

处理单元1902可用于执行图2a所示的S2步骤、图2b所示的202、206部分，图4所示402-404部分，图6所示的603-604，607-608部分，图7所示的702-703、705、707部分，图8所示的804-805，809-810。

图20示出了上述实施例中所涉及的匹配装置或终端的一种可能的结构示意图，包括：

通信模块2001，用于生成并发送预约信息，所述预约信息包括用户预约的通话主题、通话开始时间和通话持续时长中的任意一种或任意组合；

处理模块2002，用于：

判断是否到达所述通话开始时间；在判断出到达所述通话开始时间时，发送通信请求消息，以便以便服务器端为发送了通信请求消息且预约信息与之相匹配的用户之间建立通信连接，进行多人通话。

通信模块2001可用于支持图2b和图4所示的200-201、204部分，图4所示的401部分，图6所示的600-601或605-606部分，图7所示的701、704、706部分，图8所示的801-803、806-808部分，图12所示的1201-1207中，与其他装置的通信。

处理模块2002至少可用于执行图2b所示的203-205部分(通知通信模块2001执行204部分)。

上述所有实施例所涉及的匹配装置/终端/服务器/平台的另一种可能的结构示意图,可参见图1，包括：

总线、处理器501、存储器502、通信接口503、输入设备504和输出设备505。处理器501、存储器502、通信接口503、输入设备504和输出设备505通过总线相互连接。

控制器/处理器可用于执行前述涉及匹配装置/终端/服务器/平台的处理过程和/或用于本申请所描述的技术的其他过程。控制器/处理器也可用于实现前述处理单元或处理模块的功能。

通信接口则用于支持匹配装置/终端/服务器/平台与其他装置进行通信。例如,用于支持服务器与图2b、4、6-8、12所示实施例中的其他装置进行通信。

可以理解的是，图1仅仅示出了匹配装置/终端/服务器/平台的简化设计。在实际应用中，匹配装置/终端/服务器/平台可以包含任意数量的发射器，接收器，处理器，控制器，存储器，通信接口等，而所有可以实现本发明的资源管理装置/服务器/理财平台都在本发明的保护范围之内。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims

1.一种匹配方法，其特征在于，应用于服务器端，所述方法包括：

将预约信息相匹配的用户归入同一由服务器端自动创建的通信组；

在预设时间区间内，建立预约信息相匹配的用户之间的通信连接，以便所述预约信息相匹配的用户进行多人通话；所述预设时间区间中包含用户预约的通话开始时间；

所述用户包括第一用户和第二用户；在所述多人通话过程中或在所述多人通话结束后，所述方法还包括：

接收第二用户提交的、针对一个或多个第一用户的评价信息并保存；

保存提交评价信息的第二用户与所评价的第一用户之间的匹配关系；所述匹配关系用于在匹配过程中确定所述第二用户归属的通信组。

2.如权利要求1所述的方法，其特征在于，所述建立预约信息相匹配的用户之间的通信连接包括：

建立在所述预设的时间区间内、发送了通信请求消息且预约信息相匹配的用户之间的通信连接。

3.如权利要求1所述的方法，其特征在于，还包括：

在所述多人通话的过程中，接收主播模式切换请求，所述主播模式切换请求来自于所述通信组中的任一用户；

将发送所述主播切换模式请求的用户设置为主讲人。

4.如权利要求1所述的方法，其特征在于，在所述多人通话过程中或在所述多人通话结束后，还包括：

接收所述通信组中的第一用户提交的个人状态信息。

5.如权利要求3所述的方法，其特征在于，在所述多人通话结束后，所述方法还包括：

记录所述第一用户在本次多人通话中的服务时长；

确定所述第一用户所参与的所有多人通话的累积服务时长。

6.如权利要求5所述的方法，其特征在于，所述将预约信息相匹配的用户归入同一由所述服务器端自动创建的通信组包括：

创建包含N个第一用户的通信组，所述N个第一用户的预约信息相匹配，和/或，所述通信组的通话属性与所述N个第一用户的预约信息相匹配，所述通话属性包括通话主题、通话开始时间和通话持续时长中的至少一种，所述N为正整数。

7.如权利要求6所述的方法，其特征在于，所述将预约信息相匹配的用户归入同一由所述服务器端自动创建的通信组还包括：

为第二用户确定出归属的通信组，所述归属的通信组中第一用户的预约信息与所述第二用户的预约信息相匹配，和/或，所述归属的通信组的通话属性与所述第二用户的预约信息相匹配；

在所述预设时间区间内，若接收到所述第二用户的通信请求消息，则将所述第二用户加入所述归属的通信组。

8.如权利要求7所述的方法，其特征在于，所述为第二用户确定出归属的通信组包括：

为所述第二用户确定出候选通信组，所述候选通信组中第一用户的预约信息与所述第二用户的预约信息相匹配，和/或，通话属性与所述第二用户的预约信息相匹配；

优先将包含有目标第一用户的候选通信组作为所述归属的通信组，其中，所述目标第一用户与所述第二用户存在匹配关系。

9.如权利要求8所述的方法，其特征在于，所述将预约信息相匹配的用户归入同一由所述服务器端创建的通信组还包括：

获取所述通信组中N个第一用户的经验参数；

在所述N个第一用户的经验参数均低于阈值时，向所述通信组中加入至少一个经验参数高于所述阈值的第一用户。

10.如权利要求9所述的方法，其特征在于，每一所述第一用户的经验参数至少根据针对该第一用户的评价信息和该第一用户的累积服务时长中的至少一种而确定。

11.一种匹配方法，其特征在于，应用于终端，所述方法包括：

生成并发送预约信息，所述预约信息包括用户预约的通话主题、通话开始时间和通话持续时长中的任意一种或任意组合；预约信息相匹配的用户将归入同一由服务器端自动创建的通信组；

判断是否到达所述通话开始时间；

在判断出到达所述通话开始时间时，发送通信请求消息，以便服务器端为发送了通信请求消息且预约信息与之相匹配的用户之间建立通信连接，进行多人通话；

所述用户包括第一用户和第二用户；在所述多人通话过程中或在所述多人通话结束后，若所述终端对应的用户为第二用户，所述方法还包括：

提交针对一个或多个第一用户的评价信息并保存；所述服务器用于保存提交评价信息的第二用户与所评价的第一用户之间的匹配关系；所述匹配关系用于在匹配过程中确定所述第二用户归属的通信组。

12.如权利要求11所述的方法，其特征在于，还包括：

在判断出到达所述通话开始时间时，向终端的显示屏输出通话提醒消息。

13.如权利要求12所述的方法，其特征在于，在发送通信请求消息后，还包括：

向终端的拍摄装置发送开启命令。

14.一种匹配装置，其特征在于，应用于服务器端，所述匹配装置包括：

处理单元，用于将预约信息相匹配的用户归入同一由服务器端自动创建的通信组，在预设时间区间内，建立预约信息相匹配的用户之间的通信连接，以便所述预约信息相匹配的用户进行多人通话；所述预设时间区间中包含用户预约的通话开始时间；

所述用户包括第一用户和第二用户；在所述多人通话过程中或在所述多人通话结束后，所述处理单元还用于：

15.如权利要求14所述的装置，其特征在于，在将预约信息相匹配的用户归入同一由服务器端自动创建的通信组的方面，所述处理单元用于：

创建包含N个第一用户的通信组，所述N个第一用户的预约信息相匹配，和/或，所述通信组的通话属性与所述N个第一用户的预约信息相匹配，所述通话属性包括通话主题、通话开始时间和通话持续时长中的至少一种，所述N为正整数；

在所述预设的时间区间内，若接收到所述第二用户的通信请求消息，则将所述第二用户加入所述归属的通信组。

16.一种匹配装置，其特征在于，应用于终端，所述匹配装置包括：

通信模块，用于生成并发送预约信息，所述预约信息包括用户预约的通话主题、通话开始时间和通话持续时长中的任意一种或任意组合；预约信息相匹配的用户将归入同一由服务器端自动创建的通信组；

处理模块，用于：

判断是否到达所述通话开始时间；在判断出到达所述通话开始时间时，发送通信请求消息，以便服务器端为发送了通信请求消息且预约信息与之相匹配的用户之间建立通信连接，进行多人通话；

所述用户包括第一用户和第二用户；在所述多人通话过程中或在所述多人通话结束后，若所述终端对应的用户为第二用户，所述通信模块还用于：提交针对一个或多个第一用户的评价信息并保存；所述服务器用于保存提交评价信息的第二用户与所评价的第一用户之间的匹配关系；所述匹配关系用于在匹配过程中确定所述第二用户归属的通信组。

17.一种服务器，其特征在于，包括：

18.一种终端，其特征在于，包括：

处理模块，用于：