融合的信息系统.pdf

本发明涉及融合的信息系统。一种通知系统，用于通过网络利用至少两个不同协议从多个源向用户设备(UE)提供通知，该系统包括通知代理，其被布置为从所述多个通知源接收打算送给该用户的通知，该通知代理包括用于根据个体源的协议利用多个协议接收通知并且用于利用单个协议将通知传送给UE的装置，并且因此将通知的核心处理移到UE之外。

1、  一种通知系统，用于通过网络利用至少两个不同的协议从多个源向用户设备(UE)提供通知，该系统包括通知代理，其被布置为从所述多个通知源接收打算送给该用户的通知，该通知代理包括用于根据个体源的协议利用多个协议接收通知并且用于利用公共协议将通知提供给该UE的装置。

2、  根据权利要求1的通知系统，其中除了基本通知数据之外，该通知代理将另外的信息与每个通知一起提供给UE。

3、  根据权利要求2的通知系统，其中提供给UE的信息包括一个或者多个通知、动作、元数据、功能({NAMF}数据)。

4、  根据权利要求2的通知系统，其中所述数据包括表示用户响应于该通知可能希望选择的一个或者多个动作的数据。

5、  根据权利要求4的通知系统，其中该数据包括表示该通知的定位和/或显示的数据。

6、  根据权利要求1的通知系统，包括用于允许通过该公共协议从UE向通知代理传送答复并且如果合适的话，利用其单独的协议，将该答复从该通知代理传送到原始源的装置。

7、  根据权利要求1的通知系统，其中从通知代理提供给UE的数据的格式是利用公共的外观和感觉，而不管来自原始代理的通知的协议以及外观和感觉来显示的格式。

8、  根据权利要求1的通知系统，包括可插式逻辑元件。

9、  根据权利要求1的通知系统，其中根据条件和/状态来适配通知呈现和/或定时。

10、  根据权利要求1的通知系统，其中通知处理在通知代理内部完成和/或通过“可插入”到通知代理中的处理逻辑完成。

11、  一种通知代理，包括用于从每个都使用特定协议的多个源接收通知，并且用于使用公共协议将通知提供给UE的装置。

12、  根据权利要求11的通知代理，其中通知代理提供{NAMF}数据给UE。

13、  一种用于通过网络从具有不同本地协议的多个代理向用户设备传送通知的方法，包括提供适于从具有它们的本地协议的该多个代理接收通知并且利用单个协议将这些通知转发给UE的通知代理。

14、  根据权利要求13的方法，其中通知代理将另外的数据和该通知一起发送给UE。

15、  根据权利要求14的方法，其中所述另外的数据包括{NAMF}数据中的一个或者多个。

16、  根据权利要求15的方法，其中从通知代理提供给UE的数据的格式是利用公共外观和感觉，而不管来自原始代理的通知的协议以及外观和感觉来显示的格式。

17、  根据权利要求13的方法，其中该通知被UE接收并且与一系列可选择动作一起显示给该UE的用户，用户能够选择所述可选择动作并且利用所述单个协议答复通知代理，该通知代理利用它们的本地协议与该多个代理进行通信以获得另外的数据或者提供如由用户选择所确定的响应。

