本发明涉及数据查询技术领域， 具体而言， 涉及终端和联系人查找方 法。 背景技术

现有的各种移动终端中， 当用户对查找联系人时， 只能在自己的终端 的联系人数据库或云端数据库中进行查找， 当这些方式都不能得到查询结 果， 可能的方法是找电话与相熟悉的人进行询问， 过程繁瑣， 很容易耽误 用户的时间和精力， 而且相熟悉的人也不一定知道需要查找的联系 人的信 息， 因而成功率也无法保证。

因此， 需要一种新的联系人查找技术， 可以从其他用户的数据库中查 找到自身通讯录中没有的联系人信息。 发明内容

本发明正是基于上述问题， 提出了一种新的联系人查找技术， 可以从 其他用户的数据库中查找到自身通讯录中没有 的联系人信息。

有鉴于此， 本发明提出了一种终端， 包括： 查找单元， 用于在所述终 端对应的数据库中查找目标联系人； 请求生成单元， 用于在所述查找单元 查找失败的情况下， 将所述终端作为源终端， 并生成对应于所述源终端和 所述目标联系人的查询请求； 请求发送单元， 用于将所述查询请求发送至 与所述终端对应的相关联的终端， 以由所述相关联的终端执行下述查询过 程： 所述相关联的终端根据接收到的查询请求， 在其对应的数据库中查找 所述目标联系人， 若查找到， 则将所述目标联系人的信息返回所述源终 端， 否则重新生成所述查询请求， 并发送至与其相关联的其他终端， 或直 接将接收到的所述查询请求转发至与其相关联 的其他终端， 然后将所述其 他终端作为所述相关联的终端， 以重复执行所述查询过程； 以及信息接收 单元， 用于接收对应于所述查询请求的目标联系人的 信息。

在该技术方案中， 每个终端对应的数据库包括本地的联系人数据 库和 /或云端数据库， 本地的联系人数据库即存储在终端内部， 而云端数据库 则通过指定的识别码 （比如终端号码等） 与终端建立关联关系。 当源终端 从自身对应的数据库中无法查找到需要的联系 人信息时， 可以从与源终端 相关联的其他终端进行查找， 比如源终端的数据库中存在的联系人， 而如 果这些终端对应的数据库中也没有找到， 则还可以由与这些终端相关联的 终端做进一步的查找， 以此类推， 则可以形成一个类似树状的终端结构 图， 由源终端开始， 一级一级向下查找 （终端 A 发送给终端 Bl、 终端 B2 , 终端 B1 发送给终端 Cl l、 终端 C12 , 终端 B2 发送给终端 C21 ··· ··· ) , 从而极大地扩展了查找的数据库的大小， 增加了查找到目标 联系人的信息的机会。 由于上述过程均可以在终端的后台完成， 因而也不 会打扰到其他联系人。 当然， 出于对其他终端的信息安全考虑， 也可以在 接收到查询请求后， 由其他终端的用户进行确认后再执行查找， 或者可以 禁止查找。

在上述技术方案中， 优选地， 还包括： 信息设置单元， 用于根据接收 到的信息设置命令， 设置所述目标联系人的基本信息， 以确定与所述源终 端相关联的终端， 其中， 所述基本信息包括以下至少之一或其组合： 所述 目标联系人所属的用户分组、 归属地、 相关联的其他联系人。

在该技术方案中， 通过对需要查找的目标联系人的基本信息进行 设 置， 可以在用户终端的数据库中筛选出更有可能拥 有目标联系人的信息的 联系人， 以便缩短查找时间， 增加成功率。

在上述任一技术方案中， 优选地， 还包括： 数据获取单元， 用于获取 所述源终端与所述相关联的其他联系人的通信 数量 /频率； 以及数值比较 单元和 /或排序单元， 其中， 所述数值比较单元， 用于在所述通信数量 /频 率大于或等于预设数值的情况下， 选择对应的终端作为与所述源终端相关 联的终端； 所述排序单元， 用于对所述其他联系人进行排序， 并将排序最 靠前的预设数量的所述其他联系人对应的终端 作为与所述源终端相关联的 终端。

在该技术方案中， 与自己联系越多 /越频繁， 则接受查询请求的可能 性越高， 从而缩短查找时间， 增加查找成功的概率。 这里的通信可以包括 通话、 短信、 邮件、 社交网络交互信息等。

在上述任一技术方案中， 优选地， 还包括： 关联设定单元， 用于根据 接收到的关联设定命令， 确定与所述源终端相关联的终端。

在该技术方案中， 还可以由用户手动选择相关联的终端， 向认为有可 能查找到目标联系人的信息的终端发送查询请 求， 以增加查找成功的概 率。

在上述任一技术方案中， 优选地， 还包括： 次数设置单元， 用于根据 接收到的次数设置命令， 设置允许转发次数， 以由所述请求生成单元生成 对应于所述源终端、 所述目标联系人和所述允许转发次数的查询请 求， 以 由接收到该查询请求的终端对该允许转发次数 进行判断， 若该允许转发次 数大于或等于 1 , 则将该允许转发次数减 1 后得到新的允许转发次数， 并 重新生成对应于所述源终端、 所述目标联系人和所述新的允许转发次数的 新的查询请求后， 将所述新的查询请求发送至相关联的其他终端 。

在该技术方案中， 在接收到数次查询请求的转发之后， 可能仍没有查 找到目标联系人的信息， 那么， 将继续不断进行转发和查找， 而对于发起 查询请求的终端 （源终端） 而言， 尤其是如果一开始设置的相关联的终端 就存在偏差， 则终端可能将无限制地等待下去， 造成长时间的无响应， 从 而影响用户体验。 因此， 可以设置转发次数， 在设置的有限次的转发次数 内仍未查找到， 则向源终端返回失败信息。

在上述任一技术方案中， 优选地， 还包括： 编译单元， 用于将需要发 送的查询请求打包为请求短信， 以发送至相关联的终端， 其中， 所述相关 联的终端对接收到的短信的指定字段进行检测 ， 若与预设字段相符， 则判 定接收到的短信为所述请求短信， 并从所述请求短信中解析出所述查询请 求， 以查找对应的目标联系人。

在该技术方案中， 查询请求可以通过短信的方式进行发送， 这种短信 通过设置特定的字段， 从而与一般的短信进行区分， 便于终端对接收到的 短信的类型进行有效地分辨， 并及时进行处理。

