CN101453472B - 关系信息的公开、获取方法及系统 - Google Patents

Abstract

本发明提供了一种提供关系信息的系统，包括：客户端，用于发送获取关系信息的请求，并根据获取的关系信息生成和输出关系视图；关系服务单元，用于接收客户端请求，从关系记录数据库检索出用户及其各级联系人的关系记录并返回给客户端，其中，所述关系记录至少包括用户标识、该用户的联系人标识、该用户与联系人的关系信息和关系记录是否公开的标记；关系记录数据库，存储有各个用户的联系人、用户与联系人之间的关系信息。使用本发明，用户可以在即时通信等系统中，共享自己的关系信息给其他用户，以及获取到间接的关系信息或关系路径。

Description

关系信息的公开、获取方法及系统 

本专利申请是2005年11月09日向中国专利局提出申请，申请号为200510115812.1，发明名称为“关系信息的公开、获取方法及系统”的国内申请的分案申请。 

技术领域

本发明涉及通信技术领域，特别是指关系信息的公开、获取方法及系统。 

背景技术

目前的各种即时通信系统(如MSN Messenger、QQ、ICQ)、邮件通信系统或其他通信系统中，存在很多系统预设的、或用户创建的组(Group)，用于对与用户存在直接关系的联系人进行分类。如MSN Messenger中默认有四个联系人分组：家人、朋友、同事、其他联系人。如下表1示出了sunqian@mail.com的联系人列表，当然表1中的用户标识/联系人标识不仅可以是电子邮箱地址，还可以是电话号码、唯一标识用户的号码(如QQ号码)或统一资源定位符URI等。 

用户标识	联系人标识	组名称/标识
			sunqian@mail.com	wenx@mail.cn	家人
sunqian@mail.com	maning@mail.com	同事
			sunqian@mail.com	yangzhao@mail.com	朋友

表1 

通常，组的名称如“家人”即可表示用户与联系人的关系。用户可以根据需要增加新的组，如增加同学组。还可以将一个组进一步设置小组，以进一步区别与联系人的关系，如朋友组分为好朋友，普通朋友两个组。在开放移动联盟(OMA)制定的标准中，单独设置了一个共享XDM服务器(SharedXDMS)用于存放用户的组信息，以供各种业务如PoC，Presence等业务使用。

目前一个用户的组，或称为与联系人的关系信息在现有各种存在组的业务系统中都是除该用户之外的其他用户无法获得的，同时系统也没有提供公开关系信息的机制。而用户可能希望获得其他用户的联系人信息和关系信息，也可能会希望将自己的联系人及与联系人的关系信息进行适当公开，以通过朋友的朋友(联系人的联系人)结识更多的朋友，拓展自己的关系网络。而另一方面，公开关系信息涉及用户隐私，用户还可能会希望有条件的控制关系信息的公开程度和公开范围等。但是，目前尚没有相关的技术来实现用户联系人信息及关系信息的可控制的公开、获取的技术。 

发明内容

有鉴于此，本发明的主要目的在于提供了关系信息的公开和获取方法及系统，使用户可以在通信系统中，共享自己的关系信息提供给其他用户，以及获取到间接的关系信息或关系路径。 

本发明提供的提供关系信息的系统，包括： 

客户端，用于发送获取关系信息的请求，并根据获取的关系信息生成和输出关系视图； 

关系服务单元，用于接收客户端请求，从关系记录数据库检索出用户及其各级联系人的关系记录并返回给客户端，其中，所述关系记录至少包括用户标识、该用户的联系人标识、该用户与联系人的关系信息和关系记录是否公开的标记； 

关系记录数据库，存储有各个用户的联系人、用户与联系人之间的关系信息。 

由上述系统可以看出，本发明使用户可获得其他用户的联系人信息和关系信息，以及将自己的联系人及与联系人的关系信息进行适当公开，实现通过朋友的朋友(联系人的联系人)结识更多的朋友，拓展自己的关系网络。并且，实现用户可以有条件的控制关系信息的公开程度和公开范围等。 

附图说明

图1为用户之间的关系示意图。 

图2为控制关系信息的公开流程图。 

图3为获得其他用户的联系人信息的流程图。 

图4为两层级的关系记录信息示意图。 

图5为用户获得某用户关系路径的流程图。 

图6为提供关系信息的系统示意图。 

图7为用户A的2级关系视图。 

图8为用户A与C3有直接关系的2级关系视图。 

图9为用户A的基本关系视图。 

图10为关系视图生成流程图。 

图11为树形图表示的关系视图。 

图12为包含孤岛节点的关系网络图。 

图13为两个线程搜索关系路径的示意图。 

图14为用户A到用户D的关系路径示意图。 

具体实施方式

本发明，在服务器上存储用户的关系记录，每条关系记录至少包括用户标识，联系人标识以及用户与联系人的关系信息。不难理解，用户之间可能存在如图1所示的用户之间的关系，其中关系箭头的终点为起点的联系人。 

图1表示了下面的关系：用户A的关系记录中的联系人标识包括用户B，用户B关系记录中的联系人标识包括用户C等。下面以该图为例对本发明进行说明。 

本发明首先提供了用户控制对自己关系记录进行公开的方法。预先，在服务器上存储用户的关系记录，所述每条关系记录至少包括用户标识，联系人标识以及用户与联系人的关系信息。参见图2示出的流程图，包括以下步骤： 