融合的信息系统
技术领域
本发明涉及融合的信息系统。更具体地，本发明涉及一种系统，其中用户设备(UE)被用于利用许多不同的协议传送并且接收各种类型的数据。
背景技术
IPTV(互联网协议电视)的用户可能希望使用许多不同的通信和信息技术。例如，SMS、MMS、IMS(IP多媒体子系统)、IMS-IM、VOIP呼叫、RSS、电子邮件、日历功能、例如MSN或者Google Talk的即时消息收发(messaging)服务、互联网通知以及许多其他类型的服务。这些通常都涉及不同的协议。运营商越来越感兴趣的是为IPTV用户提供用于按照上述的一些或者所有通知源发出的通知来行动的功能性。也就是说，当利用特定的协议向用户通告请求或者传输时，他们接收到通知并且在该UE提供使得用户能够选择如何对其进行处理的功能性。这些应用通常被称为“融合服务”并且这些都是对传统的IPTV(例如广播TV、内容点播或者视频点播VOD)的增值服务。
类似地，用户理想地更愿意具有适合于他们的生活方式的通信体验和多媒体服务。例如，用户可能希望在TV屏幕上接收到关于来自“好友列表”中的个人的高优先级电子邮件、SMS信息或者呼叫的通知并且做出适当的响应动作。
给UE提供这样的融合服务的现有方法可以利用从通知源到UE的网关并且需要在UE处提供单独的通知客户端，该通知客户端包括对每种类型的通信(SMS、电子邮件、VOIP、日历功能性等等)所特有的通知处理逻辑。例如，为了将IMSVOIP(会话启动协议)呼叫递送给IP子系统，使用网关将IMS VOIP通知递送给IPTVUE。该网关可以利用SIP将呼叫通知递送给IPTVUE，并且UE上的内置客户端提供响应动作。典型地，可能的选项可以包括：重定向到语音邮件，请求更多的关于呼叫方的信息、拒绝、应答或者其他。
另一个例子是电子邮件通知。通过诸如POP3、IMAP、SMTP等电子邮件协议将进来的电子邮件的通知直接或者经由网关递送给UE用户，并且在UE上的不同的内置客户端提供响应动作。典型地，这些动作可能是答复，读出正文，忽略，或其它。根据该响应，该客户端然后将利用POP3、IMAP等重新获得电子邮件的文本。
该现有办法的主要问题是其需要包括用于每一个通知源的特殊协议和通知处理逻辑的专门的UE客户端。该客户端必须在UE自身上提供。这产生了以下限制。
需要新的UE客户端来支持新的通知源，例如电子邮件、SMS，这在中等规模到更高规模的配置中是不经济的，
UE上需要新的通知处理逻辑来支持新的通知源
UE上的附加处理逻辑需要额外的处理功率和硬件需求，增加了成本，
多个通知客户端和其他应用之间的仲裁也增加了成本，以及
当图形用户接口(GUI)被用户化的时候，需要对每个客户端进行用户化，再次增加了成本。
此外，难以给现有的UE增加新的服务。
这种通知方法在ES 20239 10-3“Open Service Access”(OSA)“parlayX-webservices Part3：Call Notification”中被标准化。其中，客户端应用必须为具体的通知源进行登记并且实施通知处理逻辑。
发明内容
本发明的出现试图提供一种用于在UE装置上实施来自多个通知源的通知和响应动作的改进方法，并且试图提供一种实现新的通知源和类型的简单添加的系统。
根据本发明，提供了一种通知系统，用于通过网络利用至少两个不同协议从多个源向用户设备提供通知，该系统包括通知代理，其被布置为从所述多个通知源接收打算送给该用户的通知，该通知代理包括用于根据个体(individual)源的协议来利用多个协议接收通知并且用于利用公共协议将通知提供给UE的装置。
该通知代理优选地将另外的数据与该通知一起打包，所述数据表示一个或者多个参数。该参数可以仅仅有元数据，响应动作以及允许的功能中的一个或者多个，或者称为“{通知、动作、元数据、功能}”({NAMF})包。
该{NAMF}可以单独地、一起或者以其他方式从通知代理传递到客户端用户设备(UE)。任选地，它们可以通过IPTVAS传送。
该系统进一步可以包括用于初始处理的可插式处理逻辑。
在又一方面，本发明进一步提供了一种用于通过网络从具有不同本地协议的多个代理向用户设备传送通知的方法，该方法包括提供适于从该多个代理利用它们的本地协议接收通知并且利用单个协议将这些通知转发给UE的通知代理。
在UE处的通知代理可以被布置为向用户指示已经接收到通知，并且，如果合适的话，给用户呈现可能的动作范围使得该用户可以选择动作。如果合适的话，该用户然后可以将选择的动作传回到通知动作代理以便随后处理。
本发明进一步提供了一种通知代理，其包括用于从每一个都使用特定协议的多个源接收通知，并且用于利用公共协议给UE提供通知的装置。
本发明进一步提供一种通知系统或者代理，其包括在此公开的和/或者要求保护的一个或者多个新颖特征或者这些特征的组合。
附图说明
下面将参考附图，仅作为示例来描述本发明的实施例，其中：
附图1示出了通知系统；
附图2示出了数据流；
附图3示出了数据包；
附图4示出了在用户设备(UE)上的屏幕显示；
附图5示出了另一个屏幕显示；和
附图6示出了第一屏幕显示。
具体实施方式
现在参考附图1，示出了一般化的系统，该系统使得用户设备1能够接收来自各个源的通知。在这种情况下，该UE1是IPTV设备，其包括连接到显示器3的机顶盒2，不过该STB当然也可以与该显示器集成在一起。可替代地，该UE可以是任何其他设备，例如移动电话、PDA或者手持终端或者任何其他设备。可提供可以指示特定用户在任何时间是正在使用他的移动设备还是机顶盒亦或其他设备从而使得通信能够被寻址到相关设备的装置(未构成本发明的部分)。
这通过任何适合的通信信道，例如封闭式IP网络、开放式因特网，例如使用GPRS、UMTS的无线信道或其它无线或固定线路信道或通过这些的组合或者任何其他装置，连接到在网络上的任何合适位置提供的包括通知代理4的远程“中间件(middle ware)”。该通知代理4可以通过一系列网关接收和传输数据给各种通信服务，包括电子邮件5、MMS/SMS服务6、互联网7、VOIP服务8、IMSVOIP服务9以及许多其他类型的服务10。这些也可以利用许多不同的协议进行通信。例如，可以利用SMTP、POP3、IMAP或者SMPP传送电子邮件，与互联网的通信可以利用HTTP/XML，VOIP可以使用SIP(会话启动协议)，就像IMS VOIP可以使用SIP一样，并且其他数据源可以使用类似的协议或者其他协议。
该通知代理4被布置为从多个通知源5到10收集/接收通知。注意，为了可缩放性可以使用多个代理。可以使用不同的模式，例如用于进入的SIP的被动收听模式或用于互联网更新的主动拖拉模式(active pull mode)，或者其他功能。经由各个标准接口从各种通知服务接收进入的通知并且这在附图1中被示出为步骤A。该通知代理4包括处理该通知并将其转换为单个通知格式/协议的功能性。此外，该通知代理4将元数据、响应动作、呈现(presentation)性质和允许的功能打包并且这些被称为“{通知、动作、元数据、功能}”，即{NAMF}包。典型的包在附图3中示意性地示出，其中包5包括通知N、可能的动作范围A、元数据M和功能F，并且该包被传输给UE1。下面将会进一步描述。
附图1示出了若干通知处理逻辑单元6，它们是外部的、可插式的逻辑设备。该通知代理可以将来自多个信息源5到10的进入的通知传递到通知计划逻辑设备6用于初始处理，并且这在附图1中被示出为步骤B。
一旦通知代理将{NAMF}打包，则它们接着在步骤C中被发送到UE。它们可以被一起传递，即作为如附图3所示的包被传递，或者被单独地传递，并且实际的传输实现/协议可以是任何合适的一个。UE通过显示器3将通知和各种选项/动作呈现给用户。任选地，可以通过IPTV AS递送通知。各种可用的选项被显示给用户并且他可以选择它们中的一个。在用户选择了希望的动作后，该UE将选择的动作传回通知代理，步骤D。该通知代理然后或者处理所选择的动作或者将其传递给相关的可插式通知处理逻辑6。任选地，新的通知和动作选择需要被传送回UE。该通知代理然后产生新的NAMF并且将其传递给STB。如果需要进一步的反复，则可以完全重复步骤B、C和D。
如果需要对原始通知源5到10做出响应，则通知代理4通过在其上最初接收通知的标准(本地)通知服务接口递送响应，步骤E。
附图2示意性地示出了数据流。来自各个代理(在这种情况下三个代理；仅作为示例示出了电子邮件5，互联网7和VOIP8)的通知被通知代理4接收。其将该通知转换为单个通知格式/信号协议。其产生{NAMF}包并且将该包传输给UE1。该UE1然后显示该通知和任何可用选项并且用户选择一选项。然后，在步骤D中，这被传输回通知代理4。如果需要与原始代理进行进一步的通信数据传输，则执行上述步骤，否则通知代理接着可能通过通知处理逻辑6(为了清楚而在附图2中没有示出)在步骤C2将另外的{NAMF}传输回UE。在通知代理4和UE之间的所有通信是通过单个协议，通过单个通信装置来完成的，并且因此现在在UE本身中不再需要通知处理逻辑。这全部在通知代理4中完成。因此，可以支持多个通知源。事实上，几乎不受限制的扩展可以被添加到基于中间件的通知代理4上从而包括出现的新通知源(例如电子邮件，SMS或者其它源)，而无需任何对UE的更新或者修改。
更概括地，在中间件内的公共通知代理NA4从多个通知源收集和接收通知。该代理接收并且处理通知，并且以统一的方式将该通知与元数据、响应动作、显现性质、允许的功能或者其他参数或者功能性打包，并且这个包接着通过单个通知信道被传输给UE。该UE因此利用包呈现性质并且利用统一的UE外观和感觉将该通知呈现给用户，而与源5到10的本质无关。
附图3通过举例的方式示出了传输的实际{NAMF}包。除了基本通知外，如上所述，各种其他信息被打包。这可以包括动作A。例如，如果该通知涉及电子邮件，则“通知”可以仅包括电子邮件的主题。该“动作”可以包括用户可以采取的各种动作，例如阅读、保存、获取正文(GET BODY)、忽视等等。“功能”可以包括指示UE(例如机顶盒)如何显示主题以及各种动作的信息，包括可选择的虚拟按钮在屏幕上的位置、显示持续时间，大小/颜色，等等。也可以包括各种类型的“元数据”并且当然还可以包括其他功能或者数据。功能F不仅可以包括如何显示各种选项，例如在显示器上以按钮的形式，还可以包括物理上在显示器的哪里放置这些按钮并且，如果用户当时正在观看IPTV节目或者其他内容，如何处理已经显示的内容。例如，可以包括信息，该信息关于通知和各种功能是应当叠加在现有显示的上面还是替换现有显示，或者如果现有显示是视频内容，在显示通知时是否允许继续该现有显示，或者应该将其变空白还是冻结。也可以传输许多其他类型的信息。该信息还可以包括自动存储视频内容的指示，使得当通知不再显示在屏幕上时，该视频内容自动从其停止的地方重新开始(即暂停功能)。
其它的可能被传输的元素可以涉及例如优先级信息。这可能意味着例如如果消息源自用户的好友名单中的个人或者源自由于其他原因应当被给予较高优先级的个人，则该消息被更显著地显示，或者优先于可能已经正在显示的另一个消息而显示，或者可能改变任何其他呈现性质。该消息可能来自于用户的小孩并且该用户因此迫切地需要观看该消息。许多不同类型的逻辑也是显而易见的。
附图4到6示出了显示的例子。在附图4中，显示器3上正显示视频10。当通知出现时，依据处理逻辑以及与通知一起发送的指示，其以叠加在视频图像10上的方式显示。在这种情况下，该信息是电子邮件的形式并且该电子邮件的主题在第一框11中显示。多个动作按钮12a、12b和12c也被显示，叠加在视频图像上。12a可以是获取正文，12b可以是删除，12c可以是保存等等。可以存在多于或者少于三个的按钮。该按钮12a是可选的，可能通过用户在(例如)遥控器上选择按钮“1”，利用键盘或者其他输入装置，或者通过利用触摸屏直接触摸，通过利用遥控指示器或者通过任何其他装置。
如果用户选择了选项12a获取主题，则这一消息被中继回通知代理并且接着返回到电子邮件源5(附图1)。接着获得该主题并且将其传输回UE。附图6示出了随后的显示，其中正文(或者完整消息)与一些其他的选项一起显示在框13内。这些可以是例如框14a中的删除和框14b中的答复。许多其它的选项当然也是可能的，并且可以存在多于或者少于两个的可能的答复按钮。
当然，附图4到6的实施例是示意性的并且代表该消息是电子邮件的情况。其他类型的通知和显示适合于其他类型的数据。
例如可能存在内容共享的情形。在这种情况下，通知代理4检测到新的用户产生的内容已经被上载代理10上载。该代理向内容始发者的“好友”产生大意是“你有来自Fred的新内容”的通知。这可能是放在附图5的主题框11中的通知。然后可能的动作可能是：读取描述，稍后观看，尽快观看，忽视，给FRED发送短消息。该UE以标准外观和感觉在显示器上呈现通知“你有来自Fred的新内容”并且叠加各种动作。注意，动作的定位可以由从通知发送的包或者根据在UE上的预定规则来确定。
如果用户选择稍后观看，则UE将该动作传到通知代理。该通知代理然后触发内容移动从而缓冲该内容用于稍后观看。然后可以产生新通知“准备在17:00观看该内容。无动作。”
在上述例子中，在UE上不需要特殊的知晓内容的客户端也不需要任何处理逻辑。
又一种情形涉及在IPTV系统上接收的电子邮件。该通知代理4检测到已经接收到新的电子邮件。该代理向IPTV UE产生通知“你有电子邮件”。动作读取，答复，忽视。该UE以标准外观和感觉呈现其通知并且叠加各种动作。在该例子中该用户选择读取。UE将这一动作传给通知代理。该代理然后利用合适的电子邮件协议(例如IMAP，POP3)重新取得电子邮件正文。然后产生包括邮件正文和一组新动作的新通知。然后继续该循环。在这一例子中，再次，在UE上不需要特殊的电子邮件处理(PO3，IMAP，SMTP等)客户端也不需要任何处理逻辑。
又一种情形涉及IPTVSMS通知。将出现与上述情形类似的数据流，但是从通知代理服务器(proxy)对SMPP上的SMS服务器触发读取动作。再次，在UE本身上不需要SMPP客户端也不需要任何处理逻辑。所有上述情形，以及许多其他情形，都可以利用公共的外观和感觉来在相同的UE上实现，而在UE上无需特殊的客户端或处理逻辑。
多种变型是可能的。可以适配(adapt)通知呈现，使得如果例如接收到低优先级的消息，则在用户正观看的TV节目(例如足球比赛)之后递送该消息。或者以不太明显但是叠加在比赛上的方式显示该消息。
本发明从UE中去除了通知处理逻辑。这使得能够通过公共的且节省成本的方式支持多个通知源。其还允许几乎不受限制的扩展，包括将新的通知源添加到具有UE更新或者修改的中间件(即在服务器或者基础设施级)。这非常节省成本并且还使得能够根据运营商的要求得到“挑选和混合”融合服务。
该UE无需具有在多个通知客户端和其他应用之间的任何仲裁。同样，每一个客户端也无需GUI用户化，因为UE能够对所有通知使用公共的外观和感觉。
因此，通知的核心处理从UE中移除并且在通知代理中(和/或通过外部可插式逻辑)完成而不是在UE中完成。用户仅需要选择响应。