CN1221285A - 数字电视系统中用于管理服务信息的方法和接收机 - Google Patents

Abstract

本发明涉及数字电视系统中用于管理服务信息的方法。就系统的接收机而言,该方法包括下列步骤:为用来从数字数据流中有选择地提取信息的装置(5)编制程序;至少存储某些取出的信息;依据关于这个信息项为所述有选择提取的装置的编程,标明存储的信息项为更新的或未更新的。本发明还涉及用来实现这个方法的设备。

Description

数字电视系统中用于管理服务 信息的方法和接收机

本发明涉及数字电视系统中用于管理服务信息，特别是与节目指南有关的信息的方法。

本发明尤其适用于数字电视译码器。

电子节目指南(或EPG)是在数字电视系统内部使用的软件应用系统。这些应用系统为观看者提供接口，借此他一般可咨询与节目广播有关的信息。

通过多路传输数字数据流中适当的数据包传送信息。经常用于这类数据的名称是“服务信息”(或者简单地“SI”)。

定期广播服务信息，特别是根据可利用的通带和用户请求信息的频率来选择周期。这是因为当用户想要快速观看有关大量节目的信息时，最好是使用户信息请求和回答这项请求之间的等待时间尽可能短。一种方法是为每台接收机或译码器提供大量存储器，以便存储尽可能多的信息，使得能立即回答用户的请求。结果是广播的信息总是这样的，使得在用于公众的大量产品中，至少按目前的半导体存储器价格，这种解决办法是不可行的。此外，信息项经常变化的事实将会迫使接收机或译码器把它的资源的相当大的部分用于更新信息，不管它随后是否被使用。特别是可为之编制程序并同时实现的数据包多路分解滤波器的数量是有限的。

以申请人的名义在1996年8月9日提出的两项法国专利申请FR 9610067和FR 96 10068涉及接收机中，特别是数字电视译码器中用于管理服务信息的一种模块。申请FR 96 10067涉及一种电视接收机以及用于管理更新存储在接收机内部动态数据库中的某些类型的数据的方法，而申请96 10068涉及在内部数据库中给从数字流中接收和取出的数据加索引的方法。指定欧洲，美国，日本和中国的申请WO 98/09430要求申请FR 9610068的优先权。要求FR 9610067的优先权的申请已经在欧洲(出版号0823798)，中国(出版物1175826A)，美国(申请08/906597)，印度尼西亚(申请P-972774)和日本(出版物98508/98)提出。

这两项专利还描述象节目指南之类的应用可能发出的请求，以便从管理SI数据的模块中请求这个或那个信息项，该模块为多路分解器编制程序；永久的或一次性请求，预期的或意外的请求。

根据这两项专利，把与永久请求对应的数据存储在内部数据库中，直到为永久请求再编制程序为止，而在一次性请求以后，除了直接处理以外，不把取出的数据保存在存储器中。

在用户通过节目指南回顾他的步骤的情况下，有可能必须再一次取出最近删除的数据。

本发明建议提高在这种情况下系统的反应能力。

本发明的主题是用于管理数字电视系统中的服务信息的方法，其特征在于，就系统的接收机而言，它包括下列步骤：

-为用来从数字数据流中有选择地提取信息的装置(5)编制程序；

-至少存储某些取出的信息；

-依据关于这个信息项为所述有选择提取装置的编程，标明存储的信息项是更新的或未更新的。

当为从数据流中有选择提取信息项的装置解除编程(deprogramme)时，把事先存储在接收机的内部数据库中的信息仍然保存在库中，但标明为未更新的。

这样，一方面，如果用户回顾他的步骤时，有可能非常快速地为他提供这种未更新的信息，而不用等待新的提取。虽然由此使得接收机的存储器更忙，但是如果存储器变得饱和时，可容易地删除未更新的数据。

根据本发明的一个特定实施例，在由应用提出提取信息项的请求以后，按如下所述执行编程和存储步骤：

-如果要求的信息项存在于数据库中，在从数据流中提取信息项以后，把信息项传送给应用，为从数据流中有选择地提取信息项的装置编制程序，并更新数据库中的信息项；

-如果要求的信息项不在数据库中，在从数据流中把它取出以后，为有选择提取的装置编制程序并把该信息项存储在译码器的数据库中。

