CN1939033B - 用于管理一组电信用户的存在数据的方法以及用于执行该方法的设备 - Google Patents

Abstract

各个通信用户的特性借助于存在服务器来收集并且可以由其他用户和应用询问。存在数据例如涉及用户的可达性。本发明的任务是存储一组用户的存在数据。通过为虚拟用户产生附加的存在信息，将虚拟的组好友存放在存在服务器中，其中所述虚拟用户不存在于网络中，而是汇总在该组中存在的用户的列表。本发明的优点是不必由发出询问的用户执行用户的各个上下文存在数据的链接，为此在其终端设备中可能需要附加的计算效率。此外，有利的是，用户不必对其组中的每一个单个组好友单独地进行询问。由此避免经由空中接口的不必要地多的数据通信、以及上下文信息的冗余链接。

Description

用于管理一组电信用户的存在数据的方法以及用于执行该方法的设备

技术领域

本发明涉及一种用于管理电信网内用户的所谓的存在信息或者上下文信息的方法以及一种用于执行该方法的设备。

背景技术

为了执行电信业务，如果用户的某些信息可供使用，则通常是有利的。这些信息除了包含用户的停留位置以外，还包含其可用性、所使用的终端设备的类型、通过确定的终端设备的可达性或者其停留位置。有利地，这些信息被集中存放在电信网内，以便可由极大不同的应用以及其他用户访问。

这个问题在标准化的过程中已经是已知的。因此存在关注结构、功能以及其他问题的不同标准。因此，对于因特网来说，应提及网络工作组IETF的RFC请求注释2778。相应地对于移动无线电网来说存在3GPP标准、即3GPP TS 23.141“Technical Specification GroupServices and System Aspects；Presence-Service；Architectureand Functional Description”((第6次发行)，2003年的6.3.0版)以及3GPP TS 22.141“Presence-Service；Stage 1”((第6次发行)，2003年3月的6.2.0版)。

借助存在服务器，所选择的通信用户的特性被收集并且能够由其他的用户和应用询问。在标准中已经描述了可能的存在数据的集合，但是该集合并不是封闭的。可以期望的是，利用继续行进的终端设备和应用还能够接收更多的存在数据。

存在数据(在这些标准中也被称为“存在体”(Presentity))的目的是将关于某些用户或者应用的可用性的信息传送给其他用户。为了实现这一点，可以设置进行监视的用户(所谓的“观察者(Watcher)”)，该用户通过定期询问用户的存在数据的状态或者在某一存在状态变化的时候获得消息来监视该用户的存在数据的状态。

这些存在信息的常见的应用在于一组用户的、关于其他的组成员的相应可达性状态的相互信息。为此，所谓的“好友列表”是已经已知的，该好友列表是不同用户的存在体的集合，订户对不同的用户感兴趣。通常，在用户自己处管理这个好友列表。在连接的建立开始时，用户向每一个好友发送订阅请求。之后当在其好友列表的用户之一处状态发生变化时，他每次都被通知。

这种方式的缺点在于，首先在大的好友列表情况下产生大量数据通信，也即每个用户一个订阅消息并且在每一次状态变化时一个信息消息。假定用户不是自动地被告知状态变化，那么他就要自己负责询问每一个好友的当前值。这对他来说意味着大的工作量以及额外的数据传输。因为他也必须对每一个询问进行分析，所以在好友列表较长的情况下询问的间隔将变长，由此信息的现实状态不再被保证。

在因特网草案Draft-Rosenberg-Sinmple-Buddy-List-Package-00.txt中描述了好友列表。IETF为了进行评价已经添加了该文件有半年时间、也即从2001年11月14日起。它没有成为RFC，因此在2002年5月已经到期(“期满”)。

在这个文件中建议了所谓的好友列表订阅服务器BLSS。该好友列表订阅服务器相当于好友列表自身的存在代理。这意味着，该好友列表订阅服务器能自己设法得到成员的好友列表。之后该好友列表订阅服务器接管与存在服务器的通信，在该存在服务器处收集关于好友列表的用户的所有信息。一旦所有的信息被收集，该好友列表订阅服务器就将这些信息共同地转发给用户。

发明内容

本发明的任务是给出一种如何使好友列表的被选择的通信用户的上下文数据和该组的上下文信息相链接的方法。此外，本发明的任务是给出一种用于执行该方法的设备。

该任务通过根据权利要求1的特征的方法以及根据权利要求6的特征的设备得以解决。

本发明的核心思想是，在存在服务器自身中存放所谓的虚拟的组好友。这意味着，为虚拟用户产生附加的存在信息，该虚拟用户不存在于网络中，而是汇总组中存在的用户的列表。根据每一个组用户的各个相应的用户存在数据来产生该存在信息。

