CN1277770A

CN1277770A - 数据发送控制方法、数据发送方法和设备以及接收设备

Info

Publication number: CN1277770A
Application number: CN99801581A
Authority: CN
Inventors: 北里直久; 斋藤润也; 村田贤一; 片山靖
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 1998-07-14
Filing date: 1999-07-14
Publication date: 2000-12-20
Anticipated expiration: 2019-07-14
Also published as: KR20010023971A; KR100641594B1; US20060117370A1; US6966065B1; EP1014620A1; EP1705918A2; US8209734B2; EP1014620A4; EP1705918B1; EP1705918A3; CN100382498C; WO2000004676A1; EP1014620B1; DE69943228D1

Abstract

客户机向服务器发送一事件Event∷Subscribe(“DSI_CHANGED”)。服务器向客户机返回为“DSI_CHANGED”事件设置的事件号码。在获得该事件号码之后,客户机向服务器发送Event∷notify，并请求包括“DSI_CHANGED”的某事件产生通知。当在接收的karrusel的DSI中有变化时,即,当在接收到Event∷notify之后的某个时刻产生“DSI_CHANGED”事件时,服务器向客户机发送相应于该“DSI_CHANGED”事件的事件号码,作为对EVent∷notify的响应。在服务器通知客户机产生了事件号码之后,在产生事件号码之前的karrusel的内容继续使用一时间段,在该时间段内客户机向服务器发送Session∷detach。

Description

数据发送控制方法、数据发送方法和设备以及接收设备

技术领域

本发明涉及数据发送控制方法、数据发送方法、数据发送设备、以及能够接收与主TV(电视)节目广播相关的数据服务的接收设备，所述主TV节目广播比如为数字卫星广播等。

背景技术

近年来，数字卫星广播已广为传播。数字卫星广播与例如现有的模拟广播相比，具有很强的抗噪声性及抗衰落性，并且能够发送高质量的信号。可以提高频率使用效率并且还可以实现多频道。具体地讲，在数字卫星广播中，可以由一个卫星负责数百个频道。在这种数字卫星广播中，配备了许多个专用频道，如体育、电影、音乐、新闻等等。在那些专用频道中，广播相应于每个专用内容的节目。

已经提出了这样一种方法：该方法能够使用户使用前面提到的卫星广播系统，在观看广播屏幕的同时，下载如音乐片段等的音频数据或者对某些产品进行购物交易，就象所谓的电视购物。也就是说，数据业务广播是作为数字卫星广播系统与原始广播内容平行进行广播的。

例如，在下载音乐片段数据的情况下，音乐片段数据与广播侧的广播节目一起多路复用并播出。当下载了音乐片段数据时，用户能够通过显示GUI(图形用户界面)画面(即用于下载的操作画面)进行交互式操作。然而，要输出到GUI画面的数据也要进行多路复用并播出。

在拥有接收设备的用户侧，在选择所需频道的状态下，通过接收设备的预定操作显示并输出要下载音乐片段数据的GUI画面。通过用户对显示的操作画面进行的操作，数据提供给例如与接收设备连接的数字音频设备，并且使该数据记录下来。

作为如上所述的下载音乐片段数据的GUI画面，考虑到这样一种结构：除了比如部件类(parts-like)图像数据、文本数据等形成GUI画面的信息之外，还将比如用于按照预定操作进行音频输出的音频数据等的单元数据(文件)作为对象进行处理，并且该对象的输出格式是由预定系统通过方案说明书(scenario description)来规定的，以便相对于操作画面实现所需的显示格式以及所需的输出格式等。

用于通过由描述信息指定而实现某些目的的功能的显示画面(这里也包括音频输出等)，就象上面提到的GUI画面，在此称为“场景(scene)”。“对象”表示其输出格式根据描述信息规定的图像、音频声音、文本等的单元信息。在发送时，描述信息本身的数据文件也作为一个“对象”处理。

用于实现场景显示以及在该场景显示上进行音频输出的对象例如由预定发送系统进行编码并发送。

在接收设备侧，接收相应于发送系统的数据，对接收数据执行解码处理，获得例如对要显示的场景所必需的每个对象的一组数据，并将该数据作为场景输出。

考虑到拥有接收设备的用户的使用环境，希望使用于由接收设备接收的数据服务的数据能够按照预定发送系统尽可能有效地执行，并使比如更新要显示和输出的场景内容、转换场景、和主TV广播节目及例如静止图像等的附加信息的同步显示等的处理过程能够通过小型处理过程尽可能迅速地执行。

本发明的概述

本发明的一个目的是提供一种数据发送控制方法、数据发送方法、数据发送设备及接收设备，其中对于用于由接收设备接收的数据服务的数据的处理过程能够尽可能有效地执行。

另外，本发明的另一个目的是提供一种数据发送控制方法、数据发送方法、数据发送设备及接收设备，其中可尽可能迅速地在接收设备侧获得对场景所必需的数据，并且例如还可以尽可能迅速地执行场景输出的切换等。

为实现本发明的上述目的，本发明的目的是提供一种数据发送控制方法、数据发送方法、数据发送设备及接收设备，这些方法和设备可由尽可能小规模的电路来实现，而不需要例如具有大容量的缓冲器等设备。

考虑到前面所提到的问题，按照本发明，按照其中循环数据单元由要传送的所需数据形成并且在所需时间段内重复传送该循环数据单元的一种传送系统，来执行数据发送控制，以便执行循环数据单元切换处理，从而可以使一种事实通知给使用来自接收所述循环数据单元的服务器侧的循环数据单元的客户机，该事实是，循环数据单元的内容已被切换。

按照上述结构，至少客户机可以知道这样的事实：循环数据单元的内容已被切换，并且该客户机可据此执行所需的相应处理。

按照本发明，作为一种相应于其中形成的数据发送单元包括与预定系统的方案(scenario)说明书相关的对象的数据传送系统的数据发送控制方法，进一步形成的循环数据单元包括要在某个预定时间段内传送的一个或多个数据发送单元，并且重复传送该循环数据单元，还执行对象更新和通知处理，其中可将一种事实通知给使用来自接收所述循环数据单元的服务器侧的循环数据单元的客户机，该事实是，包括在所述循环数据单元中的对象已被更新。

按照上述结构，客户机至少可以知道这样的事实：某些对象已相对于形成循环数据单元的数据被更新，并且该客户机可据此执行所需的相应处理。

此外，按照本发明，在发送多媒体数据的数据发送方法中，事件通知是由时间信息和事件名称构成的，表示一个事件要立即产生的代码定义在该时间信息的位置处，当客户机想立即产生一个事件时，表示所述事件要立即产生的代码安排在事件通知的事件信息的时间信息的位置处，并对其进行发送

将不能作为时间信息出现的用于包含事件名称和时间信息的流事件的时间信息的所述代码中的一种(例如，全为“1”)定义为具有“事件要立即产生”的含义。因此，例如，如果将时间信息的位置设定为全“1”，并且发送流事件，则该事件在接收侧立即产生。因此，当客户机想要通过在略微提前于产生事件的定时的定时处将时间信息的位置例如设定为全“1”来发送流事件，从而使显示数据与视频图像或音频声音同步时，所述显示数据可以与所述视频图像或音频声音同步。在接收侧不需要有时间管理。

此外，按照本发明，能够使必要场景的数据在接收设备侧尽可能迅速地获得，因而可考虑这样的目的：例如使场景输出的切换等尽可能迅速地执行。为实现上述目的，例如，本发明还考虑这样的目的：能够使上述结构通过尽可能小规模的电路来实现，而不必具有大容量的缓冲器等设备。

为达到此目的，使形成一个场景的场景数据相应于一个或多个信息发送单元，并且，一种接收发送信息的接收设备，其中包含一个或多个信息发送单元的发送数据是周期性发送的，所述接收设备包含：接收装置，用于接收所述发送信息并将其作为接收数据取出；存储器装置，可临时存储基于信息发送单元的数据；场景数据取出装置，用于从接收数据中提取所述基于信息发送单元的数据，使提取出的数据保持在所述存储器装置中，将作为存储在所述存储器装置中的场景数据的信息发送单元发送到用于存储场景数据的场景数据存储装置，并使所述信息发送单元存储在所述场景数据存储装置中；场景输出装置，用于使场景输出通过使用来自存储在所述场景数据输出装置中的场景数据的所需场景数据来执行；信息获得装置，用于从由所述接收装置接收的发送信息中获得表示场景优先级的场景优先级信息；和控制装置，用于控制所述场景数据取出装置，以便根据由所述信息获得装置获得的场景优先级信息，来选择作为要从接收数据中提取出并存储在所述存储器装置中的场景数据的信息发送单元。

按照本发明的上述结构，作为用于接收的接收设备，该设备相应于其中包含比如一个或多个信息发送单元(模块)的发送数据被周期性发送的发送系统(karrusel系统)，首先，通过将形成一个场景的场景数据相应于信息发送单元的状态用作先决条件，根据场景优先级来取出信息发送单元，并且取出的信息发送单元存储在场景数据取出装置中。也就是说，对于确定要根据场景优先级从接收数据中提取并取出的模块进行规定。因此，场景按照场景优先级从高优先级开始存储在场景数据取出装置中。

附图的简要说明

图1是说明本发明一个实施例的数字卫星广播接收系统的构成示例的方框图；

图2是说明在该实施例中的接收设施的构成示例的方框图；

图3是说明用于IRD的遥控器的外观的前视图；

图4A和4B是说明广播画面和GUI画面之间的切换的示例图；

图5是说明地面站的构成示例的方框图；

图6是说明从地面站发送的数据的图；

图7A到7H是说明发送数据的时分复用结构的解释图；

图8A到8F是说明由DSM-CC形成的发送格式的解释图；

图9是说明数据业务的目录(directory)结构的例子的解释图；

图10A到10C是传输流的数据结构图；

图11A到11D是说明PSI的表结构的解释图；

图12是说明IRD的结构的解释图；

图13是说明U-UAPI接口的通用控制操作的例子的解释图；

图14是说明作为第一个例子的karrusel(卡路塞尔)切换通知控制的解释图；

图15是说明作为第二个例子的karrusel切换通知控制的解释图；

图16是说明作为第一个例子的对象更新通知控制的解释图；

图17是说明作为第二个例子的对象更新通知控制的解释图；

图18是说明在该第二个例子中在客户机侧配备的表结构的解释图；

图19是说明作为第三个例子的对象更新通知控制的解释图；

图20A和20B是说明在该第三个例子中在客户机侧配备的表结构的解释图；

图21是说明用于数据业务的目录结构的映射的一个例子的解释图；

图22是作为实施例说明用于数据业务的目录结构的映射的一个例子的解释图；

图23是作为实施例说明用于数据服务的目录结构的映射的另一个例子的解释图；

图24A到24C是说明相应于上述实施例而对场景数据模块执行的取出操作的解释图；

图25是说明场景转换的例子的解释图；

图26是说明按照图17所示场景的转换例子而在下一个场景管理器中管理的场景优先级的例子的解释图；

图27是说明按照图17所示场景的转换例子而在所述下一个场景管理器中管理的场景优先级的例子的解释图；

图28A和28B是说明按照从图18到图19的转换所示出的场景优先级变化而对场景数据的模块进行的取出操作的解释图；

图29是用于实现相应于实施例中的场景切换的模块分配的流程图；

图30A到30C是用于解释事件的一个例子的示意图；

图31是用于解释脚本的示意图；

图32是说明流事件分组结构的示意图；

图33A到33D是用于解释流事件序列的一个例子的定时图；

图34A到34D是用于解释流事件序列的另一个例子的定时图；

图35A到35E是用于解释事件的另一个例子的示意图；和

图36A到36E是用于解释流事件序列的再一个例子的定时图。

实施本发明的最好模式

下面将描述本发明的一个实施例。作为本发明所应用的一种系统，作为例子提出了这样一种系统：利用数字卫星广播来播出节目，并且在接收设备侧，可下载诸如有关该节目的音乐片段数据(音频数据)等的信息。

下面将以下列顺序进行解释。

1.数字卫星广播系统

1-1.整体结构

1-2.用于GUI画面的操作

1-3.地面站

1-4.发送格式

1-5.IRD

2.karrusel切换时的处理过程

2-1.第一个例子

2-2.第二个例子

3.对象更新时的处理过程

3-1.第一个例子

3-2.第二个例子

3-3.第三个例子

4.模块到队列的分配

5.主视频图像●音频数据的再现和附加数据的再现之间的同步

1.数字卫星广播系统

1-1.整体结构

图1示出了按照一个实施例的数字卫星广播系统的整体结构。如图1所示，来自电视(TV)节目素材服务器6的电视节目广播素材、来自音乐片段素材服务器7的音乐片段数据素材、来自音频附加信息服务器8的音频附加信息、以及来自GUI数据服务器9的GUI数据，都发送到数字卫星广播的地面站1。

TV节目素材服务器6是提供普通广播节目素材的服务器。从该电视节目素材服务器发送的音乐广播素材包含运动图像和音频声音。例如，在音乐广播节目的情况下，用于促销一个新音乐片段的运动图像和音频声音是利用TV节目素材服务器6的运动图像和音频声音素材来播出的。

音乐片段素材服务器7是利用音频频道来提供音频节目的服务器。音频节目素材仅包括音频声音。音乐片段素材服务器7将多个音频频道的音频节目素材发送给地面站1。

在每个音频频道的节目广播中，相同的音乐片段在预定单元时间内重复播出。每个音频频道都是独立的，并且还考虑到音频频道的各种使用方法。例如，在一个音频频道中，最新日本流行歌曲的少数几个音乐片段在某个预定时间段内重复播出，而在另一个音频频道中，最新外国流行歌曲的少数几个音乐片段在某个预定时间段内重复播出。

音频附加信息服务器8是提供从音乐片段素材服务器7输出的音乐片段的时间信息等的服务器。

GUI数据服务器9提供“GUI数据”，以形成用于用户操作的GUI画面。例如，在关于下面将解释的音乐片段的下载的GUI画面的情况下，提供了形成要发布的音乐片段的列表页和每个音乐片段的信息页的图像数据、文本数据、形成唱片封面(album jacket)的静止图像的数据等。此外，用于在接收设施3一侧显示节目表的EPG数据也从GUI数据服务器9提供，该节目表是所谓的EPG(Electrical Program Guide，电子节目指南)。

作为“GUI数据”，例如，采用MHEG(Multimedia HypermediaInformation Coding Experts，多媒体超媒体信息编码专家组)系统。按照MHEG，每个多媒体信息、过程、操作等以及它们的组合都被看作对象，对这些对象进行编码，之后，将它们设置为方案说明书的国际标准，以形成一标题(例如，GUI画面)。假定在本实施例中采用MHEG-5。

地面站1对从TV节目素材服务器6、音乐片段素材服务器7、音频附加信息服务器8和GUI数据服务器9发送的信息进行多路复用并发送它们。

在本实施例中，由MPEG(Moving Picture Experts Group，运动图像专家组)2系统对从TV节目素材服务器6发送的视频数据进行压缩编码，并且由MPEG音频系统对音频数据进行压缩编码。例如，由MPEG音频系统或者ATRAC(Adaptive Transform Acoustic Coding，自适应变换声音编码)系统对从音乐片段素材服务器7发送的音频数据进行压缩编码。

在多路复用时，采用来自密钥信息服务器10的密钥信息对数据进行加密。下面将描述地面站1的结构的例子。

来自地面站1的信号通过卫星2由每个家庭的接收设施3接收。在卫星2中安装了多个转发器。一个转发器例如具有30Mbps的发送能力。作为每个家庭的接收设施8，配备了抛物面天线11、IRD(Integrated Receiver Decoder，集成接收器解码器)12、存储设备13及监视设备14。配备的遥控器64执行用于IRD12的操作。

通过卫星2播出的信号由抛物面天线11接收。接收信号由附接到抛物面天线11的LNB(Low Noise Block Down Converter，低噪声块下变换器)15转换为预定频率，并提供给IRD 12。

作为IRD 12的示意性操作，从接收信号中选出预定频道的信号，并从选出信号中解调作为节目的视频数据和音频数据，并且将其作为视频信号和音频信号输出。IRD 12还根据与作为节目的数据一起多路复用并发送的GUI数据来输出GUI画面。IRD 12的这种输出例如提供给监视设备14。这样，在监视设备14中，执行对由IRD 12所接收和选择的节目的图像显示和音频输出，并且可按照用户的操作显示GUI画面，如下面将解释的。

存储设备13用于存储由IRD 12下载的音频数据(音乐片段数据)。对于存储设备13的种类没有特殊限制。可以使用MD(Mini Disk，迷你盘)记录器/播放器、DAT记录器/播放器、DVD记录器/播放器，等等。作为存储设备13，音频数据还可以通过使用个人计算机设备不但存储于硬盘中，还能存储于包括CD-R等的可记录介质中。

作为本实施例的接收设施3，如图2所示，MD记录器/播放器13A具有相应于用作数据传输标准的IEEE 1394的数据接口，并且可用作图1所示的存储设备13。