这样，当信息项存在于库中时，就把它传送给为此作出请求的应用而不用等待。如果在由应用最近请求以后曾把它存储起来，例如在用户通过节目指南回顾他的步骤时，情况尤其是这样。有很大的可能性，这样存储的信息项仍然通用，或者至少它将满足用户。

用于寻找数据流中的信息项和用于存储这个信息项的资源仅仅用来寻找或更新由应用请求的信息项，而不是不加选择地用于存储和更新信息。

根据一个特定实施例，寻找装置包括多路分解器。

根据一个特定实施例，标明存储的信息项是更新的在取出所述项以后的整个期间内都是有效的，而且在该期间内为该寻找装置编制程序，以便从其中取出新的值。在取出一个项以后，只要取出它的滤波器仍然有效时，可认为该项是更新的。如果在流中检测到未改变的型号时，也可认为它是更新的。

根据一个特定实施例，连同为寻找这个信息项的装置解除编程一起，在从流中取出它以后标明存储的信息项是未更新的。

根据特定的实施例，标明信息项是未更新的包括把这个信息项与日期相联系，在该日期为与该信息项对应的有选择提取装置解除编程。

这个特征使得有可能确定自上次更新信息项以后过去的时间。这使得有可能判断它的逐渐过时，尤其是如果已知它的传送周期时。

根据一个特定实施例，如果接收机的数据库变得饱和，即按日期长久的顺序删除标为未更新的信息。

根据不同的实施例，把信息项的标记与这个信息项一起通知要求该信息项的应用。

这样，应用可依据标记的状态决定这个信息项的用途。

根据不同的实施例，如果接收机的数据库变得饱和时，可按日期长久的顺序删除标为未更新的信息。

根据不同的实施例，直观地确定由应用在屏幕上显示的未更新的信息项为未更新的。

从而提醒用户该信息项的状态以及后者可能过时的危险。

本发明的主题还是在其中传送服务信息，特别是节目指南信息的数字电视系统中的接收机，所述接收机包括：

数据流多路分解器，所述多路分解器包括用来从所述流中有选择提取信息的可编程滤波器，

所述接收机的特征在于它包括：

-用来容纳所述接收机的数据库的存储器，所述数据库包括以前取出的信息；

-用来标明数据库的信息为更新或未更新的装置。

根据不同的实施例，随着为所述多路分解器编制程序的变化，完成标明为更新或未更新的工作。

根据不同的实施例，该设备进一步包括用来标明未更新信息的时钟。

通过描述非限制性实施例将呈现本发明的其它特征和优点。本实施例用附图说明，其中：

-图1是根据本实施例的电视接收机的框图，

-图2a到2c是在图1的设备的应用、数据管理模块和多路分解器之间发生的交换的时间图，

-图3a和3b是分别说明一次性请求和永久请求的工作方式的状态图，

-图4是一种应用，即电子节目指南的屏幕简图，

-图5是在给定时刻由管理模块保持的数据库简图。

为了获得有关MPEG和DVB服务数据、段和表的格式和内容的更多信息，将特别涉及下列三个文件：

(a)ETS 300 468-关于数字电视广播(DVB)系统中的服务信息(SI)的详细说明-1996年1月23日，

(b)ISO/IEC 13818-1(1994)电影和有关声音的类编码-建议H.220，也称为“MPEGⅡ系统”，以及

(c)ETR 211-用于电视的数字广播系统：关于使用MPEG-2系统的实现指南；有关实现和使用服务信息指南。

图1是用于数字电视的DVB(数字电视广播)型集成译码器/接收机的框图。

显而易见，本发明并不局限于这种物理环境，而是可容易地适用于某些其它类型的服务数据传输，例如在帧回扫的时间间隔内通过已调制数据传输。

图1的译码器和天线1连接，而后者本身与译码器的调谐器2连接。调谐器传送的信号由解调器3解调。已解调的数据由校正电路4校正并被传送到多路分解器5。

后者是，例如，与以THOMSON MULTIMEDIA(汤姆逊多媒体)名义在1995年12月29日提出的法国专利申请95 15767号中所描述的一种类似的多路分解器。多路分解器5包括若干扩展称为滤波器的、由微处理器23随着被译码器支持的各种应用的变化而编程的筛选寄存器。多路分解器把筛选寄存器的内容同数据包的某些参数比较并装入与正比较对应的数据包。