本发明的优点是，用户的各个上下文存在数据的链接不必由进行询问的用户来执行，为此在其终端设备中可能需要附加的计算效率。此外有利的是，用户不必对其组中的每一个单个组好友单独地进行询问。由此避免经由空中接口的不必要地多的数据通信、以及上下文信息的冗余链接。

因此，基本思想在于，在所谓的组上下文中传输单个移动无线电用户的独特的用户上下文，所述组上下文反映用户的全体。

有利的扩展方案和改进方案在从属权利要求中给出。

在产生组存在数据时可以应用不同的规则。这里将示例性地列举一些规则。例如可设想的是，只有在该组的所有成员都已经设置了某个值的时候，参数才能采用该值。例如在位置信息的情况下可设想该特征，其中只有在该组的所有用户基本上都停留在同一个位置时，该组的位置信息才有意义。

在弱化的形式中，如果该组的预先确定的百分比具有一个值、例如50％，则该组的确定的存在值也可以被设置为该值。另一极端是，如果相应的组用户中的至少一个具有确定的值，则相应的组存在值就被设置为该存在数据值。

也可以设想的是，确定的组存在数据值恰好给出所有相应的用户存在数据值的平均值。

对存在数据的收集只有在这些存在值也能够被传播给网络的其它用户时才是有意义的。该方案已经在3GPP的标准中被详细描述了。然而可以由用户限制对某些数据的访问。因此，在本发明的另一实施例中，只可以对组成员本身释放对该组的上下文信息的访问，对每个其他用户或者应用来说，该访问被禁止。

组存在数据变化的信息的类型是通知。有利地，在组存在数据的值变化时，将此通知该组的所选择的用户。替代地，可以设想的是：通知不是该组的用户的第三人。

附图说明

下面将借助实施例来阐述本发明。在此：

图1示出本发明方法的示意图，

图2示出根据现有技术的对应于图1的示意图，

图3示出一个实施例，

图4示出根据具有增补的标准TS 23.141的存在业务的结构，

图5示出本发明装置。

具体实施方式

图1示出本发明的基本结构。在通信网络中，具有不同终端设备、例如移动无线电电话或者膝上型电脑的多个用户User1、User2、User3例如利用WLAN连接在网络中注册。这些用户中的每一个都拥有自己的在网络中的存在信息Netzinfo user1、user2、user3。该存在信息的主要组成部分是用户在该通信网络中的停留位置、即“位置”。在该情况下，用户1和用户3在柏林，而用户2目前停留在慕尼黑。

现在在第一步骤中根据3个单个用户的存在信息生成组1的共同的存在信息Kontext Gruppe 1。这借助使各个上下文和组上下文相链接的功能来实现。

在该情况下，用户具有共同性，即它们都在网络中“在线”。因此，用于构成组上下文的规则在这里可以是：如果该组的所有用户的状态都同样是“在线”，则将状态设置为“在线”。其他的规则可以适用于将组上下文分配给停留位置。该组上下文在结构上和用户上下文相同，也即基本上涉及“虚拟的”用户。

如果现在例如应该由该组的用户或者由需要用于提供业务的信息的应用询问该组上下文，那么该信息可以简单地从网络中通过询问组上下文而得知。

图2示出与目前构成现有技术的过程相同的过程。又存在每一个单个用户的存在信息。这些存在信息被集中地存放在网络中的存在服务器内。如果现在网络中的应用想要拥有组上下文，则该应用必须通过网络单独地询问每一个单个用户存在信息。于是必须在应用中实现存在信息的链接。

这导致很大的通信耗费以及应用的研发耗费，因为对上下文信息的分析必须在每一个应用中或者在每个用户处单独实现。此外，本发明处理方式的优点是，各个用户上下文信息被概况成组上下文信息可以在统一的规则下实现。

在第一实施例中，上下文管理器作为附加的功能被集成在驻留于网络中的存在管理器中。对于进行投票、也即以能够表决的方式产生信息的应用来说，前提是：表决所需数量的组成员“在线”并且准备好表决。一旦满足了这个前提，就向用户发送通知。

类似地，好友组的“情绪”上下文(也就是说所有好友情绪都很好并且是富有活动能力的)可以被传播给用于电影广告的应用，然后该应用向该组发送当前的电影预告片。

在图3中示出如何根据3个用户存在数据产生组上下文。再次具有图1和图2中的3个用户，这些用户已经分别产生了简档。用户A目前已设置了离开标志。如果现在规则是：在该组的所有用户实际上都是可达的前提下，上下文值“意愿”、也即“可达性”被置为“可用”、也即“可达”，那么在图3中所描述的情况下该值被置为“不可用”，因为用户A已在他的存在信息中录入值“请勿打扰”。但是该规则也可以是：一旦该组的多于50％的用户是可达的，该值就被置为“可用”。