步骤201：用户向服务器发送将关系记录设置为公开的请求消息，该请求消息至少包括该用户的标识，联系人标识。本例中，设发起请求的用户是用户B，联系人标识为用户C的标识。当然联系人标识可以为多个，这样可以在一个请求消息中将用户与多个联系人的关系记录设置为公开。 

该请求消息中还可包括该用户B设定公开范围的参数，用来限定公开信息提供给哪些用户；以及设定公开程度的参数，用来限定提供哪些相关的关系信息(如关系信息、用户属性等)。公开范围参数还可以和公开程度参数建立对应关系，这样，对于符合不同公开范围参数的用户，可以获得不同的公开程度的信息。 

步骤202：服务器接收到所述请求消息后，根据该请求消息中的联系人用户C的标识，向联系人的客户端发送关系记录公开请求确认消息。 

此步骤的目的是因为关系隐私涉及到用户B和联系人用户C，因此通过该步骤去寻求联系人对公开关系记录的确认，可以加强对隐私信息的控制。另外，在客户端返的回确认消息后中还可包括该用户设定的公开范围参数和/或公开程度参数，由服务器保存，进一步对其隐私信息的公开进行控制。 

步骤203：联系人用户C同意公开，通过其客户端返回确认的响应消息，否则返回拒绝公开的响应消息。 

步骤204：服务器收到确认的响应消息后，将用户B与返回确认消息的联系人(用户C)标识对应的关系信息标记为公开；若收到拒绝公开的响应消息，则不进行公开的操作，将原因返回给用户B。 

同时，当请求消息中包括设定公开范围的参数、设定公开程度的参数时，服务器要保存这些参数作为公开的限定。 

不难理解的是，用户还可以向服务器发送将关系记录设置为不公开的请求消息，该请求消息至少包括发送该请求消息用户的用户标识，联系人标识；当服务器根据接收到的请求消息中的用户标识和联系人标识检索到所述用户标识和联系人标识之间的关系记录，并将该关系记录标记为不公开。并且，服务器向所述关系记录设置为不公开的请求消息中的联系人标识对应的客户端发送关系记录已设置为不公开的通知消息。 

下面再来说明用户如何获得其他用户的联系人及关系信息的步骤。同样的，服务器中存储有用户与联系人的关系记录，所述每条关系记录至少包括用户标识、联系人标识、还存储有用户与联系人的关系信息和公开参数信息。这里的公开参数信息即包括用户设置的与某联系人的关系记录是否公开的标记、公开范围参数和公开程度参数。公开参数可以是在用户控制对自己关系信息进行公开的步骤中设置的。网络中还保存有用户属性(如性别、年龄、职业)。 

以用户A获取用户B的联系人和关系信息为例，参见图3示出的流程图，获得其他用户的联系人及关系信息的步骤包括： 

步骤301：用户A向服务器发送获取用户B关系信息的请求消息，该请求消息包括要查询的目的用户标识(即用户B标识)。该请求还可包括获取关系信息的限定参数，限定参数可以包括用户属性信息(如性别、年龄、职业)、关系名称信息(如家人、朋友)、关系层级/数量、关系亲密级别、用户标识(如统一资源定位符URI，直接给出到指定用户标识的关系路径)等，多个限定参数可以同时存在。 

步骤302：服务器根据接收到的所述请求消息中的用户B的用户标识，从其存储的关系记录中检索获得用户B的满足公开参数信息的关系记录信息，获得用户B的标记为公开的联系人标识(如用户C标识)、及该联系人与用户B的关系信息。 

若步骤301所述请求中包括设定的关系信息限定参数，则对获得的关系记录信息进一步进行过滤，仅得到满足所述关系记录信息限定参数的所述关系记录信息。例如当关系信息限定参数包括用户属性“男”，则根据联系人属性，过滤掉记录性别为“女”的联系人。 

又如，当关系信息限定参数包括关系的层级时，将检索到的各个联系人分别作为要查询的目的用户标识，返回步骤302实现遍历以得到每个联系人的关系记录信息，获得下一层次的关系信息；之后再返回步骤302，直到获得限定的关系层级。如图4所示，当关系层级为2时，发起请求的用户A可以得到用户B的第一层级的关系记录信息：用户C1、C2标识及与用户B的关系信息，和第二层级的关系记录信息：用户D1、D2、D3标识及与各自 所属用户的关系信息。 

又如，当关系信息限定参数包括关系亲密级别时，会判断检索到的联系人与用户B的关系信息所对应的级别，将不符合关系亲密级别的联系人过滤掉。当然，关系信息对应的级别需要预先设定，例如，家人的亲密级别为1、朋友的亲密级别为2、同事的亲密级别为3。 

当同时存在几个限定参数时，则依照限定参数依次进行过滤，即取交集。 

步骤303：服务器确定用户A标识在所请求的用户B的公开范围参数内，并获得该公开范围参数对应的公开程度参数，然后将步骤获得的检索结果以所述公开程度参数进行过滤，将符合公开程度参数的关系记录信息作为检索结果。 

当然，确定用户A在所述公开范围内的步骤也可在步骤302检索关系记录信息之前进行，即对用户A进行鉴权。当用户A不在所请求的用户B的公开范围参数内时，直接拒绝用户A的请求。 

步骤304：服务器将步骤303后的关系记录信息的检索结果(包括用户B的联系人信息、用户B联系人与用户B的关系信息等)返回给用户A的客户端。 

步骤305：用户A的客户端保存获得的关系记录信息的检索结果，并根据检索结果生成并输出关系视图给用户A。当然，关系视图也可以由服务器生成后再输出给用户A客户端进行保存。 

