CN106330657B - 一种好友处理方法和装置 - Google Patents

Abstract

本申请提供一种好友处理方法和装置，其中方法包括：获取待进行好友生成的目标用户的用户标识；根据所述用户标识，获取与目标用户具有业务场景关联的多个联系人及所述业务场景关联的场景联系信息，并根据所述场景联系信息由多个联系人中确定所述目标用户的好友，所述场景联系信息是用于表示所述联系人与目标用户之间的关联关系的信息；建立所述目标用户与好友之间的对应关系；将所述好友作为所述目标用户所在的客户端的初始化好友发送至所述客户端，以使得客户端显示好友信息。本申请提高了好友生成的便利性。

Description

一种好友处理方法和装置

技术领域

本申请涉及网络技术，特别涉及一种好友处理方法和装置。

背景技术

随着网络技术的不断发展，各种用途的应用使得人们的生活更加便利，例如，可以在智能手机上安装社交应用，支付应用等。其中，为了方便用户和朋友之间通过应用进行交互，应用中还可以添加好友功能，即用户可以在应用中找到自己的好友，并向好友发起各种业务场景，比如聊天、送红包等。相关技术中，应用中的好友通常都是由用户主动添加的，例如，用户可以在通讯录中选择自己的好友添加为应用好友，以方便在应用中进行好友联系。但是这种方式用户需要不断操作使得好友的生成非常繁琐。

发明内容

有鉴于此，本申请提供一种好友处理方法和装置，以提高好友生成的便利性。

具体地，本申请是通过如下技术方案实现的：

第一方面，提供一种好友处理方法，包括：

获取待进行好友生成的目标用户的用户标识；

根据所述用户标识，获取与目标用户具有业务场景关联的多个联系人及所述业务场景关联的场景联系信息，并根据所述场景联系信息由多个联系人中确定所述目标用户的好友，所述场景联系信息是用于表示所述联系人与目标用户之间的关联关系的信息；建立所述目标用户与好友之间的对应关系；

将所述好友作为所述目标用户所在的客户端的初始化好友发送至所述客户端，以使得客户端显示好友信息。

第二方面，提供一种好友处理方法，包括：

接收服务端返回的与目标用户对应的好友的好友信息，所述好友是所述服务端根据与所述目标用户具有业务场景关联的场景联系信息，由业务场景关联的多个联系人中确定；

将所述好友作为初始化好友，显示所述好友信息。

第三方面，提供一种好友处理装置，包括：

信息获取模块，用于获取待进行好友生成的目标用户的用户标识；

好友确定模块，用于根据所述用户标识，获取与所述目标用户具有业务场景关联的多个联系人及所述业务场景关联的场景联系信息，并根据所述场景联系信息由所述多个联系人中确定所述目标用户的好友，所述场景联系信息是用于表示所述联系人与目标用户之间的关联关系的信息；建立所述目标用户与好友之间的对应关系；

好友发送模块，用于将所述好友作为所述目标用户所在的客户端的初始化好友发送至所述客户端，以使得客户端显示好友信息。

第四方面，提供一种好友处理装置，包括：

信息接收模块，用于接收服务端返回的与目标用户对应的好友的好友信息，所述好友是所述服务端根据与所述目标用户具有业务场景关联的场景联系信息，由业务场景关联的多个联系人中确定；

好友显示模块，用于将所述好友作为初始化好友，显示所述好友信息。

本申请提供的好友处理方法和装置，通过由服务端根据与目标用户具有业务场景关联的联系人的场景联系信息，可以确定目标用户的好友，并发送至客户端作为初始化好友，相对于传统方式中的用户主动添加好友的方式，将使得好友的获得更加便利，减少了用户的操作，提高了好友生成的便利性。

附图说明

图1是本申请一示例性实施例示出的一种好友处理方法的应用系统示意图；

图2是本申请一示例性实施例示出的一种好友处理方法的应用界面图一；

图3是本申请一示例性实施例示出的一种好友处理方法的应用界面图二；

图4是本申请一示例性实施例示出的一种好友处理方法的流程图；

图5是本申请一示例性实施例示出的另一种好友处理方法的流程图；

图6是本申请一示例性实施例示出的一种好友确定的流程；

图7是本申请一示例性实施例示出的一种好友处理装置的结构图；

图8是本申请一示例性实施例示出的另一种好友处理装置的结构图；

图9是本申请一示例性实施例示出的又一种好友处理装置的结构图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

目前方便人们生活各个方面的应用越来越多，例如，可以安装在智能终端的应用，可以安装在PC端的应用等，这些应用在使用时，都可以通过图1示例的系统来实现。如图1所示，应用的服务端11可以用于存储应用的功能信息(例如，在客户端显示的信息可以存储在服务端)，并将功能信息发送至客户端12进行显示，通过客户端12与服务端11之间的信息交互来实现对应用的操作和使用。

