CN107862530A - 建立用户人际关系信息的方法及装置 - Google Patents

Abstract

本申请实施例公开了建立用户人际关系信息方法及装置，其中，所述方法包括：提供用户特征信息，根据所述特征信息，确定用户之间的关联关系强度；对于其中一指定用户，确定与所述指定用户之间的关联关系强度满足预置条件的至少一个候选用户；根据所述采集到的预置维度上的特征信息，从所述候选用户中确定出与所述指定用户具有特定人际关系的至少一个目标用户；保存所述指定用户与所述至少一个目标用户之间的特定人际关系信息。通过本申请实施例，可以启发基于特定人际关系的信息进行用户需求挖掘，从而有利于节省系统资源，提升用户体验。

Description

建立用户人际关系信息的方法及装置

技术领域

本申请涉及用户信息处理技术领域，特别是涉及建立用户人际关系信息的方法及装置。

背景技术

大数据分析对电子商务交易平台而言具有巨大的意义，例如，通过大数据分析，可以获知用户性别年龄、工作、收入水平、兴趣偏好、地理位置等等，通过这些信息，可以进行用户潜在需求的挖掘，进而向用户进行更有针对性的商品推荐等操作。这种方式无论对于商家还是对于买家都可以获得良好的体验。首先，对于商家而言，可以使得商品获得更多的展示渠道，并且这种针对性较强的推荐，还可以提高商品浏览-购买转化率。同时，对于买家用户而言，由于可以更方便快捷的获得自己感兴趣的商品的相关信息，不需要输入关键词，或者在类目树中逐级查找，因此，缩短用户的操作路径，提高效率。

但是，现有技术中在进行用户需求挖掘时，仍然存在一些不足，例如，一些推荐出的商品对象可能并不是用户所真正需要的，而用户真正需要的商品对象又没有被推荐出来，等等，这样会对推荐资源等系统资源造成很大的浪费，也不利于提升用户体验。因此，如何提高信息推荐等环节上的准确度，以达到节省系统资源，提升用户体验等目的，成为需要本领域技术人员解决的技术问题。

发明内容

本申请提供了建立用户家庭关系信息的方法及装置，可以启发基于特定人际关系的信息进行用户需求挖掘，从而有利于节省系统资源，提升用户体验。

本申请提供了如下方案：

一种建立用户人际关系信息方法，包括：

提供用户特征信息，根据所述特征信息，确定用户之间的关联关系强度；

对于其中一指定用户，确定与所述指定用户之间的关联关系强度满足预置条件的至少一个候选用户；

根据所述采集到的预置维度上的特征信息，从所述候选用户中确定出与所述指定用户具有特定人际关系的至少一个目标用户；

保存所述指定用户与所述至少一个目标用户之间的特定人际关系信息。

一种数据对象推荐方法，包括：

提供特定人际关系信息库，所述信息库中保存有与指定用户具有特定人际关系的至少一个目标用户的信息；

在向指定用户客户端提供数据对象推荐信息时，根据所述用户关系信息库，确定所述与指定用户具有特定人际关系的至少一个目标用户；

为所述指定用户客户端提供与所述特定人际关系相关的数据对象推荐信息。

一种提供日历信息的方法，包括：

提供特定人际关系信息库，所述信息库中保存有与指定用户具有特定人际关系的至少一个目标用户的信息，以及在所述第一特定人际关系中，与所述目标用户相关的至少一个目标日期；

接收指定用户客户端提交的访问日历信息的请求；

利用所述特定人际关系信息库中保存的信息，提供与所述目标用户相关的目标日期信息。

一种数据对象集合信息处理方法，包括：

提供特定人际关系信息库，所述信息库中保存有与指定用户具有特定人际关系的至少一个目标用户的信息；

根据所述信息库，确定所述与指定用户具有特定人际关系的至少一个目标用户；

判断所述目标用户关联的待处理数据对象集合中是否存在符合预置条件的数据对象；

如果存在，则将所述符合预置条件的数据对象合并到所述指定用户关联的待处理数据对象集合中，以便在所述指定用户客户端对合并后的集合中的各个待处理数据进行统一处理。

一种数据对象集合信息处理方法，包括：

提供特定人际关系信息库，所述信息库中通过特定人际关系关联的多个用户的信息，以及各用户在所述特定人际关系中相对于其他用户所具有的身份信息；

提供待处理数据对象公用集合，并在接收到向所述公用集合中添加数据对象的请求时，记录添加所述数据对象的第一用户与数据对象之间的对应关系，所述第一用户为同一特定人际关系内的任一用户；

在接收到第二用户客户端查看所述公用集合的请求时，提供所述公用集合中的数据对象列表，以及所述第一用户在所述特定人际关系中相对于所述第二用户的身份信息。

一种建立用户人际关系信息装置，包括：

用户特征提供单元，用于提供用户特征信息，根据所述特征信息，确定用户之间的关联关系强度；

候选用户确定单元，用于对于其中一指定用户，确定与所述指定用户之间的关联关系强度满足预置条件的至少一个候选用户；

目标用户确定单元，用于根据所述采集到的预置维度上的特征信息，从所述候选用户中确定出与所述指定用户具有特定人际关系的至少一个目标用户；

关系保存单元，用于保存所述指定用户与所述至少一个目标用户之间的特定人际关系信息。

一种数据对象推荐装置，包括：

信息库提供单元，用于提供特定人际关系信息库，所述信息库中保存有与指定用户具有特定人际关系的至少一个目标用户的信息；

目标用户确定单元，用于在向指定用户客户端提供数据对象推荐信息时，根据所述用户关系信息库，确定所述与指定用户具有特定人际关系的至少一个目标用户；

信息推荐单元，用于为所述指定用户客户端提供与所述特定人际关系相关的数据对象推荐信息。

一种提供日历信息的装置，包括：

信息库提供单元，用于提供特定人际关系信息库，所述信息库中保存有与指定用户具有特定人际关系的至少一个目标用户的信息，以及在所述第一特定人际关系中，与所述目标用户相关的至少一个目标日期；

访问请求接收单元，用于接收指定用户客户端提交的访问日历信息的请求；

日历信息提供单元，用于利用所述特定人际关系信息库中保存的信息，提供与所述目标用户相关的目标日期信息。

一种数据对象集合信息处理装置，包括：

信息库提供单元，用于提供特定人际关系信息库，所述信息库中保存有与指定用户具有特定人际关系的至少一个目标用户的信息；

目标用户确定单元，用于根据所述信息库，确定所述与指定用户具有特定人际关系的至少一个目标用户；

判断单元，用于判断所述目标用户关联的待处理数据对象集合中是否存在符合预置条件的数据对象；

合并单元，用于如果存在，则将所述符合预置条件的数据对象合并到所述指定用户关联的待处理数据对象集合中，以便在所述指定用户客户端对合并后的集合中的各个待处理数据进行统一处理。

一种数据对象集合信息处理装置，包括：

信息库提供单元，用于提供特定人际关系信息库，所述信息库中通过特定人际关系关联的多个用户的信息，以及各用户在所述特定人际关系中相对于其他用户所具有的身份信息；

公用集合提供单元，用于提供待处理数据对象公用集合，并在接收到向所述公用集合中添加数据对象的请求时，记录添加所述数据对象的第一用户与数据对象之间的对应关系，所述第一用户为同一特定人际关系内的任一用户；

数据对象列表提供单元，用于在接收到第二用户客户端查看所述公用集合的请求时，提供所述公用集合中的数据对象列表，以及所述第一用户在所述特定人际关系中相对于所述第二用户的身份信息。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，可以通过数据挖掘的方式，发现并建立起用户之间的特定人际关系(例如，直系三代内的家庭关系，等等)，这样，通过这种特定人际关系信息，可以更丰满的了解用户需求，进而，在个性化推荐场景，定制化导购场景等技术上，可以通过增加用户特定人际关系属性的特征，更有针对性的进行用户需求的挖掘，有利于提高提供出的信息的质量，节省系统资源，提升用户体验。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请实施例提供的系统架构示意图；

图2是本申请实施例提供的第一方法的流程图；

图3是本申请实施例提供的第二方法的流程图；

图4是本申请实施例提供的第三方法的流程图；

图5是本申请实施例提供的用户界面示意图；

图6是本申请实施例提供的第四方法的流程图；

图7是本申请实施例提供的第五方法的流程图；

图8是本申请实施例提供的第一装置的示意图；

图9是本申请实施例提供的第二装置的示意图；

图10是本申请实施例提供的第三装置的示意图；

