一种用户联系方式的查询方法及服务器与流程

本发明涉及通信技术领域，尤其涉及一种用户联系方式的查询方法和一种服务器。

背景技术：

着通讯技术的发展，移动终端已经被越来越多的人接受并在人们的工作、学习、日常生活中等各方面的使用越来越普遍。

在移动终端的使用过程中，当前用户与其他用户进行通信的使频率较大，使得移动终端中存储了数量较多的联系人信息。

如果某个用户想将另一个用户的联系方式作为联系人信息存储在移动终端中，一般需要当面要联系方式，或者，通过询问第三方用户来找到此用户的联系方式。

这两种方式，不能够及时地获得想要联系的用户的联系方式，及时性差，而且，若长时间不联系，很多时候很难见到想要联系的用户、也很难通过第三方找到想要联系的用户的联系方式，实用性差。

技术实现要素：

本发明实施例提供一种用户联系方式的查询方法，以解决查询用户的联系方式及时性差、实用性差的问题。

第一方面，提供了一种用户联系方式的查询的方法，所述方法包括：

接收来自发起方所在终端的查询请求，所述查询请求中包括目标用户特征和所述发起方的信息；

根据所述发起方的信息，获取所述发起方的联系人列表，并在预置的联系人数据库中，查找与所述目标用户特征匹配的候选用户，获取所述候选用户的联系人列表；

计算所述发起方的联系人列表与所述候选用户的联系人列表之间的匹配度；

当所述匹配度满足预设条件时，将所述候选用户的联系方式返回给所述终端。

第二方面，提供了一种服务器，所述服务器包括：

查询请求接收模块，用于接收来自发起方所在终端的查询请求，所述查询请求中包括目标用户特征和所述发起方的信息；

联系信息获取模块，用于根据所述发起方的信息，获取所述发起方的联系人列表，并在预置的联系人数据库中，查找与所述目标用户特征匹配的候选用户，获取所述候选用户的联系人列表；

匹配度计算模块，用于计算所述发起方的联系人列表与所述候选用户的联系人列表之间的匹配度；

联系方式返回模块，用于在所述匹配度满足预设条件时，将所述候选用户的联系方式返回给所述终端。

这样，本发明实施例中，根据发起方的信息，获取发起方的联系人列表，并在预置的联系人数据库中，查找与目标用户特征匹配的候选用户，获取候选用户的联系人列表，通过计算发起方的联系人列表与候选用户的联系人列表之间的匹配度，当匹配度满足预设条件时，将候选用户的联系方式返回给终端，通过前期众多用户在云端共享联系方式，后期可以基于用户特征即可查询到想要联系的用户，避免了当面要联系方式和通过询问第三方用户，操作简便，大大提高了查询的及时性和实用性，同时，通过联系人信息之间的匹配度决定是否反馈用户的联系方式，可以保证联系方式的隐私性。

附图说明

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

图1是本发明的一种用户联系方式的查询方法实施例的步骤流程图；

图2是本发明的另一种用户联系方式的查询方法实施例的步骤流程图；

图3是本发明的另一种用户联系方式的查询方法实施例的步骤流程图；

图4是本发明的一种服务器的结构框图；

图5是本发明实施例的一种联系信息获取模块的框图；

图6是本发明实施例的一种的匹配度计算模块的框图；

图7是本发明实施例的一种联系信息获取模块的框图；

图8是本发明实施例的一种匹配度计算模块的框图；

图9是本发明的另一种服务器的结构框图；

图10是本发明实施例的一种联系方式返回模块的框图；

图11是本发明的另一种服务器的结构框图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

第一实施例

参照图1，示出了本发明的一种用户联系方式的查询方法实施例的步骤流程图，具体可以包括如下步骤：

步骤101，接收来自发起方所在终端的查询请求。

在具体实现中，本发明实施例可以应用在服务器中，该服务器可以为独立的计算机，也可以为计算机集群，如分布式系统，本发明实施例对此不加以限制。

该服务器设置有API(Application Programming Interface，应用程序编程接口)，提供用户联系方式的查询服务。

用户可以通过终端(例如，手机、平板电脑、个人数字助理、穿戴设备(如眼镜、手表等)等)可以调用该服务器提供的API接口，按照该API接口的参数规范，将目标用户特征作为参数、组装成一查询请求，发送到该服务器，以调用该服务器的用户联系方式的查询服务，查询目标用户的信息。