以在智能手机上安装一个社交应用APP为例(不限定应用的类型)，该应用中可以包括多个功能模块，比如，转账模块、信用卡还款模块等，其中可以存在一个“朋友模块”，以方便智能手机用户与其朋友进行交互。如图2所示，智能手机的用户可以点击该应用的朋友模块的标签21，进入朋友模块。在传统方式中，如果用户是第一次打开该朋友模块，那么当进入图3示例的朋友列表时，该列表为空，需要用户手动添加好友；而在本申请的例子中，即使用户首次使用朋友模块，也可以看到该模块已经存在了一些好友，例如图3示例的小张、小王、小李等(当然，也可以是其他好友标识)。

也就是说，本例子的应用可以为用户进行好友的初始化，不需要用户手动添加就已经存在用户的好友，用户可以直接与好友进行交互。并且，需要说明的是，该例子中的好友是应用按照本申请的好友处理方法得到的，具有较高的准确性，即该初始化的好友很大程度上就是用户的好友。由上述图2和图3可以看到，这种进行好友初始化的方式，对于用户来说非常便利，不用再手动添加，避免了添加好友的繁琐操作。如下将详细描述本申请的好友处理方法是如何实现图3所示的好友初始化场景。

图4示例了本申请的好友处理方法，该方法可以是图1中的服务端执行，如图4所示，可以包括：

401、获取待进行好友生成的目标用户的用户标识；

402、根据用户标识，获取与所述目标用户具有业务场景关联的多个联系人及所述业务场景关联的场景联系信息，并根据所述场景联系信息由所述多个联系人中确定所述目标用户的好友，所述场景联系信息是用于表示所述联系人与目标用户之间的关联关系的信息；建立所述目标用户与好友之间的对应关系；

403、将所述好友作为所述目标用户所在的客户端的初始化好友发送至所述客户端，以使得客户端显示好友信息。

而图5示例了图1中的客户端对应执行的好友处理方法，可以包括：

501、接收服务端返回的与目标用户对应的好友的好友信息，所述好友是所述服务端根据与所述目标用户具有业务场景关联的场景联系信息，由业务场景关联的多个联系人中确定；

502、将所述好友作为初始化好友，显示所述好友信息。

结合图4和图5所示，在401中，由服务端来看，可以获取到待进行好友生成的目标用户的用户标识。

例如，以支付客户端为例，示例性的，该支付客户端可以为支付宝钱包。当用户注册支付宝钱包后，支付宝的服务端将会获取到该用户的支付宝账号，可以将支付宝账号作为该用户的用户标识。需要说明的是，用户标识不一定是支付宝账号，在本实施例中，用户标识的作用是，可以根据该用户标识查找与目标用户具有关联的各个联系人，比如，用户在注册支付宝账号时，使用了自己的手机号，或者使用了自己的邮箱，那么可以将手机号或邮箱称为用户标识，当用户使用了相同的手机号或邮箱注册微博账号时，就可以根据该手机号或邮箱查找到用户的微博账号，进而得到在微博这个社交场景中与用户联系的人；而在找到用户的好友时，建立用户与好友的对应关系(即好友关系)，可以使用支付宝账号作为用户标识；或者，在资金交互的场景中，可以使用支付宝账号来查找交易的联系人，此时又可以将支付宝账号称为用户标识。

此外，由于支付宝钱包中包括上述的朋友模块，那么该用户就是有可能点击朋友模块的潜在用户(即，用户也可能会点击使用朋友功能，也可能不点击)，不论用户以后是否会使用朋友模块，只要该用户当前尚未使用朋友模块，支付宝的服务端都将该用户作为目标用户，为其进行好友生成，即开始获取该用户的好友，以备用户首次使用朋友模块时为用户进行好友初始化。

在402中，服务端可以根据得到的用户标识，获取与所述目标用户具有业务场景关联的多个联系人及所述业务场景关联的场景联系信息，并根据所述场景联系信息由所述多个联系人中确定目标用户的好友，并建立目标用户与确定的好友之间的对应关系。

例如，与目标用户有关联的联系人，可以包括多个业务场景下的联系人，与目标用户具有业务场景关联，并且可以用场景联系信息表示联系人与目标用户之间的关联关系。如下，以目标用户为用户A为例，用户A在其智能手机上安装了支付宝钱包，具有用户A对应的支付宝账号。示例几种与用户A具有业务场景关联的例子：

在一个例子中，如果用户B与用户A具有社交关联，则可以将用户B作为用户A的联系人。社交关联例如包括如下方面具有联系：微博(例如，至少其中一方关注了另一方的微博)、来往(例如，双方进行过聊天、评论等)、QQ群(例如，双方有共同群)、红包(例如，双方之间进行过讨红包、红包邀请等交互)等。

