使用基于消息的协议的电视入口服务系统及方法

文档序号:7595302阅读:99来源:国知局
专利名称:使用基于消息的协议的电视入口服务系统及方法
技术领域
本发明一般地涉及电视(例如数字电视)入口服务(television portalservice)系统和方法,尤其是涉及一种在实现家庭入口服务过程中把基于消息的协议用作考虑了服务控制、用户管理和服务间关联的框架的电视(TV)入口服务系统和方法。
背景技术
一般来说,数字电视(DTV)提供了一个能够打开具有与数据通信组合的新概念的服务领域的机会,以及一个改善常规模拟电视的图像和声音质量的目的。
近来,基于使用高清晰像质和网络的电视(TV)专用入口设备的家庭生活信息/媒体服务因为具有广泛的适用性,已深深吸引了相关的工业。
家庭入口服务(home portal service)的范围已延伸到多个领域,包括信使服务、多媒体服务如视频点播(VOD)、广播服务、商务服务以及简单的生活信息服务,每种服务的类型随其应用对象、先进的技术或商业特征而变。提供终端的服务和服务器需要一种结构化/技术性的方案正确地处理每种服务请求。

发明内容
本发明的目的是解决当前电视入口服务系统中存在的已知问题,以及提供一种使用基于消息的协议的电视入口服务系统和方法,其利用基于消息的协议实现用户系统到每一服务使用和管理的登录、消息服务自身及注销,由此提供集合服务,以便将各个单一服务并入到电视入口服务的配置中。
根据用于达到以上目的的本发明实施例,提供一种用于提供电视入口服务的客户终端设备,其包括至少一个或多个服务应用(serviceapplication),用于基于根据用户的请求从服务器收到的服务消息执行多种入口服务;以及通信客户模块,用于a)通过基于消息的协议把多个服务应用产生的服务请求消息转换为消息帧格式,以便经由网络把消息帧格式发送给服务器,以及b)接收经由服务器发送的用于服务消息的消息帧格式,分析收到的消息帧格式,以及把被分析的服务消息提供给多个服务应用中的对应于相关服务消息的服务应用。
根据本发明的另一实施例,一种用于提供电视入口服务的系统,其包括通信服务器模块,用于a)通过基于消息的协议接收经由网络从客户终端发送的服务请求消息帧,分析收到的消息帧,以及然后输出被分析的服务请求消息,以及b)通过基于消息的协议把根据客户终端的请求提供的服务请求和处理结果消息及用户通告消息转换为消息帧,以及然后经由网络把消息帧发送给客户终端;以及消息服务器,用于根据从通信服务器模块输出的被分析的服务请求消息,产生相关的服务请求和处理消息及用户通告消息,以及把消息提供给通信服务器模块。
根据本发明的又一实施例,提供一种电视入口服务系统,其包括至少一个或多个服务应用,用于基于根据用户的请求经由网络收到的服务消息执行多种入口服务;通信客户模块,用于a)通过基于消息的协议把多个服务应用产生的服务请求消息转换为消息帧格式,以便经由网络发送消息帧格式,以及b)接收经由网络收到的用于服务消息的消息帧格式,分析收到的消息帧格式,以及把被分析的服务消息提供给多个服务应用中的对应于相关服务消息的服务应用;通信服务器模块,用于a)对经由网络通过基于消息的协议从通信客户模块收到的服务消息帧进行分析,以及然后输出被分析的服务请求消息,以及b)通过基于消息的协议把根据通信客户模块的请求提供的服务请求和处理结果消息及用户通告消息转换为消息帧,以及然后经由网络把消息帧发送给通信客户模块;以及消息服务器,用于根据从通信服务器模块输出的被分析的服务请求消息,产生相关的服务请求和处理消息及用户通告消息,以及把消息提供给通信服务器模块。
客户终端的通信客户模块可以包括消息帧产生单元,用于针对从多个服务应用产生的服务请求消息产生相应的消息帧,以便经由网络把客户消息帧发送给通信服务器模块;以及消息分析单元,用于分析发自通信服务器模块的服务器消息帧,以及把被分析的服务消息提供给相关的服务所对应的服务应用,客户终端的通信客户模块还可包括消息队列,用于临时存储来自通信客户模块的被分析的服务消息,以及然后把服务消息传送给相关的服务所对应的服务应用。
电视入口服务系统还包括先进先出(FIFO)存储器,用于临时存储消息,以致当来自通信客户模块的被分析的消息是要求用户确认的消息或用户通告消息时,相关的消息通过相关的服务应用被显示在电视屏幕上。在电视模式是电视观看模式的情况下,消息可以以窗口小部件的形式显示为屏幕显示(OSD),在电视模式是个人计算机(PC)屏幕模式的情况下,利用操作系统(OS)的应用程序接口(API),消息可以显示在消息框中或显示为图标形式。
更进一步,服务器系统的通信服务器模块可以包括消息帧产生单元,用于针对从消息服务器产生的服务请求和处理消息及用户通告消息产生相应的消息帧,以及经由网络把产生的消息帧发送给通信客户模块;以及消息分析单元,用于对发自通信客户模块的服务消息帧进行分析,以及把被分析的服务消息提供给消息服务器。
而且,根据本发明的另一实施例,在用于提供电视入口服务的服务器和客户终端之间提供一种基于消息的协议,该基于消息的协议能够通过分别产生以下字段以及通过添加相关的消息到每一产生的字段,来执行服务器与客户终端之间的数据发送和接收,所述以下字段包括消息类型字段,用于对在服务器与客户终端之间发送和接收的消息的属性进行分类;服务类型字段,用于对电视入口服务类型进行分类;数据类型字段,用于对在服务器与客户终端之间发送和接收的数据的类型进行分类;数据字段,其包括在服务器与客户终端之间发送和接收的实际数据;以及结果类型字段,用于对消息处理结果进行分类。
同时,根据本发明的另一实施例,一种处理客户终端中的消息以提供电视入口服务的方法,该方法包括以下步骤如果根据用户的请求从多个服务应用产生了服务请求消息,则通过基于消息的协议针对至少一个或多个产生的服务请求消息产生消息帧,以及经由网络把产生的消息帧发送给服务器;接收经由网络从服务器收到的针对用户请求消息的响应消息帧及处理和通告消息;以及通过分析收到的消息帧及通过把被分析的服务消息提供给多个服务应用中对应于相关服务消息的服务应用,来执行相关的服务。
根据本发明的又一实施例,一种处理服务器中的消息以提供电视入口服务的方法,该方法包括以下步骤通过基于消息的协议接收经由网络从客户终端发送的服务请求消息帧;分析收到的消息帧以提取服务请求消息;根据提取的服务请求消息,通过基于消息的协议产生针对服务请求的响应消息帧和处理结果消息及用户通告消息;以及经由网络把产生的消息帧发送给客户终端。
根据本发明的另一实施例,一种电视入口服务方法,该方法包括以下步骤如果根据用户的请求从客户终端的多个服务应用产生了服务请求消息,则通过基于消息的协议针对至少一个或多个产生的服务请求消息产生消息帧,以及经由网络把产生的消息帧发送给服务器;通过基于消息的协议接收经由网络从客户终端发送的服务请求消息帧,并分析收到的消息帧以提取服务请求消息;根据提取的服务请求消息,通过基于消息的协议产生针对服务请求的响应消息帧和处理结果消息及用户通告消息,然后经由网络把消息帧发送给客户终端;以及通过分析经由网络从服务器发送的消息帧及通过把被分析的服务消息提供给多个服务应用中对应于相关服务消息的服务应用,来执行相关的服务。
在此,通过相同的基于消息的协议从服务器发送的消息帧的格式与发送给服务器的消息帧的格式具有相同的格式结构。
发自服务器的消息帧的格式和发送给服务器的消息帧的格式包括消息类型字段,用于对在服务器与客户终端之间发送和接收的消息的属性进行分类;服务类型字段,用于对电视入口服务类型进行分类;数据类型字段,用于对在服务器与客户终端之间发送和接收的数据的类型进行分类;数据字段,其包括在服务器与客户终端之间发送和接收的实际数据;以及结果类型字段,用于对消息处理结果进行分类。