因此，查询请求中具有目标用户特征和发起方的信息，其中，目标用户特征为体现目标用户的特征的信息，一般为姓名，当然，也可以为性别、公司、E-mail(电子邮件)地址、即时通讯工具的账号、支付应用的账号等等，本发明实施例对此不加以限制。

例如，第一移动终端所属的用户想要联系一个姓名为“王超”的用户，则可以以姓名为key(键)、王超为value(值)作为参数，发送至服务器。

如果第一移动终端所属的用户除了知道目标用户的姓名为“王超”之外，还知道该目标用户就职的公司为A通信公司，则除了以姓名为key(键)、王超为value(值)作为参数之外，还可以以公司为key(键)、A通信公司为value(值)作为参数，发送至服务器。

步骤102，根据所述发起方的信息，获取所述发起方的联系人列表，并在预置的联系人数据库中，查找与所述目标用户特征匹配的候选用户，获取所述候选用户的联系人列表。

在具体实现中，终端可以通过SIM(Subscriber Identity Module，客户识别模块)卡、USIM(Universal Subscriber Identity Module，全球用户识别卡)卡、电子邮箱等方式与其他终端进行通信，用户通常会记录数量不等的联系人信息，例如，姓名、电话号码、性别、E-mail(电子邮件)地址、即时通讯工具的账号、支付账号等等。

这些终端的操作系统可以包括Android(安卓)、IOS、Windows Phone、Windows等等，通常配置有通讯录，其中包括系统内置的通讯录，第三方应用的通讯录，用于存储联系人信息，并形成联系人列表。

进一步而言，这些通讯录的联系人信息一般会存储在操作系统的联系人数据库中，通讯录上显示的联系人信息一般是通过查询此联系人数据库得到的，供用户进行浏览、删除、修改等操作。

以Android系统为例，联系人数据库可以为contacts2.db，其存储目录一般为/data/data/com.android.providers.contacts/databases。

contacts2.db中一般具有raw_contacts表、contacts表和data表等表格。

contacts表存储联系人lookup(可以理解为类似ID的功能)。

raw_contacts表存储了联系人的姓名、姓名的字母索引和帐户类型信息(区别是本机号码还是SIM卡号码)。

data表存储了联系人的号码、邮件、IM等数据。

在本发明实施例中，可以通过如下两种方式获取在发起方的联系人列表：

1、终端上传。

在此种方式中，服务器可以根据发起方的信息，从发起方所在终端获取所述发起方的联系人列表。

进一步而言，发起方的终端可以随目标用户特征一同在目标用户的查询请求上传存储在通讯录的联系人列表，也可以单独上传存储在通讯录的联系人列表，本发明实施例对此不加以限制。

例如，发起方的终端可以先在目标用户的查询请求中上传目标用户特征，在联系人数据库中，服务器查找到与目标用户特征匹配的候选用户之后，可以向发起方的终端返回应答信息，发起方的终端依据该应答信息上传存储在通讯录的联系人列表；如果服务器未查找到与目标用户特征匹配的候选用户，可以向发起方的终端返回查询失败的消息，发起方的终端不上传联系人列表。

2、服务器查询。

在此种方式中，发起方的终端在先将其所属的联系方式(包括电话号码、用户特征，如姓名、公司等)作为候选用户联系方式、存储在通讯录的联系人列表上传至服务器，建立关联关系、存储在联系人数据库中。

发起方的终端可以随目标用户特征一同在目标用户的查询请求中嵌入第一移动终端的SIM卡或USIM卡的目标电话号码等用户标识作为发起方的信息。

根据发起方的信息，从联系人数据库中获取所述发起方的联系人列表，即服务器可以基于发起方的终端上传的用户标识，在预置的联系人数据库中查找该用户标识对应的候选用户联系方式，并提取候选用户联系方式对应的联系人列表。

当然，上述发起方的联系人列表的获取方式只是作为示例，在实施本发明实施例时，可以根据实际情况设置其他发起方的联系人列表的获取方式的方式，本发明实施例对此不加以限制。另外，除了上述发起方的联系人列表的获取方式外，本领域技术人员还可以根据实际需要采用其它发起方的联系人列表的获取方式，本发明实施例对此也不加以限制。