这种方式中，聊天次数、共同联系人数量、评论次数等这些信息可以称为该社交关联业务场景下的场景联系信息。获取场景联系信息的方式，例如可以是：用户注册支付宝钱包、与注册微博的邮箱是同一个邮箱，或者使用了同一个手机号进行注册，那么根据上述同一邮箱或手机号得到该目标用户的微博，并查看用户微博中关注的各个联系人。也就是说，本例子中所获得的联系人，可以与目标用户一样，同为支付宝钱包的用户，并且使用了至少一种相同的信息，可以称为用户标识(比如上述的邮箱或手机号)，以通过该用户标识查找到关联的另一个场景下的信息。又比如，来往的账号注册时也可以是与支付宝钱包的注册使用了同一种信息，查找方式同上。

在另一个例子中，如果用户B与用户A之间具有通讯关联，则可以将用户B作为用户A的联系人。通讯关联例如包括：双方至少一方是另一方的联系人。这种方式中，双方通讯录的共同联系人数可以称为场景联系信息。获取场景联系信息的方式，例如可以是：获得目标用户所在的智能手机上的通讯录，得到通讯录中该目标用户的各个联系人。

在再一个例子中，如果用户B与用户A之间具有媒介关联，则可以将用户B作为用户A的联系人。媒介关联指的是，用户B和用户A之间使用过同一媒介，比如，使用同一台电脑、同一部手机、使用过同一个缴费户号等。

这种方式中，使用共同媒介的天数、最近交互时间等可以称为媒介关联业务场景下的场景联系信息。获取场景联系信息的方式，例如可以是：假设用户A和用户B在同一部智能手机上登录了各自的支付宝账号，那么支付宝的客户端可以采集所在的终端设备的设备标识，并上报至服务端，那么服务端可能发现用户A的支付宝客户端所在的设备标识与用户B的支付宝客户单所在的设备标识相同，那么确定用户A和用户B使用了同一媒介(智能手机)。而由于两个用户使用了同一媒介，服务端就判定这两个用户可能是关系亲密的用户，则将其中一方作为另一方的联系人。

在又一个例子中，如果用户B与用户A之间具有资金关联，则可以将用户B作为用户A的联系人。资金关联例如是双方之间进行过转账、代付、亲密付、代订机票、信用卡还款等资金交易的联系。这种方式中，可以将交易次数、交易金额、最近一次交易时间等信息，称为该资金关联业务场景下的场景联系信息。获取场景联系信息的方式，例如可以是：由于应用客户端可以包括上述的资金关联的各个子场景，这些子场景可以作为客户端的各功能模块，所以可以由客户端采集到场景联系信息上报至服务端。

需要说明的是，联系人与目标用户之间的业务场景关联并不局限于上述举例的几种场景，还可以包括其他场景关联。此外，服务端获取上述场景关联下的场景联系信息的方式也可以有多种，例如，以支付宝钱包为例，支付宝服务端获取来往、资金关联等信息很方便，因为这些信息可以是属于同一信息管理者的管理，可以容易的获取到相关信息；而对于微博、QQ群等信息，比如可以是与支付宝管理者具有合作或某种业务关系的管理者的信息，也为信息的获取提供了方便；对于通讯关联的信息，可以是由客户端采集后上报至服务端，例如，用户在手机上安装支付宝钱包客户端后，由客户端将用户手机上的通讯录的信息上传至服务端(在用户知晓并授权的前提下)。

此外，上述信息的获取可以是以在线方式或离线方式获取，并且，由于其中的一些信息是动态变化的，例如，聊天次数、交易次数等，服务端可以定期采集一次场景联系信息，并重新根据场景联系信息计算目标用户的好友。尽管计算获取好友信息依据的场景联系信息是动态变化的，可以定期采集，但是服务端可以是在用户首次使用应用的朋友模块功能之前，执行上述的定期采集和更新好友，以备在用户首次使用时向用户初始化更加准确的好友信息。而在用户初次使用好友功能之后，服务端可以固话目标用户与好友的关系，不再进行定期更新，这样做可以防止用户看到的好友不断变化，给用户更好的使用体验。

由上述描述也可以看到，好友信息的确定可以是综合多种业务场景关联得到的，考虑了与目标用户在各个方面发生关联的联系人，这种多场景关系确定好友的方式，相较于单一因素确定好友，将使得好友信息更加准确。后续的实施例将详细描述如何根据场景联系信息从联系人中选择好友。

在经过计算和分析确定目标用户的好友后，服务端可以建立目标用户与好友之间的对应关系，比如可以建立目标用户的用户标识与好友的好友信息之间的对应关系。例如，仍以支付宝钱包为例，用户标识和好友信息可以都为支付宝账号，在支付宝服务端经过402中的计算，得到与目标用户对应的好友后，可以建立目标用户与其好友之间的对应关系，即可以建立目标用户的支付宝账号与好友的支付宝账号之间的关联(本例子中可以是限定在具有支付宝账号的人才可能成为待选择的联系人)。

在步骤403中，服务端可以向客户端发送上述确定的好友的好友信息，在客户端会根据该好友信息将所述好友作为目标用户的初始化好友，显示在客户端。在一个例子中，可以在用户通过客户端向服务端初次请求好友时，比如类似图2所示的，用户点击了客户端中的朋友模块标签，则服务端将在402中确定的与目标用户对应的好友信息发送至客户端，客户端显示为图3示例的好友列表，实现好友初始化。