参照以下连同附图一起考虑的详细说明,本发明及其伴随的许多优点将变得更明显和更易理解,在附图中相同的附图标记表示相同或相似的部件,其中图1所示的框图说明了示例TV入口服务系统的结构;图2所示的框图说明根据本发明的TV入口服务系统的结构;图3说明了根据本发明在客户与服务器之间收发的消息帧格式;图4a说明了图3所示的消息类型的数据格式;图4b说明图3所示的服务类型的数据格式;图4c说明了图3所示的数据类型中所包括的数据类型的例子,以及对应于该数据类型的实际传输数据格式;图4d说明了用于对图3所示的消息处理结果(结果类型)分类的数据格式的例子;图5说明了根据本发明在客户中收到消息时的操作流程;图6说明了根据本发明消息从客户发送到服务器时的操作流程;图7说明了根据本发明实施例在客户与服务器之间的登录/注销消息流程;图8说明了根据本发明实施例从服务器到客户的通告服务的消息流程;图9说明了根据本发明实施例进行订单服务时在客户与服务器之间的订单接收消息流程;图10说明了根据本发明实施例进行订单服务时在客户与服务器之间的订单接收后取消消息流程;图11说明了根据本发明实施例进行预定服务时在客户与服务器之间的预定接收消息流程;图12说明了根据本发明实施例进行预定服务时在客户与服务器之间的预定接收后取消消息流程;图13说明了根据本发明实施例进行EPG服务时在客户与服务器之间的EPG广播预定消息流程;以及图14说明了根据本发明实施例进行VOD服务时在客户与服务器之间的VOD服务消息流程。
具体实施例方式
以下,将参照