根据本发明的又一方面， 还提出了一种联系人查找方法， 包括： 步骤

202 , 在源终端对应的数据库中查找目标联系人， 若查找失败， 则生成对 应于所述源终端和所述目标联系人的查询请求 ， 并发送至相关联的终端； 步骤 204, 获取所述目标联系人的信息， 其中， 所述目标联系人的信息是 由所述相关联的终端根据接收到的查询请求， 在其对应的数据库中查找到 的， 以及若未查找到， 则由所述相关联的终端重新生成所述查询请求 ， 并 发送至与其相关联的其他终端， 或直接将接收到的所述查询请求转发至与 其相关联的其他终端， 然后将所述其他终端作为所述相关联的终端， 以重 复执行所述步骤 204。

在该技术方案中， 每个终端对应的数据库包括本地的联系人数据 库和 /或云端数据库， 本地的联系人数据库即存储在终端内部， 而云端数据库 则通过指定的识别码 （比如终端号码等） 与终端建立关联关系。 当源终端 从自身对应的数据库中无法查找到需要的联系 人信息时， 可以从与源终端 相关联的其他终端进行查找， 比如源终端的数据库中存在的联系人， 而如 果这些终端对应的数据库中也没有找到， 则还可以由与这些终端相关联的 终端做进一步的查找， 以此类推， 则可以形成一个类似树状的终端结构 图， 由源终端开始， 一级一级向下查找 （终端 A 发送给终端 Bl、 终端 B2 , 终端 B1 发送给终端 Cl l、 终端 C12 , 终端 B2 发送给终端 C21 ··· ··· ) , 从而极大地扩展了查找的数据库的大小， 增加了查找到目标 联系人的信息的机会。 由于上述过程均可以在终端的后台完成， 因而也不 会打扰到其他联系人。 当然， 出于对其他终端的信息安全考虑， 也可以在 接收到查询请求后， 由其他终端的用户进行确认后再执行查找， 或者可以 禁止查找。

在上述技术方案中， 优选地， 所述步骤 202还包括： 根据接收到的信 息设置命令， 设置所述目标联系人的基本信息， 以确定与所述源终端相关 联的终端， 其中， 所述基本信息包括以下至少之一或其组合： 所述目标联 系人所属的用户分组、 归属地、 相关联的其他联系人。

在该技术方案中， 通过对需要查找的目标联系人的基本信息进行 设 置， 可以在用户终端的数据库中筛选出更有可能拥 有目标联系人的信息的 联系人， 以便缩短查找时间， 增加成功率。

在上述任一技术方案中， 优选地， 所述步骤 202还包括： 获取所述源 终端与所述相关联的其他联系人的通信数量 /频率， 当所述通信数量 /频率 大于或等于预设数值时， 选择对应的终端作为与所述源终端相关联的终 端； 和 /或按照所述通信数量 /频率， 对所述其他联系人进行排序， 并将排 序最靠前的预设数量的所述其他联系人对应的 终端作为与所述源终端相关 联的终端。

在该技术方案中， 与自己联系越多 /越频繁， 则接受查询请求的可能 性越高， 从而缩短查找时间， 增加查找成功的概率。 这里的通信可以包括 通话、 短信、 邮件、 社交网络交互信息等。

在上述任一技术方案中， 优选地， 所述步骤 202还包括： 根据接收到 的关联设定命令， 确定与所述源终端相关联的终端。

在该技术方案中， 还可以由用户手动选择相关联的终端， 向认为有可 能查找到目标联系人的信息的终端发送查询请 求， 以增加查找成功的概 率。

在上述任一技术方案中， 优选地， 还包括： 所述查询请求中包含有预 设的允许转发次数， 若从接收到的查询请求中获取的允许转发次数 大于或 等于 1 , 则将该允许转发次数减 1 后得到新的允许转发次数； 以及重新生 成对应于所述源终端、 所述目标联系人和所述新的允许转发次数的新 的查 询请求， 并将所述新的查询请求发送至相关联的其他终 端。

在该技术方案中， 在接收到数次查询请求的转发之后， 可能仍没有查 找到目标联系人的信息， 那么， 将继续不断进行转发和查找， 而对于发起 查询请求的终端 （源终端） 而言， 尤其是如果一开始设置的相关联的终端 就存在偏差， 则终端可能将无限制地等待下去， 造成长时间的无响应， 从 而影响用户体验。 因此， 可以设置转发次数， 在设置的有限次的转发次数 内仍未查找到， 则向源终端返回失败信息。

在上述任一技术方案中， 优选地， 还包括： 将需要发送的查询请求打 包为请求短信， 以发送至相关联的终端， 其中， 所述相关联的终端对接收 到的短信的指定字段进行检测， 若与预设字段相符， 则判定接收到的短信 为所述请求短信， 并从所述请求短信中解析出所述查询请求， 以查找对应 的目标联系人。

在该技术方案中， 查询请求可以通过短信的方式进行发送， 这种短信 通过设置特定的字段， 从而与一般的短信进行区分， 便于终端对接收到的 短信的类型进行有效地分辨， 并及时进行处理。

本发明还提出了一种终端， 包括： 请求接收单元， 用于接收来自其他 终端的查询请求； 查找单元， 用于根据所述查询请求， 在对应的数据库中 查找目标联系人； 信息发送单元， 用于在所述查找单元查找成功的情况 下， 从所述查询请求中解析出源终端， 并将所述目标联系人的信息发送至 所述源终端； 请求发送单元， 用于在所述查找单元查找失败的情况下， 将 重新生成的所述查询请求发送至相关联的终端 ， 或直接将接收到的所述查 询请求转发至相关联的终端， 以供所述相关联的终端继续进行查找。