为了框图清楚起见，仅仅表示了微处理器23的最重要连接。

把由多路分解器筛选的声频或视频数据包或段存储在等待应用的缓冲存储器6的预定区域。如果需要时，在存储到这个缓冲存储器6之前，随着用户权利的变化，首先用解码电路7把信息解码。

根据本实例，有五种应用：声频译码器16，视频译码器17，电视文字广播译码器18，访问控制部件(包括解码器7，检验微控制器8和在正常工作状态下用于与微处理器卡10连接的微处理器卡9的接口)，以及服务数据管理模块。

译码器还包括用于遥控的红外接口24，所述接口还与微处理器23连接。后者与装有操作系统以及用来实现应用的常驻或下载程序的存储器12连接。

与交换电话网络14连接的调制解调器13也由微处理器控制。

字符发生器15使得能产生与译码器的参数或特定应用有关的命令菜单或图形。和朝着与电视机22连接的第一SCART插座或与录象机21连接的第二SCART插座行进的，从视频译码器17或从电视文字广播译码器18产生的视频信号之一一起多路传送由这个字符发生器产生的视频信号。多路传输电路20由微处理器23控制。

根据本示范实施例，尽管在概念上服务数据管理模块是以使用专用电路的声频或视频译码器的方式处理数据包的应用，但实际上它表示由微处理器管理的程序。

该模块是服务数据(MPEG和DVB表以及段)和用户应用(节目指南，电视购物，交互游戏，等等)之间的接口。它管理来自用户应用的请求并凭借接收的服务数据保持内部数据库。

根据本示范实施例，用户应用是也由微处理器管理的节目指南。

管理模块使用户应用可以得到用来表达有关应用所需信息的请求的若干功能。

请求功能异步操作。如果有答复，当这个答复可得到时，由管理模块把对请求的答复通知应用。这需要实现请求功能鉴别机制。为此，由应用为与这个请求一起发出和传送的每个请求选择标识符。由管理模块把这个标识符和答复的通知结合。

图2a到2c说明在请求以后，在用户应用、服务数据管理模块和这些数据源之间，即多路分解器/缓冲存储器/微处理器部件之间交换的三种情况。

图2a涉及内部数据库(“超高速缓存”)包括由用户应用所请求的信息项的情况。用户应用请求继之以通知可获得这个信息项。在这种情况下，信息项存在于数据库中，答复的通知几乎是即时的。在这种情况下，没有数据项被传送到多路分解器或自其中传送出来。向应用的数据传送是通过管理模块把数据写入其中的缓冲存储器实现的。在应用的请求中标出了要使用的缓冲存储器区域。一旦通知之后，应用将从其中及时读出数据。下面将更详细地看到这种情况。

图2b说明请求的信息项不在内部数据库中出现的情况。在这种情况下，用户应用的请求同样继之以由管理模块通知预定的应用，告知它暂时不能获得信息项，然后告知由管理模块访问多路分解器的命令。当在被多路分解并存储在缓冲存储器中的数据流中已经找到与寻找的信息项对应的段或若干段时，多路分解器通知SI(服务信息)管理模块，这些段已可利用。在读出并使这些段的数据重新格式化之后，管理模块又通知用户应用，所寻找的信息项已可利用。就象在前面的情况中那样，模块把寻找的信息项(它可能只是段中的某些数据)写入在其由用户应用最初请求过程中所分配的缓冲存储器。因此，在这种情况下，这个通知比在2a的情况下到达得更慢些。

图2c说明一种情况，其中象图2a那样的最初请求规定，应该用信号通知寻找的信息中的变化。在这种情况下，把使得有可能从数据流中取出含有这个信息项的数据包的多路分解器的滤波器保持在以前的值上，而不是使之不活动。下面将更详细地描述这种类型的称为永久请求的请求。

根据本示范实施例，有四种类型的请求：

(a)一次性请求：

当由应用向管理模块提出这样的请求时，管理模块使其资源(滤波器和存储器)仅仅可利用到把请求的数据传送到应用的时刻为止。原则上使资源立即自由。

(b)预期的一次性请求：

这种请求具有一次性请求的特征，但具有较低的优先级。管理模块支持两个FIFO(先进先出)型存储器，一个用于预期请求，而另一个用于意外请求。总是在意外请求之后处理正在等待的预期请求。