图11是本申请实施例提供的第四装置的示意图；

图12是本申请实施例提供的第五装置的示意图；。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

本申请发明人在实现本申请的过程中发现，现有技术在对用户进行维护及潜在需求挖掘时，通常都只针对单个账户进行，但是，在实际应用中，用户的需求可能会通过其所处的人际关系环境而体现出来。例如，用户可能经常需要给亲密账户购买礼物，包括，给用户的孩子/爱人/父母生日购买礼物，等等。为此，在本申请实施例中，可以通过数据挖掘的方式，发现并建立起用户之间的特定人际关系(例如、家庭关系，直系两代、三代以内的家庭关系，等等)，这样，通过这种特定人际关系信息，可以更丰满的了解用户需求，进而，在个性化推荐场景，定制化导购场景等技术上，可以通过增加算法中用户特定人际关系属性的特征，更多更好的进行数据对象的推荐等操作。

也就是说，本申请实施例首先可以通过丰富海量的平台用户信息、用户终端特征识别、抽样样本调研等方式获取用户与用户之间的信息，经过一系列的数据处理、算法及模型搭建，产生用户特定人际关系图谱，另外，还可以进行用户在人际关系中所处的角色识别等操作，从而可以为用户添加对应的标签，这样，可以使得用户的画像更为清晰和丰满，进而可以制定用户个性化日历、亲情互动、基于特定人际关系相关的数据对象推荐等多种应用场景，实现对用户需求的更深层次的挖掘，提升信息推荐质量，节省信息推荐资源。

具体实现时，参见图1，本申请实施例可以包括用户人际关系网络建立以及对该建立起的关系网络进行应用这样两个部分。其中，在进行用户人际关系网络建立时，数据源可以包括大数据平台(例如，大数据计算服务Odps等)、终端网络API、用户调研等多个部分，用于采集用户的特征信息，例如，Odps数据平台可以获取用户各类行为及特征数据，如身份证年龄、身份证性别、居住城市、收货地址、联系方式、购买分布、够买行为簇等等，基于网络终端的ip、uid判断可以获取并定位，通过上述粗略判断有人群关系的账号后，还可以通过投放调研问卷等方式，派生出用户真实关系判别数据，等等。在采集到一些特征数据后，可以通过同人信息、行为特征数据等进行分析，进而还可以生成机器学习样本，建立起模型。在算法模型的基础上，可以产出基于特定人际关系网的用户角色判别，并为用户的身份打上多重标签(妈妈、妻子等)，并产出以直系三代为原型的家庭关系图谱(例如，某用户的标签可以包括丈夫、父亲、儿子等等，当然，也可以是更简单或复杂的家庭关系图谱)。另外，还可以同时同步每个用户的主要值得纪念的日子(生日、与其家庭身份标签相关的节日、纪念日等)，用于用户服务及需求场景识别。最后，就可以利用数据库中记录的各项信息，在应用层进行各种应用，例如，可以进行基于人际关系的数据对象信息推荐，或者，可以基于单个账号同步其密切账号相关日子和需求，提供个性化日历，或者，还可以在指定类目打通“购物车”，实现购物车共享、合理合并埋单等功能，等等。

下面对具体的实现进行详细介绍。

实施例一

在该实施例一中，首先提供了一种建立用户人际关系信息方法，参见图2，该方法可以包括以下步骤：

S201：提供用户特征信息，根据所述特征信息，确定用户之间的关联关系强度；

具体采集用户特征信息时，可以有多种数据来源，如图1所示，采集的特征也可以是多个维度上的特征，例如，包括但不限于：年龄、性别、居住城市、联系方式等，另外，在电子商品交易平台内，采集的用户特征还可以包括访问销售平台过程中产生的记录信息，例如，具体可以包括以下中的一项或多项：访问销售平台时使用的网络地址信息/终端设备信息、登录使用的账号信息、常用收货地址信息、代付记录信息、关联的支付账户信息等。采集到以上信息后，可以对用户间的关系进行初步筛选，具体可以是根据输入的用户特征，输出两个用户之间的关联关系强度。例如，如果两个用户经常使用同一网络地址或者终端设备进行登录，则两者之间的关联强度会比较高，等等。

需要说明的是，在该步骤中，所谓的“用户”是指已经在当前系统(例如，某电子商务交易平台等)中注册了账号的人，也就是说，如果某个人能够被称为之为用户，则意味着他已经注册了账号，并且，在通常意义上而言，用户与账号是一一对应的。当然，在实际应用中，可能存在同一个人注册了多个账号的情况，为了能够识别出这种账号，可以预先建立识别模型，该模型通过对用户特征进行分析，可以识别出这些同人账号，具有该功能的模型就可以称为“同人模型”。具体实现时，这种同人模型通常是通过计算两个用户之间关联关系的强弱，来最终识别两个账号是否为同人账号，也就是说，这种同人模型的输出结果通常是两个用户之间关联关系的强度。例如，某同人模型可以将两个用户之间的关联关系强度定义为5级，每个级别对应一个得分，分别为1到5分，分数越高，代表两个用户之间的关联关系越强，如果某两个用户之间的关联关系强度为最高分，则这两个用户可能对应现实世界的同一人。如果两个用户之间的关联关系强度很低，则证明这两个用户在现实世界中可能基本不存在关联，等等。因此，在本申请实施例的该步骤S201中，就可以首先利用这种同人模型对用户进行初步计算，这样，对于每个用户，都可以确定出与其他用户之间的关联关系强度得分。

具体在采集用户信息时，对于一个来访问平台的用户，可以首先判别他是否已经登录，对于登录的账号，可以提取其用户名，未登录的，可以通过其设备编号或取历史cookie等来获取其历史uid，然后再关联到用户id，并关联其身份特征、年龄、交易情况等多个维度上的同人模型判别所需数据，通过算法判断可能与其有关系的用户id。

S202：对于其中一指定用户，确定与所述指定用户之间的关联关系强度满足预置条件的至少一个候选用户；

通过步骤S201，对于每个用户，都可以计算出与其他用户之间的关联关系强度，进而，在该步骤S202中，可以为各个用户确定出一候选用户集合，集合中包括与当前用户之间的关联关系强度满足预订条件的至少一个候选用户，例如，对于某用户A，与其关联关系强度大于3分的用户可以加入到该用户A的候选用户集合中。也就是说，候选用户集合中的用户数量可能是一个或者多个，当然，也可能存在集合中用户数量为零的情况。

S203：根据所述采集到的预置维度上的特征信息，从所述候选用户中确定出与所述指定用户具有特定人际关系的至少一个目标用户；

通过步骤S202，可以为每个用户确定出一候选用户集合，对于其中一指定用户，集合内各个候选用户与该指定用户之间的关联关系强度都比较高，进而，就可以从这些候选用户中，确定出可能与当前指定用户存在特定人际关系的目标用户，例如，家庭成员关系等。为了达到该目的，可以利用在步骤S201中采集到的用户特征信息进行进一步的判断。具体的，由于该步骤的目的是要识别出可能具有特定人际关系的用户，也就是说，需要判断出两个用户之间的关联关系是否由于具有某种特定的人际关系而产生的，为此，在该步骤中，可以以一些特定维度上的特征信息为判断依据，这些特定维度上的特征信息具体可以是指用户在访问数据对象服务器的过程中产生的记录信息。也就是说，在本申请实施例中，如果两个用户之间具有某种特定人际关系，则这两个用户在访问数据对象服务器的过程中通常会体现出一些特点，例如，可能会使用同一终端设备进行登录，或者，可能会具有代付或共用同一支付账户等情况。因此，可以通过对上述记录信息进行判断，确定出两个用户之间是否具有特定人际关系。

具体的，访问数据对象服务器过程中产生的记录信息具体可以包括：访问数据对象服务器时使用的网络地址信息/终端设备信息、收货地址信息、支付行为信息，等等。这样，具体在判断两个用户之间是否存在家庭关联关系时，可以根据所述记录信息执行判断。例如，如果所述指定用户与其中一候选用户在网络地址、终端设备和/或家庭住址类收货地址方面存在共用，并且在支付行为上存在关联，则将该候选用户确定为与所述指定用户之间具有第一特定人际关系的目标用户。其中，所述的第一特定人际关系就可以是指家庭关联关系等，如，可以是夫妻关系、父母与子女的关系，等等。所谓的支付行为上存在关联，具体可以是指指定用户与所述候选用户之间存在代付行为，和/或，所述指定用户与所述候选用户共用同一支付账户进行支付。