由于用户的关系通常是比较稳定的，变化比较慢，如增加、删除联系人，改变与联系人的关系名称等等，因此保存在客户端可以有较少的访问网络的好处。 

另外，但在需要的情况下，客户端记录的关系记录/关系视图可以由客户端发起请求进行主动更新，或由服务器在关系变化时通知用户。下面对更 新客户端记录的信息的步骤进行简述： 

客户端主动更新关系视图(关系记录)的步骤：客户端在保存的关系记录/关系视图中选择一个直接或间接的联系人，将联系人的用户标识发送给服务器，服务器检索该用户标识的关系记录，并发送给客户端，客户端将收到的关系记录与保存的关系记录进行对比，将变化的关系记录更新，重新生成关系视图。 

服务器可以仅对第一关系层级的联系人的关系发生变化时进行通知，服务器通知更新关系视图(关系记录)的步骤：服务器获知一用户的关系记录发生变化后，获取该用户所属的用户标识，向所属用户标识发送关系记录变化的通知，客户端收到后，向服务器请求最新的关系记录，并以此更新本地保存的关系记录。 

另外，当采用了缓存机制时，例如服务器预先检索并缓存用户和各级联系人的关系记录信息；那么，步骤304中的查询关系记录信息的步骤可以通过查询缓存的信息来实现，仅在缓存中不存在要查询的信息时，再从服务器中查询。 

下面再来说明用户如何获得到某用户关系路径的步骤。关系路径指由不同联系人信息建立的从一用户到另一用户经历的所有用户的信息。同样的，服务器中存储有用户与联系人的关系记录，所述每条关系记录至少包括用户标识、联系人标识、还存储有用户与联系人的关系信息和公开参数信息。这里的公开参数信息即包括用户设置的与某联系人的关系记录是否公开的标记、公开范围参数和公开程度参数。公开参数可以是在用户控制对自己关系信息进行公开的步骤中设置的。网络中还保存有用户属性(如性别、年龄、职业)。 

参见图5示出的流程图，以用户A获得到用户C关系路径为例，对用户获得到某用户关系路径进行说明，包括以下步骤： 

步骤501：用户A通过客户端向服务器发送获取关系路径的请求消息， 所述请求消息包括、用户A标识、要查询的用户C标识； 

步骤502：服务器根据接收到的所述要查询的用户C标识，根据存储的标记为公开的各个用户的关系记录信息，以某种遍历的算法(如宽度优先搜索或/和深度优先搜索)检索用户A标识到要查询的用户C的关系路径信息。 

其中，可以仅在满足设定条件的关系记录的子集中查询关系路径。例如，设定仅在一定的用户关系(如家人和朋友)的关系记录的集合中搜索，或者满足一定亲密级别的关系记录的集合中查询关系路径，或在一定关系层级/数量内。这些预设条件可以是在步骤50 1中由用户A发送请求时一并发送给服务器的。凡是在设定条件内无法查询到关系路径，则服务器认为不存在这样的关系路径。 

另外，可以预先将具有直接或间接关系的用户设置一相同的关系网络标识，表示具有直接或间接存在关系；当服务器检索查询用户A到用户C的关系路径时，首先判断一下两个用户对应的关系网络标识是否相同，如果不同直接返回提示难以到达的消息即可。 

步骤503：将获得的关系路径信息返回给用户A的客户端。 

其中，对于步骤502也可以如下进行关系路径的获得： 

在服务器上启动两个线程单元，一个线程单元从起点(即用户A标识)出发遍历起点的各级联系人，并保存关系信息，另一个线程单元从目标(即用户C标识)出发，遍历目标的各级联系人，并保存关系信息； 

同时检测已经得到的起点和目标的各级联系人中是否有相同的，如果有则可到达，并根据存储的关系信息得到关系路径信息；如果没有，当宽度到达预先设定的层级时，停止搜索遍历，向客户端返回提示很难到达的消息。 

相应的，本发明还提供了一种提供关系信息的系统，参见图6示出的系统结构图，包括： 

客户端，用于发送获取关系信息的请求，并根据获取的关系信息生成和 输出关系视图。 

关系服务单元，用于接收客户端请求，从关系记录数据库或缓存服务单元检索出用户及其各级联系人的关系记录信息或/和关系路径信息，从用户属性数据库获取用户的属性信息，以及将获取到的关系记录和用户属性返回给客户端。 

关系记录数据库，存储有各个用户的联系人、用户与联系人之间的关系信息。 

查询服务单元，用于接收请求去检索用户属性数据库获得用户属性，或根据用户属性(如年龄、性别等)反查用户属性数据库获得对应的用户标识(查出的用户标识可能不唯一)。 

用户属性数据库，存储有各个用户的属性信息，包括用户标识、姓名、电话、性别、职业等，用于向查询服务单元和/或关系服务单元提供各级联系人的属性信息。 

缓存服务单元，用于缓存关系服务单元检索出的关系信息，由关系服务单元提供给客户端。 

活动服务单元，用于存储客户端创建的活动记录，所述的活动记录包括活动编号，活动名称，创建者，时间等字段。创建者可以设置活动记录的公开范围，以及加入活动的权限。并在接收到查看活动信息或加入活动的请求时向关系服务单元请求验证发送请求的用户与创建活动的用户之间的关系信息，验证符合预设的关系后才允许查看活动信息或加入活动。 