(c)永久请求：

甚至在把请求的数据多路分解和传送之后，还保留管理模块的资源。每当在这些数据中发生变化时，即把通知传送给应用。管理模块因而进行系统监控，这样进行到应用发出中断这种监控的命令为止。

(d)预期的永久请求

这种请求与永久请求类似，但具有较低的优先级。

附加在请求上的优先级当然不会以任何方式预先判断实际上收到有关这些请求的数据的顺序。这个顺序还取决于一些因素，如每个数据项的周期以及相对于这个周期正式提出请求的时刻。

图3a是一次性请求的状态图，而图3b是永久请求的状态图。

每当应用正式提出请求时，请求类型必定与此有联系。

在永久请求的情况下，把从流中检索到的数据补充存储到管理模块的内部数据库中。对于在一次性请求之后取出的数据来说，情况不是这样，对于一次性请求没有保存数据的拷贝。当检测到含有与永久请求有关的数据的表的新版本时，把这个表中的适当数据与数据库中的数据比较。用与每个表一起传送的称为“version id”(版本-标识符”)或“version number”(“版本-号”)的参数值的变化表示版本的变化。除非已经修改了这些数据中的至少一个数据，事先不传送更新的通知。不管表中发生的变化，即使它仅仅涉及未由应用请求的数据，实际上也修改了表的版本标识符“version id”。这种机制避免了在应用和管理模块之间传送冗余数据。

此外，应用请求不同于基本请求。就象它们的名称所显示的那样，应用请求是由用户应用发出的请求。由SI管理模块根据需要把应用请求转换为尽可能多的基本请求。在这个意义上，基本请求是可被转换为在多路分解器级的一个滤波器的一种请求。以这样的方式确定基本请求，即它们与之有关的数据不重叠。

由SI模块保存两种请求表：应用请求表和基本请求表。应用请求表

请求标识符	类型	功能	等待	SingNB	S清单	参数

基本请求表

请求标识符	功能	状态	类型	日期	应用请求数	参数

应用请求表包括关于每个请求的下列成分：

-请求标识符，

-请求的类型(预期的一次性请求，意外的一次性请求…)，

-请求的功能，

-‘等待’：等待的、即还没有得到回答的相应的基本请求数(当这个数字等于零时，发送第一个通知给发出请求的应用)，

-“SingNB”：没有导致把数据传送到缓冲存储器的基本请求数，

-“S清单”：与这个应用请求相关的基本请求的标识符清单，

-与应用请求联系的参数(例如，为其寻找事件清单的服务标志)。

基本请求表包括关于每个基本请求的下列成分：

-请求标识符，

-请求的类型，

-请求的功能，

-请求的状态，

-与该基本请求联系的应用请求数，

-请求失效的日期(如果有关的话)，

-与基本请求联系的参数。

当SI管理模块把应用请求转换为一个或多个基本请求时，它检查基本请求表是否已经包括这些请求。只有在早先没有同样的请求时，才把新的基本请求加进相应的表中。这使得有可能避免把多路分解器的资源使用到过量的极限。

如果它们具有相同的功能和相同的参数时，两个基本请求就被认为是相同的。如果基本请求已经存在于相应的表中，那么SI模块就检查已存在的基本请求的类型。如果这种类型具有比新的基本请求的类型(这是产生这种新的基本请求的应用请求类型)更低的优先级时，那么就改变原有的基本请求类型，以便取新的值。从最低到最高优先级的请求类型的类别为：预期的一次性，预期的永久，意外的一次性，意外的永久。

在编程或修改相应的基本请求之后，更新应用请求表随后的成分：“等待”，“S清单”。从而建立与基本请求表内容的联系。

基本请求表还具有另外的作用：它提供一种可能性，以便确定一个数据项是否存在于库中以及这个数据项是否是最新的。

这个表中的请求的“状态”域可取下列值之一：

-‘等待’：请求是有效的，但还没有收到数据；

-‘准备就绪’：请求是有效的，而且数据已被存储在数据库中并被更新；

-‘未更新’：请求不再有效，数据存储在数据库中，但不再被更新。