需要说明的是，在具体实现时，可以将两个用户之间在支付行为上是否具有关联性，作为重要的判断标准。也就是说，如果两个用户之间曾经有过共用同一支付账户的情况，例如，关联同一信用卡等，则这两个用户之间具有家庭关联关系的可能性会非常高，这是因为，如果两个用户之间不具有家庭关联关系，则通常在金钱方面会是相互隔离的，也就是说，即使在收货地址、终端设备等方面都具有共用的情况，也通常不会共用同一信用卡。而如果两个用户是同一家庭内的成员，则可能会存在支付账户共用的情况。或者，如果两个用户之间存在代付行为，则这两个用户也具有很高的可能性是属于同一家庭的成员，等等。

另外需要说明的是，在具体实现时，所谓的特定人际关系除了家庭关联关系，还可以是同事关系、合租的室友关系，等等，这些人际关系也可能会挖掘出用户需求，因此，也可以通过对用户特征的分析，来发现这种人际关系，进而用户进行用户需求的挖掘。例如，如果两个用户共用同一收货地址，并且该收货地址属于办公地址类，在支付行为上没有太多的关联，则这两个用户之间可能具有同事关系。或者，如果两个用户共用同一收货地址，并且该地址属于家庭住址类的地址，同样在支付行为上没有太多的关联，则这两个用户可能会具有合租的室友关系，等等。在实际应用中，可以根据实际的需求，确定出其中一种或者多种特定人际关系，并用于后续的具体应用中。

S204：保存所述指定用户与所述至少一个目标用户之间的特定人际关系。

在确定出与指定用户具有特定人际关系的目标用户后，可以通过用户关系信息库的方式进行保存，具体的，由于账号与用户之间具有对应关系，因此，在用户关系信息库中保存的信息可以包括：多个用户的账号，每个账号关联一个或多个与之具有特定人际关系的目标账号。例如，在具体实现时，用户关系信息库中保存的信息可以如表1所示：

表1

账号	具有特定人际关系的目标账号
		账号A	账号a1、账号a2、账号a3
账号B	账号b1、账号b2
		……	……

通过以上方式，可以确定出哪些用户之间是具有家庭关联关系，在优选的实现方式中，还可以进一步确定出：当指定用户与目标用户之间具有特定人际关系时，这两个用户之间具体的关系类型，例如，是夫妻关系，还是父母与子女的关系等等。具体的，在步骤S201中采集到的用户特征信息，还可以包括用户的年龄、性别等自然属性信息，因此，可以根据这些信息，来进一步确定用户之间的关系类型，进而，还可以确定出指定用户在这一特定人际关系下所扮演的角色，或者，所具有的身份。例如，通过前述各步骤确定出用户A与用户a1之间具有家庭关联关系，经确定，用户A的年龄为32岁，性别为男，用户a1的年龄为30岁，性别为女，则两者之间可能是夫妻关系，同时，还可以为该用户A添加“丈夫”这一身份标签，等等。进而，还可以在用户关系信息库中保存用户的身份标签，例如，具体可以保存为表2所示：

表2

账号	具有特定人际关系的目标账号	身份标签
			账号A	账号a1、账号a2、账号a3	丈夫、儿子、父亲
账号B	账号b1、账号b2	妻子、女儿
			……	……	……

以上所述通过对用户之间的特征分析的方式，可以发现其中一些用户之间可能存在家庭关联关系，并且还可以确定出具体的家庭关系类型，为用户打上多个身份标签等等。但在实际应用中，可能并不是所有的家庭成员都注册为销售平台中的用户，例如，某用户在家庭中扮演着父亲以及儿子的角色，但是，该用户的子女年龄还很小，没有注册账户，或者父母年龄比较大，没有注册账户，等等。没有注册账户，就意味着不是销售平台的用户，无法获取到这些人的特征，因此，通过前述方式建立的用户关系信息库可能会存在不够完善的情况。

为此，在本申请实施例中，还可以通过一些方式确定出指定用户在其家庭中相对于其他家庭成员的身份标签并保存，这里所述的其他家庭成员就可以是指非平台内注册用户。具体的，由于销售平台中会对用户的行为进行记录，例如，购买行为、浏览行为、聊天记录等等，因此，可以通过对这些信息进行分析，确定出一个用户在其家庭中还可能扮演的其他角色。例如，如果某用户经常购买婴儿用品类商品对象，则该用户可能还具有父亲或者母亲的身份，如果某用户经常规律性的购买米面粮油、保健品等类目的商品对象，配送到同一地址，则该用户还可能具有儿子或者女儿的身份，等等。总之，可以通过对指定用户历史交易记录信息等进行分析，确定出指定用户在家庭中可能具有的其他身份。在确定出来之后，同样可以添加到用户关系数据库中。

需要说明的是，在实际应用中，上述通过用户在数据对象服务器中产生的记录信息、自然属性信息等对用户关系进行确定的过程中，可以是在根据所述指定用户以及所述目标用户的自然属性信息，对所述指定用户在所述第一特定人际关系中相对于所述目标用户所具有的身份标签进行预测，然后，根据预测结果向所述指定用户客户端提供提示信息，所述提示信息用于对所述预测结果进行确认，在接收到确认信息后，再根据所述预测结果确定为所述指定用户在所述第一特定人际关系中相对于所述目标用户所具有的身份标签。也就是说，系统根据数据统计分析出的信息可以作为一种预测信息，具体对用户关系以及用户身份的确定，还可以通过由用户进行确认的方式来进行。另外，家庭消费通常会体现出与具体日期相关的特点，例如，作为丈夫，可能会在妻子的生日、结婚纪念日、情人节等日期具有购物需求；作为儿子，可能会在父母生日、父亲节、母亲节、传统节日等具有购物需求，等等。因此，在本申请实施例中，还可以确定出对于所述指定用户而言，在所述第一特定人际关系中，与所述目标用户相关的至少一个目标日期。例如，对于一个用户A，其身份标签有丈夫、儿子、父亲，则可以确定出该用户A的妻子的生日，两者的结婚纪念日，还可以确定出该用户A的儿子的生日，父母的生日等等。其中，如果用户A的某身份标签对应的家庭成员也是平台内注册用户，与日期相关的部分信息可以通过前述步骤S201采集到的信息中进行提取，如果不是平台内注册用户，则可以通过用户调研方式来获得，或者，还可以通过对当前指定用户的一些购物行为特征进行分析来获得，当然，即使是平台内的注册用户，也可以通过调研的方式来获得具体的目标日期信息，例如，在确定出用户a1是用户A的妻子的情况下，还可以询问用户A，具体的结婚纪念日、妻子生日等，并记录在用户关系库中，等等。另外，还可以在用户关系库中记录一些传统的节假日等，例如，在夫妻关系中，可以将情人节等，作为需要该指定用户关注的目标日期，在父母与子女的关系中，可以将母亲节、父亲节、重阳节等作为需要该指定用户关注的日期，等等。总之，还可以在用户关系信息库中保存与目标用户相关的目标日期信息，具体的，可以如以下表3所示：

表3

在确定出与具体的目标用户关联的目标日期的情况下，还可以确定出在所述第一特定人际关系中，与所述目标用户以及所述目标日期相关的待推荐的第一数据对象信息。例如，某目标用户a1是当前指定用户A的妻子，则在该人际关系中，该目标用户对应的目标日期可以有双方的结婚纪念日，在该日期，用户A可能会需要给用户a1购买礼物，等等。因此，可以在该日期，向用户A进行数据对象推荐。为了便于进行该推荐，可以预先在用户关系库中保存与该目标用户和/或该目标日期相关的待推荐的第一数据对象信息。例如，具体可以根据目标用户的购物偏好信息确定该第一数据对象信息，或者，还可以结合具体的日期确定第一数据对象信息，例如，可以根据经常被作为情人节礼物的数据对象类目(如巧克力、戒指等)确定待推荐的第一数据对象信息，等等。再或者，还可以根据指定用户的身份标签特征，来确定待推荐的第一数据对象信息，例如，指定用户具有“父亲”标签，相关的目标日期包括儿童节，则可以根据一些经常作为儿童节礼物的数据对象类目，确定待推荐的第一数据对象信息，等等。

另外，在具有家庭关联等特定人际关系的用户之间，除了其中一个用户可能会具有为其他用户购买礼物等数据对象的需求，还可能有其他方面的需求。例如，一些家庭成员之间共用的数据对象，包括日常用品、家用电器等，各个家庭成员都可能具有购买需求，为此，在进行数据对象推荐时，还可以基于这种特定人家关系，向各个成员用户进行数据对象推荐。在这种情况下，为了便于进行这种推荐，还可以预先确定出用于向所述指定用户以及与其具有所述特定人际关系的至少一个目标用户推荐的第二数据对象信息，这样，在向指定用户提供数据对象推荐信息时，还可以根据这种第二数据对象信息来进行推荐。