相应于图中所示IEEE 1394的MD记录器/播放器13A由IEEE 1394总线16连接到IRD 12。结果，在本实施例中，作为由IRD 12接收的音乐片段的音频数据(下载数据)可在其经过由ATRAC系统执行的压缩处理的状态下直接取出并记录。当MD记录器/播放器13A和IRD 12由IEEE 1394总线16相连时，除了音频数据处，还可以记录唱片的封面数据(静止图像数据)和诸如歌词(word)的文本数据等。

IRD 12例如可通过电话线4与收费服务器5通信。在IRD 12中插入IC卡，该IC卡中存有各种信息，如后面将解释的。例如，现在假定下载一个音乐片段的音频数据，则有关于此的历史信息存储在IC卡中。该IC卡中的信息在预定的时刻通过电话线4发送给收费服务器5。收费服务器5按照所发送的历史信息来设置钱数，并对用户进行收费。

从上述说明中可以理解，在本发明所应用的系统中，地面站1对用作来自TV节目素材服务器6的音乐节目广播素材的视频数据和音频数据、用作来自音乐片段素材服务器7的音频频道素材的音频数据、来自音频附加信息服务器8的音频附加信息、和来自GUI数据服务器9的GUI数据进行多路复用并发送多路复用的数据。

当上述广播由每个家庭的接收设施3接收到时，所选频道的节目例如可由监视设备14监视。首先，EPG(电子节目指南)画面利用与节目数据一起发送来的GUI数据显示成为GUI画面，并且可进行节目的搜索等。其次，在本实施例的情况下，通过例如使用用于特殊服务而不是普通节目广播的GUI画面执行所需操作，可以接收到除了由广播系统提供的普通节目的监视以外的其它服务。

例如，如果显示用于下载音频(音乐片段)数据的GUI画面平面，并且使用该GUI画面进行操作，则用户可下载所需音乐片段的音频数据，并将记录和存储到存储设备13中。

在本实施例中，用于提供特殊服务而不是如上所述的与用于GUI画面的操作相伴随的普通节目广播的数据业务广播，也称为“交互式广播”，因为也存在具有交互式性能的情况。

1-2.用于GUI画面的操作

下面将参照图3和图4示意性地解释上述交互式广播的一个使用例子，即用于GUI画面的操作的一个例子。下面将描述下载音乐片段数据(音频数据)的情况。

首先，将具体地参照图3描述用来使用户执行用于IRD 12的操作的遥控器64的操作键中的主要操作键。

在图3中示出了遥控器64的操作面板表面，在该表面上安排了各种键。在所述各种键中，下面将描述电源键101、数字键102、屏幕显示转换键103、交互式转换键104、EPG键板单元105和频道键106。

电源键101是用于打开/关闭IRD 12的电源的键。数字键102是在通过指定一个数字而切换频道或者例如在必须在GUI画面上进行数字值输入操作时操作的键。

屏幕显示转换键103是用于例如在普通广播画面和EPG画面之间进行切换的键。例如，如果在由屏幕显示转换键103调用了EPG画面的状态下操作安排在EPG键板单元105中的各个键，则可以使用电子节目指南的显示画面进行节目搜索。EPG键板单元105中的箭头键105a也可以用于GUI画面上各种服务的光标移动等，对此将在下文中描述。

提供的交互式转换键104用于在普通广播画面和用于广播节目中各种相关服务的GUI画面之间进行切换。提供的频道键106是用于按照频道号码的升序或降序顺序切换IRD 12中的播放台选择频道的键。

然而，本实施例中的遥控器64构造成能使例如用于监视设备14的各种操作也可以执行，并且也可以提供与这些操作相应的各种键，但在此省略了对相应于监视设备14的各个键等的解释。

下面将参照图4描述用于GUI画面的操作的一个具体例子。

当由接收设施3接收到广播并选择了相应频道时，基于从TV节目素材服务器6提供的节目素材的运动图像显示在监视设备14的显示屏上，如图4A所示。也就是说，显示普通节目的内容。例如，现在假定显示音乐节目。还假定该音乐节目还伴随着一个音乐片段的音频数据的下载服务(交互式广播)。

现在，假定用户在显示音乐节目的状态下例如操作遥控器64的交互式转换键104，则显示屏幕切换到用于下载音频数据的GUI画面，如图4B所示。

在该GUI画面中，首先，显示在图4A中的由来自TV节目素材服务器6的视频数据形成的图像缩小并显示在屏幕左上部分中的TV节目显示区21A。

由音频频道播出的每个频道的音乐片段的列表21B显示在屏幕的右上部分中。文本显示区21C和封面显示区21D显示在屏幕的左下部分中。此外，歌词显示按钮22、概况显示按钮23、信息显示按钮24、预定记录按钮25、预定的列表显示按钮26、记录历史显示按钮27和下载按钮28显示在屏幕的右侧。

用户在观看显示在列表21B中的音乐片段题目的同时，可搜索所感兴趣的音乐片段。如果发现了所感兴趣的音乐片段，则用户操作遥控器64的箭头键105a(在EPG键板单元105中)，将光标移到显示该音乐片段的位置，然后，执行一回车操作(例如，按压箭头键105a的中心位置)。

这样，就可以监视到光标所指定的音乐片段。也就是说，由于在预定单位时间内在每个音频频道重复播出相同的音乐片段，频道切换到由IRD 12以上述操作选择的音乐片段的音频频道，并且产生音频声音，同时TV节目显示区21A的画面原样保持，从而可以收听该音乐片段。在这种情况下，这种音乐片段的MD封面的静止图像显示在封面显示区21D中。

例如，如果光标在上述状态下指定到歌词显示按钮22，并执行一回车输入操作(下文中，将光标指定到显示按钮并执行回车操作的操作称为“按下按钮”)，则音乐片段的歌词在与音频数据同步的时刻显示在文本显示区21C中。类似地，通过按压概况显示按钮23或者信息显示按钮24，在文本显示区21C中显示相应于该音乐片段的艺术家的概况、音乐会信息等。如上所述，用户可以了解目前正在发布哪个音乐片段，并进一步了解关于每个音乐片段的详细信息。

当用户想购买所监视的音乐片段时，他需按压载按钮28。当按下下载按钮28时，所选音乐片段的音频数据被下载并存储到存储设备13中。与音乐片段的音频数据一起还可以下载其歌词数据、艺术家的概况信息、封面的静止画面等。

每次如上所述地下载音乐片段的音频数据，其历史信息都存储在IRD 12中的IC卡中。例如每月一次地将存储在IC卡中的信息取到收费服务器5中，并按照数据服务的用户历史对用户进行收费。这样，还可以保护要下载的音乐片段的版权。

当用户想要事先预定下载时，他需按压预定记录按钮25。通过按压该按钮，切换GUI画面的显示，并且在整个屏幕上显示可预定的音乐片段的列表。例如，该列表可以一个小时、一个星期、一个频道等为单位显示搜索到的音乐片段。当用户选择了他想要从列表中预定下载的音乐片段时，关于这些音乐片段的信息登记到IRD 12中。当他想要确认其下载已被预定的音乐片段时，可通过按压预定的列表显示按钮26在整个屏幕上显示预定的音乐片段的列表。以此方式预定的音乐片段由IRD 12在预定时间下载并存储到存储设备13中。

当用户想要确认下载的音乐片段时，可通过按压记录历史按钮27在整个屏幕上显示已被下载的各音乐片段的列表。

如上所述，在本发明所应用的系统的接收设施3中，音乐片段的列表显示在监视设备14的GUI画面上。通过按照GUI画面上的显示选择音乐片段，可监视该音乐片段。可以了解该音乐片段的歌词、艺术家的概况等。此外，可执行对各音乐片段的下载及它们的预定、下载历史及预定音乐片段列表的显示，等等。

此外，在下面的详细解释中，如图4B所示的GUI画面的显示、响应于用户对该GUI画面的操作而进行的GUI画面上的显示变化、以及音频输出是通过由上面提到的基于MHEG系统的方案说明书规定各对象之间的关系而实现的。这里所提到的对象是用作相应于图4B所示的每个按钮的部分的图像数据及显示在每个显示区中的素材数据。

在本发明中，假定相应于某个对象的信息的输出格式(图像显示、音频输出等)的环境是通过由方案说明书规定各对象之间的关系而实现的，所述方案说明书就象称为“场景”的GUI画面。还假定方案说明书的一个文件本身也是作为形成一个场景的对象所包括的。

如上所述，在本发明所应用的数字卫星广播系统中，使用多个音频频道来发布广播节目并且发布音乐片段的音频数据。通过使用所发布音乐片段的列表等可搜索所需音乐片段，并且音频数据可容易地存储在存储设备13中。

在数字卫星广播系统中，包括上面提到的音乐片段数据的下载在内，还将多种服务考虑为除了提供节目的服务以外的服务。例如，在播出称为电视购物的商品介绍节目的前提条件下，还可以考虑准备能使购买合同被签定的画面(就象GUI画面)的方法。

1-3.地面站

尽管上面已描述了作为一个实施例的数字卫星广播系统的概况，下面还将进一步详细描述该系统。首先参照图5描述地面站1的结构。

下面的描述是以下列条件为先决条件而进行的。

在本实施例中，当通过卫星2从地面站1向接收设施3进行发送时，使用DSM-CC(Digital Storage Media-Command and Control，数字存储介质-命令和控制)。

众所周知，按照DSM-CC(MPEG-部分6)系统，规定了用于搜索例如通过某些网络存储在数字存储介质(DSM)中的MPEG编码位流或者将所述流存储到DSM中的命令和控制系统。在本实施例中，DSM-CC系统用作数字卫星广播系统中的发送标准。

为通过DSM-CC系统发送数据广播业务(例如，GUI画面等)的内容(一组对象)，必须定义该内容的描述格式。在本实施例中，将上述MHEG系统用作描述格式的限定。

在图5所示的地面站1的结构中，TV节目素材登记系统31将从TV节目素材(source)服务器6获得的素材数据登记到AV服务器35。该素材数据发送到TV节目发送系统39。例如用MPEG2系统对视频数据进行压缩，并且例如由MPEG音频系统对音频数据进行打包。TV节目发送系统39的输出发送到多路复用器(MUX)45。

在音乐片段素材登记系统32中，来自音乐片段素材服务器7的素材数据即音频数据提供给MPEG音频编码器36A和ATRAC编码器36B。在MPEG音频编码器36A和ATRAC编码器36B，对所提供的音频数据执行编码处理(压缩编码)，之后，将其登记到MPEG音频服务器40A和ATRAC音频服务器40B。

登记到MPEG音频服务器40A中的MPEG音频数据发送到MPEG音频发送系统43A并在此对其打包，之后，发送到多路复用器45。登记到ATRAC音频服务器40B中的ATRAC数据以4倍速ATRAC数据发送到MPEG音频发送系统43B并在此对其打包，之后发送到多路复用器45。

在音频附加信息登记系统33中，用作来自音频附加信息服务器8的素材数据的附加信息登记到音频附加信息数据库37中。登记到音频附加信息数据库37的音频附加信息传送到音频附加信息发送系统41，同样也在此打包，并发送到多路复用器45。

在GUI素材登记系统34中，用作来自GUI数据服务器9的素材数据的GUI数据登记到GUI素材数据库38中。

登记到GUI素材数据库38中的GUI素材数据发送到GUI编辑(authoring)系统42，由该GUI编辑系统42对该数据执行一处理，以使其具有可作为GUI画面即图4中提到的“场景”输出的数据格式。

也就是说，作为发送到GUI编辑系统42的数据，例如，只要是下载音乐片段的GUI画面，可以是唱片封面的静止图像、诸如歌词等的文本数据、此外还有要按照操作输出的音频数据等。

尽管每个上述数据都称为单媒体(monomedia)数据，但在GUI编辑系统42中，对那些单媒体数据是采用MHEG编辑工具编码的，并且使得这些数据能够作为对象处理。

例如，MHEG-5的内容与规定对象之间的关系的方案说明书文件(脚本)一起形成，以获得如图4B所描述的场景(GUI画面)的显示格式，以及与操作相应的图像和音频数据的输出格式。

在如图4B所示的GUI画面中，在GUI画面上显示基于TV节目素材服务器6的素材数据的图像●音频数据(MPEG视频数据、MPEG音频数据)并输出音频，并且给出与操作相应的输出格式。

因此，作为上面提到的方案说明书，在GUI编辑系统42中，基于TV节目素材服务器6的素材数据的图像●音频数据、基于音乐片段素材服务器7的素材数据的MPEG音频数据、以及基于音频附加信息服务器8的音频附加信息都在必要时作为对象处理并且由MHEG的脚本(script)规定。

作为从GUI编辑系统42发送的MHEG内容的数据，可以是脚本文件、作为对象的各种静止图像数据文件、文本数据文件等。然而，所述静止图像数据是例如由JPEG(Joint Photograph Experts Group，联合图片专家组)系统压缩的640×480像素的数据，而所述文本数据是例如在800个字符以内的文件。

由GUI编辑系统42获得的MHEG内容的数据发送到DSM-CC编码器44。

在DSM-CC编码器44中，将发送的数据转换为传输流(下文中缩写为TS(Transport Stream，传输流))，该传输流的格式使得其能够多路复用到相应于MPEG2格式的视频和音频数据的数据流中、打包并输出到多路复用器45。

在多路复用器45中，在时间基础上多路复用来自TV节目发送系统39的视频包和音频包、来自MPEG音频发送系统43A的音频包、来自ATRAC音频发送系统43B的4倍速音频包、来自音频附加信息发送系统41的音频附加信息包、来自GUI编辑系统42的GUI数据包，并在从密钥信息服务器10(图1)输出的密钥信息的基础上对它们进行加密。

多路复用器45的输出发送到无线电波发送系统46，由该系统46执行一些处理，例如添加纠错码、调制、频率转换等，之后，将处理过的信号从天线向卫星2发送并输出。

1-4.发送格式

下面将描述以DSM-CC系统为基础指定的实施例的发送格式。

图6示出了当数据从地面站1向卫星2发送并输出时该数据的例子。如前面所提到的，图中所示的相应数据实际上已在时间基础上被多路复用。在本图中，如图6所示，时间t1和时间t2之间的间隔设定为一个事件，而从时间t2起的间隔设定为下一个事件。例如，在音乐节目频道的情况下，这里所用的“事件”表示改变一组排列成行的多个音乐片段的单位，并且在时间的情况下设定为30分或者1小时。

如图6所示，在时间t1和时间t2之间的间隔的事件中，通过运动图像的普通节目广播播出具有预定内容A1的节目。在从时间t2开始的事件中，播出具有内容A2的节目。通过普通节目播出运动图像和音频声音。

作为MPEG音频频道(1)到(10)，例如，配备了10个频道CH1到CH10。在这种情况下，在每个音频频道CH1，CH2，CH3，...，和CH10中，在播出一个事件的时间段内重复发送相同的音乐片段。也就是说，在时间t1和时间t2之间的间隔中的事件的时间段内，在音频频道CH1中重复发送音乐片段B1，在音频频道CH2中重复发送音乐片段C1，以类似于上述的方式，在音频频道CH10中重复发送音乐片段K1。这一点也通用于在那些音频频道之下示出的4倍速ATRAC音频频道(1)到(10)。

也就是说，在图6中，在MPEG音频频道和4倍速ATRAC音频频道中，括号()中作为频道号码示出的数字等同地指示了相同的音乐片段。括号()中示出的用作音频附加信息的频道号码的数字表示附加到具有相同频道号码的音频数据上的音频附加信息。此外，作为GUI数据发送的静止图像数据和文本数据也在每个频道内形成。这些数据是在MPEG2的传输包中时分复用的，如图7A到7D所示，并且在IRD 12的每个数据包中采用标题信息发送并重构，如图7E到7H所示。

在上面提到的图6和图7所示的发送数据中，至少用于数据业务(交互式广播)的GUI数据是按照DSM-CC系统逻辑上以下面的方式形成的。下面的解释仅限于针对从DSM-CC编码器44输出的传输流的数据。

如图8A所示，本实施例的由DSM-CC系统发送的所有数据广播业务都包括在名称为“服务网关”的路由目录中。作为包括在该服务网关中的对象，存在各种目录，如文件、流、流事件，等等。

在这些目录中，文件设定为单独的数据文件，如静止图像、音频声音、文本、以及由MHEG描述的脚本，等等。

例如，链接到其它数据业务和AV流(用作TV节目素材的MPEG视频数据和MPEG音频数据、用作音乐片段素材的MPEG视频数据和ATRAC音频数据，等)的信息包括在流中。该链接信息和时间信息同样也包括在流事件中。目录是组合彼此有关的数据的文件夹。

在DSM-CC系统中，如图8B所示，对单元信息和服务网关分别作为对象单元处理，并转换为BIOP消息的格式。