对于每个基本请求来说，基本请求表还计算有关的有效应用请求的数目。就像通过分解新的应用请求或为旧的请求解除编程所决定的那样，使这个数目递增或递减。对于一个基本请求来说，当这个数目下降为零时，基本请求的状态变为‘未更新’(如果以前它的状态是‘准备就绪’)：换句话说，它是无效的。如果有数据的话，以前提取的数据仍然存储在库中。

从表中删去应用请求数目下降为零以及由于一种或另一种原因没有把信息存储在库中的基本请求。使多路分解器的相应的滤波器自由。这样做的原因可能是各种各样的：在可能获得数据之前过快地解除编程，请求的数据没有广播，等等。

通过适当的应用请求可使无效的基本请求再度有效，或者在有必要空出数据库中被占用的存储器中的某些空间以及要删去与那里对应的数据时，把它从基本请求表中删除。

把使请求无效的日期存储在基本请求表中。在目前情况下，这个日期包括系统时钟值，使这个时钟与编码器的时钟同步。但是，使用某些其它类型的时钟也是可能的。

在多路分解与(一次性或永久型)基本请求对应的数据时，把它们传送到缓冲存储器。与应用请求联系多少次，这种传送就进行多少次。使每个有关的应用请求中的基本请求的‘SingNB’数递减。只有在这个数对于这个应用来说到达零时，也就是说，当与由应用发出的应用请求联系的所有基本请求已得到结果并已把它传送到缓冲存储器时，才由SI管理模块通知应用可获得数据。

而如果关于基本请求在库中有随后的数据变化时，要把这种变化立即通知有关的应用。

在下面描述的图5给出了在特殊情况下两个表的例子。

假如还没有把产生数据的请求保持可从上述无效日期所确定的一段时间，当标明基本请求是‘未更新’时，这并不意味着库中的数据实际上不再是最新的，而只是表明有这样的可能性。

当管理模块把数据传送到缓冲存储器，以便传送给应用时，‘日期’域和‘状态’域的内容也被存储在那里。将由将要决定使用这个信息的应用读出这些值。当状态是‘准备就绪’时，数据是最新的。当状态是‘未更新’时，它们不是最新的，而‘日期’域表明它们是多么旧的。如果应用是节目指南，显示的表明没有被更新的数据以这样的方式被显示，以便鉴别它们：例如，不同于将要被更新的信息的阴影显示或彩色显示。

当基本请求的状态是‘准备就绪’时，数据是最新的。为了向应用表明这点，在传送数据的过程中，‘日期’域被传送的值为零。

根据本实施例，虽然只有永久基本请求(不管是否是预期的)导致把取出的数据存储在数据库中，根据不同的实施例，也保证存储与一次性请求对应的数据。在这种情况下，当然需要把一次性类型的基本请求也保存在相应的表中。

在请求以后不管是否已在内部数据库中读出未更新的数据，要给多路分解器的过滤器编程(如果这个尚未进行的话)，以便从流中取出最新的值。一旦从流中取出之后，即把这些值写入数据库，如果需要时，重写最旧的数据。相应地作出基本请求状态的改变：已经存在于表中的请求可从‘等待’状态转到‘准备就绪’状态，但也可从‘未更新’状态转到‘准备就绪’状态，反之亦然。如果没有与要取出的数据对应的基本请求，当然就建立它们。

根据本示范实施例，在多路分解器级进行‘version id’参数的管理。使用两种类型的滤波器：把要检索的信息项的型号屏蔽的第一种类型(不管其型号如何，要把检测到的第一种型式多路分解)以及其中型号具有规定的特定值的第二种类型(只有具有这个型号的信息项将被多路分解)。

当产生基本请求而且没有相应的滤波器已经存在时，它是被使用的第一种类型的滤波器。一旦已经检测到并取出相应的信息项时，如果基本请求是永久型，取出的型号值就递增并被附加到原有的滤波器上：从而形成上述的第二种类型的滤波器。这样，肯定将检测到信息项的下一个型式。

把型号值存储在数据库中当然是可能的。

利用基本请求表的‘日期’域中指出的日期清理数据库，以便空出某些存储器。按照旧的程度的顺序删去处于‘未更新’状态的基本请求以及与这些请求有密切关系的数据。当数据库装满时，就进行这种清理。只要它仅仅涉及处于‘未更新’状态下的基本请求，就由SI管理模块主动地并在其控制下进行这种清理。当数据库装满时，尽管不再有处于‘未更新’状态下的任何请求，也要把这个事实通知应用。然后可在应用的控制下进行附加的清理。