电视入口服务设备。
图1所示框图说明了示例电视入口服务设备的结构。
如图1所示,电视入口服务设备由服务客户(service client)10和服务服务器(service server)20组成。服务客户10和服务服务器20配有各自的服务应用(service application)11-15和21-25,该服务应用11-15和21-25根据各种服务类型执行相关的服务。
此外,在客户10和服务器20的各自应用之间采用了各自的协议11a-15a和21a-25a,该协议11a-15a和21a-25a处理收发的数据以执行各自的服务。在此,家庭入口服务包括,例如视频点播(VOD)服务,信使(MSG)服务,电子商务服务,验证授权计费(AAA)服务等等,以及电子节目指南(EPG)服务。
因特网入口服务是从简单的基于环球网(WEB)的服务如附加服务到多媒体服务如VOD的多种技术的集合。每种服务实际上由完全不同的协议栈管理和控制。即,附加服务由使用HTML(超文本链接标示语言)的WEB内容组成。商务服务、信道控制、用户验证和VOD分别采用安全协议、信道变换协议(CCP)如数字音视协会(DAVIC)、在AAA服务器中定义的管理协议,以及流控制协议如实时流协议(RTSP)和因特网群组管理协议(iGMP)。从而,每当一个服务附加地被执行,就必须构造相应的独立软件栈。
必须依据每种服务类型在服务客户10和服务服务器20两者中构造协议栈,以便执行每种服务。例如,VOD服务将使用HTTP(超文本传输协议)/RTSP/iGMP 11a和21a。信使、电子商务、AAA和EPG服务将分别采用TCP/IP(传输控制协议/网际协议)MSG协议12a和22a、TCP/IP SSL(安全套接字层)协议13a和23a、管理协议14a和24a,以及专用协议15a和25a。
以下将更详细地说明每种服务的协议。
首先,在VOD服务中使用的RTSP和数字存储媒体命令和控制(DSM-CC)协议的情况下,服务如因特网上提供的VOD以客户/服务器形式操作,该客户/服务器形式是由一直提供信息的一端和使用信息的一端配置的。
RTSP是用于在使用因特网的客户/服务器环境中以较松散的时间约束传输多媒体信息的一种协议。客户向服务器请求具有实时特征的视频和音频信息,并且服务器响应该请求发送信息。在传输过程中,可以获得作为盒式录像机(VCR)的基本功能的暂停、停止、重新开始、关闭等功能。流技术(streaming)是这样一种技术当在一定程度上维持实时特征时,流技术通过这样一种方式来允许连续的重现,以致当服务器分隔并发送压缩的连续消息时,接收端不是在收到所有消息之后才解码/重现消息,而是每当收到某些单元的消息就解码消息。
RTSP能够在单播和组播环境中同时控制多个媒体信息流,并能够在包括传输控制协议(TCP)和用户数据报协议(UDP)的不同传输层协议下操作,并且使用实时传输协议/实时控制协议(RTP/RTCP)。为了发送控制消息,RTSP利用可靠的TCP执行RTP/RTCP信道设置,然后使RTP/RTCP来被发送。即,设置和发布会话由RTSP控制,而实际的信息是通过RTP传输的。
使用异步传输模式(ATM)网络的VOD服务使用DSM-CC协议。DSM-CC是在应用层中用于对MPEG-1/2位流执行操作和控制功能的一种协议,并且正在被运动图像专家组(MPEG)标准化组的小组标准化。DSM-CC是用于机顶、视频服务器和通信网络的一种信号协议,其主要用途是控制从存储MPEG数据的视频存储媒体发送的MPEG位流。为此,MPEG标准化组在1994年构造了DSM-CC,并且在几经易稿之后,于1996年6月将DSM-CC用作一个国际标准。
中央集中方式的会话管理标准在DSM-CC中被制定,以便控制MPEG位流。即,会话与资源管理器(SRM)利用Q.2931信令代理来管理MPEG位流传输的带宽。而且,在客户和服务器之间,执行文件存取、目录控制和数据库控制程序以及流控制。DSM-CC描述了独立的MPEG位流控制或异构网络环境的标准规范。
另外,用于电子商务服务中的安全套接字层(SSL)协议使用这样一种方式,即随同网络连接设置一起增添中间步骤,以及请求安全维护传输选项。在这种连接状态下,服务器与客户之间的数据流在传输之前被加密,并且该加密的数据在使用之前被解密。待发的加密数据被TCP封装,然后被传送到因特网。到来的加密数据被接收,然后被发送到SSL层以便解密。
SSL协议中的该方法能够将SSL应用于任何因特网应用以及环球网(WWW)。SSL最初在HTTP下被执行。而且,如果在服务器和客户之间建立了SSL连接折衷(connection compromise),结果的数据通信信道就变成了单独的、取得确认的、可靠的信道。
通过服务器与客户之间的握手交换实现SSL链接的开始。此时,两个系统交换必须的加密信息,并支持安全信道。在信息交换之后,应用程序应该在受到传输必需的加密之后被发送给目的应用程序。目的应用程序执行数据解密和确认所需的加密。
SSL在因特网应用和网络传输层之间运行,并且对在客户和服务器之间通信的数据进行加密。
同时,如AAA服务中使用的协议,可以使用终端访问控制器访问控制系统(TACACS)、远程访问拨入用户服务(RADIUS)以及DIAMETER协议。
TACACS是有一点旧的适用于UNIX网络的验证协议,其允许远程访问服务器把用户的登录口令发送给验证服务器,以便确定是否允许访问指定的系统。因为TACACS是非加密的协议,因此与后来的TACACS+和RADIUS协议相比,其稳定性差。TACACS的后来版本是扩展的TACACS(XTACACS),在RFC(网络工作征求评议)1492“访问控制协议,有时称为TACACS(An Access Control Protocol,Sometimes Called TACACS)”中描述了TACACS和XTACACS。
TACACS+是一个全新的协议。一般,在新近配置的或更新的网络中,TACACS+和RADIUS被上述的协议替代。TACACS+使用TCP,而RADIUS使用UDP。
一些管理者推荐使用TACACS+,因为TCP是一种更稳定的协议。RADIUS在一个用户概述中同时具有验证和准许,而TACACS+被分为两项任务。TACACS和XTACACS仍然运行在许多旧系统中。
近来,最广泛使用的AAA服务是基于RADIUS协议的。RADIUS协议是用于小规模网络设备的一种协议,其支持少数订户要求基于服务器的验证,但是其不适于用于通信商务的、必须基于不同的技术同时支持数百至数千个用户的AAA服务。为了解决RADIUS协议的限制和问题,当前的因特网工程任务组(IETF)定义了diameter协议。diameter协议提供各种存取网络和安全应用服务,并且为多个网络上的有线和无线访问订户及漫游订户执行验证、授权、校验和记帐过程。
结果,单个用户终端的综合管理作为关键的技术问题呈现给各个服务提供者。即,在电视入口服务上需要一致的访问,以管理和控制服务使用权、使用时间及服务间的关联。
当利用单个协议栈配置入口时,对于终端,当根据服务添加单个应用时,要求更改现有的终端和服务器中的每个服务应用和相关的协议栈以便提供服务。从而,有一个问题是,即使配置了由优先权简档(PP)提供的服务池,也难以灵活地解决它。
虽然该配置维持单个服务执行中的独立性,但是由系统配置来看它不具备一致性,并且不能提供与服务网关执行中的多种服务组合相符的技术灵活性。
以下,将参照附图详细说明根据本发明优选实施例的电视(TV)入口服务系统和方法。
图2所示框图说明了根据本发明的电视入口服务系统的结构。
如图2所示,电视入口服务系统可以由客户终端100和服务器组成。
服务器可以由通信服务器模块310和消息服务器300组成。
客户终端100可以由通信客户模块110、可选的消息队列120、可选的先进先出存储器(FIFO)130以及用于各自服务的多个服务应用140-200组成。
在此,用于各自服务的服务应用可以包括但不限于数字电视(DTV)应用140、信息提供服务应用150、真实视频点播(RVOD)服务应用160、准视频点播(NVOD)服务应用170、订单交付服务应用180、通告服务应用190以及电子节目指南(EPG)服务应用200。
消息协议在服务器/客户结构中操作。通信服务器模块310被设置在消息服务器300中,通信客户模块110被设置在客户终端100中。在此,客户终端100可以是机顶盒或网关。
当从服务应用140-200任何之一产生要发送给服务器的消息时,利用进程间通信(IPC)通知通信客户模块110。
响应此,通信客户模块110确认由服务应用产生且经过IPC收到的消息,然后产生适于该每一产生的消息的消息帧。
产生的消息帧通过消息协议(套接字)400被发送给通信服务器模块310。
通信服务器模块310分析发自客户终端100的消息帧,以检查消息是否正在请求服务,然后向消息服务器300要求相应的服务请求。
消息服务器300响应来自客户终端100的服务请求,向通信服务器模块310提供相关的服务请求和处理结果消息。
通信服务器模块310分析由消息服务器300提供的消息,以产生合适的消息帧,然后经过消息协议(套接字)400将产生的消息帧发送给客户终端100中的通信客户模块110。
当收到服务器产生或响应的消息时,通信客户模块110利用通信客户模块110中的分析程序分析该消息,以便经过IPC将该消息发送给相关的服务应用140-200。
因此,收到消息的相关服务应用将执行请求的服务。
为了使发自服务器的服务请求和处理结果消息经由通信客户模块110被提供给每一应用,消息队列120通过通信客户模块110将每一消息临时存储在每一消息类型的消息结构中,然后经过应用程序接口(API)将存储的对应于各自应用的消息提供给相关的服务应用140-200。
同样,当在发自服务器的消息当中有消息要求用户的确认时,例如在通告服务中,FIFO 130临时存储相关的消息,以便该相关的消息经由DTV应用140显示在DTV屏幕(未显示)上。在此,消息显示方法包括以下在TV观看模式下,消息以窗口小部件(widget)的形式显示为屏幕显示(OSD);在个人计算机(PC)屏幕模式下,利用操作系统(OS)的应用程序接口(API),消息显示在消息框中或者显示为图标形式。
以下将参照附图3和4a-4d详细说明在服务器和客户之间收发的消息帧的格式结构。
图3说明了根据本发明在客户和服务器之间收发的消息帧格式,图4a说明了图3所示的消息类型的数据格式,图4b说明了图3所示的服务类型的数据格式,图4c说明了在图3所示的数据类型中所包括的数据类型的例子以及对应于数据类型的实际传输数据格式,图4d说明了用于对图3所示的消息处理结果(结果类型)进行分类的数据格式的例子。
如图3所示,在客户和服务器之间收发的消息帧格式被分类为消息类型字段,用于对消息属性分类;服务类型字段,用于对服务类型分类;数据类型字段,用于对数据类型分类;以及结果类型字段,用于对要发送的实际数据和消息处理结果分类。
在此,如图4a所示,消息类型信息可以被分类为请求(REQ)类型消息、响应(REP)类型消息和通告(INF)类型消息。
如图4b所示,服务类型信息可以被分类为例如,登录/注销服务(LOG)、电子邮件(E-MAIL)服务(EML)、订单服务(ORD)、预定服务(RES)、警报服务(ALM)和NVOD服务(NVD)。显然,为简洁起见,有许多其它可能的服务在此没有列出。
另外,如图4c所示,作为对应于服务类型的数据类型和数据,LOG服务包括登录(LON)和注销(LOF)数据作为数据类型,EML服务包括未读邮件号(UMN)数据作为数据类型。
ORD服务中包括的数据可以被分类为结算(settlement)完成(STC)、结算确认(STF)、收到(RCP)、接收后(post-receipt)取消请求(CAR)、接收后取消确认(CAF)、接收后取消处理(CAH)和订单交付(DLV)数据。
RES服务中包括的数据可以被分类为预定应用(APL)、预定接收(RCP)、接收后取消请求(CAR)、接收后取消确认(CAF)和接收后取消处理(CAH)数据。
ALM服务中包括的数据被分类为全部警报(ALL)、未读邮件警报(UMA)、预定安排警报(RSA)和预定程序警报(RPA)数据。
同时,NVD服务包括信道请求(CHR)数据。
如图4d所示,结果类型信息被分类为成功(SUC)、失败(FAL)和未知信息(NUL)。
结果,通过图3所示的包括图4a-4d所示的每一信息的基于消息的协议,客户和服务器之间的数据传输帧格式以消息帧的形式被发送。即收发的消息帧包括消息类型、服务类型、数据类型、数据以及结果类型信息。
以下将参照图5和图6说明利用这种消息帧格式在客户和服务器之间收发消息的操作。
图5说明了根据本发明在客户中收到消息时的操作流程,图6说明了根据本发明消息从客户发送给服务器时的操作流程。
首先,将参照图5说明客户接收发自服务器的消息的操作。
如图5所示,如果连接到网络的每一客户终端100都通电,则每一客户终端100试图经过预先确定的专用端口连接到消息服务器300。当连接没有被建立时,客户终端以几秒钟的间隔再次尝试连接。当客户终端100与消息服务器300之间的连接被建立时,客户终端100利用客户终端100的唯一标识符(unique ID)和从动态主机配置协议(DHCP)服务器分配的动态IP号进行“登录”。如果验证完成,只要没有异常情况(例如网络或服务器不正常等)出现,建立的连接就连续保持。
如果收到了经由通信模块310从消息服务器300发送的消息帧(例如,REQORDSTF“订单号”|“消息”NUL针对订单结算确认请求的响应消息),通信客户模块110中的消息分析程序111分析收到的消息,临时将该消息存储在消息队列120中,然后经过IPC将该消息发送给相关的服务应用150-200。因此,已收到消息的相关应用将执行相关的服务。
此时,如果收到的消息类型需要用户的确认请求,则相关的请求消息被临时存储在FIFO 130中,然后被显示在连接到客户终端100的控制台上,其中在TV观看模式下,消息以窗口小部件的形式显示在OSD上;在PC屏幕模式下,利用OS的API,消息显示在消息框中或者显示为图标形式。即相关的确认消息通过DTV应用或PC应用140被显示。
同时,以下的从客户终端100到消息服务器300的消息传输被执行。即,如图6所示,如果根据用户的请求从客户终端100中的任意服务应用150-200的任何之一产生了要发送给消息服务器300的消息,则该消息通过IPC被通知给通信客户模块110。
针对在服务应用150-200中产生的消息,通信客户模块110在内部消息发生器112中产生一消息帧(例如,REPORDSTF“特权码(franchisecode)”|“订单号”|“是”SUC),并通过消息协议(套接字)400将该产生的消息帧发送给服务器300中的通信服务器模块310。
从而,当收到来自客户终端100的消息帧时,通信服务器模块310分析收到的消息帧,并把被分析的消息帧提供给消息服务器300,以便产生针对客户终端100请求的消息的响应或确认消息。该产生的消息通过如图5所示的传输流程被发送给客户终端100。
以下,将参照附图同步说明根据每种服务类型在客户终端100与服务器300之间的消息发送和接收方法。
图7说明了根据本发明实施例在客户与服务器之间的登录/注销消息流程。
首先,当客户终端100例如机顶盒通电时,客户终端100的通信客户模块110产生一用以登录到服务器的消息帧,然后经过消息协议将该产生的登录消息帧(例如REQLOGON“MG码”|“MG IP”NUL)发送给消息服务器300(S101)。
在分析发自客户终端100的登录消息帧以执行相关客户终端100的验证之后,消息服务器300根据验证结果在通信服务器模块310中产生一登录响应消息帧,以便经过消息协议(套接字)400将该产生的响应消息帧发送给通信客户模块110。
即,如果相关客户终端100的验证及由此的登录失败,消息服务器300产生登录失败响应消息帧(例如REPLOGON“MG码”FAL),以便将其发送给客户终端100的通信客户模块110(S102),然而,如果相关客户终端100的验证及由此的登录成功,消息服务器产生登录成功响应消息帧(例如REPLOGON“MG码”SUC),以便将其发送给客户终端100的通信客户模块110(S102-1)。
从而,如果客户终端100的登录成功,消息服务器300确认是否有对于相关客户终端100的任何通告信息。如果有通告信息,消息服务器300为每一用户在消息服务器300的通信服务器模块310中产生一通告消息帧(例如INFALMALL“消息”NUL),以便经由消息协议400将该产生的通告消息帧发送给客户终端100的通信客户模块110(S103)。
从而,客户终端100的通信客户模块110分析发自服务器的通告消息帧,并将被分析的相关通告消息提供给通告服务应用190,以便相关的通告服务。
在操作中,当用户断开客户终端100的电源时,通信客户模块110针对断电产生一消息帧(例如,INFLOGLOF“MG码”NUL),以便将该消息帧发送给消息服务器300的通信服务器模块310(S104)。
如果通信服务器模块310分析发自通信客户模块110的注销消息帧,然后将被分析的注销消息传送给消息服务器300,则消息服务器300从消息服务器300管理的客户连接列表中删除相关客户终端100的ID。
结果,如图7所示的以下登录/注销服务被执行。即,当客户终端100通电时,通信客户模块110试图连接到服务器,并且如果连接被建立,利用客户终端100的唯一ID执行登录程序,以便通知服务器是否可以获得不同的入口服务。
然而,如果客户终端100被断电,通信客户模块110发送注销消息给服务器,以便请求从服务器管理的连接列表中删除相关客户终端100的ID。
图8说明了根据本发明实施例从服务器到客户的通告服务的消息流程。
如图8所示,当存在从服务器300到客户终端100的任何通告情形时,例如,当电子邮件通告、预定安排通告或预定节目通告情形产生时,消息服务器300通知通信服务器模块310。
然后,通信服务器模块310针对消息服务器300产生的通告消息产生一消息帧,例如在电子邮件通告的情况下为INFALMUMA“消息”NUL消息帧,在预定安排通告的情况下为INFALMRSA“消息”NUL消息帧,在预定节目通告的情况下为INFALMRPA“消息”NUL消息帧,并且通过消息协议400将该产生的消息帧发送给客户终端100的通信客户模块110(分别为S201、S202、S203)。
客户终端100的通信客户模块110分析发自服务器的通告消息帧,将每一通告消息临时存储在消息队列120中,然后将通告消息传送给通告服务应用190,以便执行通告服务。作为选择,当需要用户的确认时,客户模块将通告消息临时存储在FIFO 130中,然后将通告消息顺序地传送给DTV应用140,以便将通告消息显示在DTV屏幕上。此时,如上所述,在TV观看模式下,消息以窗口小部件的形式显示在OSD上;在PC屏幕模式下,利用OS的API,消息显示在消息框中或者显示为图标形式。该消息服务可以与EPG、订单交付或E-MAIL服务一起使用。
图9说明了根据本发明实施例进行订单服务时在客户与服务器之间的订单接收消息流程。
如图9所示,如果从客户终端100的订单交付服务应用180产生了针对产品订单的消息,客户终端100的通信客户模块110就针对该订单消息产生消息帧,并且经由消息协议400将该消息帧发送给服务器中的通信服务器模块310。
通信服务器模块310分析发自客户终端100的订单消息帧,然后将订单消息传送给消息服务器300。然后,消息服务器300把订单请求消息发送给某一特权终端,根据产品订单消息向该特权终端定购相关的产品。
特权终端(未显示)根据发自服务器的订单消息处理订单,然后向服务器提供订单处理结果信息。服务器将订单处理结果消息提供给客户终端100。
此时,如果从客户终端100中的订单交付服务应用180中产生了订单结算完成消息,则客户终端100的通信客户模块110针对该订单结算完成消息产生一消息帧(例如,INFORDSTC“订单号”NUL),并经过消息协议400将该产生的消息帧发送给通信服务器模块310(S301)。
通信服务器模块310分析发自客户终端100中的通信客户模块110的消息帧,并将订单结算完成消息传送给消息服务器300。
消息服务器300根据传自通信服务器模块310的订单完成消息将订单结算确认请求消息(OSF)传送给通信服务器模块310。
通信服务器模块310针对传自消息服务器300的订单结算确认请求消息产生一消息帧(REQORDOSF“订单号”|“消息”NUL),以便将该产生的消息帧发送给客户终端100的通信客户模块110(S302)。
通信客户模块110分析发自服务器的订单结算确认请求消息帧,并将订单结算确认请求消息临时存储在消息队列120中,以便将其传送给订单交付服务应用180。
更进一步,通信客户模块110分析收到的消息帧,并且因为相关的消息是请求用户确认的消息,因此经过FIFO 130将该收到的消息帧传送给DTV应用140,以便将该消息帧显示在DTV上。
如果用户响应显示的解决确认消息完成了结算确认(YES,是),则通信客户模块110针对该结算确认消息产生一消息帧(REPORDSTF“特权码”|“订单号”YESSUC),以便将该消息帧发送给服务器中的通信服务器模块310(S303)。
在分析收到的结算确认消息帧之后,通信服务器模块310将结算确认消息传送给消息服务器300。消息服务器300将结算确认消息发送给相关的特权终端,以便处理订单。
在处理订单之后,特权终端将订单处理结果消息(收到)发送给消息服务器300。消息服务器300根据发自特权终端的订单处理结果消息产生订单处理通告消息,并将该订单处理通告消息传送给通信服务器模块310。
通信服务器310针对传自消息服务器300的订单处理通告消息产生一消息帧(INFORDRCP“订单号”|“消息”NUL),并将该产生的消息帧发送给客户终端100的通信客户模块110(S304)。
从而,在分析相关的帧并将被分析的订单处理通告消息存储在消息队列120之后,通信客户模块110将其传送给订单交付服务应用180,以便执行相关的服务,并且同时将其传送给DTV应用140,以便将订单处理结果消息显示在DTV上,这样允许用户确认订单处理结果。
然而,在S302中,如果在收到发自服务器的针对订单结算确认请求消息的消息帧(REQORDOSF“订单号”|“消息”NUL)之后用户选择了解决确认(NO,否),则通信客户模块110针对订单结算确认(否)消息产生一消息帧(REPORDSTF“特权码”|“订单号”NOSUC),以便将该消息帧发送给服务器。从而服务器将结算确认(否)消息发送给特权终端,以便执行订单取消操作。
以下将参照图10说明订单接收后取消服务。
图10说明了根据本发明实施例进行订单服务时在客户与服务器之间的订单接收后取消消息流程。
如图10所示,首先,如果从订单交付服务应用180产生了取消请求消息,通信客户模块110就针对该取消请求消息产生一消息帧(INFORDCAR“特权码”|“订单号”NUL),并将该消息帧发送给服务器300中的通信服务器模块310(S401)。
服务器300中的通信服务器模块310分析发自客户终端100的消息帧,并将取消请求消息传送给消息服务器300,然后消息服务器300将其发送给某一特权终端。
如果在把从客户终端100收到的取消请求消息发送给相关的特权终端之后,消息服务器300从该相关的特权终端收到了订单接收后取消确认消息,则消息服务器300产生一订单取消确认通告消息,并针对产生的订单取消确认通告消息在通信服务器模块310中产生一消息帧(INFORDCAF“订单号”|“消息”NUL),并将该消息帧发送给客户终端100的通信客户模块110(S402)。
而且,如果消息服务器300从相关特权终端收到了订单取消处理消息,消息服务器300产生一订单取消通告消息,以便将相关的消息传送给通信服务器模块310。
通信服务器模块310针对订单取消处理消息产生一消息帧(INFORDCAH“订单号”|“消息”NUL),以便将该消息帧发送给客户终端100的通信客户模块110(S404)。通信客户模块110分析收到的消息帧,把订单取消处理消息传送给订单交付服务应用180以便处理相关的服务,以及把相关的消息传送给DTV应用140,以便显示相关的消息,这样允许用户确认订单取消结果。
以上是在存在来自用户的订单接收后取消请求的情况下的消息流程。以下,将说明存在来自特权终端的订单取消请求的情况。
首先,如果存在来自特权终端的订单取消请求,消息服务器300针对发自特权终端的订单取消请求产生一通告消息,并将相关的消息发送给通信服务器模块310。
通信服务器模块310针对从消息服务器300产生的特权订单取消通告消息产生一消息帧(REQORDCAF“订单号”|“消息”NUL),以便将该消息帧发送给客户终端100的通信客户模块110(S404)。
通信客户模块110分析发自通信服务器模块310的消息帧,并将订单取消通告消息传送给订单交付服务应用180以便执行相关的服务。另外,通信客户模块110将相关的消息传送给DTV应用140,以便显示相关的消息,这样使用户能够实现订单取消确认响应。
如果用户选择了订单取消确认响应消息“YES(是)”,则通信客户模块110针对订单取消确认响应消息产生一消息帧(REPORDCAF“特权码”|“订单号”YESSUC),以便将该消息帧发送给通信服务器模块310(S405)。
通信服务器模块310分析发自通信客户模块110的消息帧,并将相关的消息即订单取消确认响应消息发送给某一特权终端,以便处理订单取消。如果订单取消完成了,特权终端将订单取消处理结果消息发送给服务器。
响应此,服务器300中的通信服务器模块310针对订单取消确认处理通告消息产生一消息帧(INFORDCAH“订单号”|“消息”NUL),以便将该消息帧发送给通信客户模块110(S406)。
同时,在步骤S404中,当从特权终端收到订单取消请求消息时客户收到了订单取消请求消息,如果用户选择了取消确认“NO(否)”,则以与上述操作相同的方法执行发送和接收订单取消响应消息的操作(S407、S408)。因此,将省略详细的操作说明。
同样,如果收到了来自特权终端的、指示产品的订单交付处理完成的消息,通信服务器模块310就发送一针对交付处理通告消息的消息帧(INFORDDLV“订单号”|“消息”NUL)给通信客户模块110,以便完成订单交付服务操作。
图11说明了根据本发明实施例进行预定服务时在客户与服务器之间的预定接收消息流程。
如图11所示,如果存在来自用户的订单预定接收申请,订单交付服务应用180就产生订单预定接收申请消息。
这样产生的订单预定接收申请消息被传送给通信客户模块110,通信客户模块110针对该产生的订单预定接收申请消息产生一消息帧(INFRESAPL“特权码”|“预定号”NUL),以便将该消息帧发送给通信服务器模块310(S501)。
通信服务器模块310分析发自客户的针对订单预定接收申请消息的消息帧,并将相关的订单预定接收申请消息发送给相关的特权终端。
特权终端根据发自服务器的订单预定接收申请消息执行订单预定接收,并将订单预定接收处理结果消息发送给服务器中的通信服务器模块310。
服务器中的通信服务器模块310根据发自特权终端的订单预定接收处理消息,把针对预定接收处理通告消息的消息帧(INFRESRCP“预定号”|“消息”NUL)发送给客户中的客户通信模块110。
通信客户模块110分析发自服务器的针对预定接收处理通告消息的消息帧,把相关的消息传送给订单交付服务应用180以便执行相关的服务,以及把相关的消息传送给DTV应用140以便显示订单预定处理通告消息,以便用户容易地确认订单预定处理结果。
以下将参照图12说明在订单预定接收之后预定接收被取消的情况。
图12说明了根据本发明实施例进行预定服务时在客户与服务器之间的预定接收后取消消息流程。
首先,如果通过订单交付服务应用180产生了预定接收后取消请求消息,则通信客户模块110针对预定接收后取消请求消息产生一消息帧(INFORDCAR“特权码”|“预定号”NUL),并把该消息帧发送给服务器中的通信服务器模块310(S601)。
服务器中的通信服务器模块310分析发自客户终端110的消息帧,并通过消息服务器300把预定接收后取消请求消息传送给相关的特权终端。
在把从客户终端100收到的预定接收后取消请求消息发送给相关的特权终端之后,如果从特权终端收到了预定接收后取消确认消息,则消息服务器300产生一预定取消确认通告消息,并且针对该产生的预定取消确认通告消息在通信服务器模块310中产生一消息帧(INFORDCAF“预定号”|“消息”NUL),以便把该消息帧发送给客户终端100的通信客户模块110(S602)。
而且,如果消息服务器300从特权终端收到了预定取消处理消息,则消息服务器300产生预定取消处理通告消息,以便把相关的消息传送给通信服务器模块310。
通信服务器模块310针对预定取消处理通告消息产生一消息帧(INFORDCAH“预定号”|“消息”NUL),以便把该消息帧发送给客户终端100的通信客户模块110(S603)。
通信客户模块110分析收到的消息帧,把预定取消处理通告消息传送给订单交付服务应用180以便处理相关的服务,以及把相关的消息传送给DTV应用140以显示相关的消息,以便用户确认预定取消结果。
以上是当存在来自用户的预定接收后取消请求时的消息流程。以下将说明存在来自特权终端的预定接收取消请求的情况。
首先,如果存在来自特权终端的预定取消请求,消息服务器300针对来自特权终端的预定取消请求产生一消息帧,以便把相关的消息传送给通信服务器模块310。
通信服务器模块310针对从消息服务器300产生的特权预定取消通告消息产生一消息帧(REQORDCAF“预定号”|“消息”NUL),以便把该消息帧发送给客户终端100的通信客户模块110(S604)。
通信客户模块110分析发自通信服务器模块310的消息帧,并且把预定取消通告消息传送给订单交付服务应用180以便执行相关的服务。而且,通信客户模块110把相关的消息传送给DTV应用140以显示相关的消息,以便用户执行预定取消确认响应。
如果用户选择了预定取消确认响应消息“YES(是)”,则通信客户模块110针对该预定取消确认响应消息产生一消息帧(REPORDCAF“特权码”|“预定号”YESSUC),并把该消息帧发送给通信服务器模块310(S605)。
通信服务器模块310分析发自通信客户模块110的消息帧,并把相关的消息即预定取消确认响应消息发送给特权终端,以便处理预定取消。如果预定取消完成,特权终端把预定取消处理结果消息发送给服务器。
然后,服务器中的通信服务器模块310针对预定取消确认处理通告消息产生一消息帧(INFORDCAH“预定号”|“消息”NUL),以便把该消息帧发送给通信客户模块110(S606)。
同时,在步骤S604中,当来自特权终端的预定取消请求消息被接收以及由此客户收到订单取消请求消息时,如果用户选择了取消确认“NO(否)”,则以与上述操作相同的方法执行订单取消响应消息的发送和接收操作(S607、S608)。从而,将省略对其操作的详细说明。
以下,将参照图13说明进行EPG广播预定时的消息流程。
图13说明了根据本发明实施例进行EPG服务时在客户与服务器之间的EPG广播预定消息流程。
如图13所示,如果用户通过EPG屏幕实现了来自EPG服务应用200的广播预定申请,则客户终端100的通信客户模块110针对通过EPG服务应用200产生的广播预定消息产生一消息帧(INFRESCHR“预定的广播号”NUL),以便把该消息帧发送给服务器中的通信服务器模块310(S701)。
通信服务器模块310分析发自客户终端100的客户通信模块110的消息帧,以便把被分析的消息传送给消息服务器300。
消息服务器300利用发自通信服务器模块310的广播预定消息对用户请求的信道执行广播预定。
更进一步,消息服务器300检查用户选择的广播预定节目的广播预定时间,并且如果相应的时间到达,消息服务器300就产生预定节目通告消息,以便将其传送给通信服务器模块310。
通信服务器模块310针对来自消息服务器300的预定节目通告消息产生一消息帧(INFALMRPA“消息”NUL),并把该产生的消息帧发送给通信客户模块110(S702)。
通信客户模块110分析发自服务器300中的通信服务器模块310的、针对广播预定节目通告消息的消息帧,把相关的消息发送给EPG服务应用200,以便执行相关的服务,即例如把某一信道变换到广播预定节目的信道那样的功能,并且还把相关的消息传送给DTV应用140,以显示预定节目通告消息,这样允许用户确认消息。
即,EPG服务是基于环球网提供的,其允许与通告服务关联的广播预定。如果在EPG屏幕预定(screen reservation)上选择了要预定的广播,则依据预定消息格式将要预定的广播发送给服务器。
如果在记录广播预定情形之后相应的时间到了,服务器通过通告服务通知终端这件事。当收到预定通告消息,终端试图将信道自动地转换到相关的信道,或者将预定通告消息通知给DTV应用140。
以下,将参照图14说明经过消息协议的VOD服务的操作。
首先,如果用户通过VOD服务应用160和170请求用于观看的VOD信道,通信客户模块110针对VOD信道请求产生一消息帧(REQNVDCHR“信道号”NUL),以便把该消息帧发送给通信服务器模块310(S801)。
通信服务器模块310分析发自通信客户模块110的针对VOD信道请求的消息帧,并把VOD信道请求消息传送给消息服务器300。
消息服务器300利用传自通信服务器模块310的VOD信道请求消息执行信道验证,以检查相关的信道是否为客户终端100中可得的信道。
如果信道验证成功或失败,即,如果在客户终端100中可获得或不能获得相关的信道,消息服务器300把针对信道验证响应消息的消息帧发送给客户终端100。如果相关的VOD服务是单播的,并且如果相关信道的验证成功,则通信服务器模块310把(REPNVDCHR“信道号”SUC)消息帧发送给客户终端100的通信客户模块110,相反,如果VOD信道验证失败,则通信服务器模块310把(REPNVDCHR“信道号”FAL)消息帧发送给客户终端100的通信客户模块110(S802、S803)。
通信客户模块110在分析程序中分析发自服务器的针对响应消息的消息帧,并把相关的消息传送给VOD服务应用以显示相关的消息,以便用户确认消息。
然而,在VOD服务为组播的情况下,如果信道验证成功,且产生针对VOD信道请求的响应消息帧,消息服务器300把(REPNVDCHR“信道号”|“组播IP”SUC)消息帧发送给客户终端100的通信客户模块110(S804)。如果信道验证失败,则消息服务器300把(REPNVDCHR“信道号”NULFAL)消息帧发送给客户终端100的通信客户模块110(S805)。
结果,如果客户终端100通过通信客户模块110向服务器300请求要观看的VOD信道,服务器300确认被请求的信道是否可用于相应的终端,并且发送一响应消息。此时,在VOD服务是单播的情况下,如果客户终端收到指示信道可用的响应,则通过通信客户模块110的分析程序收到该响应的VOD应用分析流,以便显示它。
然而,如果VOD服务是组播的,则服务器把对应于请求的信道的组播组IP插入到响应消息中,以便将其发送给客户终端100。
因此,客户终端100中的通信客户模块110的分析程序把IP传送给VOD应用,VOD应用通过发送一用于利用IP连接相关的组播组的消息来接收并分析流,并且显示流。
结果,根据本发明的TV入口服务设备和方法定义了在服务器和客户终端之间执行可得的若干服务所需的控制消息。而且,根据本发明的TV入口服务设备和方法建议如图3和图4所示的一种服务框架和消息标准去共同地管理和处理若干服务,以便使用利用家庭中的一个终端和多项服务的高清晰/标准清晰(HD/SD)广播接收,所述多项服务包括诸如订单交付、VOD、监控以及利用本发明的信息提供。
如上所述,根据本发明的TV入口服务设备和方法允许通过在TV入口服务中提供一致的基于消息的框架对各种服务项进行管理和控制。而且,有可能实现新的应用,这些新的应用是难以通过在单个服务之间提供关联工具实现的。其通过使TV入口服务的API标准化,导致了服务器和终端实现的技术效率,以及灵活服务的实现。
权利要求
1.一种电视入口服务系统,包括客户终端,具有至少一个或多个用于基于根据用户的请求经由网络收到的服务消息执行多种不同的入口服务的服务应用;通信客户模块,用于a)根据用户的请求,把从每一服务应用产生的每一服务请求消息转换为相应的客户消息帧格式,以便通过网络的基于消息的协议发送客户消息帧格式,以及b)接收通过网络的基于消息的协议收到的针对入口服务消息的服务器消息帧格式,分析收到的服务器消息帧格式,以及把被分析的入口服务消息提供给所述服务应用中的相应之一;通信服务器模块,用于a)对通过网络的基于消息的协议从通信客户模块收到的客户服务消息帧格式进行分析,然后输出被分析的服务请求消息,以及b)把根据来自通信客户模块的用户请求提供的服务请求和处理结果消息及用户通告消息转换为服务器消息帧格式,以便通过网络的基于消息的协议把服务器消息帧格式发送给通信客户模块;以及消息服务器,用于根据从通信服务器模块输出的被分析的服务请求消息来产生服务请求和处理结果消息及用户通告消息,并把这些消息提供给通信服务器模块。
2.根据权利要求1所述的电视入口服务系统,其中至少一个或多个服务应用包括以下服务应用的至少之一或多个订单交付服务应用,准视频点播服务应用,真实视频点播服务应用,信息提供服务应用,通告服务应用,电子节目指南服务应用,以及数字电视服务应用。
3.根据权利要求1所述的电视入口服务系统,其中消息帧格式包括消息类型字段,具有用于对在服务器终端与客户终端之间发送和接收的消息的属性进行分类的消息类型信息;服务类型字段,具有用于对电视入口服务类型进行分类的服务类型信息;数据类型字段,具有用于对在服务器终端与客户终端之间发送和接收的数据的类型进行分类的数据类型信息;数据字段,包括在服务器终端与客户终端之间发送和接收的实际数据;以及结果类型字段,具有用于对消息处理结果进行分类的结果类型信息。
4.根据权利要求3所述的电视入口服务系统,其中用于对消息的属性进行分类的消息类型信息包括至少以下信息之一请求信息(REQ)、响应信息(REP)和通告信息(INF)。
5.根据权利要求3所述的电视入口服务系统,其中用于对服务类型进行分类的服务类型信息包括至少以下信息之一登录/注销服务(LOG)信息,电子邮件服务(EML)信息,订单服务(ORD)信息,预定服务(RES)信息,警报服务(ALM)信息,以及准视频点播服务(NVD)信息。
6.根据权利要求3所述的电视入口服务系统,其中用于对数据类型进行分类的数据类型信息包括至少以下信息之一登录数据(LOG),警报数据(ALM),订单数据(ORD),预定数据(RES),电子邮件数据(EML),以及准视频点播数据(NVD)。
7.根据权利要求6所述的电视入口服务系统,其中数据类型信息的登录数据(LOG)包括登录(LON)和注销(LOF)数据。
8.根据权利要求6所述的电视入口服务系统,其中数据类型信息的电子邮件数据(EML)包括未读邮件号(UMN)数据。
9.根据权利要求6所述的电视入口服务系统,其中数据类型信息的订单数据(ORD)包括至少以下数据之一结算完成(STC),结算确认(STF),收到(RCP),接收后取消请求(CAR),接收后取消确认(CAF),接收后取消处理(CAH),以及订单交付(DLV)数据。
10.根据权利要求6所述的电视入口服务系统,其中数据类型信息的预定数据(RES)包括至少以下数据之一预定申请(APL),预定接收(RCP),接收后取消请求(CAR),接收后取消确认(CAF),以及接收后取消处理(CAH)数据。
11.根据权利要求6所述的电视入口服务系统,其中数据类型信息的警报数据(ALM)包括至少以下数据之一全部警报(ALL),未读邮件警报(UMA),预定安排警报(RSA),以及预定节目警报(RPA)数据。
12.根据权利要求6所述的电视入口服务系统,其中数据类型信息的准视频点播数据(NVD)包括信道请求(CHR)数据。
13.根据权利要求3所述的电视入口服务系统,其中结果类型信息包括至少成功(SUC)、失败(FAL)和未知(NUL)信息之一。
14.根据权利要求1所述的电视入口服务系统,其中通信客户模块包括消息帧产生单元,用于针对从服务应用产生的每一服务请求消息产生相应的客户消息帧格式,以便把客户消息帧格式发送给通信服务器模块;以及消息分析单元,用于分析发自通信服务器模块的服务器消息帧格式,以及把被分析的入口服务消息提供给相关的服务。
15.根据权利要求1所述的电视入口服务系统,还包括消息队列,用于临时存储来自通信客户模块的被分析的入口服务消息,以及然后把入口服务消息传送给要执行的入口服务所对应的相关服务应用。
16.根据权利要求1所述的电视入口服务系统,还包括先进先出存储器,用于当来自通信客户模块的被分析的入口服务消息是要求用户响应的消息或通知用户关于请求的入口服务的状态的通告消息时,当被分析的入口服务消息要显示在电视屏幕上,临时存储被分析的入口服务消息。
17.根据权利要求16所述的电视入口服务系统,还包括数字电视应用和个人计算机应用,其中在电视模式是电视观看模式的情况下,从先进先出存储器输出的被分析的入口服务消息被提供给数字电视应用,以便以窗口小部件的形式显示为屏幕显示,以及当电视模式是个人计算机屏幕模式时,从先进先出存储器输出的被分析的入口服务消息被提供给个人计算机应用,以便利用操作系统的应用程序接口显示在消息框中或显示为图标形式。
18.根据权利要求1所述的电视入口服务系统,其中通信服务器模块包括消息帧产生单元,用于针对从消息服务器产生的服务请求和处理消息或用户通告消息产生相应的服务器消息帧格式,以及通过网络把产生的服务器消息帧格式发送给通信客户模块;以及消息分析单元,用于对发自通信客户模块的客户服务消息帧格式进行分析,以及把被分析的服务请求消息提供给消息服务器。
19.一种电视入口服务方法,包括以下步骤当根据用户的请求从客户终端的多个服务应用任何之一产生服务请求消息时,对于每一产生的服务请求消息产生一客户服务消息帧,并通过网络的基于消息的协议把产生的客户服务消息帧发送给服务器终端;通过基于消息的协议在服务器终端接收客户服务消息帧,并分析收到的客户服务消息帧以便提取服务请求消息;产生响应和处理结果消息及用户通告消息,以响应被分析的服务请求消息;根据响应和处理结果消息及用户通告消息产生服务器消息帧,然后通过网络的基于消息的协议把消息帧从服务器终端发送给客户终端;在客户终端接收服务器消息帧,并且分析服务器消息帧,以便把被分析的服务器服务消息提供给多个服务应用中的相应之一或多个;以及根据服务请求消息,执行被提供给服务应用的被分析的服务器服务消息所对应的服务。
20.根据权利要求19所述的电视入口服务方法,其中通过相同的基于消息的协议发送的服务器消息帧和客户服务消息帧具有相同的格式结构。
21.根据权利要求19所述的电视入口服务方法,其中服务器消息帧和客户服务消息帧每一个的格式结构包括消息类型字段,具有用于对在服务器终端与客户终端之间发送和接收的消息的属性进行分类的消息类型信息;服务类型字段,具有用于对电视入口服务类型进行分类的服务类型信息;数据类型字段,具有用于对在服务器终端与客户终端之间发送和接收的数据的类型进行分类的数据类型信息;数据字段,包括在服务器终端与客户终端之间发送和接收的实际数据;以及结果类型字段,具有用于对消息处理结果进行分类的结果类型信息。
22.根据权利要求19所述的电视入口服务方法,还包括步骤把被分析的服务器服务消息临时存储在消息队列中,以及然后当被分析的入口服务消息要显示在电视屏幕上时,把存储的被分析的服务器服务消息传送给相关的服务应用。
23.根据权利要求19所述的电视入口服务方法,还包括以下步骤当被分析的服务器服务消息是要求用户响应的消息或通知用户关于请求的入口的状态的通告消息时,把被分析的服务器服务消息临时存储在先进先出存储器中;以及当被分析的入口服务消息要显示在电视屏幕上时,把存储的被分析的服务器服务消息传送给相关的服务应用。
24.根据权利要求23所述的电视入口服务方法,还包括,当被分析的服务器服务消息要显示在电视屏幕上时当电视模式是电视观看模式时,将被分析的服务器服务消息提供给数字电视应用,以便以窗口小部件的形式将服务器服务消息显示为屏幕显示,以及当电视模式是个人计算机屏幕模式时,将被分析的服务器服务消息提供给个人计算机应用,以便利用操作系统的应用程序接口将服务器服务消息显示在消息框中或显示为图标形式。
全文摘要
一种使用基于消息的协议的电视(TV)入口服务设备和方法,其通过在TV入口服务中提供一致的基于消息的框架,来允许对各种服务项进行管理和控制。更进一步,有可能通过在单个服务之间提供关联工具来实现新的应用,从而通过使TV入口服务的应用程序接口(API)标准化,导致了实现服务器和终端的技术效率,以及灵活服务的实现。
文档编号H04L12/58GK1578277SQ200410062178
公开日2005年2月9日 申请日期2004年7月2日 优先权日2003年7月4日
发明者金永执, 成基演, 姜承美, 韩荣燮 申请人:三星电子株式会社
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1