应用本发明实施例，候选用户的终端可以上传候选用户的联系方式及联系人列表，建立关联关系、存储在联系人数据库中。

其中，候选用户联系方式，可以为候选用户的联系方式，即上传联系人列表的用户的联系方式。

在具体实现中，候选用户的联系方式可以以候选用户特征与候选电话号码的形式存储。

其中，候选用户特征为体现第二移动终端所属用户的特征的信息，一般为姓名，当然，也可以为性别、公司、E-mail(电子邮件)地址、即时通讯工具的账号、支付应用的账号等等，本发明实施例对此不加以限制。

因此，若服务器接收到发起方的终端发送的查询请求，则可以以目标用户特征在联系人数据库中的候选用户特征进行比对。

如果目标用户特征与候选用户特征部分关键的特征(如姓名)或全部特征相同，则可以认为目标用户特征与候选用户特征匹配，进而确认目标用户特征与候选用户特征所属的候选用户联系方式匹配。

因此，当目标用户特征与候选用户匹配时，可以按照该关联关系提取该候选用户对应的联系人列表。

步骤103，计算所述发起方的联系人列表与所述候选用户的联系人列表之间的匹配度。

在用户的日常生活中，经常需要在不同场合与不同的人进行交流，人们对于在社交中个体之间关系理解将会或多或少的影响到对联系人信息的使用，这些联系人信息很多是基于实现的社交关系存储的，因此，通讯录中的联系人信息在某种程度上表达用户的社会关系网络。

若发起方与候选用户认识，其社会关系网络一般具有相关性，如具有共同的好友，共同存储了该好友的联系人信息。

反之，若发起发与候选用户不认识，其社会关系网络一般不具有相关性，如不具有共同的好友，没有共同存储该好友的联系人信息。

在本发明实施例中，可以计算发起发的联系人列表与候选用户的联系人列表之间的匹配度(即匹配的程度)，反映两个用户之间的社会关系网络的相关性。

步骤104，当所述匹配度满足预设条件时，将所述候选用户的联系方式返回给所述终端。

在具体实现中，若匹配度满足一定的条件，则可以将该候选用户联系方式返回发起方的终端，展示给发起方。

这样，本发明实施例中，通过在服务器中按照第一移动终端上传的目标用户特征匹配第二移动终端上传的候选用户联系方式，按照第一移动终端中存储的第一联系人信息与第二移动终端的第二联系人信息之间的匹配度将候选用户联系方式返回第一移动终端，通过众多用户在云端共享联系方式，通过用户特征即可查询到想要联系的用户，避免了当面要联系方式和通过询问第三方用户，操作简便，大大提高了查询的及时性和实用性，同时，通过联系人信息之间的匹配度决定是否反馈用户的联系方式，可以保证联系方式的隐私性。

第二实施例

参照图2，示出了本发明的另一种用户联系方式的查询方法实施例的步骤流程图，具体可以包括如下步骤：

步骤201，接收来自发起方所在终端的查询请求。

其中，所述查询请求中包括目标用户特征和所述发起方的信息。

步骤202，根据所述发起方的信息，获取所述发起方的联系人列表。

步骤203，在预置的联系人数据库中，查找到与所述目标用户特征匹配的多个候选用户，分别获取所述多个候选用户的联系人列表。

在本发明实施例中，如果存在与目标用户特征匹配的多个候选用户，如存在多个姓名相同的候选用户，则可以分别提取该多个候选用户的多个候选人列表。

步骤204，分别计算所述发起方的联系人列表与各个候选用户的联系人列表之间的匹配度。

如果提取了多个候选用户的联系人列表，则可以分别计算发起方的联系人列表与各个候选用户的联系人列表之间的匹配度，逐一验证。

在本发明的一个实施例中，针对每次发起方的联系人列表与候选用户的联系人列表之间的匹配度计算，可以将发起方的联系人列表中的各个联系人的联系方式与候选用户的联系人列表中的各个联系人的联系方式进行匹配，获取联系方式相同的联系人数量。

将联系人数量和/或联系人数量在候选用户的联系人列表中的比例，作为发起方的联系人列表与候选用户的联系人列表之间的匹配度。

