为了在服务器200上辅助识别呼叫的对端身份，将根据本发明的实施例的对端身份辅助识别服务器端250(以下简称为服务器端250)安装在服务器200上。服务器端250可以由服务提供商以软件的形式自行安装在服务器200中，或者可以由生产厂商以硬件或固件的形式安装在服务器200中。在一些实施例中，服务器端250可以是例如在服务提供商购买了服务器200之后从网络中下载的专门用于本发明的应用软件。在另一些实施例中，服务器端250可以是例如由生产厂商以固件或硬件形式预先安装在服务器200中的应用程序。在又一些实施例中，服务器端250可以是由生产厂商生产的硬件模块或服务器200本身。
[0071]接下来，将参考图2和图3来详细描述根据本发明实施例的用于识别呼叫的对端身份的示例流程。
[0072]下文中，假定存在一个或多个终端100 (或客户端150)，且每个终端100 (客户端150)可以具有终端(客户端)识别信息。在一个实施例中，该终端识别信息可以是Android平台的Android IDo当然，本发明不限于此。在其他实施例中，终端识别信息也可以是终端的MAC地址、IP地址、CPU序列号等，也可以是其它与终端(客户端)绑定，并能够用于识别终端的信息。各个终端100可以通过共享的方式向服务器200共享(上传)各个终端的本地联系人信息(地址簿等)。而各个终端100可以享受由服务器200的陌生号码来电识另U、名片信息识别系统提供的服务。
[0073]例如，一个终端100A通过应用市场安装了一个根据本发明实施例的应用(APP)，例如CallBlocker。在首次使用该应用(例如，客户端150)时，或在后期更新(例如，添加、删除、修改等)了终端100A的通讯录(或地址簿、联系人信息等)，用户可以在终端100A上选择“共享”或“不共享”本地联系人。当选择“共享”时，该客户端150读取本地的一个或多个联系人信息(例如，具有vCard文件格式)后加密上传到服务器200。服务器200在收到该一个或多个vCard后，加密存储到数据库(例如，对象数据库)中。当然，在其他实施例中，该存储也可以是不加密的，完全取决于实现者的具体实现需求。在一个实施例中，在数据库中存储时使用的主键可以是根据终端100的Android ID生成的，或更直接的，就是AndroidID。在数据库中主要存储这一个或多个vCard的用户名称、电话号码、邮件地址、邮编号码和电话类型等。当然，本发明不限于此，还可以存储与本地联系人相关联的其它信息。
[0074]在终端100向服务器200上传数据时，如果根据Android ID或其他识别信息发现所上传的数据属于同一个终端100，则数据库存储平台可以按照增量的形式进行增减或者修改(更新)。如果发现上传的数据来自与数据库中现有数据所属终端不同的终端，则可以直接加密后存储。
[0075]这样，终端10A就可以在陌生人来电时享受本发明实施例提供的对端身份识别服务。即，在接通陌生来电前就可以知道对方的名字和基本信息(例如，头像、年龄、地址、职业等)。此外，终端100A的用户可以手动把通过本发明实施例的方法识别的号码添加到其本地通讯录中。同理，其他终端100在使用时如果也同意共享，那么也可以享受对端身份识别服务。
[0076]当然，本发明不限于在同意共享自己的联系人信息的情况下才可以享受对端身份识别服务。也可以在满足其他条件的情况下，就能够享受该服务。例如，在一个实施例中，当终端100B的用户支付一定费用成为平台会员时，其在不共享自己的联系人信息的情况下，就能够同样享受该服务。在该情况下，可以避免自己的私密信息与他人共享。
[0077]具体地，参见图3，当例如终端100A接收到呼入呼叫(“手机来电”)时，其可以从呼入呼叫所携带的元信息中提取来电号码(“客户端采集来电号码”)。首先，终端100A尝试在本地识别该来电号码(“是否陌生号”)。如果其发现该号码为与本地已知的联系人相关联的号码时(“否”)，其可以直接向用户提供对该联系人的指示，例如联系人的姓名、头像等。如果未在本地地址簿中找到对应联系人(“是”)，则终端100A判断该号码为陌生号码，其应当向服务器200进行查询。在一个实施例中，终端100A可以用查询请求的方式将该号码和其自身的Android ID告知服务器200( “客户端把号码上传到平台”)。换言之，该查询请求可以包括呼叫的号码以及终端100A的识别信息。当然，本发明不限于此，查询请求也可以仅包括呼叫的号码，或包括其他信息。
[0078]当服务器200接收到该查询请求后，服务器200根据一个或多个识别依据，在其数据库中检索相应对端身份记录(“是否在平台”/ “是否命中提示规则”，下文具体描述)，并向终端100A反馈查询结果(“平台返回VCard给客户端”)。最后，终端100A可以显示服务器200的识别结果(“客户端提示主要信息”)。如果服务器200未检索到对应身份记录(“是否在平台”一“否”)，则向终端100A返回查询失败的指示。
[0079]在一些实施例中，服务器200向终端100A发送的查询结果可以是符合vCard文件格式标准的数据。此外，服务器200在检索到一条或多条身份记录时(“是否在平台”一“是”)，其可以根据以下至少一项识别依据，来选择作为查询结果的身份记录(“是否命中提示规则”):
[0080](I)共享人数。理论上，当同一身份记录的共享(认可)人数超过某一阈值时，才认为该条身份记录可信度较高，并向终端100A加以推荐。因此，共享人数是一项重要的识别依据。在一个实施例中，该共享人数可以是2，当然，本发明不限于此，根据需要其也可以是其他数目，例如，自然数或甚至某个实数(例如，1.5)。这里出现实数的情况主要是可能由于根据统计数据来归纳出达到某一可信度所需要的平均共享人数。
[0081](2)禁止规则。可以使用预先设置的过滤器，当检测到名称、地址、邮箱地址等文字描述中出现违反法律、法规、社会公德等，或者检测到服务器200的服务运营商认为其它应当禁止使用的内容时，可以设置忽略对应的身份记录，以防止有恶意用户注册/上传恶意信息，并造成一系列问题。
[0082](3)非人际关系称呼。人际关系称呼可以包括亲属/朋友称呼等，例如爸爸、妈妈、爷爷、奶奶、叔叔、阿姨等，这种称呼通常仅对于上传对应身份信息的用户有意义，而对于其他第三方来说是无意义的。因此，在过滤器(可以与上述过滤器是同一个过滤器，也可以是不同的过滤器)判断出现这种称呼时，同样忽略对应的身份记录。
[0083](4)加权。当涉及同一号码的共享用户大于2时，如果出现名称不同的情况，可以采取加权方式判断返回。例如，针对同一电话号码“4008-517-517”，终端100A上的身份信息包括名称项“麦当劳”，而终端100B上的身份信息包括名称项“快餐”，则可以根据针对终端100A和100B的不同权重来选择针对终端100C的查询请求的查询结果。在一个实施例中，根据终端100A和100B上传的其他条目的可信度(或者其他用户对这两个用户上传条目的认可度)，对这两个终端加以不同权重。例如，终端100A上传的其他99条联系人信息非常准确，其每一条联系人信息都与其他用户的联系人信息吻合，从而服务器200可以认为终端100A的可信度较高，赋予高权重。相对地，终端100B上传的其他99条联系人信息准确度一般，仅有一半的联系人信息与其他用户的联系人信息吻合，从而服务器200可以认为终端100B的可信度一般，赋予中等权重。因此，在终端100A和100B关于同一号码的身份信息发生分歧时，由于终端100A的权重较高，因此在向终端100C返回查询结果时，采信了终端100A的身份数据。
[0084]当然，本申请不限于上述四种选择依据，也可以根据其它选择依据来判断向终端100返回哪(些)条身份记录。在其他实施例中，可以向终端100A返回全部身份记录，以由终端100A自行选择恰当的身份记录。
[0085]此外，在一些实施例中，当已注册的商家号码和主动注册个人号码被其他用户分享到平台而平台号码信息未做更改；用户来电或者去电时，平台通过命中规则智