其中，具体在确定用于向所述指定用户以及与其具有所述特定人际关系的至少一个目标用户推荐的第二数据对象信息时，可以有多种方式。例如，在其中一种具体的实现方式下，可以是获取所述指定用户以及所述至少一个目标用户的历史操作行为记录信息，然后根据所述历史操作行为记录确定所述待推荐的第二数据对象信息。具体的，在一种情况下，可以根据所述历史操作行为记录判断是否存在对目标数据对象的周期性操作行为，如果是，根据该目标数据对象确定所述待推荐的第二数据对象信息。例如，通过对用户行为记录分析法下，某家庭关系网内的各个用户经常周期性购买纸巾、食用油等日常消费品，因此，这类的数据对象就可以用于向当前指定用户以及其他各成员用户进行推荐。

或者，在另一种情况下，有些数据对象可能具有更新换代属性，例如，家用电器等，这些数据对象可能并不会像纸巾等数据对象那样需要周期性购买，但是，在使用了一定的时间之后，由于出现老化、技术落后等现象，可能具有更新换代的需求，因此，也可以将这类数据对象作为推荐信息提供给用户，以此促进数据对象的消费升级。具体的，可以是判断用户的历史操作记录中是否存在预置类目的数据对象，如果存在，则确定对该数据对象执行预置操作的时间，如果从该时间到当前时间的时间间隔达到该类目对应的预置时间间隔阈值，则根据该预置类目确定为待推荐的第二数据对象信息。其中，所述类目对应的预置时间间隔阈值可以根据该类目下的数据对象对应的产品更新换代频率统计值而确定，当然，还可以通过其他方式确定。所谓用户的历史操作记录，可以包括当前指定用户以及与其具有特定人际关系的其他用户的操作记录，例如，在家庭关系中，只要其中一个家庭成员在历史操作记录中购买过某家用电器，则在该家庭电器使用了一定的年限后，可以向该家庭内的各个成员推荐出该家用电器的最新款等等。

总之，通过以上所述，可以建立起用户关系信息库，在该信息库中可以保存多项信息，例如，可以保存各个用户分别与哪些用户具有特定人际关系，各个用户在各自的特定人际关系中分别扮演哪些身份，这些身份对应的目标用户有哪些重要的日期，可能会使得用户具有购物需求，在各个日期待推荐的数据对象信息，等等(当然，在具体实现时，用户关系信息库中可以保存上述信息中的部分或者全部)。上述信息可以用来描述用户所处的人际关系背景及人际关系角色等信息，使得用户的画像更为清晰和丰满。在建立起用户关系信息库后，就可以利用信息库中保存的信息为用户提供各种服务，包括制定用户个性化日历、数据对象推荐、“购物车”打通等等，从而提升用户平台体验，增加亲情互动，启发基于家庭关系相关的消费场景，实现家庭消费升级。下面进行具体的举例介绍。

实施例二

以上实施例一对建立用户关系信息库的方式进行的介绍，当然，在具体实现时，还可以有其他的建立方式，这里不再一一介绍。从该实施例二开始，对具体的上层应用进行介绍。

该实施例二主要针对以下应用场景：在客户端首页等页面内可能存在“猜你喜欢”等版块，在现有技术中，在该版块通常是基于当前用户自身的历史购买或者浏览记录等，分析用户的购物偏好，然后进行推荐。但是，这种推荐信息只是从被推荐用户自身的购物偏好等信息出发，来挖掘用户可能感兴趣的数据对象进行推荐，显然，可能会存在推荐出的结果不能完全满足用户的日常需求的情况，准确性不高。为此，在本申请实施例中，由于预先建立了用户特定人际关系信息库，其中记录了用户的人际关系信息，而用户在访问数据对象网页的过程中，除了需要自己感兴趣的数据对象，可能还需要为特定人际关系中的其他用户选购商品，或者，为家庭等选购商品，因此，在本申请实施例中，还可以基于用户的特定人际关系信息，提供数据对象推荐信息。下面进行详细介绍。

参见图3，该实施例二提供了一种提供商品对象推荐信息的方法，该方法可以包括以下步骤：

S301：提供特定人际关系信息库，所述信息库中保存有与指定用户具有特定人际关系的至少一个目标用户的信息；

在该实施例二中，用户关系信息库中保存的基础信息可以是用户之间的特定人际关系信息，也就是说，可以如表1所示，当然也可以保存更多的信息，例如，表2、表3，另外还可以包括保存待推荐的第一数据对象信息，第二数据对象信息等等。

S302：在向指定用户客户端提供数据对象推荐信息时，根据所述用户关系信息库，确定所述与指定用户具有特定人际关系的至少一个目标用户；

在向指定用户客户端展示数据对象信息页面的过程中，如果需要在页面中提供数据对象推荐信息，则可以首先确定出与当前的指定用户具有特定人际关系的至少一个目标用户，以便后续根据这种特定人际关系信息，为当前的指定用户提供推荐信息。

S303：为所述指定用户客户端提供与所述特定人际关系相关的数据对象推荐信息。

在确定出与当前指定用户具有特定人际关系的目标用户之后，就可以为所述指定用户客户端提供与这种特定人际关系相关的商品对象推荐信息。其中，所谓的与目标用户相关的商品对象，可以通过多种方式确定。例如，在其中一种方式下，可以根据目标用户的年龄、性别等，提供目标用户所处年龄段的同性别用户普遍比较喜欢的商品对象，或者，还可以根据目标用户的购物偏好等信息，来提供推荐的商品对象信息。

另外，在具体实现时，如果用户特定关系信息库中保存有与所述目标用户相关的至少一个目标日期信息，则可以根据所述目标日期，为所述指定用户客户端提供与对应目标用户相关的数据对象推荐信息。例如，某用户A具有家庭关联关系的用户有用户a1、a2，a1是用户A的妻子，与用户a1相关的日期有：5月20日为用户a1的生日，8月1日是用户A与用户a1的结婚纪念日，用户a2是用户A的母亲，与a2相关的日期有：6月8日是用户a2的生日，等等。因此，在为用户A提供商品对象推荐信息时，可以在5月20之前的几天，或者8月1日之前的几天，推荐用户a1可能会感兴趣的商品对象，在6月8日之前的几天，可以推荐用户a2可能会感兴趣的商品对象，等等。在普通日期，可以推荐用户A自己可能会感兴趣的商品对象，等等。当然，如实施例一中所述，如果信息库中还保存有与所述目标用户以及所述目标日期相关的待推荐的第一数据对象信息，也即，预先对具体目标日期上对应的待推荐数据对象信息进行了确定，则可以直接根据这种待推荐的第一数据对象信息，来提供数据对象推荐信息。例如，如果待推荐的第一数据对象信息中保存的是数据对象的id等信息，则可以直接作为推荐的数据对象，如果待推荐的第一数据对象信息中保存的是数据对象的类目等信息，则可以根据这种类目信息，选择数据对象进行推荐，等等。

另外，如果所述信息库中还保存有：用于向所述指定用户以及与其具有所述特定人际关系的至少一个目标用户推荐的第二数据对象信息，则还可以根据所述待推荐的第二数据对象信息，提供数据对象推荐信息。其中，所述待推荐的第二数据对象信息具体可以包括：所述指定用户和/或所述目标用户存在周期性操作行为的目标数据对象，例如，日用品类的数据对象，或者，所述指定用户和/或所述目标用户操作过的具有更新换代属性的数据对象，例如，家用电器类的数据对象，等等。

需要说明的是，对于上述待推荐的第二数据对象信息，由于属于具有特定人际关系的各个用户共用的数据对象，各个用户都可能会具有对该数据对象进行操作(例如，购买操作等)的需求，因此，在各个用户提供推荐信息时，都可能会根据该同一份待推荐的第二数据对象信息进行推荐。这样，就可能存在以下情况：对于某待推荐的第二数据对象，可能已经有目标用户客户端在最近预置时间段内对其执行了预置操作，此时，可以将该数据对象从推荐的数据对象集合中删除，也即，不再向当前指定用户进行推荐。例如，在家庭关系中，待推荐的第二数据对象信息包括电视机类目，但是，在向某指定用户提供推荐信息时，可能已经有其他家庭成员在近期购买了某款电视机，此时，由于同一家庭内通常不会在短时间内购买多台电视机，因此，当前用户可能不再有购买电视机的需求，因此，在向当前用户提供推荐信息时，则可以不再推荐电视机类目的数据对象，从而可以进一步节省推荐资源。