在具体实现中，如果发起方的联系人列表中的联系人信息与候选用户的联系人列表中的联系人信息的部分关键的联系方式(如电话号码)或全部联系方式相同，则可以认为第一联系人信息与第二联系人信息相同。

以电话号码为例，服务器可以从发起方的联系人列表中的联系人信息中提取第一电话号码，从候选用户的联系人列表中的联系人信息提取第二电话号码。

当第一电话号码与第二电话号码匹配时，则确定两个联系方式相同。

当然，上述相同联系方式的判断方式只是作为示例，在实施本发明实施例时，可以根据实际情况设置其他相同联系方式的判断方式，本发明实施例对此不加以限制。另外，除了上述相同联系方式的判断方式外，本领域技术人员还可以根据实际需要采用其它相同联系方式的判断方式，本发明实施例对此也不加以限制。

此外，为了减少计算量，可以直接以将联系人数量和/或联系人数量在候选用户的联系人列表中的比例作为匹配度。

为了提高匹配度的准确度，可以按照发起方的终端与候选用户的终端与联系方式相同的联系人之间的通讯信息(如通讯次数、通讯时长等)配置权重，基于配置权重的联系方式相同的联系人生成匹配度。

当然，上述匹配度的生成方式只是作为示例，在实施本发明实施例时，可以根据实际情况设置其他匹配度的生成方式，本发明实施例对此不加以限制。另外，除了上述匹配度的生成方式外，本领域技术人员还可以根据实际需要采用其它匹配度的生成方式，本发明实施例对此也不加以限制。

步骤205，根据所述发起方的联系人列表与各个候选用户的联系人列表之间的匹配度，对各个候选用户进行排序。

在本发明实施例中，可以按照匹配度(如目标用户联系方式的数量)对候选用户联系方式进行顺序排序，即匹配度越高(如目标用户联系方式的数量越多)，则排序越高，反之，匹配度越低(如目标用户联系方式的数量越少)，则排序越低。

步骤206，将排序最前的预设数量的候选用户的联系方式返回给所述终端。

在本发明实施例中，由于目标用户一般是一个，因此，可以将最有可能的前N(N为正整数，如5)个候选用户的联系方式返回发起方的终端进行显示，一方面可以防止过多的信息扰乱用户，另一方面可以防止透露过多的用户信息。

步骤207，当所述匹配度满足预设条件时，将所述候选用户对应的终端的地理位置信息和/或所述候选用户的电话号码的归属地信息，返回给所述发起方所在终端。

在本发明实施例中，为了提高识别目标用户的精确度，除了候选用户的联系方式之外，还可以返回与候选用户的其他信息，辅助发起方判断该候选用户是否为目标用户。

在具体实现中，候选用户在使用终端时，可以在预设的时间点(如9时、17时、21时等)通过GPS(Global Positioning System，全球定位系统)、Wi-Fi(无线保真)等方式进行定位并上传服务器，则服务器可以查询候选用户的终端上传的地理位置信息，形成候选用户的活动区域。

例如，王超在广东深圳上梅林上班，在上塘居住，根据地理位置信息的记录，把王超的活动区域显示在一个市级的一个区的范围，即“广东省深圳市福田区”和“广东省深圳市龙华新区”。

此外，服务器可以从候选用户的联系方式中提取电话号码，查询该电话号码的归属地信息。

最后，服务器将地理位置信息和/或归属地信息，返回发起方的终端，展示给发起方进行判断。

第三实施例

参照图3，示出了本发明的另一种用户联系方式的查询方法实施例的步骤流程图，具体可以包括如下步骤：

步骤301，接收候选用户终端上传的联系人列表。

在本发明实施例中，候选用户的终端可以在满足一定条件下，如到达预设时间、联系人信息更新的数量超过预设阈值等，上传其在通讯录中存储的联系人列表至云端(服务器)，共同维护联系人数据库。

当然，为了保证用户的隐私权和知情权，可以先检查候选用户是否加入了指定计划，如果是，则确认候选用户对服务器采集候选用户的联系人列表进行了授权，候选用户的终端可以继续执行联系人列表的发送流程，如果候选用户没有加入执行计划，则确认候选用户未对服务器采集联系人列表进行授权，候选用户的终端终止执行联系人列表的发送流程。

其中，指定计划可以包括但不限于服务器发起的用户体验计划等等。

