CN103067779A - 机顶盒应用程序的更新方法及系统 - Google Patents
机顶盒应用程序的更新方法及系统 Download PDFInfo
- Publication number
- CN103067779A CN103067779A CN2012105628179A CN201210562817A CN103067779A CN 103067779 A CN103067779 A CN 103067779A CN 2012105628179 A CN2012105628179 A CN 2012105628179A CN 201210562817 A CN201210562817 A CN 201210562817A CN 103067779 A CN103067779 A CN 103067779A
- Authority
- CN
- China
- Prior art keywords
- top box
- application
- type
- upgrading
- information
- Prior art date
- Legal status (The legal status 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 status listed.)
- Granted
Links
Images
Landscapes
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Stored Programmes (AREA)
Abstract
本发明公开了一种机顶盒应用程序的更新方法及系统，机顶盒应用程序的更新方法包括：服务器接收机顶盒的前端下发的传输流，传输流的信息包括机顶盒的应用更新表；机顶盒监测服务器的应用更新表，并判断应用更新表中描述标签符取值是否正确；如果是，则判断机顶盒的应用ID、版本号和芯片ID是否符合升级要求；如果是，则选择性地采用网络路径和广播路径两者中的至少一种路径方式升级机顶盒。通过上述方式，本发明的机顶盒应用程序的更新方法及系统能够使得用户通过网络路径或广播路径升级机顶盒应用程序。
Description
技术领域
本发明涉及机顶盒领域，特别是涉及一种机顶盒应用程序的更新方法及系统。
背景技术
目前许多机顶盒的前端有更新升级信息时，无论是有权限的还是没权限的，用户都可以任意更新机顶盒应用程序，不利于运营商对前端资源的管理。
而传统的机顶盒应用程序的更新方法只通过网络路径升级，当网络拥塞或者断网的情况时，机顶盒应用程序的更新将被限制或者中断，不能选择性更新，其升级方式单一。
综上所述，有必要提供一种机顶盒应用程序的更新方法及系统以解决上述问题。
发明内容
本发明主要解决的技术问题是提供一种机顶盒应用程序的更新方法及系统，能够使得用户通过网络路径或广播路径升级机顶盒应用程序。
为解决上述技术问题，本发明采用的一个技术方案是：提供一种机顶盒应用程序的更新方法，方法包括：服务器接收机顶盒的前端下发的传输流，传输流的信息包括机顶盒的应用更新表；机顶盒监测服务器的应用更新表，并判断应用更新表中描述标签符取值是否正确；如果是，则判断机顶盒的应用ID、版本号和芯片ID是否符合升级要求；如果是，则选择性地采用网络路径和广播路径两者中的至少一种路径方式升级机顶盒。
其中，在判断机顶盒的应用ID、版本号和芯片ID符合升级要求的步骤之后包括：通过应用更新表中的应用更新类型符数据结构来判断机顶盒采用的更新类型；如果应用更新类型取值为第一更新类型值时，则机顶盒采用广播路径进行升级；如果应用更新类型取值为第二更新类型值时，则机顶盒采用网络路径进行升级；如果应用更新类型取值为第三更新类型值时，则机顶盒同时采用广播路径和网络路径进行升级。
其中，在机顶盒采用广播路径进行升级的步骤后包括：通过应用更新表中的应用更新类型符数据结构来判断机顶盒升级的数据封装类型；如果封装类型取值为第一封装类型值时，则机顶盒升级的数据封装类型为自定义协议封装；如果封装类型取值为第二封装类型值时，则机顶盒升级的数据封装类型为DSM-CC OC协议封装。
其中，在采用自定义协议封装的步骤后包括：通过应用更新表中的应用描述符数据结构来判断机顶盒更新的信息数据类型；如果信息类型取值为第一信息类型值时，则机顶盒更新的信息数据类型为文本描述类型；如果信息类型取值为第二信息类型值时，则机顶盒更新的信息数据类型为图片描述类型。
其中，应用更新表的数据结构包括有应用更新段、应用更新描述符、应用数据段、应用描述符、图片数据段，且在应用更新描述符中设置描述标签符。
为解决上述技术问题，本发明采用的另一个技术方案是：提供一种机顶盒应用程序的更新系统，更新系统包括服务器和至少一机顶盒，其中：服务器，用于接收机顶盒前端下发的应用更新表；机顶盒，用于监测服务器的应用更新表，并根据应用更新表判断机顶盒是否符合升级要求，其中：机顶盒判断应用更新表中的应用更新描述符取值是否正确；如果是，则判断机顶盒的应用ID、版本号和芯片ID是否符合升级要求；如果是，则选择性地采用网络路径和广播路径两者中的至少一种路径方式升级机顶盒。
其中，机顶盒包括：检测系统，用于检测机顶盒是否有升级的信息；升级系统，用于升级机顶盒应用程序的信息，其中，检测系统检测到机顶盒有升级信息后，升级系统更新机顶盒的升级信息。
其中，检测系统包括：版本信息模块，用于监测机顶盒的升级信息，并判断升级信息对应的应用程序和判断应用版本对应的升级版本；权限判断模块，用于判断机顶盒用户端是否有升级权限；更新类型模块，用于判断机顶盒采用的更新类型；封装类型模块，用于判断机顶盒升级的数据封装类型；信息类型模块，用于判断机顶盒更新的信息数据类型。
其中，升级系统包括：广播协议处理模块，用于进行广播路径升级；宽带协议处理模块，用于进行网络路径升级；自定义模块，用于采用自定义协议进行封装；DSM-CC OC模块，用于采用DSM-CC OC协议进行封装；信息提示模块，用于获取升级信息的信息类型的提示；应用更新模块，用于升级应用程序。
其中，应用更新表的数据结构包括有应用更新段、应用更新描述符、应用数据段、应用描述符、图片数据段，且在应用更新描述符中设置描述标签符。
本发明的有益效果是：区别于现有技术的情况，本发明的机顶盒应用程序的更新方法及系统通过监测服务器的应用更新表，并判断机顶盒的应用ID、版本号和芯片ID是否符合升级要求，如果是，则有权限的用户可以采用网络路径方式升级机顶盒、采用广播路径方式升级机顶盒或采用网络路径方式和广播路径方式共同升级机顶盒，能够解决机顶盒应用程序升级方式中单一采用网络路径升级的问题，有效帮助运营商对前端资源的管理，可以针对部分用户进行升级，对于没有权限的用户不给予升级。
附图说明
图1是本发明机顶盒应用程序的更新方法的第一实施例的工作流程示意图；
图2是本发明机顶盒应用程序的更新方法的第二实施例的工作流程示意图；
图3是本发明机顶盒应用程序的更新系统的实施例的结构示意图；
图4是本发明机顶盒应用程序的更新系统的机顶盒的结构示意图；
图5是机顶盒的检测系统和升级系统的结构示意图；
图6是图5中的宽带协议处理模块的结构示意图；
图7是图5中的广播协议处理模块的结构示意图；
图8是图5中的应用更新模块的结构示意图。
具体实施方式
下面结合附图和实施方式对本发明进行详细说明。
如图1所示，图1是本发明机顶盒应用程序的更新方法的第一实施例的工作流程示意图。机顶盒应用程序的更新方法包括以下步骤：
步骤S101：服务器接收机顶盒的前端下发的传输流，传输流的信息包括机顶盒的应用更新表。
其中，机顶盒的前端可通过广播路径或网络路径下发传输流。当然，在前端资源都比较充沛的情况下，可以通过广播路径和网络路径共同下发传输流。传输流封装有机顶盒的应用更新表及其附属信息。
步骤S102：机顶盒监测服务器的应用更新表，并判断应用更新表中描述标签符取值是否正确。
其中，机顶盒监测服务器的应用更新表时，会到应用更新表中的应用更新描述符数据结构判断描述标签符取值是否为‘0xCE’。
步骤S103：如果是，则判断机顶盒的应用ID、版本号和芯片ID是否符合升级要求。
其中，在机顶盒处于工作状态时，同时会有多个应用程序工作。其中每个应用程序对应一个应用ID。机顶盒应用程序的更新只是相对各别应用程序更新，并不是所有的应用程序都更新。如果一个应用程序要更新升级，则需要对其对应的应用ID进行判断。如果应用ID判断正确，则应用ID对应的应用程序更新升级。
应用程序对应有新版本和旧版本。应用程序每更新一次，其对应的版本号都不同。版本号能使用户了解所使用的应用程序是否为最新的版本。其中最新版本所提供的功能与设施都与旧的不同。
进一步的，通过机顶盒芯片ID能够判断机顶盒所使用的芯片类型，可选择性对使用同一款芯片ID的机顶盒进行设置升级权限。当然，还可以通过机顶盒序列号、智能卡号、用户ID或者其他用户相关数据信息对用户端进行设置升级权限。当有应用程序要更新时，需要判断对应的用户ID、对应的机顶盒序列号或对应的智能卡号是否有升级权限。在判断有权限后才能升级对应的应用程序。能够做到运营商针对有权限的部分或者个别用户进行升级应用程序。对于那些没有权限的用户，如没缴费等，运营商可不给予升级。从而使得运营商从之前的被动地位变成主动，方便运营商对资源的管理。
步骤S104：如果是，则选择性地采用网络路径和广播路径两者中的至少一种路径方式升级机顶盒。
其中，用户端有权限升级时，用户可以选择网络路径、广播路径或者网络路径和广播路径一起升级机顶盒。当网络拥塞的时候，可以采用广播路径升级机顶盒对应的应用程序。在广播带宽不足时可采用网络路径升级机顶盒对应的应用程序。当然，在前端资源都比较充沛的情况下，可采用网络路径和广播路径一起升级机顶盒对应的应用程序。
在本实施例中，应用更新表为自定义的，其数据结构包括有应用更新段、应用更新描述符、应用数据段、应用描述符、图片数据段。如表一所示：
表一应用更新表的数据结构
其中，应用更新段数据结构的具体程序代码为下：
而应用更新段(Application_Update_Section())中各个字段的语义说明如下：
table_id：表标识符，8bit字段，标识应用更新表所属的数据结构，其中，在本数据结构中，table_id取值为‘0x80’，表示该段属于应用更新段，不同的数据结构的table_id取值不同，当table_id取值为‘0x90-0x9F’，表示该段属于应用数据段；当table_id取值为‘0xA0-0xBF’，表示该段属于图片数据段；当然，table_id取值为‘0x00-0x7F’，为其他的SI规范定义；而table_id取值为‘0xC0-0xFE’，为用户定义。具体参见表二：
| table_id值 | 描述 |
| 0x00-0x7F | SI规范定义 |
| 0x80 | 应用更新段 |
| 0x90-0x9F | 应用数据段 |
| 0xA0-0xBF | 图片数据段 |
| 0xC0-0xFE | 用户定义 |
| 0xFF | 预留 |
表二table_id值的分配
section_syntax_indicator：段语法指示符，1bit字段，应置‘1’。
reserved：预留，用于将来扩展功能使用，一般编码为‘1’。
section_length：段长度，12bit字段，它表示从该字段的下一个字节开始的本段的字节长度。
reserved_future_use：保留未来使用，保留未来扩展用。
reserved：预留，用于将来扩展功能使用，一般编码为‘1’。
version_number：版本号，5bit字段，用于标识应用更新表的版本号，当应用更新表的信息发生变化时，version_number加‘1’；当值增至‘31’时，复位为‘0’。
current_next_indicator：当前后续指示符，1bit字段，当被置‘1时，表示当前子表正被使用；当其置‘0’时，表示所传子表尚未被使用，它是下一个将被使用的子表。
section_number：段号，8bit字段，用于给出table_id所标识的子表的段号，子表中的第一个段的section_number标为‘0x00’；每增加一个具有相同的table_id，section_number就加‘1’。
last_section_number：最后段号，8bit字段，表示table_id所标识的子表最后一个段(即段号最大的段)的段号。
descriptor_loop_lengh：描述符长度，用与标识所有描述符的总长度
Application_Update_Descriptor()：应用更新描述符。
CRC32：CRC32校验，32bit字段，包含了该段的CRC值。
其中，机顶盒监测应用更新表数据结构中的应用更新段时，而应用更新段调用应用更新描述符进行应用更新操作。应用更新描述符用于定义应用类型，应用版本，应用标识符，应用更新方式等。
其中，应用更新描述符数据结构的具体程序代码为下：
而应用更新描述符(Application_Update_Descriptor())中各个字段的语义说明如下：
descriptor_tag：8bit，描述符标签，暂取值为‘0xCE’，表示该描述符为应用更新描述符，是应用更新描述符的唯一标识。
descriptor_length：8bit，描述符长度，以字节为单位给出该字段之后描述符的长度。
application_id：16bit，应用标识符，与表标识符一起，唯一标识一个应用，从‘0x0001’开始，每增加一个应用，该值加‘1’。
application_version_number：16bit，应用软件新的版本号，用于存储更新后的新软件的版本号。
application_type：16bit，应用类型，16bit字段，用与存储当前应用类型。
application_update_type：2bit，应用更新类型，2bit字段，存储待更新的应用类型，用于对不同的应用进行判断，不同的应用更新类型，有不同的更新方法；其中，应用更新类型取值不同所代表的更新方式不同。见表三：
| application_update_type值 | 更新方式 |
| 0x01 | 广播路径升级 |
| 0x10 | 网络路径升级 |
| 0x11 | 广播路径和网络路径都支持 |
表三升级方式的分配
reserved：5bit，保留，用于将来扩展功能使用，一般编码为‘1’。
force_flag：1bit，强制标志，1bit字段，用于指出当应用更新表版本号发生变化时是否强制更新。当其值为‘1’时，表示监测到应用更新表版本号发生变化时，立即启动应用更新表及其附属信息更新；当其值为‘0’时，表示监测到应用更新表版本号发生变化时，不会立即启动应用更新表及其附属信息更新，而是在下一次开机或者用户进入点播界面时进行更新。
transport_stream_id：16bit，传输流标识符，16bit字段，在一个传输系统中，用于标识唯一的一个传输流。
original_network_id：16bit，原始网络标识符，16bit字段，用于给出原始传输系统的网络标识符，如果通过广播路径下发，给出传输流标识符和原始网络标识符，并对封装类型进行判断，给出数据下发方式。
packaging_type：8bit，封装类型，用于存储数据封装的类型，其中，封装类型取值不同所代表的封装方式不同。见表四：
| packaging_type值 | 封装类型 |
| 0x01 | 自定义协议封装 |
| 0x02 | DSM-CC OC协议封装 |
表四封装类型的分配
pid：13bit，包标识符，自定义协议封装时给出pid与transport_stream_id和original_network_id一起，唯一链接向一个应用更新表业务。
reserved：3bit，保留，以后使用。
table_id：8bit，表标识符，标识应用更新表所属的数据结构。
section_count：8bit，段数目，用于标识应用更新业务数据段的数目。
service_id：16bit，业务标识符，应用程序的数据量大，此时通过DSM-CC OC协议下发，与transport_stream_id和original_network_id一起，唯一链接向一个应用更新业务列表业务。
url_length：8bit，统一资源定位符长度，当application_update_type==‘0x10’时，表示通过宽带网络路径下发，这样就要给出资源定位符及其长度。
url：64bit，统一资源定位符，给出唯一的网络下载路径。
application_path_length：8bit，媒体路径长度，表示通过宽带网络路径下载时所连接的媒体路径长度。
application_path：媒体路径，数据源下载的原存储地址。
protocal：16bit，协议，表示下载数据时所用的网络协议。
其中，在封装方式为自定义时，则需要访问应用数据段，应用数据段用于承载小数据量的应用数据，通过应用标识符和应用更新描述符中的应用关联。
其中，应用数据段数据结构的具体程序代码为下：
而应用数据段(Application_Data_Section())中各个字段的语义说明如下：
table_id：表标识符，8bit字段，标识应用更新表所属的数据结构，其中本数据结构中的table_id取值为‘0x90-0x9F’，具体参见表一。
section_syntax_indicator：段语法指示符，1bit字段，应置‘1’。
reserved：预留，用于将来扩展功能使用，一般编码为‘1’。
section_length：段长度，12bit字段，它表示从该字段的下一个字节开始的本段的字节长度。
sub_table_id：用于区分一个应用下载的多个子表。
reserved：预留，用于将来扩展功能使用，一般编码为‘1’。
version_number：版本号，5bit字段，用于标识应用更新数据列表段总的版本号，当应用数据列表段的信息发生变化时，version_number加‘1’；当值增至‘31’时，复位为‘0’。
current_next_indicator：当前后续指示符，1bit字段，当被置‘1’时，表示当前子表正被使用；当其置‘0’时，表示所传子表尚未被使用，它是下一个将被使用的子表。
section_number：段号，8bit字段，用于给出table_id所标识的子表的段号，子表中的第一个段的section_number标为‘0x00’，每增加一个具有相同的table_id，section_number就加‘1’。
last_section_number：最后段号，8bit字段，表示table_id所标识的子表最后一个段(即段号最大的段)的段号。
descriptor_loop_lengh：描述符长度，用与标识所有描述符的总长度。
application_data：应用更新的真实数据。
CRC32：CRC32校验，32bit字段，包含了该段的CRC值。
其中，在本数据结构中，应用数据段调用了应用描述符，应用描述符用于给出应用相关描述信息，用于给用户提示更新时，给出应用的相关介绍信息。具体可以通过文本信息或图片的方式，通过图片时，需要定义图片数据表。
其中，应用描述符数据结构的具体程序代码为下：
而应用描述符(Application_Descriptor())中各个字段的语义说明如下：
descriptor_tag：8bit，描述符标签，暂取值为‘0xD0’，表示该描述符为应用描述符，是应用描述符的唯一标识。
descriptor_length：8bit，描述符长度，以字节为单位给出该字段之后描述符的长度。
application_type：16bit，应用类型，16bit字段，用与存储待更新的类型。
application_number：8bit，用于标识更新数据业务的版本号。
reserved：5bit，保留，用于将来扩展功能使用，一般编码为‘1’。
application_update_service_info_type：4bit，用来标识待更新的业务的信息类型，如果该值为‘0001’，表示待更新业务为文本描述；如果该值为‘0010’，表示待更新业务为图片描述。如表五所示：
表五信息类型的分配
ISO 639-2_language_code：24bit，在待更新业务为文本描述时，给出文本描述的语言代码；ISO 639-2语言代码，24bit字段，用于指明在升级数据为文本描述时字段所采用的语言；该字段包含一个由ISO 639-2定义的3字符代码，ISO 639-2/B和ISO 639-2/T都可以使用，每个字符都按照GB/T 15273.1-1994编码为8位，并依次插入24位字段。例如：法语的3字符代码‘打e’，可编码为：‘0110 0110 0111 0010 0110 0101’。
application_info_length：8bit，应用信息长度，用于标识应用信息的长度值。
text_char：8bit，表示具体的文本及字符描述。
picture_data_section_table_id：8bit，图片数据段表标识符，与图片数据段(Picture_Data_Section())中的table_id相对应。
picture_id：图片标识符，24bit字段，和图片数据段表标识符(picture_data_section_table_id)一起唯一标识一个图片；与图片数据段(Picture_Data_Section())中图片标识符(picture_id)字段相对应。
picture_format：图片格式，8bit字段，用于给出图片的格式，picture_format值和图片格式的对应关系如表六所示：
| picture_format值 | 图片格式 |
| 0x00 | 保留 |
| 0x01 | I帧 |
| 0x02 | JPG |
| 0x03 | GIF |
| 0x04 | BMP |
| 0x05-0xFF | 用户定义 |
表六picture_format的分配
picture_size：图片大小，32bit字段，用于给出由picture_data_section_table_id和picture_id所唯一标识的图片数据的字节数。
block_number：块数目，8bit字段，用于给出由picture_data_section_table_id和picture_id所唯一标识的图片数据；封装在图片数据段(Picture_Data_Section())中的分段数，与图片数据段(Picture_Data_Section())中的最后段号(last_section_number)字段相对应。
其中，图片数据段数据结构的具体程序代码为下：
而图片数据段(Picture_Data_Section())中各个字段的语义说明如下：
table_id：表标识符，8bit字段，标识应用更新表所属的数据结构，其中本数据结构中的table_id取值为‘0xA0-0xBF’，与应用数据段(Application_Data_Section())中图片数据段表标识符(picture_data_section_table_id)字段唯一对应。
section_syntax_indicator：段语法指示符，1bit字段，应置‘1’。
reserved_future_use：保留未来使用，保留未来扩展用。
resered：预留，用于将来扩展功能使用，一般编码为‘1’。
section_length：段长度，12bit字段，它表示从该字段的下一个字节开始的本段的字节长度。
version_number：版本号，5bit字段，用于给出由table_id所标识的图片数据段所属的表的版本号，当图片数据段所属的表的信息发生变化时，version_number加‘1’；当值增至‘31’时，复位为‘0’。
current_next_indicator：当前后续指示符，1bit字段，当被置‘1’时，表示当前子表正被使用；当其置‘0’时，表示所传子表尚未被使用，它是下一个将被使用的子表。
picture_id：图片标识符，24bit字段，和表标识符(table_id)一起唯一标识一个图片，从‘0x000001’开始编码，每增加一个图片，该值加‘1’；与应用描述符(Application_Descriptor())中图片标识符(picture_id)字段唯一对应。
sub_version_number：子版本号，5bit字段，给出table_id和picture_id所唯一标识的图片的版本号，当图片数据发生变化时，sub_version_number加‘1’；当值增至‘31’时，复位为‘0’。
last_picture_id：最后图片标识符，24bit字段，给出由table_id所标识的表内最后的图片标识，是table_id所标识的表内所有图片中最大的标识符。
section_number：段号，8bit字段，用于给出table_id和picture_id所唯一标识的图片子表的段号，子表中的第一个段的section_number标为‘0x00’；每增加一个具有相同的table_id和picture_id的段，section_number就加‘1’。
last_section_number：最后段号，8bit字段，表示table_id和picture_id所唯一标识的图片子表最后一个段(即段号最大的段)的段号，与应用描述符(Application_Descriptor())中块数目(block_number)字段相对应。
data_byte：数据字节，8bit字段，给出图片的实际数据。
CRC32：CRC32校验，32bit字段，包含了该段的CRC值。
如图2所示，图2是本发明机顶盒应用程序的更新方法的第二实施例的工作流程示意图。机顶盒应用程序的更新方法包括以下步骤：
步骤S201：服务器接收机顶盒的前端下发的传输流。
步骤S202：机顶盒监测服务器的应用更新表。
当有应用程序更新时，应用更新表中的数据结构应用更新段(Application_Update_section())中的版本号(version_number)字段会在原来的基础上加‘1’。
步骤S203：判断描述标签符取值是否正确。
其中，应用更新段(Application_Update_section())调用应用更新描述符(Application_Update_Descriptor())，并在应用更新描述符(Application_Update_Descriptor())判断描述标签符descriptor_tag取值是否为‘0xCE’。
如果描述标签符descriptor_tag取值不为‘0xCE’，则返回步骤S202。
如果描述标签符descriptor_tag取值为‘0xCE’，则执行步骤S204：判断机顶盒的应用ID、版本号和芯片ID是否符合升级要求。
如果顶盒的应用ID、版本号和芯片ID没有符合升级要求，则返回步骤S202。
如果顶盒的应用ID、版本号和芯片ID符合升级要求，则执行步骤S205：判断应用更新类型取值是否为第一更新类型值。
其中，应用更新描述符(Application_Update_Descriptor())的应用更新类型application_update_type第一更新类型值为‘0x01’。
如果应用更新类型application_update_type第一更新类型值为‘0x01’，则执行步骤S207：机顶盒采用广播路径进行升级。
如果应用更新类型application_update_type第一更新类型值不为‘0x01’，则执行步骤S206：判断应用更新类型取值是否为第二更新类型值。
其中，应用更新描述符(Application_Update_Descriptor())的应用更新类型application_update_type第二更新类型值为‘0x10’。
如果应用更新类型application_update_type第二更新类型值为‘0x10’，则执行步骤S209：机顶盒采用网络路径进行升级。
如果应用更新类型application_update_type第二更新类型值不为‘0x10’，则执行步骤S208：判断应用更新类型取值是否为第三更新类型值。
其中，应用更新描述符(Application_Update_Descriptor())的应用更新类型application_update_type第三更新类型值为‘0x11’。
如果应用更新类型application_update_type第三更新类型值不为‘0x11’，则返回步骤S202。
如果应用更新类型application_update_type第三更新类型值为‘0x11’，则执行步骤S210：机顶盒同时采用广播路径和网络路径进行升级。
其中，步骤S210分步骤S211：广播路径升级和步骤S212：网络路径升级。
在执行完步骤S212或步骤S209后，执行步骤S213：更新机顶盒升级信息。
采用广播路径进行升级时，都需要对数据封装数据进行判断，则在执行完步骤S211或步骤S207后，执行步骤S214：判断封装类型取值是否为第一封装类型值。
其中，应用更新描述符(Application_Update_Descriptor())的封装类型packaging_type第一封装类型值为‘0x01’。
如果封装类型packaging_type第一封装类型值不为‘0x01，则执行步骤S216：判断封装类型取值是否为第二封装类型值。
其中，应用更新描述符(Application_Update_Descriptor())的封装类型packaging_type第二封装类型值为‘0x02’。
如果封装类型packaging_type第二封装类型值不为‘0x02’，则返回步骤S214。
如果封装类型packaging_type第二封装类型值为‘0x02’，则执行步骤S217：机顶盒升级的数据封装类型为DSM-CC OC协议封装。
如果封装类型packaging_type第一封装类型值为‘0x01’，则执行步骤S215：机顶盒升级的数据封装类型为自定义协议封装。
在执行完步骤S215后，执行步骤S218：判断信息类型取值是否为第一信息类型值。
其中，应用描述符(Application_Descriptor())的信息类型application_update_service_info_type第一信息类型值为‘0001。
如果信息类型application_update_serice_info_type第一信息类型值为‘0001’，则执行步骤S220：机顶盒更新的信息数据类型为文本描述类型。
如果信息类型application_update_serice_info_type第一信息类型值不为‘0001，则执行步骤S219：判断信息类型取值是否为第二信息类型值。
其中，应用描述符(Application_Descriptor())的信息类型application_update_serice_info_type第二信息类型值为‘0010’。
如果信息类型application_update_serice_info_type第二信息类型值不为‘0010’，则返回步骤S218。
如果信息类型application_update_serice_info_type第二信息类型值为‘0010’，则执行步骤S221：机顶盒更新的信息数据类型为图片描述类型。
在执行完步骤S217、步骤S220或步骤S221后，执行步骤S213：更新机顶盒升级信息。
在本实施例中，采用网络路径进行升级时，则通过统一资源定位符url，媒体路径application_path，协议protocal来获取网络应用升级的数据。
采用广播路径升级时，如果数据封装类型为DSM-CC OC协议封装，则通过传输流标识符transport_stream_id、原始网络标识符original_network_id、业务标识符service_id来获取升级相关的数据；如果数据封装类型为自定义协议封装，则通过传输流标识符transport_stream_id、原始网络标识符original_network_id、包标识符pid、表标识符table_id和段数量section_count来获取应用数据段(Application_Data_Setion())的数据，然后应用数据段(Application_Data_Setion())通过表标识符table_id、子表标识符sub_table_id、版本号version_number及应用描述符(Application_descriptor())来获取应用升级的信息。
其中，在应用描述符(Application_descriptor())中会根据信息类型application_update_service_info_type来区别是通图片描述还是文本描述。当为文本描述时，通过ISO 639-2语言代码ISO639-2_language_code、文本字符text_char来获取文本数据；当为图片描述时，通过图片数据段表标识符picture_data_section_table_id、图片标识符picture_id、图片格式picture_format、图片大小picture_size和块数目block_number等来查找图片数据段(Picture_Data_Section())。而图片数据段(Picture_Data_Section())通过表标识符table_id、图片标识符picture_id、子版本号sub_version_number、最后图片标识符last_picture_id、段号section_number、最后段号last_section_number和数据字节data_byte来获取图片数据。
如图3所示，图3是本发明机顶盒应用程序的更新系统的实施例的结构示意图。机顶盒应用程序的更新系统包括服务器10和机顶盒11。其中，机顶盒11至少一台。服务器10用于接收机顶盒11前端下发的应用更新表。机顶盒11用于监测服务器10的应用更新表，并根据应用更新表判断机顶盒11是否符合升级要求。
具体而言，机顶盒11判断服务器10中应用更新表中的应用更新描述符取值是否正确。如果是，则判断机顶盒11的应用ID、版本号和芯片ID是否符合升级要求。如果是，则选择性地采用网络路径和广播路径两者中的至少一种路径方式升级机顶盒11。
请一并参考图4和图5，图4是本发明机顶盒应用程序的更新系统的机顶盒的结构示意图；图5是机顶盒的检测系统和升级系统的结构示意图。机顶盒11包括检测系统12和升级系统13。检测系统12用于检测机顶盒11是否有升级的信息。升级系统13用于更新机顶盒11应用程序的信息。其中，检测系统12检测到机顶盒11有升级信息后，升级系统13更新机顶盒11的升级信息。
其中，检测系统12包括：版本信息模块121，用于监测机顶盒11的升级信息，并判断升级信息对应的应用程序和判断应用版本对应的升级版本；权限判断模块122，用于判断用户端是否有升级的权限；更新类型模块123，用于判断机顶盒11采用的更新类型；封装类型模块124，用于判断机顶盒11升级的数据封装类型；信息类型模块125，用于判断机顶盒11更新的数据信息类型。
升级系统13包括：宽带协议处理模块131，用于进行网络路径升级且获取网络路径的升级数据；广播协议处理模块132，用于进行广播路径升级且获取广播路径的升级数据；DSM-CC OC模块133，用于采用DSM-CC OC协议进行封装且获取DSM-CC OC协议的数据；自定义模块134，用于采用自定义协议进行封装且获取自定义协议的数据；信息提示模块135，用于获取升级信息的信息类型的提示；应用更新模块136，用于完成最终升级。
其中，机顶盒应用程序的更新系统有更新信息时，机顶盒11中的版本信息模块121判断应用程序是否有对应程序升级的版本。如果是，则权限判断模块122判断机顶盒11有升级权限的用户和应用程序对应升级的版本号，随后判断更新类型。当更新类型模块123判断完机顶盒11的更新类型后，到升级系统13中采用宽带协议处理模块131或广播协议处理模块132处理机顶盒11的数据更新类型。
进一步的，请一并参考图6与图7，图6是图5中的宽带协议处理模块的结构示意图；图7是5中的广播协议处理模块的结构示意图。宽带协议处理模块131包括有：第一数据接收单元1311、第一数据解析单元1312、应用程序更新判定单元1313、应用数据获取请求单元1314、临时会话密钥缓存单元1315、第二数据接收单元1316、第一数据缓存单元1317和解密单元1318。广播协议处理模块132包括有：第三数据接收单元1321、第二数据解析单元1322、下载权限判断单元1323和第二数据缓存单元1324。
其中，机顶盒11升级方式采用宽带路径升级时，宽带协议处理模块131的第一数据接收单元1311接收升级的数据，并通过第一数据解析单元1312解析数据，对数据进行分析；应用程序更新判定单元1313判断第一数据解析单元1312解析的数据，应用数据获取请求单元1314在应用程序更新判定单元1313判断后发出请求对应用程序进行连接；临时会话密钥缓存单元1315缓存数据，通过第二数据接收单元1316将应用程序升级的数据接收，第一数据缓存单元1317将数据缓存并通过解密单元1318将数据进行解密且写入机顶盒11的应用程序中。
进一步的，机顶盒11升级方式采用广播路径升级时，广播协议处理模块132的第三数据接收单元1321接收升级的数据，并通过第二数据解析单元1322解析数据，对数据进行分析；下载权限判断单元1323对第二数据解析单元1322解析的数据进行判断；第二数据缓存单元1324在下载权限判断单元1323判断后缓存数据类型。
其中，机顶盒11的数据更新类型采用广播协议处理模块132处理后，机顶盒11继续判断数据封装类型。当封装类型模块124判断完机顶盒11的数据封装类型后，到升级系统13中采用DSM-CC OC模块133或自定义模块134处理机顶盒11的数据封装类型。
其中，机顶盒11的数据封装类型采用自定义模块134处理后，机顶盒11继续判断数据信息类型。当信息类型模块125判断完机顶盒11的数据信息类型后，到升级系统13中的信息提示模块135中根据信息提示采用文本单元1351或图片单元1352处理机顶盒11的信息类型。
应用更新模块136根据信息提示模块135的提示获取的升级信息完成应用程序的更新，把接收的应用数据写入机顶盒11中。其中，如图8所示，图8是图5中的应用更新模块的结构示意图。应用更新模块136包括第四数据接收单元1361、数据分析单元1362、数据写入单元1363和数据校验单元1364。应用更新模块136根据信息提示模块135获取的升级信息，第四数据接收单元1361接收相应的数据，并通过数据分析单元1362分析相应的数据，在数据分析单元1362分析完数据后数据写入单元1363下载数据，最后通过数据校验单元1364对数据进行校验无误后写入到机顶盒11应用程序中。
综上所述，本发明的机顶盒应用程序的更新方法及系统通过监测服务器的应用更新表，并判断机顶盒的应用ID、版本号和芯片ID是否符合升级要求，如果是，则有权限的用户可以采用网络路径方式升级机顶盒、采用广播路径方式升级机顶盒或采用网络路径方式和广播路径方式共同升级机顶盒，能够解决机顶盒应用程序升级方式中单一采用网络路径升级的问题，有效帮助运营商对前端资源的管理，可以针对部分用户进行升级，对于没有权限的用户不给予升级。
以上所述仅为本发明的实施方式，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。
Claims (10)
1.一种机顶盒应用程序的更新方法，其特征在于，所述方法包括：
服务器接收机顶盒的前端下发的传输流，所述传输流的信息包括所述机顶盒的应用更新表；
所述机顶盒监测所述服务器的应用更新表，并判断所述应用更新表中描述标签符取值是否正确；
如果是，则判断所述机顶盒的应用ID、版本号和芯片ID是否符合升级要求；
如果是，则选择性地采用网络路径和广播路径两者中的至少一种路径方式升级所述机顶盒。
2.根据权利要求1所述的方法，其特征在于，在所述判断机顶盒的应用ID、版本号和芯片ID符合升级要求的步骤之后包括：
通过所述应用更新表中的应用更新类型符数据结构来判断所述机顶盒采用的更新类型；
如果所述应用更新类型取值为第一更新类型值时，则所述机顶盒采用广播路径进行升级；
如果所述应用更新类型取值为第二更新类型值时，则所述机顶盒采用网络路径进行升级；
如果所述应用更新类型取值为第三更新类型值时，则所述机顶盒同时采用所述广播路径和所述网络路径进行升级。
3.根据权利要求2所述的方法，其特征在于，在所述机顶盒采用所述广播路径进行升级的步骤后包括：
通过所述应用更新表中的应用更新类型符数据结构来判断所述机顶盒升级的数据封装类型；
如果封装类型取值为第一封装类型值时，则所述机顶盒升级的数据封装类型为自定义协议封装；
如果所述封装类型取值为第二封装类型值时，则所述机顶盒升级的数据封装类型为DSM-CC OC协议封装。
4.根据权利要求3所述的方法，其特征在于，在所述采用自定义协议封装的步骤后包括：
通过所述应用更新表中的应用描述符数据结构来判断所述机顶盒更新的信息数据类型；
如果信息类型取值为第一信息类型值时，则所述机顶盒更新的信息数据类型为文本描述类型；
如果所述信息类型取值为第二信息类型值时，则所述机顶盒更新的信息数据类型为图片描述类型。
5.根据权利要求1所述的方法，其特征在于，所述应用更新表的数据结构包括有应用更新段、应用更新描述符、应用数据段、应用描述符、图片数据段，且在所述应用更新描述符中设置所述描述标签符。
6.一种机顶盒应用程序的更新系统，其特征在于，所述更新系统包括服务器和至少一机顶盒，其中：
所述服务器，用于接收所述机顶盒前端下发的应用更新表；
所述机顶盒，用于监测所述服务器的应用更新表，并根据所述应用更新表判断所述机顶盒是否符合升级要求，其中：
所述机顶盒判断所述应用更新表中的应用更新描述符取值是否正确；
如果是，则判断所述机顶盒的应用ID、版本号和芯片ID是否符合升级要求；
如果是，则选择性地采用网络路径和广播路径两者中的至少一种路径方式升级所述机顶盒。
7.根据权利要求6所述的更新系统，其特征在于，所述机顶盒包括：
检测系统，用于检测所述机顶盒是否有升级的信息；
升级系统，用于升级所述机顶盒应用程序的信息，其中，所述检测系统检测到机顶盒有升级信息后，所述升级系统更新所述机顶盒的升级信息。
8.根据权利要求7所述的更新系统，其特征在于，所述检测系统包括：
版本信息模块，用于监测所述机顶盒的升级信息，并判断所述升级信息对应的应用程序和判断应用版本对应的升级版本；
权限判断模块，用于判断所述机顶盒用户端是否有升级权限；
更新类型模块，用于判断所述机顶盒采用的更新类型；
封装类型模块，用于判断所述机顶盒升级的数据封装类型；
信息类型模块，用于判断所述机顶盒更新的信息数据类型。
9.根据权利要求7所述的更新系统，其特征在于，所述升级系统包括：
广播协议处理模块，用于进行广播路径升级；
宽带协议处理模块，用于进行网络路径升级；
自定义模块，用于采用自定义协议进行封装；
DSM-CC OC模块，用于采用DSM-CC OC协议进行封装；
信息提示模块，用于获取升级信息的信息类型的提示；
应用更新模块，用于升级应用程序。
10.根据权利要求6所述的更新系统，其特征在于，所述应用更新表的数据结构包括有应用更新段、应用更新描述符、应用数据段、应用描述符、图片数据段，且在所述应用更新描述符中设置所述描述标签符。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201210562817.9A CN103067779B (zh) | 2012-12-21 | 2012-12-21 | 机顶盒应用程序的更新方法及系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201210562817.9A CN103067779B (zh) | 2012-12-21 | 2012-12-21 | 机顶盒应用程序的更新方法及系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN103067779A true CN103067779A (zh) | 2013-04-24 |
| CN103067779B CN103067779B (zh) | 2016-06-22 |
Family
ID=48110212
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201210562817.9A Active CN103067779B (zh) | 2012-12-21 | 2012-12-21 | 机顶盒应用程序的更新方法及系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN103067779B (zh) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104461652A (zh) * | 2014-12-26 | 2015-03-25 | 珠海迈科智能科技股份有限公司 | 机顶盒软件更新方法及系统 |
| CN104581362A (zh) * | 2014-12-25 | 2015-04-29 | 四川金网通电子科技有限公司 | 从云端管理ott智能机顶盒的系统及方法 |
| WO2016023373A1 (zh) * | 2014-08-15 | 2016-02-18 | 中兴通讯股份有限公司 | 机顶盒升级的方法及装置 |
| CN109840273A (zh) * | 2019-01-18 | 2019-06-04 | 珠海天燕科技有限公司 | 一种文案生成方法和装置 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101001316A (zh) * | 2006-12-31 | 2007-07-18 | 北京广博数字电视科技有限公司 | 机顶盒软件升级管理方法和系统 |
| CN101521815A (zh) * | 2009-03-31 | 2009-09-02 | 深圳创维数字技术股份有限公司 | 一种数字电视接收终端软件的升级方法、系统及终端 |
| CN101588256A (zh) * | 2008-05-20 | 2009-11-25 | 东方有线网络有限公司 | 一种基于互动电视平台的终端软件升级管理系统 |
-
2012
- 2012-12-21 CN CN201210562817.9A patent/CN103067779B/zh active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101001316A (zh) * | 2006-12-31 | 2007-07-18 | 北京广博数字电视科技有限公司 | 机顶盒软件升级管理方法和系统 |
| CN101588256A (zh) * | 2008-05-20 | 2009-11-25 | 东方有线网络有限公司 | 一种基于互动电视平台的终端软件升级管理系统 |
| CN101521815A (zh) * | 2009-03-31 | 2009-09-02 | 深圳创维数字技术股份有限公司 | 一种数字电视接收终端软件的升级方法、系统及终端 |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2016023373A1 (zh) * | 2014-08-15 | 2016-02-18 | 中兴通讯股份有限公司 | 机顶盒升级的方法及装置 |
| US10057645B2 (en) | 2014-08-15 | 2018-08-21 | Zte Corporation | Set top box upgrade method and apparatus |
| CN104581362A (zh) * | 2014-12-25 | 2015-04-29 | 四川金网通电子科技有限公司 | 从云端管理ott智能机顶盒的系统及方法 |
| CN104461652A (zh) * | 2014-12-26 | 2015-03-25 | 珠海迈科智能科技股份有限公司 | 机顶盒软件更新方法及系统 |
| CN104461652B (zh) * | 2014-12-26 | 2017-11-03 | 珠海迈科智能科技股份有限公司 | 机顶盒软件更新方法及系统 |
| CN109840273A (zh) * | 2019-01-18 | 2019-06-04 | 珠海天燕科技有限公司 | 一种文案生成方法和装置 |
| CN109840273B (zh) * | 2019-01-18 | 2020-09-15 | 珠海天燕科技有限公司 | 一种文案生成方法和装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN103067779B (zh) | 2016-06-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN1852297B (zh) | 网络数据流识别系统及方法 | |
| CN104396186B (zh) | 用于处理互动服务的装置及方法 | |
| CN106911502B (zh) | 一种智能家庭网关设备的升级方法及系统 | |
| CN103283219B (zh) | 接收广播服务的方法和设备 | |
| CN100515029C (zh) | 对机顶盒下载器文件进行统一升级管理的系统 | |
| US8918828B2 (en) | Private user data | |
| CN101217633B (zh) | 一种实现流媒体互动的方法及系统 | |
| CN105264898B (zh) | 软件升级方法、装置及设备 | |
| CN101681264B (zh) | 网络中软件下载的方法和装置 | |
| CN103067779B (zh) | 机顶盒应用程序的更新方法及系统 | |
| CN106210827B (zh) | 一种动态配置机顶盒多ca的方法及系统 | |
| CN105794174A (zh) | 用于发送/接收广播信号的设备和方法 | |
| US20240089517A1 (en) | Systems and methods for enhanced multimedia signal broadcast, reception, data delivery, and data collection | |
| CN101207801A (zh) | 一种广告数据的传输、播放方法及装置 | |
| JP4447841B2 (ja) | Ｍｐｅｇ−２１アーキテクチャにおけるデジタル・アイテムに対するｉｐｍｐスキーム記述の方法 | |
| US20170347131A1 (en) | Transmission device and transmission method as well as reception device and reception method | |
| US20140130109A1 (en) | System and method for playing digital television program, and digital television reception terminal | |
| CN101990128A (zh) | 对象轮播的方法及装置及对象轮播下载的方法及装置 | |
| US20100023530A1 (en) | Method and apparatus for providing rich media service | |
| CN102387121B (zh) | 管理服务器、影像分发控制系统及影像分发控制方法 | |
| CN103546765A (zh) | 传输流封装方法、传输流及其解析方法 | |
| CN106134207B (zh) | 发送装置、发送方法、接收装置以及接收方法 | |
| CN102546065B (zh) | 一种紧急事件获取方法及终端 | |
| EP3352468A1 (en) | Receiving device, transmitting device, and data processing method | |
| CN101425864A (zh) | 一种数据广播发送和接收方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| C56 | Change in the name or address of the patentee | ||
| CP01 | Change in the name or title of a patent holder |
Address after: 518000 Guangdong city of Shenzhen province Nanshan District Gao Xin Road SKYWORTH building A block 14 layer Patentee after: Shenzhen Skyworth Digital Technology Co., Ltd. Address before: 518000 Guangdong city of Shenzhen province Nanshan District Gao Xin Road SKYWORTH building A block 14 layer Patentee before: Shenzhen Skyworth Digital Technology Co., Ltd. |