其中，关系服务单元还包括：第一单元，用于接收用户请求后将用户标识发送给第二单元；第二单元，用于检索关系记录并生成用户标识的基本关系信息，然后返回给第一单元。具体的，第一单元首先根据发送请求的用户(即根用户)的用户标识从第二单元获取用户的第1级联系人和关系信息，然后对第1级联系人逐一根据第1级联系人的用户标识向第二单元获取用户的第2级联系人和关系信息。如此逐级处理，直到满足预先设置的终止条件。 最后由第一单元将获取到的各级联系人和关系信息发送给客户端，客户端据此生成关系视图。 

其中，所述关系记录数据库可以与关系服务单元设置在一个服务器上，如设置在关系服务器或共享XDM服务器上。在实际的实现时，为了便于不同的业务共享关系记录信息，因此将关系记录数据库存放在与业务服务器独立的服务器上较好，如开放移动联盟OMA给出的共享XDM服务器。 

下面对本发明涉及到的一些技术再进一步的进行描述。 

首先对本发明提到的关系记录进行详述。其中，所述关系记录可以记录为以下的形式：如下表2示出了一个关系记录： 

用户标识	联系人标识	组标识	关系名称	是否公开
					sunqian@mail.com	wenx@mail.cn	家人	妻子	否
sunqian@mail.com	maning@mail.com	同事	主管	是
					sunqian@mail.com	yangzhao@mail.com	朋友	好朋友及同事	是

表2 

关系记录还使用扩展标记语言XML文件存储。以上述表格中的第一条关系记录为例，下面示出了XML存储的方式： 

<list name＝″家人″> 

   <display-name>家人</display-name> 

   <entry uri＝″wenx@mail.cn″> 

     <display-name>温馨</display-name> 

     <relationship-name>妻子</relationship-name> 

     <visible>否</visible> 

  </entry> 

  </list> 

如上所述，本发明中，增加了“关系名称”项，这是因为，背景技术中表1用组来表示用户与联系人的关系实现起来比较简单，不适合精确的表示关系，因为用户与每个联系人的关系可能都不相同，即使与属于同一组的联系人。如用户与同属家人组两个联系人，对用户的关系一个是父亲，一个是兄弟，如果都用组来区别这些精确的不同关系会导致很多组里只有一个联系 人，因此，本发明增加“关系名称”项来表示用户与联系人的精确关系，而“组”可表示粗略的关系。关系名称可以由用户通过业务客户端界面如即时消息客户端界面进行设置。而增加的“是否公开”项用来表示该联系人与用户标识的关系信息(联系人标识、组标识、关系名称)是否公开。 

另外，考虑到关系记录信息对用户来说是一种私人数据，涉及隐私，为了更加灵活的实现用户对自己和每个联系人的关系进行是否公开、对谁公开以及公开程度的控制，可以分别设定用户和联系人的关系记录、关系隐私公开设定文件。例如，关系记录可以为下述表3内容： 

用户标识	联系人标识	组标识	关系名称
				sunqian@mail.com	wenx@mail.cn	家人	妻子

表3 

若以XML格式表示，可记录为： 

<list name＝″家人″> 

   <display-name>家人</display-name> 

   <entry uri＝″wenx@mail.cn″> 

     <display-name>温馨</display-name> 

     <relationship-name>妻子</relationship-name> 

   </entry> 

   </list> 

而关系隐私公开设定文件用于设定用户的联系人及之间的关系是否进行公开、公开范围参数(限定提供给哪些人)、公开程度参数(限定提供哪些关系信息)，可以采用下面XML格式： 

用户的关系隐私设定文件包括一个<ruleset>元素，<ruleset>元素又包括多个<rule>元素，每个<rule>元素包括一个<conditions>元素，设定该规则(rule)是对哪些人的，即限定了公开范围；一个<actions>元素，设定处理方式，通常可以表示是否允许公开等；一个<transformations>元素，设定公开程度。如下XML数据表示用户sunqian@mail.com对另一个用户user@example.com设置公开自己与wenx@mail.cn的关系：<ruleset entity＝″sunqian@mail.com″>；要查询的目的用户标识 

  <rule id＝″1″> 

  <conditions><identity><identity＝″user@example.com″/><identity><conditions> 

  <actions><sub-handling>allow</sub-handling><actions> 

  <transformations> 

     <proyide-urilist> 

        <entry uri＝″wenx@mail.cn″/>；联系人标识 

           <provide-listname>true</provide-listname>；组名称公开 

           <proyide-relationshipname>true</provide-relationshipname>；关系名称公开 

           <provide-uri>true</provide-uri>；URI公开 

       </entry> 

   </provide-urilist> 

   <transformations> 

   <rule> 

<ruleset> 

其中统一资源定位符URI列表“provide-urilist”元素中可包含多个具体的URI入口；并可进一步用子元素的值限定对每个URI入口的关系信息的公开程度，即公开关系信息的哪些内容，如组名称公开“provide-listname”、联系人用户属性公开等子元素。 

而对于所述的用户属性，指用户注册时的信息，可以包括姓名，电话，性别，职业等信息，可单独存放在用户属性数据库上。下面示出了XML格式的用户属性文件： 

  <uprofile entity＝″sunqian@mail.com″> 

      <first-name>Qian</first-name> 

      <last-name>Sun</last-name> 

      <tel type＝″e.164″>+13760463639</tel> 

      <e-mail>mailto:sunqian@mail.com</e-mail> 

      <gendar>male</gendar> 

      <occupation>engineer</occupation> 

</uprofile> 

下面，再对多级关系层级的生成和关系视图的生成技术进行详细介绍。关系视图可以直观的表示用户与其他用户之间直接或间接的关系。 