总之，通过该实施例二，在向用户提供数据对象推荐信息时，可以首先确定出与该用户具有特定人际关系的目标用户，然后，提供与该特定人际关系相关的数据对象信息，这样，在用户具有为其人际关系中的其他用户购买礼物等需求，或者具有为人际关系中的各个用户成员购买共用的数据对象等需求时，可以直接根据推荐信息进行浏览，可以提高推荐信息的有效性，节省推荐资源，缩短用户的操作路径。

实施例三

该实施例三对应的应用场景为：用户在浏览数据对象信息的过程中，可能会具有查看日历信息的需求，进而可以根据具体的日期确定是否需要为某用户购买礼物，或者是否到了需要为家庭购买日用品的日期，等等。但是，在现有技术中，数据对象页面内通常不会包括日历信息，用户通常只能通过终端设备中的日历应用中进行查看，显然，这会使得用户的操作路径很长。并且，可能出现用户忘记了某重要日期等情况，例如，用户可能忘记了某一天是其结婚纪念日，以至于无法及时购买相关的礼物，等等。可见，对于具有购物等需求的用户而言，现有技术中的日历系统中的信息过于简单，无法充分起到信息提示作用。为此，在本申请实施例中提供了一种提供日历信息的方法，也就是说，在本申请实施例三中，可以为用户提供日历信息，并且，可以在日历中展示出与当前用户具有特定人际关系的目标用户相关的日期信息，例如，妻子生日、母亲节等等，这样，可以通过这种方式对用户进行更有针对性的提示。

参见图4，该方法可以包括以下步骤：

S401：提供特定人际关系信息库，所述信息库中保存有与指定用户具有特定人际关系的至少一个目标用户的信息，以及在所述第一特定人际关系中，与所述目标用户相关的至少一个目标日期；

在该实施例中，特定人际关系信息库中保存的信息主要可以包括与指定用户具有特定人际关系的至少一个目标用户的信息，以及在所述第一特定人际关系中，与所述目标用户相关的至少一个目标日期。当然，在实际应用中，信息库中还可以保存指定用户在特定人际关系中具有的身份标签信息。如实施例一所述，同一用户可能具有多重身份标签，这些身份标签信息以及相关的目标日期信息，可以通过多种渠道获得，并保存到用户关系信息库中。例如，一部分身份标签可以是通过对用户之间的关联关系分析结果以及用户的年龄、性别等信息来确定，另一部分身份标签可以通过用户的历史行为记录等信息来分析获得，再者，还可以结合用户调研等信息，对用户关系信息库中的数据进行确认或者完善。

S402：接收指定用户客户端提交的访问日历信息的请求；

在具体实现时，可以在客户端的用户界面内提供查看日历的操作选项，用户需要查看日历时，可以通过该操作选项发起相应的请求。当然，也可以将日历默认展示在某用户界面内，这样，接收到打开该用户界面的请求时，就意味着接收到访问日历信息的请求。

S403：利用所述特定人际关系信息库中保存的信息，提供与所述目标用户相关的目标日期信息。

在接收到展示日历信息的请求后，可以首先确定出当前的指定用户的账号、id的等标识信息，进而，可以在特定人际关系信息库中提取出该指定用户关联的至少一个目标用户，并且可以提取出对应的目标日期信息，这样，在返回响应时，可以将这种目标日期信息返回，进而，客户端就可以在提供日历信息时，对这种目标日期信息进行标注。这种标注的信息可以对用户起到提醒的作用。

另外，参见图5，除了可以在日历中提供目标日期，还可以在对应的日期提供数据对象推荐信息，也就是说，可以推荐用户在对应的日期购买推荐出的数据对象。其中，关于具体将哪个或者哪些数据对象作为推荐信息进行提供，可以有多种具体的确定方式。例如，可以根据用户的身份以及具体的日期特点进行推荐，如，假设某日期是当前用户妻子的生日，则可以根据预先统计的信息，推荐出经常被作为生日礼物的商品对象，假设某日期是当前用户儿子的生日，则可以推荐出一些儿童用品等等。另外，在推荐的过程中，还可以综合考虑当前的时令、用户的购买力等多方面的信息。

或者，在另一种方式下，由于在基于特定人际关系的消费中，用户购物的目的通常是把购买到的数据对象作为礼物送给与其具有特定人际关系的目标用户，因此，在进行数据对象推荐时，还可以考虑对应目标用户的购物偏好等信息。当然，如实施例一中所述，还可以在特定人际关系信息库中保存与目标用户和/或目标日期对应的待推荐数据对象信息，这样，可以直接根据这种保存的信息进行数据对象推荐。

总之，通过该实施例三，可以在日历信息中为用户提供与其具有特定人际关系的目标用户相关的日期信息，例如，可以是家庭成员的生日、纪念日等等。这样，用户可以直观的看到可能需要购物的日期，避免有遗忘等情况出现。另外，还可以在日历中对应的目标日期上直接提供商品对象推荐信息，用户可以直接基于推荐信息进行购买，可以缩短用户的操作路径。

实施例四

该实施例四针对的应用场景可以为：用户在浏览数据对象的过程中，如果对某数据对象感兴趣，则可以通过“立即购买”等选项进行下单操作。但是，用户经常需要购买多件数据对象，因此，现有的销售平台还为用户提供了“购物车”功能。用户可以将需要购买的数据对象加入到“购物车”中，进而再基于“购物车”内的多件数据对象进行统一的下单操作，从而可以缩短用户的操作路径，也可以使得系统内的订单数量减少，便于关联。另外，“购物车”功能在另一种情况下也发挥着积极的作用，例如，有些商家或者平台可能会推出一些“满减”等活动，包括在同一店铺内购物满一定金额，可以享受一定的优惠，或者，在参加活动的多个店铺内购物满一定的金额或数量，可以享受优惠，等等。通过“购物车”功能，可以将多件数据对象合并到同一个订单中进行购买，从而使得其金额总数达到活动的优惠条件。但是，在现有技术中，用户的“购物车”都是基于用户个人的操作而生成的，因此，经常会出现以下情况：为了满足活动的优惠条件，用户经常需要进行“凑单”等操作，也即将一些本来不在计划内的数据对象加入到“购物车”中，与其他的数据对象一起进行购买。这种方式虽然能够使得用户享受到相应的优惠，但是，毕竟“迫使”用户多购买了计划外的数据对象，因此，可能会从一定程度上影响用户体验。

为此，在本申请实施例四中，提供了另一种对特定人际关系信息库的应用方式，也即，可以对具有特定人际关系的用户之间的待处理数据对象集合进行打通，其中，所谓待处理数据对象集合，可以记录有至少一个待处理的数据对象信息，也即，俗称的“购物车”等。也就是说，在特定人际关系消费场景下，同一特定人际关系中的各个用户可能会各自将一些数据对象加入到各自的“购物车”中，但是，这些用户之间由于具有比较亲密的关系，因此，在支付行为上通常是可以互通的，这就为“购物车”的打通提供了可行性。并且，通过打通“购物车”，还可以实现跨用户的“合单”操作，有利于进一步控制系统中的订单数量，并且，原本分散在多个用户的订单支付等操作，可以集中到同一个用户处进行，因此，也可以节省系统资源，避免多次访问支付账户等操作。另外，通过将不同用户之间的“购物车”打通，还可以使得同一特定人际关系内的购物过程更容易满足一些活动的优惠条件，减少“凑单”等情况的发生，从而有利于提升用户体验。

具体的，参见图6，本申请实施例六提供了一种数据对象集合处理方法，该方法可以包括以下步骤：

S601：提供特定人际关系信息库，所述信息库中保存有与指定用户具有特定人际关系的至少一个目标用户的信息；

该步骤与前述实施例二中的步骤S301类似，具体的实现方式可以参见实施例一中的介绍，这里不再赘述。

S602：根据所述信息库，确定所述与指定用户具有特定人际关系的至少一个目标用户；

该步骤的执行时机可以有多种，例如，可以是在当前的指定用户将某个符合条件的数据对象添加到数据对象集合中时进行处理，或者，在当前指定用户将要对数据对象集合中的数据对象进行付款时，再或者，还可以是在用户的请求操作触发下进行处理，等等。具体在进行处理时，可以首先根据所述特定人际关系信息库，确定所述与指定用户具有特定人际关系的目标用户，也即，使得加入“购物车”的行为成为以家庭等特定人际关系团体为单位的行为，不同用户之间的“购物车”可以进行打通。