步骤302，确定候选用户的联系方式。

在具体实现中，如果候选用户的终端在通讯录存储有候选用户的联系方式，则可以直接将候选用户的联系方式。

相对地，服务器可以接收候选用户的终端上传的联系方式。

如果候选用户的终端为在通讯录存储候选用户的联系方式，则可以上传其SIM卡、USIM卡等通信卡的候选电话号码。

相对地，服务器可以接收候选用户的终端上传的候选电话号码。

由于其他用户可能将候选用户的联系方式作为联系人信息存储在通讯录中，因此，服务器可以在联系人数据库中查询该候选电话号码所属的联系人信息，作为候选用户的联系方式。

当然，上述候选用户的联系方式的确定方式只是作为示例，在实施本发明实施例时，可以根据实际情况设置其他候选用户的联系方式的确定方式，本发明实施例对此不加以限制。另外，除了上述候选用户的联系方式的确定方式外，本领域技术人员还可以根据实际需要采用其它候选用户的联系方式的确定方式，本发明实施例对此也不加以限制。

步骤303，将所述候选用户的联系方式及所述联系人列表建立关联关系、存储在联系人数据库中。

若云端(服务器)接收到候选用户的联系方式及联系人列表，则可以对候选用户的联系方式与联系人列表建立关联关系，存储在联系人数据库。

在实际应用中，若某个用户具有一部终端，存储一份联系人列表，则候选用户的联系方式与联系人列表是一一对应的关系；若某个用户具有多部终端，存储有多份联系人列表，则服务器可以将候选用户的联系方式分别与每份联系人列表建立关联关系，也可以将多份联系人列表合并为一份联系人列表，再与候选用户的联系方式建立关联关系，本发明实施例对此不加以限制。

在本发明实施例中，联系人数据库中存储的联系人信息包括候选用户的联系方式、联系人列表。

如果候选用户的联系方式、联系人列表中的联系人信息与联系人数据库中的联系人信息的部分关键的信息(如电话号码)或全部信息相同，则可以认为候选用户的联系方式、联系人列表中的联系人信息与联系人数据库中的联系人信息匹配。

以电话号码为例，服务器可以从候选用户的联系方式中提取候选电话号码，从联系人列表中的联系人信息中提取电话号码。

当候选电话号码和/或电话号码与联系人数据库中联系人信息的电话号码相同时，确定候选用户的联系方式和/或联系人列表中的联系人信息与联系人数据库中的联系人信息匹配。

此时，认为候选用户的联系方式和/或联系人列表中的联系人信息属于同一个用户，但是，不同用户对于该用户存储的信息可能有所不同。

例如，某个用户的姓名为王超，某些用户可能存储其姓名为王超，某些用户可能存储其姓名为小王。

又例如，对于公司名称，某些用户可能简化存储。

因此，为了对存储的数据进行规范化，服务器可以对候选用户的联系方式和/或联系人列表中的联系人信息与联系人数据库中的联系人信息进行归一化处理。

对于姓名等个人信息，则可以以存储数量最多的信息作为归一化的信息；对于公司等公共信息，则可以调用相应的知识库或相关政府单位的服务器进行验证。

例如，某个用户的姓名为王超，部分用户存储为王超的数量为5，部分用户存储为小王的数量为1，则可以将姓名同一为王超进行存储。

在具体实现中，同一份联系人信息(包括候选用户的联系方式和/或联系人列表中的联系人信息)可能有多个用户存储，为了减少存储的数量，可以对其进行编号，在独立的数据库存储联系人信息(包括候选用户联系方式和/或联系人列表中的联系人信息)本身，而在联系人数据库中存储其编号。

因此，若需要与联系人信息(候选用户的联系方式和/或联系人列表中的联系人信息)进行比对，则可以按照其编码查找相应的联系人信息(候选用户的联系方式和/或联系人列表中的联系人信息)，再进行比对。

当然，如果存储空间足够，在联系人数据库中也可以直接存储联系人信息(候选用户的联系方式和/或联系人列表中的联系人信息)本身，本发明实施例对此不加以限制。

步骤304，接收来自发起方所在终端的查询请求。

其中，所述查询请求中包括目标用户特征和所述发起方的信息。