服务数据管理模块的作用之一是为多路分解器的过滤器编制程序。为了实现这种功能并使得能快速访问所需数据，它保留着它可以访问的网络或若干网络的物理结构的映像。

文件(a)和(b)定义十种表，后者给出有关网络的配置，被传送的多信道数据包，服务和事件的信息。通过特定的PID(包识别数据)值和特定的表标识符值(table-id)来鉴别表，这些值的数值由所述文件定义。每个表含有版本标识符，后者使得有可能确定，这个表的内容从表的一次传输到下一次传输是否已经改变。

这里我们所关心的表是叫做NIT(代表网络信息表)的表。NIT表包括关于给定的传输网络的信息，特别是每传输通道(或传送流)可获得的服务清单。

数据管理模块建立网络、信道和可获得的服务的内部索引。在启动译码器或更新NIT表时，分配给可获得的每项服务一个逻辑关键字。这个关键字是在由模块保持的数据库中关于这项服务的索引。

在DVB系统中，可按一种唯一的方式经由包括下列变量的路径安排服务：

-network id(网络标识符)，

-(transport_stream_id；original_network_id)对，

即(传送_流_标识符；原始_网络_标识符)对，

-service_id(实际服务标识符)。

三个变量是通过16位编码的自然整数。

产生三种类型的清单，一种关于网络的清单，一种关于每个网络的信道清单以及一种关于每个信道的服务清单。

每当多路分解包括一个新网络的NIT表时，就产生网络清单的一个成分。为了实现这个，要筛选其PID等于0×0010的传送数据包。这些数据包实际上包括另外用变量table_id(表_标识符)鉴别的NIT表。一个4位代码按照多路分解相应的表的顺序与每个网络相联系。该代码是用于包括有关这个网络的信息的结构的地址指针的索引。

NIT表包括关于这个网络的信道清单以及关于每个信道的可得到的服务清单。

为网络清单中的每个网络产生一个信道清单。用5位来表明信道清单的每个成分。该清单含有用于包括每个信道特有的数据的结构的地址指针。数据库中用来鉴别信道的逻辑关键字由用于网络的4个索引位再加上这个网络的信道索引的5位组成。

为每个信道产生一个服务清单，包括用NIT表描述的服务标识符。通过7位指明清单中的每项服务。因而数据库中服务的逻辑关键字总计包括16位：4个网络索引位，5个信道索引位以及7个服务索引位。

将用表示这个事件的16位(表的event_id变量)识别服务事件，将把有关服务的逻辑关键字的16位附加其上。

根据下列结构组织数据库结构(除去事件)：

数据库
网络清单地址

网络清单
		0	网络地址
1	网络地址
		2	网络地址
3	网络地址
		4	网络地址
5	网络地址

6	网络地址
		7	网络地址
	下一网络阵列地址

网络
	网络标识符(“network_id”)
网络名称
	信道清单地址

信道清单
		0	信道地址
1	信道地址
		2	信道地址
3	信道地址
		4	信道地址
5	信道地址
		6	信道地址
7	信道地址
			下一信道阵列地址

信道
	信道标识符(“TransportStream_id”)
原始网络标识符
	服务清单地址

服务清单
		0	服务地址
1	服务地址
		2	服务地址
3	服务地址

4	服务地址
		5	服务地址
6	服务地址
		7	服务地址
	下一服务阵列地址

服务
	服务标识符(“service_id”)
服务名称(“service_name”)
	状态(“running_status”)
当前下一事件地址

当前下一事件
	当前事件标识符(“event_id”)
当前事件开始(“start_tune”)
	当前事件持续时间(“duration”)
当前事件状态(“running_status”)
	当前事件名称长度(“event_name_length”)
当前事件名称
	当前事件说明长度(“text length”)
当前事件说明
	下一事件标识符(“event_id”)
下一事件开始(“start_tune”)
	下一事件持续时间(“duration”)
下一事件状态(“running_status”)
	下一事件名称长度(“event_name_length”)
下一事件名称
	下一事件说明长度(“text_length”)
下一事件说明

名称包含术语“地址”的变量是指向与数据结构开始对应的存储器区域的指针。

其它变量与从数据流中取出的信息相对应。为了帮助理解，使这些变量后的括号和引号内跟随有在文件(a)中所使用的名称。