S603：判断所述目标用户关联的待处理数据对象集合中是否存在符合预置条件的数据对象；

在确定出目标用户之后，可以首先查看该目标用户的数据对象集合中包含哪些数据对象，并判断其中是否包含符合预置条件的数据对象。其中，预置条件的设置可以有多种方式。具体的，其中一种方式下，可以按照类目进行设置，例如，可以是预先对家庭成员之间可能会共同关注的类目进行列举，如，可以包括日常用品类、家居用品类等等，也就是说，如果某指定用户与其家庭成员用户的购物车中均包括一些特定类目下的数据对象，则可以进行购物车合并，等等。或者，在另一种方式下，还可以按照“活动”指定的范围等进行条件设置。例如，可以根据具体“活动”指定的参加活动的数据对象的范围进行设定，例如，可以某店铺内，或者某些店铺内，等等。也即，如果某目标用户关联的数据对象集合中存在某数据对象，该数据对象与当前指定用户关联的数据对象集合中的某数据对象，同属于参加某活动的数据对象范围，则可以合并到当前指定用户关联的数据对象集合中，等等。

S604：如果存在，则将所述符合预置条件的数据对象合并到所述指定用户关联的数据对象集合中，以便在所述指定用户客户端对合并后的集合中的各个待处理数据进行统一处理。

如果目标用户的“购物车”中存在符合条件的数据对象，则可以与当前指定用户“购物车”内的数据对象进行合并，这样，当前指定用户可以对这些合并后的数据对象进行统一的下单、付款等处理操作。

需要说明的是，在具体实现时，为了防止重复下单等情况的发生，在将目标用户的部分数据对象合并到当前指定用户的数据对象集合中后，可以对所述目标用户的数据对象集合中被合并的数据对象进行标记。这样，目标用户可以根据这种标记，确定出哪些数据对象是被合并到其他用户的数据对象集合中。另外，在所述指定用户数据对象集合中的数据对象被处理完成后，还可以将所述目标用户的数据对象集合中被合并的数据对象删除。

在本申请实施例提供的这种“购物车打通”的实现方式中，由于当前指定用户与目标用户同属于同一特定人际关系团体，在支付资源上通常并不是相互隔离，因此，合并下单的方式可以节约系统资源，提高购物效率。另外，对于参加“满减活动”等情况，可以不再需要单个用户通过“凑单”的方式多购买一些计划外的数据对象，以满足活动要求，因此，可以更好的提升用户体验。

实施例五

该实施例五的应用场景与实施例四类似，但是在该实施例五中提供了另一种数据对象集合信息处理方法，也即，可以为同一特定人际关系团体提供一待处理数据对象公用集合，例如，公用的“购物车”等，这样，同一特定人际关系团体内的各个用户就都可以向该公用集合中添加数据对象，各个用户也可以分别查看该公用集合中的数据对象列表，并且，还可以展示出各数据对象的添加者用户相对于查看者用户的身份。参见图7，该方法具体可以包括以下步骤：

S701：提供特定人际关系信息库，所述信息库中通过特定人际关系关联的多个用户的信息，以及各用户在所述特定人际关系中相对于其他用户所具有的身份信息；

这里的多个用户就可以包括前述实施例中所述的指定用户以及所述至少一个目标用户，在该实施例中，指定用户以及所述至少一个目标用户都有可能是“共用集合”的数据对象添加者，也都有可能是共用集合的查看者，因此，统一用“多个用户”进行描述。

S702：提供待处理数据对象公用集合，并在接收到向所述公用集合中添加数据对象的请求时，记录添加所述数据对象的第一用户与数据对象之间的对应关系，所述第一用户为同一特定人际关系内的任一用户；

在客户端，可以向用户提供将数据对象添加到公用集合的操作选项，这样，用户就可以将其感兴趣的数据对象添加到该公用集合中。对于系统而言，在接收到这种添加请求后，还可以记录添加所述数据对象的第一用户与数据对象之间的对应关系，这样可以使得各个用户知晓各数据对象分别是由哪个用户添加到公用集合中的。

S703：在接收到第二用户客户端查看所述公用集合的请求时，提供所述公用集合中的数据对象列表，以及所述第一用户在所述特定人际关系中相对于所述第二用户的身份信息。

特定人际关系内的各个用户都可以请求查看公用集合中的数据对象列表，并且，在提供数据对象列表中，还可以提供执行添加操作的第一用户的信息。其中，在本申请实施例中，关于第一用户的信息，可以包括第一用户在所述特定人际关系中相对于第二用户的身份信息，其中，第二用户就可以是当前查看共用集合的用户，具体也可以是当前特定人际关系中的任一用户。也就是说，对于不同的第二用户，在展示公用集合时，其中的各个数据对象的添加者用户的身份标签可以随之发生变化。例如，某用户A在查看公用集合时，可以发现其中的数据对象1对应的第一用户的标识为“老婆”，数据对象2对应的第一用户的标识为“我”。而在用户a1查看公用集合时，可以发现其中的数据对象1对应的第一用户的标识为“我”，数据对象2对应的第一用户的标识为“老公”，等等。

总之，在本申请实施例中，可以直接提供一个公用集合，使得同一特定人际关系内的各个用户都可以向该共用集合中添加待处理的数据对象，并且，还可以提供各个数据对象的添加者用户相对于查看者用户的身份标签等信息。这样，可以直接生成一个“大购物车”，可以实现实施例四中所述的“购物车打通”后的效果，但是，由于不再需要系统执行“打通”操作，因此，可以进一步节省系统资源，也可以降低“重复下单”等出错的概率。

与实施例一相对应，本申请实施例还提供了一种建立用户人际关系信息装置，参见图8，该装置具体可以包括：

用户特征提供单元801，用于提供用户特征信息，根据所述特征信息，确定用户之间的关联关系强度；

候选用户确定单元802，用于对于其中一指定用户，确定与所述指定用户之间的关联关系强度满足预置条件的至少一个候选用户；

目标用户确定单元803，用于根据所述采集到的预置维度上的特征信息，从所述候选用户中确定出与所述指定用户具有特定人际关系的至少一个目标用户；

关系保存单元804，用于保存所述指定用户与所述至少一个目标用户之间的特定人际关系信息。

其中，所述预置维度上的特征信息包括访问数据对象服务器过程中产生的记录信息。

具体的，所述记录信息包括以下中的一个或多个维度：访问所述数据对象服务器时使用的网络地址信息/终端设备信息、收货地址信息、支付行为信息。

其中，目标用户确定单元803具体可以用于：

如果所述指定用户与其中一候选用户在网络地址、终端设备和/或家庭住址类收货地址方面存在共用，并且在支付行为上存在关联，则将该候选用户确定为与所述指定用户之间具有第一特定人际关系的目标用户。

其中，所述在支付行为上存在关联包括：

所述指定用户与所述候选用户之间存在代付行为，和/或，所述指定用户与所述候选用户共用同一支付账户进行支付。

具体实现时，该装置还可以包括：

身份标签确定单元，用于根据所述指定用户以及所述目标用户的自然属性信息，确定所述指定用户在所述第一特定人际关系中相对于所述目标用户所具有的身份标签。

具体实现时，所述身份标签确定单元具体可以包括：

预测子单元，用于根据所述指定用户以及所述目标用户的自然属性信息，对所述指定用户在所述第一特定人际关系中相对于所述目标用户所具有的身份标签进行预测；

提示子单元，用于根据预测结果向所述指定用户客户端提供提示信息，所述提示信息用于对所述预测结果进行确认；

确定子单元，用于在接收到确认信息后，根据所述预测结果确定为所述指定用户在所述第一特定人际关系中相对于所述目标用户所具有的身份标签。

另外，该装置还可以包括：

日期信息确定单元，用于确定在所述第一特定人际关系中，与所述目标用户相关的至少一个目标日期。

第一推荐信息确定单元，用于确定在所述第一特定人际关系中，与所述目标用户和/或所述目标日期相关的待推荐的第一数据对象信息。

具体实现时，所述第一推荐信息确定单元具体可以用于：

根据所述指定用户在所述第一特定人际关系中的身份标签特征、所述目标日期特征和/或所述目标用户的偏好信息，确定所述待推荐的第一数据对象信息。

另外，该装置还可以包括：

第二推荐信息确定单元，用于确定用于向所述指定用户以及与其具有所述特定人际关系的至少一个目标用户推荐的第二数据对象信息。

其中，第二推荐信息确定单元具体可以包括：