由于对于一个用户的联系人sunqian@mail.com，还会有其联系人如 yangzhao@mail.com，而这个联系人也会有自己的联系人列表，如下表4所示yangzhao@mail.com的关系记录： 

用户标识	联系人标识	组标识	关系名称	是否公开
					yangzhao@mail.com	sunqian@mail.com	朋友	好朋友	是
yangzhao@mail.com	mary@hotmail.com	朋友	邻居	是
					yangzhao@mail.com	tom@hotmail.com	同学	大学同学	否

表4 

同时参考表2和表4，可见存在这样的路径： 

本发明中，将这样的路径定义为关系路径，可以看出，一条关系路径至少有两个节点，即有一个起点和一个终点，起点和终点之间有零或多个节点，两个相邻的节点之间用关系连接，关系是有向，并且关系对起点应当是公开可见的。如果一个用户A与一个用户B之间存在一条以用户A为起点的关系路径，则称用户A可到达用户B，否则用户A不可到达用户B。并将关系路径包含的除起点之外的节点数量(或关系的数量)称为关系路径的长度。若用户A可到达用户B的关系路径有多条，将其中包含节点最少即关系路径的长度最小的关系路径称为用户A到达用户B的最短关系路径。从表2、4的关系记录中可见，用户sunqian@mail.com可到达mary@hotmial.com，而用户sunqian@mail.com不可到达tom@hotmial.com(因为tom@hotmial.com未公开，不可见)。并且，sunqian@mail.com到达mary@hotmial.com的关系路径的长度为2。 

由于关系是有向的，两个互为联系人的用户所设置的关系名称可以不同，如用户yangzhao@mail.com对联系人sunqian@mail.com设置的关系名称为“好朋友”时，则由表2、4可获得关系路径如下所示： 

所述的关系视图也可以看作是要检索用户在一定条件下的所有的关系 路径的图形化表示。 

在前面用户A获取他的联系人即用户B所公开的关系信息的方法的步骤302中提到，服务器根据要检索的用户B标识，检索获得该用户标识的关系记录信息(联系人、所述联系人与所述用户的关系)后，还可以将检索到的联系人依次分别作为要检索的用户，返回该步骤，实现遍历每个联系人的关系记录，进一步的获得下一层次的关系信息。循环直到满足预先设置的终止条件。不难理解，在这个步骤中，便可以根据一次次的循环生成关系视图。 

下面参见图7示出的用户A的2级关系视图来进一步说明。一般的层级为n的关系视图包含了用户的第1级至第n级联系人。如图7所示，用户A有2个联系人B1，B2，这种直接的联系人可以称为A的第一级联系人，用户A设置的关系名称分别为关系1和关系2；B1又有2个联系人C1、C2，B2有1个联系人C3，关系名称分别为关系3、4、5，其中关系3、4、5对用户A来说应当是公开的，即对用户A来说应当是可见的，对用户A不公开可见的关系在生成用户A的关系视图时不予考虑，C1、C2、C3这种间接的联系人可以称为A的第二级联系人，以此类推C1、C2、C3的联系人，不包括第一级联系人和第二级联系人，可以称为第三级联系人等等。又如当还存在B1与其联系人C4的关系7，但关系7设置为不公开时，导致C4不是到B1的关系路径，则所得到的关系视图仍为图7，即用户A的关系视图中不会出现B1与C4的关系路径。另外，用户A和用户C3之间也可能存在如图8示出的有直接关系6的关系视图。 

其中，将一个用户与自己的直接联系人形成的1级关系视图也称为基本关系视图，如图9示出了用户A的基本关系视图。 

总结起来，可参见图10示出的生成关系视图的流程图，关系视图的生成包括以下步骤： 

步骤1001：检索出所要检索的用户(即根用户A)的关系记录，从该关系记录得到根用户的联系人称为第1级联系人(如B1、B2)，生成用户 的基本关系视图，并在内存中记录第1级联系人列表；此时关系视图的层级为1。 

步骤1002：针对联系人列表中的用户A的联系人，检索各个联系人的关系记录，并将这些关系记录中获得针对用户A的下一级的联系人列表(如C1、C2、C3)，存储在内存中。如果联系人已经存在于前级联系人列表中，则不对该联系人进行记录保存(这样可以避免重复循环)。并生成对根用户A公开的当前的关系视图。 

步骤1003：返回步骤1002，直到满足预先设置的生成关系视图的终止条件。生成关系视图的终止条件如预先设置的关系视图的层级，找到满足预设条件的联系人等。 

其中，呈现给用户的可视化的关系视图，可以是用点或方块等图元表示用户或联系人，用直线或带箭头的线表示用户以及联系人之间的关系，以及文本框在相应位置进行注释说明，如在表示用户或联系人的点旁边标明用户或联系人的姓名、性别等用户属性等，在表示关系的直线旁标明关系名称等。或者关系视图也可以用图11示出的树形图表示。 

以上可见，关系视图的节点数量是随视图的层数级数增长的，信息量太大对用户来说反而用处不大，所以应该减少信息量，可以通过在生成关系视图时如步骤302所述，输入限制参数条件，只处理满足条件的节点和关系。如设置节点对应联系人用户的性别、年龄、职业等条件，设置关系为家人。这样关系视图就不会随着层级的增加而迅速发散，如果平均每个用户有10个联系人，则一个用户的第二层联系人的数量就有10²即100个，第三层就有10³即1000个；如果限定一下性别，一般就可以减少一半数量，再限定一下职业就可以减少更多。 