在该技术方案中， 每个终端对应的数据库包括本地的联系人数据 库和 /或云端数据库， 本地的联系人数据库即存储在终端内部， 而云端数据库 则通过指定的识别码 （比如终端号码等） 与终端建立关联关系。 当源终端 从自身对应的数据库中无法查找到需要的联系 人信息时， 可以从与源终端 相关联的其他终端进行查找， 比如源终端的数据库中存在的联系人， 而如 果这些终端对应的数据库中也没有找到， 则还可以由与这些终端相关联的 终端做进一步的查找， 以此类推， 则可以形成一个类似树状的终端结构 图， 由源终端开始， 一级一级向下查找 （终端 A 发送给终端 Bl、 终端 B2 , 终端 B1 发送给终端 Cl l、 终端 C12 , 终端 B2 发送给终端 C21 ··· ··· ) , 从而极大地扩展了查找的数据库的大小， 增加了查找到目标 联系人的信息的机会。 由于上述过程均可以在终端的后台完成， 因而也不 会打扰到其他联系人。 当然， 出于对其他终端的信息安全考虑， 也可以在 接收到查询请求后， 由其他终端的用户进行确认后再执行查找， 或者可以 禁止查找。

在上述技术方案中， 优选地， 还包括： 信息设置单元， 用于根据接收 到的信息设置命令， 设置所述目标联系人的基本信息， 以确定所述相关联 的终端， 其中， 所述基本信息包括以下至少之一或其组合： 所述目标联系 人所属的用户分组、 归属地、 相关联的其他联系人。

在该技术方案中， 通过对需要查找的目标联系人的基本信息进行 设 置， 可以在用户终端的数据库中筛选出更有可能拥 有目标联系人的信息的 联系人， 以便缩短查找时间， 增加成功率。

在上述任一技术方案中， 优选地， 还包括： 数据获取单元， 用于获取 所述终端与所述相关联的其他联系人的通信数 量 /频率； 以及数值比较单 元和 /或排序单元， 其中， 所述数值比较单元， 用于在所述通信数量 /频率 大于或等于预设数值的情况下， 选择对应的终端作为所述相关联的终端； 所述排序单元， 用于对所述其他联系人进行排序， 并将排序最靠前的预设 数量的所述其他联系人对应的终端作为所述相 关联的终端。

在该技术方案中， 与自己联系越多 /越频繁， 则接受查询请求的可能 性越高， 从而缩短查找时间， 增加查找成功的概率。 这里的通信可以包括 通话、 短信、 邮件、 社交网络交互信息等。

在上述任一技术方案中， 优选地， 还包括： 关联设定单元， 用于根据 接收到的关联设定命令， 确定所述相关联的终端。

在该技术方案中， 还可以由用户手动选择相关联的终端， 向认为有可 能查找到目标联系人的信息的终端发送查询请 求， 以增加查找成功的概 率。

在上述任一技术方案中， 优选地， 所述查询请求中包含有预设的允许 转发次数， 则所述终端还包括： 次数判断单元， 用于判断从接收到的查询 请求中获取的允许转发次数是否大于或等于 1 ; 次数处理单元， 用于在所 述次数判断单元的判断结果为是的情况下， 将该允许转发次数减 1后得到 新的允许转发次数； 以及请求生成单元， 用于生成对应于所述源终端、 所 述目标联系人和所述新的允许转发次数的新的 查询请求， 以由所述请求发 送单元将所述新的查询请求发送至所述相关联 的终端。

在该技术方案中， 在接收到数次查询请求的转发之后， 可能仍没有查 找到目标联系人的信息， 那么， 将继续不断进行转发和查找， 而对于发起 查询请求的终端 （源终端） 而言， 尤其是如果一开始设置的相关联的终端 就存在偏差， 则终端可能将无限制地等待下去， 造成长时间的无响应， 从 而影响用户体验。 因此， 可以设置转发次数， 在设置的有限次的转发次数 内仍未查找到， 则向源终端返回失败信息。

在上述任一技术方案中， 优选地， 还包括： 字段检测单元， 用于对接 收到的短信的指定字段进行检测， 若与预设字段相符， 则判定接收到的短 信为请求短信； 解析单元， 用于在所述字段检测单元判定所述短信为请求 短信的情况下， 从所述请求短信中解析出所述查询请求， 以由所述查找单 元查找对应的目标联系人。

在上述任一技术方案中， 优选地， 还包括： 编译单元， 用于将需要发 送的查询请求打包为请求短信， 以发送至相关联的终端。

在该技术方案中， 查询请求可以通过短信的方式进行发送， 这种短信 通过设置特定的字段， 从而与一般的短信进行区分， 便于终端对接收到的 短信的类型进行有效地分辨， 并及时进行处理。

根据本发明的又一方面， 还提出了一种联系人查找方法， 包括： 接收 来自其他终端的查询请求； 根据所述查询请求， 在对应的数据库中查找目 标联系人； 若查找成功， 则从所述查询请求中解析出源终端， 并将所述目 标联系人的信息发送至所述源终端， 否则重新生成所述查询请求， 并发送 至相关联的终端， 或直接将接收到的所述查询请求转发至相关联 的终端， 以供所述相关联的终端继续进行查找。

在该技术方案中， 每个终端对应的数据库包括本地的联系人数据 库和 /或云端数据库， 本地的联系人数据库即存储在终端内部， 而云端数据库 则通过指定的识别码 （比如终端号码等） 与终端建立关联关系。 当源终端 从自身对应的数据库中无法查找到需要的联系 人信息时， 可以从与源终端 相关联的其他终端进行查找， 比如源终端的数据库中存在的联系人， 而如 果这些终端对应的数据库中也没有找到， 则还可以由与这些终端相关联的 终端做进一步的查找， 以此类推， 则可以形成一个类似树状的终端结构 图， 由源终端开始， 一级一级向下查找 （终端 A 发送给终端 Bl、 终端 B2 , 终端 B1 发送给终端 Cl l、 终端 C12 , 终端 B2 发送给终端 C21 ··· ··· ) , 从而极大地扩展了查找的数据库的大小， 增加了查找到目标 联系人的信息的机会。 由于上述过程均可以在终端的后台完成， 因而也不 会打扰到其他联系人。 当然， 出于对其他终端的信息安全考虑， 也可以在 接收到查询请求后， 由其他终端的用户进行确认后再执行查找， 或者可以 禁止查找。

在上述技术方案中， 优选地， 在发送所述查询请求之前， 还包括： 根 据接收到的信息设置命令， 设置所述目标联系人的基本信息， 以确定所述 相关联的终端， 其中， 所述基本信息包括以下至少之一或其组合： 所述目 标联系人所属的用户分组、 归属地、 相关联的其他联系人。