在第二实施例中，从某一终端设备的角度看，组上下文也可以由上下文管理器产生，并被提供给所有的组成员。例如进行对位于与参考终端设备相同的移动无线电小区内的所有终端设备的位置信息的分析。根据密度和平均速度的确定来计算在该移动无线电小区中在所选择的高速公路段上的堵车危险。该结果然后被提供给所有的组成员。

在另一应用情况下，组成员是属于一个呼叫中心的人员。这里，现在由上下文管理器监控，该组的多少用户目前处于“在线”。如果被标出为“忙碌”的用户的份额超过确定的百分比、例如80％，则这个组上下文被通知，以便显示由此导致的呼叫中心的容量瓶颈。可以例如通过将其他用户添加到该组中来相应地对该通知作出反应。

另一有利的应用领域是所谓的“智能家庭”。在此情况下，组的用户不是人，而是物品、例如牛奶袋。通过监视这些物品的上下文信息、也即现有的袋数、失效日期、环境温度(例如太高，即冰箱效应)，上下文管理器可以进行分析。分析的目的是：当牛奶储备将消耗殆尽并且必须购买新的牛奶时，发送消息给冰箱的用户。

图4基本上示出如由标准3GPP TS 23.141预先给定的结构。添加了所谓的存在管理器，该存在管理器对被存放于存在服务器中的存在信息进行访问。左侧的框(存在供应商)表示源，存在服务器从所述源、也即从用户自己、从其它应用或者从网络得到存在服务器的存在信息。可以使用每个目前可设想的例如GSM、UMTS、WLAN等等的电信网络作为所基于的网络。监视者(观察者)负责将在存在服务器中所收集到的信息以适当的方式转发给该网络的用户或者应用。专业人员可从所述标准中得知更详细的应用。

图5现在仍然示出当存在管理器存在于网络中时该存在管理器的基本结构。由存在管理器确定用户上下文Kontext User1、User2。然后，借助例如最小值、最大值、平均值、确定的百分比等等的适当的规则Rules来确定所属的组上下文CALC。随后，所确定的组上下文被通知给存在服务器，该存在服务器于是在组上下文(KontextGruppel)中设置所计算的相应值。在存在服务器中该组上下文与每个任意的单个用户上下文完全一样地被处理。

Claims (4)

1.用于在电信网络(Kommunikationsnetz)中的存在服务器中管理存在数据(Presennce Info)的方法，其中

-至少两个电信用户(user1，user2，user3)构成一个组(Gruppe1)，并且

-属于所述组(Gruppe1)的每一个用户都具有自己的用户存在数据(Netzinfo user1，Netzinfo user2，...)，以及

-在存在数据库中，针对所述组的存在数据(Kontext Gruppe1)，存在代表所述组的虚拟用户的录入项，其中

-如果所有相应的用户存在数据(Netzinfo user1，Netzinfo user2，...)都具有代表所述组的虚拟用户的存在数据的值，或者如果

-至少预先确定的百分比的、属于所述组的相应的用户存在数据都具有代表所述组的虚拟用户的存在数据的值，或者如果

-相应的用户存在数据中的至少一个具有代表所述组的虚拟用户的存在数据的值，

则由与所述存在服务器分离的存在管理器根据所属的用户存在数据(Netzinfo user1，Netzinfo user2，...)按照预先确定的规则将所述组的存在数据确定和设置为该值并且由所述存在服务器相应地设置所述虚拟用户的录入项，或者

-按照所述规则将所述组的存在数据(Kontext Gruppe 1)设置为属于所述组的用户的、所有相应的用户存在数据的相应值的所计算的平均值。

2.如权利要求1所述的方法，其特征在于，所述组存在数据(Kontext Gruppe1)仅仅对于属于所述组(Gruppe1)的用户(user1，user2，user3)来说是可读的。

3.如上述权利要求之一所述的方法，其特征在于，在组存在数据值变化时，产生给

-所述组的至少一个用户或者

-所述组之外的另外的用户

的通知。

4.用于执行如权利要求1-3之一所述的方法的设备(KontextManager)，该设备具有：

-用于收集(get)属于所述组的用户的相应的用户存在数据(Kontext user1，Kontext user2，...)的装置，

-用于按照预先确定的规则(Rules)根据所收集的用户存在数据来计算(calc)组存在数据的所属值的装置，以及

-用于在组存在数据(Kontext Gruppe1)中设置(set)新确定的存在数据值的装置。

Images