关系视图可由服务器或客户端生成。较佳的，关系视图的生成由客户端根据关系信息自行生成关系视图，这样网络传输信息量较小，而且客户端可以更灵活的根据用户的需要和设置生成关系视图，也可以减轻服务器的负 担。根据用户和各级联系人的关系记录即可生成关系视图，因此客户端只要从服务器获取用户和各级联系人的关系记录即可。另外还可以同时获取各级联系人的用户属性等信息，当然各级联系人的用户属性要对根用户是公开的。上述的关系视图、关系记录以及联系人的用户属性等都属于关系信息。 

下面，再对关系路径的获取技术进行详细介绍。 

实际上，服务器上存储的关系记录由于用户及其联系人的关联关系形成了图的数据结构，即关系网络图，因此可以应用图的遍历算法获得关系路径以及关系视图信息等，如宽度(广度)优先算法，深度优先算法等。而其中宽度优先算法更适合，因为一般用户并不希望获得较长的关系路径，或层级较大的关系视图。当服务器发现目标用户不是起点用户的第n级联系人，就可以停止遍历搜索了，n可由起点用户设定，如设为3。 

宽度(广度)优先算法(Breadth-First Search，BFS)是：先搜索完一个起点所有的第1级联系人，然后再继续搜索下一级联系人，直到底层(或设定的层次)为止。该算法保证了对浅层级的首先处理，当遇到一个无穷尽或很深的深层分支时，不会导致陷进其中出现出不来的情况发生。宽度优先搜索以一种系统的方式搜索，从而发现起点所能到达的所有节点，并计算起点到所有这些节点的长度(最少边数)，该算法同时能生成一棵根为起点且包括所有其可达节点的宽度优先树。对从起点可达的任意目标节点v，宽度优先树中从起点到目标v的路径对应于图中从起点到目标v的最短路径，即包含最小边数的路径。该算法对有向图和无向图都适用。 

深度优先搜索(Depth-First Search，DFS)是另一种搜索方法。从起点v出发，DFS按如下过程进行：首先将v标记为已到达节点，然后选择一个与v邻接的尚未到达的节点u，如果这样的u不存在，搜索中止。假设这样的u存在，那么从u又开始一个新的DFS。当从u开始的搜索结束时，再选择另外一个与v邻接的尚未到达的节点，如果这样的节点不存在，那么搜索终 止。而如果存在这样的节点，又从这个节点开始DFS，如此循环下去。 

一组关系记录的集合对应的关系网络图中可能会存在孤岛节点，如图12示出的关系路径图中的E1，即是一个孤岛节点，与任何其他节点都没有连接关系。例如，一个新注册的用户，还没有增加任何联系人，即还没有关系记录，但是存在用户属性数据时就是一个孤岛节点。这样，在查询关系路径时，首先要检查一下发送请求的用户，以及指定要到达的用户是否为孤岛节点，即是否存在关系记录，如果有任何一个不存在相应的关系记录则直接向客户端返回提示不可到达的消息即可。 

如步骤502所述，用户在不希望系统在所保存的关系记录的全集中查询关系路径，而是希望在满足预设条件的关系记录的子集中查询关系路径时，可以设定查询的条件，如限定关系名称(如家人或/和朋友)，用户属性(如性别)等，这样得到的关系路径可以称为有条件的关系路径。另外一种有用的限定是避免关系路径中关系的衰减，关系按用户之间的亲密程度笼统的可以分为强连接和弱连接，可在关系记录中增加一个字段表示亲密级别，用量化的值表示，如数值3表示高亲密度级别(如与家人之间的关系)，2表示较高(如与同学、同事之间的关系)，1表示普通(如与网友之间的关系)，3和2表示的关系可以属于强连接，1表示的关系属于弱连接，通常强连接对用户更有用，而在一个关系路径中强连接的关系比较多说明关系衰减的比较慢，起点和终点的用户更可能建立信任度较高的关系，因此用户可能会希望建立一个具有较多强连接关系的路径，而不是简单的最短路径。(甚至还可用负值表示不受欢迎的负面关系，如黑名单，可用-1表示，当然本发明中查询关系路径和关系视图信息都不必考虑负面关系记录)。这样可以在查询关系路径的预设条件中限定亲密级别的下限，如指定为2，则服务器只在满足亲密级别不低于2的关系记录的集合中查询关系路径。同样的可以在生成关系视图时，通过指定亲密级别限定参数，生成满足亲密级别条件的关系视 图。另外还可以在生成关系视图中，用不同的线型或颜色表示不同亲密程度的关系。 

另外，一组关系记录的集合对应的关系网络图中也可能会存在多个相互独立的关系子网，即两个子网之间没有任何连接关系，如图1 2中用户A与用户F1所在的两个子网，分别位于两个子网中的任何两个节点都互相不能到达对方。特别的如果对关系记录用预设条件进行了限定，则满足预设条件的关系记录集合对应的关系网络图中很可能会存在相互独立的子网和孤岛节点。为了能尽早发现不能达到指定用户的情况，避免服务器做徒劳无益的遍历搜索浪费系统资源，本发明在步骤502中还提出了可采用下述方法： 

在用户属性中增加一个关系网络标识字段，表示该用户所属的关系子网；新增加注册的用户为其分配一个新的关系网络标识。 

当在服务器上为用户增加一条新的关系记录时，如果其中的联系人标识对应的关系网络标识与用户对应的关系网络标识不同，则将用户对应的关系网络标识修改为联系人标识对应的关系网络标识(或者反之亦可)，然后将用户其他各级联系人对应的关系网络标识全部修改为与上述同样的关系网络标识。这个步骤实际上是在两个独立的关系子网中有两个节点建立关系时进行合并，另外以上合并的处理可以在服务器空闲时进行，而不必在增加一条新的关系记录时实时处理。如果其中的联系人标识对应的关系网络标识与用户对应的关系网络标识相同则不用进行处理。 