在该技术方案中， 通过对需要查找的目标联系人的基本信息进行 设 置， 可以在用户终端的数据库中筛选出更有可能拥 有目标联系人的信息的 联系人， 以便缩短查找时间， 增加成功率。

在上述任一技术方案中， 优选地， 还包括： 获取与所述相关联的其他 联系人的通信数量 /频率， 当所述通信数量 /频率大于或等于预设数值时， 选择对应的终端作为所述相关联的终端； 和 /或按照所述通信数量 /频率， 对所述其他联系人进行排序， 将排序最靠前的预设数量的所述其他联系人 对应的终端作为所述相关联的终端。

在该技术方案中， 与自己联系越多 /越频繁， 则接受查询请求的可能 性越高， 从而缩短查找时间， 增加查找成功的概率。 这里的通信可以包括 通话、 短信、 邮件、 社交网络交互信息等。

在上述任一技术方案中， 优选地， 在发送所述查询请求之前， 还包 括： 根据接收到的查找设定命令， 确定所述相关联的终端。

在该技术方案中， 还可以由用户手动选择相关联的终端， 向认为有可 能查找到目标联系人的信息的终端发送查询请 求， 以增加查找成功的概 率。

在上述任一技术方案中， 优选地， 所述查询请求中包含有预设的允许 转发次数； 当查找失败时， 若从接收到的查询请求中获取的允许转发次数 大于或等于 1 , 则将该允许转发次数减 1 后得到新的允许转发次数； 以及 生成对应于所述源终端、 所述目标联系人和所述新的允许转发次数的新 的 查询请求， 并将所述新的查询请求发送至所述相关联的终 端。 在该技术方案中， 在接收到数次查询请求的转发之后， 可能仍没有查 找到目标联系人的信息， 那么， 将继续不断进行转发和查找， 而对于发起 查询请求的终端 （源终端） 而言， 尤其是如果一开始设置的相关联的终端 就存在偏差， 则终端可能将无限制地等待下去， 造成长时间的无响应， 从 而影响用户体验。 因此， 可以设置转发次数， 在设置的有限次的转发次数 内仍未查找到， 则向源终端返回失败信息。

在上述任一技术方案中， 优选地， 还包括： 对接收到的短信的指定字 段进行检测， 若与预设字段相符， 则判定接收到的短信为所述请求短信， 并从所述请求短信中解析出所述查询请求， 以查找对应的目标联系人。

在上述任一技术方案中， 优选地， 还包括： 将需要发送的查询请求打 包为请求短信， 以发送至所述相关联的终端。

在该技术方案中， 查询请求可以通过短信的方式进行发送， 这种短信 通过设置特定的字段， 从而与一般的短信进行区分， 便于终端对接收到的 短信的类型进行有效地分辨， 并及时进行处理。

通过以上技术方案， 可以从其他用户的数据库中查找到自身通讯录 中 没有的联系人信息。 附图说明

图 1示出了根据本发明的一个实施例的终端的框� �；

图 2示出了根据本发明的一个实施例的联系人查� �方法的流程图； 图 3示出了根据本发明的另一个实施例的终端的� �图；

图 4示出了根据本发明的另一个实施例的联系人� �找方法的流程图； 图 5示出了根据本发明的一个实施例的终端发送� �询请求的流程示意 图 6示出了根据本发明的一个实施例的终端接收� �询请求的流程示意 图 7示出了根据本发明的一个实施例的查询联系� �的各终端之间的结 具体实施方式

为了能够更清楚地理解本发明的上述目的、 特征和优点， 下面结合附 图和具体实施方式对本发明进行进一步的详细 描述。 需要说明的是， 在不 沖突的情况下， 本申请的实施例及实施例中的特征可以相互组 合。

在下面的描述中阐述了很多具体细节以便于充 分理解本发明， 但是， 本发明还可以采用其他不同于在此描述的其他 方式来实施， 因此， 本发明 的保护范围并不受下面公开的具体实施例的限 制。

图 1示出了根据本发明的一个实施例的终端的框� �。

如图 1 所示， 根据本发明的一个实施例的终端 100, 包括： 查找单元 102 , 用于在所述终端 100 对应的数据库中查找目标联系人； 请求生成单 元 104, 用于在所述查找单元 102查找失败的情况下， 将所述终端 100作 为源终端， 并生成对应于所述源终端和所述目标联系人的 查询请求； 请求 发送单元 106, 用于将所述查询请求发送至与所述终端 100对应的相关联 的终端， 以由所述相关联的终端执行下述查询过程： 所述相关联的终端根 据接收到的查询请求， 在其对应的数据库中查找所述目标联系人， 若查找 到， 则将所述目标联系人的信息返回所述源终端， 否则重新生成所述查询 请求， 并发送至与其相关联的其他终端， 或直接将接收到的所述查询请求 转发至与其相关联的其他终端， 然后将所述其他终端作为所述相关联的终 端， 以重复执行所述查询过程； 以及信息接收单元 108 , 用于接收对应于 所述查询请求的目标联系人的信息。

在该技术方案中， 每个终端 （包括源终端和其他终端） 对应的数据库 包括本地的联系人数据库和 /或云端数据库， 本地的联系人数据库即存储 在终端内部， 而云端数据库则通过指定的识别码 （比如终端号码等） 与终 端建立关联关系。 当源终端从自身对应的数据库中无法查找到需 要的联系 人信息时， 可以从与源终端相关联的其他终端进行查找， 比如源终端的数 据库中存在的联系人， 而如果这些终端对应的数据库中也没有找到， 则还 可以由与这些终端相关联的终端做进一步的查 找， 以此类推， 则可以形成 一个类似树状的终端结构图， 由源终端开始， 一级一级向下查找 （终端 A 发送给终端 Bl、 终端 B2, 终端 B1发送给终端 Cl l、 终端 C12, 终端 B2 发送给终端 C21 ··· ··· ) , 从而极大地扩展了查找的数据库的大小， 增加了 查找到目标联系人的信息的机会。 由于上述过程均可以在终端的后台完 成， 因而也不会打扰到其他联系人。 当然， 出于对其他终端的信息安全考 虑， 也可以在接收到查询请求后， 由其他终端的用户进行确认后再执行查 找， 或者可以禁止查找。