行为记录信息获取子单元，用于获取所述指定用户以及所述至少一个目标用户的历史操作行为记录信息；

记录信息分析子单元，用于根据所述历史操作行为记录确定所述待推荐的第二数据对象信息。

具体的，所述记录信息分析子单元具体可以用于：

根据所述历史操作行为记录判断是否存在对目标数据对象的周期性操作行为，如果是，根据该目标数据对象确定所述待推荐的第二数据对象信息。

或者，在另一种实现方式下，记录信息分析子单元具体可以用于：

判断所述历史操作记录中是否存在预置类目的数据对象，如果存在，则确定对该数据对象执行预置操作的时间，如果从该时间到当前时间的时间间隔达到该类目对应的预置时间间隔阈值，则根据该预置类目确定为待推荐的第二数据对象信息。

其中，所述类目对应的预置时间间隔阈值根据该类目下的数据对象对应的产品更新换代频率统计值而确定。

与实施例二相对应，本申请实施例还提供了一种数据对象推荐装置，参见图9，该装置具体可以包括：

信息库提供单元901，用于提供特定人际关系信息库，所述信息库中保存有与指定用户具有特定人际关系的至少一个目标用户的信息；

目标用户确定单元902，用于在向指定用户客户端提供数据对象推荐信息时，根据所述用户关系信息库，确定所述与指定用户具有特定人际关系的至少一个目标用户；

信息推荐单元903，用于为所述指定用户客户端提供与所述特定人际关系相关的数据对象推荐信息。

具体实现时，所述信息库中还保存有：在所述第一特定人际关系中，与所述目标用户相关的至少一个目标日期；此时，所述信息推荐单元903具体可以用于：

根据所述目标日期，为所述指定用户客户端提供与对应目标用户相关的数据对象推荐信息。

另外，所述信息库中还保存有：与所述目标用户以及所述目标日期相关的待推荐的第一数据对象信息；所述信息推荐单元903具体可以用于：

在所述目标日期，根据所述待推荐的第一数据对象信息，提供数据对象推荐信息。

或者，所述信息库中还可以保存有：用于向所述指定用户以及与其具有所述特定人际关系的至少一个目标用户推荐的第二数据对象信息；

此时，所述信息推荐单元903具体可以用于：

根据所述待推荐的第二数据对象信息，提供数据对象推荐信息。

其中，所述待推荐的第二数据对象信息包括：所述指定用户和/或所述目标用户存在周期性操作行为的目标数据对象，或者，所述指定用户和/或所述目标用户操作过的具有更新换代属性的数据对象。

另外，该装置还可以包括：

判断单元，用于判断所述目标用户客户端是否已在最近预置时间段内对待推荐的数据对象执行了预置操作，如果是，则将该数据对象从推荐的数据对象集合中删除。

与实施例三相对应，本申请实施例还提供了一种提供日历信息的装置，参见图10，该装置具体可以包括：

信息库提供单元1001，用于提供特定人际关系信息库，所述信息库中保存有与指定用户具有特定人际关系的至少一个目标用户的信息，以及在所述第一特定人际关系中，与所述目标用户相关的至少一个目标日期；

访问请求接收单元1002，用于接收指定用户客户端提交的访问日历信息的请求；

日历信息提供单元1003，用于利用所述特定人际关系信息库中保存的信息，提供与所述目标用户相关的目标日期信息。

具体实现时，该装置还可以包括：

信息推荐单元，用于提供所述目标用户和/或目标日期相关的推荐商品对象信息。

与实施例四相对应，本申请实施例还提供了一种数据对象集合信息处理装置，参见图11，该装置具体可以包括：

信息库提供单元1101，用于提供特定人际关系信息库，所述信息库中保存有与指定用户具有特定人际关系的至少一个目标用户的信息；

目标用户确定单元1102，用于根据所述信息库，确定所述与指定用户具有特定人际关系的至少一个目标用户；

判断单元1103，用于判断所述目标用户关联的待处理数据对象集合中是否存在符合预置条件的数据对象；

合并单元1104，用于如果存在，则将所述符合预置条件的数据对象合并到所述指定用户关联的待处理数据对象集合中，以便在所述指定用户客户端对合并后的集合中的各个待处理数据进行统一处理。

具体实现时，该装置还可以包括：

标记单元，用于对所述目标用户关联的数据对象集合中被合并的数据对象进行标记。

另外还可以包括：

删除单元，用于在所述指定用户关联的合并后的数据对象集合中的数据对象被处理完成后，将所述目标用户关联的数据对象集合中被合并的数据对象删除。

与实施例四相对应，本申请实施例还提供了一种数据对象集合信息处理装置，参见图12，该装置具体可以包括：

信息库提供单元1201，用于提供特定人际关系信息库，所述信息库中通过特定人际关系关联的多个用户的信息，以及各用户在所述特定人际关系中相对于其他用户所具有的身份信息；

公用集合提供单元1202，用于提供待处理数据对象公用集合，并在接收到向所述公用集合中添加数据对象的请求时，记录添加所述数据对象的第一用户与数据对象之间的对应关系，所述第一用户为同一特定人际关系内的任一用户；

数据对象列表提供单元1203，用于在接收到第二用户客户端查看所述公用集合的请求时，提供所述公用集合中的数据对象列表，以及所述第一用户在所述特定人际关系中相对于所述第二用户的身份信息。

通过本申请实施例，可以通过数据挖掘的方式，发现并建立起用户之间的特定人际关系(例如，直系三代内的家庭关系，等等)，这样，通过这种特定人际关系信息，可以更丰满的了解用户需求，进而，在个性化推荐场景，定制化导购场景等技术上，可以通过增加用户特定人际关系属性的特征，更有针对性的进行用户需求的挖掘，有利于提高提供出的信息的质量，节省系统资源，提升用户体验。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的建立用户人际关系信息的方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (32)

1.一种建立用户人际关系信息方法，其特征在于，包括：

提供用户特征信息，根据所述特征信息，确定用户之间的关联关系强度；

对于其中一指定用户，确定与所述指定用户之间的关联关系强度满足预置条件的至少一个候选用户；

根据所述采集到的预置维度上的特征信息，从所述候选用户中确定出与所述指定用户具有特定人际关系的至少一个目标用户；

保存所述指定用户与所述至少一个目标用户之间的特定人际关系信息。

2.根据权利要求1所述的方法，其特征在于，所述预置维度上的特征信息包括访问数据对象服务器过程中产生的记录信息。

3.根据权利要求2所述的方法，其特征在于，所述记录信息包括以下中的一个或多个维度：访问所述数据对象服务器时使用的网络地址信息/终端设备信息、收货地址信息、支付行为信息。

4.根据权利要求3所述的方法，其特征在于，所述确定目标用户的步骤，具体包括：

如果所述指定用户与其中一候选用户在网络地址、终端设备和/或家庭住址类收货地址方面存在共用，并且在支付行为上存在关联，则将该候选用户确定为与所述指定用户之间具有第一特定人际关系的目标用户。

5.根据权利要求4所述的方法，其特征在于，所述在支付行为上存在关联包括：

所述指定用户与所述候选用户之间存在代付行为，和/或，所述指定用户与所述候选用户共用同一支付账户进行支付。

6.根据权利要求4所述的方法，其特征在于，还包括：

根据所述指定用户以及所述目标用户的自然属性信息，确定所述指定用户在所述第一特定人际关系中相对于所述目标用户所具有的身份标签。

7.根据权利要求6所述的方法，其特征在于，所述确定身份标签的步骤具体包括：

根据所述指定用户以及所述目标用户的自然属性信息，对所述指定用户在所述第一特定人际关系中相对于所述目标用户所具有的身份标签进行预测；

根据预测结果向所述指定用户客户端提供提示信息，所述提示信息用于对所述预测结果进行确认；

在接收到确认信息后，根据所述预测结果确定为所述指定用户在所述第一特定人际关系中相对于所述目标用户所具有的身份标签。

8.根据权利要求6所述的方法，其特征在于，还包括：

确定在所述第一特定人际关系中，与所述目标用户相关的至少一个目标日期。

9.根据权利要求8所述的方法，其特征在于，还包括：

确定在所述第一特定人际关系中，与所述目标用户和/或所述目标日期相关的待推荐的第一数据对象信息。

10.根据权利要求9所述的方法，其特征在于，所述确定所述待推荐的第一数据对象信息的步骤，具体包括：

根据所述指定用户在所述第一特定人际关系中的身份标签特征、所述目标日期特征和/或所述目标用户的偏好信息，确定所述待推荐的第一数据对象信息。

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