将要指出，把网络、信道和服务清单中的每个清单组织成阵列，每个阵列一方面由指向网络、信道或服务类型的8个指针组成，另一方面由指向包括清单的剩余部分的可能阵列的一个指针组成。当没有其它阵列时，即当阵列包括清单末尾的成分时，这个最后的指针是零。

阵列包括八个成分，这相当于2的幂。在这种情况下，这使得有可能通过屏蔽信道索引的最后三位确定含有所需指针的阵列。

数据库阵列含有指向包括网络清单的第一部分的阵列的指针。

网络清单阵列含有指向最先的八个网络的指针。根据本示范实施例，最多有包括全部网络清单的两个网络清单阵列。

网络阵列包括与给定网络有关的信息以及指向与这个网络有关的信道清单的第一个阵列的指针。

其它阵列的结构与刚才陈述的类似。此外，易于把它延伸到事件和其它类型的数据。

根据一个不同的实施例，有关涉及网络、信道和服务结构的数据的请求是永久型请求，其目的是使阵列映像在数据库中经常保持在最新状态。

在它们与管理模块交换时，应用使用逻辑关键字。这些被模块转换为与存储信息项的位置对应的存储器地址。它们构成存储在请求表中的参数的一部分。

图5是在存在包括两个信道的网络，而每个信道本身包括两项服务的情况下，管理模块的数据库简图。

上述应用请求表给出了由应用提出的请求清单。根据本实例，正在进行中的唯一请求是一种永久型请求，用来检索网络上存在的服务清单。

在此情况下，假定网络中有两个信道，需要两个基本请求来说明应用请求：把每个服务清单要不就是每个信道中的一个基本请求写入基本请求表。

在图中，与每个基本请求对应的过滤器(筛选程序)出现在基本请求表的左侧。

假定在图5所示的时刻，已经第一次输入了服务清单。给定应用请求的永久特性，在获得预期的数据的第一时刻之后保留相应的筛选程序以及有关这个请求的数据库内容。

标记加入清单的分支和这个清单中的成分的数字与清单中这个成分索引(逻辑关键字)相符合。

此时应用设法获得网络中的正在进行的事件的清单。在每项服务有一个正在进行的事件；这使得有必要筛选相应的‘当前/下一个EIT’表(“事件信息表”)。在说明的剩余部分将要假定，确实为每项服务广播这样的表，也就是说，对于这些服务来说服务说明表的标志EIT_present_following_flag具有数值1。

对于一项给定的服务来说，由应用发出的请求包括下列参数：

-请求标识符，

-请求的类型，

-有关服务的逻辑关键字，

-用来从SI模块接收多路分解的数据的缓冲存储器的存储器地址。

首先将要假定，库不含有与进行中的事件或下一批事件有关的数据项，也就是说，基本请求表不包含与这些数据有关的基本请求。

例如，节目指南应用寻找属于第一个网络(“0”)的第一个信道(“0”)的第二项服务(“1”)的当前和下一事件。这个请求接着有一个用户命令，以便显示有关一项给定服务正在进行中的节目以及紧接着进行中的节目的节目的信息，例如Canal+(法国电视频道)。

因此有关服务的逻辑关键字是：

0000 00000 000001

相应的应用请求被传送到SI模块。这个请求将是永久型。假定在这个例子的范围内，应用只要求一项服务的当前和下一事件，这个请求是基本的并不应由SI模块进一步分解。该基本请求被写入相应的请求表。

另外，SI模块为多路分解器的过滤器拟定程序，使得能正确进行有关这个请求的EIT表的筛选。根据文件(a)，包括“当前/下一个”EIT表的数据包的PID值是0×0012。借助于逻辑关键字在数据库中可获得服务标识符(“service_id)，信道标识符(“transport_strean_id”和“original_network_id”)的值，为了从那些广播中确定哪个是正确的EIT表，这些值是必需的。此外，把基本请求表中的基本请求状态设置为“等待”状态。

在检测到正确的EIT表之后，SI模块从数据包中取出要存储在其内部数据库中的数据值。根据本示范实施例，这些数据是出现在上述“CurrentNextEvent”(“当前下一事件”)数据结构中的那些。SI模块通知请求的应用有数据并把它们复制到事先由应用保留的缓冲存储器中。在数据库中，用与“CurrentNextEventAddress”(“当前下一事件地址”)结构对应的存储器地址为与由逻辑关键字指出的路径对应的服务服务结构的“CurrentNextEventAddress”地址指针拟定程序。基本请求表中的基本请求状态从“等待”转换为“准备就绪”。