在上述技术方案中， 优选地， 还包括： 信息设置单元 110 , 用于根据 接收到的信息设置命令， 设置所述目标联系人的基本信息， 以确定与所述 源终端相关联的终端， 其中， 所述基本信息包括以下至少之一或其组合： 所述目标联系人所属的用户分组、 归属地、 相关联的其他联系人。

在该技术方案中， 通过对需要查找的目标联系人的基本信息进行 设 置， 可以在用户终端的数据库中筛选出更有可能拥 有目标联系人的信息的 联系人， 以便缩短查找时间， 增加成功率。

在上述任一技术方案中， 优选地， 还包括： 数据获取单元 1 12 , 用于 获取所述源终端与所述相关联的其他联系人的 通信数量 /频率； 以及数值 比较单元 1 14和 /或排序单元 116, 其中， 所述数值比较单元 114, 用于在 所述通信数量 /频率大于或等于预设数值的情况下， 选择对应的终端作为 与所述源终端相关联的终端； 所述排序单元 116 , 用于对所述其他联系人 进行排序， 并将排序最靠前的预设数量的所述其他联系人 对应的终端作为 与所述源终端相关联的终端。

在该技术方案中， 与自己联系越多 /越频繁， 则接受查询请求的可能 性越高， 从而缩短查找时间， 增加查找成功的概率。 这里的通信可以包括 通话、 短信、 邮件、 社交网络交互信息等。

在上述任一技术方案中， 优选地， 还包括： 关联设定单元 1 18 , 用于 根据接收到的关联设定命令， 确定与所述源终端相关联的终端。

在该技术方案中， 还可以由用户手动选择相关联的终端， 向认为有可 能查找到目标联系人的信息的终端发送查询请 求， 以增加查找成功的概 率。

在上述任一技术方案中， 优选地， 还包括： 次数设置单元 120 , 用于 根据接收到的次数设置命令， 设置允许转发次数， 以由所述请求生成单元 104 生成对应于所述源终端、 所述目标联系人和所述允许转发次数的查询 请求， 以由接收到该查询请求的终端对该允许转发次 数进行判断， 若该允 许转发次数大于或等于 1 , 则将该允许转发次数减 1 后得到新的允许转发 次数， 并重新生成对应于所述源终端、 所述目标联系人和所述新的允许转 发次数的新的查询请求后， 将所述新的查询请求发送至相关联的其他终 端。

在该技术方案中， 在接收到数次查询请求的转发之后， 可能仍没有查 找到目标联系人的信息， 那么， 将继续不断进行转发和查找， 而对于发起 查询请求的终端 （源终端） 而言， 尤其是如果一开始设置的相关联的终端 就存在偏差， 则终端可能将无限制地等待下去， 造成长时间的无响应， 从 而影响用户体验。 因此， 可以设置转发次数， 在设置的有限次的转发次数 内仍未查找到， 则向源终端返回失败信息。

在上述任一技术方案中， 优选地， 还包括： 编译单元 122 , 用于将需 要发送的查询请求打包为请求短信， 以发送至相关联的终端， 其中， 所述 相关联的终端对接收到的短信的指定字段进行 检测， 若与预设字段相符， 则判定接收到的短信为所述请求短信， 并从所述请求短信中解析出所述查 询请求， 以查找对应的目标联系人。

在该技术方案中， 查询请求可以通过短信的方式进行发送， 这种短信 通过设置特定的字段， 从而与一般的短信进行区分， 便于终端对接收到的 短信的类型进行有效地分辨， 并及时进行处理。

图 2示出了根据本发明的一个实施例的联系人查� �方法的流程图。 如图 2所示， 根据本发明的一个实施例的联系人查找方法， 包括： 步 骤 202 , 在源终端对应的数据库中查找目标联系人， 若查找失败， 则生成 对应于所述源终端和所述目标联系人的查询请 求， 并发送至相关联的终 端； 步骤 204, 获取所述目标联系人的信息， 其中， 所述目标联系人的信 息是由所述相关联的终端根据接收到的查询请 求， 在其对应的数据库中查 找到的， 以及若未查找到， 则由所述相关联的终端重新生成所述查询请 求， 并发送至与其相关联的其他终端， 或直接将接收到的所述查询请求转 发至与其相关联的其他终端， 然后将所述其他终端作为所述相关联的终 端， 以重复执行所述步骤 204。

在该技术方案中， 每个终端对应的数据库包括本地的联系人数据 库和 /或云端数据库， 本地的联系人数据库即存储在终端内部， 而云端数据库 则通过指定的识别码 （比如终端号码等） 与终端建立关联关系。 当源终端 从自身对应的数据库中无法查找到需要的联系 人信息时， 可以从与源终端 相关联的其他终端进行查找， 比如源终端的数据库中存在的联系人， 而如 果这些终端对应的数据库中也没有找到， 则还可以由与这些终端相关联的 终端做进一步的查找， 以此类推， 则可以形成一个类似树状的终端结构 图， 由源终端开始， 一级一级向下查找 （终端 A 发送给终端 Bl、 终端 B2 , 终端 B1 发送给终端 Cl l、 终端 C12 , 终端 B2 发送给终端 C21 ··· ··· ) , 从而极大地扩展了查找的数据库的大小， 增加了查找到目标 联系人的信息的机会。 由于上述过程均可以在终端的后台完成， 因而也不 会打扰到其他联系人。 当然， 出于对其他终端的信息安全考虑， 也可以在 接收到查询请求后， 由其他终端的用户进行确认后再执行查找， 或者可以 禁止查找。

在上述技术方案中， 优选地， 所述步骤 202还包括： 根据接收到的信 息设置命令， 设置所述目标联系人的基本信息， 以确定与所述源终端相关 联的终端， 其中， 所述基本信息包括以下至少之一或其组合： 所述目标联 系人所属的用户分组、 归属地、 相关联的其他联系人。

在该技术方案中， 通过对需要查找的目标联系人的基本信息进行 设 置， 可以在用户终端的数据库中筛选出更有可能拥 有目标联系人的信息的 联系人， 以便缩短查找时间， 增加成功率。

在上述任一技术方案中， 优选地， 所述步骤 202还包括： 获取所述源 终端与所述相关联的其他联系人的通信数量 /频率， 当所述通信数量 /频率 大于或等于预设数值时， 选择对应的终端作为与所述源终端相关联的终 端； 和 /或按照所述通信数量 /频率， 对所述其他联系人进行排序， 并将排 序最靠前的预设数量的所述其他联系人对应的 终端作为与所述源终端相关 联的终端。