步骤305，根据所述发起方的信息，获取所述发起方的联系人列表，并在预置的联系人数据库中，查找与所述目标用户特征匹配的候选用户，获取所述候选用户的联系人列表。

步骤306，计算所述发起方的联系人列表与所述候选用户的联系人列表之间的匹配度。

步骤307，当所述匹配度满足预设条件时，将所述候选用户的联系方式返回给所述终端。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。

第四实施例

参照图4，示出了本发明的一种服务器的结构框图，该服务器400具体可以包括如下模块：

查询请求接收模块401，用于接收来自发起方所在终端的查询请求，所述查询请求中包括目标用户特征和所述发起方的信息；

联系信息获取模块402，用于根据所述发起方的信息，获取所述发起方的联系人列表，并在预置的联系人数据库中，查找与所述目标用户特征匹配的候选用户，获取所述候选用户的联系人列表；

匹配度计算模块403，用于计算所述发起方的联系人列表与所述候选用户的联系人列表之间的匹配度；

联系方式返回模块404，用于在所述匹配度满足预设条件时，将所述候选用户的联系方式返回给所述终端。

在本发明的一个实施例中，参考图5所示的联系信息获取模块的框图，所述联系信息获取模块402进一步可以包括如下子模块：

数据库获取子模块4021，用于根据所述发起方的信息，从所述联系人数据库中获取所述发起方的联系人列表；

或者，

终端获取子模块4022，用于根据所述发起方的信息，从所述发起方所在终端获取所述发起方的联系人列表。

在本发明的一个实施例中，参考图6所示的匹配度计算模块的框图，所述匹配度计算模块403进一步可以包括如下子模块：

联系方式匹配子模块4031，用于将所述发起方的联系人列表中的各个联系人的联系方式与所述候选用户的联系人列表中的各个联系人的联系方式进行匹配，获取联系方式相同的联系人数量；

相同联系人计算子模块4032，用于将所述联系人数量和/或所述联系人数量在所述候选用户的联系人列表中的比例，作为所述发起方的联系人列表与所述候选用户的联系人列表之间的匹配度。

在本发明的一个实施例中，参考图7所示的联系信息获取模块的框图，所述联系信息获取模块402进一步可以包括如下子模块：

多联系人列表获取子模块4021，用于在预置的联系人数据库中，查找到与所述目标用户特征匹配的多个候选用户，分别获取所述多个候选用户的联系人列表。

在本发明的一个实施例中，参考图8所示的匹配度计算模块的框图，所述匹配度计算模块403进一步可以包括如下子模块：

多匹配度计算模块4033，用于分别计算所述发起方的联系人列表与各个候选用户的联系人列表之间的匹配度。

在图4的基础上，可选地，服务器400还可包括候选用户排序模块405，参见图9。

候选用户排序模块405，用于根据所述发起方的联系人列表与各个候选用户的联系人列表之间的匹配度，对各个候选用户进行排序。

在本发明的一个实施例中，参考图10所示的联系方式返回模块的框图，所述联系方式返回模块404进一步可以包括如下子模块：

排序返回子模块4041，用于将排序最前的预设数量的候选用户的联系方式返回给所述终端。

在图4的基础上，可选地，服务器400还可包括相关信息返回模块406，参见图11。

相关信息返回模块406，用于在所述匹配度满足预设条件时，将所述候选用户对应的终端的地理位置信息和/或所述候选用户的电话号码的归属地信息，返回给所述发起方所在终端。

服务器400能够实现图1至图3的方法实施例中服务器实现的各个过程，为避免重复，这里不再赘述。

这样，本发明实施例中，根据发起方的信息，获取发起方的联系人列表，并在预置的联系人数据库中，查找与目标用户特征匹配的候选用户，获取候选用户的联系人列表，通过计算发起方的联系人列表与候选用户的联系人列表之间的匹配度，当匹配度满足预设条件时，将候选用户的联系方式返回给终端，通过前期众多用户在云端共享联系方式，后期可以基于用户特征即可查询到想要联系的用户，避免了当面要联系方式和通过询问第三方用户，操作简便，大大提高了查询的及时性和实用性，同时，通过联系人信息之间的匹配度决定是否反馈用户的联系方式，可以保证联系方式的隐私性。

本领域普通技术人员可以意识到，结合本发明实施例中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。