确定用于向所述指定用户以及与其具有所述特定人际关系的至少一个目标用户推荐的第二数据对象信息。

12.根据权利要求11所述的方法，其特征在于，所述确定所述待推荐的第二数据对象信息的步骤，具体包括：

获取所述指定用户以及所述至少一个目标用户的历史操作行为记录信息；

根据所述历史操作行为记录确定所述待推荐的第二数据对象信息。

13.根据权利要求12所述的方法，其特征在于，所述根据所述历史操作行为记录确定所述待推荐的第二数据对象信息，包括：

根据所述历史操作行为记录判断是否存在对目标数据对象的周期性操作行为，如果是，根据该目标数据对象确定所述待推荐的第二数据对象信息。

14.根据权利要求12所述的方法，其特征在于，所述根据所述历史操作行为记录确定所述待推荐的第二数据对象信息，包括：

判断所述历史操作记录中是否存在预置类目的数据对象；

如果存在，则确定对该数据对象执行预置操作的时间，如果从该时间到当前时间的时间间隔达到该类目对应的预置时间间隔阈值，则根据该预置类目确定为待推荐的第二数据对象信息。

15.根据权利要求14所述的方法，其特征在于，所述类目对应的预置时间间隔阈值根据该类目下的数据对象对应的产品更新换代频率统计值而确定。

16.一种数据对象推荐方法，其特征在于，包括：

提供特定人际关系信息库，所述信息库中保存有与指定用户具有特定人际关系的至少一个目标用户的信息；

在向指定用户客户端提供数据对象推荐信息时，根据所述用户关系信息库，确定所述与指定用户具有特定人际关系的至少一个目标用户；

为所述指定用户客户端提供与所述特定人际关系相关的数据对象推荐信息。

17.根据权利要求16所述的方法，其特征在于，所述信息库中还保存有：在所述第一特定人际关系中，与所述目标用户相关的至少一个目标日期；

所述为所述指定用户客户端提供与所述特定人际关系相关的数据对象推荐信息，包括：

根据所述目标日期，为所述指定用户客户端提供与对应目标用户相关的数据对象推荐信息。

18.根据权利要求17所述的方法，其特征在于，所述信息库中还保存有：与所述目标用户以及所述目标日期相关的待推荐的第一数据对象信息；

所述在所述目标日期，为所述指定用户客户端提供与对应目标用户相关的数据对象推荐信息，包括：

在所述目标日期，根据所述待推荐的第一数据对象信息，提供数据对象推荐信息。

19.根据权利要求16所述的方法，其特征在于，所述信息库中还保存有：用于向所述指定用户以及与其具有所述特定人际关系的至少一个目标用户推荐的第二数据对象信息；

所述为所述指定用户客户端提供与所述特定人际关系相关的数据对象推荐信息，包括：

根据所述待推荐的第二数据对象信息，提供数据对象推荐信息。

20.根据权利要求19所述的方法，其特征在于，所述待推荐的第二数据对象信息包括：所述指定用户和/或所述目标用户存在周期性操作行为的目标数据对象，或者，所述指定用户和/或所述目标用户操作过的具有更新换代属性的数据对象。

21.根据权利要求19所述的方法，其特征在于，所述根据所述待推荐的第二数据对象信息，提供数据对象推荐信息时，还包括：

判断所述目标用户客户端是否已在最近预置时间段内对待推荐的数据对象执行了预置操作，如果是，则将该数据对象从推荐的数据对象集合中删除。

22.一种提供日历信息的方法，其特征在于，包括：

提供特定人际关系信息库，所述信息库中保存有与指定用户具有特定人际关系的至少一个目标用户的信息，以及在所述第一特定人际关系中，与所述目标用户相关的至少一个目标日期；

接收指定用户客户端提交的访问日历信息的请求；

利用所述特定人际关系信息库中保存的信息，提供与所述目标用户相关的目标日期信息。

23.根据权利要求22所述的方法，其特征在于，还包括：

提供所述目标用户和/或目标日期相关的推荐商品对象信息。

24.一种数据对象集合信息处理方法，其特征在于，包括：

提供特定人际关系信息库，所述信息库中保存有与指定用户具有特定人际关系的至少一个目标用户的信息；

根据所述信息库，确定所述与指定用户具有特定人际关系的至少一个目标用户；

判断所述目标用户关联的待处理数据对象集合中是否存在符合预置条件的数据对象；

如果存在，则将所述符合预置条件的数据对象合并到所述指定用户关联的待处理数据对象集合中，以便在所述指定用户客户端对合并后的集合中的各个待处理数据进行统一处理。

25.根据权利要求24所述的方法，其特征在于，还包括：

对所述目标用户关联的数据对象集合中被合并的数据对象进行标记。

26.根据权利要求24所述的方法，其特征在于，还包括：

在所述指定用户关联的合并后的数据对象集合中的数据对象被处理完成后，将所述目标用户关联的数据对象集合中被合并的数据对象删除。

27.一种数据对象集合信息处理方法，其特征在于，包括：

提供特定人际关系信息库，所述信息库中通过特定人际关系关联的多个用户的信息，以及各用户在所述特定人际关系中相对于其他用户所具有的身份信息；

提供待处理数据对象公用集合，并在接收到向所述公用集合中添加数据对象的请求时，记录添加所述数据对象的第一用户与数据对象之间的对应关系，所述第一用户为同一特定人际关系内的任一用户；

在接收到第二用户客户端查看所述公用集合的请求时，提供所述公用集合中的数据对象列表，以及所述第一用户在所述特定人际关系中相对于所述第二用户的身份信息。

28.一种建立用户人际关系信息装置，其特征在于，包括：

用户特征提供单元，用于提供用户特征信息，根据所述特征信息，确定用户之间的关联关系强度；

候选用户确定单元，用于对于其中一指定用户，确定与所述指定用户之间的关联关系强度满足预置条件的至少一个候选用户；

目标用户确定单元，用于根据所述采集到的预置维度上的特征信息，从所述候选用户中确定出与所述指定用户具有特定人际关系的至少一个目标用户；

关系保存单元，用于保存所述指定用户与所述至少一个目标用户之间的特定人际关系信息。

29.一种数据对象推荐装置，其特征在于，包括：

信息库提供单元，用于提供特定人际关系信息库，所述信息库中保存有与指定用户具有特定人际关系的至少一个目标用户的信息；

目标用户确定单元，用于在向指定用户客户端提供数据对象推荐信息时，根据所述用户关系信息库，确定所述与指定用户具有特定人际关系的至少一个目标用户；

信息推荐单元，用于为所述指定用户客户端提供与所述特定人际关系相关的数据对象推荐信息。

30.一种提供日历信息的装置，其特征在于，包括：

信息库提供单元，用于提供特定人际关系信息库，所述信息库中保存有与指定用户具有特定人际关系的至少一个目标用户的信息，以及在所述第一特定人际关系中，与所述目标用户相关的至少一个目标日期；

访问请求接收单元，用于接收指定用户客户端提交的访问日历信息的请求；

日历信息提供单元，用于利用所述特定人际关系信息库中保存的信息，提供与所述目标用户相关的目标日期信息。

31.一种数据对象集合信息处理装置，其特征在于，包括：

信息库提供单元，用于提供特定人际关系信息库，所述信息库中保存有与指定用户具有特定人际关系的至少一个目标用户的信息；

目标用户确定单元，用于根据所述信息库，确定所述与指定用户具有特定人际关系的至少一个目标用户；

判断单元，用于判断所述目标用户关联的待处理数据对象集合中是否存在符合预置条件的数据对象；

合并单元，用于如果存在，则将所述符合预置条件的数据对象合并到所述指定用户关联的待处理数据对象集合中，以便在所述指定用户客户端对合并后的集合中的各个待处理数据进行统一处理。

32.一种数据对象集合信息处理装置，其特征在于，包括：

信息库提供单元，用于提供特定人际关系信息库，所述信息库中通过特定人际关系关联的多个用户的信息，以及各用户在所述特定人际关系中相对于其他用户所具有的身份信息；

公用集合提供单元，用于提供待处理数据对象公用集合，并在接收到向所述公用集合中添加数据对象的请求时，记录添加所述数据对象的第一用户与数据对象之间的对应关系，所述第一用户为同一特定人际关系内的任一用户；

数据对象列表提供单元，用于在接收到第二用户客户端查看所述公用集合的请求时，提供所述公用集合中的数据对象列表，以及所述第一用户在所述特定人际关系中相对于所述第二用户的身份信息。