在该技术方案中， 与自己联系越多 /越频繁， 则接受查询请求的可能 性越高， 从而缩短查找时间， 增加查找成功的概率。 这里的通信可以包括 通话、 短信、 邮件、 社交网络交互信息等。

在上述任一技术方案中， 优选地， 所述步骤 202还包括： 根据接收到 的关联设定命令， 确定与所述源终端相关联的终端。

在该技术方案中， 还可以由用户手动选择相关联的终端， 向认为有可 能查找到目标联系人的信息的终端发送查询请 求， 以增加查找成功的概 率。

在上述任一技术方案中， 优选地， 还包括： 所述查询请求中包含有预 设的允许转发次数， 若从接收到的查询请求中获取的允许转发次数 大于或 等于 1 , 则将该允许转发次数减 1 后得到新的允许转发次数； 以及重新生 成对应于所述源终端、 所述目标联系人和所述新的允许转发次数的新 的查 询请求， 并将所述新的查询请求发送至相关联的其他终 端。

在该技术方案中， 在接收到数次查询请求的转发之后， 可能仍没有查 找到目标联系人的信息， 那么， 将继续不断进行转发和查找， 而对于发起 查询请求的终端 （源终端） 而言， 尤其是如果一开始设置的相关联的终端 就存在偏差， 则终端可能将无限制地等待下去， 造成长时间的无响应， 从 而影响用户体验。 因此， 可以设置转发次数， 在设置的有限次的转发次数 内仍未查找到， 则向源终端返回失败信息。

在上述任一技术方案中， 优选地， 还包括： 将需要发送的查询请求打 包为请求短信， 以发送至相关联的终端， 其中， 所述相关联的终端对接收 到的短信的指定字段进行检测， 若与预设字段相符， 则判定接收到的短信 为所述请求短信， 并从所述请求短信中解析出所述查询请求， 以查找对应 的目标联系人。

在该技术方案中， 查询请求可以通过短信的方式进行发送， 这种短信 通过设置特定的字段， 从而与一般的短信进行区分， 便于终端对接收到的 短信的类型进行有效地分辨， 并及时进行处理。

图 3示出了根据本发明的另一个实施例的终端的� �图。

如图 3 所示， 根据本发明的另一个实施例的终端 300, 包括： 请求接 收单元 302 , 用于接收来自其他终端的查询请求； 查找单元 304 , 用于根 据所述查询请求， 在对应的数据库中查找目标联系人； 信息发送单元

306, 用于在所述查找单元 304 查找成功的情况下， 从所述查询请求中解 析出源终端， 并将所述目标联系人的信息发送至所述源终端 ； 请求发送单 元 308, 用于在所述查找单元 304查找失败的情况下， 将重新生成的所述 查询请求发送至相关联的终端， 或直接将接收到的所述查询请求转发至相 关联的终端， 以供所述相关联的终端继续进行查找。

在该技术方案中， 每个终端对应的数据库包括本地的联系人数据 库和 /或云端数据库， 本地的联系人数据库即存储在终端内部， 而云端数据库 则通过指定的识别码 （比如终端号码等） 与终端建立关联关系。 当源终端 从自身对应的数据库中无法查找到需要的联系 人信息时， 可以从与源终端 相关联的其他终端进行查找， 比如源终端的数据库中存在的联系人， 而如 果这些终端对应的数据库中也没有找到， 则还可以由与这些终端相关联的 终端做进一步的查找， 以此类推， 则可以形成一个类似树状的终端结构 图， 由源终端开始， 一级一级向下查找 （终端 A 发送给终端 Bl、 终端 B2 , 终端 B1 发送给终端 Cl l、 终端 C12 , 终端 B2 发送给终端 C21 ··· ··· ) , 从而极大地扩展了查找的数据库的大小， 增加了查找到目标 联系人的信息的机会。 由于上述过程均可以在终端的后台完成， 因而也不 会打扰到其他联系人。 当然， 出于对其他终端的信息安全考虑， 也可以在 接收到查询请求后， 由其他终端的用户进行确认后再执行查找， 或者可以 禁止查找。

在上述技术方案中， 优选地， 还包括： 信息设置单元 310, 用于根据 接收到的信息设置命令， 设置所述目标联系人的基本信息， 以确定所述相 关联的终端， 其中， 所述基本信息包括以下至少之一或其组合： 所述目标 联系人所属的用户分组、 归属地、 相关联的其他联系人。

在该技术方案中， 通过对需要查找的目标联系人的基本信息进行 设 置， 可以在用户终端的数据库中筛选出更有可能拥 有目标联系人的信息的 联系人， 以便缩短查找时间， 增加成功率。

在上述任一技术方案中， 优选地， 还包括： 数据获取单元 312 , 用于 获取所述终端 300 与所述相关联的其他联系人的通信数量 /频率； 以及数 值比较单元 314和 /或排序单元 316 , 其中， 所述数值比较单元 314 , 用于 在所述通信数量 /频率大于或等于预设数值的情况下， 选择对应的终端作 为所述相关联的终端； 所述排序单元 316 , 用于对所述其他联系人进行排 序， 并将排序最靠前的预设数量的所述其他联系人 对应的终端作为所述相 关联的终端。

在该技术方案中， 与自己联系越多 /越频繁， 则接受查询请求的可能 性越高， 从而缩短查找时间， 增加查找成功的概率。 这里的通信可以包括 通话、 短信、 邮件、 社交网络交互信息等。

在上述任一技术方案中， 优选地， 还包括： 关联设定单元 318 , 用于 根据接收到的关联设定命令， 确定所述相关联的终端。

在该技术方案中， 还可以由用户手动选择相关联的终端， 向认为有可 能查找到目标联系人的信息的终端发送查询请 求， 以增加查找成功的概 率。

在上述任一技术方案中， 优选地， 所述查询请求中包含有预设的允许 转发次数， 则所述终端 300还包括： 次数判断单元 320 , 用于判断从接收 到的查询请求中获取的允许转发次数是否大于 或等于 1 ; 次数处理单元 322 , 用于在所述次数判断单元 320 的判断结果为是的情况下， 将该允许 转发次数减 1 后得到新的允许转发次数； 以及请求生成单元 324 , 用于生 成对应于所述源终端、 所述目标联系人和所述新的允许转发次数的新 的查 询请求， 以由所述请求发送单元 308将所述新的查询请求发送至所述相关 联的终端。