在关于本发明的描述中，由于文件、流和流事件这三个对象之间的区别不是主要的，因此那些文件可以由作为文件的对象来代表，并且将在下文中对其作出解释。

在DSM-CC系统中，形成称为模块的数据单元，如图8C所示。该模块表示通过转换数据使其包括变换为如图8B所示的BIOP消息的一个或多个对象并附加上BIOP标题而形成的可变长度的数据单元。这种模块在接收侧变为接收数据的缓冲单元，下文中将对其进行解释。

作为DSM-CC系统，对于在由多个对象形成一个模块的情况下的各个对象之间的关系没有特殊规定或限制。也就是说，极端上讲，即使一个模块由没有关系的各场景之间的两个或多个对象形成，也不违背DSM-CC系统的规定。

为采用称为由MPEG2格式规定的部分(section)的格式进行发送，如图8D所示，对模块机械地以称为“块”的原则上为固定长度的数据单元为基础进行划分。然而，模块中的最后一个块不必设定为规定的固定长度。对块进行划分的原因是基于这样的事实：在MPEG2格式中规定上述一个部分必须不超过4K字节。

在这种情况下，作为上面提到的块的数据单元和所述部分是类似的。

如上所述通过划分模块而得到的块通过附加标题而被转换为称为DDB(Download Data Block，下载数据块)的消息的格式，如图8E所示。

DSI(Download Server Initiate，下载服务器启动)和DII(Download IndicationInformation，下载指示信息)的控制消息与所述到DDB的转换并行形成。

DSI和DII是当在接收侧从接收数据中获得模块时所必需的信息(IRD 12)。DSI主要具有karrusel(模块)的识别符，对此将在后面解释，DSI还具有关于整个karrusel的信息等，比如karrusel旋转一次的时间、karrusel旋转的超时值(time-out value)信息。DSI还具有可以了解数据业务(在对象karrusel系统的情况下)的路由目录(服务网关)位置的信息。

DII表示相应于包括在karrusel中的每个模块的信息，并且具有关于每个模块的尺寸及版本、模块的超时值等的信息。

如图8F所示，上面所述的DDB、DSI和DII这三种消息周期性且重复地发送，以便相应于部分(section)的数据单元。因此，在接收侧，在任何时间都可以接收到包括例如获得目标GUI画面(场景)所必需的对象的模块。

在本说明书中，上述发送系统称为类似“旋转木马(merry-go-round)”式的“karrusel系统”，并且假定图8F中用图解法示出的数据发送格式称为karrusel。

作为包括在一个karrusel中的模块数目，可以包括多个模块。例如，一个数据服务所必需的多个模块也可以由一个karrusel发送。

将“karrusel系统”划分为“数据karrusel系统”级和“对象karrusel系统”级。具体地讲，对象karrusel系统是用于利用karrusel将具有比如文件、目录、流、服务网关等的属性的对象作为数据传送的系统，并且与数据karrusel系统的最大区别点在于可处理目录结构。对象karrusel系统用在本实施例的系统中。

图9示出相应于MHEG系统的作为数据服务的文件(MHEG应用程序文件)的目录结构。如上所述，对象karrusel系统具有能处理该目录结构的特征。

通常讲，用作服务域入口的(MHEG应用程序文件)变为刚好存在于服务网关之下的app0/startup(启动)文件。

基本上讲，应用程序目录(app0，app1，…，appN)存在于服务域(服务网关)之下，而称为startup的应用程序文件以及构成应用程序的每个场景的目录(scene0，scene1，…)存在于应用程序目录之下。此外，MPEG场景文件和构成场景的每个内容文件存在于场景目录之下。

由上面所述的karrusel发送的GUI数据即从图5中的DSM-CC编码器44输出的数据是以传输流的格式输出的。该传输流例如具有图10所示的结构。

图10A示出了传输流。该传输流是以MPEG系统定义的比特串，并且是通过如图中所示连接188字节固定长度的包(传输包)而形成的。

如图10B所示，每个传输包包括：一首标；一自适应字段，允许将附加信息包括在特定单独包中；和一有效负荷(数据区)，表示该包的内容(视频/音频数据，等)。

该首标实际上例如包括4字节。如图10C所示，同步字节当然安排在首标的头部。用作包的标识信息的PID(Packet_ID)，表示加扰的存在或不存在的加扰控制信息、以及表示随后的自适应字段和有效负荷的存在或不存在等的自适应字段控制信息都存储在同步字节之后的预定位置。

根据那些控制信息，在接收设备侧，以包单元为基础执行解扰，并且由解复用器分离并提取比如视频/音频/数据等的必要的包。在这里还可以再现用作同步再现视频/音频数据的基准的时间信息。

从上面的描述中可以理解，多个频道的视频/音频数据包已被多路复用成一个传输流。然而，除此之外，还多路复用了用于选择称为PSI(ProgramSpecific Information，节目特定信息)的播送台的信号、限制性接收(按照个人合同情况确定允许或禁止接收收费频道的接收功能)所必需的信息(EMM/ECM)、以及用于实现诸如EPG的服务的SI(服务信息)等。

PSI包含如图11所示的四个表。每个表都是以称为部分(section)格式的相应于MPEG系统的格式发送的。

图11A示出了NIT(Network Information Table，网络信息表)和CAT(Conditional Access Table，条件性接入表)。

在所述NIT中，在所有的载波中都已多路复用相同的内容。在该NIT中描述了每个载波的发送标准(极化平面、载波频率、卷积率等)以及其中多路复用的频道的列表。作为NIT的PID，可设定为PID＝0x0010。

同样，在所述CAT中，也在所有的载波中已多路复用相同的内容。在该CAT中描述了包括诸如限制性接收的识别的个人信息以及合同信息等的EMM(权利管理消息)。作为PID，可表示为PID＝0x0001。

在图11B中，示出的PAT用作具有对每个载波特有的内容的信息。在该PAT中描述了载波中的频道信息和说明每个频道的内容的PMT的PID。作为PID，可表示为PID＝0x0000。

作为载波中每个频道的信息，提供了图11C所示的一个PMT表(ProgramMap Table，节目映射表)。

在PMT中，已多路复用了每个频道的内容。例如，如在图11中所示的，由PAT指定构成每个频道的分量(视频/音频等)以及PMT的PID，其中已描述了解扰所必需的ECM(Encryption Control Message，加密控制消息)包的PID。

1-5.IRD

随后将参照图12描述为接收设施3提供的IRD 12的构成示例。

在该图示出的IRD 12中，由抛物面天线11的LNB 15转换为预定频率的接收信号输入到输入端T1并提供给调谐器/前端单元51。

在调谐器/前端单元51中，根据从CPU(中央处理单元)80提供并且其中已设置了发送标准的设置信号，接收由该设置信号确定的载波(接收频率)，并且例如使其经过维特比(Viterbi)解码处理、纠错处理等，从而获得传输流。

由调谐器/前端单元51获得的传输流提供给解扰器52。在调谐器/前端单元51中，从传输流中获得PSI的包，更新其播放台选择信息，获得该传输流中每个频道的分量PID并将其例如发送给CPU 80。在CPU 80中，获得的PID用于接收信号处理。

在解扰器52中，通过CPU 80接收存储在IC卡中的解扰密钥数据，并且由CPU 80设置PID。解扰处理是根据解扰密钥数据来执行的，并且将所述PID和所得数据发送给传输单元53。

传输单元53包含解复用器70和例如由DRAM等构成的队列(queue)71。队列71的形成使得相应于模块单元的多个存储器区域排列成各列。例如，在本实施例中，提供了32列的存储器区域。也就是说，多至32个模块的信息可同时存储。

作为解复用器70的示意性操作，按照由CPU 80的DeMUX(解复用器)驱动器82设置的筛选(filter)条件，从解扰器52所提供的传输流中分离出必需的传输包。必要时，将队列71用作工作区域，并且获得已在图7E到7H中示出的格式的数据，并将其提供给每个必需的功能电路部分。

由解复用器70分离的MPEG视频数据输入到MPEG2视频解码器55，并且MPEG音频数据输入给MPEG音频解码器54。由解复用器70分离的MPEG视频/音频数据的每个包以称为PES(Packetized Elementary Stream，打包的基本流)的格式输入到每个解码器。

由解复用器70将传输流中的MHEG内容的数据写入队列71中的相应存储器区域，同时将所述数据以传输包单元为基础从传输流中分离并提取出来，以使其以模块单元为基础收集而形成。收集到模块单元的MHEG内容的数据在CPU 80的控制下通过总线写入并保持在DSM-CC缓冲器91中。

至于传输流中的4倍速ATRAC数据(压缩音频数据)，同样，由解复用器70以传输包单元为基础分离并提取必要数据，并将其输出到IEEE 1394接口60。在通过IEEE 1394接口60发送数据的情况下，除了发送音频数据外，还发送视频数据、各种命令信号等。

在已输入了按作为PES格式的MPEG视频数据的MPEG2视频解码器55中，按照MPEG2格式执行解码处理，同时将存储器55A用作工作区域。解码的视频数据提供给显示处理电路58。

从MPEG2视频解码器55输入的视频数据和将在下文中解释的从主存储器90的MHEG缓冲器92中获得的用于数据业务等的GUI画面的视频数据，输入到显示处理单元58。显示处理单元58对如上所述输入的视频数据执行所需的信号处理，由预定电视系统将其转换为模拟音频信号，并将其输出到模拟视频输出端T2。

这样，通过连接模拟视频输出端T2和监视设备14的视频输入端，例如，可执行如前面提到的图4中的显示。

输入了PES格式的MPEG音频数据的MPEG音频解码器54按照MPEG音频格式执行解码处理，同时将存储器54A用作工作区域。解码的音频数据提供给D/A转换器56和光学/数字输出接口(I/F)59。

D/A转换器56将输入的音频数据转换为模拟音频信号，并将其输出到开关电路57。开关电路57切换信号路径，以便将该模拟音频信号输出到模拟音频输出端T3或者T4。

假定提供的模拟音频输出端T3连接到监视设备14的模拟音频输入端。提供的模拟音频输出端T4用于以模拟信号输出下载的音乐片段。

光学/数字输出接口59将输入的数字音频数据转换为光信号并将其输出。在这种情况下，光学/数字输出接口59例如符合IEC958。

当CPU 80执行各种控制处理时，将主存储器90用作工作区域。在该实施例中，在主存储器90中分配作为上述DSM-CC缓冲器91和MHEG缓冲器92的区域。

按照MHEG系统的脚本说明书，在MHEG缓冲器92中提供了产生图像数据(例如，GUI画面的图像数据)的工作区域。在该工作区域中形成的图像数据通过总线提供给显示处理单元58。

CPU 80执行IRD 12中的总体控制。这种控制也包括对在解复用器70中的数据分离和提取进行的控制。

此外还通过对获得的MHEG内容的数据执行解码处理来按照所述脚本说明内容执行构成GUI画面(场景)的处理。

因此，作为本实施例的CPU 80，例如，除提供了执行主控制处理的控制处理单元81之外，至少还提供了DeMUX驱动器82、DSM-CC解码器块83和MHEG解码器块84。在本实施例中，至少所述DSM-CC解码器块83和MHEG解码器块84是由软件组成的。

DeMUX驱动器82根据输入的传输流的PID设置解复用器70中的筛选条件

DSM-CC解码器块83具有用作DSM管理器的功能。存储在DSM-CC缓冲器91中的模块单元的数据重构成MHEG内容的数据。按照来自MHEG解码器块84的访问信号来执行关于所需的DSM-CC解码的处理等。

MHEG解码器块84访问由DSM-CC解码器块83获得的MHEG内容的数据，即由DSM-CC缓冲器91获得的MHEG内容的数据，并执行解码处理，以输出场景。也就是说，通过实现由MHEG内容的脚本文件规定的对象之间的关系来形成场景。在这种情况下，当形成作为一个场景的GUI画面时，使用MHEG缓冲器92，并按照脚本文件的内容形成GUI画面的图像数据。

将U-U API(DSM-CC U-U API(Application Portability Interface，应用程序可移植接口))用作DSM-CC解码器块83和MHEG解码器块84之间的接口。

该U-U API是例如在客户机(MHEG解码器块84)侧访问DSM管理器对象(实现DSM的功能的服务器对象：DSM-CC解码器块83)时使用的接口，并且是能使包括在karrusel中的其属性比如为服务网关、目录、文件、流、流事件等的对象可以象文件系统那样以结构方式访问的API。

通过经API访问包括在karrusel中的对象，使用该karrusel的程序(客户机)可通过使用总线名称访问到对象，而不涉及到karrusel接收操作。

由于该U-U API是一组规定的接口，它们的使用与较低层的数据传送系统无关，因此该U-U API具有这样的优点：能使使用该API的程序可用在提供U-UAPI的任何数据传送系统中。

下面将描述提取目标对象的操作例子，该目标对象是通过CPU 80的控制从传输流中形成一个场景所必需的。

在DSM-CC中，IOR(Interoperable Object Reference，可互操作的对象基准)用于表示传输流中对象的位置。标签(association_tag)信息用于识别包括对象的模块信息所具有的DII，该标签信息包括在IOR内，在该IOR内还包括用于查找对象的相应于karrusel的识别符、包括该对象的模块的识别符(在下文中将该识别符表示为module_id)、以及指定一个模块中的对象的识别符(在下文中将该识别符表示为object key)。

具有模块信息的DII包括：诸如关于一个或多个模块中的每一个模块的module_id、模块的大小和版本的信息；和用于识别各模块的标签(association_tag)信息。

当从传输流提取的IOR由CPU 80识别时，通过接收和分离对象而由IOR获得所示对象的处理例如如下面所示。

(Pr1)在CPU 80的DeMUX驱动器82中，通过搜索与来自karrusel中的PMT的ES循环的IOR的association_tag(关联标签)的值具有相同的值的的基本流(下文中缩写为ES)来获得PID。包括在ES中的DII具有该PID 。

(Pr2)PID和table_id_extension作为筛选条件设置到解复用器70中。因此，解复用器70分离出DII并将其输出到CPU 80。

(Pr3)在DII中，获得相应于包括在上面提到的IOR中的module_id的模块的association_tag。

(Pr4)从PMT的ES循环(karrusel)中搜索具有与association_tag的值相同的值的ES，从而获得PID。目标模块包括在具有此PID的ES中。

(Pr5)将PID和module_id设置为筛选(filter)条件，并且由解复用器70进行筛选。按照该筛选条件分离并提取出的传输包存储在队列71的所需存储器区域(列)中，以使目标模块可最终形成。

(Pr6)从该模块中提取相应于包括在上述IOR中的object_key的对象，并使其变为目标模块。从该模块提取的目标例如写入DSM-CC缓冲器91中的预定区域。

例如，通过重复上述操作，收集目标对象，并将它们存储到DSM-CC缓中器91中，来获得形成必要场景的MHEG内容。

在人-机接口61中，接收从遥控器64发送的命令信号，并将其发送给CPU 80。CPU 80执行所需的控制处理，以按照接收的命令信号获得设备的操作。

IC卡65插入到IC卡槽62中。由CPU 80将信息写入到插入的IC卡65中或者从插入的IC卡65中读出。

Modem(调制解调器)63通过电话线4连接到收费服务器5，对该modem 63进行控制，以便在CPU 80的控制下进行IRD 12和收费服务器5之间的通信。

下面将参照图4中描述的显示格式补充解释具有上述结构的IRD 12中的视频/音频素材的信号流。

在如图4A所示输出普通程序的情况下，从输入的传输流中分别提取必要节目的MPEG视频数据和MPEG音频数据，并使这些数据经过解码处理。所述MPEG视频数据和MPEG音频数据输出到模拟视频输出端T2和模拟音频输出端T3，从而在监视设备14中执行广播节目的图像显示和音频输出。

在如图4B所示输出GUI画面的情况下，由传输单元53从输入的传输流中分离并提取出对于GUI画面(场景)所必需的MHEG内容的数据，并将该数据存储在DSM-CC缓冲器91中。DSM-CC解码器块83和MHEG解码器块84使用此数据来行使上面提到的功能，以便由MHEG缓冲器92形成场景(GUI画面)的图像数据。该图像数据通过显示处理单元58提供给模拟视频输出端T2，从而在监视设备14上显示GUI画面。

当从图4B所示的GUI画面上的音乐片段的列表21B中选择了音乐片段，并且监视该音乐片段的音频数据时，由解复用器70取得该音乐片段的MPEG音频数据。该MPEG音频数据通过MPEG音频解码器54、D/A转换器56、开关电路57和模拟音频输出端T3转换为模拟音频信号，并将该音频信号输出到监视设备14。

当按下图4B中所示的GUI画面上的下载按钮28并且下载音频数据时，由解复用器70提取要下载的音乐片段的音频数据，并将该音频数据输出到模拟音频输出端T4、光学/数字输出接口59或者IEEE 1394接口60。