这样，当服务器检索查询一个用户到达另一个用户的关系路径时，首先判断一下两个用户对应的关系网络标识是否相同，如果不同直接返回提示不可到达的消息即可。 

本发明还提出在服务器上启动两个线程单元加快关系路径搜索的方法，一个线程单元从起点出发遍历起点的各级联系人，并保存关系信息，另一个线程单元从目标(如果存在关系路径就是终点)出发，遍历目标的各级联系 人，并保存关系信息，其中的遍历方法采用宽度(或广度)优先方法(BFS)；同时检测已经得到的起点和目标的各级联系人中是否有相同的，如果有则可到达，并根据存储的关系信息得到关系路径信息。如果没有，当宽度到达预先设定的层级时，停止搜索遍历，向客户端返回提示很难到达的消息。由于路径跨过多个节点时，该关系路径对用户的意义也就不大了，可以将两个线程单元停止搜索遍历的预先设定的层级条件设置为层级为2。 

以图13示出的关系网络图进行说明，该图中，两个线程单元分别得到了用户A和用户D的第1级和第2级联系人，如果在用户A和用户D的各级联系人中没有任何两个相同的，则用户A和用户D之间的关系路径至少为5，这是因为用户A第2级联系人不可能与用户D的第1级联系人有关系，反之用户D第2级联系人也不可能与用户A的第1级联系人有关系，否则用户A和用户D的各级联系人中就存在两个相同的了，因此只可能用户A第2级联系人与用户D的第2级联系人有关系，如假定F2与C4存在关系，这时用户A到用户D的关系路径则为图14所示。 

实际上，关系路径的长度为5已经是比较长的关系路径了，该路径对用户的实际意义不大了，因此，在实际设置时，可以认为用户A很难到达用户D。 

上述设置双线程从起点和目标同时进行遍历的方法实际上假定了系统中两个用户之间的关系是对称的，即存在互相对称的两条关系记录；或者将两个用户之间只要存在一个方向的关系即认为是有关系的。而如表2和表4所示，实际生活中互为联系人的两个用户，存储的关系记录可能是单向的，即一个用户把另一个用户加为自己的联系人，但另一个用户并没有这样做，这样两个用户之间的关系记录只有1条，而不是通常互相对称的2条。另外即使两个用户有互相对称的2条关系记录，也可以分别设置不同的关系名称(如一个为好友，另一个设置为同事)，亲密程度以及不同的公开程度和公开范围等。因此，关系路径对应的应该是有向关系网络图。这一点在此进行一下说明。 

上述的各种遍历方法中，多数都是单向进行搜索遍历，如从起点(或根用户)出发，逐级遍历各级联系人，而没有反向进行搜索，即检索某用户是哪些用户的联系人，这样可以获取更全面完整的关系，例如可以获得双向的关系信息，而不只是单向的关系信息，如表2和表4的例子，sunqian@mail.com可以得知yangzhao@mail.com设置的对自己的关系名称是“好朋友”。但是如果同时进行反向搜索则处理效率太低，而且通常情况下关系都是对称存在的，所以一般就不用进行反向搜索了。可以认为当两个节点只要存在有一个方向的关系时，即认为两个节点之间是有关系的，其中任一节点可以到达对方节点。 

下面再详细介绍一下活动服务单元，用于存储客户端创建的活动记录，所述的活动记录包括活动编号，活动名称，创建者，时间等字段。创建者可以设置活动记录的公开范围，以及加入活动的权限。如公开范围可以设定对所有用户都公开，而其他用户加入活动需要经创建者的确认。其他用户客户端向活动服务单元发送加入活动的请求消息，该消息包括活动编号，活动服务单元向活动记录的创建者发送确认消息，在收到确认消息后，将其加入到该活动的参与者列表记录中。 

进一步用户可以设置允许自己的第1级联系人和第2级联系人参与活动，则活动服务单元在其他用户请求加入时，向关系服务单元请求验证是否为第1级联系人或第2级联系人(也可以直接从关系记录数据服务器中检索关系记录进行验证)，如果是则允许加入，否则拒绝加入。 

另外一个用户还可以向活动服务单元发送请求，获取另一个用户参与的活动记录，请求中包括另一个用户的用户标识。活动服务单元检索活动的参与人列表，将参与人列表中包括指定用户标识的活动记录返回。 

下面再对本发明的缓存机制进行介绍。通过对要访问或常访问的数据进 行缓存，而不是在需要时才去检索获取数据信息，可以大大提高系统处理效率。本发明设置了一个缓存服务单元，来缓存用户的关系信息，这里所说的关系信息不是指可视化的关系视图，而是建立可视化的关系视图所需要的关系信息。 

由上面的说明可知，关系视图实际上对应着以指定用户为起点的宽度优先树，宽度优先树中存储着起点用户以及各级联系人之间的关系信息，另外还可以包括节点的用户属性信息。因此只要在缓存服务单元中缓存用户的宽度优先树即可，宽度优先树对应关系视图的层级最好设置为2，因为层级为1没有必要缓存，而层级为3或更大会导致缓存的信息数据量极大，而使用这些数据的可能性又不是太大。除了缓存关系信息外，还可以缓存各级联系人的用户属性信息。 