在该技术方案中， 在接收到数次查询请求的转发之后， 可能仍没有查 找到目标联系人的信息， 那么， 将继续不断进行转发和查找， 而对于发起 查询请求的终端 （源终端） 而言， 尤其是如果一开始设置的相关联的终端 就存在偏差， 则终端可能将无限制地等待下去， 造成长时间的无响应， 从 而影响用户体验。 因此， 可以设置转发次数， 在设置的有限次的转发次数 内仍未查找到， 则向源终端返回失败信息。

在上述任一技术方案中， 优选地， 还包括： 字段检测单元 326 , 用于 对接收到的短信的指定字段进行检测， 若与预设字段相符， 则判定接收到 的短信为请求短信； 解析单元 328 , 用于在所述字段检测单元 326判定所 述短信为请求短信的情况下， 从所述请求短信中解析出所述查询请求， 以 由所述查找单元 304查找对应的目标联系人。

在上述任一技术方案中， 优选地， 还包括： 编译单元 330, 用于将需 要发送的查询请求打包为请求短信， 以发送至相关联的终端。

在该技术方案中， 查询请求可以通过短信的方式进行发送， 这种短信 通过设置特定的字段， 从而与一般的短信进行区分， 便于终端对接收到的 短信的类型进行有效地分辨， 并及时进行处理。

图 4示出了根据本发明的另一个实施例的联系人� �找方法的流程图。 如图 4所示， 根据本发明的另一个实施例的联系人查找方法 ， 包括： 步骤 402 , 接收来自其他终端的查询请求； 步骤 404 , 根据所述查询请 求， 在对应的数据库中查找目标联系人； 步骤 406, 若查找成功， 则从所 述查询请求中解析出源终端， 并将所述目标联系人的信息发送至所述源终 端， 否则重新生成所述查询请求， 并发送至相关联的终端， 或直接将接收 到的所述查询请求转发至相关联的终端， 以供所述相关联的终端继续进行 查找。

在该技术方案中， 每个终端对应的数据库包括本地的联系人数据 库和 /或云端数据库， 本地的联系人数据库即存储在终端内部， 而云端数据库 则通过指定的识别码 （比如终端号码等） 与终端建立关联关系。 当源终端 从自身对应的数据库中无法查找到需要的联系 人信息时， 可以从与源终端 相关联的其他终端进行查找， 比如源终端的数据库中存在的联系人， 而如 果这些终端对应的数据库中也没有找到， 则还可以由与这些终端相关联的 终端做进一步的查找， 以此类推， 则可以形成一个类似树状的终端结构 图， 由源终端开始， 一级一级向下查找 （终端 A 发送给终端 Bl、 终端 B2 , 终端 B1 发送给终端 Cl l、 终端 C12 , 终端 B2 发送给终端 C21 ··· ··· ) , 从而极大地扩展了查找的数据库的大小， 增加了查找到目标 联系人的信息的机会。 由于上述过程均可以在终端的后台完成， 因而也不 会打扰到其他联系人。 当然， 出于对其他终端的信息安全考虑， 也可以在 接收到查询请求后， 由其他终端的用户进行确认后再执行查找， 或者可以 禁止查找。

在上述技术方案中， 优选地， 在发送所述查询请求之前， 还包括： 根 据接收到的信息设置命令， 设置所述目标联系人的基本信息， 以确定所述 相关联的终端， 其中， 所述基本信息包括以下至少之一或其组合： 所述目 标联系人所属的用户分组、 归属地、 相关联的其他联系人。

在该技术方案中， 通过对需要查找的目标联系人的基本信息进行 设 置， 可以在用户终端的数据库中筛选出更有可能拥 有目标联系人的信息的 联系人， 以便缩短查找时间， 增加成功率。

在上述任一技术方案中， 优选地， 还包括： 获取与所述相关联的其他 联系人的通信数量 /频率， 当所述通信数量 /频率大于或等于预设数值时， 选择对应的终端作为所述相关联的终端； 和 /或按照所述通信数量 /频率， 对所述其他联系人进行排序， 将排序最靠前的预设数量的所述其他联系人 对应的终端作为所述相关联的终端。

在该技术方案中， 与自己联系越多 /越频繁， 则接受查询请求的可能 性越高， 从而缩短查找时间， 增加查找成功的概率。 这里的通信可以包括 通话、 短信、 邮件、 社交网络交互信息等。

在上述任一技术方案中， 优选地， 在发送所述查询请求之前， 还包 括： 根据接收到的查找设定命令， 确定所述相关联的终端。

在该技术方案中， 还可以由用户手动选择相关联的终端， 向认为有可 能查找到目标联系人的信息的终端发送查询请 求， 以增加查找成功的概 率。

在上述任一技术方案中， 优选地， 所述查询请求中包含有预设的允许 转发次数； 当查找失败时， 若从接收到的查询请求中获取的允许转发次数 大于或等于 1 , 则将该允许转发次数减 1 后得到新的允许转发次数； 以及 生成对应于所述源终端、 所述目标联系人和所述新的允许转发次数的新 的 查询请求， 并将所述新的查询请求发送至所述相关联的终 端。

在该技术方案中， 在接收到数次查询请求的转发之后， 可能仍没有查 找到目标联系人的信息， 那么， 将继续不断进行转发和查找， 而对于发起 查询请求的终端 （源终端） 而言， 尤其是如果一开始设置的相关联的终端 就存在偏差， 则终端可能将无限制地等待下去， 造成长时间的无响应， 从 而影响用户体验。 因此， 可以设置转发次数， 在设置的有限次的转发次数 内仍未查找到， 则向源终端返回失败信息。

在上述任一技术方案中， 优选地， 还包括： 对接收到的短信的指定字 段进行检测， 若与预设字段相符， 则判定接收到的短信为所述请求短信， 并从所述请求短信中解析出所述查询请求， 以查找对应的目标联系人。

在上述任一技术方案中， 优选地， 还包括： 将需要发送的查询请求打 包为请求短信， 以发送至所述相关联的终端。

在该技术方案中， 查询请求可以通过短信的方式进行发送， 这种短信 通过设置特定的字段， 从而与一般的短信进行区分， 便于终端对接收到的 短信的类型进行有效地分辨， 并及时进行处理。