具体讲，当图2中所示的相应于IEEE 1394的MD记录器/播放器13A连接到IEEE 1394接口60时，在解复用器70中，下载音乐片段的4倍速ATRAC数据经IEEE 1394接口60被提取并记录到装入该MD记录器/播放器13A的盘中。在此情况下，例如，也是由解复用器70从传输流中提取出例如由JPEG系统压缩的唱片封面的静止图像数据以及诸如歌词和艺术家的概况等的文本数据，并经IEEE 1394接口60将这些数据传送到MD记录器/播放器13A。该MD记录器/播放器13A可将所述静止图像数据和文本数据记录到装入盘的预定区域。

下面将参照图13描述U-U API接口的一般例子。

下面将作为例子解释作为客户机的MHEG解码器块84再现流的情况。在该图中，在圈“○”中示出的数字表示MHEG解码器块84和DSM-CC解码器块83的处理过程。下面将按照该处理过程进行解释。

(处理过程1)客户机在所需定时处向服务器发送Event∷Subscribe(“streamon”)。

Event∷Subscribe(“stream on”)是向服务器预订(subscribe)一消息的接口，该消息是之后要接收一“stream on”事件。

(处理过程2)当接收到Event∷Subscribe(“stream on”)时，服务器返回相应于“stream on”事件的事件号码。在此情况下，Event#10设置并发送到客户机

(处理过程3)当获得事件号码时，客户机向服务器输出Event∷notify(事件∷通知)。

Event∷notify是这样的接口：如果在服务器侧产生某事件，则其通知由客户机侧向服务器侧请求。

(处理过程4)作为用于(处理过程3)的通知的响应处理，如果在如图15所示的某个定时处在接收数据中产生“stream on”事件，则服务器将Event#10作为为“stream on”事件设置的事件号码发送给客户机。

(处理过程5)客户机通过接收的Event#10来了解“stream on”事件的产生。在这种情况下，例如，执行用于流再现的MHEG解码处理。

2.karrusel切换时的处理过程

下面将描述在进行karrusel切换时的处理过程。当由对象karrusel系统接收到数字数据广播时，假定在广播期间切换karrusel的内容(广播内容)，则在切换时刻点使切换之前的karrusel的数据无效，并使系统进入能够访问新内容的karrusel的状态。作为用于形成karrusel的数据单元，例如，设置相应于图6中所示的一个事件的数据。

迄今为止，服务器侧(DSM-CC解码器块83)不具有这样的接口：该接口能够在切换karrusel的内容时的定时处，将切换消息通知到客户机侧(MHEG解码器块84)。也就是说，在IRD 12中，即使karrusel的内容在DSM-CC解码器块83侧的接收数据中进行切换，它也不能立即通知到MHEG解码器块84侧。在后面的描述中，将MHEG解码器块84称为客户机，而将DSM-CC解码器块83称为服务器。

不管当前用于场景显示的karrusel内容的切换没有被通知的状况，在客户机随后从服务器中读出此karrusel的情况下，由该karrusel读出并显示与前面的karrusel不同的数据。例如，当客户机想不顾karrusel内容的切换而保持前面的显示状态时，则客户机侧的这种操作会造成不方便。作为这种状态，例如，可以提到的一种情况是这样一种状态：用户监视能使该用户购买音乐片段等的广播，在该用户执行关于该购买的输入操作等的同时，karrusel的内容被切换。在这种情况下，在切换karrusel的内容的时间点，到此为止一直进行着的购买操作变为无效并且购买失败。

相反，在必须按照karrusel的内容切换改变当前场景显示的一部分内容的情况下，直到有机会从服务器中读出切换的karrusel才会改变场景的显示。也就是说，切换场景的显示内容的时刻比切换karrusel的内容的实际时刻延迟了

如上面所提到的，由于karrusel的内容切换没有通知给客户机的事实，会产生一些不方便。

2-1.第一个例子

因此，在本实施例中，如下文中将要解释的，能使客户机(MHEG解码器块84)侧知道karrusel的内容的切换，从而能够执行与其相应的MHEG解码处理。作为用于向客户机通知karrusel的内容被切换的事实的接口，可使用相应于U-U API的接口。

如上面所提到的，传统的DSM-CC解码器块83不具有用于在karrusel的内容被切换的时刻向客户机通知karrusel的内容被切换的事实的接口。表示karrusel的切换的标识信息不从广播电台发送。

然而，当切换karrusel的内容时，这些内容会反映到图8中描述的DSI的内容。也就是说，改变DSI中的karrusel内容的信息，并且将此应用在本实施例中。

作为本实施例的karrusel切换通知控制，在第一个例子中将“DSI_CHANGED”事件附加为U-U API的接口。该“DSI_CHANGED”事件表示在服务器侧接收到其内容被改变的新的DSI消息。按照如图14中的(处理过程1)到(处理过程4)的处理来执行karrusel切换通知控制。

(处理过程1)客户机向服务器发送Event∷Subscribe(“DSI_CHANGED”)。

(处理过程2)当接收到Event∷Subscribe(“DSI_CHANGED”)时，服务器向客户机返回为该“DSI_CHANGED”(DSI已改变)事件设置的事件号码。在此情况下，将Event#1设置给该“DSI_CHANGED”事件并返回。

(处理过程3)在获得事件号码之后，客户机向服务器发送Event∷notify，并且，如果产生了包括“DSI_CHANGED”的某个事件，则发出一请求以将其通知给服务器。

(处理过程4)允许服务器保持包括在接收的karrusel数据中的DSI。假定包括在接收的karrusel数据中的DSI在接收到Event∷notify之后的某个时刻改变。这就意味着切换了由DSI所表示的karrusel的内容。