本申请中的好友处理方法，通过由服务端预先获取与目标用户具有场景关联的联系人，并在联系人中确定目标用户的好友，使得用户的初始化好友的生成非常便利，比如可以在用户首次进行好友请求时，实现客户端的好友初始化，这种方式使得客户端能够自动生成好友，在初次使用应用时不需要用户手动添加好友，提高了好友生成的便利性，也提升了用户体验。

如下将详细描述在本申请的好友处理方法中，如何根据场景联系信息由多个联系人中选择好友。在这个例子中，以支付宝钱包应用为例，为钱包用户的朋友模块进行好友初始化；并且，可以由如下的业务场景关联寻找到用户的联系人，包括：社交关联、通讯关联、媒介关联和资金关联，通过这几个方面进行联系人的衡量，以期对联系人的评价(评价是否可以作为用户的好友)更加准确。

图6示例了好友选择的流程，可以包括：

601、对于每一个联系人，根据联系人与目标用户在各个业务场景下的场景联系信息，分别计算对应各个业务场景的联系人与目标用户之间的场景关系指数；

602、综合各个业务场景下的场景关系指数，得到联系人与目标用户的好友关系指数；

603、将好友关系指数达到指数阈值的联系人，确定为目标用户的好友。

由图6的流程可以看到，对于社交关联、通讯关联、媒介关联和资金关联这四个业务场景，可以在601中分别计算各个业务场景下的场景关系指数，场景关系指数是一种用于衡量某个联系人与目标用户之间的联系关系强弱的指标，例如，场景关系指数的数值越高，可以表示该联系人与目标用户之间的关系较强，成为目标用户的好友的希望越高；而如果场景关系指数的数值越低，则可以表示该联系人与目标用户之间的关系较弱，比如也可能是仅交互为一次的普通人，并不能称为目标用户的好友。

在步骤602中，综合各个业务场景下的场景关系指数，例如可以是，将上述社交关联、通讯关联、媒介关联和资金关联这四个业务场景下的场景关系指数相加，得到一个指数总和，可以称为“好友关系指数”，相当于通过该好友关系指数从多个业务场景方面对联系人与目标用户的关系进行了全面的考量，考量该联系人是否可以被确定为目标用户的好友。

步骤603提供了一种通过好友关系指数衡量是否选择该联系人作为好友的方法，例如，可以预先设定一个指数阈值，比如，指数阈值可以为70分，如果某个联系人与目标用户在社交、通讯、资金等多个方面都有过联系，而且经过各个业务场景下的指数计算得到的好友关系指数是85分，那么可以确定该联系人是目标用户的好友，而如果好友关系指数是60分，达不到阈值，则不将该联系人作为目标用户的好友。

有时也可能计算得到的达到指数阈值的联系人的数量较多，此时，可以将好友关系指数达到指数阈值的联系人，依据所述好友关系指数由高到低排序，并将排序在前N位的联系人作为所述好友，N大于0。例如，可以设定在向支付宝钱包的朋友模块初始化好友时，向客户端推送10个好友，那么可以将排序后的top10联系人作为目标用户的10个好友。当然，如果达到指数阈值的联系人的数量不足10个，可以按照实际达到阈值的数量作为好友。

还需要说明的是，在通过好友指数关系衡量联系人是否作为目标用户的好友时，可以进行双向的好友衡量。比如，在为用户A计算好友时，其中包括判断用户B是否可以作为用户A的好友，该用户B可以在社交、资金等多个方面都与用户A发生过联系。但是，仍然有可能用户A将用户B视为自己的好友，而用户B尚未将用户A视为自己的好友，比如，用户A将用户B的联系方式存储在通讯录中，而用户B并为存储用户A的联系方式。因此，可以进行双方的好友关系衡量，计算用于衡量是否将目标用户作为联系人的好友的第一关系指数、以及用于衡量是否将联系人作为目标用户的好友的第二关系指数，如果第一关系指数和第二关系指数均达到指数阈值，则可以设定目标用户和联系人互为好友，即将用户B作为用户A的初始化好友，同时也将用户A作为用户B的初始化好友，实现双向好友初始化。

下面将以上述的社交关联、通讯关联、媒介关联和资金关联这四个业务场景为例，为支付宝钱包的朋友模块进行好友初始化的好友计算，并且分别描述如何计算各个业务场景下的联系人与目标用户之间的场景关系指数，该场景关系指数是根据对应场景下的场景联系信息计算得到；并且，在计算场景关系指数时，可以按照矢量方向，分别计算第一场景关系指数(衡量目标用户是否可以作为联系人的好友)和第二场景关系指数(衡量联系人是否可以作为目标用户的好友)。