图 5示出了根据本发明的一个实施例的终端发送� �询请求的流程示意 图。

如图 5所示， 根据本发明的一个实施例的终端发送查询请求 的流程包 括：

步骤 502 , 终端查找对应的数据库， 包括终端自身的存储空间中的联 系人数据库， 以及云端数据库， 该云端数据库通过指定的识别码 （比如终 端号码） 与该终端保持关联关系， 用于存储终端的相关信息。

步骤 504 , 若查找到， 则结束流程， 否则进入步骤 506。

步骤 506 , 将查询内容和路由数据生成查询请求， 其中， 查询内容包 括所需要查询的联系人的基本信息， 比如姓名、 归属地、 相关联的联系人 等信息， 便于进行查询， 而路由数据则是用于限制查询请求的转发次数 ， 若不进行限制， 则可能在终端之间进行无限制转发和查询， 使得用户长时 间得不到查询响应， 影响用户的使用体验， 也浪费终端的运行资源。

步骤 508 , 确定发送对象， 终端在自身对应的数据库中无法查询到目 标联系人信息时， 需要通过发送查询请求， 从而借由其他终端在对应的数 据库中进行查询， 并返回给最初的终端， 因此， 选定合适的发送对象， 有 利于缩短查询时间、 增加查询的成功率。 具体地， 可以根据目标联系人的 分组、 归属地、 相关联的联系人、 与终端最常联系的联系人等信息， 综合 确定最有可能查询到的对象， 并向其发送查询请求。

步骤 510 , 向确定的对象发送查询请求， 以期获取对应的查询结果。 相应地， 图 6示出了根据本发明的一个实施例的终端接收� �询请求的 流程示意图。

如图 6所示， 根据本发明的一个实施例的终端接收查询请求 的流程包 括：

步骤 602 , 终端接收到来自其他终端的短信。

步骤 604 , 判断接收到的短信是否为查询请求， 若是， 则进入步骤 606 , 否则结束该流程， 并按照正常情况对该短信进行处理。 具体地， 在 判断时， 可以通过对短信的指定字段进行检测， 如果与预设字段相符， 则 认定该短信为查询请求。

步骤 606 , 按照查询请求查询目标联系人的信息， 包括在本地或云端 的数据库中进行查询。

步骤 608 , 是否查询成功， 若成功， 则进入步骤 612 , 否则进入步骤

610。

步骤 610 , 是否将查询请求转发至其他终端， 这里可以通过自动和被 动的方式实现， 对于自动的情况下， 可以在最初生成的查询请求中， 即设 置路由数据， 从而通过该路由数据对请求的转发次数进行限 制， 避免无限 制地转发。 那么， 对于接收到查询请求的终端， 需要从其中解析出路由数 据， 并将该路由数据自动减 1 , 若处理后的路由数据仍然大于或等于 1 , 则在查询失败的情况下， 继续向其他终端转发， 否则停止转发， 并向源终 端 （最初生成查询请求的终端） 返回查询失败的消息。 对于被动的情况 下， 可以直接对该终端的用户进行查询， 并由用户选择是否继续由其他终 端进行查询， 并可以指定相应的终端。

若选择继续转发查询请求， 则对于接收到该查询请求的终端， 相当于 返回步骤 602 , 并执行之后的步骤， 若选择不继续转发， 则结束流程， 并 且可以向源终端返回查询失败的消息。

步骤 612 , 向源终端返回查询结果。

图 7示出了根据本发明的一个实施例的查询联系� �的各终端之间的结 构示意图。

如图 7所示， 根据本发明的一个实施例的查询联系人的各终 端之间的 结构如下：

终端 A 在自身对应的本地数据库和云端数据库进行目 标联系人的查 询， 若查询失败， 则作为源终端， 生成对应于目标联系人和自身的查询请 求， 发送至相关联的终端 Bl、 终端 B2 , 并由终端 B1和终端 B2在其对应 的数据库中进行查询。 在查询时， 首先从查询请求中解析出目标联系人的 信息， 比如姓名、 归属地、 相关联的联系人等， 并依据这些信息进行查 询， 若查询成功， 则根据从查询请求中解析出的终端 A的信息， 将查询到 的目标联系人的信息返回终端 A。

若终端 B1 或终端 B2 查询失败， 则分别将查询请求转发至其他终 端， 继续进行查询， 比如终端 B1 将查询请求转发至终端 Cl l、 终端 C12、 终端 C13 等， 而终端 B2则将查询请求转发至终端 C21、 终端 C22 等， 继续进行查询。

若查询成功， 则直接将查询结果返回终端 A, 若失败， 还可以继续转 发至其他终端， 继续进行查询。

如果将各个终端的查询顺序和转发信息的关系 来看， 可以将终端 A看 做第一层级， 终端 Bl、 终端 B2等看做第二层级， 终端 Cl l、 终端 C12、 终端 C13、 终端 C21、 终端 C22等看做第三层级， 则本发明的技术方案相 当于按照层级顺序， 依次在第一层级、 第二层级、 第三层级……对目标联 系人进行查找， 从而将查询的数据库从终端 A的数据库扩展为更多终端对 应的数据库， 从而增加查询的成功率。

但上述过程可能由于一些原因， 使得虽然在不断查询和转发查询请 求， 但依然无法查询到结果， 从而给终端 A的用户带来 "无响应" 的查询 体验， 因此， 可以在终端 A生成的查询请求中， 添加路由数据， 限制转发 次数， 比如为 2次， 则当处于第三层级的终端 C11等仍查询不到对应的联 系人信息时， 便直接向终端 A返回查询失败信息， 而不会无限制地转发和 查询下去。

以上结合附图详细说明了本发明的技术方案， 考虑到相关技术中， 对 于未知联系人信息的查询过程繁瑣、 成功率低， 因此， 本发明提供了相应 的终端和联系人查找方法， 可以从其他用户的数据库中查找到自身通讯录 中没有的联系人信息。

以上所述仅为本发明的优选实施例而已， 并不用于限制本发明， 对于 本领域的技术人员来说， 本发明可以有各种更改和变化。 凡在本发明的精 神和原则之内， 所作的任何修改、 等同替换、 改进等， 均应包含在本发明 的保护范围之内。