如上面所提到的，当改变DSI时，即产生“DSI_CHANGED”事件时，服务器将为该“ DSI_CHANGED”事件设置的事件号码(Event#1)发送给客户机，作为对(处理过程3)的Event∷notify的响应。

因此，客户机至少可以以近乎实时的方式知道这样的事实：在当前正播出的数据业务中切换了karrusel。

响应于该通知，作为(处理过程5)，可以执行相应于karrusel的内容切换的一些适当的MHEG解码处理(场景的输出控制等)。在图14所示的例子中，客户机可以在改变DSI的时间点进行切换之后使用karrusel 2的数据开始处理

也就是说，在本发明中，客户机可以通过(处理过程4)检测karrusel的切换时刻。根据该定时，可以请求在DSM-CC缓冲器91中读出的切换之后karrusel 2的数据，并将该数据存储在MHEG缓冲器92中。因此，可以在几乎与karrusel的切换时刻同时的时刻由切换之后karrusel 2的数据构成并输出GUI画面。

尽管如上面所提到的，图14中作为(处理过程3)示出的Event∷notify是从客户机向服务器请求以通知产生了某事件的事实，实际上，如果由于产生某事件而在服务器侧执行响应于Event∷notify的通知，Event∷notify在此时刻无效

因此，在图14所示的实际处理中，在作为(处理过程1)首先发出了Event∷Subscriber(“DSI_CHANGED”)之后，如果通知响应于一次发出的Event∷notify的事件，以便向客户机通知在服务器侧产生了“DSI_CHANGED”事件，而不会将其丢失，则在此之后立即发出下一个Event∷notify。也就是说，在服务器侧，构造成尽可能使Event∷notify无效的时间段不发生。

利用这种方法，在数据业务广播期间，每次切换DSI，都可以以几乎实时的方式将“DSI_CHANGED”事件的产生通知给客户机，而不会将其丢失

考虑到用于使DSI的切换在数据业务广播期间被无丢失地连续通知的处理，刚好在启动MHEG解码器块84的程序(MHEG引擎)之后的时刻以及切换karrusel的数据内容的时刻，执行用于将(处理过程1)的Event∷Subscriber(“DSI_CHANGED”)从客户机通知给服务器的接口程序。

启动MHEG解码器块84的程序的情况相应于这样的时刻：例如，当频道从比如迄今为止一直接收不伴随业务数据广播的广播的状态切换时，或者节目从该状态改变时，从而可以新接收伴随着数据业务广播的节目等。

2-2.第二个例子

随后，将参照图15描述作为第二个例子的karrusel切换通知控制。在该第二个例子中，在将事件号码(Event#1)发送(处理过程4)给客户机之后(即，在切换karrusel之后)，客户机可以在切换之前一段预定时间内连续使用karrusel1。由于从(处理过程1)开始并到达(处理过程4)的处理步骤类似于上述第一个例子中的处理步骤，因而省略了对其的描述。

在本例中，当在客户机中发送了事件号码(Event#1)时(处理过程4)，由IRD 12接收切换之后的karrusel 2。然而，将切换之前karrusel 1的可处理数据1继续用于相应处理(处理过程6)。

在这种情况下，服务器不向客户机公开切换之后karrusel 2的数据，而公开作为可处理数据1在DSM-CC缓冲器91中取出的karrusel 1的数据(例如，阴影部分)以及设置(sets)，以使客户机可以访问到这些数据和设置。也就是说，执行用以在改变DSI的切换之后延迟读出karrusel 2的数据的控制。

之后，客户机在预定时刻(处理过程7)发送Session∷detach(会话脱开)。Session∷detach是用于让客户机请求释放相应于没有由服务器通过(处理过程6)公开的karrusel 2的可处理数据2的释放请求事件，并且该事件在预定时刻发送给服务器。

这样，服务器能使客户机访问相应于karrusel 2的可处理数据2。因此，在发送Session∷detach之后，客户机可根据由服务器新公开的karrusel 2的可处理数据2来执行所需处理。

作为发送Session∷detach的时刻，例如，可以预设从(处理过程6)开始起经过的一个时间，或者该时刻可以设置为确定当前正处理的数据即本例中的可处理数据1变为不必要的时刻。作为区别可处理数据1变为不必要的因素，例如，可以是由用户检测到所需操作的情况，等。

如上面所提到的，按照该第二个例子，即使在切换karrusel之后，也可以通过继续使用切换之前的数据来执行处理。因此，可以将系统构造成使得当前正执行的处理不会相关于karrusel的切换而中断。

3.对象更新时的处理过程

下面将描述更新对象时的处理。例如，当由对象karrusel系统接收到数字数据广播时，假定在广播期间更新了包括在该karrusel中的某个对象的版本，则在更新时刻使得更新之前的对象的数据无效，并且系统进入能够访问该新版本的对象的状态。

然而，传统的DSM-CC系统不具有这样的接口：该接口能够在更新karrusel中的对象版本的时刻将该更新事实通知到客户机侧。也就是说，在IRD 12的情况下，即使在DSM-CC解码器块83侧发生了接收数据中某个对象的版本更新(version-up)，该事实也不能立即通知到MHEG解码器块84侧。

不管当前用在场景显示中的对象的版本更新没有被通知的状况，在客户机随后从服务器中读出此对象的情况下，由该对象读出并显示与前面的对象不同的数据。例如，在客户机想不顾对象的版本更新而保持前面的显示状态的情况下，则客户机侧的这种操作会造成不方便。

相反，如果必须按照对象的版本更新改变当前场景显示的一部分内容，则直到有机会从服务器中读出更新的对象才会改变场景的显示。也就是说，更新场景的显示内容的时刻比对象的版本更新的实际时刻延迟了。

如上面所提到的，由于对象的版本更新没有通知给客户机，会产生一些不方便。

因此，在本实施例中，如下文中将要解释的，能使客户机(MHEG解码器块84)侧知道对象的版本更新，从而能够执行与其相应的MHEG解码处理。此外，通过使版本更新对象可以指定，该对象可被再一次从服务器侧有效读出。作为用于通知对象的版本更新的接口，可使用符合U-U API的接口。

3-1.第一个例子

如上面所提到的，DSM-CC不具有用于在karrusel中的对象被更新的时刻向客户机通知该更新事实的接口。表示对象的更新的标识信息不从广播电台发送。

然而，在DSM-CC中，当更新某对象(版本更新)时，响应于该更新而对包括此对象的模块执行版本更新。该模块的版本更新会反映到图8中描述的DII的内容。也就是说，改变DII中的模块的版本信息，并且将此应用在本实施例中。

作为本实施例的对象更新通知控制，在第一个例子中，将“DII_CHANGED”事件附加为U-U API的接口。该“DII_CHANGED”事件表示在服务器侧接收到其内容被更新的新的DII消息。按照如图16中的(处理过程1)到(处理过程4)的处理来执行对象更新通知控制。

(处理过程1)客户机向服务器发送Event∷Subscribe(“DII_CHANGED”)。

(处理过程2)当接收到Event∷Subscribe(“DII_CHANGED”)时，服务器向客户机返回为该“DII_CHANGED”事件设置的事件号码。在本例中，将Event#2设置给该“DII_CHANGED”事件并返回。

(处理过程3)在获得事件号码之后，客户机向服务器发送Event∷notify，并且，如果产生了包括“DII_CHANGED”的某个事件，则发出请求通知该事件。

(处理过程4)在服务器中，为包括在接收的karrusel的数据中的每个DII保持DII的版本值。假定包括在接收的karrusel的数据中的DII的版本值已在接收到Event∷notify之后的某个时刻改变，即DII的内容已被改变。这就意味着在由DII所表示的karrusel的模块中，某个对象的版本更新了，尽管该对象不能被指定。

如上面所提到的，当发生了DII的版本更新(内容的切换)时，即产生“DII_CHANGED”事件时，响应于(处理过程3)的Event∷notify，服务器将为该“DII_CHANGED”事件设置的事件号码(Event#2)发送给客户机。

因此，客户机可以以近乎实时的方式知道这样的事实：在当前正播出的数据业务中至少发生了对象改变。

按照该通知，可以执行相应于对象的版本更新的一些适当的MHEG解码处理(关于场景的输出控制，等)。

在U-U API的说明书中规定，当执行接口程序时，可以附加某些信息，并且可以传送所得数据。

因此，当通过(处理过程4)将事件号码(Event#2)发送给客户机时，如图中所示，如果相应于DII的更新的版本更新模块的标识信息(模块Id)与事件号码一起附加，则客户机侧可以指定其中对象内容被改变的模块。

在此情况下，由于在客户机侧没有指定更新的对象，不可能区别当前感兴趣的对象(例如，当前用于在客户机侧显示GUI画面等的对象，等)是否属于版本更新模块。因此，例如，在客户机侧，再一次从DSM-CC缓冲器91中装入对于当前正输出的场景(GUI画面，等)所必须的所有对象。通过使用该方法，尽管实际更新的对象有可能与当前正输出的场景的内容的改变无关，但只要更新的对象涉及当前正输出的场景的内容的改变，该场景的内容就必然会改变。

尽管如上面所提到的，作为(处理过程3)示出的Event∷notify是从客户机向服务器请求以通知该客户机产生了某事件的事实，实际上，如果由于产生某事件而使服务器侧发送响应于Event∷notify的通知，则Event∷notify在此时刻无效。

因此，在图16所示的实际处理中，作为(处理过程1)首先发出Event∷Subscribe(“DII_CHANGED”)。之后，为了向客户机通知在服务器侧产生了“DII_CHANGED”事件，而不会将其丢失，则在执行响应于一次发出的Event∷notify的事件通知之后，会立即发出下一个Event∷notify。也就是说，在服务器侧，尽可能使Event∷notify无效的时间段不发生。

利用这种方法，在数据业务广播期间，每次切换DII，都可以以几乎实时的方式将“DII_CHANGED”事件的产生通知给客户机，而不会将其丢失

考虑到能使在数据业务广播期间的DII的切换被无丢失地连续通知，刚好在启动MHEG解码器块84的程序(MHEG引擎)之后的时刻以及改变karrusel的数据内容(广播内容)本身的时刻，执行作为(处理过程1)将Event∷Subscribe(“DII_CHANGED”)从客户机传送给服务器的接口程序。

启动MHEG解码器块84的程序的情况设定于这样的时刻：例如，当频道从比如迄今为止一直接收不伴随业务数据广播的广播的状态切换时，或者节目从该状态改变时，从而可以新接收伴随着数据业务广播的节目等。

3-2.第二个例子

随后，将参照图17和18描述作为第二个例子的对象更新通知控制。在该第二个例子中，可在客户机侧指定改变的对象。

图17中示出的由(处理过程1)到(处理过程8)执行的该第二个例子的处理过程如下。

(处理过程1)即使在该第二个例子中，以类似于上述第一个例子情况的方式使用“DII_CHANGED”事件，并且客户机首先向服务器传送Event∷Subscribe(“DII_CHANGED”)。

(处理过程2)当接收到Event∷Subscribe(“DII_CHANGED”)时，服务器向客户机返回为该“DII_CHANGED”事件设置的事件号码。在本例中，作为相应于该“DII_CHANGED”事件的事件号码，设置并返回Event#2。

(处理过程3)在获得事件号码之后，客户机向服务器发送Version∷get(objectId)的接口程序。

Version∷get(objectId)是用于在客户机侧向服务器侧发送感兴趣的对象的接口。作为该接口程序的变元(objectId)，说明了关于所感兴趣的对象的对象标识(objectId)。在本说明书中，“感兴趣的对象”例如表示用在当前正由客户机(MHEG解码器块84)输出的场景(GUI画面等)中的对象等。

作为实际的Version∷get()，存在下列API。

interface Version {

void get(in ObjRef obj，out u_short moduleId)；

}；

(处理过程4)响应于Version∷get(objectId)的接收，从服务器返回moduleId，作为由objectId表示的对象所属的模块的标识信息。

响应于返回的moduleId，客户机侧发送相应于返回的moduleId的objectId并对其进行存储。

对于客户机中所有当前感兴趣的对象，都执行包含(处理过程3)→(处理过程4)的接口程序。现在，假定完成了例如相应于(处理过程3)→(处理过程4)的最后一个接口程序的(处理过程5)→(处理过程6)的接口程序，则在客户机侧获得如图18所示的表信息。也就是说，由于执行了[(处理过程3)→(处理过程4)]...[(处理过程5)→(处理过程6)]，对于客户机侧所有感兴趣的对象中的每一个对象，都获得其中使objectId和moduleId相互对应的一个表。之后的处理例程在(处理过程7)之前。

(处理过程7)客户机向服务器发送Event∷notify。当产生某事件时，客户机请求通知该事件。

(处理过程8)下面在服务器中，假定响应于Event∷notify而使DII的内容切换并且产生“DII_CHANGED”事件，则从服务器向客户机发送已为该“DII_CHANGED”事件设置的事件号码(Event#2)。然而，如上面所提到的，在U-U API中规定在发送某事件时可附加某些信息。在这种情况下，将DII的版本更新所对应的模块(即版本更新对象所属的模块)的moduleId附加到事件号码(Event#2)，并发送所得数据。设置如下的API。

    module DSM{

       interface Event{

         struct StreamEvent{

             u short eventId；∥用于DII CHANGED的id

             AppNPT rAppTime；∥不使用

             sequence＜u_short，65535＞moduleIdList；
    ∥(NEW)

      }

      }

      }

当如上所述在客户机侧获得了事件号码(Event#2)和moduleId时，客户机侧搜索图18所示的表，并搜索与通过(处理过程8)从所述表中发送的moduleId相符的moduleId。由于存在着由相应于搜索到的moduleId的objectId所表示的对象是更新对象的可能性，故客户机将该对象指定为更新对象。

在此情况下，例如，还存在这样的可能性：相应于与通过(处理过程8)发送的moduleId相符的moduleId的多个objectId存在于所述表中。在此情况下，尽管由所述多个objectId所表示的所有对象实际上不一定总是被更新，故将多个对象看做被更新。通过这种方法，实际被更新的对象当然包括在其中。

此外，在该第二个例子中，为在不丢失DII的切换的情况下能够将“DII_CHANGED”事件的事件号码+moduleId通知给客户机，以类似于第一个例子的情况的方式，需要刚好在启动MHEG解码器块84之后以及切换karrusel的时刻，执行作为(处理过程1)从客户机向服务器传送Event∷Subscribe(“DII_CHANGED”)的处理。

此外，在实际处理过程中作为(处理过程7)向服务器传送Event∷notify的过程中，当通知与其相应的某事件，并且获得了事件号码+moduleId的返回(处理过程8)时，立即传送下一个Event∷notify(#2)。

如上面所提到的，客户机可以通过了解更新的对象来执行相应于对象的版本更新的适当的MHEG解码处理，作为例子可以执行下面的处理。

如上面所提到的，MPEG解码器块84按照MHEG的描述内容，从DSM-CC缓冲器91中读出必要对象的数据，通过MHEG缓冲器92形成诸如GUI画面等的场景的数据，并将其输出到显示处理单元58。

现在，假定由图17中所示的过程来指定一个或多个特定对象的版本更新。还假定将这些对象用作形成当前GUI画面的对象，并且，如果这些对象的内容改变(版本更新)，则必须将该改变情况尽可能迅速地反映到GUI画面。

在这种情况下，MPEG解码器块84再一次只装入其版本更新被从存储在DSM-CC缓冲器91中的模块单元数据中指定的对象的数据。在MHEG缓冲器92中，通过只交换所述各对象中的内容并将其输出到显示处理单元58来形成新场景的数据。

例如，在不能指定更新对象的情况下，只通知相对于场景产生某些变化的可能性(例如，第一个例子)，即使在例如相应于一部分场景内容改变的情况下，也必须对于形成场景的所有对象都从DSM-CC缓冲器91中读出数据，并在MHEG缓冲器92中重构该场景。

另一方面，在如同在第二个例子中所示那样指定了更新对象的情况下，就象在前面的处理中所示的那样，MHEG解码器块84仅相对于一部分场景内容改变所必需的对象执行处理就足够了。换言之，当改变了一部分相同场景内容时，甚至还可以减小MHEG解码器块84的处理负担。

3-3.第三个例子

随后，将参照图19和20描述作为第三个例子的对象更新通知控制。

在该第三个例子中，也可以在客户机侧指定改变的对象。然而，在该第三个例子中，不使用用在上述第一和第二个例子中的“DII_CHANGED”事件

图19所示的第三个例子中的处理过程如下：

(处理过程1)相对于当前感兴趣的对象，客户机向服务器侧传送UpdateEvent∷subscribe(objectId)(更新事件∷预订(对象Id))。

UpdateEvent∷subscribe(objectId)是在执行了由变元表示的objectld所指示的对象所属于的模块的版本更新的情况下预订接收一事件(UpdateEvent)的事件。调用如下的API。

interface UpdateEvent{

void subscribe(in ObjRef obj，out u_short up eventId)；

void notify(in u_short up_eventId)；

}；

(处理过程2)当接收到UpdateEvent∷subscribe(objectId)时，服务器返回UpdateEventId(更新事件标识)，作为对接收的UpdateEvent∷subscribe(objectId)所特有的标识信息。该UpdateEventId是在服务器侧专门设置的标识(Id)。

客户机重复传送UpdateEvent∷subscribe(objectId)(处理过程1)，并且响应于此，对于所有当前感兴趣的对象重复接收UpdateEventId(处理过程2)。现在假定(处理过程3)→(处理过程4)的处理相应于涉及最后一个对象的(处理过程1)→(处理过程2)。

在按照所有感兴趣的对象完成了(处理过程1)→(处理过程2)...(处理过程3)→(处理过程4)时的阶段，客户机(MHEG解码器块84)可以获得图20A所示的表信息。该表信息说明了作为(处理过程1)(或(处理过程3))发送给服务器的objectId，即对于感兴趣的对象的objectId，和响应于此而从服务器得出的UpdateEventId之间的对应关系。

图20B示出的表信息是在服务器(DSM-CC解码器块83)侧获得的。该表信息说明了相应于由(处理过程1)(或(处理过程3))发送的objectId而设置的UpdateEventId、指定由上述objectId表示的对象所属于的模块的moduleId(模块标识)、以及该模块的version number(版本号码)(由DII表示)之间的对应关系。

(处理过程5)当如上所述地完成了(处理过程1)→(处理过程2)...(处理过程3)→(处理过程4)时，客户机向服务器发送UpdateEvent∷notify(更新事件∷通知)。如果产生了更新事件(模块的更新)，则客户机请求通知该事件。

(处理过程6)接收到UpdateEvent∷notify之后，服务器将由接收的DII表示的模块的版本值与图20B所示的表相对照。当相应于表中某个模块标识的版本号码与由DII表示的模块的版本值不同时，识别为存在该模块的版本更新。

当如上所述地相对于模块执行了版本更新时，即，当产生了UpdateEvent时，服务器参照所述表而附加相应于该版本更新模块的moduleId的UpdateEventId，调用下列API，并返回UpdateEventId。

    interface UpdateEvent{

      struct VersionUpEvent{

        u_short eventId；∥用于DII_CHANGED的id

        }

    }

当由(处理过程6)接收并获得了UpdateEventId时，客户机访问所述表(图20A)中与接收的UpdateEventId相符的UpdateEventId。通过查看与访问的UpdateEventId相应的objectId，来指定版本更新对象。

在该第三个例子中，由于如上所述地指定版本更新对象，也可以按照类似于前面第二个例子的方式更高效地执行MHEG解码器块84侧的处理。

在该第三个例子的情况下，还存在下面的优点。如图20A所示，在客户机(MHEG解码器块84)所具有的表中，能够使objectId对应于在服务器侧专门设定的UpdateEventId。因此，在客户机侧，可通过响应于Event∷notify取得UpdateEventId，来无条件地指定objectId。也就是说，在该第三个例子中，不需要为在客户机侧指定版本更新对象而搜索所述表，从而减小了客户机的处理负担。

在该第三个例子中，在作为(处理过程5)向服务器传送UpdateEvent∷notify的过程中，在获得响应于此UpdateEventId的应答(处理过程6)之后，也立即传送下一个UpdateEvent∷notify，从而能使版本更新模块无丢失地被通知。

在客户机侧对版本的更新不感兴趣的情况下(例如，当停止显示GUI画面时)，发出下列API。

interface UpdateEvent{

void unsubscribe(up_eventId)；

}；

于是，在服务器侧擦除用于通知UpdateEvent的管理信息。

4.模块到队列的分配

至于实现场景显示以及该场景显示上的音频输出等的对象，对于要在广播电台侧形成要播出的场景的数据执行正确的映射，并按照预定发送系统对于对象进行编码并发送。例如，如果对于一个确定的节目来说必须有多个场景，则正确映射并发送对所述多个场景所必需的对象的数据。

在接收设备侧，通过按照发送系统执行解码处理，例如，获得作为对场景所必需的每个对象组的数据，并将其作为一场景输出。

对于拥有接收设备的用户，从舒适的操作环境的角度来讲，最好，在选定某个频道之后直到首次显示场景之前所需的等待时间，或者当某个场景的显示切换到另一个场景的显示时所需的等待时间尽可能的短。

在将DSM-CC系统用作发送标准的数字卫星广播系统中，接收设备即IRD的类型可根据接收缓冲器的结构划分为两种。

一种是IRD具有与数据业务(GUI画面的显示输出)相对应的诸如快闪存储器、硬盘等的大容量接收缓冲器的结构。在这种结构中，播出的全部数据业务(MHEG内容)被汇总(in a lump)接收并保持在接收缓冲器中。因此，在一次接收并取出数据业务之后，由MHEG形成的任何场景(GUI画面平面)都可以只通过等待存储器存取的等待时间就立即显示并输出。也就是说，即使用户执行用于切换GUI画面(场景)等的操作，也可以几乎立即显示下一场景。

在这种情况下，由于切换解复用器的筛选条件而造成的轻微额外开销不会显著造成关于GUI画面的显示的问题。

另一种涉及由于要降低IRD的成本等原因而不具有如上所述的大容量接收缓冲器的结构，这种结构就相应于本实施例的IRD 12。在这种情况下，不能缓存全部数据广播业务的数据，相反，该IRD仅具有能够缓存作为接收单元接收数据广播的数据的数个模块的接收缓冲器。在图12所示的IRD 12中，该接收缓冲器相应于队列71，并且仅提供了能够如上所述地缓存各模块的存储器区域的32列。

相反，在这种IRD中，模块的大小不能超过接收器的缓冲存储器的大小。因此，全部数据业务都是由数个模块的组构成的，并且每次都执行仅接收对于显示等所必需的模块的过程。

上述的用于提取对象的过程(Pr1)到(Pr6)相应于诸如不具有大容量接收缓冲器的IRD的结构。

假定将图9的目录结构用作例如某个数据业务中的前提条件，首先在该数据业务中访问的应用程序是称为Gateway/app0/startup的文件，而第一个场景是由包括在scenedir0或者一文本文件中的静止图像构成的。

现在，假定由IRD相对于如上所述的数据业务启动接收，则执行下列过程。

(Pr11)参照PMT获得所需数据业务的PID，此筛选过程是由解复用器在将PID、table_id和table_id_extension用作筛选条件的同时执行的，并且获得DSI。服务网关对象的IOR已被写入DSI。

(Pr12)通过上述的对象提取过程(Pr1)和(Pr6)从IOR中获得服务网关对象

在服务网关对象和目录对象这两种BIOP消息中，刚好在目录之下的对象的名称和位置(IOR)信息和目录种类是作为称为“捆绑(binding)”的属性信息提供的。因此，当给出了对象的名称时，通过从服务网关开始并逐一向下追踪目录(如果存在相同名称的对象，必需较高总线名称，直到对象名称不同的位置)，可以到达该名称的对象。进一步还执行下列过程。

(Pr13)app0对象的IOR是从服务网关对象的捆绑信息中获得的，并且该app0对象是由所述对象提取过程(Pr1)和(Pr6)得出的。

(Pr14)startup对象的IOR是从app0对象的捆绑信息中获得的，并且该startup(启动)对象是由所述对象提取过程(Pr1)和(Pr6)得出的。以类似于上述的过程，获得作为第一场景的scenedir0等。

如上面所提到的，形成各模块的对象之间的关系在DSM-CC系统中没有特别限制而是任意设定的。因此，如图21所示，假定执行能使一个对象相应于一个模块的映射，并且从地面站1发送数据。在进行由DSM-CC编码器44形成模块的处理时，对MHEG内容的数据执行用于数据业务的目录结构的映射处理。

在此情况下，继续接收一新模块，以随后在IRD侧由(Pr11)到(Pr14)的过程获得对象。因此，必须执行这样一过程：每次获得对象都多次改变筛选条件并将其设置到解复用器70并且进行筛选(filtering)。由于这种筛选操作的接收造成了场景取出的延迟，从而造成了业务性能的恶化，由此也延迟了显示

考虑到用于karrusel的一次旋转的时间段到达从几秒到几十秒或更长范围内的一时间，尽管其依赖于数据业务的全部数据大小或者在广播时分配的频带。由于在最坏的情况下在一次筛选操作中会发生karrusel的一个旋转周期的等待时间(平均值为1/2旋转周期)，通过尽可能减少筛选次数，会直接有利于提高业务性能。

下面将考虑场景的切换。按照图21所示的映射，发生这样的情况：当从正显示的场景中调用下一个场景的文件时，该文件必须从较高目录中搜索。

例如，在图21所示的映射的情况下，当从app0/scenedir0转移到app0/scenedir1时，已经从app0对象的BIOP消息中获得scenedir1的捆绑信息。然而，当从app0/scenedir0转移到appN/scenedir0时，从存在于服务网关对象的BIOP消息中的appN对象的捆绑信息中搜索appN/scenedir0。也就是说，为改变场景，首先接收服务网关对象的模块，从BIOP消息中获得appN的捆绑信息，识别appN/scenedir0的目录，之后，必须接收appN/scenedir0的模块。(然而，上述的操作仅仅是在首次访问appN时执行的。在第二次及后续次的访问中，如果保持appN的捆绑信息，则没有必要执行上述过程。)

也就是说，甚至在这种情况下，由于模块的筛选而导致的场景切换等待时间变长。

因此，在本实施例中，使用下面的对象映射方法，从而甚至可由上面所述的(Pr1)到(Pr6)的对象提取过程来减小由于首次场景显示或者场景的切换而导致的等待时间。

图22示出了按照本实施例的用于数据业务的目录结构的映射的一个例子

在图22中，将构成一个场景的所有对象组合成一个模块(模块2，3，…，N)，并且包括服务网关的其它较高目录映射为一个模块(模块1)。然而，将首先访问的应用程序文件“Startup”映射到与第一场景相同的模块(模块2)。

通过执行如上所述的映射，如果首先接收服务网关的模块1，并且所有的子目录结构都存在于该相同模块中，则IRD 12侧可以通过接收该模块1来获得整个目录结构。

随后接收模块2，并且该模块2是通过映射首先出现的场景的文件而形成的。因此，在完成对该模块2的数据取出之后，获得输出该第一场景所必需的对象的所有信息。也就是说，当完成上面所述的(Pr5)的过程时，几乎在相同的时间内也完成了(Pr6)的过程。实际上，当在队列71中获得模块2时，模块2用作一个场景的数据并将其发送到DSM-CC缓冲器91中。这种过程类似地也对包括路由目录的模块1执行。

因此，在这种情况下，只要连续完成对诸如模块1和模块2的两次模块接收(捕获)，就可以原样开始第一场景的再现。当该场景进一步切换到另一个场景时，可参照首先取出的目录对象的捆绑信息直接接收所需场景目录的模块。

即使在这种情况下，尽管场景切换的额外开销肯定不大，也必须在出现数据业务的第一个场景之前两次接收模块。

按照图22所示的映射，尽管多个对象进入其中组合了较高目录的模块1，由于服务网关和目录的两种对象是通过组合诸如如上所述要捆绑到目录的对象的名称和IOR的较少数据量的信息而构成的，即使对象数目较大，整个数据容量也不会大。

图23示出了作为一个实施例的另一个映射例子。在本例中，对于组合的较高目录的组，要首先访问的应用程序文件(startup)和第一个场景的对象进一步映射到一个模块1。其它模块2，…，N是通过以与图22所示的模块3，…，N等类似的方式组合对于每个场景所必需的对象而形成的。

在执行映射并且发送所得数据的情况下，IRD侧仅接收模块1并将其从队列电路71发送到DSM-CC缓冲器91，以使第一个场景可以很快显示。由于在此阶段可参照目录对象的捆绑信息，因而能够按照后续场景的切换立即访问包含必要场景的对象的模块。

尽管在上述映射例子中形成一个场景的各对象必然存储在一个模块中，但在形成一个场景的所有对象的容量较大并且超过指定为一个模块的最大尺寸的情况下，例如，形成一个确定场景的各对象尽可能多地存储到第n个模块，并且第(n+1)个模块是由形成不能存储在第n个模块中的相同场景的对象形成的。使得所述第n和(n+1)个模块连续并通过karrusel系统来发送。通过使用这种方法，尽管必须两次接收所述第n和(n+1)个模块，场景可以相对迅速地再现。

在下面的描述中，通过如上所述地存储能够形成一个场景的所有对象而形成的模块也称为“场景模块”。

随后，将参照图24到28描述在IRD 12侧作为接收处理的对队列71的模块分配。在该实施例的IRD 12中，将能使广播侧(地面站侧)的数据映射被执行的条件用作先决条件，并且执行对下面将解释的队列71的模块分配，从而能进一步高效获得必要的场景。

在图24A中，概念性地示出了传输单元53中的解复用器70和队列70以及DSM-CC缓冲器91中的存储器区域的结构。

作为该图中示出的传输单元53，示出了解复用器70和形成队列71的存储器区域Mem-1，Mem-2，Mem-3，…，和Mem-32。每个存储器区域可存储模块单元的数据。

如上面所提到的，从传输流中分离并提取出适合于为解复用器70给出的筛选条件的数据(例如，部分单元)。分离并提取的部分存储在任意存储器区域Mem-1到Mem-32中。通过重复该操作，对某个存储器区域形成一模块，并将该模块存储在其中，该模块包含一组收集的部分，以适合于筛选条件。

例如，现在假定由解复用器70分离并提取由构成场景A的数据所形成的模块数据，并将其存储在存储器区域Mem-2中。在使用该场景A的模块以显示GUI画面的情况下，从存储器区域Mem-2中读出该场景A的模块数据并将其写入DSM-CC缓冲器中。

也就是说，作为接收的场景模块的通用发送格式，在该场景一次存储在队列的存储器区域中之后，该场景存储在DSM-CC缓冲器91中。MHEG解码器块84访问如上所述存储在DSM-CC缓冲器91的场景数据，并将其装入并存储在MHEG缓冲器中，以便能够输出GUI画面的场景等。

就象这里作为存储器区域Mem-1到Mem-32所表示的，本实施例中形成队列71的存储器区域也限于32列。只要实际进行了接收传输流的操作，这些存储器区域就处于它们中的多数被分离出的各种模块数据以及例如MPEG流数据等占用的状态，以便适合于各种不同的筛选条件。

这种条件意味着，例如，即使MHEG解码器块84设法取出需要访问到DSM-CC缓冲器91中的多个场景模块，由于临时保持场景模块的存储器区域数目有限，实际上很难比如将许多必需场景模块成块存储到队列中的多个存储器区域并将它们传送到DSM-CC缓冲器91。

在DSM-CC系统中，模块的接收顺序(取出顺序)没有特殊规定。也就是说，由传输单元53将各模块提取并存储在各存储器区域的顺序是任意设定的

因此，在本实施例中，在如上所述地假定存储器区域的数目有限的前提下，模块分配(接收顺序)是如下面所述以这种方式规定的：该方式使得需要存储在DSM-CC缓冲器91中的模块由传输单元53尽可能迅速地获得。

如上所述，例如在图22和23中示出了数据业务的目录结构和用于该目录结构的模块的映射。然而，例如，对于app0的目录，只要获得app0/startup和app0/scenedir0/scene0的对象，就可以获得形成应用程序app0的场景的优先级信息。相同的方案也可以类似地应用于其它应用程序app1到appN。

对于优先级来说，例如，在显示输出从某个场景的显示输出转移到其它场景的显示输出(该转移称为“转换”)的情况下，通常有多个作为其它场景的候选者。然而，在那些多个场景候选者中，例如，当必须通过用户的操作切换场景时，按照切换可能性的程度分配优先级。

在本实施例中，模块分配是根据场景的优先级信息规定的，下面将参照图24再次对其进行解释。

为方便解释，现在假定可将场景模块保持在传输单元53中的存储器区域仅仅为Mem-2，并且其它存储器区域被占用以存储其它类型的数据(例如，MPEG视频数据等)。下面将针对由应用程序app0输出场景的情况进行解释。

在传输单元53中，假定已接收到app0/startup和app0/scenedir0/scene0的对象所属于的各模块，并且例如在CPU 80的控制处理单元81中，已获得了应用程序app0中的场景优先级信息。

假定针对存在于app0的目录结构之下的多个场景，由优先级信息给出的优先级类似为场景A→场景B→场景C→场景D→…，并且必须将各场景尽可能多地存储到DSM-CC缓冲器91中。

在这种情况下，控制处理单元81首先执行一控制，以使具有最高优先级的场景A的模块存储在传输单元53的存储器区域Mem-2中。根据该控制，解复用器驱动器82将适合于场景A的模块的筛选条件设置给解复用器70。因此，如图24A所示，场景A的模块存储在存储器区域Mem-2中并传送到DSM-CC缓冲器91。

随后，作为用于捕获其优先级仅次于场景A的优先级的场景B的处理，控制处理单元81指示解复用器驱动器82将适合于场景B的模块的筛选条件设置到解复用器70中。因此，如图24B所示，在存储器区域Mem-2中获得场景B的模块并将其传送给DSM-CC缓冲器91。在图24A的各电路块中，仅提取存储器区域Mem-2和DSM-CC缓冲器91，并将它们示于图24B中。同样的方案也类似地应用于图24C。

此外，为获得其优先级次于场景B的优先级的场景C，将适合于场景C的模块的筛选条件设置给解复用器70。如图24C所示，获得场景C并将其传送给DSM-CC缓冲器91。

以类似于上述的方式，将相应于优先级的场景的筛选条件设置给解复用器70，并且在存储器区域Mem-2中获得各场景模块并将其传送给DSM-CC缓冲器91。

通过执行上述操作，将输出场景所必需的场景模块的数据，或者其中在场景切换时在下一个需要它的概率较高的场景模块的数据，按照优先级存储在DSM-CC缓冲器91中。

MHEG解码器块84访问通过DSM-CC缓冲器91获得的场景模块的数据，并输出如上所述的诸如GUI画面等的场景。然而，如果在数据广播期间通过用户的操作请求调用所需场景，则该调用请求的场景的数据已经保持在DSM-CC缓冲器91中的概率非常高。调用请求的场景数据几乎可被必然访问并迅速输出。

DSM-CC缓冲器91的容量很显然有限，并且实际上不可能分配大容量。因此，例如，存在这样的情况：不能存储其中假定由MHEG解码器块84使用的所有的场景模块。因此，例如假定发生了下面的不方便。

例如，如图25所示，假定在某个应用程序之下准备了5个场景A、B、C、D和E，并且各场景之间的转换格式(其转换规则描述在MHEG中)如图所示地设置。例如，在场景A的情况下，可执行到场景B、C或者E的转换。

假定DSM-CC缓冲器91的容量限定为最多可以存储4个场景模块的容量。在此条件下，如果MHEG解码器块84使用其中准备了如图25所示的5个场景模块即场景A到E，这5个模块即场景A到E中的一个不能存储在DSM-CC缓冲器91中。

在上述条件下，例如，假定在某个阶段显示并输出场景A，并且存储在DSM-CC缓冲器91中的场景模块为4个场景A、B、C和D。例如，如果在此状态下通过用户的操作请求调用场景E，则响应于此而执行从场景A到场景E的转换。

然而，由于在此情况下场景E不存在于DSM-CC缓冲器91中，为满足对场景E的调用请求，必须从karrusel中新取出场景E的模块。对于这个时间段，会给用户造成一个等待时间，直到从场景A的显示到场景E的显示的转换结束

因此，为尽可能解决这种不方便，在本实施例中进一步执行下面的模块分配。

在MHEG系统的实际数据业务中，存在的一种情况是，某个应用程序中多个场景之间的优先级随着当前显示并输出的场景进行改变。按照正输出的场景变化的优先级也可以根据上面提到的优先级信息来获得。

因此，在本实施例中，作为MHEG解码器块84的程序，启动下一个场景管理器，以便当某个场景当前正输出时，通过将正输出的场景用作激活的参考来管理其它场景的优先级。

作为所述下一个场景管理器的管理例子，假定在当前正输出如图25所示各场景之间的场景A的情况下，由下一个场景管理器管理的各优先级如图26所示。也就是说，假定各优先级是以(1)场景A→(2)场景C→(3)→场景E→(4)场景B→(5)场景D的顺序管理的。这种优先级实际上是由图中所示的优先级值确定的。优先级值越大，则优先级越高。用于场景A外的其它场景的优先级值的设定为：对场景C设定为“10”，对场景E设定为“9”，对场景B设定为“7”，并且对场景D设定为“1”。

在此情况下，存储在DSM-CC缓冲器91中的场景模块为如图28A所示的场景A、E、C和B。

当假定在此状态下发出一请求，以执行从场景A到场景C的转换时，例如，MHEG解码器块84在图28A所示的存储状态下执行用于从DSM-CC缓冲器91访问场景C的数据并将其输出的处理。

在MHEG解码器块84中，相应于到场景C的转换，由比如图27所示的下一个场景管理器更新并管理场景的优先级。

在图27中，假定将当前正输出的场景C设置到头部，则各优先级是以(1)场景C→(2)场景B→(3)→场景A→(4)场景D→(5)场景E的顺序管理的。在这种情况下，用于场景C外的其它场景的优先级值的设定为：对场景B设定为“7”，对场景A设定为“ 6”，对场景D设定为“4”，并且对场景E设定为“2”，并且上述优先级是按照这些优先级值来确定的。如上面所提到的，按照当前正输出的场景来改变各场景之间的优先级。

在本实施例中，根据如图27所示的更新的场景之间的优先级，来如下更新存储在DSM-CC缓冲器91中的场景模块的内容。

例如，CPU 80对当前由图27所示的下一个场景管理器管理的场景之间的优先级与在图28A中存储在DSM-CC缓冲器91中的场景模块进行比较。

因此，可以理解，按照如图27所示的优先级，第一优先级的场景C、第二优先级的场景B、第三优先级的场景A和第五优先级(最低优先级)的场景E存储在DSM-CC缓冲器91中，而第四优先级的场景D不存储。

因此，CPU 80执行一控制，其控制方式使得存储在DSM-CC缓冲器91中的场景模块变为当前管理的优先级之中的较高四个场景。也就是说，在此情况下，如图28B所示，场景D代替场景E存储在DSM-CC缓冲器91中，从而能使所述较高四个场景模块被最终存储。

为达到此目的，首先，CPU 80中的控制处理单元81发出指令，其指令方式使得例如用于获得场景D的模块的筛选条件从解复用器驱动器82输出到解复用器70。这样，场景D的模块存储在队列71中分配给该场景数据的各模块的存储器区域中。执行用于DSM-CC缓冲器91的写控制，其控制方式使得在队列71的存储器区域中获得的场景D的模块用场景E的模块来代替。例如，由控制处理单元80执行所述写控制就足够了。

如果作为在按照场景切换改变的场景优先级之间进行比较的结果必须交换两个或多个场景模块以及迄今为止存储在DSM-CC缓冲器91中的场景模块数据，则按照上述控制操作取出这些场景模块。

例如，当用户在输出某个场景的状态下执行场景的切换操作时，实际上，很有可能按照此时刻由下一个场景管理器管理的优先级选择要切换的场景

因此，如果规定传输单元53中的模块分配，以便优先将来自按照如上所述当前输出的场景而确定的各场景中更高优先级的场景的模块存储到DSM-CC缓冲器91，例如，可以尽可能避免这样一种情况发生的可能性：当请求场景转换时，该场景的模块不存储在如上所述的DSM-CC缓冲器91中。因此，在多数情况下，场景的切换按照场景切换操作立即进行。

实际上，需要略微较高的时间才能使DSM-CC缓冲器91的存储状态按照相应于例如图28A和28B所示的场景切换而改变的场景优先级而移位。然而，例如，在开始输出场景C之后通常需要存在一定时间段才能使第一场景切换操作被执行。也就是说，用户通常在开始输出场景C之后对场景C的图像观察一会儿。由于DSM-CC缓冲器91中的场景数据交换通常在这样一个时间段内几乎可以结束，因而在实际应用中不会发生问题。

下面将参照图29的流程图描述实现图26到28描述的模块分配的处理操作。该图中示出的各处理过程由CPU 80执行。也就是说，这些处理过程是由这样一种方法实现的：解复用器82、DSM-CC解码器83和MHEG解码器块84根据控制处理单元81的整体控制来适当执行所需的控制处理。

该图示出关于在下列情况下的场景模块分配的相应处理，所述情况例如为：因为执行了由用户请求场景切换的操作等，必须进行场景切换。

首先，在步骤S101，对于按照场景切换之前的下一个场景管理器的场景优先级列出的场景候选者和按照场景切换之后的下一个场景管理器的场景优先级列出的场景候选者进行比较，并且提取出这些场景候选者之中的不一致的(dissident)候选者。将这些场景候选者之中的相一致的场景登记到要由下一个场景管理器按照场景切换进行处理的“场景列表”中。

该处理过程例如是通过由MHEG解码器块84启动所述下一个场景管理器而实现的。

在随后的步骤S102中，执行这样的处理：该处理使得在步骤S101中提取的不同场景候选者中，删除场景切换之前的场景候选者，并将场景切换之后变为候选者的场景添加到列表中，该处理是由MHEG解码器块84执行的。

通过该处理，按照场景切换，将变为候选者的多个场景准备为场景列表

在步骤S103，对于登记为场景列表的各场景，按照场景优先级执行排序，该场景优先级是使用所述下一个场景管理器的功能而按照场景切换改变的

因此，管理状态从图26所示的下一个场景管理器的管理状态转移到图27所示的下一个场景管理器的管理状态。

在步骤S101到S103中示出的处理过程中，步骤S101和S102中的处理过程没有在上述关于图26和27的描述中特别提到。这是因为，在图26和27所示的情况中，场景候选者不会由于场景A到场景C的场景切换而交换。也就是说，当从图26到27进行场景切换时，在步骤S101不提取不同的场景，并且认为所有的场景都一致，以使它们登记在场景列表中。

在步骤S103之后，执行步骤S104的处理。在步骤S103所存储的场景列表中，开始对作为优先者的最高级别的场景进行处理。也就是说，该场景作为“当前场景”处理，并且执行后续处理。

作为步骤S104中的“作为优先者的最高级别的场景”，除了当前正输出的场景(图27的场景C)之外，还选择最高优先级的场景。即，在图27所示的情况下选择场景B。例如，当获得图27所示的优先级管理状态时，如果场景C不存储在DSM-CC缓冲器91中，则假定执行步骤S104中的处理，以便例外地将场景C作为当前场景处理。

在随后的步骤S105中，检验由步骤S104中选择的当前场景的数据形成的模块(场景模块)的数据大小。该数据大小例如可由下列方法来识别：从karrusel的数据中取出作为相应于当前场景模块的控制信息的DII(参照图8)，并且，例如，DSM-CC解码器块83查阅表示取出的DII中的模块数据大小的信息。这里所获得的当前场景模块的数据大小信息被暂时保持并用于步骤S107的辨别操作，对该操作将在下文中解释。

在步骤S106，辨别系统是否处于当前场景模块已被存储在DSM-CC缓冲器91中的状态中。如果是，则接着执行步骤S110，并执行这样一处理：对于迄今为止的当前场景，将分配了下一级优先级的场景选择为场景列表上的当前场景，并开始对这样的当前场景进行的处理。

另一方面，如果在步骤S106中的判断结果为否，则处理流程进到处理步骤S107。

在步骤S107，进行检验查看DSM-CC缓冲器91的当前剩余容量(数据取出可能容量)是否大于在步骤S105检验的当前场景模块的大小。如果检验结果为是，即，判断出存在能够取出和存储当前场景模块容量的剩余容量，作为DSM-CC缓冲器91的当前剩余容量，则接着执行步骤S111。执行这样一处理：将来自karrusel的当前场景模块数据累积到队列71中，并将其取出并存储到DSM-CC缓冲器91中。CPU 80实现此处理的控制操作以及与其相关的每个部分的信号处理操作例如在图28的描述中所述及。

在执行了步骤S111的处理之后，处理例程经过步骤S110的处理返回到步骤S105的处理。

如果在步骤S107的检验结果为否，并且当DSM-CC缓冲器91的当前剩余容量小于在步骤S105中检验的当前场景模块的大小时，处理流程进到步骤S108。

在步骤S108，将由所述下一个场景管理器管理的当前优先级管理与当前存储在DSM-CC缓冲器91中的场景模块进行比较，并且在当前存储在DSM-CC缓冲器91中的场景模块中，指定当前作为具有最低优先级的模块管理的场景模块。在下一步骤S109中，判断指定的场景模块的优先级是否低于当前模块的优先级。

在步骤S109中，如果在步骤S108中指定的场景模块的优先级低于当前场景的优先级，则接着执行步骤S112。从DSM-CC缓冲器中删除指定的场景模块，并且处理例程返回到步骤S107。通过该处理，从DSM-CC缓冲器91中删除最低优先级的场景模块(然而，仅将其优先级低于当前场景的优先级的场景模块才作为目标处理)，直到获得可以取出当前场景模块的DSM-CC缓冲器91的剩余容量。

如果在步骤S109的判断结果为否，即，当判断出在步骤S108中指定的场景模块的优先级高于当前场景的优先级时，在此阶段，存储在DSM-CC缓冲器91中的场景模块最终相应于由下一个场景管理器管理的当前场景的优先级。也就是说，按照上面的具体例子，获得与图27所示的下一个场景管理器的管理相对应的图28B所示的场景模块的存储状态。在此情况下，迄今为止完成了如图所示用于模块分配的处理。

在多路复用和广播音乐片段数据以便与TV广播节目并行进行下载的业务的情况下，存在这样一种情况：客户机想要使主频道的视频图像和音频数据的再现(例如，图4中的21A)与诸如静止图像等的附加数据的再现(例如，图4中的21D)同步。

例如，图像以下列方式显示。也就是说，如图30所示，在主节目的画面P1通过图30A所示的布置在时刻T0和时刻T2之间的时间段进行显示的同时，如图30B所示，在时刻T1除了显示主节目的画面P1之外，还显示附加数据的静止图像P2。静止图像P2连续显示，直到时刻T2。静止图像在时刻T2消失，如图30C所示。

在这种情况下，即使仅仅是与视频图像和音频数据的广播同时地发送附加数据，则在接收侧，视频图像和音频数据的再现也不能总是与附加数据的再现同步。

下面将描述这样一种方法：利用该方法，在脚本中描述事件的产生时间，并且当事件的产生时间到来时开始再现数据。通过如上所述详细描述事件产生时间，主视频图像和音频数据的再现可以与附加到其上的静止图像数据等的再现相同步。

在此情况下，如果对于要发送的时间信息要求秒级精度或更高精度，则对发送侧和接收侧造成的负担增加。经常还会有这样一种情况：由于体育节目、特殊新闻广播等改变节目的规定时间。在由脚本描述显示附加数据的时间信息并使系统可操作的情况下，如果如上所述存在节目的时间变化，则很难应付这种情况。

因此，在本实施例中，由时间信息构成事件通知，并且在时间信息部分定义和安排事件名称和表示该事件要立即产生的代码，并对其进行发送。通过使用此方法，在接收侧不需要管理时间，并且可以减小CPU的负荷。

下面将在下文中详细描述使主频道的视频图像和音频数据的再现与静止图像的附加数据的再现同步的方法。

作为包括在主服务网关中的对象，可以是上面所提到的目录、文件、流和流事件。然而，在这些对象之中，编辑是由GUI编辑系统42执行的，以便链接信息、事件名称和时间信息包括在流事件中。

图31示出了产生这样一个流事件的脚本(MHEG)的例子。如图31所示，当形成这种显示数据时的事件名称定义在该脚本之中，并且描述了根据该事件名称发生状态变化(显示数据的开/关(on/off))。

在DSM-CC编码器44中，读出要同步的视频素材的时间代码，将读出的时间代码用作时间信息，并且通过使该时间代码相应于事件名称来形成流事件包。从广播站与karrusel分开地重复发送该流事件包，如下文中将解释的。

图32示出这种流事件包的结构。如图32所示，在流事件包的头部提供表示流事件包的首标。在该首标之后描述了一对第一事件名称和时间信息。此外，在此之后描述了一对下一个事件名称和时间信息。可继续连接多对事件名称和时间信息。

作为事件的时间信息，存在这样一种情况：一种不可能的代码，例如其中所有比特都为1的全“1”安排在时间信息部分。在此情况下，定义其意味着“事件立即产生”。

尽管主节目的视频图像和音频数据和附加数据是从发送侧发送的，流事件包在从早于同步定时的预定处理时间的定时起的预定间隔内重复发送多次

在接收侧，当接收流事件包时，该事件在相应于包中的时间信息的时刻产生。如果时间信息部分指示全“1”，则事件在接收之后很快产生。因此，主节目的视频图像和音频数据的再现可以与附加数据的显示同步。

也就是说，如图33A所示，主节目的视频图像和音频数据的流连续发送。附加数据包是如图33C所示那样发送的，并且附加数据预先取到接收器中。在本例中，假定一个事件(Event 1)是在时间点T1产生的，而另一个事件(Event 2)是在时间点T2产生的。事件(Event 1)启动静止图像P2的显示。事件(Event 2)关闭静止图像P2的显示。

在此情况下，如图33B所示，在略微提前于产生事件(Event 1)的时刻点T1的时刻，发送其中事件名称为事件(Event 1)并且时间信息部分设置为全“1”的流事件包SE1-1。周期性地发送其中事件名称为事件(Event 1)并且时间信息部分设置为全“1”的流事件包SE1-2，SE1-3，…，直到开始下一个事件(Event2)的时刻之前的时刻。

在略微提前于产生事件(Event 2)的时刻点T2的时刻，发送其中事件名称为事件(Event 2)并且时间信息部分设置为全“1”的流事件包SE2-1。周期性地发送其中事件名称为事件(Event 2)并且时间信息部分设置为全“1”的流事件包SE2-2，SE2-3，…，直到开始下一个事件的时刻之前的时刻(或者直到节目结束)。

在接收侧，在略微提前于产生事件(Event 1)的时刻点T1的时刻，接收流事件包SE1-1。由于在事件包SE1-1中将时间信息部分设置为全“1”，在接收到事件包SE1-1的时间点立即产生事件(Event 1)。由于该事件(Event 1)打开了静止图像P2的显示，该事件在接收到流事件包SE1-1的时间点立即产生。静止图像P2的显示开启，如图33D所示。

流事件包SE1-1在略微提前于产生事件(Event 1)的时间点T1的时刻发送的原因是必须考虑处理时间。由于存在这种处理时间，通过在略微提前于产生事件(Event 1)的时间点T1的时刻发送流事件包SE1-1，静止图像刚好在时间点T1显示。由于图33D所示的显示数据已在产生事件之前取出，因而考虑到显示数据的处理时间仅仅基于图像显现所需的时间，并且可以认为其几乎为常数。

随后在略微提前于产生事件(Event 2)的时间点T2的一时刻接收流事件包SE2-1。由于流事件包SE2-1的时间信息部分设置为全“1”，事件(Event 2)在接收流事件包SE2-1的时间点立即产生。由于该事件(Event 2)关闭了静止图像P2的显示，该事件在接收到流事件包SE2-1的时间点立即产生，并且关闭静止图像P2的显示。由于存在显示时间的处理时间，数据的处理刚好在时间点T2完成。如图33D所示，擦除静止图像。

如上面所提到的，用于产生各事件的流事件包在早于产生每个事件的时间的时刻经过事件数据的处理时间发送。用于该事件的附加数据已被事先发送并取出到接收器。因此，每个事件可在规定时间产生。

重复发送流事件包，直到开始下一个事件的时间点，或者直到节目结束。相同的流事件包重复发送的原因是，在接收器的电源在定义的每个事件的时间之后接通的情况下，或者在该状况从另一个频道改变到此频道的情况下，必须将显示数据移到正确的状态。

在上面的例子中，事件(Event 1)和事件(Event 2)都作为流事件包发送，其中时间信息部分设置为全“1”。然而，其中描述了事件名称和事件时间信息的流事件包和其中将事件名称和时间信息部分设置为全“1”的流事件包可被组合并发送。

图34示出了这样一个例子，在该例子中，其中描述了事件名称和事件时间信息的流事件包和其中将事件名称和时间信息部分设置为全“1”的流事件包可被组合并发送。

也就是说，在图34中，事件(Event 11)的流事件包SE11-1，SE11-2，SE11-3，...在时间点T11开启静止图像P2的显示。“时间T1”描述在流事件包SE11-1，SE11-2，SE11-3，...的时间信息中。另一方面，事件(Event 12)的流事件包SE12-1，SE12-2，SE12-3，...在时间点T12关闭静止图像P2的显示。在流事件包SE12-1，SE12-2，SE12-3，...中，时间信息部分设置为全“1”。

在此情况下，如图34B所示，从产生事件(Event 11)的时间点T11之前的一时刻起，周期性重复发送流事件包SE11-1，SE11-2，SE11-3，...。在略微提前于开始下一个事件(Event 12)的时间点T12的一时刻，发送事件(Event 12)的流事件包SE12-1。随后，周期性重复发送类似的流事件包SE12-2，SE12-3，...。

在接收侧，在产生事件的时间点T11之前的一时刻接收流事件包SE11-1，SE11-2，SE11-3，...。所有的流事件包SE11-1，SE11-2，SE11-3，...都是类似的包。流事件包SE11-1，SE11-2，SE11-3，...的时间信息设置为“时间T11”。因此，接收器侧等待，直到时间点T11到来。

当时间点T11到来时，产生事件(Event 11)。由于该事件(Event 11)开启了静止图像P2的显示，静止图像P2的显示从时间点T11起开启，如图34D所示。

流事件包SE12-1在略微提前于产生事件(Event 12)的时间点T12的一时刻被接收。由于该流事件包SE12-1的时间信息设置为全“1”，该事件(Event12)在接收到流事件包SE12-1的时间点立即产生。由于该事件(Event 12)关闭了静止图像P2的显示，该事件(Event 12)在接收到流事件包SE12-1的时间点立即产生。关闭静止图像P2的显示。由于存在显示时间的处理时间，如图34D所示，静止图像P2的显示处理刚好在时间点T12完成，并且擦除该静止图像

在此情况下，也重复发送流事件包，直到开始下一个事件的时间点，或者直到节目结束。相同的流事件包如上所述地重复发送的原因是，以类似于上述的方式，在接收器的电源在定义的每个事件的时间之后接通的情况下，或者在该状况从另一个频道改变到此频道的情况下，必须将显示数据移到正确的状态。

在在流事件包的时间信息中描述时间并且发送该流事件包的情况下，描述MHEG脚本，比如为“如果描述的时间信息指示当前时间通过，则事件立即产生”。通过使用此方法，描述了流事件包的时间信息，并且，甚至在当前时间已通过了由该时间信息所示的时间的情况下，事件也会立即产生。

尽管上述的例子涉及简单的事件处理，比如为开启/关闭一个附加数据，但也可以处理多个附加数据。在此情况下，通过将关于相同附加数据的各事件处理为一组，可以类似于简单序列情况下的方式执行处理。

例如，如图35所示，假定以下列方式执行显示处理：在时间T20和时间T24之间的时间段内通过如图35A所示的布置显示主节目的图像P21，在时间点T21如图35B那样显示静止图像P22，进一步在时间点T22如图35C那样显示静止图像P23，在时间点T23如图35D那样只擦除静止图像P22，在时间点T24如图35E那样擦除静止图像P23，并且，仅有主运动图像P21连续显示。

如上面所提到的，当存在两个事件，即关于静止图像P22的事件和关于静止图像P23的事件时，将关于每个附加数据的各事件考虑为一个组。

首先，作为关于静止图像P22的组的事件，存在这样一个事件：该事件在时间点T21开启静止图像P22的显示，并在时间点T23关闭静止图像P22的显示。作为关于静止图像P23的组的事件，存在这样一个事件：该事件在时间点T22开启静止图像P23的显示，并在时间点T24关闭静止图像P23的显示。

为实现关于第一组的静止图像P22的事件，在略微提前于时间点T21的一时刻，发送其中将时间信息部分设置为全“1”的用于开启静止图像P22的显示的事件名称的流事件包。之后，周期性地重复发送该流事件包。在略微提前于时间点T23的一时刻，发送其中将时间信息部分设置为全“1”的用于关闭静止图像P22的显示的事件名称的流事件包。之后，周期性地重复发送该流事件包。

为实现关于下一组的静止图像P23的事件，在略微提前于时间点T22的一时刻，发送其中将时间信息部分设置为全“1”的用于接通静止图像P23的显示的事件名称的流事件包。之后，周期性地重复发送该流事件包。在略微提前于时间点T24的一时刻，发送其中将时间信息部分设置为全“1”的用于关闭静止图像P23的显示的事件名称的流事件包。之后，周期性地重复发送该流事件包。

如上面所提到的，当存在关于多个附加数据的事件时，通过对每个数据执行组合(grouping)，可以对这些数据以类似于一个数据的情况下的方式来考虑。在同时产生多个事件的情况下，不需要通过另一个包来发送这些事件，并且多个流事件信息可由一个流事件包发送。

图36示出了实现相应于图35所示事件的流的流事件序列。如图36A所示，主节目的视频图像和音频数据流连续发送。附加数据的包如图36C所示那样发送，并且此附加数据包已被事先取出。

事件(Event G1-1)是用于开启静止图像P22的显示的事件。事件(Event G1-2)是用于关闭静止图像P22的显示的事件。事件(Event G2-1)是用于开启静止图像P23的显示的事件。事件(Event G2-2)是用于关闭静止图像P23的显示的事件。

在此情况下，如图36B所示，在略微提前于产生事件(Event G1-1)的时间点T21的一时刻，发送其中事件名称为事件(Event G1-1)并且时间信息部分设置为全“1”的流事件包SE21-1。之后，周期性地重复发送相同的流事件包SE21-2，SE21-3，…。

在略微提前于产生事件(Event G2-1)的时间点T22的一时刻，发送其中事件名称为事件(Event G2-1)并且时间信息部分设置为全“1”的流事件包。在此情况下，也必须连续发送其中事件名称为事件(Event G1-1)并且时间信息部分设置为全“1”的流事件包。因此，周期性地连续发送其中这些事件已被合并的流事件包SE22-1，SE22-2，SE22-3，…。

在略微提前于产生事件(Event G1-2)的时间点T23的一时刻，发送其中事件名称为事件(Event G1-2)并且时间信息部分设置为全“1”的流事件包。在此情况下，也必须连续发送其中事件名称为事件(Event G2-1)并且时间信息部分设置为全“1”的流事件包。因此，周期性地连续发送其中这些事件已被合并的流事件包SE23-1，SE23-2，SE23-3，…。

在略微提前于产生事件(Event G2-2)的时间点T24的一时刻，发送其中事件名称为事件(Event G2-2)并且时间信息部分设置为全“1”的流事件包。在此情况下，也必须连续发送其中事件名称为事件(Event G1-2)并且时间信息部分设置为全“1”的流事件包。因此，周期性地连续发送其中这些事件已被合并的流事件包SE24-1，SE24-2，SE24-3，…。

通过如上所述地对每个目标组合流事件，例如，即使此频道在时间T22和时间T23之间的时间段内被选择，作为产生两个事件即事件(Event G1-1)和事件(Event G2-1)的结果，静止图像P22的显示和静止图像P23的显示都可以开启。当在时间T23和时间T24之间的时间段内选择了此频道时，事件(EventG2-1)和事件(EventG1-2)都产生，从而可最终显示静止图像P23。

尽管对本发明已对于将DSM-CC系统用作数据发送系统并将U-U API用作MHEG客户机服务器之间的接口的情况作了描述，但本发明不限于此。本发明可应用于任何符合上面实施例中描述的发送格式的发送系统和接口。本发明所应用的系统不限于数字卫星广播系统，而是还可应用于例如电缆电视等的广播、因特网等等。

如上所述，按照本发明，例如，作为用于通过DSM-CC系统中的对象karrusel发送数据的系统的接收侧的数据发送控制方法，可从自karrusel接收并保持数据的服务器侧向客户机通知这样的事实：karrusel的内容已被改变，以便通过使用karrusel的数据实现所需功能。因此，客户机侧能够响应于karrusl的内容切换而迅速或高效地按照此通知执行操作。

按照本发明，作为用于如上所述将karrusel的内容已被改变事实通知给客户机的karrusel内容切换通知处理，例如，在现有的比如U-U API等的接口下，可设置表示关于karrusel的内容切换的控制信息(DSI)的变化的控制信息变化事件(DSI_CHANGED)，并且，通过使用该控制信息变化事件，该控制信息已被改变的事实从客户机侧通知到服务器侧。也就是说，可按照现有的接口实现karrusel的内容切换的通知，而不用使用专门接口标准，从而赋予了普遍性。

预订事件(Event∷subscribe)的传送是在激活客户机的程序或者切换karrusel本身时执行的。通过允许事件通知请求(Event∷notify)在获得来自服务器的事件通知请求的响应消息之后立即执行，可在激活客户机的程序之后获得karrusel的内容切换通知，而且几乎不会将其丢失。例如，GUI画面的内容可以几乎快速响应于广播侧等的karrusel的内容切换而变化。故提高了可靠性

此外，在产生控制信息改变事件之前karrusel的内容连续用于预定时间段，直到在服务器向客户机通知产生了控制信息变化事件之后客户机向服务器传送会话脱开(Session∷detach…release request(会话∷脱开…释放请求))。因此，能够以下列方式构建系统：即使切换了karrusel的内容，也不中断之前刚好基于该karrusel的内容执行的处理。

作为在用于通过例如DSM-CC系统下的对象karrusel执行数据传送的系统接收侧的数据传送控制方法，可从接收并保持来自karrusel的数据的服务器侧向客户机通知一事实：karrusel(循环数据单元)中的对象已被更新，以便通过使用此karrusel的数据实现所需功能。因此，客户机侧能够按照此通知，迅速或高效地执行要响应于该对象更新而执行的处理。

在本发明中，作为用于如上所述将对象更新通知给客户机的对象更新通知处理，例如，在现有的比如U-U API等接口下设置控制信息改变事件(DII_CHANGED)，该控制信息改变事件意味着改变关于其内容按照对象的更新而更新的模块的控制信息(DII)。通过使用该控制信息改变事件，控制信息改变的存在从客户机侧通知给服务器侧。也就是说，可按照现有的接口实现对象的更新通知，而不用使用专门接口标准，因而赋予了普遍性。

当根据所述控制信息改变事件从服务器侧通知了控制信息改变事件的产生时，如果添加了控制信息所对应的模块，则客户机侧不仅可以知道对象只不过在karrusel中更新，而且还可以指定更新对象所属于的模块。因此，当执行用于将数据等再次装入的处理时可以高效地执行处理。

作为本发明的另一个对象更新通知处理，意味着DII的改变的控制信息改变事件(DII_CHANGED)在现有的比如U-U API等的接口之下进行设置，并且客户机侧以类似于上面提到的方式预订接收所述控制信息改变事件(Event∷subscribe)。之后，所感兴趣对象的ID发送到服务器，并且该对象所属于的模块从服务器发送到客户机。响应于客户机的接收该控制信息改变事件的后续请求，服务器侧添加更新的控制信息的模块的ID，并通知客户机该控制信息改变事件的存在。

因此，在接收器侧，通过搜索其中使得对象ID和模块ID相对应的表，也可以指定几乎更新的对象。在此情况下，客户机侧例如在对象单元基础上再次装入数据就足够了。进一步减小了处理负担。

作为再一个对象更新通知处理，客户机侧添加所感兴趣对象的ID并向服务器预订接收模块的更新事件，并且，服务器响应于此(预订)而执行接口程序，以使特殊模块更新事件被设置并返回给客户机。

响应于客户机的接收模块更新事件的后续请求，服务器侧添加更新控制信息的模块更新事件ID，并且发送模块更新事件。

甚至通过使用此结构，在客户机侧，通过搜索其中使得对象ID和模块更新事件ID相对应的表，也可以指定几乎更新的对象。在此结构中，由于获得的模块更新事件ID和相应的对象ID是无条件地获得的，不需要为了指定更新对象而搜索该表。因而进一步减小了处理负担。

预订事件(Event∷subscribe)的传送是在激活客户机的程序或者切换karrusel本身时执行的。通过以下列方式进行构建：使得事件通知请求(Event∷notify)在获得来自服务器的事件通知请求的响应消息之后立即执行，可在激活客户机的程序之后获得对象更新的通知，而且几乎不会将其丢失。例如，GUI画面的内容可以几乎快速响应于广播侧等的对象更新而变化。故提高了可靠性。

按照本发明，对于包含事件名称和时间信息的流事件的时间信息，不能作为时间信息出现的一个代码(例如，全“1”)定义为意味着“事件立即产生”。因此，当通过将时间信息部分设置为例如全“1”而发送流事件时，该事件在接收侧立即产生。因此，当客户机想要使显示数据与视频图像和音频数据同步时，通过在略微提前于产生事件的定时的一时刻发送其中将时间信息部分例如设置为全“1”的流事件，显示数据可以与视频图像和音频数据同步。因此，视频图像和音频数据与附加数据之间的同步可以轻易实现，并且能够容易地处理节目的改变。在接收侧不需要时间管理。

此外，本发明是以下列方式说明的：作为发送系统，一个场景的场景数据原则上形成一个模块，而作为相应于通过karrusel系统发送包含一个或多个模块的发送数据的情况的接收设备，按照各场景的优先级确定作为要从karrusel(发送信息)中提取并取出到队列(存储器装置)的场景数据的模块。

例如，在没有特别说明模块到队列的取出顺序的情况下，需要较长时间才能在场景数据存储装置(DSM-CC缓冲器)中获得并取出显示输出所必需的场景数据。为解决这个问题，必需多个队列才能使作为目标场景数据的模块通过场景数据存储装置被尽可能迅速地获得。

另一方面，按照本发明，由于作为场景数据的各模块是按照优先级通过上述结构取出的，即使在使用有限数目的队列装置的结构中，也能相对迅速地获得显示输出所必需的场景数据或者很有可能必需的场景数据。也就是说，按照本发明，即使队列电路较少，本发明也能迅速地处理场景输出和场景切换。相反，与不使用本发明而实现快速场景输出和场景切换的情况相比，可以减少队列数目，从而可以减小IRD(接收设备)的电路规模，并且可以实现低成本。

由于要从接收数据的karrusel中取出的作为场景数据的模块是按照要响应于当前输出的场景改变的优先级确定的，获得这样一种状态：场景数据已响应于场景显示的切换，按照从较高级场景数据起的优先级优先存储在场景数据存储装置中。

在此情况下，要由场景显示的切换操作来选择的场景的场景数据已存储在场景数据存储装置中的可能性非常高。因此，即使在例如，当执行了场景显示的切换操作时，在许多情况下，场景切换操作也能迅速执行。该结构尤其对于下列条件有效：场景数据存储装置(DSM-CC缓冲器)的容量有限，并且不能存储大量场景数据。

工业应用性

本发明可用于下列情况：发送与主TV节目广播相关的音乐数据，并且例如在数字卫星广播中传播音乐等。

Claims

1.一种数据发送控制方法，其特征在于，

所述方法相应于一数据传送系统，其中循环数据单元由要传送的所需数据形成，并且所述循环数据单元在所需时间段内周期性重复传送，和

执行一循环数据单元切换处理过程，用于使所述循环数据单元的内容被切换的事实从接收所述循环数据单元的服务器侧通知到使用所述循环数据单元的客户机。

2.如权利要求1所述的数据发送控制方法，其特征在于，

其内容按照所述循环数据单元的切换而切换的控制信息包括在所述循环数据单元中，

所述循环数据单元切换处理是由下列方式实现的：

设置表示所述控制信息已在预定接口标准下接收的控制信息改变事件，和

之后，至少执行：

第一处理过程，用于允许所述客户机向所述服务器发送一预订事件，以预订接收所述控制信息改变事件，

第二处理过程，用于允许所述客户机向所述服务器发送一事件通知请求，以请求产生事件的通知，和

第三处理过程，用于向所述客户机通知这样一事实：所述控制信息改变事件已在接收到改变的控制信息时产生，作为所述服务器对所述事件通知请求的响应。

3.如权利要求2所述的数据发送控制方法，其特征在于，作为所述第一处理过程的所述预订事件的发送是在所述循环数据单元的内容被切换时执行的。

4.如权利要求2所述的数据发送控制方法，其特征在于，作为所述第一处理过程的所述预订事件的发送是在激活所述客户机的程序时执行的。

5.如权利要求2所述的数据发送控制方法，其特征在于，

在所述服务器通过所述第三处理过程通知所述客户机产生了所述控制信息改变事件之后，

在所述第三处理过程中产生所述控制信息改变事件之前在预定时间段内所述客户机继续使用所述循环数据单元，直到相应于所述改变了的控制信息的循环数据单元的释放请求发送到所述服务器。

6.一种数据发送控制方法，其特征在于，所述方法是以下列方式构建的，该方式使得，

所述方法相应于一数据传送系统，其中形成一数据发送单元，以便包括按预定系统的方案说明书相关的对象，此外，形成一循环数据单元，以便包括要在某个预定时间段内发传送的一个或多个数据发送单元，并且，所述循环数据单元重复传送，和

执行一对象更新通知处理过程，用于使所述循环数据单元中包括的对象被更新的事实被从接收所述循环数据单元的服务器侧通知到使用所述循环数据单元的客户机。

7.如权利要求6所述的数据发送控制方法，其特征在于，

其内容按照所述对象的更新而更新并且与所述数据发送单元相关的控制信息被包括在所述循环数据单元中，和

所述对象更新通知处理过程由下列方式实现：

设置表示所述控制信息已在预定接口标准下接收的控制信息更新事件，和

之后，至少执行：

第一处理过程，用于允许所述客户机向所述服务器发送一预订事件，以预订接收所述控制信息更新事件，

第三处理过程，用于向所述客户机通知这样一事实：所述控制信息更新事件已在接收到更新的控制信息时产生，作为所述服务器对所述事件通知请求的响应。

8.如权利要求7所述的数据发送控制方法，其特征在于，所述第三处理过程添加由更新的控制信息所表示的数据发送单元的识别信息，并通知所述客户机已产生控制信息接收事件的事实。

9.如权利要求7所述的数据发送控制方法，其特征在于，所述方法是以下列方式构建的：该方式使得作为所述第一处理过程的所述预订事件的发送是在激活所述客户机的程序或者切换所述循环数据单元本身时执行的。

10.如权利要求7所述的数据发送控制方法，其特征在于，所述方法是以下列方式构建的：该方式使得，在从所述服务器获得用于所述事件通知请求的响应消息之后，作为所述第二处理过程的所述事件通知请求立即执行。

11.如权利要求6所述的数据发送控制方法，其特征在于，所述方法是以下列方式构建的：该方式使得，

关于所述数据发送单元的信息包括在所述循环数据单元中，所述数据发送单元的内容按照属于其的对象的更新而更新，和

所述对象更新通知处理过程至少执行：

第一处理过程，用于允许客户机向服务器发送一预订事件，以预订接收所述控制信息更新事件，

第二处理过程，用于允许客户机将所感兴趣对象的对象ID通知给服务器侧，并允许服务器侧向客户机返回所通知的对象所属的数据发送单元的数据发送单元ID，

第三处理过程，用于允许客户机形成表示由所述第二处理过程通知给服务器侧的对象ID和由所述第二处理过程从所述服务器侧获得的数据发送单元ID之间的对应关系的表信息，

第四处理过程，用于允许客户机向服务器发送一事件通知请求，以请求产生事件的通知，

第五处理过程，用于在由所述服务器作为对所述服务器中的事件通知请求的响应处理而接收到更新的控制信息时，添加由更新的控制信息表示的数据发送单元ID，并将控制信息更新事件的产生通知给客户机，和

第六处理过程，用于允许客户机搜索与由所述第五处理过程获得的数据发送单元ID相符的表信息的数据发送单元ID，并指明由相应于所述搜索到的数据发送单元ID的对象ID所表示的对象已被更新。

12.如权利要求11所述的数据发送控制方法，其特征在于，所述方法是以下列方式构建的：该方式使得，作为所述第一处理过程的所述预订事件的发送是在激活所述客户机的程序或者切换所述循环数据单元本身时执行的。

13.如权利要求11所述的数据发送控制方法，其特征在于，所述方法是以下列方式构建的：该方式使得，在从所述服务器获得对所述事件通知请求的响应消息之后，作为所述第四处理过程的所述事件通知请求立即执行。

14.如权利要求6所述的数据发送控制方法，其特征在于，所述方法是以下列方式构建的：该方式使得，

所述对象更新通知处理过程执行：

第一处理过程，用于允许客户机向服务器发送一预订事件，以预订接收一数据发送单元更新事件，并发送所感兴趣对象的对象ID，并且允许客户机响应于此而设置特殊的数据发送单元更新事件ID，并将所述数据发送单元更新事件ID发送到客户机，

第二处理过程，用于允许客户机形成表示由所述第一处理过程发送到服务器侧的对象ID和由所述第一处理过程从所述服务器侧获得的数据发送单元更新事件ID之间的对应关系的表信息，

第三处理过程，用于允许客户机向服务器发送一事件通知请求，以请求产生数据发送单元更新事件的通知，

第四处理过程，用于在作为对所述服务器中的事件通知请求的响应而接收到更新的控制信息时，添加由更新的控制信息表示并且相应于包括在数据发送单元中的对象的对象ID而设置的数据发送单元更新事件ID，并将该数据发送单元更新事件的产生通知给客户机，和

第五处理过程，用于允许客户机识别与由所述第四处理过程获得的数据发送单元更新事件ID相符的所述表信息的数据发送单元更新事件ID的对象ID，并且指明由所述识别的对象ID表示的对象作为更新的对象。

15.如权利要求14所述的数据发送控制方法，其特征在于，所述方法是以下列方式构建的：该方式使得，在从所述服务器获得对于所述事件通知请求的响应消息之后，作为所述第二处理过程的所述事件通知请求立即执行。

16.一种发送多媒体数据的数据发送方法，其特征在于

一事件通知是由时间信息和事件名称构成的，在所述时间信息的位置处定义表示一事件要立即产生的代码，和

当打算立即产生该事件时，所述表示该事件要立即产生的代码被安排在所述事件通知的所述时间信息的位置并对其进行发送。

17.如权利要求16所述的数据发送方法，其特征在于，所述表示事件要立即产生的代码从不能作为所述时间信息存在的代码中选择。

18.如权利要求16所述的数据发送方法，其特征在于，包括所述表示事件要立即产生的代码的所述事件通知是在提前于打算产生该事件的时刻的作为预定数据处理时间的一时刻发送的。

19.如权利要求16所述的数据发送方法，其特征在于，包括所述表示事件要立即产生的代码的所述事件通知是在提前于打算产生该事件的时刻的作为预定数据处理时间的一时刻发送的，并且之后，以预定周期重复发送类似事件通知。

20.如权利要求19所述的数据发送方法，其特征在于，所述类似事件通知是以预定周期重复发送的，直到开始下一个事件。

21.如权利要求19所述的数据发送方法，其特征在于，所述类似事件通知是以预定周期重复发送的，直到节目结束。

22.如权利要求16所述的数据发送方法，其特征在于，包括所述表示事件要立即产生的代码的所述事件通知和描述所述时间信息的一事件通知是混合发送的。

23.如权利要求16所述的数据发送方法，其特征在于，当存在多个所述事件时，所述各事件对作为相同目标的数据的每个事件进行组合，并且，当同时发送多个组的事件信息时，所述每个组的多个事件信息合并为一个事件包并被发送。

24.一种数据发送设备，其特征在于，该设备包括：

用于发送由时间信息和事件名称构成的事件通知的装置；和

用于发送其中表示一事件要立即产生的代码安排在所述时间信息的位置处的事件通知的装置。

25.一种接收设备，其特征在于，该设备包括：

用于接收一事件通知的装置；和

一装置，用于当接收到包括时间信息的事件通知时，按照由所述事件通知发送的时间信息产生一事件，并且当接收到包括表示立即产生事件的代码的事件通知时，立即产生所述事件。

26.一种接收设备，其特征在于，

该设备作为一种接收发送信息的接收设备，该发送信息中形成一个场景的场景数据相应于一个或多个信息发送单元，并且包含一个或多个所述信息发送单元的发送数据是周期性发送的，所述接收设备包括：

接收装置，用于接收所述发送信息并取出作为接收数据的所述信息；

场景数据取出装置，具有可按所述信息发送单元临时存储数据的存储器装置，所述场景数据取出装置用于从所述接收数据中提取基于所述信息发送单元的数据，将所述数据存储到所述存储器装置中，并且将作为保持在所述存储器装置中的所述场景数据的信息发送单元发送并存储到用于存储场景数据的场景数据存储装置中；

场景输出装置，能够使用存储在所述场景数据存储装置中的场景数据中的所需场景数据来输出一场景；

信息获得装置，用于从由所述接收装置接收的发送信息中获得表示场景优先级的场景优先级信息；和

控制装置，用于控制所述场景数据取出装置，以便根据由所述信息获得装置获得的场景优先级信息，来选择作为要从接收数据中提取出并存储在所述存储器装置中的场景数据的信息发送单元。

27.如权利要求26所述的接收设备，其特征在于，

所述控制装置根据所述场景优先级信息，鉴别要按照由所述场景输出装置输出的场景作改变的场景的优先级；和

所述控制装置控制所述场景数据取出装置，其控制方式使得，按照所述鉴别的场景优先级获得要存储在所述场景数据存储装置中的场景数据，并且选择作为要从接收数据中提取并存储在存储器装置中的所述场景数据的信息发送单元。