缓存服务单元所缓存用户的关系信息来源可以由缓存服务单元主动获取，即向关系记录数据服务器获取用户的宽度优先树，将包含用户各级联系人信息的宽度优先树信息存储。另外也可以在用户客户端获取关系视图或关系路径时，关系服务单元在将检索到的关系信息返回给客户端的同时将其保存到缓存服务单元上。 

缓存机制特别适用于设置了关系隐私设定文件、用户属性隐私设定文件时的情况。若没有缓存机制，每次获取一个用户的关系记录和用户属性时，都要检查匹配上述的隐私设定文件，对于用户请求实时生成宽度优先树，处理速度会很慢。 

而当一个用户请求获取到其他用户的关系路径时，如果已经缓存了该用户的关系信息，则只需要检查指定的其他用户是否在已经缓存的各级联系人中，如第1级联系人和第2级联系人，如果没有则检查指定的其他用户已经缓存的各级联系人中是否有该用户，如果没有，则再检查该用户和指定用户的各级联系人是否有相同的，如果没有，则返回用户很难到达指定用户的提示。以上各检查步骤中，如果有，则已发现了该用户到指定的其他用户的关系路径，将相应的关系信息返回给用户客户端即可。可见，通过缓存关系信 息，只要进行一些简单的检查判断即可获得关系路径信息，大大提高了系统效率，以及缩短了系统的响应时间。 

其中，可以只对系统的部分用户(如比较活跃的用户，对使用共享关系信息功能付费的用户)的关系信息进行缓存处理，而不是对系统中的所有用户。并且，对于缓存信息的存储和更新，可以在系统比较空闲的时间，如凌晨，进行存储处理或更新，并且，由于关系信息通常比较稳定，可以定期如每天，或每周更新一下缓存的关系信息。 

根据上述缓存机制，用户客户端在向关系服务单元获取关系信息或关系路径时，关系服务单元首先到缓存服务单元检查是否存在该用户(获取关系路径时还包括指定的目标用户)缓存的关系信息，如果有则基于已经缓存的关系信息进行处理。 

如果已经缓存的关系信息不能满足用户的请求，如用户请求获取限定条件(如职业)的3级联系人的关系信息，而只缓存有2级联系人的关系信息，则关系服务单元可以在缓存服务单元上存储的2级联系人的基础上进行遍历搜索，获取3相应3级联系人的关系信息。同时关系服务单元将获取的进一步的关系信息即3级联系人的关系信息也可以缓存到缓存服务单元上，以备将来使用。 

缓存的宽度优先树可以用XML格式表示，下面示出了一个缓存的宽度优先树： 

<BFS-Tree entity＝″sunqian@mail.com″> 

  <entry uri＝″wenx@mail.cn″level＝1> 

        <display-name>温馨</display-name> 

        <relationship-name>妻子</relationship-name> 

  </entry> 

  <entry uri＝″yangzhao@mail.com″level＝1> 

        <display-name>招扬</display-name> 

        <relationship-name>好朋友及同事</relationship-name> 

  </entry> 

  <entry uri＝″mary@hotmail.com″level＝2> 

         <parent>yangzhao@mail.com</parent> 

         <display-name>玛丽</display-name> 

          <relationship-name>邻居</relationship-name> 

   </entry> 

</BFS-Tree> 

即在XML文件中先将第1级联系人的信息列出，再对第2级联系人的信息逐一列出，并标记每个第2级联系人的父级联系人即对应的第1级联系人，如此类推。 

以上对本发明进行了详细的描述，由上述方法可以看出，本发明使用户可以共享关系信息，获取到间接的关系信息。另外也可以控制关系信息的公开。 

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

Claims (5)

1.一种提供关系信息的系统，包括：

客户端，用于发送获取关系信息的请求，并根据获取的关系信息生成和输出关系视图；

关系服务单元，用于接收客户端请求，从关系记录数据库检索出用户及其各级联系人的关系记录并返回给客户端，其中，所述关系记录至少包括用户标识、该用户的联系人标识、该用户与联系人的关系信息和关系记录是否公开的标记；

关系记录数据库，存储有各个用户的联系人、用户与联系人之间的关系信息。

2.根据权利要求1所述的系统，其特征在于，该系统进一步包括：

查询服务单元，用于接收客户端和/或关系服务单元的请求去检索用户属性数据库获得用户属性，或根据用户属性反查用户属性数据库获得对应的用户标识；

用户属性数据库，存储有各个用户的属性信息，向查询服务单元和/或关系服务单元提供各级联系人的属性信息。

3.根据权利要求1所述的系统，其特征在于，该系统进一步包括：

缓存服务单元，用于缓存关系服务单元检索出的关系信息，并由关系服务单元提供给客户端。

4.根据权利要求1所述的系统，其特征在于，该系统进一步包括：

活动服务单元，用于存储客户端创建的活动记录，并在接收到查看活动信息或加入活动的请求时向关系服务单元请求验证发送请求的用户与创建活动的用户之间的关系信息，验证符合预设的关系后才允许查看活动信息或加入活动。

5.根据权利要求1所述的系统，其特征在于，该系统中的所述关系服务单元包括：

第一单元，用于将发送请求的用户标识发送给第二单元，以及将第二单元返回的基本关系信息进行缓存，并根据所述基本关系信息中包含的各级联系人的用户标识继续上述步骤，从第二单元获取各级联系人的基本关系信息，最终组合各级联系人的基本关系信息后返回给客户端；

第二单元，用于根据第一单元发送的用户标识检索关系记录并生成该用户标识的基本关系信息，返回给第一单元。

Images