应该指出，每项服务最多有一个当前事件和一个下一事件。因此，在这种特定情况下，没有理由给“CurrentNextEvent”(“当前下一事件”)数据结构的结构加索引，因为它已经由导致该项服务的逻辑关键字完全确定，而它随服务而定。

如果装入包含按时间顺序的事件序列的EIT表的内容时，情况将会不同。在这种情况下，可证明加索引是必要的。

在这一或那一时间，例如在用户重新关闭节目指南的命令以后，应用将取消其请求。在这种情况下，如果没有更多的涉及与当前/下一事件有关的基本请求的正在进行的应用请求时，SI模块释放多路分解器的过滤器并把目前的系统时钟值写入原始请求表的“日期”区域。假定实际上已把数据多路分解并事先存储在库中，请求的状态变为“未更新”，这里的情况就是这样。在相反的情况下，将会简单地从表中删除它们。

根据一个不同的实施例，管理模块本身产生与网络结构(特别是网络清单和有关的信道清单)有关的某些请求并把它们永久保存。

应该指出，本发明并不只是局限于通过卫星，无线电中继站或电缆传送数据，而是可在数据流中周期性地出现数据或数据包的任何系统中实现。对于记录的或预先记录的数据流来说，情况尤其是这样。

此外，鉴于给出的例子更详细地涉及服务数据，很明显，本发明并不局限于这类数据。例如，可按类似的方式处理所谓专用数据。

Claims (12)

1．在数字电视系统中用于管理服务信息的方法，就系统的接收机而言，其特征在于它包括下列步骤：

-为用来从数字数据流中有选择地提取信息的装置(5)编制程序；

-至少存储取出的某些信息；

-依据关于这个信息项为所述有选择的提取装置的编程，标明存储的信息项是更新的或未更新的。

2．根据权利要求1的方法，其特征在于在由应用提出提取信息项的请求以后，按如下所述进行编程和存储步骤：

-如果要求的信息项存在于数据库中，在从数据流中提取信息项以后，把信息项传送给应用，为从数据流中有选择地提取信息项的装置编制程序并更新数据库中的信息项；

-如果要求的信息项不在数据库中，在从数据流中取出它以后，为有选择提取的装置编制程序并把信息项存储在译码器的数据库中。

3．根据权利要求1或2之一的方法，其特征在于有选择提取的装置包括多路分解器。

4．根据权利要求1到3之一的方法，其特征在于把存储的信息项标明为更新的在提取它以后的整个时间间隔内都是有效的，而且在该时间内为有选择提取的装置编程序，以便从其中取出新的值。

5．根据权利要求1到4之一的方法，其特征在于连同为寻找这个信息项的装置解除编程，在从流中取出信息项之后，把存储的信息项标明为未更新的。

6．根据权利要求5的方法，其特征在于标明信息项为未更新的包括把这个信息项与日期相联系，在该日期为与该信息项对应的有选择提取装置解除编程。

7．根据权利要求6的方法，其特征在于如果接收机的数据库变得饱和时，按照日期长久的顺序删除被标明为未更新的信息。

8．根据上述权利要求之一的方法，其特征在于和这个信息项一起，把给信息项作标记通知已请求该信息项的应用。

9．根据上述权利要求之一的方法，其特征在于直观地识别由应用在屏幕上显示的未更新的信息项是未更新的。

10．在其中传送服务信息、特别是节目指南信息的数字电视系统中的接收机，所述接收机包括：

数据流多路分解器(5)，所述多路分解器包括用来从所述流中有选择地提取信息的可编程滤波器，

所述接收机的特征在于它包括：

-用来容纳所述接收机的数据库的存储器(12)，所述数据库包括以前取出的信息；

-用来把数据库的信息标明为更新的或未更新的装置(23)。

11．根据权利要求10的设备，其特征在于按照所述多路分解器(5)的编程的函数标明为更新或未更新的。

12．根据权利要求10或11之一的设备，其特征在于它进一步包括用来标明未更新信息的时钟。

Images