但是，对于有些方向性不太强的场景(即，有些用户和联系人之间的场景联系，对双向关系评价影响不大，比如转账时，A向B转账，则可以认为这一次转账中A——>B和B——>A这两个指数是相等的，不用做严格的区分；而对于有些方向性较强的业务场景(即，有些用户和联系人之间的场景联系，对双向关系评价影响较大；比如，用户A存储了用户B的联系方式，但用户B未存储用户A的联系方式，很可能双方对于对端的态度是不一样的)，可以分别计算两个方向的场景关系指数。可以根据实际场景情况区别分析。

在计算各个场景下的指数之前，可以预先定义各个场景分别对应的指数的数值范围，并且通过数值范围的大小区别各个场景在最终的好友关系指数中的占比，以体现不同场景下好友评估的重要程度的区别。比如，在支付宝钱包初始化的例子中，可以将资金关联业务场景对应的场景关系指数占比最大，即设置资金场景下的指数数值范围最大，表明资金交互方面的联系作为评价是否好友的一个最重要的因素。当然，如果是其他类型的应用的好友初始化，也可以设定其他场景的分值范围较大；或者，还可以是调整在好友关系指数计算中的各个场景下的场景关系指数的权重，来区别体现各个业务场景对好友评价的不同重要程度。

社交关联：分值范围[1-170]

社交关联例如包括：微博、来往、QQ群、一次性活动；其中，一次性活动例如包括：讨红包、逗比红包、红包邀请、红包接龙、送彩票帮好友开光等。分别计算上述的微博、来往、QQ群、一次性活动下的场景关系指数，并将这四种场景关系指数相加，即为社交关联下的场景关系指数。

微博[分值范围：10-60]：微博可以看作是属于社交关联场景下的子场景，该子场景下的场景联系信息包括：共同联系人的数量。比如，目标用户是用户A，正在评价的联系人是用户B，用户A的微博中有自己关注的多个联系人，用户B的微博中也有自己关注的多个联系人，可以获取双方共同关注的联系人的个数。

微博的场景关系指数的计算：如果用户A和用户B是双向关注，即用户A关注了用户B，用户B也关注了用户A，那么第一场景关系指数和第二场景关系指数是相等的，都可以计算为50+10*[逻辑归一(共同联系人个数)]，这里的[逻辑归一(共同联系人个数)]指的是，按照一个逻辑归一的函数公式，依据共同联系人个数，将共同联系人个数作为该公式的一个参数进行计算，以期将场景关系指数和控制在微博场景对应的数值范围内。后续出现的逻辑归一均指的是按照某个参数计算以控制指数在数值范围。

如果用户A和用户B是单向关注，比如，用户A关注了用户B，但是用户B未关注用户A，那么第一场景关系指数(A——>B)的计算为30+20*[逻辑归一(共同联系人个数)]，而第二场景关系指数(B——>A)的计算为10+20*[逻辑归一(共同联系人个数)]，可以看到，这种单向情况下，第一场景关系指数的数值要高于第二场景关系指数，即A成为B的好友的分值要高于B成为A的好友的分值。反之，如果用户B关注了用户A，但是用户A未关注用户B，第一场景关系指数和第二场景关系指数的计算方式类似，不再赘述。

来往[分值范围：1-30]：该子场景下的场景联系信息可以包括：聊天次数、评论次数、转载次数、交互天数。

来往的场景关系指数的计算：先分别计算聊天次数的影响因子、评论的影响因子、转载的影响因子和天数影响因子；影响因子按照如下公式计算：

以聊天次数的影响因子的计算为例，在上述公式中，Num(A，B)表示A和B的聊天次数，分母代表A的聊天次数，0.01常数是为了避免分母为0的情况发生，2.718＝自然对数e的值，用于保证第一部分log的值大于1。同理，评论的影响因子、转载的影响因子和天数影响因子也按照该公式计算，只是公式中参数的含义将发生变化，例如，在计算评论的影响因子时，Num(A，B)表示B对A内容的评论次数，分母表示A接收到的总评论次数；或者，表示A对B内容的评论次数，分母表示B接收到的总评论次数。

在按照影响因子的计算公式计算了各个影响因子后，再按照公式(2)计算场景关系指数：

场景关系指数1＝聊天次数的影响因子+评论的影响因子+0.5*转载的影响因子+2*天数影响因子。若为双向关注且为密友，调整场景关系指数1为场景关系指数2＝2.0*强弱指数1；若为密友，调整场景关系指数1为场景关系指数2＝1.5*强弱指数1；若关注类型为删除，或关系类型不为密友或普通好友，调整场景关系指数1为场景关系指数2＝0.5*强弱指数1。然后将场景关系指数2归一化在区间[10,30]。对于只存在A-B，没有B-A的关系对，B-A对的场景关系指数默认为1.0。比如，只有A向B发生聊天信息，而B从来没有向A发送聊天信息，正是因为只有A——>B而没有B——>A，所以B——>A设为1，因此范围是[1-30]。

QQ群[分值范围：10-30]：该子场景下的场景联系信息可以包括：双方共同的QQ群的数量。场景关系指数的计算：两个方向的场景关系指数相等，共同群1个分数10，共同群2个分数20，共同群多个分数30。

一次性活动[分值范围：30-50]：该子场景下的场景联系信息包括：各个活动的交互次数。场景关系指数的计算：两个方向的场景关系指数相等，按活动交互叠加次数，并按照99分位数归一化叠加的互动次数：30+20*[逻辑归一(互动次数)]。

将上述的微博、来往、QQ群和一次性活动四个子场景下的场景关系指数相加，得到社交关系场景下的场景关系指数；并且，可以是分别将对应两个方向的第一场景关系指数和第二场景关系指数相加，得到对应的总和。

通讯关联：分值范围[1-100]

通讯关联主要指的是通讯录的关联。例如，联系人用户B与目标用户用户A之间的通讯关联，可以包括：用户A将用户B存储在自己的通讯录中；或者，用户B将用户A存储在自己的通讯录中；或者，双方都将对方存储在自己的通讯录中。此外，在该场景下的场景联系信息包括：双方共同联系人个数，即双方通讯录中的共同联系人的数量。

该通讯关联场景下的场景关系指数的计算：该计算的原理与微博场景下的场景关系指数的计算原理类似，包括：如果双方都将对方存储在自己的通讯录中，那么指数＝80+20*[逻辑归一(共同联系人个数)]；如果用户A将用户B存储在通讯录中，而用户B未将用户A存储在通讯录中，那么第一场景关系指数(A——>B)的计算为30+50*[逻辑归一(共同联系人个数)]，而第二场景关系指数(B——>A)的计算为10+40*[逻辑归一(共同联系人个数)]。反之，如果只有用户B将用户A存储在通讯录中，而用户A未存储，第一场景关系指数和第二场景关系指数的计算方式类似，不再赘述。

媒介关联：分值范围[1-501]

该媒介关联指的是考虑到如果某个联系人与目标用户之间使用了相同的媒介，则表明该联系人可能与目标用户较为亲密，有可能是目标用户的好友。这里的媒介包括很多种，例如，手机、PC、邮箱、银行卡、缴费户号、密码等，场景也包括很多种，例如，支付宝登录事件、银行卡绑定事件、身份证绑定事件、手机号绑定事件等。比如，用户A和用户B在同一部手机上登录了自己的支付宝账号，或者，用户A和用户B在注册某个账号时使用了相同的邮箱或相同的密码等。

该媒介关联场景下的场景联系信息可以包括：每个场景的媒介数、媒介产生的场景数、使用天数、最近交互时间。其中，每个场景的媒介数指的是，例如，用户A和用户B在历史登录支付宝钱包这个场景中使用的共同手机的手机数量；而媒介产生的场景数，例如可以是，在一个相同的手机上，用户A和用户B登录过多少次支付宝钱包等。最近交互时间指的是，用户双方使用相同媒介的最近时间，而使用天数即使用相同媒介的天数。

根据上述的场景联系信息计算场景关系指数的方式：将设备标识MAC和UMID合并成PC_DEVICE代表PC端媒介类型、将设备标识TID和UTDID合并成MOB_DEVICE代表手机端媒介类型，根据合并后的类型取每个场景的媒介数、场景数、天数三个指标，计算关系双方在该指标的调和平均数作为最终关系对的属性值；计算每个类型下三个指标上的平均值，并根据最近交互时间进行时间微调降权，时间微调因子半衰期为24个月；合并A用户的支付宝账号和B用户的支付宝账号之间所有媒介关系的得分总和，逻辑归一化到[1-501]。例如，分别计算手机、PC、邮箱、银行卡等各个媒介下计算的经过时间降权的平均值，并将各个平均值求和，得到媒介下的场景关系指数。

资金关联：分值范围[1-1001]

该资金关联例如包括：转账、亲密付、代付、代充、AA收款、代订酒店、代订机票、彩票赠送、面对面红包、定向现金红包、送礼金、信用卡还款等。在该场景下的场景联系信息可以包括：交易次数、交易账号个数、交易时间跨度、交易金额、最近一次交易时间。

根据上述场景联系信息计算资金关联下的场景关系指数：

首先，如果将转账、亲密付、代付等各自称为一个子场景，那么可以分别计算每个子场景下的频次影响因子和场景权重，而该资金关联下的场景关系指数如下：

即将各个子场景下的频次影响因子和场景权重相乘，并求各个子场景下的数值的总和即可。其中，每个子场景下的计算如下：

对场景下的资金关系进行处理，合并双向关系并统计交易次数、交易金额和计算最近一次交易时间的距今日期。计算该单个场景对用户的权重，计算公式：

其中分母代表A总共与多少位联系人使用过场景K。

计算单个场景的频次影响因子，计算公式：

其中Num<A,B>[k]代表A,B在场景K上的交易次数，分母代表A和所有人在场景K上的交易次数。

此外，为了使得场景关系指数更加准确，可以对计算得到的Strength＜A，B＞进行修正。比如，若A,B在场景K中动态一年的交易次数只有1次，则该场景的权重等于1.7。

再用金额、时间微调因子进行降权后，将场景关系指数归一化在[1-1001]的区间范围内。其中，金额时间微调因子的计算公式如下，用户按时间、金额降权，计算公式：

其中rn为按金额排序的位数，常数2为保证分母大于0。时间的微调因子为距今三个月内取1，否则取指数，半衰期为24个月,计算公式：

时间微调因子＝e^{-(距今月份/24)}

综合降权因子＝时间微调因子*金额微调因子，使用该综合降权因子对上面计算得到的场景关系指数降权处理，再将场景关系指数归一化在[1-1001]的区间范围内。综合各个子场景下的指数得到该资金关联场景下的指数。

此外，有时为了后续应用对场景关系指数数据的使用，还可以依据将上述的各个场景下的场景关系指数相加得到的总和的场景关系指数，划分强弱关系等级，例如，强关系等级为1，分值在[90,1752]，中等关系等级为2，分值在[30,90)，弱关系等级为3，分值在[0,30)。

为了实现上述的好友处理方法，本申请还提供了一种好友处理装置，如图7所示，该装置可以应用在服务端，可以包括：信息获取模块71、好友确定模块72和好友发送模块73；其中，

信息获取模块71，用于获取待进行好友生成的目标用户的用户标识；

好友确定模块72，用于根据所述用户标识，获取与所述目标用户具有业务场景关联的多个联系人，并根据所述业务场景关联的场景联系信息由所述多个联系人中选择好友，所述场景联系信息用于限定所述联系人与目标用户之间的联系；建立所述用户标识与所述好友的好友信息之间的对应关系；

好友发送模块73，用于在接收到目标用户所在的客户端发送的初次好友请求时，将所述好友信息发送至客户端，以使得客户端显示所述好友信息。

例如，业务场景关联，可以包括：社交关联、通讯关联、媒介关联或者资金关联。

进一步的，如图8所示，好友确定模块72可以包括：场景计算单元721、综合计算单元722和好友选择单元723；其中，

场景计算单元721，用于对于每一个联系人，根据所述联系人与目标用户在各个业务场景下的场景联系信息，分别计算对应所述各个业务场景的所述联系人与目标用户之间的场景关系指数；

综合计算单元722，用于综合所述各个业务场景下的场景关系指数，得到所述联系人与目标用户的好友关系指数；

好友选择单元723，用于将所述好友关系指数达到指数阈值的联系人，确定为目标用户的好友。

进一步的，所述好友关系指数，包括：用于衡量是否将目标用户作为联系人的好友的第一关系指数、以及用于衡量是否将联系人作为目标用户的好友的第二关系指数。好友选择单元723，用于在第一关系指数和第二关系指数均达到所述指数阈值时，将所述联系人确定为所述目标用户的好友，并且将所述目标用户确定为所述联系人的好友。

进一步的，好友选择单元723，用于将所述好友关系指数达到指数阈值的联系人，依据所述好友关系指数由高到低排序，并将排序在前N位的联系人作为所述好友，N大于0。

为了实现上述的好友处理方法，本申请还提供了一种好友处理装置，如图9所示，该装置可以应用在客户端，可以包括：信息接收模块91和好友显示模块92；其中，

信息接收模块91，用于接收服务端返回的与目标用户对应的好友的好友信息，所述好友是所述服务端根据与所述目标用户具有业务场景关联的场景联系信息，由业务场景关联的多个联系人中确定；

好友显示模块92，用于将所述好友作为所述目标用户的初始化好友，显示所述好友信息。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (9)

1.一种好友处理方法，其特征在于，包括：

获取待进行好友生成的目标用户的用户标识；所述目标用户是当前尚未使用朋友模块的用户；

根据所述用户标识，获取与所述目标用户具有业务场景关联的多个联系人及所述业务场景关联的场景联系信息，并根据所述场景联系信息由所述多个联系人中确定所述目标用户的好友，所述场景联系信息是用于表示所述联系人与目标用户之间的关联关系的信息；建立所述目标用户与好友之间的对应关系；

将所述好友作为所述目标用户的初始化好友发送至所述目标用户对应的客户端，以使得客户端显示好友信息；所述初始化好友是不需要用户手动添加就已经存在的好友；

所述业务场景关联，包括如下至少一种：社交关联、通讯关联、媒介关联或者资金关联；

所述根据场景联系信息由所述多个联系人中确定目标用户的好友，包括：

对于每一个联系人，根据所述联系人与目标用户在各个业务场景下的场景联系信息，分别计算对应所述各个业务场景的所述联系人与目标用户之间的场景关系指数；

综合所述各个业务场景下的场景关系指数，得到所述联系人与目标用户的好友关系指数；

将所述好友关系指数达到指数阈值的联系人，确定为目标用户的好友。

2.根据权利要求1所述的方法，其特征在于，所述好友关系指数，包括：用于衡量是否将目标用户作为联系人的好友的第一关系指数、以及用于衡量是否将所述联系人作为目标用户的好友的第二关系指数；

所述将所述好友关系指数达到指数阈值的联系人确定为目标用户的好友，包括：若所述第一关系指数和第二关系指数均达到所述指数阈值，则将所述联系人确定为所述目标用户的好友，并且将所述目标用户确定为所述联系人的好友。

3.根据权利要求1所述的方法，其特征在于，在所述综合各个业务场景下的场景关系指数得到联系人与目标用户的好友关系指数时，所述各个业务场景中的资金关联业务场景对应的场景关系指数占比最大。

4.根据权利要求1所述的方法，其特征在于，所述将所述好友关系指数达到指数阈值的联系人，确定为目标用户的好友，包括：

将所述好友关系指数达到指数阈值的联系人，依据所述好友关系指数由高到低排序，并将排序在前N位的联系人作为所述好友，N大于0。

5.一种好友处理方法，其特征在于，包括：

接收服务端返回的与目标用户对应的好友的好友信息，所述好友是所述服务端根据与所述目标用户具有业务场景关联的场景联系信息，由业务场景关联的多个联系人中确定；所述目标用户是当前尚未使用朋友模块的用户；

将所述好友作为所述目标用户的初始化好友，显示所述好友信息；所述初始化好友是不需要用户手动添加就已经存在的好友；所述业务场景关联，包括如下至少一种：社交关联、通讯关联、媒介关联或者资金关联；

所述好友是所述服务端根据与所述目标用户具有业务场景关联的场景联系信息，由业务场景关联的多个联系人中确定，包括：

对于每一个联系人，根据所述联系人与目标用户在各个业务场景下的场景联系信息，分别计算对应所述各个业务场景的所述联系人与目标用户之间的场景关系指数；

综合所述各个业务场景下的场景关系指数，得到所述联系人与目标用户的好友关系指数；

将所述好友关系指数达到指数阈值的联系人，确定为目标用户的好友。

6.一种好友处理装置，其特征在于，包括：

信息获取模块，用于获取待进行好友生成的目标用户的用户标识；所述目标用户是当前尚未使用朋友模块的用户；

好友确定模块，用于根据所述用户标识，获取与所述目标用户具有业务场景关联的多个联系人及所述业务场景关联的场景联系信息，并根据所述场景联系信息由所述多个联系人中确定所述目标用户的好友，所述场景联系信息是用于表示所述联系人与目标用户之间的关联关系的信息；建立所述目标用户与好友之间的对应关系；

好友发送模块，用于将所述好友作为所述目标用户的初始化好友发送至所述目标用户对应的客户端，以使得客户端显示好友信息；所述初始化好友是不需要用户手动添加就已经存在的好友；

所述业务场景关联，包括：社交关联、通讯关联、媒介关联或者资金关联；

所述好友确定模块包括：

场景计算单元，用于对于每一个联系人，根据所述联系人与目标用户在各个业务场景下的场景联系信息，分别计算对应所述各个业务场景的所述联系人与目标用户之间的场景关系指数；

综合计算单元，用于综合所述各个业务场景下的场景关系指数，得到所述联系人与目标用户的好友关系指数；

好友选择单元，用于将所述好友关系指数达到指数阈值的联系人，确定为目标用户的好友。

7.根据权利要求6所述的装置，其特征在于，所述好友关系指数，包括：用于衡量是否将目标用户作为联系人的好友的第一关系指数、以及用于衡量是否将所述联系人作为目标用户的好友的第二关系指数；

所述好友选择单元，用于在第一关系指数和第二关系指数均达到所述指数阈值时，将所述联系人确定为所述目标用户的好友，并且将所述目标用户确定为所述联系人的好友。

8.根据权利要求6所述的装置，其特征在于，

所述好友选择单元，用于将所述好友关系指数达到指数阈值的联系人，依据所述好友关系指数由高到低排序，并将排序在前N位的联系人作为所述好友，N大于0。

9.一种好友处理装置，其特征在于，包括：

信息接收模块，用于接收服务端返回的与目标用户对应的好友的好友信息，所述好友是所述服务端根据与所述目标用户具有业务场景关联的场景联系信息，由业务场景关联的多个联系人中确定；所述目标用户是当前尚未使用朋友模块的用户；

好友显示模块，用于将所述好友作为所述目标用户的初始化好友，显示所述好友信息；所述初始化好友是不需要用户手动添加就已经存在的好友；所述业务场景关联，包括如下至少一种：社交关联、通讯关联、媒介关联或者资金关联；

所述好友是所述服务端根据与所述目标用户具有业务场景关联的场景联系信息，由业务场景关联的多个联系人中确定，包括：

对于每一个联系人，根据所述联系人与目标用户在各个业务场景下的场景联系信息，分别计算对应所述各个业务场景的所述联系人与目标用户之间的场景关系指数；

综合所述各个业务场景下的场景关系指数，得到所述联系人与目标用户的好友关系指数；

将所述好友关系指数达到指数阈值的联系人，确定为目标用户的好友。

Images