WO2015161582A1 - Iptv的消息处理方法及装置 - Google Patents

Iptv的消息处理方法及装置 Download PDF

Info

Publication number
WO2015161582A1
WO2015161582A1 PCT/CN2014/083748 CN2014083748W WO2015161582A1 WO 2015161582 A1 WO2015161582 A1 WO 2015161582A1 CN 2014083748 W CN2014083748 W CN 2014083748W WO 2015161582 A1 WO2015161582 A1 WO 2015161582A1
Authority
WO
WIPO (PCT)
Prior art keywords
epg
versions
interface
view
view types
Prior art date
Application number
PCT/CN2014/083748
Other languages
English (en)
French (fr)
Inventor
费立华
谢士昭
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Priority to US15/305,297 priority Critical patent/US20170055037A1/en
Priority to EP14890385.9A priority patent/EP3136674B1/en
Publication of WO2015161582A1 publication Critical patent/WO2015161582A1/zh

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/482End-user interface for program selection
    • H04N21/4821End-user interface for program selection using a grid, e.g. sorted out by channel and broadcast time
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/06Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26291Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for providing content or additional data updates, e.g. updating software modules, stored at the client
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/431Generation of visual interfaces for content selection or interaction; Content or additional data rendering
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/458Scheduling content for creating a personalised stream, e.g. by combining a locally stored advertisement with an incoming stream; Updating operations, e.g. for OS modules ; time-related management operations
    • H04N21/4586Content update operation triggered locally, e.g. by comparing the version of software modules in a DVB carousel to the version stored locally
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643Communication protocols
    • H04N21/64322IP
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85Assembly of content; Generation of multimedia applications
    • H04N21/854Content authoring
    • H04N21/8543Content authoring using a description language, e.g. Multimedia and Hypermedia information coding Expert Group [MHEG], eXtensible Markup Language [XML]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02Standardisation; Integration
    • H04L41/0233Object-oriented techniques, for representation of network management data, e.g. common object request broker architecture [CORBA]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Definitions

  • the present invention relates to the field of communications, and in particular to a message processing method and apparatus for an Internet Protocol TV or Interactive Personal TV (IPTV). Background technique
  • IPTV which is a display terminal such as a television, a computer, and a mobile terminal (such as a mobile phone), and connects a set-top box, a computer, or a mobile terminal (such as a mobile phone) device to the Internet, through the Internet, especially a broadband network, to the TV.
  • Various users such as PCs and mobile terminals provide various real-time and non-real-time multimedia services.
  • the sub-area upgrade method can implement thousands of edge devices in sub-area and batch-to-batch upgrades, and the upgrade process does not need to interrupt services.
  • the upgrade has no impact on user usage, and users are not aware. Minimize and reduce the benefits and operational losses caused by the upgrade to the operator, and ensure a good business experience for the user.
  • a message processing method and apparatus for an IPTV are provided to solve at least the problem that the IPTV batch service upgrade in the related art fails to process the service normally.
  • a message processing method for an IPTV including: acquiring a plurality of electronic program guide (EPG) versions that exist simultaneously; and acquiring corresponding one or more view types according to the multiple EPG versions. And dividing a set of EPGs with the same processing manner into one view type; processing the request messages of the multiple EPG versions according to the one or more view types.
  • the method further includes: classifying one or more EPG versions having the same number of table fields and the same field length in the table structure as one view type.
  • the method further includes: the same type of the table field and the same length of the same field in the table structure
  • the correspondence between multiple EPG versions and their corresponding view types is stored in the Control Point (CP).
  • Obtaining the corresponding one or more view types according to the multiple EPG versions includes: determining corresponding one or more view types according to the multiple EPG versions; reading the one or more from a service database (DB) View type.
  • DB service database
  • the method further includes: acquiring an interface type corresponding to the current request message; determining, according to the interface type, whether to follow the one or more The view type processes the request messages of the plurality of EPG versions.
  • the interface type is a File Transfer Protocol (FTP) interface, Decoding the request message of the plurality of EPG versions by one or more view types;
  • the interface type is a Transmission Control Protocol (TCP) and/or a JavaScript Object Notation (JSON) interface, and directly The EPG version of the request message is processed;
  • the interface type is Hypertext Transfer Protocol (HTTP) and/or Extensible Markup Language (XML) interface, then the type of the request message is converted into a JSON message, and directly Request messages for multiple EPG versions are processed.
  • FTP File Transfer Protocol
  • TCP Transmission Control Protocol
  • JSON JavaScript Object Notation
  • HTML Hypertext Transfer Protocol
  • XML Extensible Markup Language
  • a message processing apparatus for an IPTV including: a first acquiring module, configured to acquire a plurality of EPG versions that exist simultaneously; and a second acquiring module, configured to The EPG version obtains one or more view types, wherein a set of EPG versions with the same processing manner is divided into one view type; and a processing module is set to the plurality of EPG versions according to the one or more view types
  • the request message is processed.
  • the apparatus further includes: a dividing module configured to classify one or more EPG versions having the same number of table fields and the same field length in the table structure as one view type.
  • the device further includes: a storage module, configured to store, in the CP, a correspondence between one or more EPG versions having the same number of table fields and the same field length in the table structure and their corresponding view types.
  • the second obtaining module includes: a determining unit, configured to determine a corresponding one or more view types according to the plurality of EPG versions; and a reading unit configured to read the one or more view types from the service DB .
  • the device further includes: a third obtaining module, configured to acquire an interface type corresponding to the current request message; and a determining module, configured to determine, according to the interface type, whether to select the plurality of EPG versions according to the one or more view types The request message is processed.
  • the determining module includes at least one of the following: a first processing unit, configured to process the request message of the multiple EPG versions according to the one or more view types if the interface type is an FTP interface a second processing unit, configured to directly process the request message of the multiple EPG versions if the interface type is a TCP and/or a JSON interface; and the third processing unit is configured to be at the interface type In the case of an HTTP and/or XML interface, the type of the request message is converted into a JSON message and the request messages of the plurality of EPG versions are processed directly.
  • a plurality of EPG versions that exist at the same time are obtained; and one or more view types are obtained according to the foregoing multiple EPG versions, wherein a set of EPG versions having the same processing manner is divided into one view type;
  • the method for processing the request message of the foregoing multiple EPG versions by the one or more view types solves the problem that the IPTV batch service upgrade fails to process the service in the related art, and the batch service upgrade of the IPTV system is implemented. It provides a technical foundation to minimize and reduce the benefits and operational losses of the upgrade to the operator, ensuring a good business experience for the user.
  • FIG. 1 is a flowchart of a message processing method of an IPTV according to an embodiment of the present invention
  • FIG. 2 is a structural block diagram of a message processing apparatus for an IPTV according to an embodiment of the present invention
  • FIG. 3 is a preferred embodiment according to the present invention.
  • FIG. 4 is a schematic diagram of a division of an agreement number management manner according to a preferred embodiment of the present invention.
  • FIG. 5 is a schematic flow chart of obtaining different synchronization data by two versions of EPG according to a preferred embodiment of the present invention.
  • BEST MODE FOR CARRYING OUT THE INVENTION the present invention will be described in detail with reference to the accompanying drawings. It should be noted that the embodiments in the present application and the features in the embodiments may be combined with each other without conflict.
  • FIG. 1 is a diagram according to an embodiment of the present invention.
  • the method includes the following steps: Step S102: Acquire an electronic product guide (Elec a version of the EPG system is obtained. Step S104: Obtain a corresponding one or more view types according to the foregoing multiple EPG versions, where a group of EPG versions having the same processing manner are divided into one view type; Step S106, The request messages of the plurality of EPG versions are processed according to one or more of the view types described above.
  • the multiple EPG versions that exist at the same time are divided according to the view type, and the request messages of the multiple EPG versions are processed according to the corresponding view type, so that the IPTV system is mainly controlled by the service core network element.
  • Control Point (Control Point, CP for short, service control module in IPTV system) can process the request message normally when multiple EPG versions exist at the same time, which solves the problem of IPTV batch service upgrade in related technologies.
  • the problem of not being able to handle the business normally provides a technical basis for the batch service upgrade of the IPTV system, so as to minimize and reduce the benefits and operational losses caused by the upgrade to the operator, and ensure that the user is given a good Business experience.
  • one or more EPG versions having the same number of table fields and the same field length in the table structure may be classified into one view type. . By dividing the view type in this way, the processing method is more convenient and efficient, and the processing efficiency is high.
  • the number of table fields may be the same and the same field length in the table structure is the same.
  • the correspondence between the one or more EPG versions and their corresponding view types is stored in the CP. Instead, store each view type in the database. Stored in this way, the reading efficiency is high.
  • the manner of obtaining the corresponding one or more view types according to the foregoing multiple EPG versions may be, first, determining one or more corresponding ones according to multiple EPG versions that exist simultaneously.
  • the view type and then read the one or more view types from the business database (DataBase, referred to as DB, business database in the IPTV system).
  • DB business database in the IPTV system.
  • the processing of the request message can be determined according to the interface type. Specifically, before processing the request message of the multiple EPG versions according to the one or more view types, the interface type corresponding to the current request message may be acquired first; and then determining whether to follow one or more according to the interface type.
  • the view types process the request messages of the above multiple EPG versions.
  • the following is the case of determining whether to process the request messages of the multiple EPG versions according to the one or more view types.
  • the following are given in the embodiment, which are not limited to the following:
  • FTP File Transfer Protocol
  • TCP Transmission Control Protocol
  • TCP Transmission Control Protocol
  • JSON JavaScript Object Notation
  • HTML Hypertext Transfer Protocol
  • XML Extensible Markup Language
  • an IPTV message processing apparatus is also provided, which is configured to implement the foregoing embodiments and preferred embodiments, and has not been described again.
  • the term "module" may implement a combination of software and/or hardware of a predetermined function.
  • the apparatus described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware, is also possible and conceivable.
  • 2 is a structural block diagram of a message processing apparatus for an IPTV according to an embodiment of the present invention. As shown in FIG. 2, the apparatus includes: a first obtaining module 22, a second obtaining module 24, and a processing module 26, which are performed on each module.
  • the first obtaining module 22 is configured to obtain a plurality of EPG versions that exist at the same time.
  • the second obtaining module 24 is connected to the first obtaining module 22, and is configured to obtain a corresponding one according to multiple EPG versions acquired by the first obtaining module 22 a plurality of view types, wherein the set of EPGs having the same processing manner is divided into one view type;
  • the processing module 26 is connected to the first obtaining module 22 and the second obtaining module 24, and is configured to be acquired according to the second obtaining module 24.
  • the one or more view types process the request messages of the plurality of EPG versions acquired by the first obtaining module 22.
  • the apparatus may further include: a dividing module 28, connected to the second obtaining module 24, configured to classify one or more EPG versions having the same number of table fields and the same field length in the table structure as one view type .
  • the apparatus may further include: a storage module 30, connected to the second obtaining module 24 and the dividing module 28, configured to set one or more EPG versions with the same number of table fields and the same field length in the table structure The corresponding relationship of the corresponding view type is stored in the CP for the second acquisition module 24 to acquire.
  • the second obtaining module 24 may include: a determining unit 242, configured to determine a corresponding one or more view types according to the plurality of EPG versions; the reading unit 244 is connected to the determining unit 242, and is configured to read from the service DB. Take one or more view types.
  • the device further includes: a third obtaining module 32, configured to acquire an interface type corresponding to the current request message; the determining module 34 is connected to the third obtaining module 32, and is configured to determine, according to the interface type, whether to follow one or more views. The type processes request messages for multiple EPG versions.
  • the determining module 34 may include at least one of the following: the first processing unit 342 is configured to process the request messages of the multiple EPG versions according to one or more view types if the interface type is an FTP interface; The second processing unit 344 is configured to directly process the request messages of the multiple EPG versions in the case that the interface type is the TCP and/or JSON interface; the third processing unit 346 is configured to set the interface type to HTTP and/or XML. In the case of an interface, the type of the request message is converted into a JSON message, and the request messages of multiple EPG versions are processed directly.
  • a method for implementing a sub-area upgrade in an IPTV system is provided, and the interrupted IPTV service can also be upgraded in batches.
  • the edge device may be upgraded in a sub-area or a batch, and the existing IPTV service upgrade must be interrupted by the method and function.
  • the sub-area method and its functions in the IPTV system of the preferred embodiment include the following steps: Step S2: Initiating a network-wide emergency, all users logging in in an emergency mode, and the IPTV system provides services in an emergency state.
  • Step S4 Upgrade the service network element in the central equipment room at the back end of the IPTV service system.
  • Step S6 When the service network element at the back end of the IPTV service system can work normally, the network emergency is closed.
  • FIG. 3 is a schematic structural diagram of implementing a sub-area upgrade in an IPTV according to a preferred embodiment of the present invention. As shown in FIG. 3, the structure includes:
  • DB module The business database module in the IPTV system mainly stores some program data, content data, column data and so on.
  • CP module This module is the core service control module of the IPTV system. It mainly processes various message requests sent by the EPG module and returns corresponding processing messages.
  • EPG module The electronic program list is mainly set to receive various request messages sent by the terminal device, and the message is processed and forwarded to the CP module. And set top box (STB) module and FTP server.
  • STB set top box
  • EPG versions share a view, that is, the view corresponding to the protocol number VI.0, of course, it may be other divisions in actual use.
  • the CP module maintains a correspondence between the version and the protocol number
  • the DB module maintains a view corresponding to all the protocol numbers.
  • compatible CP modules and EPG modules include FTP, HTTP+XML, TCP, and JSON interfaces. The following is an example of the four interfaces to illustrate the technical processing of the CP module compatible with the two different EPG versions.
  • the program data that the user sees on the electronic program list is mainly obtained by the EPG module from the DB module through the CP module.
  • the data synchronization between the EPG module and the CP module is handled by the FTP interface.
  • the EPG version is upgraded from EPGV1.01.02.02 to EPGV1.02.01.03. If the EPG version is upgraded by sub-regional upgrade, there will be cases where EPGV1.01.02.02 and EPGV1.02.01.03 coexist.
  • the CP module can pass.
  • the version before and after the upgrade obtains the corresponding protocol number (that is, the view type, which is numbered VX.0 in the preferred embodiment) is V1.0 and V2.0 respectively, and then reads the corresponding view from the DB module to obtain synchronization data, that is, CP.
  • the two types of view data are obtained, and the EPG obtains the corresponding synchronization data through the FTP interface through the protocol number maintained by the EPG, thereby achieving compatibility.
  • FIG. 5 is a flow chart showing the process of acquiring different synchronization data by two versions of EPG according to a preferred embodiment of the present invention, as shown in FIG. 5. After all the EPGs are upgraded to the new version of EPGV1.02.01.03, you can configure the CP module to obtain only the view with the protocol number of V2.0, so that only one type of synchronization data can be obtained to avoid data redundancy.
  • TCP and/or JSON interface The IPTV system provides users with services such as collections and bookmarks. Users add favorites, add bookmarks, add child locks, apply for personal network recording, etc. on the electronic program list, etc., using TCP and/or JSON interfaces. Processed. The JSON interface sends and receives messages using key-value methods. The length, location, and number of fields are not limited. Therefore, TCP and JSON message processing can support sub-regional upgrade.
  • modules or steps of the present invention can be implemented by a general-purpose computing device, which can be concentrated on a single computing device or distributed over a network composed of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device so that they may be stored in the storage device by the computing device and, in some cases, may be executed in a different order than here.
  • the steps shown or described are either fabricated into individual integrated circuit modules, or a plurality of modules or steps are fabricated as a single integrated circuit module.
  • the invention is not limited to any specific combination of hardware and software. The above is only the preferred embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes can be made to the present invention.
  • an IPTV message processing method and apparatus provided by an embodiment of the present invention have the following beneficial effects: Providing a technical basis for realizing batch service upgrade of an IPTV system, thereby being able to minimize And reduce the benefits and operational losses caused by the upgrade to the operator, ensuring a good business experience for the user.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Human Computer Interaction (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本发明公开了一种IPTV的消息处理方法及装置,其中,该方法包括:获取同时存在的多种EPG版本;根据上述多种EPG版本获取对应的一个或多个视图类型,其中,将处理方式相同的一组EPG版本划分至一个视图类型;依照上述一个或多个视图类型对上述多个EPG版本的请求消息进行处理。通过本发明,解决了相关技术中IPTV分批次业务升级导致无法正常处理业务的问题,为实现IPTV系统的分批次业务升级提供了技术基础,从而能够在最大程度上减少和降低升级对于运营商所造成的利益和营运上的损失,确保给予用户良好的业务体验。

Description

IPTV的消息处理方法及装置 技术领域 本发明涉及通信领域, 具体而言, 涉及一种交互式个人电视(Internet Protocol TV or Interactive Personal TV, 简称为 IPTV) 的消息处理方法及装置。 背景技术
IPTV, 是以电视机、 电脑及移动终端(例如手机)等设备为显示终端, 将机顶盒、 计算机或移动终端 (例如手机) 设备接入到互联网络, 通过互联网络, 特别是宽带网 络, 向 TV、 PC、 移动终端等多种用户提供各种实时、 非实时的多媒体业务。 在 IPTV业务快速发展的今天, 国内外都有数个已发展至几十万甚至是上百万用 户的 IPTV局点。 随着用户量的增加以及运营商为运营需要实现更加完善、 丰富的多 媒体服务以满足用户需求, IPTV系统就需要在原有的业务系统的基础上进行升级来满 足各种各样新需求的实现。 就目前而言, 整个 IPTV系统升级非常复杂、 困难, 涉及 到的边缘设备非常多, 对于上百万用户的 IPTV局点边缘设备就要上千台, 升级起来 不仅耗时而且还需要中断业务, 不仅影响用户体验, 还存在着一定的风险, 如果升级 完成后出现故障, 上千台的边缘设备还存在再次升级的可能性。 分区域升级方法可以实现上千台的边缘设备分区域、 分批次升级, 且升级过程不 需要中断业务, 做到升级对用户使用无影响, 用户无感知。 在最大程度上减少和降低 升级对于运营商所造成的利益和营运上的损失, 确保给予用户良好的业务体验。 综上所述, 如果能够使得 IPTV业务系统升级不需要中断业务, 在用户体验无影 响的情况下实现分批次完成, 这不仅为运营商运营提供了有力的保障, 更为终端用户 使用提供了便捷。 但是, 如果进行分批次升级, 在升级过程中就会有多种业务系统的 版本同时存在, 这就为业务处理带来了非常大的困难。 针对相关技术中 IPTV分批次业务升级导致无法正常处理业务的问题, 目前尚未 提出有效的解决方案。 发明内容 在本发明实施例中, 提供了一种 IPTV的消息处理方法及装置, 以至少解决相关 技术中 IPTV分批次业务升级导致无法正常处理业务的问题。 根据本发明的一个实施例, 提供了一种 IPTV的消息处理方法, 包括: 获取同时 存在的多种电子节目单 (EPG)版本; 根据所述多种 EPG版本获取对应的一个或多个 视图类型, 其中, 将处理方式相同的一组 EPG版本划分至一个视图类型; 依照所述一 个或多个视图类型对所述多个 EPG版本的请求消息进行处理。 在根据所述多种 EPG版本获取对应的一个或多个视图类型之前, 还包括: 将表字 段个数相同且表结构中同一字段长度相同的一种或多种 EPG版本划为一个视图类型。 在将表字段个数相同且表结构中同一字段长度相同的一种或多种 EPG版本划为 一个视图类型之后, 还包括: 将表字段个数相同且表结构中同一字段长度相同的一种 或多种 EPG版本与其对应的视图类型的对应关系存储在控制点 (CP) 中。 根据所述多种 EPG版本获取对应的一个或多个视图类型包括:根据所述多种 EPG 版本确定对应的一个或多个视图类型; 从业务数据库(DB) 中读取所述一个或多个视 图类型。 在依照所述一个或多个视图类型对所述多个 EPG版本的请求消息进行处理之前, 还包括: 获取当前请求消息对应的接口类型; 根据所述接口类型判断是否依照所述一 个或多个视图类型对所述多个 EPG版本的请求消息进行处理。 根据所述接口类型判断是否依照所述一个或多个视图类型对所述多个 EPG版本 的请求消息进行处理包括以下至少之一: 所述接口类型为文件传输协议(FTP)接口, 则依照所述一个或多个视图类型对所述多个 EPG版本的请求消息进行处理;所述接口 类型为传输控制协议 (TCP) 和 /或 JavaScript对象表示法 (JSON) 接口, 则直接对所 述多个 EPG版本的请求消息进行处理; 所述接口类型为超文本传输协议 (HTTP) 和 / 或可扩展标记语言 (XML) 接口, 则将所述请求消息的类型转换成 JSON消息, 并直 接对所述多个 EPG版本的请求消息进行处理。 根据本发明的另一实施例, 还提供了一种 IPTV的消息处理装置, 包括: 第一获 取模块, 设置为获取同时存在的多种 EPG版本; 第二获取模块, 设置为根据所述多种 EPG版本获取对应的一个或多个视图类型,其中,将处理方式相同的一组 EPG版本划 分至一个视图类型; 处理模块, 设置为依照所述一个或多个视图类型对所述多个 EPG 版本的请求消息进行处理。 所述装置还包括: 划分模块, 设置为将表字段个数相同且表结构中同一字段长度 相同的一种或多种 EPG版本划为一个视图类型。 所述装置还包括: 存储模块, 设置为将表字段个数相同且表结构中同一字段长度 相同的一种或多种 EPG版本与其对应的视图类型的对应关系存储在 CP中。 所述第二获取模块包括: 确定单元, 设置为根据所述多种 EPG版本确定对应的一 个或多个视图类型; 读取单元, 设置为从业务 DB中读取所述一个或多个视图类型。 所述装置还包括: 第三获取模块, 设置为获取当前请求消息对应的接口类型; 判 断模块, 设置为根据所述接口类型判断是否依照所述一个或多个视图类型对所述多个 EPG版本的请求消息进行处理。 所述判断模块包括以下至少之一: 第一处理单元, 设置为在所述接口类型为 FTP 接口的情况下,依照所述一个或多个视图类型对所述多个 EPG版本的请求消息进行处 理; 第二处理单元, 设置为在所述接口类型为 TCP和 /或 JSON接口的情况下, 直接对 所述多个 EPG版本的请求消息进行处理; 第三处理单元, 设置为在所述接口类型为 HTTP和 /或 XML接口的情况下, 将所述请求消息的类型转换成 JSON消息, 并直接 对所述多个 EPG版本的请求消息进行处理。 通过本发明实施例, 采用获取同时存在的多种 EPG版本; 根据上述多种 EPG版 本获取对应的一个或多个视图类型, 其中, 将处理方式相同的一组 EPG版本划分至一 个视图类型;依照上述一个或多个视图类型对上述多个 EPG版本的请求消息进行处理 的方式, 解决了相关技术中 IPTV分批次业务升级导致无法正常处理业务的问题, 为 实现 IPTV系统的分批次业务升级提供了技术基础, 从而能够在最大程度上减少和降 低升级对于运营商所造成的利益和营运上的损失, 确保给予用户良好的业务体验。 附图说明 此处所说明的附图用来提供对本发明的进一步理解, 构成本申请的一部分, 本发 明的示意性实施例及其说明用于解释本发明, 并不构成对本发明的不当限定。 在附图 中: 图 1是根据本发明实施例的 IPTV的消息处理方法的流程图; 图 2是根据本发明实施例的 IPTV的消息处理装置的结构框图; 图 3是根据本发明优选实施例的 IPTV中实现分区域升级的结构示意图; 图 4是根据本发明优选实施例的协议号管理方式举例的划分示意图; 图 5是根据本发明优选实施例的两种版本 EPG获取不同同步数据的流程示意图。 具体实施方式 下文中将参考附图并结合实施例来详细说明本发明。 需要说明的是, 在不冲突的 情况下, 本申请中的实施例及实施例中的特征可以相互组合。 在本实施例中, 提供了一种 IPTV的消息处理方法, 图 1是根据本发明实施例的
IPTV的消息处理方法的流程图, 如图 1所示, 该方法包括如下步骤: 步骤 S102, 获取同时存在的多种电子节目单(Electronic Program Guide , 简称为 EPG, IPTV各种业务的索引及导航都是通过 EPG系统来完成的) 版本; 步骤 S104, 根据上述多种 EPG版本获取对应的一个或多个视图类型, 其中, 将 处理方式相同的一组 EPG版本划分至一个视图类型; 步骤 S106, 依照上述一个或多个视图类型对上述多个 EPG版本的请求消息进行 处理。 本实施例通过上述步骤, 将同时存在的多种 EPG版本按照视图类型进行划分, 并 根据对应的视图类型对上述多个 EPG版本的请求消息进行处理, 使得 IPTV系统 (主 要由业务核心网元控制点 (Control Point, 简称为 CP, IPTV系统中的业务控制模块) 处理)能够在同时存在多种 EPG版本的情况下, 正常对请求消息进行处理, 解决了相 关技术中 IPTV分批次业务升级导致无法正常处理业务的问题,为实现 IPTV系统的分 批次业务升级提供了技术基础, 从而能够在最大程度上减少和降低升级对于运营商所 造成的利益和营运上的损失, 确保给予用户良好的业务体验。 优选地, 在根据所述多种 EPG版本获取对应的一个或多个视图类型之前, 可以将 表字段个数相同且表结构中同一字段长度相同的一种或多种 EPG版本划为一个视图 类型。 通过这种方式划分视图类型, 处理方式更为方便快捷, 处理效率高。 优选地,在将表字段个数相同且表结构中同一字段长度相同的一种或多种 EPG版 本划为一个视图类型之后, 可以将表字段个数相同且表结构中同一字段长度相同的一 种或多种 EPG版本与其对应的视图类型的对应关系存储在 CP中。 而将各个视图类型 存储在数据库中。 通过这种方式存储, 读取效率高。 优选地, 在读取视图类型的过程中, 根据上述多种 EPG版本获取对应的一个或多 个视图类型的方式通常可以是,先根据同时存在的多种 EPG版本确定对应的一个或多 个视图类型, 然后从业务数据库(DataBase, 简称为 DB, IPTV系统中的业务数据库) 中读取该一个或多个视图类型。 作为一种优选实施方式, 由于有些接口对应的解析类型对于不同 EPG版本的表字 段个数和表结构中同一字段长度在解析过程中没有区别,因此不同 EPG版本对于这些 接口的影响就会很小甚至没有影响, 因此为提高处理效率, 可以根据接口类型确定请 求消息的处理方式。具体地, 在依照所述一个或多个视图类型对所述多个 EPG版本的 请求消息进行处理之前, 还可以先获取当前请求消息对应的接口类型; 然后根据接口 类型判断是否依照上述一个或多个视图类型对上述多个 EPG版本的请求消息进行处 理。 优选地,根据接口类型判断是否依照上述一个或多个视图类型对多个 EPG版本的 请求消息进行处理的具体情况, 在本实施例中给出了以下几种, 当然并不限于以下几 种: 当接口类型为文件传输协议 (File Transfer Protocol, 简称为 FTP) 接口时, 可以 依照视图类型对多个 EPG版本的请求消息进行处理; 当接口类型为传输控制协议 (Transmission Control Protocol, 简称为 TCP) 禾口 /或
JavaScript对象表示法 (JavaScript Object Notation, 简称为 JSON) 接口时, 由于这两 种接口类型在解析过程中, 不同的 EPG版本对其没有影响, 因此可以直接按照正常方 式对多个 EPG版本的请求消息进行处理; 当接口类型为超文本传输协议 (Hypertext Transfer Protocol, 简称为 HTTP), 浏 览器与服务器之间通信的规则) 和 /或可扩展标记语言 (Extensible Markup Language, 简称为 XML)接口时, 如果直接使用接口的常规解析方式会解析失败, 而将解析方式 转换成 JSON之后, 各个 EPG版本就对其没有影响了, 因此可以将请求消息的类型转 换成 JSON消息, 然后直接按照正常方式对多个 EPG版本的请求消息进行处理。 在本实施例中, 还提供了一种 IPTV的消息处理装置, 该装置设置为实现上述实 施例及优选实施方式, 已经进行过说明的不再赘述。 如以下所使用的, 术语 "模块" 可以实现预定功能的软件和 /或硬件的组合。尽管以下实施例所描述的装置较佳地以软 件来实现, 但是硬件, 或者软件和硬件的组合的实现也是可能并被构想的。 图 2是根据本发明实施例的 IPTV的消息处理装置的结构框图, 如图 2所示, 该 装置包括: 第一获取模块 22、 第二获取模块 24和处理模块 26, 下面对各个模块进行 详细说明: 第一获取模块 22, 设置为获取同时存在的多种 EPG版本; 第二获取模块 24, 与 第一获取模块 22相连,设置为根据第一获取模块 22获取的多种 EPG版本获取对应的 一个或多个视图类型, 其中, 将处理方式相同的一组 EPG版本划分至一个视图类型; 处理模块 26, 与第一获取模块 22和第二获取模块 24相连, 设置为依照第二获取模块 24获取的一个或多个视图类型对第一获取模块 22获取的多个 EPG版本的请求消息进 行处理。 优选地, 该装置还可以包括: 划分模块 28, 与第二获取模块 24相连, 设置为将 表字段个数相同且表结构中同一字段长度相同的一种或多种 EPG版本划为一个视图 类型。 优选地, 该装置还可以包括: 存储模块 30, 与第二获取模块 24和划分模块 28相 连,设置为将表字段个数相同且表结构中同一字段长度相同的一种或多种 EPG版本与 其对应的视图类型的对应关系存储在 CP中, 以便第二获取模块 24获取。 优选地, 第二获取模块 24可以包括: 确定单元 242, 设置为根据多种 EPG版本 确定对应的一个或多个视图类型; 读取单元 244, 与确定单元 242相连, 设置为从业 务 DB中读取一个或多个视图类型。 优选地, 上述装置还包括: 第三获取模块 32, 设置为获取当前请求消息对应的接 口类型; 判断模块 34, 与第三获取模块 32相连, 设置为根据接口类型判断是否依照 一个或多个视图类型对多个 EPG版本的请求消息进行处理。 优选地, 判断模块 34可以包括以下至少之一: 第一处理单元 342, 设置为在接口 类型为 FTP接口的情况下, 依照一个或多个视图类型对多个 EPG版本的请求消息进 行处理; 第二处理单元 344, 设置为在接口类型为 TCP和 /或 JSON接口的情况下, 直 接对多个 EPG版本的请求消息进行处理; 第三处理单元 346, 设置为在接口类型为 HTTP和 /或 XML接口的情况下, 将请求消息的类型转换成 JSON消息, 并直接对多 个 EPG版本的请求消息进行处理。 下面结合优选实施例和附图对上述实施例及优选实施方式的实现过程进行详细说 明。 在以下优选实施例中, 提供了一种 IPTV系统中分区域升级的实现方法, 中断 IPTV服务也可以分批次升级。 在本优选实施例中提供的 IPTV系统中分区域升级的实现方法,在 IPTV系统升级 时边缘设备可采用分区域、 分批次升级, 通过该方法和功能来解决现有的 IPTV业务 升级必须中断业务, 且要花费较长时间且存在较大风险的现状。 本优选实施例的 IPTV系统中这种分区域方法和其功能, 包括以下步骤: 步骤 S2: 启动全网应急, 所有用户以应急模式登陆, IPTV系统在应急状态下提 供服务。 步骤 S4: 升级 IPTV业务系统后端的中心机房内的业务网元。 步骤 S6: 在 IPTV业务系统后端的业务网元能够正常工作的情况下, 关闭全网应 急。 步骤 S8: 将 IPTV系统中的边缘 EPG设备 (例如, 共有一千台 EPG设备) 按地 域特性进行划分, 升级其中的 50台, 此时将所有的终端用户负载到未升级的 950台 EPG上(通常升级可以放在凌晨进行, 在线用户较少, 950台 EPG同样可以满足负载 性能)。 这 50台 EPG升级成功且经过测试功能正常后, 可以将用户再负载回来。 此时 现网会存在已升级 EPG设备和未升级 EPG设备并存的情况。 步骤 S10: 在观察已升级 EPG—切正常后再逐歩升级余下的 950台 EPG。 本优选实施例中 IPTV业务核心网元 CP模块需要兼容至少有新旧两种不同的 EPG 版本(当然也可以存在多种 EPG版本), 需要能够处理至少两个不同 EPG版本的接口 请求并返回各自版本定义的字段数据, 包括但不限于登录, 点播、 直播、 系统录制、 时移电视、 收藏、 书签等媒体服务。 下面结合附图对本优选实施例进行更为详细的说明。 图 3是根据本发明优选实施例的 IPTV中实现分区域升级的结构示意图, 如图 3 所示, 该结构包括:
DB模块: IPTV系统中的业务数据库模块, 主要存放一些节目数据、 内容数据、 栏目数据等等。 CP模块:该模块为 IPTV系统核心的业务控制模块,主要处理 EPG模块发送的各 类消息请求并返回对应的处理消息。 EPG模块: 电子节目单, 主要设置为接收终端设备发送的各种请求消息, 并将消 息处理后转发给 CP模块。 以及机顶盒 (Set Top Box, 简称为 STB) 模块和 FTP服务器。 下面将以 EPG版本仅有新旧两种为例进行重点介绍, 以说明 CP模块兼容新旧两 种不同的 EPG版本的技术处理。 当前 EPG版本和未来要升级的 EPG版本, 不单指版 本号的变更, 它可以存在至少以下情况: 新旧版本的表字段个数的增加或者减少; 新 旧版本的表结构中某字段长度的增加或者减少。 本优选实施例中采用协议号(即上文中的视图类型)的管理方式对两种不同的 EPG 版本进行分类管理, 协议号的管理方式是指将若干个没有对视图进行较大改动的相邻 版本进行分类管理, 图 4是根据本发明优选实施例的协议号管理方式举例的划分示意 图, 如图 4 所示, 即 EPGV1.01.01.01、 EPGV1.01.01.02 EPGV1.01.01.03 EPGV1.01.02.01、 EPGV1.01.02.02这几个 EPG版本共用一个视图, 即协议号为 VI.0 对应的视图, 当然在实际使用过程中也可能是其他划分方式。 在本优选实施例中, CP 模块维护版本与协议号之间的对应关系,而 DB模块则维护所有的协议号对应的视图。 目前而言兼容 CP模块和 EPG模块之间包括 FTP、 HTTP+XML、 TCP、 JSON四 种接口。 下面则以这 4个接口为例分别阐述 CP模块兼容新旧两种不同的 EPG版本的 技术处理。
FTP接口: 用户在电子节目单上看到的节目数据等, 主要是 EPG模块通过 CP模 块从 DB模块获取的, EPG模块与 CP模块之间的数据同步就是采用 FTP接口进行处 理的。 假设 EPG版本从 EPGV1.01.02.02升级到 EPGV1.02.01.03, 采用分区域升级方 式升级 EPG版本就会存在 EPGV1.01.02.02、 EPGV1.02.01.03两种版本共存的情况, CP模块可以通过升级前后的版本获取对应的协议号(即视图类型,本优选实施例中以 VX.0编号)分别为 V1.0和 V2.0, 再从 DB模块读取对应的视图获取同步数据, 即 CP 获取 2种视图数据, EPG再通过各自维护的协议号通过 FTP接口获取对应的同步数据, 从而实现兼容。图 5是根据本发明优选实施例的两种版本 EPG获取不同同步数据的流 程示意图, 如图 5所示。 当所有的 EPG都升级至新版本 EPGV1.02.01.03后, 可通过 配置使得 CP模块只获取协议号为 V2.0的视图, 从而只获取一种同步数据, 避免出现 数据的冗余。
TCP和 /或 JSON接口: IPTV系统为用户提供收藏、 书签等服务, 用户在电子节 目单上进行添加收藏、 添加书签、 添加童锁、 申请个人网络录制等等都是采用 TCP和 /或 JSON接口进行处理的。 JSON接口是采用 key-value的方式发送和接收消息, 因其 不区分长度、 位置、 字段个数限制, 故 TCP、 JSON方式的消息处理可以支持分区域 升级的方式。
HTTP+XML接口: IPTV系统为用户提供收藏、 书签等服务, 用户在查询收藏列 表、 书签列表, 用户订购的按次产品列表时采用 HTTP+XML 的方式进行处理。 EPG 获取返回的 HTTP消息后进行解析并转化为 map组, 再进一步转化为 JSON、 直接入 EPG的内存库、转化为 decorator的方式返回终端, 也就是说如果其中的某个字段长度 或者位置变化对终端的数据读取没有影响, 比如说 EPGV1.01.02.02的某表有三个字段 A、 B、 C, JSON的处理模式可简单描述为 A=l, B=2, C=3 ; 而 EPGV1.02.01.03的该 表增加了一个字段 D, 那么 JSON的处理模式就为 A=l, B=2, C=3, D=4; 当有两种 EPG版本共存的时候, 老版本只关心 A、 B、 C, 新版本关心 A、 B、 C、 D, 所以就可 以兼容两种消息格式,如果使用 XML方式就会解析失败,所以将 HTTP+XML的方式 转换成 JSON消息就可以支持分区域升级的情况。 通过本优选实施例的方案, 能够实现在 IPTV业务系统升级时, 不影响用户使用, 在用户拥有良好业务体验的同时分区域、 分批次地完成整个系统的升级, 它相对之前 的升级方式更加安全、 更加灵活, 为用户和运营商提供了强有力的保障。 在另外一个实施例中, 还提供了一种软件, 该软件用于执行上述实施例及优选实 施例中描述的技术方案。 在另外一个实施例中, 还提供了一种存储介质, 该存储介质中存储有上述软件, 该存储介质包括但不限于光盘、 软盘、 硬盘、 可擦写存储器等。 显然, 本领域的技术人员应该明白, 上述的本发明的各模块或各步骤可以用通用 的计算装置来实现, 它们可以集中在单个的计算装置上, 或者分布在多个计算装置所 组成的网络上, 可选地, 它们可以用计算装置可执行的程序代码来实现, 从而可以将 它们存储在存储装置中由计算装置来执行, 并且在某些情况下, 可以以不同于此处的 顺序执行所示出或描述的步骤, 或者将它们分别制作成各个集成电路模块, 或者将它 们中的多个模块或步骤制作成单个集成电路模块来实现。 这样, 本发明不限制于任何 特定的硬件和软件结合。 以上所述仅为本发明的优选实施例而已, 并不用于限制本发明, 对于本领域的技 术人员来说, 本发明可以有各种更改和变化。 凡在本发明的精神和原则之内, 所作的 任何修改、 等同替换、 改进等, 均应包含在本发明的保护范围之内。 工业实用性 如上所述, 本发明实施例提供的一种 IPTV的消息处理方法及装置, 具有以下有 益效果: 为实现 IPTV系统的分批次业务升级提供了技术基础, 从而能够在最大程度 上减少和降低升级对于运营商所造成的利益和营运上的损失, 确保给予用户良好的业 务体验。

Claims

权 利 要 求 书
1. 一种交互式个人电视 IPTV的消息处理方法, 包括: 获取同时存在的多种电子节目单 EPG版本;
根据所述多种 EPG版本获取对应的一个或多个视图类型,其中, 将处理方 式相同的一组 EPG版本划分至一个视图类型; 依照所述一个或多个视图类型对所述多个 EPG版本的请求消息进行处理。
2. 根据权利要求 1所述的方法, 其中, 在根据所述多种 EPG版本获取对应的一个 或多个视图类型之前, 还包括: 将表字段个数相同且表结构中同一字段长度相同的一种或多种 EPG版本 划为一个视图类型。
3. 根据权利要求 2所述的方法, 其中, 在将表字段个数相同且表结构中同一字段 长度相同的一种或多种 EPG版本划为一个视图类型之后, 还包括: 将表字段个数相同且表结构中同一字段长度相同的一种或多种 EPG版本 与其对应的视图类型的对应关系存储在控制点 CP中。
4. 根据权利要求 1至 3中任一项所述的方法, 其中, 根据所述多种 EPG版本获取 对应的一个或多个视图类型包括: 根据所述多种 EPG版本确定对应的一个或多个视图类型;
从业务数据库 DB中读取所述一个或多个视图类型。
5. 根据权利要求 1至 3中任一项所述的方法, 其中, 在依照所述一个或多个视图 类型对所述多个 EPG版本的请求消息进行处理之前, 还包括: 获取当前请求消息对应的接口类型;
根据所述接 Π类型判断是否依照所述一个或多个视图类型对所述多个 EPG 版本的请求消息进行处理。
6. 根据权利要求 5所述的方法, 其中, 根据所述接口类型判断是否依照所述一个 或多个视图类型对所述多个 EPG版本的请求消息进行处理包括以下至少之一: 所述接口类型为文件传输协议 FTP接口, 则依照所述一个或多个视图类型 对所述多个 EPG版本的请求消息进行处理;
所述接口类型为传输控制协议 TCP和 /或 JavaScript对象表示法 JSON接口, 则直接对所述多个 EPG版本的请求消息进行处理;
所述接口类型为超文本传输协议 HTTP和 /或可扩展标记语言 XML接口, 则将所述请求消息的类型转换成 JSON消息,并直接对所述多个 EPG版本的请 求消息进行处理。
7. 一种交互式个人电视 IPTV的消息处理装置, 包括: 第一获取模块, 设置为获取同时存在的多种电子节目单 EPG版本; 第二获取模块,设置为根据所述多种 EPG版本获取对应的一个或多个视图 类型, 其中, 将处理方式相同的一组 EPG版本划分至一个视图类型; 处理模块,设置为依照所述一个或多个视图类型对所述多个 EPG版本的请 求消息进行处理。
8. 根据权利要求 7所述的装置, 其中, 所述装置还包括: 划分模块, 设置为将表字段个数相同且表结构中同一字段长度相同的一种 或多种 EPG版本划为一个视图类型。
9. 根据权利要求 8所述的装置, 其中, 所述装置还包括: 存储模块, 设置为将表字段个数相同且表结构中同一字段长度相同的一种 或多种 EPG版本与其对应的视图类型的对应关系存储在控制点 CP中。
10. 根据权利要求 7至 9中任一项所述的装置, 其中, 所述第二获取模块包括: 确定单元, 设置为根据所述多种 EPG版本确定对应的一个或多个视图类 型;
读取单元, 设置为从业务数据库 DB中读取所述一个或多个视图类型。
11. 根据权利要求 7至 9中任一项所述的装置, 其中, 所述装置还包括: 第三获取模块, 设置为获取当前请求消息对应的接口类型;
判断模块, 设置为根据所述接口类型判断是否依照所述一个或多个视图类 型对所述多个 EPG版本的请求消息进行处理。
2. 根据权利要求 11所述的装置, 其中, 所述判断模块包括以下至少之一: 第一处理单元,设置为在所述接口类型为文件传输协议 FTP接口的情况下, 依照所述一个或多个视图类型对所述多个 EPG版本的请求消息进行处理; 第二处理单元, 设置为在所述接口类型为传输控制协议 TCP 和 /或 JavaScript对象表示法 JSON接口的情况下, 直接对所述多个 EPG版本的请求 消息进行处理;
第三处理单元,设置为在所述接口类型为超文本传输协议 HTTP和 /或可扩 展标记语言 XML接口的情况下, 将所述请求消息的类型转换成 JSON消息, 并直接对所述多个 EPG版本的请求消息进行处理。
PCT/CN2014/083748 2014-04-22 2014-08-05 Iptv的消息处理方法及装置 WO2015161582A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US15/305,297 US20170055037A1 (en) 2014-04-22 2014-08-05 Methods and devices for processing messages of iptv
EP14890385.9A EP3136674B1 (en) 2014-04-22 2014-08-05 Method and device for processing message of iptv

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201410164301.8 2014-04-22
CN201410164301.8A CN105024974B (zh) 2014-04-22 2014-04-22 Iptv的消息处理方法及装置

Publications (1)

Publication Number Publication Date
WO2015161582A1 true WO2015161582A1 (zh) 2015-10-29

Family

ID=54331680

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2014/083748 WO2015161582A1 (zh) 2014-04-22 2014-08-05 Iptv的消息处理方法及装置

Country Status (4)

Country Link
US (1) US20170055037A1 (zh)
EP (1) EP3136674B1 (zh)
CN (1) CN105024974B (zh)
WO (1) WO2015161582A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107172495B (zh) * 2017-04-26 2020-01-31 青岛海信电器股份有限公司 针对电子节目指南epg的视图生成方法及智能电视
CN108683541A (zh) * 2018-05-21 2018-10-19 宁波三星医疗电气股份有限公司 一种基于无线公网的终端升级方法
CN114827729B (zh) * 2022-05-07 2023-10-20 烽火通信科技股份有限公司 一种epg上线检测方法、装置及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101710934A (zh) * 2009-11-25 2010-05-19 中兴通讯股份有限公司 一种机顶盒版本升级的方法及系统
CN102291616A (zh) * 2011-09-03 2011-12-21 四川公用信息产业有限责任公司 Iptv终端管理系统
US8347333B1 (en) * 2003-08-13 2013-01-01 The Directv Group, Inc. Modified electronic program guide

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5760821A (en) * 1995-06-07 1998-06-02 News America Publications, Inc. Electronic program guide schedule localization system and method
US5999947A (en) * 1997-05-27 1999-12-07 Arkona, Llc Distributing database differences corresponding to database change events made to a database table located on a server computer
EP1234451B1 (en) * 1999-10-22 2003-05-07 General Instrument Corporation Method and apparatus for managing multiple applications in large scale networks
CN1391765A (zh) * 1999-10-22 2003-01-15 通用仪器公司 在大型网络中管理多种应用程序的方法和装置
US20010054112A1 (en) * 2000-01-26 2001-12-20 Lida Nobakht Channel-based internet network for a satellite system
US20030088420A1 (en) * 2001-07-10 2003-05-08 Koninklijke Philips Electronics N.V. Electronic program guide for processing content-related information configured using a reference information model
KR20060056075A (ko) * 2004-11-19 2006-05-24 엘지전자 주식회사 Tv 시스템 소프트웨어 업그레이드 방법
US20070239841A1 (en) * 2006-03-31 2007-10-11 Tandberg Television Americas Systems and methods for distributing software to a host device in a cable system
US9071859B2 (en) * 2007-09-26 2015-06-30 Time Warner Cable Enterprises Llc Methods and apparatus for user-based targeted content delivery
CN101179429B (zh) * 2007-12-03 2011-09-21 中兴通讯股份有限公司 一种配置文件的远程展示和实时编辑方法
US8983365B2 (en) * 2007-12-21 2015-03-17 Ibiquity Digital Corporation Systems and methods for communicating and rendering electronic program guide information via digital radio broadcast transmission
CN101883227B (zh) * 2009-05-05 2013-04-24 百视通网络电视技术发展有限责任公司 支持多标准和多终端的电子节目指南(epg)系统及其实现方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8347333B1 (en) * 2003-08-13 2013-01-01 The Directv Group, Inc. Modified electronic program guide
CN101710934A (zh) * 2009-11-25 2010-05-19 中兴通讯股份有限公司 一种机顶盒版本升级的方法及系统
CN102291616A (zh) * 2011-09-03 2011-12-21 四川公用信息产业有限责任公司 Iptv终端管理系统

Also Published As

Publication number Publication date
EP3136674B1 (en) 2019-10-09
CN105024974B (zh) 2019-08-27
CN105024974A (zh) 2015-11-04
EP3136674A4 (en) 2017-04-19
EP3136674A1 (en) 2017-03-01
US20170055037A1 (en) 2017-02-23

Similar Documents

Publication Publication Date Title
TWI602415B (zh) 用於受遞送媒體之彈性快取的方法及裝置
JP6093482B2 (ja) 携帯端末で検索結果を表示する方法及び装置
AU2018205094A1 (en) Application discovery
US20190243442A1 (en) Knowledge base in virtual mobile management
US20020032754A1 (en) Method and apparatus for profiling in a distributed application environment
US20080127257A1 (en) System and method for viewing a TV program guide on a mobile device background
US11310066B2 (en) Method and apparatus for pushing information
CN102761532B (zh) 网络视频的信息处理系统和方法
CN103268319A (zh) 一种基于网页的云浏览器
WO2011076146A1 (zh) 下载应用数据的方法、数字电视接收终端及系统
CN105307019B (zh) 数字电视接收机功能调用的方法
CN105704562B (zh) 一种网络电视云服务平台的多版本兼容方法及装置
CN111400777A (zh) 一种网络存储系统、用户认证方法、装置及设备
US11240562B1 (en) Set-top box reboot and polling tool
EP2618297A1 (en) Operation information generation device
WO2015161582A1 (zh) Iptv的消息处理方法及装置
CN112243158B (zh) 媒体文件处理方法、装置、计算机可读介质及电子设备
US20120331096A1 (en) Telecommunications terminal, broadcast receiving terminal and computer program
CN103905496A (zh) 一种图片下载方法及装置
CN113596087A (zh) 应用升级方法、装置及计算机可读存储介质
US20150293914A1 (en) Multimedia information processing method, multimedia apparatus, and multimedia network system
CN103442256A (zh) 一种基于html5实现电子节目菜单的方法及系统
CN116260994A (zh) 纠错方法、装置、可读存储介质及电子设备
CN113438313B (zh) 视频续播处理方法、相关装置及可读存储介质
CN103685548A (zh) 内容传送网络的数据处理方法与系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14890385

Country of ref document: EP

Kind code of ref document: A1

REEP Request for entry into the european phase

Ref document number: 2014890385

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 15305297

Country of ref document: US

Ref document number: 2014890385

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE